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 .
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained through the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ranganath (US 2024/0259879 A1) hereinafter “Ranganath” in view of RFC 6241 (“Network Configuration Protocol (NETCONF)”, June 2011) hereinafter “RFC 6241”.
Regarding claim 1, Ranganath discloses: An apparatus configured to receive, from an rApp or other SMO functions, (See Fig. 12 software elements 1228 “rApps” and 1202 “SMO” and paragraph [0005] discloses hardware platform “O-RAN architecture”)
Ranganath, in paragraphs [0025] to [0027] and [0148], teaches configuring an O-RAN architecture 100 that includes an O-RAN distributed unit (O-DU). Similarly, the published specification of the pending application, in paragraph [0045], describes configuring the same O-RAN distributed unit (O-DU). In addition, paragraph [0012] of the published instance of pending application discloses data transfer using at least two storage units within the O-RAN network (see also SUN Fig. 3B, elements 322 and 324). This disclosure inherently relies on the fundamental feature of the distributed storage capability of the O-DU, which allows the read and write storage units to be in separate location within the same distributed O-RAN network environment, as taught by Ranganath (see also Ranganath Fig. 3A, element 115, O-DU): provided in the request using a write storage different from the read storage; (Ranganath in paragraph [0025] and [0027] discloses UE communicated with a distributed data storage VE-to-distributed unit (DU) under O-RAN architecture environment which allow distributed file system to read and write in a different location (i.e., “request using a write storage different from the read storage” as claimed): (“[0025] user equipment (UE) communication traffic to sustain uplink and downlink connections and associated VE-to-distributed unit (DU) and/or VE-to-remote unit (RU) measurements that can be used for intelligent RAN analytics . . . [0027] The O-RAN architecture 100 also includes an O-RAN cloud platform 106, a non-RT RIC 112, . . . an O-RAN distributed unit (O-DU) 115”)
Ranganath teaches: wherein the write storage and the read storage are comprised in the apparatus. Ranganath in Fig.12 and paragraph [0187] disclose a database storage for read/write and modify information on the DB 1216.
With respect to claim 1, Ranganath does not explicitly disclose steps for request to obtaining “a configuration data” and updating configurations of network elements: 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; However, pg.35, RFC-6241 in §7.1 - §7.2 further provides API functionalities where RPC perform operations for configuration of retrieval and modification, including operations such as steps for obtaining specified configuration data (i.e., “a request to obtain a configuration data” as claimed) using “<get-config>” parameter and requests to update configurations data using “<edit-config>” over the network via RPC operation.
Further, Ranganath does not explicitly disclose obtain the configuration data using a read storage: 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; However, pg.35, RFC-6241 §7.1 disclose an operation “<get-config>” for retrieving all or part of specified configuration datastore where the parameter identifies the portions of the device configuration datastore to retrieve. (i.e., “obtain the configuration data using a read storage” as claimed)
Moreover, Ranganath does not explicitly disclose updating the configuration data using a read storage: and 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. However, pg. 37 RFC-6241 §7.2 disclose an operation “<edit-config>” for updating/editing all or part of a specified configuration to the specified target configuration datastore.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify/implement the O-RAN/SMO/rApp apparatus of Ranganath to employ the claimed method of configuration retrieval/update requests using the well-known standardized configuration RPC mechanisms of RFC-6241 (e.g., “<get-config>” to retrieve configuration from a datastore/read storage and “<edit-config>” to update configuration to a target datastore/write storage), thereby meeting the claimed limitations.
Doing so allows the apparatus to expose standardized, network-based configuration read and write operations to rApps/SMO functions, reliably retrieving configuration data from a configuration datastore (read storage) and applying configuration changes to a target datastore (write storage)—while remaining consistent with Ranganath’s disclosed O-RAN/SMO integration and database-backed management approach.
Regarding claim 2, Ranganath in para. [0116] –[0117] teaches a method of configuring an application for sending and receiving messages however, Ranganth does not explicitly disclose determining and obtaining the configuration data using a read storage unit: 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 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.
However, pg.35-36, RFC-6241 §7.1 discloses that <get-config> retrieves all or part of a specified configuration datastore (“source”), (i.e., “obtaining the … determining whether the configuration data is stored in the read storage” as claimed) and that a positive response includes an <rpc-reply> containing a <data> element with the results of the query, (i.e., “in response to determining ... transmitting the configuration data from the read storage to the rApp or other SMO functions” as claimed)
Regarding claim 3, Ranganath does not explicitly disclose updating the configurations of the O-RAN network element based on the configuration provided: 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;
PNG
media_image1.png
542
1928
media_image1.png
Greyscale
However, pg.37, RFC-6241 §7.2 in RFC-6241, the <edit-config> operation loads only the configuration actually present in the <config> parameter for updating the existing configuration at the target location.
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.
Further, pg.54, RFC-6241 §8.3.4.1 discloses a method of updating the configuration into the storage unit when the candidate configuration’s content is complete.
PNG
media_image2.png
428
1988
media_image2.png
Greyscale
Regarding claim 4, Ranganath does not explicitly disclose updating the read storage based on the received configuration stored in the write storage: 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.
However, RFC-6241 in pg. 54 §8.3.4.1 discloses that the <commit> operation When the candidate configuration’s content is complete, the configuration data can be committed, publishing the data set to the rest of the device, which corresponds to updating a read storage based on configuration stored in a write storage.
Regarding claim 5, Ranganath does not explicitly disclose a transaction (involving request-replay steps) based network storage updates and commits: 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 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.
However, this is the same steps from claim 3 and 4 except the claim 5 recites notification functionality of rApp or other SMO, which can be found in RFC-6241 in pg. 55 of §8.3.4.1 describing <rpc> response functionality of standard rpc transaction protocol steps for notifying success or failure (i.e., “. . . 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 claimed)
First notification: <edit-config> has a positive response of an <rpc-reply> containing <ok> (consistent with a first response after loading/storing configuration).
Second notification: <commit> likewise has a positive response of an <rpc-reply> containing <ok> after implementing candidate configuration into running configuration (consistent with a subsequent notification/response that configuration has been applied/updated).
Accordingly, the first and second notifications can consist of one of following responses (see RFC-6241 in pg. 55 of §8.3.4.1)
PNG
media_image3.png
500
1888
media_image3.png
Greyscale
Regarding claim 6, Ranganath does not explicitly disclose: 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 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.
However, RFC-6241 in page 6 discloses that NETCONF is a network configuration protocol (API) allows the device to expose a full, formal application programming interface (API) over the multiple network (i.e., a first O-RAN and second O-RAN network elements as claimed) . Applications can use this straightforward API to send and receive full and partial configuration data sets. Further, page 8 discloses that NETCONF uses a simple RPC-based mechanism to facilitate communication between a client and a server, which indicate that the API call is designed to work over the multiple network elements.
Regarding claim 7, Ranganath does not explicitly disclose: 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 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 7 depends from claim 1 to update configurations of a second O-RAN network element and that the update requests for the first and second O-RAN network elements are bundled into a single API call. Further, RFC-6241 7.2 in page 37 discloses that <edit-config> loads all or part of a specified configuration to a target datastore, and further notes that <edit-config> can contain multiple sub-operations (i.e., multiple configuration changes within a single request), consistent with bundling multiple configuration updates into a single API call. (i.e., . . . “a first and a second O-RAN network element . . . configuration provided” as claimed
Regarding claim 8, 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; 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 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, 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.
Claim 8 is an apparatus variant of claim 1 and therefore, it is rejected under the same rationale
Regarding claim 9, 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 56 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.
Claim 9 is directed to the method counterpart of Claim 1. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 1.
Regarding claim 10, 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 directed to the method counterpart of Claim 1. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 1.
11. 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 directed to the method counterpart of Claim 2. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 2.
12. 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 directed to the method counterpart of Claim 4. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 4.
13. 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 directed to the method counterpart of Claim 5. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 5.
14. 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 directed to the method counterpart of Claim 6. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 6.
15. 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 directed to the method counterpart of Claim 7. Accordingly, it is rejected for the same reasons and based on the same rationale set forth with respect to Claim 7.
16. 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 59 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 recites the same substantive limitations as claim 8, but in method form rather than apparatus form.
17. 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.
Claim 17 is directed to a non-transitory computer-readable recording medium version of claim 1.
18. 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 directed to a non-transitory computer-readable recording medium version of claim 2.
19. 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 directed to a non-transitory computer-readable recording medium version of claim 3.
20. 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 directed to a non-transitory computer-readable recording medium version of claim 4.
Conclusion
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
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478