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 .
This office action is in response to Applicant’s preliminary amendment filed April 8, 2025. Claims 1, 3-9 have been amended. Claims 10-20 are newly added. Claims 1-20 are pending.
Information Disclosure Statement
The IDS filed 5/13/2025 and 12/11/2025 have been considered.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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.
Claim(s) 1-5, 8-13, 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Xu (US 20230359515), in view of Krishan et al. (US 20230229539, hereinafter referred to as “Krishan”).
Regarding claim 1, Xu teaches a communication method, wherein the method comprises:
receiving, by a first entity, a first request sent by a second entity, wherein the first request comprises a first application programming interface (API) requested by the second entity (abstract - sending a first service application programming interface (API) discover request to a second network function); and
receiving, by the first entity, a first response sent by the network management system, wherein the first response comprises interface information of the first API (abstract - receiving a first service API discover response from the second network function. The first service API discover response comprises location information of at least one API exposing function providing the discovered service API.).
However, Xu does not explicitly teach determining, by the first entity from pre-stored first API information, that the first API is unavailable, wherein the first API information comprises availability of a plurality of APIs, and the plurality of APIs comprise the first API; and sending, by the first entity, a second request to a network management system, wherein the second request is used to request to instantiate an API provider entity corresponding to the first API.
In an analogous art, Krishan teaches determining, by the first entity from pre-stored first API information, that the first API is unavailable, wherein the first API information comprises availability of a plurality of APIs, and the plurality of APIs comprise the first API ([0051] In some embodiments, CAPIF node 200, RM 204, or another entity may use health statuses or related information when providing notifications (e.g., about changing of availability of API endpoints) to subscribed API invoker(s) 210. For example, CAPIF node 200, RM 204, or another entity may be configured to notify subscribed API invoker(s) 210 about an API endpoint being available/unavailable (e.g., at or during runtime) based on health statuses or related information determined from performing health checks.); and
sending, by the first entity, a second request to a network management system, wherein the second request is used to request to instantiate an API provider entity corresponding to the first API ([0091] In step 511, in response to determining that an API or related endpoint is now “inactive”, a notification message indicating this change in availability may be sent from CAPIF node 200 to subscribed entities, e.g., API invoker(s) 210. For example, CAPIF node 200, RM 204, or another entity may be configured to notify subscribed API invoker(s) 210 about an API endpoint being unavailable.).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to incorporate the API availability determination of Krishan into the API discovery framework of Xu to ensure that API discovery results accurately reflect the operational availability of registered APIs, therefore improving the reliability of API discovery and reducing unsuccessful connection attempts.
Regarding claim 2, Xu teaches the method according to claim 1, wherein the method further comprises: sending, by the first entity, a second response to the second entity, wherein the second response comprises the interface information of the first API (figure 6: 606).
Regarding claim 3, Xu teaches the method according to claim 1, wherein the method further comprises: when the API provider entity corresponding to the first API comprises a plurality of API provider entities, selecting, by the first entity, a target API provider entity from the plurality of API provider entities ([0011] In an embodiment, when the first service API discover response comprises information regarding a second CAPIF core function, the method may further comprise sending a second service API discover request to the second CAPIF core function. The method may further comprise receiving a second service API discover response from the second CAPIF core function. The second service API discover response comprises location information of at least one API exposing function providing the discovered service API.)
However, Xu does not teach wherein: the second request comprises an identifier of the target API provider entity, and the second request is used to request to instantiate the target API provider entity.
Krishan teaches wherein: the second request comprises an identifier of the target API provider entity, and the second request is used to request to instantiate the target API provider entity ([0091] In step 511, in response to determining that an API or related endpoint is now “inactive”, a notification message indicating this change in availability may be sent from CAPIF node 200 to subscribed entities, e.g., API invoker(s) 210. For example, CAPIF node 200, RM 204, or another entity may be configured to notify subscribed API invoker(s) 210 about an API endpoint being unavailable.).
The motivation to combine is the same as claim 1.
Regarding claim 4, Xu teaches the method according to claim 1, wherein before the receiving, by a first entity, a first request sent by a second entity, the method further comprises: receiving, by the first entity, second API information sent by the network management system, wherein the second API information comprises at least one of an API of an instantiable API provider entity or availability of the API of the instantiable API provider entity ([0095] FIG. 4 shows high level functional architecture for CAPIF interconnection within a CAPIF provider domain according to an embodiment of the disclosure, in which the embodiments of the present disclosure can be implemented. FIG. 4 is same as Figure 6.2.2-2 of 3GPP TS 23.222 V17.1.0. The architectural model for the CAPIF interconnection within the same CAPIF provider domain may allow API invokers of CAPIF core function 1 to utilize the service APIs from CAPIF core function 2, where both CAPIF core function 1 and CAPIF core function 2 are hosted within the trust domain of the CAPIF provider A.).
Regarding claim 5, Xu teaches the method according to claim 1, wherein the first entity is a common application programming interface framework core function (CCF) entity, and the second entity is an application programming interface (API) invoking entity ([0006] A second problem is that there is no API invoker interface information in a service API discovery request. The API invoker interface information such as the API invoker’s IP (Internet protocol) address may be useful for a CCF (CAPIF core function) to make a decision in a service API discovery procedure. For example, the API invoker interface information may be used to offer candidate AEFs which are topologically close to the API invoker. However there is no API invoker interface information in the service API discovery request.).
Claim 8 is similar to claim 1. It is broader in that it does not recite pre-stored first API information. Nevertheless, it is rejected under the same rationale as claim 1.
Claim 9 is similar to claim 1 but in communication apparatus form. It further recites processor and non-transitory computer readable medium. Nevertheless all the extra features as well as the main features are disclosed in Xu in view of Krishan as cited in claim 1. For example, Xu teaches both processor and non-transitory computer readable medium in [0037].
Claims 10-13 are similar to claims 2-5, respectively, therefore are rejected under the same rationale.
Claims 16-19 are similar to claims 2-5, respectively, therefore are rejected under the same rationale.
Claim(s) 6-7, 14-15 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Xu (US 20230359515), in view of Krishan et al. (US 20230229539, hereinafter referred to as “Krishan”), in further view of Caldato et al. (US 10599499, hereinafter referred to as “Caldato”).
Regarding claim 6, neither Xu nor Krishan teaches the method according to claim 1, wherein the availability of the plurality of APIs indicates that an API is available after instantiation for the API is performed. Caldato teaches wherein the availability of the plurality of APIs indicates that an API is available after instantiation for the API is performed (col. 22, lines 7-25: When a calling service 2006 wants to use the service 2008, the API registry 404 can generate code in the client library 2002 that handles the run-time instantiation of the service 2008. For example, the CreateInstance( ) function call in the client library 2002 can create a call to the API registry 404. The API registry can then interact with the container platform 210 to determine whether an operating instance of the service 2008 is available. If not, the API registry 404 can instruct the container platform 210 to instantiate an instance of the service 2008 in a container in the container platform 2010. The container platform 210 can then return the endpoint (e.g., IP address and port number) to the API registry 404. The API registry 404 can then create a binding between that endpoint and the API function call created in the client library 2002. API registry 404 can then return the endpoint to the client library 2002 which can be used to create the direct connection between the calling service 2006 and the newly instantiated service 2008.)
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to combine the service instantiation technique of Caldato with the teachings of Xu and Krishan so that when a request API provider is not operational, an instance is instantiated before interface information is returned, thus improvise the reliability of API discovery by ensuring that the returned interface information corresponds to an operational API provider cable of service the request.
Regarding claim 7, neither Xu nor Krishan teaches the method according to claim 6, further comprising: determining, by the first entity, that the API is available after the instantiation for the API is performed. Caldato teaches determining, by the first entity, that the API is available after the instantiation for the API is performed (col. 22, lines 7-25: When a calling service 2006 wants to use the service 2008, the API registry 404 can generate code in the client library 2002 that handles the run-time instantiation of the service 2008. For example, the CreateInstance( ) function call in the client library 2002 can create a call to the API registry 404. The API registry can then interact with the container platform 210 to determine whether an operating instance of the service 2008 is available. If not, the API registry 404 can instruct the container platform 210 to instantiate an instance of the service 2008 in a container in the container platform 2010. The container platform 210 can then return the endpoint (e.g., IP address and port number) to the API registry 404. The API registry 404 can then create a binding between that endpoint and the API function call created in the client library 2002. API registry 404 can then return the endpoint to the client library 2002 which can be used to create the direct connection between the calling service 2006 and the newly instantiated service 2008.). The motivation to combine is the same as claim 6.
Claims 14-16 are similar to claims 6-7, respectively, therefore are rejected under the same rationale.
Claim 20 is similar to claim 6, therefore is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ge et al., CN 110730499 - a MEC information obtaining method and device, comprising: the first network element receives the target reference information from the second network element, information of the first network element to the second network element sends the MEC of the target corresponding to the reference information. The method realizes the discovery process of the MEC can make the second network element communicates with the MEC according to information obtained by the MEC, so as to use the capability of the MEC implement itself cannot satisfy the service requirement.
Ge et al., CN 110661638 - the CCF network element firstly sends the reference information of the application to the first network element, so the first network element determines the network slicing information corresponding to the application, so that the first network element sends the determined network slicing information to the CCF network element; Thus, the CCF network element can determine network slicing information corresponding to the application, so that when the API calls the network element to search API, the CCF network element can be from the network slice corresponding to the network slicing information; the API query parameter is accurately searched to the API.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights