DETAILED ACTION
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 .
Preliminary amendments were submitted on 1/27/25. Amended claims 1-4, 7, 12, 14-16, 18-21, 23, 25, and 29-33 are pending and were examined.
Information Disclosure Statement
The IDS’s received on 1/27/25, 9/21/25, and 8/26/26 were considered.
Claim Rejections - 35 USC § 102
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.
Claim(s) 1-3, 7, 14-15, 19, 21, 23, 25, 29-32 is/are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Rajadurai et al (US 2019/0149576).
Claim 1:
Rajadurai discloses:
sending to a Common API Framework (CAPIF) authentication/authorization function a first token request message configured to request a token, wherein the token is configured to authorize the API invoker to obtain, modify or set a target resource of a target resource owner (paragraphs 12 and 16-18 and Fig 2; An API invoker performs certificate based mutual authentication;
receiving a token response message sent by the CAPIF authentication/authorization function, wherein the token is carried in the token response message (paragraphs 12 and 16-18 and Fig 2);
sending a service API invocation request message to an API Exposure Function (AEF) based on the token (paragraphs 12,16-18, and 109-110 and Fig 2; As per paragraph 110, the embodiments (including the ones based on token based mutual authentication) can be implemented in a network exposure function, which would utilize an API Exposure Function); and
receiving a service API invocation response message returned by the AEF, wherein the target resource is carried in the service API invocation response message (paragraphs 12,16-18, and 109-110 and Fig 2).
Claim 2:
Rajadurai further discloses wherein the first token request message comprises at least one of: an identity of the API invoker; an identity of the target resource owner; an identity of the target resource; an identity of a service API requested by the API invoker; an identity of a service requested by the API invoker; or an identity of a service operation requested by the API invoker (paragraphs 48 and 109; Identity of the API invoker).
Claim 3:
Rajadurai further discloses wherein the token comprises at least one of: a token type; an identity of the CAPIF authentication/authorization function; an identity of the API invoker; an identity of an expected service API; an identity of a service requested by the API invoker; an identity of a service operation requested by the API invoker; an identity of the target resource; an identity of the target resource owner; a geographic area where the API invoker is located when accessing the target resource; an identity of the AEF; or a validity expiration time of the token (paragraphs 48 and 109; Identity of the API invoker).
Claim 7:
Rajadurai further discloses wherein the method further comprises: performing mutual authentication with the CAPIF authentication/authorization function; establishing a first secure connection with the CAPIF authentication/authorization function in a case where the mutual authentication with the CAPIF authentication/authorization function is passed; wherein performing the mutual authentication with the CAPIF authentication/authorization function comprises any one of: performing the mutual authentication with the CAPIF authentication/authorization function based on a certificate; performing the mutual authentication with the CAPIF authentication/authorization function based on a Generic Bootstrapping Architecture (GBA)-based authentication mechanism; or performing the mutual authentication with the CAPIF authentication/authorization function based on an Authentication and Key Management for Applications (AKMA)- based authentication mechanism; and wherein sending to the Common API Framework (CAPIF) authentication/authorization function the first token request message configured to request the token comprises: sending the first token request message to the CAPIF authentication/authorization function through the first secure connection (paragraphs 12, 15-18, 42, 48-53, 57-59, 59, 71, and 74).
Claim 14:
Rajadurai discloses:
receiving a first token request message sent by an API invoker, wherein the first token request message is configured to request a token, and the token is configured to authorize the API invoker to obtain, modify or set a target resource of a target resource owner (paragraphs 12 and 16-18 and Fig 2; Mutual authentication using certificate/token;
determining, based on the first token request message, that the API invoker is the target resource owner (paragraphs 12,16-18, and 109-110 and Fig 2); and
sending a token response message to the API invoker, wherein the token is carried in the token response message (paragraphs 12,16-18, and 109-110 and Fig 2).
Claim 15:
The rejection of claim 2 applies, mutatis mutandis, to claim 15.
Claim 19:
The rejection of claim 3 applies, mutatis mutandis, to claim 19.
Claim 21:
Rajadurai further discloses wherein the method further comprises: performing mutual authentication with the API invoker; and establishing a first secure connection with the API invoker in a case where the mutual authentication with the API invoker is passed; wherein performing the mutual authentication with the API invoker comprises any one of: performing the mutual authentication with the API invoker based on a certificate; performing the mutual authentication with the API invoker based on a Generic Bootstrapping Architecture (GBA)-based authentication mechanism; or performing the mutual authentication with the API invoker based on an Authentication and Key Management for Applications (AKMA)-based authentication mechanism (paragraphs 12, 15-18, 42, 48-53, 57-59, 59, 71, and 74).
Claim 23:
Rajadurai further discloses wherein receiving the first token request message configured to request the token sent by the API invoker comprises: when the first secure connection with the API invoker is established, receiving the first token request message sent, through the first secure connection, by the API invoker (paragraphs 16-18).
Claim 25:
Rajadurai discloses:
receiving a service API invocation request message sent by an API invoker (paragraphs 12,16-18, and 109-110 and Fig 2; Mutual authentication request sent by API invoker);
in response to a token being carried in the service API invocation request message, determining a verification result of the token, wherein the token is configured to authorize the API invoker to obtain, modify or set a target resource of a target resource owner (paragraphs 12,16-18, and 109-110 and Fig 2); and
in response to the verification result indicating that the token is valid and information in the service API invocation request message matching information in the token, sendinga service API invocation response message to the API invoker, wherein the target resource is carried in the service API invocation response message (paragraphs 12,16-18, and 109-110 and Fig 2).
Claim 29:
Rajadurai further discloses wherein the method further comprises: in response to the token being not carried in the service API invocation request message, sending a service API invocation rejection message to the API invoker (paragraphs 16-18).
Claim 30:
Rajadural further discloses wherein the method further comprises: determining that first identity information of the API invoker has been authenticated; determining that the verification result indicates that the token is valid; in response to the authenticated first identity information being identical to an identity of the API invoker in the token, and the information in the service API invocation request message failing to match the information in the token, sending a service API invocation rejection message to the API invoker; or in response to the identity of the API invoker in the token being able to be mapped to the authenticated first identity information, and the information in the service API invocation request message failing to match the information in the token, sending the service API invocation rejection message to the API invoker (paragraphs 16-18 and 109-110 and Fig 2).
Claim 31:
Rajadurai further discloses determining that first identity information of the API invoker has been authenticated; in response to the verification result indicating that the token is valid and the information in the service API invocation request message matching the information in the token, sending the service API invocation response message to the API invoker comprises: in response to the authenticated first identity information being identical to an identity of the API invoker in the token, the verification result indicating that the token is valid, and the information in the service API invocation request message matching the information in the token, sending the service API invocation response message to the API invoker; or in response to the identity of the API invoker in the token being able to be mapped to the authenticated first identity information, the verification result indicating that the token is valid, and the information in the service API invocation request message matching the information in the token, sending the service API invocation response message to the API invoker (paragraphs 16-18 and 109-110).
Claim 32:
The rejection of claim 3 applies, mutatis mutandis, to claim 32.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rajadurai et al (US 2019/0149576).
Claim 12:
As per claim 2, Rajadurai does not explicitly disclose wherein sending the service API invocation request message carrying the token to the API Exposure Function (AEF) comprises: establishing a second secure connection with the AEF, and sending, through the second secure connection, the service API invocation request message to the AEF. However, official notice is taken that the limitation was well known in the art before the effective filing date of applicant’s claimed invention. When a first connection between two parties fail for sending messages, network routing protocol often utilizes a second connection in case there is some form of error (either due to congestion or error in the first connection), regardless of whether the connection is secure or unsecure. As such, before the effective filing date of applicant’s claimed invention was made, it would have been obvious to one of ordinary skill in the art to modify Rajadurai’s invention in accordance with the limitations further recited in claim 2. One of ordinary skill in the art would have been motivated to do so because utilizing a secondary connection to send messages/tokens would bypass whatever caused use of the first connection to fail.
Allowable Subject Matter
Claims 4, 16-18, 20, and 33 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PONNOREAY PICH whose telephone number is (571)272-7962. The examiner can normally be reached M-F 9am-5pm EST, 10am-6pm during Daylight Savings Time.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/PONNOREAY PICH/Primary Examiner, Art Unit 2495
