DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 23 January 2026 has been entered.
Claims 21, 25-27, 29, 31, 38-40, 43, 45, and 50-53 are pending.
Claims 21 and 40 have been amended.
Claims 23 and 41 have been cancelled.
Response to Arguments
35 USC § 102
Regarding amended claim 21, Applicant argues that, “NPL does nothing however to state that the status of the service API comprises active or inactive statuses. In the rejection to claim 23, the Final Office Action states that Table 8.8.6-1 discloses this but the table merely comprises a list of Events and Event Descriptions, none of which comprises an event titled "Status of the Service API" or active/inactive”. Examiner finds the argument persuasive and a new ground of rejection is presented herewith.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21, 25-27, 29, 31, 38-40, 43, 45, and 50-53 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP TS 23.222 v16.10.0 (2021-06), hereinafter NPL, in view of Kwan et al (US 11,748,686).
Regarding claim 21, NPL teaches a method in a Common Application Programming Interface 'API' Framework 'CAPIF' Core Function, CCF, comprising:
receiving, from an API Publishing Function, APF, a service API publish request or service API update request containing service API status information indicating a status of a service API, and indicating, to an API invoker or another CCF, the service API status information as part of a service API discovery procedure (NPL 8.28.2.1 and “Table 8.28.2.1-1 describes the information flow, registration request, from the API management function to the CAPIF core function”);
wherein the service API status information is carried in service API information (NPL 8.25.3.2 provides Service API discovery involving multiple CCFs. Specifically, fig. 8.25.3.2-1: Service API discovery involving multiple CCFs provides for an API invoker or another CCF and service API status information as part of the API discovery procedure. In this regard, NPL states, The API invoker sends a service API discover request to the CCF-A. Tt includes the API invoker identity, and may include query information. The CCF-A verifies the identity of the API invoker and retrieves the stored service APIs) information and service API categories. The information of CCF-B with the service API category matching the discovery criteria is returned to API invoker in the service API discover response. NOTE: The remaining steps are only applied when the service API category is included in the interconnection AP publish request as described in subclause 8.25.21. The APL invoker sends as service APL discover request to the CCF-B. The identity of API invoker is included. The query information is also provided. Upon receiving the service APL discover request, the CCF-B verifies the identity of the APL invoker. The CCF-8 retrieves the stored service APIs) information as per the query information in the service API discover request. Further, the CCF-B applies the discovery policy and performs filtering of service APls information which matches the discovery criteria. The CCF-B sends an service API discover response to the API invoker with the list of service API information for which the API invoker has the required authorization).
NPL teaches the above, but NPL does not explicitly teach wherein the status of the service API comprises active or inactive. However, in a similar field of endeavor, Kwan teaches wherein the status of the service API comprises active or inactive (Kwan col.7 lines 16-21 provides “Further, the dimension configuration 114 can be generated by the service onboarding server 110 from the API configuration information 106 and the API service information 108. For example, the dimension configuration 114 for the Invoice Manager service can include an indication of a API state (e.g., active or inactive) …”).
One of ordinary skill in the art before the effective filing date of Applicant’s claimed invention would have recognized the utility of the API state information as taught by Kwan, in the NPL system, for monitoring service availability, managing traffic flow, and directing requests away from failing components.
Regarding claim 25, the method of claim 21, further comprising: transmitting, to another CCF, an interconnection API publish request containing the service API status information (NPL Table 8.25.2.1-1).
Regarding claim 26, the method of claim 21, wherein the service API discovery procedure further comprises: receiving, from an API invoker or the other CCF, a service API discover request (NPL 8.28.2.1 and “Table 8.28.2.1-1 describes the information flow, registration request, from the API management function to the CAPIF core function”; and transmitting, to the API invoker or the other CCF, a service API discover response based on the service API status information (NPL 8.28.2.1 and “Table 8.28.2.1-1 describes the information flow, registration request, from the API management function to the CAPIF core function”.
Regarding claim 27, the method of claim 26, wherein said transmitting the service API discover response based on the service API status information comprises: transmitting the service API discover response that contains service API information of the service API, the service API information containing the service API status information (NPL table 8.28.2.1-1 in which it is specified that the request contains a list of API provider domain functions including role as AEF for instance: "List of API provider domain functions including role (e.g. AEF, APF, AMF) and, if required, specific security information", hence information regarding AEF is sent in the registration request; NPL shows the architecture that is used for the common API framework CAPIF allowing the exposition of the 3GPP API to third party application. The CAPIF allows the registration and discovery of API. API Invokers discover and have access to the APIs via the CAPIF. The invokers can subscribe for events of the CAPIF. The CAPIF already receives information on AEF from an AMF (paragraph 8.28.2.1). This means that the AMF has access on data regarding the AEF, its nature and if it is available or not, otherwise it would not be possible to list it in the registration process. This implies that the AMF has knowledge of the status of the AEF. Coming to solve the above proposed objective technical problem of monitoring an AEF, and knowing that AEF information is sent from the AMF to the CAPIF it can be reasonably interpreted that all the available information regarding the AEF in the process of registration in sent, as is already done for other available information).
Regarding claim 29, the method of claim 26, wherein said transmitting the service API discover response based on the service API status information comprises: transmitting the service API discover response that contains service API information of the service API when the status of the service API is active (NPL table 8.28.2.1-1 in which it is specified that the request contains a list of API provider domain functions including role as AEF for instance: "List of API provider domain functions including role (e.g. AEF, APF, AMF) and, if required, specific security information", hence information regarding AEF is sent in the registration request; NPL shows the architecture that is used for the common API framework CAPIF allowing the exposition of the 3GPP API to third party application. The CAPIF allows the registration and discovery of API. API Invokers discover and have access to the APIs via the CAPIF. The invokers can subscribe for events of the CAPIF. The CAPIF already receives information on AEF from an AMF (paragraph 8.28.2.1). This means that the AMF has access on data regarding the AEF, its nature and if it is available or not, otherwise it would not be possible to list it in the registration process. This implies that the AMF has knowledge of the status of the AEF. Coming to solve the above proposed objective technical problem of monitoring an AEF, and knowing that AEF information is sent from the AMF to the CAPIF it can be reasonably interpreted that all the available information regarding the AEF in the process of registration in sent, as is already done for other available information; Table 8.8.6-1).
Regarding claim 31, the method of claim 26, further comprising: receiving, from an API Management Function, AMF, a registration request or registration update request containing API Exposing Function, AEF, information on an AEF that is an Application Server, AS, providing the service API, the AEF information comprising a status of the AEF (NPL 6.2.0-1, 6.2.0-2).
Regarding claim 38, the method of claim 21, further comprising: receiving, from an API invoker or another CCF, a request for subscribing, or updating subscription, for notification of service API status information associated with the service API or a service API type to which the service API belongs; and transmitting, to the API invoker or the other CCF, a notification of the service API status information (NPL 8.8).
Regarding claim 39, the method of claim 38, wherein the request for subscribing or updating comprises an event filter for an identification of the service API or the service API type (NPL 8.8).
Regarding claim 40, this claim contains limitations found within those of claim 21, and the same rationale of rejection applies, where applicable.
Regarding claim 43, the method of claim 40, wherein the service API discovery procedure further comprises: transmitting, to the CCF, a service API discover request, wherein said receiving the service API status information comprises: receiving, from the CCF, a service API discover response that contains service API information of the service API, the service API information containing the service API status information (NPL 8.8).
Regarding claim 45, the method of claim 43, further comprising: transmitting, to the CCF, a request for subscribing, or updating subscription, for notification of API Exposing Function, AEF, information associated with an AEF that is an Application Server, AS, providing the service API or an AEF type to which the AEF belongs; and receiving, from the CCF, a notification of the AEF information, the AEF information comprising a status of the AEF (NPL 6.2.0-1, 6.2.0-2, 8.8).
Regarding claim 50 the method of claim 40, further comprising: transmitting, to the CCF, a request for subscribing, or updating subscription, for notification of service API status information associated with the service API or a service API type to which the service API belongs, wherein said receiving the service API status information comprises: receiving, from the CCF, a notification of the service API status information (NPL 8.28.2.1, 8.8).
Regarding claim 51, the method of claim 50, wherein the request for subscribing or updating comprises an event filter for an identification of the service API or the service API type (NPL 8.21.3).
Regarding claim 52, the method of claim 40, further comprising: transmitting, to the CCF, an onboard API invoker request containing an indication that the CCF is to take control of API invocation influence or containing no indication on whether the API invoker or the CCF is to take control of API invocation influence; and receiving, from the CCF, an onboard API invoker response containing a confirmation or indication that the CCF is to take control of API invocation influence (NPL 6.4.6).
Regarding claim 53, the method of claim 40, further comprising: transmitting, to the CCF, an onboard API invoker request containing an indication that the API invoker is to take control of API invocation influence; and receiving, from the CCF, an onboard API invoker response containing a confirmation that the API invoker is to take control of API invocation influence (NPL 6.4.6).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Doane et al US 2023/0135936.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ISHRAT RASHID whose telephone number is (571)272-5372. The examiner can normally be reached 10AM-6PM EST M-F.
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, Tonia L Dollinger can be reached at 571-272-4170. 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.
/I.R/Examiner, Art Unit 2459 /TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459