DETAILED ACTION
Response to Amendment
This Non-Final Office Action is in response to the applicant’s remarks and arguments filed on June 25, 2025.
Claims 49, 61 and 68-69 were amended.
Claims 49-69 remain pending in the application. Claims 49-69 are being considered on the merits.
Response to Arguments
Response to the Section 103 Rejections
Applicant argues that:
Point 1 :
“There are two major problems with the Office Action's findings here. First, nothing in Hironori's paragraph 0040 says anything at all about location information of at least one API exposing function providing a discovered service”,
“second, the "Onboarding API invoker request" described in Hironori's paragraph 0040 is not an API discover response at all, and does not correspond to GE's "API discovery request.".
In response ,the examiner respectfully disagrees and submits that Hironori teaches in para 63 and 64, “service API information “ coupled with “service API Type/name “ and “API provider ID, publishing function ID” in Table 2, wherein the API type, interface details e,g, IP address"…. URI in FIG. 8) . Thus, the IP address" and URI represent address .Therefore these teachings of the service API information “ coupled with “service API Type/name coupled with “IP address" and the “URI” suggest an application location information of at least one API exposing function providing a discovered service.
Moreover , Hironori teaches in FIG. 8, “3. Service API discover response” coupled with “API provider functions” having “service API type” in para 35, wherein the wherein the “API type include IP address, URI/ location information in FIG. 8 . Thefore, these teachings of Hironnori suggest an API discover response that correspond API discovery request
Applicant is reminded that rejections are based on references as a whole and not just the cited passages. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the cited art or disclosed by the examiner.
As to point 2: “ The "first CAPIF core function" is introduced in claim 50, from which claim 51 depends, and is the node that sends the service API discover response. Thus, a first CCF, to which a service API discover request is sent, responds with a service API discover response that comprises information about a second CCF. This is not disclosed or suggested in either GE or Hironori.”.
In response, the examiner respectfully disagrees and submits that Hironori teaches in para 35, Table 1, “API provider functions” and “control plane functions”, “ user plane functions” .
Thus, one of the “functions” include a first CAPIF core function and second network function coupled with the API type comprising IP address, URI/ location information(see FIG. 8) representing information about first CAPIF core function and second network function. Therefore, these teachings of Hironori suggest a first CCF, to which a service API discover request is sent, responds with a service API discover response that comprises information about a second CCF .
Point 3:
Claim 53 specifies that the first network function is a first CCF, while the second network function is a second CCF. “,“In its analysis of claim 53, the Office Action demonstrates that GE discloses a CCF, but does not (and cannot) explain where or how GE discloses that an API discovery request and API discovery response are exchanged between two CCFs, as opposed to between an API invoker and a CCF” .
In response , the examiner respectfully disagrees and submits that GE teaches in claim 53, a first common API framework(CAPIF) core function and second CAPIF core function (e.g., see FIG. 2, para 72, “CAPIF Core Function (CAPIF Core Function, CCF)”, wherein “the CCF mainly has the following functions:”, “(1) authenticating”, “(4) supporting API publishing, API storage, and API discovery”, “(6) storing API invocation logs and providing the logs to an authorization entity; (7) performing charging based on the API logs; (8) monitoring API invocation; (9) registering the API invoker; (10) storing a configuration policy; and (11) supporting audit of the invocation and the logs” and “ a CAPIF-2 or CAPIF-2e interface” , “The CCF network element is connected to the AEF network element through a CAPIF-3 interface” , “ The CCF network element is connected to the APF network element through a CAPIF-4 interface” .
Thus, the CCF functions coupled with CAPIF- 1, CAPIF-2 , CAPIF-4 for “so that the API invoker can discover the API” in para 79, therefore these teaching suggest a first common API framework(CAPIF) core function and second CAPIF core function as disclosed in claim 53(emphasis added).
Applicant is reminded that rejections are based on references as a whole and not just the cited passages. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the cited art or disclosed by the examiner.
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
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) 49-69 are rejected under 35 U.S.C. 103 as being unpatentable over Culli GE et al. (WO2020/147565, published in July 23, 2020, examiner relies on US PUB. 2021/0344774 as the official translation document of the WO2020/147565, GE, hereinafter) in view of ITO, Hironori (WO 2019/194242, Hironori hereinafter).
As to claim 49, GE teaches a method performed by a first network function ( e.g., see “API invoker”, FIG. 2, para 93, “the CCF”,” API invoker sends an API discovery response message”), the method comprising:
sending a first service application programming interface (API) discover request (e.g., see FIG. 2, para [0093] Step 1: The API invoker sends an API discovery request message to the CCF, where the API discovery request message includes the identifier of the API invoker and a discovery filtering condition.) to a second network function (e.g., “CAPIF API”, “CAPIF Core Function”, FIG. 2, “CCF”, para 72-73, “ CAPIF Core Function (CAPIF Core Function, CCF)” The CCF mainly has the following functions: (1) authenticating the API invoker based on an identifier of the API invoker and other information; (2) supporting mutual authentication between the CCF and the API invoker; (3) providing the API invoker with authorization before the API invoker invokes the API; (4) supporting API publishing, API storage, and API discovery; (5) being responsible for access control of the API based on policies of a PLMN operator; (6) storing API invocation logs and providing the logs to an authorization entity; (7) performing charging based on the API logs; (8) monitoring API invocation; (9) registering the API invoker; (10) storing a configuration policy; and (11) supporting audit of the invocation and the logs).
Thus, the CAPIF Core Function, CCF” coupled with functions: (1) authenticating”, “2) supporting mutual authentication “ include the second network function .; and
receiving a first service API discover response from the second network function ( e.g., wherein “The CCF sends an API discovery response message to the API invoker” in para 95 . Thus, receiving a first service API discover response from the second network function ) of at least one API exposing function (e.g., API exposing Function “, FIG. 2) providing the discovered service API (e.g., para [0095] Step 3: The CCF sends an API discovery response message to the API invoker, where the API discovery response message includes information about an API allowed to be used by the API invoker. It should be understood that the information about the API may be information about one API or information about a plurality of APIs), wherein the first service API discover response comprises information (e.g., “information about one API “, “identifier of the API invoker and other information” in para 76 and 95) of at least one API exposing function providing the discovered service API (para 75, [0075] 3. API Exposing Function (API Exposing Function, AEF) Network Element
[0076] The AEF provides the API, and is an entry for the API invoker to invoke the API. The AEF mainly includes the following functions: (1) authenticating the API invoker based on the identifier of the API invoker and other information provided by the CCF; (2) confirming the authorization provided by the CCF; and (3) synchronizing the API logs to the CCF)..
However, GE does not teach location information.
Hironori teaches wherein the first service API discover response comprises location information of at least one API exposing function providing the discovered service API (e.g., see FIG. 8, FIG. 8, “Result list of service APis corresponding to the request, Including API description such as API name, API type, Interface details (e,g, IP address" …URL)” , para 90, “API invoker's service API request” , “the Service API discover response message to the API invoker 20 along with Result, Service API information”.. Thus, the API type , IP address" and “URL” as the result include comprises location information ). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 50, GE teaches wherein the first network function is an API invoker (e.g., “API invoker ”, FIG. 2) and the second network function is a first common API framework (CAPIF) core function (e.g., “CAPIF core function”, FIG. 2 and “the CAPIF is deployed, the CCF” , “The CCF mainly has the following functions: (1) authenticating the API invoker based on the identifier of the API invoker and other information provided by the CCF; (2) confirming the authorization provided by the CCF; and (3) synchronizing the API logs to the CCF) “ in para 72-73 and 100 . Thus, one of the “functions” include a first common API framework (CAPIF) .
As to claim 51, GE teaches wherein when the first service API discover response comprises information regarding a second CAPIF core function, the method further comprises: sending a second service API discover request to the second CAPIF core function; and receiving a second service API discover response from the second CAPIF core function (e.g., [0095] Step 3: The CCF sends an API discovery response message to the API invoker, where the API discovery response message includes information about an API allowed to be used by the API invoker. It should be understood that the information about the API may be information about one API or information about a plurality of APIs.
Thus, the “the information” includes information regarding a second CAPIF core function, wherein the “plurality of APIs” coupled with “information about a plurality of APIs” , The “CCF receives the API discovery request message from the API invoker”, “ The CCF sends an API discovery response message to the API invoker” n para 93-95, therefore , wherein when the first service API discover response comprises information regarding a second CAPIF core function, the method further comprises: sending a second service API discover request to the second CAPIF core function; and receiving a second service API discover response from the second CAPIF core function ). However, GE does not teach wherein the second service API discover response comprises location information of at least one API exposing function providing the discovered service API. Hironori teaches the second service API discover response comprises location information of at least one API exposing function providing the discovered service API (e.g., e.g., see FIG. 8, FIG. 8, “Result list of service APis corresponding to the request, Including API description such as API name, API type, Interface details (e,g, IP address" …URL)” , para 90, “API invoker's service API request” , “the Service API discover response message to the API invoker 20 along with Result, Service API information”.. Thus, the API type , IP address" and “URL” as the result include comprises location information). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 52, GE does not explicitly teach sending an onboard API invoker request to a third CAPIF core function; and receiving an onboard API invoker response from the third CAPIF core function, wherein the onboard API invoker request and the onboard API invoker response comprise location information of at least one API exposing function. However, Hironori teaches sending an onboard API invoker request to a third CAPIF core function; and receiving an onboard API invoker response from the third CAPIF core function, wherein the onboard API invoker request and the onboard API invoker response comprise location information of at least one API exposing function (e.g., see Figure 2, para [0036] Variant for Onboard Token generation: Onboard token generation shall be bound to any combination of the following: API provider ID/CAPIF core function Specific API Invoker IDII CAPIF IDI Onboarded Subscription Typell Discovery levelllLifetimellSecret.
[0040] 1. The API invoker 20 sends the Onboarding API invoker request to the CAPIF core function 21 with the API Invoker Information along with the subscription identification information, subscription identifier, subscriber identifier or device identifier, user or device specific application identifier, requested subscription type, see FIG. 8, FIG. 8, “Result list of service APis corresponding to the request, Including API description such as API name, API type, Interface details (e,g, IP address" …URL)” , para 90, “API invoker's service API request” , “the Service API discover response message to the API invoker 20 along with Result, Service API information”.. Thus, the API type , IP address" and “URL” as the result include comprises location information Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 53, GE teaches wherein the first network function is a first common API framework (CAPIF) core function (e.g., “authenticating the API invoker based on an identifier of the API invoker and other information “in para 73, include first common API framework (CAPIF) core function ) and the second network function is a second CAPIF core function (e.g., para [0072] 2. CAPIF Core Function (CAPIF Core Function, CCF) Network Element
[0073] The CCF mainly has the following functions: (1) authenticating the API invoker based on an identifier of the API invoker and other information; (2) supporting mutual authentication between the CCF and the API invoker; (3) providing the API invoker with authorization before the API invoker invokes the API; (4) supporting API publishing, API storage, and API discovery; (5) being responsible for access control of the API based on policies of a PLMN operator; (6) storing API invocation logs and providing the logs to an authorization entity; (7) performing charging based on the API logs; (8) monitoring API invocation; (9) registering the API invoker; (10) storing a configuration policy; and (11) supporting audit of the invocation and the logs.
Thus, “supporting API publishing, API storage, and API discovery” include the second CAPIF core function).
As to claim 54, GE teach wherein the first service API discover request is an interconnection service API discover request and the first service API discover response is an interconnection service API discover response (e.g., see FIG. 6 and 7-8, para [0093] Step 1: The API invoker sends an API discovery request message to the CCF, where the API discovery request message includes the identifier of the API invoker and a discovery filtering condition.
[0094] Step 2: The CCF receives the API discovery request message from the API invoker, and authenticates an identity of the API invoker based on the identifier of the API invoker. If the API invoker is authenticated, the CCF searches for information about a published API based on the foregoing discovery filtering condition and policy information of the API invoker.
[0095] Step 3: The CCF sends an API discovery response message to the API invoker, where the API discovery response message includes information about an API allowed to be used by the API invoker. It should be understood that the information about the API may be information about one API or information about a plurality of APIs.
As to claim 55, GE teaches further receiving a third service API discover request from a fifth network function; processing the third service API discover request; and sending a third service API discover response to the fifth network function (e.g., para [0095] Step 3: The CCF sends an API discovery response message to the API invoker, where the API discovery response message includes information about an API allowed to be used by the API invoker. It should be understood that the information about the API may be information about one API or information about a plurality of APIs.
Thus, the “plurality of APIs” coupled with “API discovery response message” , “the API discovery request message “ in para 93, include a third service API discover request, a third service API discover response, therefore receiving a third service API discover request from a fifth network function; processing the third service API discover request; and sending a third service API discover response to the fifth network function ). However, GE does not explicitly teach wherein the third service API discover response comprises location information of at least one API exposing function providing the discovered service API. Hironori teaches wherein the third service API discover response comprises location information of at least one API exposing function providing the discovered service API (e.g. see FIG. 10, para [0117] Figure 10 illustrates schematically an exemplary security procedure for authen- [0118] citation between the API invoker 20 and the AEF 22 upon the service API invocation. 1. The API invoker 20 sends the Service API invocation request message with authentication information such as CAPIF API Invoker ID, Invocation token* (derived as shown in Figure 11), Required or Requested Service Apl(s) ID(s) (Service type/name/ID) and related information to the API exposing function (AEF) 22. For every new invocation, a new Invocation Token* is computed to avoid security breach due to token reuse. a. Variant: Invocation token* is derived using invocation/ access/ authorization
Para [0088] 1. The API invoker 20 sends the Service API discover request message to the CCF 21 with API invoker identity information (CAPIF API Invoker ID and/or its related credentials), Authorization Token (it is the onboard token itself or a token derived from the Onboard token), Zone id (API invoker's current network or location), and other Query information: Criteria for discovering matching service APis ( e.g. API type, in terfaces , protocols).
[0089] 2. The CCF 21, on receiving the Service API discover request message, verifies the CAPIF specific API Invoker ID, its stored Onboarding result, Trust level of API invoker and Zone/network/location corresponding to the Zone ID from where the API invoker resides and Authorization Token (it is bounded to the onboard token and/or CAPIF API ID and/or CAPIF ID) and if the verification is successful, the CCF 21 retrieves the service Apl(s) information based on the verification results). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 56, GE teaches wherein the fifth network function is an API invoker or a CAPIF core function (e.g., see “ API invoker”, “CCF”, FIGs.2 2 2 6 and 7, para [0091] 2. API Discovery Procedure [0092] If the API invoker has logged in and an identifier of the API invoker exists, and the CCF has configured a discovery policy for the API invoker, the following steps may be performed: [0093] Step 1: The API invoker sends an API discovery request message to the CCF, where the API discovery request message includes the identifier of the API invoker and a discovery filtering condition. [0094] Step 2: The CCF receives the API discovery request message from the API invoker, and authenticates an identity of the API invoker based on the identifier of the API invoker. If the API invoker is authenticated, the CCF searches for information about a published API based on the foregoing discovery filtering condition and policy information of the API invoker.).
As to claim 57, GE teaches wherein processing the third service API discover request comprises determining that the second network function is used for serving the third service API discover request and wherein the first service API discover request is sent to the second network function in response to the determination (e.g., see FIGs.2 26 and 7, para [0091] 2. API Discovery Procedure [0092] If the API invoker has logged in and an identifier of the API invoker exists, and the CCF has configured a discovery policy for the API invoker, the following steps may be performed: [0093] Step 1: The API invoker sends an API discovery request message to the CCF, where the API discovery request message includes the identifier of the API invoker and a discovery filtering condition. [0094] Step 2: The CCF receives the API discovery request message from the API invoker, and authenticates an identity of the API invoker based on the identifier of the API invoker. If the API invoker is authenticated, the CCF searches for information about a published API based on the foregoing discovery filtering condition and policy information of the API invoker. [0095] Step 3: The CCF sends an API discovery response message to the API invoker, where the API discovery response message includes information about an API allowed to be used by the API invoker. It should be understood that the information about the API may be information about one API or information about a plurality of APIs. Therefore, wherein processing the third service API discover request comprises determining that the second network function is used for serving the third service API discover request and wherein the first service API discover request is sent to the second network function in response to the determination would have been inherent). .
As to claim 58, GE does not explicitly teach wherein a service API discover request comprises API invoker interface information and/or location information of at least one target API exposing function, wherein 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, wherein the API invoker interface information is used to discover at least one second service API and at least one API exposing function providing the discovered at least one second service API is topologically close to the API invoker. However, Hironori teaches wherein a service API discover request comprises API invoker interface information and/or location information of at least one target API exposing function, wherein 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, wherein the API invoker interface information is used to discover at least one second service API and at least one API exposing function providing the discovered at least one second service API is topologically close to the API invoker (e.g., see FIG. 8, para [0087] Figure 8 illustrates schematically an exemplary security procedure to discover Service APis.
[0088] 1. The API invoker 20 sends the Service API discover request message to the CCF 21 with API invoker identity information (CAPIF API Invoker ID and/or its related credentials), Authorization Token (it is the onboard token itself or a token derived from the Onboard token), Zone id (API invoker's current network or location), and other Query information: Criteria for discovering matching service APis ( e.g. API type, interfaces, protocols). a. Variant: The authorization token issued is specific to the discovery level or is derived from the Onboard token.
[0089] 2. The CCF 21, on receiving the Service API discover request message, verifies the CAPIF specific API Invoker ID, its stored Onboarding result, Trust level of API invoker and Zone/network/location corresponding to the Zone ID from where the API invoker resides and Authorization Token (it is bounded to the onboard token and/or CAPIF API ID and/or CAPIF ID) and if the verification is successful, the CCF 21 retrieves the service Apl(s) information based on the verification results.
[0090] 3. If the verification is successful, the CCF 21 sends the Service API discover response message to the API invoker 20 along with Result, Service API information. Based on the verification of the trust level of the API invoker 20 and/or its API invoker Zone, or User/ API invoker/application specific subscription information stored at the CCF 21, the Discovery of Service API level for an API invoker 20 is decided and Topology is hidden accordingly.). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 59, GE teaches wherein the API invoker interface information comprises an Internet protocol (IP) address of the API invoker (e.g., para [0180] In S603, the API invoker sends an API invocation request to the border AEF, where the API invocation request includes information about an API (for example, an address (URI) of a resource (resource) corresponding to the API, or identification information of the API) and invocation parameter information. The invocation parameter information may be specifically a terminal device IP, area information, location information, or the like. The terminal device IP indicates an IP address of a terminal device, and may be an IPv4 or IPv6 address. The area information indicates information about an area in which the API is used. The area information may be network area description information, for example, a cell identifier, a tracking area (tracing area, TA) identifier, and an area of interest identifier, or may be physical area description information. The location information may indicate information about a location at which the API is used, and may be specifically location information of the terminal device.).
As to claim 60, GE does not teach wherein the location information of at least one target API exposing function comprises at least one of a civic address, a coordinate, or a data center identifier. However, Hironori teaches wherein the location information of at least one target API exposing function comprises at least one of a civic address, a coordinate or a data center identifier (e.g., para [0172] 3) Trust Zone level indication/indicator indicates a zone where the API invoker 20 resides or the API invoker's Access point or radio or access network element through which it connects to the network. The CCF 21 decides the trust level of the API invoker's residing zone based on the Zone ID/APN/access network information it received from the API invoker 20 or the trust level information it maintains with various network zone it can support communication and services. Every CCF 21 maintains a specific trust level for every network/location/zone it can support service/ communication.
“ 5) Zone ID and its trust level related indicator: Mobile network operators subdivide their networks into trust zones. Each trust zone has a unique Zone ID. Any network entity that communicates with another entity that reside in a particular zone has a trust level assigned for that Zone ID based on their policies or service level history. A specific zone's Zone ID and its trusted level differ or does not differ across its relation with other different network.
Thus, the Zone ID represents coordinate or data center identifier). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 61, see rejection of claim 1 above. GE teaches further a method performed by a second network function (e.g., para 0056] FIG. 9 is a schematic block diagram of another apparatus for invoking an application programming interface according to an embodiment of this application; and [0057] FIG. 10 is a schematic block diagram of another apparatus for invoking an application programming interface according to an embodiment of this application)
As to claim 62, see rejection of claim 58 above.
As to claims 63-65, see rejection of claims 59-60 and 56 above.
As to claim 66, GE teaches wherein processing the first service API discover request comprises: determining that a second CAPIF core function is used for serving the first service API discover request, wherein the first service API discover response comprises information regarding the second CAPIF core function (e.g., see FIGs.2 6 an7, para [[0093] Step 1: The API invoker sends an API discovery request message to the CCF, where the API discovery request message includes the identifier of the API invoker and a discovery filtering condition. [0094] Step 2: The CCF receives the API discovery request message from the API invoker, and authenticates an identity of the API invoker based on the identifier of the API invoker. If the API invoker is authenticated, the CCF searches for information about a published API based on the foregoing discovery filtering condition and policy information of the API invoker. [0095] Step 3: The CCF sends an API discovery response message to the API invoker, where the API discovery response message includes information about an API allowed to be used by the API invoker. It should be understood that the information about the API may be information about one API or information about a plurality of APIs. ).
As to claim 67, GE does not teach receiving an onboard API invoker request from the API invoker; processing the onboard API invoker request; and sending an onboard API invoker response to the API invoker, wherein the onboard API invoker request and the onboard API invoker response comprise location information of at least one API exposing function. However, Hironori teaches receiving an onboard API invoker request from the API invoker; processing the onboard API invoker request; and sending an onboard API invoker response to the API invoker, wherein the onboard API invoker request and the onboard API invoker response comprise location information of at least one API exposing function (.g., see Figure 2, para [0036] Variant for Onboard Token generation: Onboard token generation shall be bound to any combination of the following: API provider ID/CAPIF core function Specific API Invoker IDII CAPIF IDIIOnboarded Subscription Typell Discovery levelllLifetimellSecret.
[0040] 1. The API invoker 20 sends the Onboarding API invoker request to the CAPIF core function 21 with the API Invoker Information along with the subscription identification information, subscription identifier, subscriber identifier or device identifier, user or device specific application identifier, requested subscription type, its locations Trust Zone Level Indication or zone identifier (Zone ID) and the maximum or minimum Onboarding Lifetime (Optional parameter). a. Variant: The Zone ID can be the Access Point Name or the access network related information through which the API invoker 20 is connected to the network.). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of GE by adopting the teachings of Hironori to allow this “ensures mutual authentication between the API invoker 20 and the AEF 22 upon service invocation.” (see Hironori, para 122).
As to claim 68, see rejection of claim 1 above. GE teaches further a first network function, comprising: a processor; and a memory coupled to the processor, said memory containing instructions executable by said processor, whereby said first network function is operative to (e.g., para [0221] FIG. 10 shows another apparatus 1000 for invoking an application programming interface according to an embodiment of this application. The apparatus 1000 includes a processor 1010, a transceiver 1020, and a memory 1030. The processor 1010, the transceiver 1020, and the memory 1030 communicate with each other through an internal connection path. The memory 1030 is configured to store instructions. The processor 1010 is configured to execute the instructions stored in the memory 1030, to control the transceiver 1020 to send a signal and/or receive a signal.):
As to claim 69, GE teaches further second network function, comprising: a processor; and a memory coupled to the processor, said memory containing instructions executable by said processor, whereby said second network function is operative to: (e.g., [0221] FIG. 10 shows another apparatus 1000 for invoking an application programming interface according to an embodiment of this application. The apparatus 1000 includes a processor 1010, a transceiver 1020, and a memory 1030. The processor 1010, the transceiver 1020, and the memory 1030 communicate with each other through an internal connection path. The memory 1030 is configured to store instructions. The processor 1010 is configured to execute the instructions stored in the memory 1030, to control the transceiver 1020 to send a signal and/or receive a signal.).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198