DETAILED ACTION
This action is in response to communication filed on 2/12/2025.
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 6, 13, and 18 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 6, and 17 of copending Application No. 18/1224,556 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because these additions are an obvious extension of the parent’s AI-driven prediction of performance/failure states and causes, as one of ordinary skill would have been motivated to apply the parent’s predictive output to enable proactive configuration optimization and failure prevention under MPEP 2143(D).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 2 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The term “known standard configuration” in claim 2 is a relative term which renders the claim indefinite. The term “known standard configuration” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
It is unclear what qualifies as a “standard” configuration and how such a configuration is determined to be “known”. The specification does not define or provide objective boundaries from this term. For example, it is unclear whether the “standard configuration” refers to an industry standard, a vendor recommended configuration, an operator defined baseline, a previously learned optimal configuration, or some other criteria. Because the metes and bonds of the claim cannot be reasonably ascertained, claim 2 is indefinite.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 7-9, 12-15 and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Melodia et al. (US 2022/0167236).
Regarding claim 1, Melodia discloses a computer implemented method for determining optimized network configuration, the method comprising:
receiving, at a performance analysis server (PAS), from a plurality of nodes of a network environment, a plurality of performance parameters for each of the plurality of nodes and a plurality of network parameters for the network environment (Melodia discloses receiving performance metrics and key performance indicators (KPIs/KPMs) from base stations (nodes) in the network at a central controller (RIC hosting xApps), where the data includes multiple type of performance parameters that characterize the state of the network and its nodes/slices; [0072] “The data 108′ received may include at least one key performance metric (KPM) (not shown) or key performance indicator (KPI) (not shown). For non-limiting example, the at least one KPM or KPI may be associated with throughput, service latency, quality of service (QoS), signal-to-noise ratio, telemetry, or a combination thereof”, [0088] “Through the O-RAN E2 interface, an example embodiment of a DRL agent running on a RIC xApp is fed with real-time performance measurements related to the network slices instantiated on the base stations of the network controlled by O-RAN”); and
generating, using an artificial intelligence and/or machine learning (AI) engine, based on at least one of: the plurality of performance parameters, or the plurality of network parameters, a network status for the network environment, the network status comprising at least one of: a performance state of a node from the plurality of nodes, wherein at least one performance parameter from the plurality of performance parameters causes the performance state, or a network state of at least a portion of the network environment, wherein at least one network parameter from the plurality of network parameters causes the network state; (Melodia discloses using a data driven logic unit (AI/ML engine) that includes an autoencoder and a deep reinforcement learning (DRL) agent. The autoencoder processes the received performance metrics to produce a “presentation describing the state of the RAN”; [0075] “the data-driven logic unit 206 includes an autoencoder 216 and a deep reinforcement learning (DRL) agent 218. The autoencoder 216 may be configured to produce the representation describing the state. The DRL agent 218 may be configured to instruct the action 212”, [0076] “The autoencoder 216 may be configured to modify the data 208′ by padding the data 208′ received in an event data is missing from the data 208′ received. The autoencoder may be further configured to decrease dimensionality of the data 208′ received, or decrease dimensionality of the data 208′ received and modified, to produce a reduced data set (not shown) of the specific type of data for the DRL agent 218. The autoencoder 216 may be further configured to encode the reduced data set to produce the representation describing the state of the RAN”, [0088] “data goes through an autoencoder for dimensionality reduction, the output is then used by the agent that identifies the state of the system and uses a fully connected neural network to determine the best scheduling policy for the corresponding slice together with the configuration of the slice”),
determining a configuration change based on at least one of: the performance parameter, or the network parameter (Melodia discloses that after the AI/ML engine generates the state representation from the performance metric, the DRL agent determines optimal configuration changes (e.g., slice configuration, scheduling policy, resource allocation, load balancing) and transmit them to the base stations/nodes for implementation; [0087] “the DRL agent is able to dynamically select the optimal configuration of the base stations of the network, and of the network slices instantiated on them (e.g., slices configuration and scheduling policy to execute at each slice) based on the performance metrics sent by the base stations at run-time”, [0089] “An example embodiment optimally selects configurations for each network slice instantiated on the network base stations based on performance metrics sent by the base stations. An example embodiment communicates the found optimal configurations to the base stations controlled by O-RAN through the O-RAN E2 interface”).
Regarding claim 2, Melodia discloses the computer implemented method of claim 1, wherein the determining the configuration change is further based on a comparison of at least one of: a network environment configuration with a known standard network configuration, or configuration of at least one node from the plurality of the nodes with a known standard configuration of the at least one node (Melodia [0087] “The DRL agent is able to dynamically select the optimal configuration of the base stations of the network, and of the network slices instantiated on them (e.g., slices configuration and scheduling policy to execute at each slice) based on the performance metrics sent by the base stations at run-time”).
Regarding claim 3, Melodia discloses the computer implemented method of claim 1, wherein the at least one performance parameter of the node comprises at least one of: a status of hardware or a software of the node, and wherein the at least one network parameter comprises at least one of: a bandwidth, traffic, or anomalies in at least one layer of the open systems interconnection (OSI) model, or usage of the node or the network environment (Melodia [0072] “The data 108′ received may include at least one key performance metric (KPM) (not shown) or key performance indicator (KPI) (not shown). For non-limiting example, the at least one KPM or KPI may be associated with throughput, service latency, quality of service (QoS), signal-to-noise ratio, telemetry, or a combination thereof”).
Regarding claim 7, Melodia discloses the computer implemented method of claim 1, wherein the configuration change comprises at least one of:
dynamic resource allocation, activation of firewalls, traffic flow optimization, traffic distribution, Quality of Service (QoS) optimization, anomaly detection and troubleshooting, predictive analysis, dynamic load balancing, Software-Defined Wide Area Network (SD-WAN) optimization, packet level optimization, network slicing, auto-configuration and provisioning of network, or energy optimization (Melodia [0087] “The DRL agent is able to dynamically select the optimal configuration of the base stations of the network, and of the network slices instantiated on them (e.g., slices configuration and scheduling policy to execute at each slice) based on the performance metrics sent by the base stations at run-time”).
Regarding claim 8, Melodia discloses the computer implemented method of claim 1, comprising executing the configuration change to modify the network status (Melodia [0070] “The data-driven logic unit 106 is configured to (i) produce, based on data 108′ received from the RAN via the interface 104, a representation 110 describing a state of the RAN and (ii) based on the representation 110 describing the state, instruct an action 112 associated with at least one network element (not shown). The interface 104 may produce the data 108′ by transforming the data 108 received from the RAN. Such transformation may be implemented via Abstract Syntax Notation One (ASN. 1) decoding, for non-limited example. The interface 104 is configured to transmit a message 114 based on the action 112 instructed, the message 114 to be routed to the at least one network element. The representation 110 describing the state is based on a context of the RAN. The message 114 that is transmitted enables re-configuration of the at least one network element. The re-configuration improves performance of the at least one network element within the context”).
Regarding claim 9, Melodia discloses the computer implemented method of claim 8, wherein the executing comprises transmitting a set of signals to the plurality of nodes to execute the configuration change determined by the AI engine, wherein the set of signals comprises one or more instructions executable by the plurality of nodes (Melodia [0072] “The action 112 instructed may include at least one instruction to alter at least one parameter of the at least one network element. The data 108′ received may include at least one key performance metric (KPM) (not shown) or key performance indicator (KPI)”).
Regarding claim 12, Melodia discloses the computer implemented method of claim 1, wherein the plurality of performance parameters comprises at least one of:
device performances, errors, usage timing, utilization of the network bandwidth, network key performance indicators (KPI), current network configuration, topology, segmentation, software versions of the plurality of nodes, traffic patterns, check protocol performances, security measures, Internet Protocol (IP) provisioning, network diameter, jitter, power consumption, or Voice-over IP (VOIP) quality (Melodia [0005] “The data received may include at least one key performance metric (KPM) or key performance indicator (KPI). For non-limiting example, the at least one KPM or KPI may be associated with throughput, service latency, quality of service (QoS), signal-to-noise ratio, telemetry, or a combination thereof”).
Regarding claim(s) 13-15 and 19, do(es) not teach or further define over the limitation in claim(s) 1-3 and 8-9 respectively. Therefore claim(s) 13-15 and 19 is/are rejected for the same rationale of rejection as set forth in claim(s) 1-3 and 8-9 respectively.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4-5 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Melodia et al. (US 2022/0167236) in view of Carmel et al. (US 2016/0315837).
Regarding claim 4, Melodia discloses the invention substantially, however the prior art does not explicitly disclose the computer implemented method of claim 1, wherein the determining the configuration change comprises:
identifying, a subset of nodes from the plurality of nodes associated with at least one of: the at least one performance parameter causing the performance state of each of the subset of nodes, or at least a portion of the network environment causing and the network state of the plurality of nodes respectively;
generating, using an optimizer module, a set of configuration changes that shift the network status of the plurality of nodes to a desired network status based on at least one of: the at least one performance parameter of the subset of nodes, or the at least one network parameter of the network, wherein the desired status is configured to optimize operation of the plurality of nodes; and
selecting the configuration change from the set of configuration changes.
Carmel in the field of the same endeavor discloses technique for identifying the specific subset of nodes tied to the performance or network parameters causing a detected state, generate multiple candidate configuration changes that shift the overall network status to a desired optimized condition, and then select the optimal change from that set. In particular, Carmel teaches the following:
identifying, a subset of nodes from the plurality of nodes associated with at least one of: the at least one performance parameter causing the performance state of each of the subset of nodes, or at least a portion of the network environment causing and the network state of the plurality of nodes respectively (Carmel [0037] “A determination may then be made as to whether the multiple application nodes do not satisfy a health rule at step 350. In some cases, multiple nodes may collectively not satisfy a particular health rule. In many instances, the multiple nodes may not satisfy the health rule due to the same reasons. In some embodiments, the multiple nodes may fail to satisfy the health rule for the same reason but at different degrees of violation”);
generating, using an optimizer module, a set of configuration changes that shift the network status of the plurality of nodes to a desired network status based on at least one of: the at least one performance parameter of the subset of nodes, or the at least one network parameter of the network, wherein the desired status is configured to optimize operation of the plurality of nodes (Carmel [0034] “An action is selected to apply to the selected application node at step 420. The action may be selected by policy engine 220. The policy engine may be configured to do a particular action for a particular health rule violation. Different levels of violations may correspond to different actions. In some embodiments, the selected action may be a first action from a list of several actions. The actions may be presorted based on the probability they have of succeeding”, [0042] “If the selected application does not satisfy the health node (or does not improve performance), a determination is made as to whether there are more actions to apply at step 450. For example, there may be additional actions in a list of actions to apply to the particular type of node in view of the particular health rule violation. If there are more actions to apply, the next action is selected at step 460 and the method of FIG. 4 returns to step 430”); and
selecting the configuration change from the set of configuration changes (Carmel [0043] “The selected action may be applied if the health rule is satisfied or there is improvement in the performance of the node. The selected action may then be set as the first action in a list of actions to be applied for future health rule violations of this type at step 480. The results are then reported to an administrator or otherwise, as configured by a user or administrator, at step 490”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Carmel. One would have been motivated to predictably improved the efficiency and precision of the prior art AI driven network status determination and configuration process by enabling targeted, multi-option optimization focused only on affected nodes.
Regarding claim 5, Melodia-Carmel discloses the computer implemented method of claim 1, wherein the determining comprises:
comparing at least one of: the at least one performance parameter, or the at least one network parameter with a corresponding threshold range (Carmel [0032] “Health rules 210 may include one or more rules which specify an expression involving a metric. The expression may relate to one or more business applications, a method, a cluster, a node, a resource, or some other entity. Examples of an expression may include “response time greater than one second”, or “CPU usage greater than 80%”, “processing time greater than a fourth standard deviation,” “error rate greater than 0.5%”, or some other metric”); and
determining, using an optimizer module, one or more instructions to modify at least one of: the at least one performance parameter or the at least one network parameter, wherein the one or more instructions, when executed by the plurality of nodes, cause at least one of: the at least one performance parameter, or the at least one network parameter to be within the corresponding threshold range (Carmel [0034] “Policy engine 220 determines what action should be applied to an application or node based on the health rule violation detected. A policy engine 220 may detect that a health rule is violated by a particular node and select a particular action to apply to the node”, [0040] “An action is selected to apply to the selected application node at step 420. The action may be selected by policy engine 220. The policy engine may be configured to do a particular action for a particular health rule violation. Different levels of violations may correspond to different actions”, [0043] “If the selected application does satisfy the health node, the selected action may be applied to the remainder of the application nodes in the cluster at step 470. The selected action may be applied if the health rule is satisfied or there is improvement in the performance of the node”. Rationale to combine is similar to claim above).
Regarding claim(s) 16-17, do(es) not teach or further define over the limitation in claim(s) 4-5 respectively. Therefore claim(s) 16-17 is/are rejected for the same rationale of rejection as set forth in claim(s) 4-5 respectively.
Claims 6, 11, 18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Melodia et al. (US 2022/0167236) in view of DaSilva et al. (US 2023/0300654).
Regarding claim 6, Melodia discloses the invention substantially, however the prior art does not explicitly disclose the computer implemented method of claim 1, further comprising:
forecasting, using the AI engine, the network status of the plurality of nodes for a first time interval in the future; and
determining the configuration change based on the forecasted network status.
DaSilva in the field of the same endeavor discloses techniques for AI/ML to analyze performance parameters from network nodes and network parameters to determine network status and then derive configuration changes for optimization. In particular, DaSilva teaches the following:
forecasting, using the AI engine, the network status of the plurality of nodes for a first time interval in the future (DaSilva [0176] “the UE 103 may be able to get a vector or list with a time series predictions for occurrences of OOS events, such as [X OOS OOS OOS OOS] with the first value at t0 meaning that all is fine, represented by an X, then one can see that at t0+T UE may predict an OOS event, same at t0+2T, same at t0+3T, so if N310*=3, where N310* may be something different for predictions compared to N310 for real failure, perhaps more conservative for predictions N310*>>N310, or even a mapping based on probabilities and N310* represents consecutive OOS predictions to predict starting T310 timer. Hence, somehow at t0+3T, the UE 103 may predict the occurrence the start of timer T310. Then, knowing the value of timer T310, the UE 103 may check further predictions, and also predict if OOS continues and/or no IS event is expected while timer T310 is running. For example, if timer T310* value = T, and at t0+4T there was no IS event, the UE 103 may predict the expiry of timer T310, hence, predict the failure declaration in advance, in this example, 4T in advance”); and
determining the configuration change based on the forecasted network status (DaSilva [0176] “if measurement reports are being transmitted, that information may be comprised in the reports so that it may be helpful to the network node 101 to decide whether a handover shall be performed or not. Or, even if some reliability feature should be enabled e.g. DAPS and/or CHO and/or timer T312, etc.”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with teaching of DaSilva. One would have been motivated because DaSilva enhances the prior art with forward-looking adaptation for improved reliability and efficiency in networked environments.
Regarding claim 11, Melodia-DaSilva discloses the computer implemented method of claim 9, wherein the set of signals are transmitted through signals transmitted through at least one level of open system interconnection (OSI) model (DaSilva [0059] “It should be noted that the communication links in the wireless communications network 100 may be of any suitable kind comprising either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer, e.g. as indicated by the Open Systems Interconnection (OSI) model, as understood by the person skilled in the art”. Rationale to combine is similar to claim above).
Regarding claim(s) 18 and 20, do(es) not teach or further define over the limitation in claim(s) 6 and 11 respectively. Therefore claim(s) 19 and 20 is/are rejected for the same rationale of rejection as set forth in claim(s) 6 and 11 respectively.
Claims 10 are rejected under 35 U.S.C. 103 as being unpatentable over Melodia et al. (US 2022/0167236) in view of Mermoud et al. (US 2023/0164029).
Regarding claim 10, Melodia discloses the the prior art does not explicitly disclose the computer implemented method of claim 9, wherein the set of signals to indicate to an operator to manually execute the configuration change.
Mermoud in the field of the same endeavor discloses techniques for recommending configuration changes in software-defined networks using machine learning. In particular, Mermoud teaches the following:
wherein the set of signals to indicate to an operator to manually execute the configuration change (Mermoud [0085] “Such recommendations may be provided to a user interface for review by an administrator or implemented, automatically, in various embodiments. For instance, change suggestion module 508 may generate a list of differences in some structured format (akin to the output of code versioning tools such as Git or the Gnu diff command) that can be readily applied by the administrator, or even by an automated mechanism”).
Therefore, it would have been obvious to a person of ordinary in the art at the time the invention was effectively filed to combine the prior art with the teaching of Mermoud. One would have been motivated because the combination would predictably yield the know, desirable results of a flexible hybrid system supporting either automated execution or operator notification for manual intervention when human oversight is preferred.
Conclusion
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chris Parry can be reached at 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights