DETAILED ACTION
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 .
Status of the Application
This Office action is in response to the amendment and remarks filed June 11, 2026. Claims 1, 9, and 17 have been amended; no claims have been cancelled; and no claims have been added. Claims 1-20 are pending and are examined herein.
THIS ACTION IS MADE FINAL. The new grounds of rejection of claims 1-7, 9-15, and 17-20 set forth below were necessitated by Applicant’s amendment of independent claims 1, 9, and 17, which added the limitation that the write storage and the read storage are comprised in the apparatus associated with an SMO function within the SMO, the SMO function being distinct from the O-RAN network element. The rejection of claims 8 and 16 has been modified to address the first and second digital twins recited in those claims. Accordingly, this action is properly made final. See MPEP 706.07(a).
Response to Arguments
Applicant’s arguments filed June 11, 2026 have been fully considered. Applicant’s arguments directed to claims 8 and 16, and Applicant’s argument that Ranganath discloses a single database used for both reading and writing, are persuasive. The rejections are revised accordingly and set forth in full below. The remaining arguments are not persuasive.
With respect to Applicant’s argument that “Ranganath in view of RFC 6241 does not disclose or suggest a read storage and a write storage respectively used to obtain and update configuration(s) of the same ”O-RAN network element,“ wherein the ”write storage [is] different from the read storage“” (Remarks, pages 12-13), the argument is persuasive as to Ranganath and the rejection no longer relies on Ranganath for that limitation. Applicant is correct that Ranganath’s DB 1216 is a single database that is read from and written to, and Applicant is likewise correct that the passages of Ranganath previously cited describe communication link measurements rather than separate storages. The separation of the read storage from the write storage is instead taught by RFC 6241, which defines two distinct configuration datastores: a running configuration datastore that holds the configuration currently active on the device and is the source read by the <get-config> operation, and a candidate configuration datastore that is written by the <edit-config> operation and that is thereafter committed to the running configuration datastore. Those passages are quoted in the rejection set forth below.
In regard to Applicant’s argument that “the cited art does not suggest ”wherein the write storage and the read storage are comprised in the apparatus associated with an SMO function within the SMO, the SMO function being distinct from the O-RAN network element from which the configuration data is obtained or to which the configurations are updated“” and that “Ranganath’s disclosure is directed to an xApp manager that obtains telemetry data; the xApp manager is located within the near RT RIC, which is external to the SMO” (Remarks, page 13), the argument is not persuasive. The rejection does not rely on the xApp manager or on the near-RT RIC for this limitation. Ranganath separately describes the O-RAN management architecture in which the non-RT RIC function resides in the SMO layer, which also handles deployment and configuration, and in which the SMO is connected by the O1 interface to the O-RAN network functions. Ranganath further describes that rApps operate within the non-RT RIC and that the non-RT RIC framework is functionality internal to the SMO. The SMO function is therefore distinct from the O-RAN network element whose configurations are obtained or updated, as quoted in the rejection below.
As to Applicant’s argument that claims 8 and 16 are patentable because “the cited art plainly fails to disclose a digital twin, let alone distinct digital twins as claimed” and that “The Office Action fails to even address or recognize this limitation explicitly recited in the claim” (Remarks, page 14), the argument is persuasive. The prior Office action treated claim 8 as an apparatus variant of claim 1 and did not address the recited first and second digital twins. Claims 8 and 16 are accordingly rejected below on a new ground of rejection that additionally relies on ITU-T Y.3090. Applicant’s arguments directed to the dependent claims (Remarks, page 14) rely on the patentability of the independent claims and are unpersuasive for the reasons given above and for the reasons set forth in the rejections below.
Accordingly, the rejections below constitute new grounds of rejection necessitated by Applicant’s amendment, and THIS ACTION IS MADE FINAL.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/26/2026 was filed after the mailing date of the non-final office action on 03/11/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner
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 (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 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, 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.
Claims 1-7, 9-15, and 17-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Ranganath (US 2024/0259879 A1) in view of RFC 6241 (“Network Configuration Protocol (NETCONF)”, June 2011).
Regarding claim 1, (Currently Amended) Ranganath discloses: An apparatus configured to: receive, from an rApp or other Service Management and Orchestration (SMO) functions, at least one of a request to obtain a configuration data of an O-RAN network element, and a request to update configurations of an O-RAN network element; because Ranganath teaches that the non-RT RIC operates one or more rApps whose functionality enables control and optimization of RAN elements, and that the service management and orchestration framework is connected by the O1 interface to the O-RAN network functions and itself handles deployment and configuration: (Ranganath, para [0161] “The non-RT RIC 912 can include and/or operate one or more non-RT RIC applications (rApps) 911”; Ranganath, para [0161] “The rApp 911 functionality within the non-RT RIC 912 enables non-RT control and optimization of RAN elements (or RANFs) and resources”; Ranganath, para [0143] “which connect the service management and orchestration framework (SMO) 802 to O-RAN network functions (NFs) 804 and the O-Cloud 806”).
Even though Ranganath teaches the apparatus and the receipt of configuration requests from an rApp or other SMO functions: (Ranganath, para [0143], [0148], [0161]), Ranganath does not explicitly disclose obtaining the configuration data using a read storage, or updating the configurations using a write storage different from the read storage.
However, Ranganath in view of RFC 6241 discloses in response to receiving the request to obtain the configuration data of the O-RAN network element, obtain the configuration data using a read storage; and because RFC 6241 teaches a <get-config> operation that retrieves all or part of a specified configuration datastore identified by a source parameter, and defines the running configuration datastore as the datastore holding the configuration currently active on the device: (RFC 6241, § 7.1, page 35, “Retrieve all or part of a specified configuration datastore”; RFC 6241, § 7.1, page 35, “source: Name of the configuration datastore being queried, such as <running/>”; RFC 6241, § 1.1, page 7, “running configuration datastore: A configuration datastore holding the complete configuration currently active on the device”).
Furthermore, Ranganath in view of RFC 6241 discloses in response to receiving the request to update the configurations of the O-RAN network element, update the configurations of the O-RAN network element based on a configuration provided in the request using a write storage different from the read storage; because RFC 6241 teaches an <edit-config> operation that loads a specified configuration to a specified target configuration datastore, and defines the candidate configuration datastore, which is written in this manner, as a datastore separate from the running configuration datastore to which it is thereafter committed: (RFC 6241, § 7.2, page 37, “The <edit-config> operation loads all or part of a specified configuration to the specified target configuration datastore”; RFC 6241, § 1.1, page 7, “candidate configuration datastore: A configuration datastore that can be manipulated without impacting the device’s current configuration and that can be committed to the running configuration datastore”).
Ranganath further discloses wherein the write storage and the read storage are comprised in the apparatus associated with an SMO function within the SMO, the SMO function being distinct from the O-RAN network element from which the configuration data is obtained or to which the configurations are updated. because Ranganath teaches that the non-RT RIC function resides in the SMO layer, which handles deployment and configuration, that the non-RT RIC framework is functionality internal to the SMO, and that the O-RAN network elements to be configured, including the O-RAN Distributed Unit and the O-RU, are on the radio side of the architecture and separate from the SMO: (Ranganath, para [0143] “The non-RT RIC function 812 resides in the SMO layer 802 that also handles deployment and configuration, as well as data collection of RAN observables and the like”; Ranganath, para [0161] “The non-RT RIC framework refers to functionality internal to the SMO 902”; Ranganath, para [0148] “The radio side of the logical architecture 900 includes the near-RT RIC 914, the O-RAN Distributed Unit (O-DU) 915, the O-RU 916”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to implement the configuration retrieval and configuration update requests handled by Ranganath’s SMO using the standardized NETCONF operations of RFC 6241, such that the configuration data is obtained from the running configuration datastore and the configuration provided in the request is written to the separate candidate configuration datastore, because doing so would have applied a known, standardized configuration protocol to an architecture that Ranganath already describes as handling deployment and configuration, and would have predictably allowed configuration changes to be staged without disturbing the configuration currently active on the network element.
Regarding claim 2, (Original) Ranganath in view of RFC 6241 discloses: The apparatus according to claim 1, wherein the apparatus is configured to obtain the configuration data using the read storage by: determining whether the configuration data is stored in the read storage; and as RFC 6241 further teaches that the filter parameter of the <get-config> operation identifies the portions of the configuration datastore to be retrieved: (RFC 6241, § 7.1, page 36, “This parameter identifies the portions of the device configuration datastore to retrieve”).
Furthermore, Ranganath in view of RFC 6241 discloses in response to determining that the configuration data is stored in the read storage, transmitting the configuration data from the read storage to the rApp or other SMO functions. as RFC 6241 further teaches that a positive response to <get-config> returns the results of the query to the requesting client: (RFC 6241, § 7.1, page 36, “If the device can satisfy the request, the server sends an <rpc-reply> element containing a <data> element with the results of the query”). Accordingly, the rationale to combine Ranganath and RFC 6241 is the same as set forth for claim 1 above.
Regarding claim 3, (Original) Ranganath in view of RFC 6241 discloses: The apparatus according to claim 1, wherein the apparatus is configured to update the configurations of the O-RAN network element based on the configuration provided in the request using the write storage by: receiving the configuration from the rApp or other SMO functions; storing the received configuration in the write storage; and as RFC 6241 further teaches that the <edit-config> operation loads the specified configuration into the specified target configuration datastore: (RFC 6241, § 7.2, page 37, “The <edit-config> operation loads all or part of a specified configuration to the specified target configuration datastore”).
Furthermore, Ranganath in view of RFC 6241 discloses updating the configurations of the O-RAN network element based on the received configuration stored in the write storage. as RFC 6241 further teaches that, once the candidate configuration is complete, the configuration data is committed and published to the rest of the device, which is thereby required to conform to the new configuration: (RFC 6241, § 8.3.4.1, page 54, “When the candidate configuration’s content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration”). Accordingly, the rationale to combine Ranganath and RFC 6241 is the same as set forth for claim 1 above.
Regarding claim 4, (Original) Ranganath in view of RFC 6241 discloses: The apparatus according to claim 3, wherein the apparatus is further configured to update the configurations the O-RAN network element based on the configuration provided in the request using the write storage by, after updating the configurations of the O-RAN network element based on the received configuration stored in the write storage, updating the read storage based on the received configuration stored in the write storage. as RFC 6241 further teaches that the commit operation sets the running configuration, which is the datastore read by <get-config>, to the current contents of the candidate configuration: (RFC 6241, § 8.3.1, page 54, “The <commit> operation effectively sets the running configuration to the current contents of the candidate configuration”). Accordingly, the rationale to combine Ranganath and RFC 6241 is the same as set forth for claim 1 above.
Regarding claim 5, (Original) Ranganath in view of RFC 6241 discloses: The apparatus according to claim 3, wherein the apparatus is further configured to update the configurations of the O-RAN network element based on the configuration provided in the request using the write storage by: after storing the received configuration in the write storage, transmitting a first response to the rApp or other SMO functions, wherein the first response is configured to notify the rApp or other SMO functions that the received configuration is stored in the write storage; and as RFC 6241 further teaches that a positive response to the <edit-config> operation that loaded the configuration into the target datastore is returned to the client: (RFC 6241, § 7.2, page 40, “If the device was able to satisfy the request, an <rpc-reply> is sent containing an <ok> element”).
Furthermore, Ranganath in view of RFC 6241 discloses after updating the configurations of the O-RAN network element based on the received configuration stored in the write storage, transmitting a second notification to the rApp or other SMO functions, wherein the second notification is configured to notify the rApp or other SMO functions that the configurations of the O-RAN network element are updated based on the received configuration stored in the write storage. as RFC 6241 further teaches that the subsequent <commit> operation likewise returns a positive response to the client once the candidate configuration has been published to the device: (RFC 6241, § 8.3.4.1, page 55, “If the device was able to satisfy the request, an <rpc-reply> is sent that contains an <ok> element”). Accordingly, the rationale to combine Ranganath and RFC 6241 is the same as set forth for claim 1 above.
Regarding claim 6, (Original) Ranganath in view of RFC 6241 discloses: The apparatus according to claim 1, wherein: the O-RAN network element is a first O-RAN network element; the apparatus is further configured to receive, from an rApp or other SMO functions, a request to obtain a configuration data of a second O-RAN network element different from the first O-RAN network element; and because Ranganath teaches that the radio side of the architecture includes a plurality of distinct O-RAN network elements: (Ranganath, para [0148] “The radio side of the logical architecture 900 includes the near-RT RIC 914, the O-RAN Distributed Unit (O-DU) 915, the O-RU 916”).
Furthermore, Ranganath in view of RFC 6241 discloses the request to obtain the configuration data of the first O-RAN network element and the request to obtain the configuration data of the second O-RAN network element are bundled into a single Application Programming Interface (API) call. as RFC 6241 further teaches that the protocol exposes a full, formal application programming interface through which applications send and receive full and partial configuration data sets, using a single remote procedure call mechanism: (RFC 6241, § 1.1, page 6, “The protocol allows the device to expose a full, formal application programming interface (API). Applications can use this straightforward API to send and receive full and partial configuration data sets”; RFC 6241, § 1.2, page 8, “NETCONF uses a simple RPC-based mechanism to facilitate communication between a client and a server”). Accordingly, the rationale to combine Ranganath and RFC 6241 is the same as set forth for claim 1 above.
Regarding claim 7, (Original) Ranganath in view of RFC 6241 discloses: The apparatus according to claim 1, wherein: the O-RAN network element is a first O-RAN network element; the apparatus is further configured to receive, from an rApp or other SMO functions, a request to update configurations of a second O-RAN network element different from the first O-RAN network element based on a configuration provided in the request to update the configurations of the second O-RAN network element; and because Ranganath teaches a plurality of distinct O-RAN network elements on the radio side of the architecture: (Ranganath, para [0148] “The radio side of the logical architecture 900 includes the near-RT RIC 914, the O-RAN Distributed Unit (O-DU) 915, the O-RU 916”).
Furthermore, Ranganath in view of RFC 6241 discloses the request to update the configurations of the first O-RAN network element and the request to update the configurations of the second O-RAN network element are bundled into a single Application Programming Interface (API) call. as RFC 6241 further teaches that a single <edit-config> call loads all or part of a specified configuration to the target datastore, and that the protocol exposes a formal API by which applications send full and partial configuration data sets: (RFC 6241, § 7.2, page 37, “The <edit-config> operation loads all or part of a specified configuration to the specified target configuration datastore”; RFC 6241, § 1.1, page 6, “Applications can use this straightforward API to send and receive full and partial configuration data sets”). Accordingly, the rationale to combine Ranganath and RFC 6241 is the same as set forth for claim 1 above.
Regarding claim 9, (Currently Amended) the claim recites: A method comprising: receiving, from an rApp or other SMO functions, at least one of a request to obtain a configuration data of an O-RAN network element, and a request to update configurations of an O-RAN network element; in response to receiving the request to obtain the configuration data of the O-RAN network element, obtaining the configuration data using a read storage; and in response to receiving the request to update the configurations of the O-RAN network element, updating the configurations of the O-RAN network element based on a configuration provided in the request using a write storage different from the read storage; wherein the write storage and the read storage are comprised in an apparatus that performs the method, the apparatus associated with an SMO function within the SMO, the SMO function being distinct from the O-RAN network element from which the configuration data is obtained or to which the configurations are updated. Claim 9 is analogous to claim 1 and therefore is rejected for the same reason.
Regarding claim 10, (Original) the claim recites: The method according to claim 9, wherein the obtaining the configuration data using the read storage comprises: determining whether the configuration data is stored in the read storage; and in response to determining that the configuration data is stored in the read storage, transmitting the configuration data from the read storage to the rApp or other SMO functions. Claim 10 is analogous to claim 2 and therefore is rejected for the same reason.
Regarding claim 11, (Original) the claim recites: The method according to claim 9, wherein the updating the configurations the O-RAN network element based on the configuration provided in the request using the write storage comprises: receiving the configuration from the rApp or other SMO functions; storing the received configuration in the write storage; and updating the configurations of the O-RAN network element based on the received configuration stored in the write storage. Claim 11 is analogous to claim 3 and therefore is rejected for the same reason.
Regarding claim 12, (Original) the claim recites: The method according to claim 11, wherein the updating the configurations of the O-RAN network element based on the configuration provided in the request using the write storage further comprises, after updating the configurations of the O-RAN network element based on the received configuration stored in the write storage, updating the read storage based on the received configuration stored in the write storage. Claim 12 is analogous to claim 4 and therefore is rejected for the same reason.
Regarding claim 13, (Original) the claim recites: The method according to claim 11, wherein the updating the configurations of the O-RAN network element based on the configuration provided in the request using the write storage further comprises: after storing the received configuration in the write storage, transmitting a first response to the rApp or other SMO functions, wherein the first response is configured to notify the rApp or other SMO functions that the received configuration is stored in the write storage; and after updating the configurations of the O-RAN network element based on the received configuration stored in the write storage, transmitting a second notification to the rApp or other SMO functions, wherein the second notification is configured to notify the rApp or other SMO functions that the configurations of the O-RAN network element are updated based on the received configuration stored in the write storage. Claim 13 is analogous to claim 5 and therefore is rejected for the same reason.
Regarding claim 14, (Original) the claim recites: The method according to claim 9, wherein: the O-RAN network element is a first O-RAN network element; the method further comprises receiving, from an rApp or other SMO functions, a request to obtain a configuration data of a second O-RAN network element different from the first O-RAN network element; and the request to obtain the configuration data of the first O-RAN network element and the request to obtain the configuration data of the second O-RAN network element are bundled into a single Application Programming Interface (API) call. Claim 14 is analogous to claim 6 and therefore is rejected for the same reason.
Regarding claim 15, (Original) the claim recites: The method according to claim 9, wherein: the O-RAN network element is a first O-RAN network element; the method further comprises receiving, from an rApp or other SMO functions, a request to update configurations of a second O-RAN network element different from the first O-RAN network element based on a configuration provided in the request to update the configurations of the second O-RAN network element; and the request to update the configurations of the first O-RAN network element and the request to update the configurations of the second O-RAN network element are bundled into a single Application Programming Interface (API) call. Claim 15 is analogous to claim 7 and therefore is rejected for the same reason.
Regarding claim 17, (Currently Amended) the claim recites: A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: receiving, from an rApp or other SMO functions, at least one of a request to obtain a configuration data of an O-RAN network element, and a request to update configurations of an O-RAN network element; in response to receiving the request to obtain the configuration data of the O-RAN network element, obtaining the configuration data using a read storage; and in response to receiving the request to update the configurations of the O-RAN network element, updating the configurations of the O-RAN network element based on a configuration provided in the request using a write storage different from the read storage; wherein the write storage and the read storage are comprised in the apparatus associated with an SMO function within the SMO, the SMO function being distinct from the O-RAN network element from which the configuration data is obtained or to which the configurations are updated. Claim 17 is analogous to claim 1 and therefore is rejected for the same reason. Ranganath additionally teaches the recited recording medium: (Ranganath, para [0302] “may be embodied as a non-transitory machine-readable medium (NTMRM) 1760 including code to direct the processor 1752 to perform electronic operations in the compute node 1750”).
Regarding claim 18, (Original) the claim recites: The non-transitory computer-readable recording medium according to claim 17, wherein the obtaining the configuration data using the read storage comprises: determining whether the configuration data is stored in the read storage; and in response to determining that the configuration data is stored in the read storage, transmitting the configuration data from the read storage to the rApp or other SMO functions. Claim 18 is analogous to claim 2 and therefore is rejected for the same reason.
Regarding claim 19, (Original) the claim recites: The non-transitory computer-readable recording medium according to claim 17, wherein the updating the configurations the O-RAN network element based on the configuration provided in the request using the write storage comprises: receiving the configuration from the rApp or other SMO functions; storing the received configuration in the write storage; and updating the configurations of the O-RAN network element based on the received configuration stored in the write storage. Claim 19 is analogous to claim 3 and therefore is rejected for the same reason.
Regarding claim 20, (Original) the claim recites: The non-transitory computer-readable recording medium according to claim 19, wherein the updating the configurations of the O-RAN network element based on the configuration provided in the request using the write storage further comprises, after updating the configurations of the O-RAN network element based on the received configuration stored in the write storage, updating the read storage based on the received configuration stored in the write storage. Claim 20 is analogous to claim 4 and therefore is rejected for the same reason.
Claims 8 and 16 are rejected under 35 U.S.C. § 103 as being unpatentable over Ranganath (US 2024/0259879 A1) in view of RFC 6241 (“Network Configuration Protocol (NETCONF)”, June 2011) and further in view of ITU-T Y.3090 (02/2022), “Digital twin network - Requirements and architecture”.
Regarding claim 8, (Original) Ranganath discloses: An apparatus configured to: receive, from an rApp or other SMO functions, at least one of a request to obtain a configuration data of an O-RAN network element, and a request to update configurations of an O-RAN network element; because Ranganath teaches that the non-RT RIC operates one or more rApps whose functionality enables control and optimization of RAN elements, and that the service management and orchestration framework is connected to the O-RAN network functions: (Ranganath, para [0161] “The non-RT RIC 912 can include and/or operate one or more non-RT RIC applications (rApps) 911”; Ranganath, para [0143] “which connect the service management and orchestration framework (SMO) 802 to O-RAN network functions (NFs) 804 and the O-Cloud 806”).
Even though Ranganath in view of RFC 6241 teaches the receipt of the configuration requests and the use of a datastore that is read from and a separate datastore that is written to and thereafter committed: (Ranganath, para [0143], [0161]; RFC 6241, § 1.1, page 7; RFC 6241, § 7.1, page 35; RFC 6241, § 7.2, page 37), Ranganath in view of RFC 6241 does not explicitly disclose that the configuration data is obtained using a first digital twin, or that the configurations are updated using a second digital twin different from the first digital twin, the first and second digital twins comprising a full digital replica of the O-RAN network element.
However, Ranganath in view of RFC 6241 and further in view of Y.3090 discloses in response to receiving the request to obtain the configuration data of the O-RAN network element, obtain the configuration data using a first digital twin; and because Y.3090 teaches that the network data collected from the physical network is stored in the virtual twin network as a unified data repository that serves as the single source of truth from which data is provided: (Y.3090, cl. 6, page 3, “Massive network data collected from a physical network can be stored in a virtual twin network as a unified data repository, which can be the single source of truth and provide timely and accurate data support for models”).
Furthermore, Ranganath in view of RFC 6241 and further in view of Y.3090 discloses in response to receiving the request to update the configurations of the O-RAN network element, update the configurations of the O-RAN network element based on a configuration provided in the request using a second digital twin different from the first digital twin, because Y.3090 teaches that a model instance of the virtual twin network carries out the configuration objectives and verifies the change controls within the virtual twin network before those changes are distributed to the physical network: (Y.3090, cl. 8, page 13, lines 16-19: “The model instance needs to complete the full emulation and verification of the prediction, scheduling, configuration, optimization and other objectives in the virtual twin network to ensure the effectiveness and reliability of the change controls before they are distributed to the physical network”).
Furthermore, Ranganath in view of RFC 6241 and further in view of Y.3090 discloses wherein the first digital twin and the second digital twin are comprised in the apparatus, and wherein the first digital twin and the second digital twin comprise a full digital replica of the O-RAN network element. because Y.3090 teaches that the digital twin network is a virtual representation of the physical network achieving a real-time interactive mapping to it, and that the basic model is a network element model of the digital twin entity that completes a real-time accurate description of the physical network: (Y.3090, cl. 3.2.1, page 1, “digital twin network: A virtual representation of a physical network”; Y.3090, cl. 3.2.1, page 1, “to achieve the real-time interactive mapping between the physical network and virtual twin network”; Y.3090, cl. 8, page 13, “Basic model refers to the network element model and network topology model of the network digital twin entity based on the basic configuration, environment information, operational state, link topology and other information of the network element, to complete the real-time accurate description of the physical network”).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to implement the configuration retrieval and configuration update operations of Ranganath’s SMO using the digital twin network of Y.3090, such that the configuration data is obtained from the twin’s unified data repository and the requested configuration change is applied and verified in the twin’s model instance before being distributed to the physical network, because Y.3090 states that doing so ensures the effectiveness and reliability of the change controls, and because separating the repository used to answer read requests from the model instance used to stage configuration changes is the same known arrangement of read and write datastores already taught by RFC 6241 and applied to the same architecture. Ranganath and RFC 6241 are combined for the reasons set forth in the rejection of claim 1 above.
Regarding claim 16, (Original) the claim recites: A method comprising: receiving, from an rApp or other SMO functions, at least one of a request to obtain a configuration data of an O-RAN network element, and a request to update configurations of an O-RAN network element; in response to receiving the request to obtain the configuration data of the O-RAN network element, obtaining the configuration data using a first digital twin; and in response to receiving the request to update the configurations of the O-RAN network element, updating the configurations of the O-RAN network element based on a configuration provided in the request using a second digital twin different from the first digital twin; wherein the first digital twin and the second digital twin are comprised in an apparatus that performs the method, and wherein the first digital twin and the second digital twin comprise a full digital replica of the O-RAN network element. Claim 16 is analogous to claim 8 and therefore is rejected for the same reason.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHONGSUH (John) PARK whose telephone number is 408-918-7574. The examiner can normally be reached Monday - Friday 8:00-5:30 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, Avellino, Joseph can be reached at 571-272-3905 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.
/CHONGSUH PARK/Examiner, Art Unit 2478
/KODZOVI ACOLATSE/Primary Examiner, Art Unit 2478
Prosecution Insights