CTFR 18/553,552 CTFR 86065 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Response to Amendment This is in response to Applicant’s amendment which was filed on 1/20/2026 and has been entered. Claims 26, 36-45 have been amended. Claims 1-25 were previously cancelled. No claims have been added. Claims 26-45 are pending in this application, with claims 26, 36 and 45 being independent. Response to Arguments Amendments to claims 36-44 overcome the rejection under 35 USC 101 and the rejection is withdrawn. Applicant’s arguments with respect to the rejection of the claims under 35 USC 102 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA The factual inquiries 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. 07-21-aia AIA Claim s 26-45 are rejected under 35 U.S.C. 103 as being unpatentable over O-RAN Working Group 2 Non-RT RIC: Functional Architecture , O-RAN.WG2.Non-RT-RIC-ARCH-TR - v01.00 Technical Report, O-RAN ALLIANCE e.V., 2021 Year 02 Month, Internet <URL:https://specifications.o - ran.org/download?id=40 > ( herein after “cited document 1” ) in view of US Publication No. 2016/0124742 (“Rangasamy et al.”) . Regarding claim 26, “cited document 1” discloses an apparatus of a non-real time radio access network intelligent controller (non-RT RIC) network node in an open radio access network (0-RAN) (see lines 22-24 on page 7 and Figure 4.1-1), the device comprising processing circuitry coupled to storage, the processing circuitry configured to: identify a first request received from a data consumer non-RT RIC application (rApp), wherein the first request is received over an R1 termination interface (see lines 22-23 on page 18; lines 19-21 on page 19, the R1 interface describes whether the rApp, which is the producer of the data, has one or more consumer rApps for the data. Or providing a function that does not need to know the nature of the consumer); cause to send a first response to the data consumer rApp in response to the first request (see lines 27-28 on page 19; lines 38-39 on page 19 data registration and data subscription services); and cause to send a notification frame to the data consumer rApp over the R1 termination interface indicating that data will be delivered to the data consumer rApp (see lines 18-20 on page 21, the Non-RT RIC framework determines whether the requested data is already available locally (see lines 23-24 on page 21), as a Non-RT RIC framework data registration service requirement (see lines 35-36 on page 21) In response to receiving the R1 data type request of the consumer rApp, the Non-RT RIC framework needs to set consumption routing rules for the data type in the rApp even if no known data source is found; the Non-RT RIC framework needs to be able to communicate to the R1 consumer rApp whether or not the data consumption needs of the rApp are met by a known data source (see "[REQ - nRTRfW - R1r-60]" and "[REQ - nRTRfW - R1r-70]" on page 22); at some point after the data registration interaction, the rApp initiates a subscription request, after which the Non-RT RIC framework begins providing the actual data measurement instance (see lines 26-29 on page 27). Cited Document 1 describes responding to the consumer request, but does not specify “identify a data producer rApp by checking a data catalog in order to satisfy the first request; cause to send a second request to the data producer rApp over the R1 termination interface” as claimed. In a similar field of endeavor, Rangasamy et al. discloses an intermediary device receives a client request and determines which backend services should satisfy the request. cloud exchange includes an orchestration engine 118 that organizes, directs and integrates underlying software sub-systems 120 for managing various aspects of interconnection within the network infrastructure 122 as well as cloud services management. The orchestration engine 118 may, for example, provide a rule-drive workflow engine that operates between the APIs 114 and the underlying interconnect platform of cloud exchange 100 that includes sub-systems 120 and network infrastructure 122 ([0053]). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to use known API techniques for a service management function that receives a request from a consumer application to invoke requests an identified producer rApp in an O-Ran R1 service architecture to satisfy the request. Regarding claim 36, the above combination discloses the method performed by a non-transitory computer-readable medium storing computer-executable instructions which when executed by one or more processors of a non-real time radio access network intelligent controller (non-RT RIC) network node in an open radio access network (0-RAN) result in performing operations. Regarding claim 45, the above combination discloses the method performed by the apparatus of claim 26. Regarding claims 27 and 37, the above combination discloses the apparatus of claim 26, wherein the first request is a data subscription request, and wherein the first response is a data subscription response (since the Non-RT RIC framework may reject subsequent subscription requests of the data type, it is clear that it responds to the request of the consumer rAPP). Regarding claims 28 and 38, the above combination discloses the apparatus of claim 26, wherein the processing circuitry is further configured to: cause to send a second request to the data producer rApp over the R1 termination interface; and identify a second response from the data producer rApp (cited document 1, in response to the reception of the R1 data type request of the consumer rApp, the Non-RT RIC framework needs to set the consumption routing rule of the data type to the rApp even if the known data source is not found, and the Non-RT RIC framework needs to be able to communicate to the R1 consumer rApp whether or not the data consumption needs of the rApp are satisfied by the known data source; therefore, it is clear that the Non-RT RIC framework responds to the request of the consumer rApp). Regarding claims 29 and 39, the above combination discloses the apparatus of claim 28, wherein the second request is a data subscription request, and wherein the second response is a data subscription response (since the Non-RT RIC framework starts providing an actual data measurement instance, it is clear that the data is distributed to the consumer rAPP). Regarding claims 30 and 40, the above combination discloses the apparatus of claim 26, wherein the processing circuitry is further configured to: identify a registration request received from the data producer rApp; and cause to send a registration response to the data producer rApp, wherein the registration response is sent after a data management function performs a data catalog check to determine whether a same data type is found in another data producer rApp (According to lines 7-9 on page 20 of Cited Document 1, it is described that the rApp authorizes the generation of data of a specific data type, and the service provider applies a policy that two separate rApp instances do not generate the same data type within the same Non-RT RIC framework instance. The Non-RT RIC framework responds to the data registration of the producer rApp according to the policy that two separate rApp instances do not generate the same data type in the same Non-RT RIC framework instance). Regarding claims 31 and 41, the above combination discloses the apparatus of claim 26, wherein the processing circuitry is further configured to: identify a discover request received from the data consumer rApp; and cause to send a discover response to the data consumer rApp (According to "[REQ - nRTRfW - R1r-60]" and "[REQ - nRTRfW - R1r-70]" on page 22 of Cited Document 1, it is described that in response to the reception of the R1 data type request of the consumer rApp, the Non-RT RIC framework needs to set the consumption routing rule for that data type in the rApp even if no known data source is found, and that the Non-RT RIC framework needs to be able to communicate to the R1 consumer rApp whether or not the data consumption needs of the rApp are satisfied by the known data source, how to call the request from the consumer rAPP is an arbitrary matter). Regarding claims 32 and 42, the above combination discloses the apparatus of claim 26, wherein the processing circuitry is further configured to: check a discovery policy associated with a data type of a data registration request received from the data consumer rApp; and determine whether the data consumer rApp is allowed to discover the data type (According to lines 10-13 on page 20 of Cited Document 1, it is described that an rApp is authorized to consume data of a specific data type, a service provider may want to restrict the use of a specific data type, such as a data type related to confidential data, the number of rApp consumers existing for a specific data type is considered, and the license of an rApp that generates specific data may depend on the number of consumer instances of that data type. The restriction on the use of the data type based on the data type and the number of consumers of the data type is a policy for the data type. The Non-RT RIC framework determines whether the data consumption needs of rApp are satisfied by a known data source based on the data type and the number of data type consumers). Regarding claims 33 and 43, the above combination discloses the apparatus of claim 26, wherein the data catalog comprises one or more registered data types associated with one or more data producer rApps (cited document 1, since the Non-RT RIC framework does not need to understand the meaning and internal structure of data in order to provide R1 data registration and data subscription services, managing and determining data in a catalog when determining whether or not the data consumption needs of rApp are satisfied by a known data source and determining whether or not the requested data is already available locally.). Regarding claims 34 and 44, the above combination discloses the apparatus of claims 26, wherein the processing circuitry is further configured to create or update a discovery policy for registered data types using a service provided by a data policy administration service produced by data policy administration functions (According to lines 10-13 on page 20 of Cited Document 1, it is described that an rApp is authorized to consume data of a specific data type, a service provider may want to restrict the use of a specific data type, such as a data type related to confidential data, the number of rApp consumers that exist for a specific data type is considered, and the license of an rApp that generates specific data may depend on the number of consumer instances of that data type and updating a policy for approving consumption of a specific data type on the basis of a request of a service provider. The restriction on the use on the data side based on the data type and the number of consumers of the data type is a policy for the data type). Regarding claims 35, the above combination discloses the apparatus of claim 34, wherein the processing circuitry is further configured to: update the data catalog; and add the data type indicated in a registration request received from the data producer rApp into a list of known data types, based on the discovery policy (cited document 1, since the service provider applies a policy that two separate rApp instances do not generate the same data type in the same Non-RT RIC framework instance, it is clear that the registered data type is checked to determine whether the same data type can be found in another rApp. Managing data in a catalog would be used to check the registered data type and determine whether or not the same data type can be found in another rApp). Conclusion 07-40 AIA 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 JIRAPON TULOP whose telephone number is (571)270-7491. The examiner can normally be reached Monday to Friday, 10:00AM-6:00PM. 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, Ahmad Matar can be reached at 571-272-7488. 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. /JIRAPON TULOP/Examiner, Art Unit 2693 Application/Control Number: 18/553,552 Page 2 Art Unit: 2693 Application/Control Number: 18/553,552 Page 3 Art Unit: 2693 Application/Control Number: 18/553,552 Page 4 Art Unit: 2693 Application/Control Number: 18/553,552 Page 5 Art Unit: 2693 Application/Control Number: 18/553,552 Page 6 Art Unit: 2693 Application/Control Number: 18/553,552 Page 7 Art Unit: 2693
Prosecution Insights