DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The present application, filed on March 10, 2025, is accepted.
Claims 1 – 5, 7 – 10, 12 – 18, 20, 22, 26 and 29 are being considered on the merits.
Drawings
The drawings, filed on March 10, 2025, are accepted.
Specification
The specification, filed on March 10, 2025, is accepted.
Double Patenting
No rejection warranted at application’s initial filling time of filling for a patent.
Claim Objections
Claim 8 is objected to because of the following informalities:
Claim 8 is being dependent on claim 6 which is cancelled. For the purpose of examination, the claim 8 is being dependent on claim 5. Appropriate correction is required.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 – 5, 7 – 10, 12 – 18, 20, 22, 26 and 29 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 20220217178 A1 to Rajadurai et al., (hereinafter, “Rajadurai”).
As per claim 1, Rajadurai teaches an application programming interface (API) invoking method, executed by an API exposing function (AEF) entity, comprising: receiving an API invoking request sent by an API invoking entity, [Rajadurai, para. 16 discloses receiving a service API access request from the at least one API invoker along with an access token] wherein the API invoking request comprises API invoking information and a user resource access token; [Rajadurai, para. 16 discloses wherein the access token is generated by the CCF on receiving a OAuth based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-le interface. Para. 51 discloses a mutual authentication based on a client and server certificates shall be performed between the API invoker 102 and the AEF 108 to establish a secure TLS connection with the help of CCF 106. Here, the API invoker 102 is pre-configured or provisioned by the CCF 106 or during a service discovery and obtains an information that is required for a particular service API. Here, a request needs to be made directly with the AEF 108 without contacting the CCF 106, provided the determined security method for the service and related valid security credentials are available with the API invoker 102. Further, the AEF 108 may not depend on the CCF to authenticate the API invoker (for example, if the root certificate 106 to authenticate the API invoker 102 is pre-provisioned/available with the AEF 108).] and performing API invoking authentication based on the API invoking information and the user resource access token. [Rajadurai, para. 16 discloses authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker. Para. 51 discloses After a successful establishment of the secure TLS connection on the CAPIF-2e between the API Invoker 102 and the AEF 108. The AEF 108 requests the API Invoker's 102 authorization rights from the CCF 106 over the CAPIF-3 reference point. Further, the CCF 106 responds with the API Invoker's 102 authorization rights over the CAPIF-3. Further, on establishing the secure TLS connection over the CAPIF-2e interface, the API Invoker 102 invokes applicable 3GPP northbound APIs/service API. Further, the AEF 108 honor's the API invocations based on the authorization rights of the API Invoker 102.]
As per claim 2, Rajadurai teaches the method according to claim 1, wherein the API invoking request further comprises an API access token. [Rajadurai, para. 17 discloses wherein the access token is generated by the CCF on receiving a OAuth 2.0 based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface.]
As per claim 3, Rajadurai teaches the method according to claim 2, wherein the user resource access token and the API access token are a same token. [Rajadurai, para. 93 discloses the details about the AEF 108 are provided to the API Invoker 102 by the CCF 106, in response to the API Invoker 102 service discovery request. The details of the AEF 108 includes, the security parameters (like, Authentication method, Root certificate of the CA to verify AEF Certificate, Token, lifetime of the security credentials (Token)) and access method (CAPIF based (authentication with CCF before service request) using TLS-PSK or TLS-certificate or Access Token based or TLS-public key cryptography), Third Party Token based). In another embodiment, the API Invoker 102 may include its preference on the Authentication method, (for example, based on the foreseen frequency of the service requests) in the service discovery request.]
As per claim 4, Rajadurai teaches the method according to claim 1, wherein the API invoking information comprises one or more of: a first identity of the API invoking entity; [Rajadurai, para. 48 discloses the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API invoker 102 or presenting the valid security token (OAuth).] a first resource owner identity; [Rajadurai, para. 48 discloses the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API Invoker 102 or presenting a valid security token.] an identifier of a serving API to be invoked; [Rajadurai, para. 48 discloses the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API invoker 102 or presenting the valid security token (OAuth).] an identifier of a service to be invoked; or an identifier of a user resource to be accessed. [Rajadurai, para. 48 discloses there is an authorization and verification for the API invoker upon accessing the service API.]
As per claim 5, Rajadurai teaches the method according to claim 1, wherein the user resource access token comprises one or more of: a common application programming interface framework (CAPIF) core function identity; [Rajadurai, para. 49 discloses s establishing by the CCF 106 a secure connection with at least one API invoker 102, on receiving a connection request from the at least one API invoker 102 to access the at least one service API on the CAPIF-2e interface.] an authorization function identity; an identity of the AEF entity; a second identity of the API invoking entity; [Rajadurai, para. 49 discloses the method includes determining by the CCF 106, at least one security method to be used by the at least one API invoker 102 for the C2eIS (i.e., authentication, interface protection and authorization) of the at least one API invoker 102 for accessing the at least one service API on the CAPIF-2e interface. The at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI),an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth.] a second resource owner identity; a user resource identifier; expiration time; [Rajadurai, para. 49 discloses the at least one security method is determined based on at least one of a type of service the API invoker 102 is subscribed, a type Interface between the AEF 108 and the API Invoker 102, access scenarios, length of a secure Transport layer security (TLS) sessions required, a capability of the API Invoker 102, capability of the AEF 108, preferences of the API Invoker 102 and a negotiation between the at least one API invoker 102 and the CCF 106. In an embodiment, the at least one determined security method is also indicated, either solicited or unsolicited, by the CCF 106 to the AEF 108 to perform the determined security method on the CAPIF-2e interface.] an identifier of a serving API; or a service identifier. [Rajadurai, para. 49 discloses the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI),an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth.]
As per claim 7, Rajadurai teaches the method according to claim 1, wherein the performing the API invoking authentication based on the API invoking information and the user resource access token comprises: performing user resource access authentication on the API invoking request based on the user resource access token; [Rajadurai, para. 16 discloses authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker.] performing the API invoking authentication on the API invoking request by invoking a CAPIF core function or an authorization function; [Rajadurai, para. 12 discloses the method includes establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface, wherein establishing the secure connection between the CCF and the at least one API invoker based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface.] and in a case that the user resource access authentication and the API invoking authentication are both successful, determining that the API invoking request is authenticated. [Rajadurai, para. 17 discloses receiving a service API access request from the at least one API invoker along with an access token, wherein the access token is generated by the CCF on receiving a OAuth 2.0 based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface. Further, authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker.]
As per claim 8, Rajadurai teaches the method according to claim 6, wherein the performing the API invoking authentication based on the API invoking information and the user resource access token comprises: performing user resource access authentication and the API invoking authentication on the API invoking request based on the user resource access token; [Rajadurai, para. 16 discloses authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker.] and in a case that the user resource access authentication and the API invoking authentication are both successful, determining that the API invoking request is authenticated. [Rajadurai, para. 48 discloses the system 100 provides authorization for the API Invoker prior to accessing one or more service API's. For the CAPIF-2/2e between the API Invoker 102 and the AEF 108, the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API invoker 102 or presenting the valid security token (OAuth). Further, the system 100 provides authorization for the API invoker 102 prior to accessing the service API. Further, there is an authorization and verification for the API invoker upon accessing the service API.]
As per claim 9, Rajadurai teaches the method according to claim 2, wherein the performing the API invoking authentication based on the API invoking information and the user resource access token comprises: performing user resource access authentication on the API invoking request based on the user resource access token; [Rajadurai, para. 16 discloses receiving a service API access request from the at least one API invoker along with an access token, wherein the access token is generated by the CCF on receiving a OAuth based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-le interface.] performing the API invoking authentication on the API invoking request based on the API access token; [Rajadurai, para. 49 discloses a method and system 100 for authenticating the API invokers using the CAPIF, the method includes establishing by the CCF 106 a secure connection with at least one API invoker 102, on receiving a connection request from the at least one API invoker 102 to access the at least one service API on the CAPIF-2e interface. The secure connection is established between the CCF 106 and the at least one API invoker 102 is based on a mutual authentication between the CCF 104 and the at least one API invoker 102 over the CAPIF-le interface.] and in a case that the user resource access authentication and the API invoking authentication are both successful, determining that the API invoking request is authenticated. [Rajadurai, para. 16 discloses authorizing the at least one API invoker to access the at least one service API based on the received access token from the at least one API invoker.]
As per claim 10, Rajadurai teaches the method according to claim 1, further comprising at least one of: sending an API invoking response to the API invoking entity; [Rajadurai, para. 12 discloses establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface,] or performing mutual identity authentication with the API invoking entity. [Rajadurai, para. 12 discloses wherein establishing the secure connection between the CCF and the at least one API invoker based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface.]
As per claim 12, Rajadurai teaches the method according to claim 10, wherein the method further comprises: performing the mutual identity authentication with the AEF entity, [Rajadurai, para. 12 discloses wherein establishing the secure connection between the CCF and the at least one API invoker based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface.] and the mutual identity authentication is performed with the API invoking entity with any one of the following authentication mechanisms: transport layer security-pre-shared key (TLS-PSK); public key infrastructure (PKI); an open authorization (OAuth) license; [Rajadurai, para. 18 discloses the CCF configured to determine at least one security method to be used by the at least one API invoker for a C2eIS of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth 2.0.] a general bootstrapping architecture (GBA)-based authentication mechanism; [Rajadurai, para. 57 discloses the CAPIF-1e security mechanism can be used to “bootstrap” a key for authenticating the secure TLS connection for the CAPIF-2e. In the absence of the PSK, certificate based mutual authentication between the API invoker 102 and AEF 108 can be used to establish the secure TLS session over the CAPIF-2e interface.] an application layer authentication and key management (AKMA)-based authentication mechanism; or a license-based authentication mechanism. [Rajadurai, para. 18 discloses the CCF configured to determine at least one security method to be used by the at least one API invoker for a C2eIS of the at least one API invoker for accessing the at least one service API on a CAPIF-2e interface, wherein the at least one security method includes at least one of a Transport Layers Security -Pre-Shared Key (TLS-PSK), a TLS-Public Key Infrastructure (TLS-PKI), an Internet Key Exchange version 2 (IKEv2), an Internet Protocol Security (IPsec), an application layer protection, a native authorization mechanism and an OAuth 2.0.]
As per claim 13, Rajadurai teaches the method according to claim 10, further comprising: performing the mutual identity authentication with the AEF entity; [Rajadurai, para. 12 discloses wherein establishing the secure connection between the CCF and the at least one API invoker based on a mutual authentication between the CCF and the at least one API invoker over a CAPIF-1e interface.] and in response to the mutual identity authentication being successful, establishing a secure connection between the AEF entity and the API invoking entity. [Rajadurai, para. 48 discloses the CAPIF-1/1-e between the API Invoker 102 and the CCF 106. Further, the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API Invoker 102 or presenting a valid security token. There is a mutual authentication between the API Invoker and the CCF. Further, the system 100 provides authorization for the API Invoker prior to accessing one or more service API's. For the CAPIF-2/2e between the API Invoker 102 and the AEF 108, the system 100 authenticates the API Invoker 102 based on the identity and credentials of the API invoker 102 or presenting the valid security token (OAuth).]
As per claim 14, Rajadurai teaches an API invoking method, executed by an API invoking entity, comprising: sending an API invoking request to an AEF entity, [Rajadurai, para. 16 discloses receiving a service API access request from the at least one API invoker along with an access token,] wherein the API invoking request comprises API invoking information and a user resource access token. [Rajadurai, para. 16 discloses wherein the access token is generated by the CCF on receiving a OAuth based access token request from the at least one API invoker after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-le interface.]
Regarding claim 15 – 18, they recite features similar to features within claims 2 – 5, therefore, they are rejected in a similar manner.
Regarding claim 20, it recites features similar to features within claim 10, therefore, it is rejected in a similar manner.
Regarding claim 22, it recites features similar to features within claims 12 – 13, therefore, it is rejected in a similar manner.
Regarding claim 26, it recites features similar to features within claim 1, therefore, it is rejected in a similar manner.
Regarding claim 29, it recites features similar to features within claim 14, therefore, it is rejected in a similar manner.
Conclusion
Pertinent prior art made of record however not relied upon:
US 11277267 B2 to Smolny et al.
“A computer-implemented method for a token-based authorization in a data processing environment may be provided. The data processing environment comprises at least a user system, an application, an authentication server and an access control server. The method comprises accessing the application via a user system request, redirecting the user access request to an authentication server, authenticating the user, wherein authentication credentials comprise a request for a restricted entitlement, wherein the restricted entitlement represents a subset of existing entitlements managed by the access control server for a resource. The method comprises also sending an access token from the authentication server to the application, requesting execution of an operation comprising invoking the operation by the application providing the access token comprising restricted entitlements, invoking the access control server, and providing the scope of the token comprising the subset of the existing entitlements.”
US 11178128 B2 to Poschel et al.
“Certain aspects involve facilitating the integration of sensitive data from a data provider into an instance of a web-based, third-party application. For example, a data provider service can receive an authentication API call from a third-party system. The authentication API call can include a user identifier and a request for an access token usable by a web-based interface of the third-party system. The data provider service can generate an access token for the third-party system from which the authentication API call is received. The data provider service can subsequently receive, from the user device, a feature API call including the access token and a feature request for sensitive data. The data provider service can generate output data specific to the user identified by the access token included in the feature API call. The data provider service can provide the output to the user device via the web-based interface.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12: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, Linglan Edwards can be reached at (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights