DETAILED ACTION
The following is a final office action in response to applicant’s remarks/arguments 11/14/2025 for
response of the office action mailed on 7/14/2025. Claims 1, 8, and 15 have been amended. Claims 1-20 remain pending in the application.
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 .
Response to Amendment
The Amendment filed on 11/14/2025 has been entered.
Applicant’s amendments to the Claims have overcome each and every objection previously set forth in
the Non-Final Rejection mailed on 7/14/2025.
Response to Remarks/Arguments
Applicant’s remarks/arguments (page 8-11), filed on 11/14/2025, with respect to claim 1 have been
fully considered but are moot because the arguments are based on newly added limitations in the amendment and new ground of rejections using a newly introduced references (HAN) are applied in the current rejection.
Applicant’s remarks/arguments, see remarks on page 8, filed 11/14/2025, with respect to claims 15-20 have been fully considered and are persuasive. The rejection of 112 (b) has been withdrawn.
Claim Rejections - 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 claims at issue 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 §§ 706.02(l)(1)-706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being
unpatentable over claims 1-20 of Copending Application No. 18/030,565 (18/030,565, hereinafter “Copending Application”). Although the conflicting claims are not identical, they are not patentably distinct from each other because claims 1-20 of the instant application are broader in every aspect than the corresponding claims of Copending Application (18/030,565) and are therefore anticipated by claims 1-20 of Copending Application (18/030,565).
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims
have not in fact been patented.
Current Application No. 18/038,773
Co-pending Application No. 18/030,565
1. A method, performed by at least one processor, for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller Application (rApp) of an Open Radio Access Network (O-RAN), the method comprising:
receiving, by a radio access network (RAN) operation and maintenance {OAM)-related function of a Service Management and Orchestration (SMO) framework of the O-RAN, a read configuration request, wherein the read configuration request originates from the rApp, and
wherein the read configuration request indicates requested configuration data of a network element of the O-RAN;
determining, by the RAN OAM-related function, whether or not the read configuration request is valid; and
sending, by the RAN OAM-related function, a read configuration response to the rApp, in response to the read configuration request.
1. A method, performed by at least one processor, for managing configuration schema for an rApp, the method comprising:
receiving, by a Radio Access Network Operation and Maintenance (RAN OAM)-related
function, a get configuration schema request, wherein the get configuration schema request
originates from the rApp, and wherein the get configuration schema request is a request to
provide the rApp with a configuration schema of a network element, the configuration schema
being a schema of readable and/or writeable configuration parameters of the network
element;
determining, by the RAN OAM-related function, whether or not the get configuration schema request is valid; and
sending, by the RAN OAM-related function, a get configuration schema response to the rApp, in response to the get configuration schema request,
wherein the network element is one of a centralized unit (CU) and a distributed unit (DU) of an Open Radio Access Network (O-RAN),
wherein the get configuration schema request comprises an identifier (ID) of the rApp and information about the one of the CU and the DU, and
wherein determining whether or not the get configuration schema request is valid comprises determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema.
2. The method as claimed in claim 1, wherein the read configuration response comprises the requested configuration data.
2. The method as claimed in claim 1, wherein the get configuration schema response comprises the requested configuration schema.
3. The method as claimed in claim 2, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria.
3. The method as claimed in claim 2, wherein the get configuration schema request further comprises a query criteria.
4. The method as claimed in claim 3, wherein the read configuration request further comprises information about managed entities of a service producer.
4. canceled
5. The method as claimed in claim 3, wherein determining whether or not the read configuration request is valid comprises:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
5. The method as claimed in claim 3, wherein:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema comprises determining, by checking the ID of the rApp, whether the rApp
is included in an authorized rApps list of rApps authorized to request configuration schemas of
DUs and CUs.
6. The method as claimed in claim 5, wherein determining whether or not the read configuration request is valid comprises:
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria.
6. The method as claimed in claim 3, wherein determining whether or not the get configuration schema request is valid further comprises:
based on a determination that the rApp is authorized to request the configuration schema,
determining, by the RAN OAM-related function, whether the get configuration schema request is
valid based on the query criteria.
7. The method as claimed in claim 1, wherein the read configuration response indicates whether or not the read configuration request was successful, or failed.
7. The method as claimed in claim 1, wherein the get configuration schema response indicates whether or not the get configuration schema request was successful, or failed.
8. An apparatus for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller Application (rApp) of an Open Radio Access Network (O-RAN), the apparatus comprising:
at least one memory storing computer-executable instructions; and
at least one processor configured to execute the computer-executable instructions to:
receive, by a radio access network (RAN} operation and maintenance (OAM)-related function, a read configuration request, wherein the read configuration request originates from the rApp, and wherein the read configuration request indicates requested configuration data of a network element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU):
determine, by the RAN OAM-related function, whether or not the read configuration request is valid; and
send, by the RAN OAM-related function, a read configuration response to the rApp, in response to the read configuration request.
8. An apparatus for managing configuration schema for an rApp, the apparatus comprising:
at least one memory storing computer-executable instructions; and
at least one processor configured to execute the computer-executable instructions to:
receive, by a Radio Access Network Operation and Maintenance (RAN OAM)-related function, a get configuration schema request, wherein the get configuration schema request originates from the rApp, and wherein the get configuration schema request is a request to provide the rApp with a configuration schema of a network element, the configuration schema being a schema of readable and/or writeable configuration parameters of the network element;
determine, by the RAN OAM-related function, whether or not the get configuration schema request is valid; and
send, by the RAN OAM-related function, a get configuration schema response to the rApp, in response to the get configuration schema request.
wherein the network element is one of a centralized unit (CU) and a distributed unit (DU) of an Open Radio Access Network (O-RAN).
wherein the get configuration schema request comprises an identifier (ID) of the rApp and information about the one of the CU and the DU, and wherein the at least one processor is further configured to execute the computer executable
instructions to determine whether or not the get configuration schema request is valid by determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema.
9. The apparatus as claimed in claim 8, wherein the read configuration response comprises the requested configuration data.
9. The apparatus as claimed in claim 8, wherein the get configuration schema response comprises the requested configuration schema.
10. The apparatus as claimed in claim 9, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria.
10. The apparatus as claimed in claim 9, wherein the get configuration schema request further comprises a query criteria.
11. The apparatus as claimed in claim 10, wherein the read configuration request further comprises information about managed entities of a service producer.
11. canceled
12. The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
12. The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema by determining, by checking the ID of the rApp, whether the rApp is
included in an authorized rApps list.
13. The apparatus as claimed in claim 12, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by:
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria.
13. The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the get configuration schema request is valid by:
based on a determination that the rApp is authorized to request the configuration schema, determining, by the RAN OAM-related function, whether the get configuration schema request is valid based on the query criteria.
14. The apparatus as claimed in claim 8, wherein the read configuration response indicates whether or not the read configuration request was successful, or failed.
14. The apparatus as claimed in claim 8, wherein the get configuration schema response indicates whether or not the get configuration schema request was successful, or failed.
15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to cause the at least one processor to perform a method comprising:
receiving, by a radio access network (RAN) operation and maintenance (OAM)-related function of an Open Radio Access Network (O-RAN), a read configuration request, wherein the read configuration request originates from a Non-Real-Time Radio Access Network Intelligent
Controller Application (rApp), and wherein the read configuration request indicates requested configuration data of a network element of the O-RAN, the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU);
determining, by the RAN OAM-related function, whether or not the read configuration request is valid; and
sending, by the RAN OAM-related function, a read configuration response to the rApp, in response to the read configuration request.
15. A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to cause the at least one processor to perform a method comprising:
receiving, by a Radio Access Network Operation and Maintenance (RAN OAM)-related function, a get configuration schema request, wherein the get configuration schema request originates from an rApp, and wherein the get configuration schema request is a request to provide the rApp with a configuration schema of a network element, the configuration schema being a schema of readable and/or writeable configuration parameters of the network element;
determining, by the RAN OAM-related function, whether or not the get configuration schema request is valid; and
sending, by the RAN OAM-related function, a get configuration schema response to the rApp, in response to the get configuration schema request.
wherein the network element is one of a centralized unit (CU) and a distributed unit (DU) of an Open Radio Access Network (O-RAN).
wherein the get configuration schema request comprises an identifier (ID) of the rApp and information about the one of the CU and the DU, and
wherein determining whether or not the get configuration schema request is valid comprises determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema.
16. The non-transitory computer-readable recording medium as claimed in claim 15, wherein the read configuration response comprises the requested configuration data.
16. The non-transitory computer-readable recording medium as claimed in claim 15, wherein the get configuration schema response comprises the requested configuration schema.
17. The non-transitory computer-readable recording medium as claimed in claim 16, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria.
17. The non-transitory computer-readable recording medium as claimed in claim 16, wherein the get configuration schema request further comprises a query criteria.
18. The non-transitory computer-readable recording medium as claimed in claim 17, wherein the read configuration request further comprises information about managed entities of a service producer.
18. canceled
19. The non-transitory computer-readable recording medium as claimed in claim 17, wherein determining whether or not the read configuration request is valid comprises:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
19. The non-transitory computer-readable recording medium as claimed in claim 17, wherein
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration schema comprises determining, by checking the ID of the rApp, whether the rApp
is included in an authorized rApps list.
20. The non-transitory computer-readable recording medium as claimed in claim 19, wherein determining whether or not the read configuration request is valid comprises:
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria.
20. The non-transitory computer-readable recording medium as claimed in claim 17, wherein determining whether or not the get configuration schema request is valid further comprises:
based on a determination that the rApp is authorized to request the configuration schema, determining, by the RAN OAM-related function, whether the get configuration schema request is valid based on the query criteria.
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 onobviousness.
Claims 1-4, 7-11, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Dent et al.
(US 2023/0388844 A1, hereinafter “Dent”) in view of HAN (WO 2022/060923 A1, hereinafter “Han”) and in further view of Radulescu et al. (US 2012/0106370 Al, hereinafter “Radulescu”).
.
Regarding claim 1, Dent discloses:
A method, performed by at least one processor, for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller Application (rApp) of an Open Radio Access Network (O-RAN), the method comprising (the rApp can provide this data directly to other 0-RAN components. method for modifying settings of a legacy radio access network (RAN) by anapplication executing on a 5G RAN intelligent controller (MC) framework (e.g., a non-real-time (non-RT) RIC). The processing unit(s) may be a single processor. 5G network elements via Distributed Unit (O-DU) and/or Centralized Unit (O-CU) elements of the 5G Open RAN (O-RAN), Dent: [0009], [0020], [0050]):
receiving, bone of the rApps sends a command to read configuration setting data from the legacy RAN. these data types allow the rApps to read configuration setting data from the legacy RAN and modify these configuration settings, Dent: [0029]-[0030], [0046]);
determining, commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]); and
sending, the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., therApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Dent does not explicitly disclose:
by a radio access network (RAN) operation and maintenance (OAM)-related function of a Service Management and Orchestration (SMO) framework of the O-RAN,
However, in the same field of endeavor, Han teaches:
The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 212 is a logical function within the SMO framework 102, 202 that enables non-realtime control and optimization of RAN elements and resources. receiving the model structure and training configurations from rApp 301 in the data 507 and collecting training 25 data from RAN, Han: [0033], [0061]),
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 modify Dent in view of Han in order to further modify a Service Management and Orchestration (SMO) framework of the O-RAN from the teachings of Han.
One of ordinary skill in the art would have been motivated because further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems (Han: [0005]).
Yet, Dent in view of Han does not explicitly disclose:
by a RAN OAM-related function,
However, in the same field of endeavor, Radulescu teaches:
by a RAN OAM-related function (the OAM may query its RAN nodes according to the configuration messages detailed on the RAN function above. For example, the OAM may (transparently or not to intermediary nodes) pass on configuration requests it received from RAN, targeted to another RAN, or the OAM may pass such information directly to the RAN, via peer OAM, or via the Global OAM, Radulescu: [0108]-[0111]),
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 modify Dent in view of Radulescu in order to further modify the method of receiving, determining, and sending the read configuration request and response from the teachings of Radulescu.
One of ordinary skill in the art would have been motivated because the neighbor relation information is sent to a destination network entity via another network entity (e.g., an OAM or core network entity) (Radulescu: [0045]).
Regarding claim 2, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Dent further discloses:
The method as claimed in claim 1, wherein the read configuration response comprises the requested configuration data (the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0044]-[0046]).
Regarding claim 3, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 2 above.
Dent further discloses:
The method as claimed in claim 2, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria (DME service then identifies the translation application as the producing rApp for the job and sends the job to the translation application. Once the translation application has performed its translation and received confirmation of the completion of the command, the translation application directly notifies the consuming rApp through the R1 interface, Dent: [0030]).
Regarding claim 4, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 3 above.
Dent further discloses:
The method as claimed in claim 3, wherein the read configuration request further comprises information about managed entities of a service producer (rApp can evaluate when certain cell sites (both NR and LTE cell sites) should be powered off to save energy. rApp uses machine learning to analyze historical cell site usage data to determine when a particular cell site will not be needed for a long enough period that it is useful to power off the cite. The translation module translates the network element (cell site) identifiers, configuration parameter identifiers, and the values into the correct scheme used by the EMS. to power cell sites on or off, one EMS might require a call to change the administrative state to locked (from unlocked) while another EMS instead requires a call to change a power setting to off, Dent: [0039], [0041]-[0042]).
Regarding claim 7, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Dent further discloses:
The method as claimed in claim 1, wherein the read configuration response indicates whether or not the read configuration request was successful, or failed (the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., the rApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Regarding claim 8, Dent discloses:
An apparatus for managing configuration data for a Non-Real-Time Radio Access Network Intelligent Controller Application (rApp) of an Open Radio Access Network (O-RAN), the apparatus comprising (In some embodiments, an rApp will change the set of NR anchor cell sites for one or more LTE cell sites (based on analysis of network topology. Applications may modify settings of 5G network elements via Distributed Unit (O-DU) and/or Centralized Unit (O-CU) elements of the 5G Open RAN (O-RAN), Dent: [0008], [0020]):
at least one memory storing computer-executable instructions (Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer readable media. Electronic system includes a bus, processing unit(s), a system memory, a read-only memory. the processing unit(s) retrieve instructions to execute and data to process, Dent: Fig.7, [0048]-[0050], [0055]); and
at least one processor configured to execute the computer-executable instructions to (Electronic system includes a bus, processing unit(s), a system memory, a read-only memory. the processing unit(s) retrieve instructions to execute and data to process. The processing unit(s) may be a single processor or a multi-core processor, Dent: Fig.7, [0048]-[0050], [0055]):
receive, one of the rApps sends a command to read configuration setting data from the legacy RAN. these data types allow the rApps to read configuration setting data from the legacy RAN and modify these configuration settings, Dent: [0029]-[0030], [0046]),
determine, commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]); and
send, the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., therApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Dent does not explicitly disclose:
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU);
However, in the same field of endeavor, Han teaches:
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) (The O-Cloud 206 is a cloud computing platfonn including a collection of physical infrastmcture nodes to host the relevant O-RAN functions. The radio portion/side of the logical architecture 200 includes the near-RT 15 RIC 214, the O-DU 215, the O-RAN Radio Unit (O-RU) 216, the O-CU-CP 221, and the O-CU-UP 222 functions, Han: [0021]-[0022]);
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 modify Dent in view of Han in order to further modify the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) from the teachings of Han.
One of ordinary skill in the art would have been motivated because further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems (Han: [0005]).
Yet, Dent in view of Han does not explicitly disclose:
by a RAN OAM-related function,
However, in the same field of endeavor, Radulescu teaches:
by a RAN OAM-related function (the OAM may query its RAN nodes according to the configuration messages detailed on the RAN function above. For example, the OAM may (transparently or not to intermediary nodes) pass on configuration requests it received from RAN, targeted to another RAN, or the OAM may pass such information directly to the RAN, via peer OAM, or via the Global OAM, Radulescu: [0108]-[0111]),
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 modify Dent in view of Radulescu in order to further modify the method of receiving, determining, and sending the read configuration request and response from the teachings of Radulescu.
One of ordinary skill in the art would have been motivated because the neighbor relation information is sent to a destination network entity via another network entity (e.g., an OAM or core network entity) (Radulescu: [0045]).
Regarding claim 9, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 8 above.
Dent further discloses:
The apparatus as claimed in claim 8, wherein the read configuration response comprises the requested configuration data (the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0044]-[0046]).
Regarding claim 10, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 8 above.
Dent further discloses:
The apparatus as claimed in claim 9, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria (DME service then identifies the translation application as the producing rApp for the job and sends the job to the translation application. Once the translation application has performed its translation and received confirmation of the completion of the command, the translation application directly notifies the consuming rApp through the R1 interface, Dent: [0030]).
Regarding claim 11, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 10 above.
Dent further discloses:
The apparatus as claimed in claim 10, wherein the read configuration request further comprises information about managed entities of a service producer (rApp can evaluate when certain cell sites (both NR and LTE cell sites) should be powered off to save energy. rApp uses machine learning to analyze historical cell site usage data to determine when a particular cell site will not be needed for a long enough period that it is useful to power off the cite. The translation module translates the network element (cell site) identifiers, configuration parameter identifiers, and the values into the correct scheme used by the EMS. to power cell sites on or off, one EMS might require a call to change the administrative state to locked (from unlocked) while another EMS instead requires a call to change a power setting to off, Dent: [0039], [0041]-[0042]).
Regarding claim 14, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 8 above.
Dent further discloses:
The apparatus as claimed in claim 8, wherein the read configuration response indicates whether or not the read configuration request was successful, or failed (the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., the rApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Regarding claim 15, Dent discloses:
A non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor to cause the at least one processor to perform a method comprising (Some embodiments include electronic components, such as microprocessors. storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media), Dent: [0055]):
receiving, one of the rApps sends a command to read configuration setting data from the legacy RAN. these data types allow the rApps to read configuration setting data from the legacy RAN and modify these configuration settings, Dent: [0029]-[0030], [0046]);
determining, commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]); and
sending, the process provides a corresponding notification regarding the success or failure of the specified operations to the originating application (i.e., therApp). the response provided to the rApp upon receiving a response from the EMS, Dent: [0044]-[0046]).
Dent does not explicitly disclose:
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU);
However, in the same field of endeavor, Han teaches:
the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) (The O-Cloud 206 is a cloud computing platfonn including a collection of physical infrastmcture nodes to host the relevant O-RAN functions. The radio portion/side of the logical architecture 200 includes the near-RT 15 RIC 214, the O-DU 215, the O-RAN Radio Unit (O-RU) 216, the O-CU-CP 221, and the O-CU-UP 222 functions, Han: [0021]-[0022]);
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 modify Dent in view of Han in order to further modify the network element being an O-RAN centralized unit (O-CU) or an O-RAN distributed unit (O-DU) from the teachings of Han.
One of ordinary skill in the art would have been motivated because further enhanced operation of LTE and NR systems in the licensed, as well as unlicensed spectrum, is expected in future releases and 5G systems such as O-RAN systems (Han: [0005]).
Yet, Dent in view of Han does not explicitly disclose:
by a RAN OAM-related function,
However, in the same field of endeavor, Radulescu teaches:
by a RAN OAM-related function (the OAM may query its RAN nodes according to the configuration messages detailed on the RAN function above. For example, the OAM may (transparently or not to intermediary nodes) pass on configuration requests it received from RAN, targeted to another RAN, or the OAM may pass such information directly to the RAN, via peer OAM, or via the Global OAM, Radulescu: [0108]-[0111]),
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 modify Dent in view of Radulescu in order to further modify the method of receiving, determining, and sending the read configuration request and response from the teachings of Radulescu.
One of ordinary skill in the art would have been motivated because the neighbor relation information is sent to a destination network entity via another network entity (e.g., an OAM or core network entity) (Radulescu: [0045]).
Regarding claim 16, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 15 above.
Dent further discloses:
The non-transitory computer-readable recording medium as claimed in claim 15, wherein the read configuration response comprises the requested configuration data (the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0044]-[0046]).
Regarding claim 17, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 16 above.
Dent further discloses:
The non-transitory computer-readable recording medium as claimed in claim 16, wherein the read configuration request comprises an identifier (ID) of the rApp, and a query criteria (DME service then identifies the translation application as the producing rApp for the job and sends the job to the translation application. Once the translation application has performed its translation and received confirmation of the completion of the command, the translation application directly notifies the consuming rApp through the R1 interface, Dent: [0030]).
Regarding claim 18, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 17 above.
Dent further discloses:
The non-transitory computer-readable recording medium as claimed in claim 17, wherein the read configuration request further comprises information about managed entities of a service producer (rApp can evaluate when certain cell sites (both NR and LTE cell sites) should be powered off to save energy. rApp uses machine learning to analyze historical cell site usage data to determine when a particular cell site will not be needed for a long enough period that it is useful to power off the cite. The translation module translates the network element (cell site) identifiers, configuration parameter identifiers, and the values into the correct scheme used by the EMS. to power cell sites on or off, one EMS might require a call to change the administrative state to locked (from unlocked) while another EMS instead requires a call to change a power setting to off, Dent: [0039], [0041]-[0042]).
Claims 5-6, 12-13, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dent-Han-Radulescu and in further view of Subramani Jayavelu et al. (US 2023/0069604 Al, hereinafter “Subramani”).
Regarding claim 5, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 3 above.
Dent further discloses:
The method as claimed in claim 3, wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
Dent-Han-Radulescu does not explicitly disclose:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
However, in the same field of endeavor, Subramani teaches:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data (In order to run a secure and hardened applications (e.g., xApps or rApps) on dRIC platform, some embodiments enforce the following policies on the applications: (1) network/security policies, (2) POD security policies, (3) limiting resource usages on a cluster, (4) controlling privileges to run, (5) K8s API Authorization (e.g., what resources can be created/deleted/updated),Subramani: [0243] ).
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 modify Dent-Han-Radulescu in view of Subramani in order to further modify determining whether the rApp is authorized to request the configuration data from the teachings of Subramani.
One of ordinary skill in the art would have been motivated because it provides services (such as metric collection, policy provisioning and configuration) to other RIC components (Subramani: [0004]).
Regarding claim 6, Dent-Han-Radulescu-Subramani teaches all the claimed limitations as set forth in the rejection of claim 5 above.
Dent further discloses:
The method as claimed in claim 5, wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria (commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]).
Regarding claim 12, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 10 above.
Dent further discloses:
The apparatus as claimed in claim 10, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
Dent-Han-Radulescu does not explicitly disclose:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
However, in the same field of endeavor, Subramani teaches:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data (In order to run a secure and hardened applications (e.g., xApps or rApps) on dRIC platform, some embodiments enforce the following policies on the applications: (1) network/security policies, (2) POD security policies, (3) limiting resource usages on a cluster, (4) controlling privileges to run, (5) K8s API Authorization (e.g., what resources can be created/deleted/updated),Subramani: [0243] ).
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 modify Dent-Han-Radulescu in view of Subramani in order to further modify determining whether the rApp is authorized to request the configuration data from the teachings of Subramani.
One of ordinary skill in the art would have been motivated because it provides services (such as metric collection, policy provisioning and configuration) to other RIC components (Subramani: [0004]).
Regarding claim 13, Dent-Han-Radulescu-Subramani teaches all the claimed limitations as set forth in the rejection of claim 12 above.
Dent further discloses:
The apparatus as claimed in claim 12, wherein the at least one processor is further configured to execute the computer-executable instructions to determine whether or not the read configuration request is valid by (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria (commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]).
Regarding claim 19, Dent-Han-Radulescu teaches all the claimed limitations as set forth in the rejection of claim 17 above.
Dent further discloses:
The non-transitory computer-readable recording medium as claimed in claim 17, wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
Dent-Han-Radulescu does not explicitly disclose:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data.
However, in the same field of endeavor, Subramani teaches:
determining, by the RAN OAM-related function, whether the rApp is authorized to request the configuration data (In order to run a secure and hardened applications (e.g., xApps or rApps) on dRIC platform, some embodiments enforce the following policies on the applications: (1) network/security policies, (2) POD security policies, (3) limiting resource usages on a cluster, (4) controlling privileges to run, (5) K8s API Authorization (e.g., what resources can be created/deleted/updated),Subramani: [0243] ).
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 modify Dent-Han-Radulescu in view of Subramani in order to further modify determining whether the rApp is authorized to request the configuration data from the teachings of Subramani.
One of ordinary skill in the art would have been motivated because it provides services (such as metric collection, policy provisioning and configuration) to other RIC components (Subramani: [0004]).
Regarding claim 20, Dent-Han-Radulescu-Subramani teaches all the claimed limitations as set forth in the rejection of claim 19 above.
Dent further discloses:
The non-transitory computer-readable recording medium as claimed in claim 19, wherein determining whether or not the read configuration request is valid comprises (this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]):
based on a determination that the rApp is authorized to request the configuration data, determining, by the RAN OAM-related function, whether the read configuration request is valid based on the query criteria (commands from the other rApps include one or more globally unique cell identifiers that specify cell sites for which the configuration settings are to be modified (or simply requested, for a read command). this notification (received through the EMS API) indicates whether the modifications were successfully committed to the RAN configuration or whether some or all of the modifications could not be made. the response provided to the rApp upon receiving a response from the EMS is a tuple with the unique LTE cell ID, parameter, and returned values, Dent: [0034], [0044]-[0046]).
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 extension fee 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.
In the case of amendments, applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and support, for ascertaining the metes and bounds of the claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SANG C LEE whose telephone number is (703)756-1461. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM EST.
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, HASSAN PHILLIPS can be reached on (571)272-3940. 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.
/S.C.L./Examiner, Art Unit 2467
/MICHAEL J MOORE JR/Primary Examiner, Art Unit 2467