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 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.
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.
Claim(s) 1-15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gudipati (US 2022/0286914) and further in view of Xu (US 2023/0359515).
Regarding claim 1, Gudipati teaches: An apparatus configured for wireless communications, comprising: one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the apparatus to:
communicate, with a network entity, via a first type of application programming interface (API) at the network entity, to register the apparatus with the network entity (¶ 74, “Registration APIs are used by the applications 1220 (e.g., xApps) to introduce themselves to other applications 1220 by providing their network identifiers (e.g., their network address and available L4 ports) and providing their functionality (e.g., performing channel prediction)”); and
exchange one or more metrics with one or more peer apparatuses associated with the network entity (¶ 42, “some embodiments expose report interfaces for the DU and/or the CU to provide various metrics to the user level tracing operations”) based on at least one of:
a first communication with the one or more peer apparatuses via at least one of a second type of API or a third type of API exposed at the apparatus (¶ 73, “Enablement APIs are the APIs that are used in some embodiments to allow the control plane applications 1220 to communicate with each other” and “The enablement APIs in some embodiments include registration APIs, service discovery APIs as well as inter-app communication APIs”);
a second communication with the one or more peer apparatuses via at least one of the second type of API or the third type of API at each of the one or more peer apparatuses (¶ 74, “The inter-app communication APIs allow the control plane applications to communicate with each other to pass along data and/or request certain operations” and ¶ 9, “the first and second control plane applications are developed by two different application developers that use a common set of RIC APIs to communicate with each other through the distributed RIC”);
a third communication with the network entity via the second type of API at the network entity (¶ 9, “the first RIC add one or more parameters to the API calls as it forwards the API calls from the first control application to the second control application” and ¶ 70, “the distributed near RT RIC platform 1200 in some embodiments uses the E2, O1, and A1 interfaces specified by the O-RAN standard specifying body. It uses the E2 APIs to communicate with the E2 O-RAN nodes, such as the O-CU-CPs 1202, O-CU-UPs 1204, and O-DUs 1206”); or
a fourth communication with the network entity via the third type of API exposed at the apparatus (¶ 71, “the RIC SDKs 1215 provide high-level counterpart APIs for the control plane applications 1220 that use the RIC SDKs and the distributed near RT RIC platform to communicate with the E2 nodes 1202-1206, the non-real-time RIC platform 1208 and the SMO 1210. FIG. 12 designates these high-level counterpart APIs for the E2, O1, and A1 interfaces with a prime sign as the E2′ API calls, O1′ API calls and A1′ API calls”).
Gudipati does not teach as clearly as Xu teaches: exchange one or more metrics with one or more peer apparatuses associated with the network entity (¶ 269, “Information from the provisioned API invoker profile which may include information to allow the API invoker to be authenticated and to obtain authorization for service APIs Service API information O (see NOTE 2) The service API information includes the service API name, service API type, communication type, description, Serving Area Information (optional), AEF location (optional), interface details (e.g. IP address, port number, URI), protocols, version numbers, and data format. Reason O(see NOTE 3)”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of exchange one or more metrics with one or more peer apparatuses associated with the network entity, as taught by Xu, in the same way to network entity registration, as taught by Gudipati. Both inventions are in the field of API based network element registrations, and combining them would have predictably resulted in a method to “offer candidate AEFs which are topologically close to the API invoke,” as indicated by Xu (¶ 6).
Regarding claim 2, Xu teaches: The apparatus of claim 1, wherein the one or more processors are configured to cause the apparatus to: send, to the network entity, via the second type of API at the network entity or a fourth type of API, a request to communicate the one or more metrics directly with the one or more peer apparatuses (¶ 21, “The method comprises receiving a first service application programming interface (API) discover request from a first network function;” and ¶ 122, “The first service API discover response may comprise a list of service API information for which the API invoker has the required authorization,” the list of service API information corresponds to the one or more metrics); and receive a message comprising location information for each of the one or more peer apparatuses (¶ 21, “The first service API discover response comprises location information of at least one API exposing function providing the discovered service API”).
Regarding claim 3, Xu teaches: The apparatus of claim 2, wherein the location information for each of the one or more peer apparatuses comprises a fully qualified domain name (FQDN) or an internet protocol (IP) address (¶ 271, “The service API information includes the service API name, service API type, communication type, description, Serving Area Information (optional), AEF location (optional), interface details (e.g. IP address, port number, URI), protocols, version numbers, and data format”).
Regarding claim 4, Xu teaches: The apparatus of claim 1, wherein the one or more processors are configured to cause the apparatus to send, to the network entity, via the second type of API at the network entity or a fourth type of API (¶ 185, “At step 1801, the API publishing function (APF) sends a service API publish request to the CAPIF core function, with the details of the service API”), a message comprising location information for each of the one or more peer apparatuses (¶ 185, “The service API publish request may include location information of at least one API exposing function (AEF)”).
Regarding claim 5, Xu teaches: The apparatus of claim 2, wherein the one or more processors are configured to cause the apparatus to receive, from the network entity, via the third type of API at the apparatus or a fourth type of API, a message comprising location information for each of the one or more peer apparatuses (¶ 9, “The first service API discover response comprises location information of at least one API exposing function providing the discovered service API”).
Regarding claim 6, Gudipati teaches: The apparatus of claim 1, wherein to exchange the one or more metrics based on the first communication with the one or more peer apparatuses via at least one of the second type of API or the third type of API exposed at the apparatus, the one or more processors are configured to cause the apparatus to: receive, directly from a first peer apparatus of the one or more peer apparatuses (¶ 73, “these APIs allow the RIC SDKs of the control plane applications to directly communicate with each other without traversing through any other components of the distributed near RT RIC”), via the second type of API or the third type of API, a request for at least one metric of the one or more metrics (¶ 74, “The inter-app communication APIs allow the control plane applications to communicate with each other to pass along data and/or request certain operations”); and send, directly to the first peer apparatus, the at least one metric in a return message to the request (¶ 65, “passes responses to these API calls from the second CP application 820 to the first CP application 815” and ¶ 53, “The output metrics for this use-case, in some embodiments, include the predicted channel condition of the user for the next scheduling window, as well as predicted downlink and uplink SINR, a precoding matrix (e.g., if applicable), and SU-MIMO layers”).
Regarding claim 7, Gudipati teaches: The apparatus of claim 6, wherein the at least one metric comprises: information associated with the apparatus; or information associated with at least one peer apparatus associated with the first peer apparatus (¶ 51, “the input metrics include at least a channel report from the UE, such as Wideband or Subband CQI/PMERI for DL, or SRS for UL, according to some embodiments. The input metrics of some embodiments can also opt to include supportive information such as UE distance, UE positioning, etc”).
Regarding claim 8, Gudipati teaches: The apparatus of claim 1, wherein to exchange the one or more metrics based on the first communication with the one or more peer apparatuses via at least one of the second type of API or the third type of API exposed at the apparatus, the one or more processors are configured to cause the apparatus to: receive, directly from a first peer apparatus of the one or more peer apparatuses (¶ 73, “these APIs allow the RIC SDKs of the control plane applications to directly communicate with each other without traversing through any other components of the distributed near RT RIC”), via the second type of API or the third type of API, at least one metric of the one or more metrics (¶ 74, “The inter-app communication APIs allow the control plane applications to communicate with each other to pass along data and/or request certain operations”).
Regarding claim 9, Gudipati teaches: The apparatus of claim 1, wherein to exchange the one or more metrics based on the second communication with the one or more peer apparatuses via at least one of the second type of API or the third type of API at each of the one or more peer apparatuses, the one or more processors are configured to cause the apparatus to: send, directly to a first peer apparatus of the one or more peer apparatuses, via the second type of API or the third type of API at the first peer apparatus, a request for at least one metric of the one or more metrics (¶ 69, “the RIC 1100 also passes API calls from the second CP application 1120 to the first CP application 1115, and responses from the first CP application 1115 to the second CP application 1120”); and receive, directly from the first peer apparatus, the at least one metric in a return message to the request (¶ 67, “responses to these API calls from the first CP application 915 to the second CP application 920 are forwarded through the first RIC SDK 902, the first RIC 900, the second RIC 901 and the second RIC SDK 904”).
Regarding claim 10, Gudipati teaches: The apparatus of claim 1, wherein to exchange the one or more metrics based on the second communication with the one or more peer apparatuses via at least one of the second type of API or the third type of API at each of the one or more peer apparatuses, the one or more processors are configured to cause the apparatus to: send, directly to a first peer apparatus of the one or more peer apparatuses, via the second type of API or the third type of API at the first peer apparatus, at least one metric of the one or more metrics (¶ 74, “The inter-app communication APIs allow the control plane applications to communicate with each other to pass along data and/or request certain operations”).
Regarding claim 11, Gudipati teaches: The apparatus of claim 1, wherein: the one or more metrics comprise information associated with the apparatus (¶ 51, “the input metrics include at least a channel report from the UE, such as Wideband or Subband CQI/PMERI for DL, or SRS for UL, according to some embodiments”); and to exchange the one or more metrics based on the third communication with the network entity via the second type of API at the network entity (¶ 70, “uses the E2 APIs to communicate with the E2 O-RAN nodes, such as the O-CU-CPs 1202, O-CU-UPs 1204, and O-DUs 1206”), the one or more processors are configured to cause the apparatus to send, to the network entity, via the second type of API, the one or more metrics (¶ 46, “Each of the apps, in some embodiments, is representative of the various functions of the RIC that use data sent from the E2 nodes 520”).
Regarding claim 12, Gudipati teaches: The apparatus of claim 1, wherein: the one or more metrics comprise information associated with at least one of the one or more peer apparatuses associated with the apparatus (¶ 42, “provide various metrics to the user level tracing operations. These metrics can include selected RRC messages, MAC/RLC/PDCP traffic volume and performance, RF condition, and RF resource consumption”); and to exchange the one or more metrics based on the third communication with the network entity via the second type of API at the network entity (¶ 70, “uses the E2 APIs to communicate with the E2 O-RAN nodes, such as the O-CU-CPs 1202, O-CU-UPs 1204, and O-DUs 1206”), the one or more processors are configured to cause the apparatus to: send, to the network entity, via the second type of API, a request for the one or more metrics (¶ 78, “the RIC SDK 1300 includes a query manager 132 that processes SDL requests from the CP application 1310”); and receive, from the network entity, the one or more metrics in a return message to the request (¶ 65, “the RIC 800 receives API calls from the CP application 815 and forwards the API calls to the CP application 820, and passes responses to these API calls from the second CP application 820 to the first CP application 815”).
Regarding claim 13, Gudipati teaches: The apparatus of claim 1, wherein: the one or more metrics comprise information associated with the apparatus (¶ 51, “The input metrics of some embodiments can also opt to include supportive information such as UE distance, UE positioning, etc”); and to exchange the one or more metrics based on the fourth communication with the network entity via the third type of API exposed at the apparatus (¶ 70, “the distributed near RT RIC platform 1200 in some embodiments uses the E2, O1, and A1 interfaces specified by the O-RAN standard specifying body. It uses the E2 APIs to communicate with the E2 O-RAN nodes, such as the O-CU-CPs 1202, O-CU-UPs 1204, and O-DUs 1206”), the one or more processors are configured to cause the apparatus to: receive, from the network entity, via the third type of API, a request for the one or more metrics (¶ 65, “the RIC 800 receives API calls from the CP application 815 and forwards the API calls to the CP application 820”); and send, to the network entity the one or more metrics in a return message to the request (¶ 65, “passes responses to these API calls from the second CP application 820 to the first CP application 815. It also passes API calls from the second CP application 820 to the first CP application 815, and responses from the first CP application 815 to the second CP application 820”).
Regarding claim 14, Gudipati teaches: The apparatus of claim 1, wherein: the one or more metrics comprise information associated with at least one of the one or more peer apparatuses associated with the apparatus (¶ 51, “the input metrics include at least a channel report from the UE, such as Wideband or Subband CQI/PMERI for DL, or SRS for UL, according to some embodiments. The input metrics of some embodiments can also opt to include supportive information such as UE distance, UE positioning, etc”); and to exchange the one or more metrics based on the fourth communication with the network entity via the third type of API exposed at the apparatus (¶ 71, “For each of these E2, A1, and O1 APIs, the RIC SDKs 1215 provide high-level counterpart APIs for the control plane applications 1220 that use the RIC SDKs and the distributed near RT RIC platform to communicate with the E2 nodes 1202-1206”), the one or more processors are configured to cause the apparatus to receive, from the network entity, via the third type of API, the one or more metrics (¶ 65, “passes responses to these API calls from the second CP application 820 to the first CP application 815. It also passes API calls from the second CP application 820 to the first CP application 815, and responses from the first CP application 815 to the second CP application 820”).
Regarding claim 15, Gudipati and Xu teach: The apparatus of claim 1, wherein to communicate, with the network entity, to register the apparatus with the network entity, the one or more processors are configured to cause the apparatus to provide the network entity with an identifier associated with the apparatus (Gudipati, ¶ 74, “Registration APIs are used by the applications 1220 (e.g., xApps) to introduce themselves to other applications 1220 by providing their network identifiers (e.g., their network address and available L4 ports) and providing their functionality (e.g., performing channel prediction)”) comprising at least one of: a fully qualified domain name (FQDN); an internet protocol (IP) address; a geolocation; an identification (ID) number; or a cell ID (Xu, ¶ 270, “The information of the API publisher may include . . . AEF location (optional), interface details (e.g. IP address, port number, URI)”).
Regarding claim 17, Xu teaches: The apparatus of claim 1, wherein the one or more peer apparatuses comprise peer apparatuses associated with the network entity that are neighbors of the apparatus based on a location of each of the one or more peer apparatuses (¶ 18, “The location information of at least one target API exposing function is used to discover at least one first service API and at least one API exposing function providing the discovered at least one first service API is geographically or topologically close to the location information of at least one target API exposing function”).
Regarding claim 18, Gudipati and Xu teach: The apparatus of claim 1, wherein the one or more metrics comprise at least one of: a cell resource; an air-interface resource; a cell load; a peer apparatus load; an amplifier load; a measurement on a physical channel; a signal strength value; an interference value; a configuration; a timing advance value; a timestamp; a paging indication; or user equipment (UE)-specific information (¶ 51, “the input metrics include at least a channel report from the UE, such as Wideband or Subband CQI/PMERI for DL, or SRS for UL, according to some embodiments. The input metrics of some embodiments can also opt to include supportive information such as UE distance, UE positioning, etc”).
Claims 19 and 20 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gudipati and Xu, as applied above, and further in view of Aggarwal (US 2024/0056434).
Regarding claim 16, Gudipati and Xu do not teach; however, Aggarwal discloses: the one or more processors are configured to cause the apparatus to receive a token based on a successful registration of the apparatus with the network entity (¶ 12, “receive a FL service request including an analytics ID, FL model parameters, and an access token from a FL server in a visiting public land mobile network (VPLMN)” and ¶ 52, “The NRF 204 also authorizes the received access tokens for each NWDAF that is a potential FL client”), to exchange the one or more metrics based on the third communication with the network entity via the second type of API at the network entity (¶ 38, “Each NF service exposes its functionality through a Service Based Interface (SBI)”), the one or more processors are configured to cause the apparatus to send, to the network entity, via the second type of API, a message comprising the one or more metrics or a request for the one or more metrics (¶ 56, “The NWDAF 206 then then retrieves the analytics data associated with the analytics ID”), and the message or the request comprises the token (¶ 54, “The access request 224 may include an access token, model parameters, model ID, etc”).
It would have been obvious to a person having ordinary skill in the art, at the effective filing date of the invention, to have applied the known technique of the one or more processors are configured to cause the apparatus to receive a token based on a successful registration of the apparatus with the network entity, to exchange the one or more metrics based on the third communication with the network entity via the second type of API at the network entity, the one or more processors are configured to cause the apparatus to send, to the network entity, via the second type of API, a message comprising the one or more metrics or a request for the one or more metrics, and the message or the request comprises the token, as taught by Aggarwal, in the same way to the exchanging metrics, as taught by Gudipati and Xu. Both inventions are in the field of API based communication networks, and combining them would have predictably resulted in “a mechanism that enables authorization of NWDAFs to operate as FL servers and FL clients is needed,” as indicated by Aggarwal (¶ 33).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ranganath (US 2024/0259879) teaches “an xApp manager that leverages the platform telemetry, capabilities and/or application traces to provide helpful information the xApps such as noisy neighbors, NIC congestion, platform reliability, dynamic power management” (¶ 25), which relates to the disclosed central management entity facilitating collection/exchange of operation metrics.
Melodia (US 2022/0167236) teaches “The RIC may be a near-real-time RIC. The at least one network element may be a base station, a central unit (CU) of a base station, a distributed unit (DU) of a base station, a radio unit (RU) of a base station” (¶ 7) which relates to the disclosed central intelligent controller.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB D DASCOMB whose telephone number is (571)272-9993. The examiner can normally be reached M-F 9:00-5:00.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/JACOB D DASCOMB/ Primary Examiner, Art Unit 2198
Prosecution Insights