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 .
This office action is in response to communication (preliminary amendments) filed on 03/25/2025.
Status of claims in the instant application:
Claims 1-15, 17-18 and 37-39 are pending.
Claims 16, 19-36 and 40-42 have been canceled.
No new claim has been added.
Claims 2, 3, 15, 37, 38 and 39 have been amended.
Priority
This application is a 371 of PCT/CN2022/122959 filed on 09/29/2022.
Information Disclosure Statement
Information Disclosure Statements (IDS) filed on 03/24/2025 have been considered, and signed copies of the IDS forms have been attached to this office action.
Drawings
Drawings filed on 03/24/2025 have been inspected, and they are in compliance with MPEP 608.02.
Specification
Specification filed on 03/25/2025 has been inspected and it’s in compliance with MPEP 608.01.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 12-13 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2 of copending Application No. 19049297 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application are just broader versions of that of the reference application. Any difference in wording are just mere obvious variations.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Reference Application (19049297)
12. (Original) A method for authorization revocation, performed by an application programming interface (API) invoker, comprising: sending a first authorization revocation request to a common application programming interface framework (CAPIF) core function/authorization function.
1. (Currently Amended) A method for authorization revocation, performed by a User Equipment (UE), and comprising: sending a first revocation request message to a Common Application Program Interface (API) Framework (CAPIF) authentication/authorization function, wherein the first revocation request message is configured to request revocation of a specified authorization, and the specified authorization is an authorization corresponding to a resource, the resource is related to the UE; and receiving a first revocation response message returned by the CAPIF authentication/authorization function, wherein the first revocation response message is configured to indicate that the specified authorization has been revoked.
13. (Original) The method according to claim 12, wherein the first authorization revocation request comprises at least one of: an API invoker identity; a first token that needs to be revoked; or a token type corresponding to the first token that needs to be revoked.
2. (Currently Amended) The method according to claim 1, wherein the first revocation request message comprises at least one of: a token type for which authorization revocation is requested; an identifier of the CAPIF authentication/authorization function that issues a token; an identifier of an API invoker identity (ID); an identifier of a service API, wherein authorization revocation for the service API is requested; an identifier of a service for which authorization revocation is requested; an identifier of a service operation for which authorization revocation is requested; an identifier of a target resource for which authorization revocation is requested; a target resource owner ID; a geographic area for which authorization revocation is requested; an identifier of API Exposing Function(AEF); or an expiration time of authorization information.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that and 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-3, 5, 9, 11, 12, 13, 14, 17, 18, 37, 38 and 39 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pub. No. US 20210320923 A1 to XU; Wenliang (hereinafter “XU”).
Regarding Claim 1. XU discloses A method for authorization revocation, performed by a common application programming interface framework (CAPIF) core function/authorization function (XU, Abstract, Para [0001, 0022, 0081-0082, 0107-0113], FIG. 6 … A method for revoking authorization for an API invoker in a first apparatus. The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier … the present disclosure generally relates to computer and communication technique fields, in particular to methods and apparatus for revoking authorization of an Application Programming Interface (API) invoker … when CAPIF Core function is triggered to revoke authorization of some specified service APIs associated with AEF for an API invoker, CAPIF core function initiates the authorization revocation using e.g. Revoke_Authorization service operation …), comprising:
receiving a first authorization revocation request sent by an application programming interface (API) invoker (XU, Para [0107-0113], FIG. 6: … the method 600, the first apparatus may be an AEF and the second apparatus may be an authorization server. In this situation, the method 600 may include the authorization server receives a request from the AEF for revoking authorization of an API for the API invoker …);
verifying the first authorization revocation request (XU, Para [0001, 0110-0113], FIG. 6: … the request is received, via an HTTP POST message containing the API invoker ID, the AEF identifier and the at least one API identifier … The HTTP POST message further contains a cause for revoking the authorization of the API identified by the at least one API identifier for the API invoker … in response to the request from the AEF, the authorization server may invalidate the authorization of the API indicated by the at least one API identifier with the AEF for the API invoker by modifying the scope field maintained on itself. After the invalidation of the authorization …); and
in response to verification of the first authorization revocation request being passed, revoking a token corresponding to the first authorization revocation request (XU, Para [0009, 0083-0085, 0110-0114, 0048], FIG. 6: … The access token may also be revoked by the client as specified in RFC 7009. The client needs to include the previously received access token in the request and the authorization server will revoke the access token if successful … the authorization server may send a response indicating the result of the invalidation operation to the AEF. If the result of the invalidation operation is positive (i.e., authorization revocation is successful), the AEF will invalidate the authorization of the service API(s) for the API invoker by modifying the scope field maintained on itself … the authorization server may notify the API invoker of revocation of the authorization of API identified by the at least one API identifier with the AEF e.g. when the invalidation of authorization operation is successful … the embodiments of the present disclosure, access token revocation with a finer granularity is achieved. This allows a better control of the access token … the AEF may modify or update the scope field in the claim stored in the local memory of the AEF itself. The scope field contains a list of AEF identifiers and the name list of its associated accessible APIs while the existing access token needs not be changed or updated. In particular, for example, the AEF may remove the API identifiers (revoked by the CAPIF core function) from the API name list associated with the AEF contained in the scope field based on the authorization revocation request …).
Regarding Claim 2. (Currently Amended). XU discloses the method according to claim 1, XU further discloses, “wherein revoking the token corresponding to the first authorization revocation request comprises one of:
revoking the token corresponding to the first authorization revocation request from the CAPIF core function/authorization function; or
revoking the token corresponding to the first authorization revocation request from an API exposure function (XU, Para [0009, 0110-0114, 0048], FIG. 6: … The access token may also be revoked by the client as specified in RFC 7009. The client needs to include the previously received access token in the request and the authorization server will revoke the access token if successful … the authorization server may send a response indicating the result of the invalidation operation to the AEF. If the result of the invalidation operation is positive (i.e., authorization revocation is successful), the AEF will invalidate the authorization of the service API(s) for the API invoker by modifying the scope field maintained on itself … the authorization server may notify the API invoker of revocation of the authorization of API identified by the at least one API identifier with the AEF e.g. when the invalidation of authorization operation is successful … the embodiments of the present disclosure, access token revocation with a finer granularity is achieved. This allows a better control of the access token …).”
Regarding Claim 3 (Currently Amended). XU discloses the method according to claim 1, XU further discloses, “wherein the first authorization revocation request comprises at least one of:
an API invoker identity (XU, Abstract, FIG. 6 … The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID …);
a first token that needs to be revoked; or
a token type corresponding to the first token that needs to be revoked.”
Regarding Claim 5. XU discloses the method according to claim 3, XU further discloses, “wherein revoking the token corresponding to the first authorization revocation request from the API exposure function comprises:
determining a second token that needs to be revoked based on the first token that needs to be revoked and the token type (XU, Para [0007-0011]: … using Authorization Code Grant, Mr. Lee has webchat/weibo account and wants to log on a third-party website. He can authorize the third-party website to use the webchat/weibo system authorized code (which is an access token) … The access token is requested by the client, and it is generated and granted by the authorization server. The authorization server may also generate a refresh token according to different authorization methods …); and
sending a second authorization revocation request to the API exposure function, wherein the second authorization revocation request indicates the API exposure function to revoke the second token that needs to be revoked (XU, Para [0090-0093]: … IG. 5 is a schematic diagram illustrating a method 500 for revoking authorization of an API invoker in a first apparatus according to an embodiment of the present application … The method 500 includes step S501 and step S502. In step S501, a request is sent to a second apparatus for revoking authorization of an API for the API invoker, and the request contains an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier. In step S502, a response to the request is received from the second apparatus … The API invoker ID is used to identify an API invoker which intends to access some specified service API(s). The AEF identifier is used to identify the AEF associated with the service API(s) to be revoked. The API identifier is used to identify the API(s) to be revoked by the API invoker …).”
Regarding Claim 9. XU discloses the method according to claim 5, XU further discloses, “wherein determining the second token that needs to be revoked based on the first token that needs to be revoked and the token type comprises at least one of:
in response to the first token that needs to be revoked being an access token, using the first token that needs to be revoked as the second token that needs to be revoked (XU, Para [0007-0011]: … using Authorization Code Grant, Mr. Lee has webchat/weibo account and wants to log on a third-party website. He can authorize the third-party website to use the webchat/weibo system authorized code (which is an access token) … The access token is requested by the client, and it is generated and granted by the authorization server. The authorization server may also generate a refresh token according to different authorization methods …); or
in response to the first token that needs to be revoked being a refresh token, using an access token corresponding to the first token that needs to be revoked as the second token that needs to be revoked.”
Regarding Claim 11. XU discloses the method according to claim 5, XU further discloses, “further comprising:
receiving a first authorization revocation response fed back by the API exposure function (XU, Para [0105]: … the AEF may send an acknowledge message to the authorization server in response to the request …); and
sending a second authorization revocation response to the API invoker (XU, Para [0106]: … Further, the authorization server may notify the API invoker of revocation of the authorization of API identified by the at least one API identifier with the AEF e.g. when the invalidation of authorization operation is successful on both the authorization server and the AEF …).
Regarding Claim 12. XU discloses A method for authorization revocation, performed by an application programming interface (API) invoker (XU, Abstract, Para [0089-0090], FIG. 5: … A method for revoking authorization for an API invoker in a first apparatus. The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier …), comprising:
sending a first authorization revocation request to a common application programming interface framework (CAPIF) core function/authorization function (XU, Abstract, Para [0089-0096], FIG. 5: … A method for revoking authorization for an API invoker in a first apparatus. The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier … The method 500 includes step S501 and step S502. In step S501, a request is sent to a second apparatus for revoking authorization of an API for the API invoker, and the request contains an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier. In step S502, a response to the request is received from the second apparatus … In the first embodiment of the method, the request may be sent, via an HTTP POST message containing the API invoker ID, the AEF identifier and the at least one API identifier, to an URI on the authorization server … the authorization server could be implemented as a Common API Framework (CAPIF) Core function …).
Regarding Claim 13. XU discloses the method according to claim 12, XU further discloses, “wherein the first authorization revocation request comprises at least one of:
an API invoker identity (XU, Abstract, Para [0090], FIG. 5: … The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID … a request is sent to a second apparatus for revoking authorization of an API for the API invoker, and the request contains an API invoker ID …);
a first token that needs to be revoked; or
a token type corresponding to the first token that needs to be revoked.”
Regarding Claim 14. XU discloses the method according to claim 13, XU further discloses, “wherein sending the first authorization revocation request to the CAPIF core function/authorization function comprises at least one of:
sending the first authorization revocation request to the CAPIF core function/authorization function actively (XU , Para [0089-0096]: … a request is sent to a second apparatus for revoking authorization of an API for the API invoker, and the request contains an API invoker ID … the request may be sent, via an HTTP POST message containing the API invoker ID, the AEF identifier and the at least one API identifier, to an URI on the authorization server … The authorization server could be implemented as a Common API Framework (CAPIF) Core function …);
in response to the CAPIF core function/authorization function or the API exposure function requesting the API invoker to revoke the first token that needs to be revoked, sending the first authorization revocation request to the CAPIF core function/authorization function; or
in response to a resource owner corresponding to the first token that needs to be revoked requesting the API invoker to revoke the first token that needs to be revoked, sending the first authorization revocation request to the CAPIF core function/authorization function.”
Regarding Claim 17. (Original) XU discloses A method for authorization revocation, performed by an application programming interface (API) exposure function (XU, Abstract, Para [0078-0080], FIG. 4 … A method for revoking authorization for an API invoker in a first apparatus. The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier … FIG. 4 is a schematic diagram illustrating an interaction procedure for revoking authorization of API invoker initiated by a CAPIF core Function according to an embodiment of the present application … This service operation (i.e., Revoke_Authorization service operation) is used by CAPIF core function to revoke authorization of service APIs. On receiving the Authorization revocation request, the API exposing function revokes authorization of service APIs for the API invoker …), comprising:
receiving a second authorization revocation request sent by a common application programming interface framework (CAPIF) core function/authorization function, wherein the second authorization revocation request indicates the API exposure function to revoke a second token that needs to be revoked (XU, Abstract, Para [0048, 0078-0082], FIG. 4 … A method for revoking authorization for an API invoker in a first apparatus. The method comprises sending to a second apparatus a request for revoking authorization of an Application Program Interface (API) for the API invoker with an API invoker ID, an API Exposing Function (AEF) identifier and at least one API identifier … According to the embodiments of the present disclosure, access token revocation with a finer granularity is achieved. This allows a better control of the access token. … FIG. 4 is a schematic diagram illustrating an interaction procedure for revoking authorization of API invoker initiated by a CAPIF core Function according to an embodiment of the present application … This service operation (i.e., Revoke_Authorization service operation) is used by CAPIF core function to revoke authorization of service APIs. On receiving the Authorization revocation request, the API exposing function revokes authorization of service APIs for the API invoker … To initiate authorization revocation, the CAPIF core function will send an HTTP POST message to the API exposing function (AEF) with the API invoker ID, a list of service API IDs, and an identifier of the AEF to the URI “{apiRoot}/aef-security/v1/revoke-authorization” …); and
setting the second token that needs to be revoked as invalid (XU, Abstract, Para [0103], FIG. 4 … in response to the request from the authorization server, the AEF may invalidate the authorization of the API indicated by the at least one API identifier with the AEF for the API invoker by modifying the scope field maintained on itself. …).
Regarding Claim 18. (Original) XU discloses the method according to claim 17, XU further discloses, “further comprising:
sending a first authorization revocation response to the CAPIF core function/authorization function (XU, FIG. 4 … Action#4 in FIG. 4 – Response to CAPIF core for AEF …).”
Regarding Claim 37. This claim contains all the same or similar limitations as claim 1, and hence similarly rejected as claim 1.
*** Note: XU also discloses “a processor and a memory storing a computer program, wherein when the computer program is executed by the processor (XU, Para [0044])”.
Regarding Claim 38. This claim contains all the same or similar limitations as claim 12, and hence similarly rejected as claim 12.
*** Note: XU also discloses “a processor and a memory storing a computer program, wherein when the computer program is executed by the processor (XU, Para [0044])”.
Regarding Claim 39. This claim contains all the same or similar limitations as claim 17, and hence similarly rejected as claim 17.
*** Note: XU also discloses “a processor and a memory storing a computer program, wherein when the computer program is executed by the processor (XU, Para [0044])”.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4, 6, 7, 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20210320923 A1 to XU; Wenliang (hereinafter “XU”). in view of Pub. No.: US 20190149576 A1 to RAJADURAI et al. (hereinafter “RAJADURAI”).
Regarding Claim 4. XU discloses the method according to claim 3, however XU does not explicitly teach, but RAJADURAI from same or similar field of endeavor teaches:
“further comprising:
performing mutual authentication with the API invoker (RAJADURAI, Para [0012]: … Accordingly the embodiments herein provide a method and system for authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). 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 response to a successful mutual authentication, establishing a secure connection with the API invoker, and determining the API invoker identity is verified (RAJADURAI, Para [0012-0015, 0048]: … Accordingly the embodiments herein provide a method and system for authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). 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 … enabling the C2eIS by the AEF, for the at least one API invoker based on the determined at least one security method includes establishing a secure Transport layer security (TLS) connection with the at least one API invoker over the CAPIF-2e interface using a pre-shared key (PSK) received from the CCF, if the determined at least one security method is the TLS-PSK, wherein the PSK is derived by at least one of the at least one API invoker and the CCF after establishing the secure TLS connection between the CCF and the at least one API invoker over the CAPIF-1e interface … 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) …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of RAJADURAI into the teachings of XU, because it discloses that, “various embodiments provide a system and a method for establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker over a CAPIF-1e interface, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface (RAJADURAI, Para [0009])”.
Regarding Claim 6. The combination of XU-RAJADURAI discloses the method according to claim 4, XU further discloses, “wherein verifying the first authorization revocation request comprises:
verifying attribution information of the first token that needs to be revoked based on the verified API invoker identity (XU, Para [0081-0084]: … To initiate authorization revocation, the CAPIF core function will send an HTTP POST message to the API exposing function (AEF) with the API invoker ID, a list of service API IDs, and an identifier of the AEF to the URI “{apiRoot}/aef-security/v1/revoke-authorization” … Upon receiving the above described HTTP POST message, the API exposing function will revoke the authorization for the service APIs identified by the list of service API IDs associated with the API invoker indicated by the API invoker ID, and then respond the CAPIF core function with 200 OK status code if the authorization revocation is successful …This custom authorization revocation operation allows the CAPIF core function to request the API exposing function to revoke the authorization of service APIs for an API invoker …);
verifying a validation of the first token that needs to be revoked (XU, Para [0007-0009]: … The access token may also be revoked by the client as specified in RFC 7009. The client needs to include the previously received access token in the request and the authorization server will revoke the access token if successful …); and
in response to verification of the attribution information and verification of the validation being passed, determining that verification of the first authorization revocation request is passed (XU, Para [0071-0072]: … To invalidate authorization of some service APIs for an API invoker, the API exposing function will send an HTTP POST message to the CAPIF core function with the API invoker ID, a list of API identifiers and the identifier of the AEF, to the URI on the CAPIF core function, e.g., “{apiRoot}/capif-security/v1/securities/{securityId}/delete” … Upon receiving the HTTP POST message, the CAPIF core function will revoke the authorization of some service APIs (associated with the AEF) identified by the list of API identifiers for the API invoker indicated by the API invoker ID and notify the API invoker of the authorization invalidation using the Notification Destination URI received in the e.g. Obtain_Security_Method message …).”
Regarding Claim 7. The combination of XU-RAJADURAI discloses the method according to claim 6, XU further discloses, “wherein verifying the attribution information of the first token that needs to be revoked based on the verified API invoker identity, comprises at least one of:
in response to the verified API invoker identity being identical to an API invoker identity corresponding to the first token that needs to be revoked, determining that the verification of the attribution information of the first token that needs to be revoked is passed (XU, Para [0137-]: … The embodiments of the disclosure further include … Currently, the AEF_Authentication_API uses standard HTTP GET method for the API invoker to confirm that the AEF has enough authentication information available, which will be used in later API invocation … FIG. 10 shows a procedure for authentication between the API invoker and the AEF prior to service API invocation … Currently, in TS 29.222, such operation is modelled as event notification as part of CAPIF core services and with event name API INVOKER AUTHORIZATION REVOKED …); or
in response to determining that the verified API invoker identity may be mapped to the API invoker identity, determining that the verification of the attribution information of the first token that needs to be revoked is passed.”
Regarding Claim 8. The combination of XU-RAJADURAI discloses the method according to claim 6, RAJADURAI further discloses, “wherein verifying the validation of the first token that needs to be revoked comprises:
verifying the validation of the first token that needs to be revoked using a public key (RAJADURAI, Para [0012-0018]: … the method includes determining by the CCF at least one security method to be used by the at least one API invoker for a CAPIF-2e interface security (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 … 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. Further, the system includes an API exposing function (AEF) configured to enable the C2eIS for the at least one API invoker based on the determined at least one security method …).”
The motivation to further combine RAJADURAI remains same as in claim 4.
Regarding Claim 15. (Currently Amended) XU discloses the method according to claim 12, however XU does not explicitly teach, but RAJADURAI from same or similar field of endeavor teaches. “further comprising at least one of:
performing mutual authentication with the CAPIF core function/authorization function (RAJADURAI, Para [0012]: … Accordingly the embodiments herein provide a method and system for authenticating application program interface (API) invokers using a common application program interface framework (CAPIF). 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 response to a successful mutual authentication, establishing a secure connection with the CAPIF core function/authorization function, and determining the API invoker identity is verified; or
receiving a second authorization revocation response sent by the CAPIF core function/authorization function.”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of RAJADURAI into the teachings of XU, because it discloses that, “various embodiments provide a system and a method for establishing by a CAPIF core function (CCF) a secure connection with at least one API invoker over a CAPIF-1e interface, on receiving a connection request from the at least one API invoker to access at least one service API on a CAPIF-2e interface (RAJADURAI, Para [0009])”.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Pub. No.: US 20210320923 A1 to XU; Wenliang (hereinafter “XU”). in view of Pub. No.: US 20260254804 A1 to CORBEL et al. (hereinafter “CORBEL”).
Regarding Claim 10. XU discloses the method according to claim 1, however XU does not explicitly teach, but CORBE from same or similar field of endeavor teaches:
“further comprising:
in response to verification of the first authorization revocation request being not passed, terminating the revocation procedure (CORBEL, Para [0026-0028]: … cancelling the suspension of said first certification token triggered by obtaining an item of information indicating that said condition for suspending said first certification token is no longer satisfied, transmitting, to said domain name server, a request for cancelling the suspension of said association established between the first certificate, the first certification token and said at least one domain name …).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of CORBEL into the teachings of XU, because it discloses that, “the first certification token associated with the item of equipment is used, for example, when the latter is attached to a home network. When the item of equipment leaves the coverage area of the home network, the first certification token is suspended. When the item of equipment attaches again to the home network, for example when the smartphone user returns home, the suspension of the first certification token can be cancelled, thus allowing the smartphone to access the server of a service provider without having to request a certificate again (CORBEL, Para [0029])”.
Pertinent Prior Arts
The following prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
US 20170134429 A1; GUSTAFSSON; Greger: GUSTAFSSON discloses methods and systems for reliable token revocation at a server are described. The server receives, a token revocation policy, which includes an identification of a set of users for which a set of associated tokens are to be revoked. The server receives, from a first client device, a first request to access resources at the server, the first request including a first token generated at the token authority server for the client device, wherein the first token is associated with a first expiration time interval; and denies access to the resources at the server based on the first token and the token revocation policy, prior to an expiration of the first expiration time interval associated with the first token.
US 20220179721 A1; GE et al.: GE discloses an authorization revocation method and an apparatus and relates to the communications field. An example method includes: receiving, by a first entity, an authorization revocation request message from a second entity, wherein the authorization revocation request message carries an identifier of an application programming interface (API) invocation entity; and sending, by the first entity, an authorization revocation response message to the second entity based on the authorization revocation request message, wherein the authorization revocation response message indicates that authorization revocation succeeds or fails.
US 20210314308 A1; KALANTRI; Saurabh Shriniwas: KALANTRI discloses Identifiers and access tokens for privacy in centralized address management. In an embodiment, address information may be associated with a unique address identifier that can be used in place of the address information. For example, a user may register an address with his or her user account using the address identifier, rather than the address information. In addition, an organization may utilize the address identifier to obtain an access token that enables communication with the user at the associated address information.
US 20210306320 A1; Squire et al.: Squire discloses A client application requesting to access a resource may be issued an access token and a refresh token. Instead of revoking the client application access to a resource by revoking the refresh token, allowing the access token to expire, and forcing a user associated with the client application to re-login, authentication for the client application to access the resource may be obtained from the user. The authentication may be obtained from the user while the client application, without notification of the concurrent authentication, may continue attempts to access the resource, for example, via an invalid access token. Once authentication is obtained, the client application may be provided access to the resource, for example, via a valid access token.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHABUB S AHMED whose telephone number is (571)272-0364. The examiner can normally be reached on 9AM-5PM EST M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached on 571-270-1050. 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 the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MAHABUB S AHMED/Examiner, Art Unit 2434
/TESHOME HAILU/Primary Examiner, Art Unit 2434
Prosecution Insights