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 .
DETAILED ACTION
1. This communication is a first office action, non-final rejection on the merits. Claims 1-19 and 22, filed as preliminary amendment, are currently pending and have been considered below.
Response to Amendment
2. Applicant’s amendment filed September 10, 2024. Claims 20-21 and 23-34 cancelled. Claims 1-19 and 22 presented for Examination. Applicant’s amendment has been fully considered and entered
Priority
3. As required by M.P.E.P.201.14(c), acknowledgement is made of applicant’s claim for priority based on applications filed on March 17, 2023(PCT/EP2023/056915) and March 29, 2022 (SE 2250386-6).
Information Disclosure Statement
4. The information disclosure statement (IDS) submitted on 10/09/24 and 09/10/24 has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Form PTO-1449 is signed and attached hereto.
Claim Rejections - 35 USC § 103
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
6. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103(a) 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.
7. Claims 1-19 and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over GUPTA (US 20210037007 A1) (hereinafter GUPTA) in view of Baskaran (US 20250167994 A1) (hereinafter Baskaran).
Regarding claim 1, GUPTA discloses a method performed by a first wireless device (WD), for accessing a service Application Programming Interface (API) the method (para 46, FIG. 1, on-boarding device 100a within a PLMN domain interacts with CAPIF server 300, The on-boarding device 100b from PLMN domain interacts with the CAPIF server 300 via CAPIF-1e and CAPIF-2e. The API exposing function, the API publishing function and API management function of API provider domain, para 158, The transceiver 1410 transmit or receive a signal through a wireless) comprising:
sending over a first interface, to a core network, control information comprising an indication that the first wireless device intends to access the service API (para 01, on-boarding of application programming interface (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server, para 47, method includes sending, by on-boarding device, an onboard API request to the CCF using the TLS session to on-boarding device, para 63, ecure service provision engine 110c is configured to send onboard API request to CCF server 300 to onboard API 110a.),
- receiving over the first interface, from the core network, access information required to access the service API (para 55, The CCF server 300 receives the onboard API invoker request and the CCF server 300 is configured to validate the at least one of the symmetric key-pair, the client certificate, and the enrollment information, para 59, processor 110 is configured to receive the onboard API invoker response comprising the API invoker profile from the CCF server 300).
GUPTA specifically fails to disclose upon determining to use the service API, performing over a second interface, based on the access information, a service API onboarding procedure.
In analogous art, Baskaran discloses upon determining to use the service API, performing over a second interface, based on the access information, a service API onboarding procedure (para 07, API provider of the wireless network, receiving an enrollment response associated with the CCF of the wireless network, and perform an onboarding procedure for onboarding CCF of the wireless network, para 35, PI system 120 to enable the API invoker 116 to perform API invocations 122 to invoke APIs 124 exposed or managed by API system 120, para 59, authorization verification for the API invoker upon accessing service API 220; controlling service API 220 access based on PLMN operator configured policies; logging service API 220 invocations).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify teaching of system for secure on-boarding of application programming interface (API) of on-boarding devices to Common API Framework (CAPIF) Core function (CCF) server disclosed by GUPTA to enable real-time user consent driven API invocation authorization and secured user service by network as taught by Baskaran to include API (UE) authenticated and authorized to access or register with a common API framework (CAPIF) function to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network [Baskaran, para 05].
Regarding claim 2, GUPTA discloses the method according to claim 1, wherein the service API is an API of a core network node (para 01, application programming interface (API) invoker of on-boarding devices to a Common API Framework (CAPIF) core function (CCF) server, para 160, transceiver to transmit to CAPIF core function, an onboard API request message and to receive an onboard API response message based on validating onboarding credential at CAPIF core function).
Regarding claim 3, GUPTA discloses the method according to claim 1, wherein the first interface is a control channel (para 07, establish a secure session with the CAPIF core function based on the onboarding information and control the transceiver to transmit, to the CAPIF core function, para 78, On-boarding device 100 and CCF server 300 establishes the secure communication channel).
Regarding claim 4, GUPTA discloses the method according to claim 1,wherein the second interface is an established data connection with the core network node (Fig. 2, para 07, establish secure session with CAPIF core function based on onboarding information, para 21, FIG. 13 established connection between API and CCF for secure on-boarding of the API, para 24, onboarding information including an onboarding credential and information of a CAPIF core function, establish a secure session).
Regarding claim 5, GUPTA discloses the method according to claim 1,wherein a communication over the first interface uses a lower protocol layer than a communication over the second interface (para 111, using security mechanism specific to protocol (TLS carrying information), para 148, API and CCF server 300 establishes secure communication channel (using communication protocol security mechanism, para 47, establishing, by on-boarding device, a TLS session and sending API request to the CCF using the TLS session).
Regarding claim 6, GUPTA discloses the method according to claim 1,wherein the control information comprises one or more of; an identifier identifying the first WD and information identifying the service API that the first wireless device intends to access (para 90, The on-boarding process involves obtaining, from CAPIF server 300, identifier (ID) of On-boarding device 100, authentication information, para 108, API 110a uses on-boarding information to identify and communicate with CCF server 300).
Regarding claim 7, GUPTA discloses the method according to claim 1,wherein the control information is comprised in a registration request message (para 44, API framework to support 3GPP Northbound APIs with common functional aspects such as authentication, authorization, discovery, registration, monitoring etc.).
Regarding claim 8, GUPTA discloses the method according to claim 1,wherein the access information comprises one or more of authorization information, authentication information, an address to a service API controlling node and a fully qualified domain name, FQDN, for the service API controlling node (para 20, FIG. 12 certificate based authentication between the API and CCF for on-boarding of API, para 46, on-boarding device 100a within PLMN trust domain interacts with CAPIF server 300 . The on-boarding device 100b from PLMN domain interacts. The API exposing function, API publishing function and API management function of API provider domain (API provider domain functions) within PLMN).
Regarding claim 9, GUPTA discloses the method according to claim 1,wherein the method comprises: performing over the second interface, an authorization procedure for authorizing the first wireless device to use the service API (para 07, API performing an onboarding including an onboarding credential and information of a CAPIF core function, establish a secure session with the CAPIF core function based on the onboarding information, para 37, a method of performing an on-boarding, by an API, obtaining, from a service provider, onboarding information including an onboarding credential and information of a CAPIF core function, para 27, onboard API invoker response message may include an assigned API ID, authentication and authorization information and API certificate).
Regarding claim 10, GUPTA discloses the method according to claim 1,herein performing the authorization procedure (para 46, FIG. 1, on-boarding device 100a within a PLMN domain interacts with CAPIF server 300, The on-boarding device 100b from PLMN domain interacts with the CAPIF server 300 via CAPIF-1e and CAPIF-2e. The API exposing function, the API publishing function and API management function of API provider domain, para 158, The transceiver 1410 transmit or receive a signal through a wireless, para 27, onboard API invoker response message may include an assigned API ID, authentication and authorization information and API certificate) comprises:
- sending to the core network, an authorization request message to use the service API (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server, para 47, method includes sending, by on-boarding device, an onboard API request to the CCF using the TLS session to on-boarding device, para 63, secure service provision engine 110c is configured to send onboard API request to CCF server 300 to onboard API 110a),
wherein the authorization request message comprises authentication information for authenticating the first wireless device (para 01, on-boarding of application programming interface, para 46, on-boarding device 100a within PLMN trust domain interacts with CAPIF server 300 . The on-boarding device 100b from PLMN domain interacts. The API exposing function, API publishing function and API management function of API provider domain (API provider domain functions) within PLMN, para 34, in response to a validation of the on-boarding credential being successful, generate an API profile including authentication and authorization information).
GUPTA specifically fails to disclose upon the wireless device being authorized to use the service API, receiving- from the core network, an authorization accept message.
In analogous art, Baskaran discloses upon the wireless device being authorized to use the service API, receiving- from the core network, an authorization accept message (para 07, API provider of the wireless network, receiving an enrollment response associated with the CCF of the wireless network, and perform an onboarding procedure for onboarding CCF of the wireless network, para 35, PI system 120 to enable the API invoker 116 to perform API invocations 122 to invoke APIs 124 exposed or managed by API system 120, para 59, authorization verification for the API invoker upon accessing service API 220; controlling service API 220 access based on PLMN operator configured policies; logging service API 220 invocations).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify teaching of system for secure on-boarding of application programming interface (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server disclosed by GUPTA to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network as taught by Baskaran to include an API (UE) can be authenticated and authorized to access or register with a common API framework (CAPIF) function to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network [Baskaran, para 05].
Regarding claim 11, GUPTA discloses the method according to claim 10, wherein sending-comprises sending the authorization request to a service API controlling node, and wherein receiving comprises receiving the authorization accept message from the service API controlling node (para 36, The onboard API invoker response message may include an assigned API invoker ID, authentication and authorization information and API certificate, para 55, The CCF server 300 receives the onboard API invoker request and CCF server 300 is configured to validate the at least one of the symmetric key-pair, client certificate, and enrollment information, para 59, processor 110 to receive onboard API response comprising the API profile from CCF server 300. para 46, on-boarding device 100a within PLMN trust domain interacts with CAPIF server 300 . The on-boarding device 100b from PLMN domain interacts. The API exposing function, API publishing function and API management function of API).
Regarding claim 12, GUPTA discloses the method according to claim 1,wherein the method comprises: establishing a data connection to the core network via the first interface (Fig. 2, para 07, establish secure session with CAPIF core function based on onboarding information, para 21, FIG. 13 established connection between API and CCF for secure on-boarding of the API).
Regarding claim 13, GUPTA discloses the method according to claim 1,wherein the method comprises: upon successfully finalizing the API on boarding procedure, sending, to the core network, a message using the service API. to the core network via the first interface (para 01, on-boarding of application programming interface (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server, para 47, method includes sending, by on-boarding device, an onboard API request to the CCF using the TLS session to on-boarding device, para 63, secure service provision engine 110c send onboard API request to CCF server 300 to onboard API 110a).
Regarding claim 13, GUPTA discloses the method according to claim 1,wherein the service API is a service API for positioning of wireless devices (para 78, On-boarding device 100 and CCF server 300 establishes the secure communication channel, para 148, API and CCF server 300 establishes secure communication channel (using communication protocol security mechanism).
Regarding claim 15, GUPTA discloses fails to the method according to claim 13,wherein the message is a positioning request for a plurality of second wireless devices.
In analogous art, Baskaran discloses the method according to claim 13,wherein the message is a positioning request for a plurality of second wireless devices (para 07, API provider of the wireless network, receiving an enrollment response associated with the CCF of the wireless network, and perform an onboarding procedure for onboarding CCF of the wireless network, para 254, implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify teaching of system for secure on-boarding of application programming interface (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server disclosed by GUPTA to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network as taught by Baskaran to include wireless communication at a device (e.g., UE), which includes receiving authentication/authorization request for authenticating/authorizing an API to onboard with a CCF of a wireless network, the authentication/authorization request including a UE identifier for the API and a CCF identifier for the CCF of the wireless network, deriving, based on the CCF identifier, [Baskaran, para 09].
Regarding claim 16, GUPTA discloses a method performed by a first core network node, for enabling a wireless device to access a service Application Programming Interface API of a core network (para 46, FIG. 1, on-boarding device 100a within a PLMN domain interacts with CAPIF server 300, The on-boarding device 100b from PLMN domain interacts with the CAPIF server 300 via CAPIF-1e and CAPIF-2e. The API exposing function, the API publishing function and API management function of API provider domain, para 158, The transceiver 1410 transmit or receive a signal through a wireless), the method comprising:
- receiving, from a wireless device, control information comprising an indication that the wireless device intends to access the service API (para 55, The CCF server 300 receives the onboard API invoker request and the CCF server 300 is configured to validate the at least one of the symmetric key-pair, the client certificate, and the enrollment information, para 59, processor 110 is configured to receive the onboard API invoker response comprising the API invoker profile from CCF server 300),
- performing, based on the control information, a first authorization validation with a second core network node, for authorizing the wireless device to access the service API (para 07, API performing an onboarding including an onboarding credential and information of a CAPIF core function, establish a secure session with CAPIF core function based on onboarding information, para 37, method of performing on-boarding, by API, obtaining, from service provider, onboarding information including onboarding credential and information of CAPIF core function, para 45, on-boarding process obtaining an ID of the API, authentication information, authorization information etc.,).
GUPTA specifically fails to disclose upon the wireless device being authorized to access the service API, transmitting, to the wireless device, access information required to access the service AP.
In analogous art, Baskaran discloses upon the wireless device being authorized to access the service API, transmitting, to the wireless device, access information required to access the service AP (para 07, API provider of the wireless network, receiving an enrollment response associated with the CCF of the wireless network, and perform an onboarding procedure for onboarding CCF of the wireless network, para 35, PI system 120 to enable the API invoker 116 to perform API invocations 122 to invoke APIs 124 exposed or managed by API system 120, para 59, authorization verification for the API invoker upon accessing service API 220; controlling service API 220 access based on PLMN operator configured policies; logging service API 220 invocations).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify teaching of system for secure on-boarding of application programming interface (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server disclosed by GUPTA to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network as taught by Baskaran to include UE identifier for API, sending authentication function of wireless network, an authentication/authorization request that includes UE identifier and a CCF identifier for CCF of the wireless network, receiving, from the authentication entity, an authentication/authorization response including key data for the CCF of the wireless network, and sending, to the API invoker, an enrollment response that includes an indication that the API invoker is successfully enrolled for onboarding with the CCF of the wireless network, [Baskaran, para 08].
Regarding claim 17, GUPTA discloses the method according to claim 16, wherein the control information comprises one or more of an identifier identifying the wireless device and information identifying the service API that the first wireless device intends to access (para 90, The on-boarding process involves obtaining, from CAPIF server 300, identifier (ID) of On-boarding device 100, authentication information, para 108, API 110a uses on-boarding information to identify and communicate with CCF server 300).
Regarding claim 18, GUPTA discloses the method according to claim 16,herein the control information is comprised in a registration request message (para 44, API framework to support 3GPP Northbound APIs with common functional aspects such as authentication, authorization, discovery, registration, monitoring etc.).
Regarding claim 19, GUPTA discloses the method according to claim 16,herein the access information comprises one or more of authorization information, authentication information, an address to a service API controlling node, and a fully qualified domain name(FQDN)or the service API controlling node node (para 46, on-boarding device 100a within PLMN trust domain interacts with CAPIF server 300 . The on-boarding device 100b from PLMN domain interacts. The API exposing function, API publishing function and API management function of API provider domain (API provider domain functions) within PLMN, para 57, digitally signed by the service provider or a CAPIF certificate authority or a trusted certificate authority, and authentication and authorization information for allowed service APIs).
Regarding claim 22, GUPTA discloses a method performed by a second core network node, for enabling a wireless device to access a service Application Programming Interface (API) of a core network (para 46, FIG. 1, on-boarding device 100a within a PLMN domain interacts with CAPIF server 300, The on-boarding device 100b from PLMN domain interacts with the CAPIF server 300 via CAPIF-1e and CAPIF-2e. The API exposing function, the API publishing function and API management function of API provider domain, para 158, The transceiver 1410 transmit or receive a signal through a wireless), the method comprising:
- receiving, from a first core network node, a first authorization validation request message, for authorizing the wireless device to access the service API, the first authorization validation request message comprising control information (para 55, The CCF server 300 receives the onboard API invoker request and the CCF server 300 is configured to validate the at least one of the symmetric key-pair, the client certificate, and the enrollment information, para 59, processor 110 is configured to receive the onboard API invoker response comprising the API invoker profile from the CCF server 300, para 37, a method of performing an on-boarding, by an API, obtaining, from a service provider, onboarding information including onboarding credential and information of a CAPIF core function, para 77, On-boarding device 100 to authenticate and communicate with CCF server 300),
- validating, based on the control information, whether the wireless device is authorized to access the service API (para 44, API framework to support 3GPP Northbound APIs with common functional aspects such as authentication, authorization, discovery, registration, monitoring etc., Abstract, onboard API request message along with onboarding credential and to receive onboard API response message based on a result of validating onboarding credential at CAPIF core function, para 34, in response to a validating of on-boarding credential being successful, generate API profile including authentication and authorization information, para 78, TLS connection provides authentication based on the CCF certificate i.e., certificate based authentication).
GUPTA specifically fails to disclose upon the wireless device being authorized to access the service API, transmitting, to the first core network node, access information required to access the service API.
In analogous art, Baskaran discloses upon the wireless device being authorized to access the service API, transmitting, to the first core network node, access information required to access the service API (para 07, API provider of the wireless network, receiving an enrollment response associated with the CCF of the wireless network, and perform an onboarding procedure for onboarding CCF of the wireless network, para 35, PI system 120 to enable the API invoker 116 to perform API invocations 122 to invoke APIs 124 exposed or managed by API system 120, para 59, authorization verification for API upon accessing service API 220; controlling service API 220 access based on PLMN operator policies; logging service API 220 invocations).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify teaching of system for secure on-boarding of application programming interface (API) of on-boarding devices to a Common API Framework (CAPIF) Core function (CCF) server disclosed by GUPTA to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network as taught by Baskaran to include an API (UE) can be authenticated and authorized to access or register with a common API framework (CAPIF) function to enable real-time user consent driven API invocation authorization and secured user service data exposure by a network [Baskaran, para 05].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mirza Alam whose telephone number is (469) 295-9286. The examiner can be reached on Monday-Thursday 7:30AM-6:00PM (EST).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Steven Lim can be reached on 571-270-1210. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for Published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MIRZA F ALAM/Primary Examiner, Art Unit 2688
Prosecution Insights