DETAILED ACTION
Response to Arguments
Applicant's arguments ("REMARKS") filed 11 March 2026 have been fully considered, and they are partially persuasive as to the previous grounds of rejection.
Claims 1, 4, 6, 9, 12, 14, 17, and 20 were amended. Claims 1, 9, and 17 are independent. Claims 1-20 are currently pending.
Re: Claim Rejections Under 35 U.S.C. §112(b)
The rejection to claims 4-6, 14, and 20 under 35 U.S.C. §112(b) has been withdrawn in view of the amendments indicated on p.11 of the REMARKS.
The amendments to the claims, however, raises new issues under 35 U.S.C. 112(b), as set forth below.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s amendment and arguments, indicated on pp.11-15 of the REMARKS, in response to the rejection of the claims under 35 U.S.C. §103 with respect to Lenglet et al., US 2021/0385083 A1 (hereinafter, “Lenglet ‘083”), Blasi, US 2022/0407850 A1 (hereinafter, “Blasi ‘850”), Holt et al., US 2019/0318115 A1 (hereinafter, “Holt ‘115”), and Leibmann et al., US 2021/0250361 A1 (hereinafter, “Leibmann ‘361”) have been fully considered, and they are partially persuasive as to the previous grounds of rejection. In particular, Applicant argues that:
Lenglet ‘083, Blasi ‘850, Holt ‘115, and Leibmann ‘361 do not disclose independent claims 1, 9, and 17, as amended.
Lenglet ‘083, Blasi ‘850, Holt ‘115, and Leibmann ‘361 do not disclose dependent claims 4, 6, 12, 14, and 20, as amended.
In Response to Argument A
Applicant argues that none of the cited references of Lenglet ‘083, Blasi ‘850, Holt ‘115, and Leibmann ‘361 disclose the independent claims 1, 9, and 17, as amended.
The independent claims were amended to include modified limitations from the original dependent claims 4 and 6. Amended claim 1 now recites the “first client location in a logic system group” limitation of original claim 4, and a modified version of the access-token-copy limitations of original claim 6. Original claim 6 was rejected under 35 U.S.C. 103 over Lenglet ‘083, in view of Blasi ‘850, further in view of Holt ‘115, and further in view of Leibmann ‘361.
Specifically, with respect to the limitation “sending a copy of the access token to a second client location in the logic system group”(original claim 6), Applicant argues that Leibmann ‘361 does not disclose ‘a protected forwarded access pattern where a first service receives an access token issued to a client and forwards this token to a second service or microservice’. Applicant’s arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over further clarifications of and additional citations to Leibmann ‘361. The Examiner has considered Applicant’s arguments and provides the following clarification and supplemental reasoning.
Leibmann ‘361 provides further clarification with respect to the above limitation at ¶33 and ¶¶35-36. Leibmann ‘361 at ¶33, states: “The authorization policy includes a set of authorization grants for protected forwarded access (using a protected forwarded token-or PFT). This type of access pattern is used when a middle tier service or microservice receives an access token issued to a device or web application and forwards this, along with the API request, to the microservice that is ultimately being accessed”.
Leibmann ‘361 at ¶35, further states: “Configuring permissions for an access pattern that is implemented as a protected forward access pattern are permissions that apply to access tokens issued to an application, that are then forwarded by a middle tier service or API. The access grants can include two aspects. One is that they are to accept an access token that was forwarded by a particular service or API …”.
And Leibmann ‘361 at ¶36, sets forth the example: “[A]ssume that the client issues the token to a first service B which forwards the token to service A which then sends the token to the ultimate API or microservice. In such a scenario, the ‘front door service’ is service B and the ‘actor’ is still service A, while the ‘downstream API’ is still the ultimate API or microservice that receives the token”.
Leibmann ‘361 at ¶36, thus describes a first location (service B) sending the access token to a second location (service A), which in turn submits the token to a resource (the downstream API or microservice) associated with that second location (i.e., “sending a copy of the access token to a second client location in the logic system group”).
Applicant next argues, on p.14 of the REMARKS, that: ‘instead of a Key ID, Leibmann ‘361 (specifically in Paragraph [0057]) focuses on extracting different types of metadata from an access token to perform authorization’. This argument is not persuasive because Leibmann ‘361 at ¶57 does not describe access tokens, metadata extraction, or authorization. Leibmann ‘361 at ¶57 of discloses the cloud computing architecture 500 of FIG.4. The App ID extraction Applicant appears to describe is instead disclosed at ¶26 and ¶43 of Leibmann ‘361.
The substance of Applicant’s argument is that Leibmann ‘361 assumes that the token is already valid, that it does not describe any cryptographic validation step where a Key ID would be extracted to look up a public key for signature verification, and that it is therefore directed toward authorization based on identity claims, and does not disclose or suggest the specific limitations now recited in the independent claims.
Firstly, Applicant’s premise that Leibmann ‘361 ‘assumes the token is already valid’ is inaccurate. Leibmann ‘361 at ¶43, states that “[t]he authentication server for the receiving microservice 106 … validates the access token provided by microservice 104”, and that the authorization policy lookup based on the App ID and the access pattern occurs thereafter. Leibmann ‘361 therefore distinguishes token validation from authorization. While Leibmann ‘361 does not go into detail regarding the specific mechanics of the validation step, Lenglet ‘083 is relied upon for those mechanics, as stated below.
Secondly, Applicant’s argument is not persuasive because it is directed to limitations for which Leibmann ‘361 was never relied upon. Leibmann ‘361 is relied upon solely for the limitation “sending a copy of the access token to a second client location in the logic system group”. Applicant’s argument addresses Leibmann ‘361 in isolation, and “[o]ne cannot show non-obviousness by attacking references individually where … the rejections are based on combinations of references.” In re Keller, 642 F.2d 413, 426 (CCPA 1981).
The limitations Applicant identifies, namely the extraction of a key ID, the comparison of the key ID against cryptographic keys previously received at a resource server, and the use of a matching key to verify the token, are disclosed by Lenglet ‘083, as set forth in the previous Office action and as maintained herein. Lenglet ‘083 at ¶26, discloses that “the token issuer 200 includes a key ID 230 within the authentication token 210 that identifies the cryptographic key 220 that the token issuer 200 used to sign the authentication token 210”. Lenglet ‘083 at ¶28 further discloses that “the token authenticator 250 obtains a list of valid key IDs 230 … from the token issuer 200” and “determines whether a cryptographic key 220 used to sign the received authentication token 210 is valid based on the list of valid key IDs 230”. And Lenglet ‘083 at ¶21 and ¶¶28-29, discloses that when the cryptographic key used to sign the token is valid, the token authenticator 250 determines that the token is valid and allows the client 10 access to the resource.
See Claim Rejections – 35 USC §103 below for further details.
In Response to Argument B
Applicant argues that none of the cited references of Lenglet ‘083, Blasi ‘850, Holt ‘115, and Leibmann ‘361 disclose dependent claims 4, 6, 12, 14, and 20, as amended.
As an initial matter, proper support for the amendments to the claims must be identified. Applicant states, on p.13 of the REMARKS, that support for the amendments is found in ¶¶54-65 of the present application. ¶¶54-65, however, is only directed to the amendments to independent claims 1, 9, and 17. Applicant has identified no support for the subject matter newly added to claims 4, 6, 12, 14, and 20 (emphasis added). Amended claims 6, 14, and 20 recite that the second resource server initiates a request with “a second authorization server” for information associated with verifying the access token. ¶64 of the present application states that “the second resource server 272 initiates a request with the authorization server 256”, and ¶65 states that “the authorization server 256 may return a copy of the respective Signer … to the second resource server 272”. Authorization server 256, however, is the same, single authorization server that issued the access token to the first client location 260 (see ¶¶55-58) and that the first resource server 262 queries (see ¶¶60-61). Applicant’s cited support therefore describes the authorization server, not a second one (emphasis added). Claims 6, 14, and 20 are accordingly rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement.
See Claim Rejections – 35 USC §112(a) below for further details, and requests that Applicant identify the support relied upon.
With respect to dependent claims 4, 6, 12, 14, and 20, Applicant’s arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over Kishimoto et al., US 2020/0076791 A1 (hereinafter, “Kishimoto ‘791”) and Kitagata et al., US 2020/0336494 A1 (hereinafter, “Kitagata ‘494”).
With respect to dependent claims 4 and 12, Kishimoto ‘791 discloses the limitations recited in claims 4 and 12, as amended. A resource server 202 holds a public key management table associating Key IDs with public keys obtained from an authentication/authorization server 201 (Kishimoto ‘791, ¶¶47-48, 53). Upon receiving a signed access token, the resource server obtains the KeyID from the header parameter of the token (Kishimoto ‘791, ¶¶38-39, 65). The resource server then queries whether a key matching that KeyID is present, and “[t]he process moves to step S703 if there is no key matching the obtained KeyID” (Kishimoto ‘791, ¶66). At step S703, “the public key management unit 502 makes a request to the authentication/authorization server 201 for obtaining a public key not held by the resource server 202” (Kishimoto ‘791, ¶67). The resource server thereafter verifies the token “by confirming the signature using the public key that matches the KeyID” (Kishimoto ‘791, ¶¶68-69), and provides the requested service if the token is valid (Kishimoto ‘791, ¶61). Kishimoto ‘791 also identifies the specific failure mode that arises from locally cached keys: an access token “signed using a key held by the authorization/authentication server 201 but not held by the resource server 202 … will be determined to be invalid when the signature is verified in the resource server 202, despite the access token actually being valid” (Kishimoto ‘791, ¶¶35-36).
See Claim Rejections – 35 USC §103 below for further details.
With respect to dependent claims 6, 14, and 20, Kitagata ‘494 discloses the limitations recited in claims 6, 14, and 20, as amended. An authentication/authorization server 111 “is a different server from the authentication/authorization server 110, and controls access to a resource server 121”, the two authorization servers being located in different data centers (Kitagata ‘494, ¶¶28, 64). Kitagata ‘494 at ¶58 further discloses that “[t]he public key for verifying the JWS signature is provided in advance in the resource servers 120 and 121 … Although belonging to a different security domain from the authentication/authorization server 110, the resource server 121 holds the public key for verifying the JWS access token. Accordingly, the resource server 121 holding the public key which verifies the JWS access token issued by the authentication/authorization server 110 can be used with that JWS access token”.
See Claim Rejections – 35 USC §103 below for further details.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6, 14, and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As per claims 6, 14, and 20:
Claims 6, 14, and 20, as amended, each recite “… causing the second resource server to initiate a request with a second authorization server for information associated with verifying the access token …”. The term “a second authorization server” constitutes new matter, as the originally filed disclosure does not describe a second authorization server.
The specification describes a single authorization server, namely authorization server 256 of FIG.2B. Authorization server 256 is the server that maintains the lookup table 258 (¶¶56-57), that receives the access token request from the first client location 260 (¶55), and that issues and returns the access token 266 to the first client location 260 (¶58). It is the same authorization server with which the first resource server 262 initiates a request when cryptographic information correlated with the received access token is not identified in local memory (¶60), and that returns a copy of the respective Signer to the first resource server 262 (¶61).
Furthermore, the specification describes the second resource server performing the operation recited in claims 6, 14, and 20 with that same authorization server 256, and not with any second authorization server. For example, ¶64 of the present application states: “However, in situations where cryptographic information correlated with the received access token is not identified in local memory, the second resource server 272 initiates a request with the authorization server 256. See operation 263. The second resource server 272 may send a request to the authorization server 256 for a Signer that is correlated with the received access token. In other words, the second resource server 272 requests cryptographic information from the authorization server 256 that may be used to verify authenticity of the access request received from the second client location 270.”
¶65 of the present application also states: “… in response to determining the received access token and corresponding key ID do match an active entry in lookup table 258, the authorization server 256 may return a copy of the respective Signer (e.g., private and/or public cryptographic keys) to the second resource server 272. Operation 263 may thereby include sharing the public and/or private key(s) 268 that correspond to the received access token.”
¶¶64-65 are the only paragraphs of the specification that describe the second resource server 272 requesting information associated with verifying the access token copy. Both describe that request as being made to the authorization server 256, which is the same authorization server that issued the underlying access token 266 and that maintains the lookup table 258 against which the token and key ID are compared. FIG.2B depicts a single authorization server 256 having a single lookup table 258, serving the first client location 260, the first resource server 262, the second client location 270, and the second resource server 272 alike. The term “second authorization server” does not appear anywhere in the specification as originally filed, and that the specification contains no description of a second, additional, or further authorization server in connection with the operations recited in claims 6, 14, and 20.
Applicant is requested to identify the portion of the originally filed disclosure that provide written description support for “a second authorization server” as recited in claims 6, 14, and 20. It is noted that claims 4 and 12 were amended to recite “the authorization server”, and are supported by ¶¶60-61 of the specification. Claims 4 and 12 are not rejected under 35 U.S.C. 112(a) on this ground.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-6, 14, and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 4, 6, 12, 14, and 20:
Claims 4, 6, 12, 14, and 20 each recite “… causing the [first/second] resource server to use the received cryptographic information to verify …”. The term “the received cryptographic information” renders the claims indefinite as it lacks proper antecedent basis.
As per claims 6, 14, and 20:
Claims 6, 14, and 20 each recite “… causing the second resource server to use the received cryptographic information to verify the access token copy and secondary access request”. The term “secondary access request” renders the claims indefinite as it lacks proper antecedent basis.
No secondary access request, second access request, or any access request other than the “access request” recited in claims 1, 9, and 17 is recited anywhere in the claims. Claims 1, 9, and 17 recite receiving “an access request” at a first client location targeting a first resource server, and further recite “sending a copy of the access token to a second client location in the logic system group”. No request associated with the access token copy, and no request directed to the second resource server, is recited. It is therefore unclear whether “secondary access request” refers to the access request recited in claims 1, 9, and 17, to a distinct request implied by the sending of the access token copy to the second client location, or to some other request altogether.
As per claims 5 and 13:
Claims 4 and 12 were rejected under 35 U.S.C. 112(b), as stated above, as being indefinite for failing to particularly point out and distinctly claim the subject matter. Thus, claims 5 and 13 are rejected under 35 U.S.C. 112(b) for at least the same reasons as claims 4 and 12, respectively, due to their dependency thereon.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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.
Claims 1-3, 7-11, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Lenglet et al., US 2021/0385083 A1 (hereinafter, “Lenglet ‘083”), in view of Blasi, US 2022/0407850 A1 (hereinafter, “Blasi ‘850”), and further in view of Holt et al., US 2019/0318115 A1 (hereinafter, “Holt ‘115”), and further in view of Leibmann et al., US 2021/0250361 A1 (hereinafter, “Leibmann ‘361”).
As per claim 1: Lenglet ‘083 discloses:
A method, comprising: (a method for expiring authentication tokens using signing key rotation [Lenglet ‘083, ¶¶Abstract, 3, 21; Fig. 4])
causing a key identification (ID) to be extracted from the requested access token received from the authorization server (the token issuer 200 includes a key ID 230 within the authentication token 210 that identifies the cryptographic key 220 used to sign the authentication token, where the authentication token 210 is received by the token authenticator 250 and the key ID is extracted therefrom [Lenglet ‘083, ¶¶21, 26-28; Figs. 1-2]);
causing the key ID to be compared against cryptographic keys previously received at the first resource server (the token authenticator 250 obtains a list of valid key IDs 230 from the token issuer 200, where the list of valid key IDs includes IDs each associated with a corresponding valid cryptographic key 220, and where the token authenticator 250 determines whether a cryptographic key 220 used to sign the received authentication token 210 is valid based on the list of valid key IDs 230 obtained from the token issuer 200, i.e., comparing the key ID in the received token against the previously received list of valid key IDs [Lenglet ‘083, ¶¶21, 28, 30; Figs. 1-2]);
in response to the key ID matching one of the cryptographic keys previously received at the first resource server, causing the matching previously received cryptographic key to be used to verify the access token (when the cryptographic key 220 used to sign the authentication token 210 is valid, i.e., when the key ID matches one of the valid key IDs in the previously received list, the token authenticator 250 determines that the authentication token 210 is valid [Lenglet ‘083, ¶¶21, 28-29]); and
in response to the access token being verified, causing the access request to be granted (when the cryptographic key 220 used to sign the authentication token 210 is valid, the token authenticator 250 allows the client 10 access to the resource, e.g., the token authenticator 250 issues permission 254 to the remote system 140 [Lenglet ‘083, ¶¶21, 28-29; Fig. 1]);
causing the key ID to be extracted from the access token copy; causing the extracted key ID to be compared against cryptographic keys previously received at a second resource server associated with the second client location; and in response to the extracted key ID matching one of the cryptographic keys previously received at the second resource server, causing the matching previously received cryptographic key to be used to verify the access token copy (the token authenticator 250 receives an authentication token 210, obtains a list of valid key IDs 230 for cryptographic keys 220, extracts a key ID 230 from the authentication token 210, and determines whether the cryptographic key 220 used to sign the authentication token 210 is valid based on the list of valid key IDs 230, and when valid, allows access to the resource; the system 100 may include any number of token authenticators 250 controlling access to any number of resources, where the token issuer 200 updates some or all token authenticators 250 as new keys 220 are generated and old keys 220 are deleted, and where the token issuer 200 may keep multiple sets of keys 220 for different sets or groups of token authenticators 250; this verification process is applicable to any resource server that receives the access token [Lenglet ‘083, ¶¶21, 27-30, 39, 41-42]).
As stated above, Lenglet ‘083 does not explicitly disclose the limitations “receiving, at a first client location in a logic system group, an access request targeting a first resource server; sending a request to an authorization server for an access token associated with performing the access request … sending a copy of the access token to a second client location in the logic system group …”.
Blasi ‘850, however, discloses:
receiving, at a first client location in a logic system group, an access request targeting a first resource server (receiving, by an access management server 110 and from a remote computing device 130, a service request message requesting access to an API of a resource server 140, where the system 100 includes the access management server 110 in communication with the remote computing device 130 and the resource server 140, where the remote computing device 130 executes an ISV application 132 that performs operations including transmitting service requests to the resource server 140, and where the access management server 110, the remote computing device 130, the resource server 140, the API management server 150, and the global access cache 160 can communicate with each other over one or more networks such as a local area network (LAN) or a wide area network (WAN) [Blasi ‘850, ¶¶3, 15-16, 20, 30, 32, 68]);
Lenglet ‘083 and Blasi ‘850 are analogous art because they are from the same field of endeavor, namely that of token-based authentication and authorization for accessing protected resources. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 and Blasi ‘850 before them, to modify the method in Lenglet ‘083 to include the teachings of Blasi ‘850, namely to implement the token authentication system of Lenglet ‘083 in the context of a resource server architecture where the access management server receives service request messages targeting a resource server, and further to implement the token authentication operations within a distributed system architecture comprising a remote computing device (client location) that communicates with resource servers over a network (logic system group), as disclosed in Blasi ‘850. A motivation for doing so would be to provide token-based access authorization to APIs of a resource server while reducing the overhead associated with token verification by utilizing locally-cached tokens, and further to provide a scalable and distributed system for token-based access authorization that enables multiple computing devices to communicate and share authentication information across a network (see Blasi ‘850, ¶¶3, 6, 16, 22-23, 30).
As stated above, Lenglet ‘083 in view of Blasi ‘850 does not explicitly disclose the limitation “sending a request to an authorization server for an access token associated with performing the access request … sending a copy of the access token to a second client location in the logic system group …”.
Holt ‘115, however, discloses:
sending a request to an authorization server for an access token associated with performing the access request (in step 701, the client system 103 receives an access request from the user device 101; in step 703, the client system 103 transmits a request for an access token to the authorization server 105 in response to the access request; in step 705, the client system 103 receives the access token from the authorization system 105 [Holt ‘115, ¶¶114-116; Fig. 7])
… …
Lenglet ‘083 (modified by Blasi ‘850) and Holt ‘115 are analogous art because they are from the same field of endeavor, namely that of token-based authentication and authorization for accessing protected resources. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850) and Holt ‘115 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850) to include the teachings of Holt ‘115, namely to implement the token-based access control process such that a request for an access token is sent to an authorization server in response to receiving an access request, as disclosed in Holt ‘115. A motivation for doing so would be to ensure that the client system has a current, valid access token at the time of servicing the access request, which is a known approach in OAuth 2.0 systems for managing access to protected resources (see Holt ‘115, ¶¶17-18, 113-116).
As stated above, Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115 does not explicitly disclose the limitation “sending a copy of the access token to a second client location in the logic system group”.
Leibmann ‘361, however, discloses:
sending a copy of the access token to a second client location in the logic system group (a protected forwarded access pattern, using a protected forwarded token (PFT), that is used when a middle tier service or microservice receives an access token issued to a device or web application and forwards this, along with the API request, to the microservice that is ultimately being accessed, where the permissions apply to access tokens issued to an application that are then forwarded by a middle tier service or API, and where the receiving microservice is to accept an access token that was forwarded by a particular service or API; in a disclosed example, a client issues the token to a first service B, which forwards the token to a service A, which then sends the token to the ultimate API or microservice, where service B is the “front door service”, service A is the “actor”, and the ultimate API or microservice is the “downstream API” that receives the token [Leibmann ‘361, ¶¶12, 26-28, 31-32; and in particular: ¶¶33, 35-36]).
Lenglet ‘083 (modified by Blasi ‘850 and Holt ‘115) and Leibmann ‘361 are analogous art because they are from the same field of endeavor, namely that of access token authentication and authorization in distributed computing environments. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850 and Holt ‘115) and Leibmann ‘361 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850 and Holt ‘115) to include the teachings of Leibmann ‘361, namely to implement a protected forwarded access pattern in which a first client location sends a copy of the access token to a second client location, and in which the second client location submits the access token copy to a second resource server associated therewith, as disclosed in Leibmann ‘361, where the key ID extraction, comparison, and verification process taught by Lenglet ‘083 is applied at the second resource server that receives the forwarded access token copy. A motivation for doing so would be to enable the microservices of a distributed service to communicate with one another in order to deliver acceptable performance for the overall service, while maintaining proper authorization controls over the data controlled by each, and to thereby permit an access token issued to a client to be accepted at an additional resource by way of the forwarding pattern, without requiring a separate access token to be issued for that resource (see Leibmann ‘361, ¶¶12, 33, 35).
As per claim 2: Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 discloses all limitations of claim 1, as stated above, from which claim 2 is dependent upon. Furthermore, Lenglet ‘083 discloses:
further comprising: inspecting a lease time associated with the matching previously received cryptographic key; and in response to determining that the lease time assigned to the matching previously received cryptographic key has not expired, causing the matching previously received cryptographic key to be used to verify the access token (each key ID 230 in the list of valid key IDs 230 is associated with a respective expiration time 232, where the expiration time 232 indicates when the respective key 220 will expire; when the token authenticator 250 receives an authentication token 210, the token authenticator 250 determines whether the expiration time 232 associated with the respective key ID 230 has expired; when the key 220 used to sign the authentication token 210 has not yet expired, the token authenticator 250 determines that the authentication token 210 is valid and grants the client access to the resource [Lenglet ‘083, ¶¶4, 29; Fig. 2A]).
As per claim 3: Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 discloses all limitations of claims 1-2, as stated above, from which claim 3 is dependent upon. Lenglet ‘083 in view of Blasi ‘850 does not explicitly disclose the limitations of claim 3. Holt ‘115, however, discloses:
in response to determining that the lease time assigned to the matching previously received cryptographic key has expired, causing a request for an updated cryptographic key to be sent to the authorization server (each grant token provided to the client system 103 by the authorization system 105 has a corresponding time to expire which is the time at which the token will not be considered valid [Holt ‘115, ¶97]; a time interval is determined based on the expiry time of the received grant token, where the time interval may be equal to the expiry time of the grant token such that the client system 103 can initiate the process of requesting a new grant token at the moment the grant token expires [Holt ‘115, ¶102]; once the time interval has elapsed, the client system 103 transmits a refresh request to the authorization system 105, where the refresh request comprises an instruction for a new grant token to be provided to the client system 103 from the authorization system 105 [Holt ‘115, ¶106]);
and in response to receiving the updated cryptographic key, using the updated cryptographic key to verify the access token (the client system 103 receives the new grant token in response to the refresh request [Holt ‘115, ¶107]; the client system 103 may transmit the most recently received grant token to the resource system 107 in order to initiate a request for the protected resource, where the token is used for verification purposes [Holt ‘115, ¶¶107-108]).
Lenglet ‘083 (modified by Blasi ‘850 and Leibmann ‘361) and Holt ‘115 are analogous art because they are from the same field of endeavor, namely that of authentication token management and verification in distributed computing systems. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850 and Leibmann ‘361) and Holt ‘115 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850 and Leibmann ‘361) to include the teachings of Holt ‘115, namely to implement a mechanism whereby the first resource server, upon detecting that the lease time associated with a cached cryptographic key has expired, transmits a request to the authorization server for an updated cryptographic key, as analogously taught by the grant token refresh mechanism in Holt ‘115. A motivation for doing so would be to ensure that a valid cryptographic key is held at the resource server, thereby allowing access requests to be serviced reliably and quickly without delay caused by using expired credentials (see Holt ‘115, ¶97).
As per claim 7: Lenglet ‘083, in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 discloses all limitations of claim 1, as stated above, from which claim 7 is dependent upon. Lenglet ‘083 in view of Holt ‘115 does not explicitly disclose the limitations of claim 7. Blasi ‘850, however, discloses:
further comprising: in response to the access token not being verified, causing the access request to be denied (in response to determining that the ISV application 132 should not be authorized to access the requested services and/or data of the resource server 140, the method 600 advances to block 612 in which the resource server 140 takes preventative measures and the method 600 subsequently terminates, thereby denying access to the requested services and/or data [Blasi ‘850, ¶69]).
Lenglet ‘083 (modified by Holt ‘115 and Leibmann ‘361) and Blasi ‘850 are analogous art because they are from the same field of endeavor, namely that of token-based authentication and access control for distributed computing resources. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Holt ‘115 and Leibmann ‘361) and Blasi ‘850 before them, to modify the method in Lenglet ‘083 (modified by Holt ‘115 and Leibmann ‘361) to include the teachings of Blasi ‘850, namely to deny the access request when the access token is not verified by the resource server, as disclosed in Blasi ‘850. A motivation for doing so would be to protect the integrity of the system and prevent unauthorized access to protected resources when token verification fails (see Blasi ‘850, ¶¶59, 69).
As per claim 8: Lenglet ‘083, in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 discloses all limitations of claim 1, as stated above, from which claim 8 is dependent upon. Furthermore, Lenglet ‘083 discloses:
wherein the access token is a JSON Web Token (JavaScript Object Notation (JSON) Web Token is an Internet standard for creating access tokens [Lenglet ‘083, ¶19]).
As per claims 9-11 and 15-16: Claims 9-11 and 15-16 define a computer program product that recites substantially similar subject matter as the method of claims 1-3 and 7-8, respectively. Specifically, claims 9-11 and 15-16 are directed to a computer program product comprising one or more computer-readable storage media and program instructions stored on the one or more storage media to perform the computer-implemented method of claims 1-3 and 7-8, respectively. Thus, the rejection of claims 1-3 and 7-8 is equally applicable to claims 9-11 and 15-16, respectively.
As per claims 17-19: Claims 17-19 define a computer system that recites substantially similar subject matter as the method of claims 1-3, respectively. Specifically, claims 17-19 are directed to a computer system comprising a processor set, one or more computer-readable storage media, and program instructions stored on the one or more storage media to cause the processor set to perform the computer-implemented method of claims 1-3, respectively. Thus, the rejection of claims 1-3 is equally applicable to claims 17-19, respectively.
Claims 4-5 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Lenglet ‘083, in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361, and further in view of Kishimoto et al., US 2020/0076791 A1 (hereinafter, “Kishimoto ‘791”).
As per claim 4: Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 discloses all limitations of claim 1, as stated above, from which claim 4 is dependent upon. Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 does not explicitly disclose the limitations of claim 4. Kishimoto ‘791, however, discloses:
further comprising: in response to the key ID not matching one of the cryptographic keys previously received at the first resource server: causing the first resource server to initiate a request with the authorization server for information associated with verifying the access token (the resource server 202 comprises a public key management unit 502 that manages public keys obtained from the authentication/authorization server 201, where the public keys are managed in a public key management table constituted by a Key ID item, which indicates a Key ID for uniquely identifying the public key, and a public key item, and where the resource server 202 obtains the public keys from the authentication/authorization server 201 [Kishimoto ‘791, ¶¶47-48, 53]; the JWS access token verification unit 504 of the resource server 202 obtains the JWS access token from the service request received from the client 203, where the KeyID included in the header parameter of the obtained JWS access token is obtained and used in the verification, the “kid” (Key ID) being a JWS header claim which indicates which key was used to protect the JWS [Kishimoto ‘791, ¶¶38-39, 65]; in step S702, the JWS access token verification unit 504 queries the public key management unit 502 as to whether or not a key matching the KeyID obtained in step S701 is present, where the process moves to step S703 if there is no key matching the obtained KeyID, and to step S705 if a matching key is present [Kishimoto ‘791, ¶66]; in step S703, the public key management unit 502 makes a request to the authentication/authorization server 201 for obtaining a public key not held by the resource server 202 [Kishimoto ‘791, ¶67]); and
causing the first resource server to use the received cryptographic information to verify the access token and access request (in step S704, the JWS access token verification unit 504 again queries the public key management unit 502 as to whether or not a key matching the KeyID obtained in step S701 is present; in step S705, the JWS access token verification unit 504 verifies whether or not the access token is valid on the basis of the signature in the obtained JWS access token, where an access token can be confirmed as having been issued by a valid authentication/authorization server by confirming the signature using the public key that matches the KeyID [Kishimoto ‘791, ¶¶68-69]; if the result of the verification indicates that the JWS access token is valid, the resource server 202 executes processing for providing the service [Kishimoto ‘791, ¶61]).
Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) and Kishimoto ‘791 are analogous art because they are from the same field of endeavor, namely that of verification of signed access tokens at a resource server using cryptographic keys identified by a key identification. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) and Kishimoto ‘791 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) to include the teachings of Kishimoto ‘791, namely to implement the key ID comparison process of Lenglet ‘083 such that, when the key ID extracted from the access token does not match one of the cryptographic keys previously received at the first resource server, the first resource server initiates a request with the authorization server for the cryptographic information required to verify the access token, and uses the cryptographic information received in response to that request to verify the access token and the access request, as disclosed in Kishimoto ‘791. A motivation for doing so would be to permit the resource server to verify a signed access token that was signed using a key added at the authorization server, even where the resource server has not been notified that the key has been added, thereby avoiding a circumstance in which an access token is determined to be invalid when the signature is verified at the resource server despite the access token actually being valid, and further to avoid the complexity of a notification system by which the authorization server would otherwise be required to confirm that all linked resource servers have obtained the key (see Kishimoto ‘791, ¶¶3, 7, 35-36).
As per claim 5: Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361, and further in view of Kishimoto ‘791 discloses all limitations of claims 1 and 4, as stated above, from which claim 5 is dependent upon. Furthermore, Lenglet ‘083 discloses:
wherein the authorization server is not included in the logic system group (the token issuer 200 and the token authenticator 250 may execute on separate systems completely independent from one another, where the token issuer 200 corresponds to an authorization server that issues authentication tokens and cryptographic keys [Lenglet ‘083, ¶27]), wherein the first resource server is included in the logic system group (the token authenticator 250, which controls access to the resource, may execute within the remote system 140, where the system 100 may include any number of token authenticators 250 controlling access to any number of resources [Lenglet ‘083, ¶27]).
As per claims 12-13: Claims 12-13 define a computer program product that recites substantially similar subject matter as the method of claims 4-5, respectively. Specifically, claims 12-13 are directed to a computer program product comprising one or more computer-readable storage media and program instructions stored on the one or more storage media to perform the computer-implemented method of claims 4-5, respectively. Thus, the rejection of claims 4-5 is equally applicable to claims 12-13, respectively.
Claims 6, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lenglet ‘083, in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361, and further in view of Kishimoto ‘791, and further in view of Kitagata, US 2020/0336494 A1 (hereinafter, “Kitagata ‘494”).
As per claim 6: Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361, and further in view of Kishimoto ‘791 discloses all limitations of claims 1 and 4, as stated above, from which claim 6 is dependent upon. Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 does not explicitly disclose the limitations of claim 6. Kishimoto ‘791, however, discloses:
further comprising: in response to the extracted key ID not matching one of the cryptographic keys previously received at the second resource server: causing the second resource server to initiate a request with (the resource server 202 comprises a public key management unit 502 that manages public keys obtained from the authentication/authorization server 201 in a public key management table constituted by a Key ID item and a public key item [Kishimoto ‘791, ¶¶47-48, 53]; the JWS access token verification unit 504 of the resource server 202 obtains the KeyID included in the header parameter of the obtained JWS access token [Kishimoto ‘791, ¶¶38-39, 65]; in step S702, the JWS access token verification unit 504 queries the public key management unit 502 as to whether or not a key matching the obtained KeyID is present, where the process moves to step S703 if there is no key matching the obtained KeyID [Kishimoto ‘791, ¶66]; in step S703, the public key management unit 502 makes a request to the authentication/authorization server 201 for obtaining a public key not held by the resource server 202 [Kishimoto ‘791, ¶67]); and
causing the second resource server to use the received cryptographic information to verify the access token copy and secondary access request (in step S704, the JWS access token verification unit 504 again queries the public key management unit 502 as to whether or not a key matching the obtained KeyID is present; in step S705, the JWS access token verification unit 504 verifies whether or not the access token is valid on the basis of the signature in the obtained JWS access token, by confirming the signature using the public key that matches the KeyID [Kishimoto ‘791, ¶¶68-69]; if the verification indicates that the JWS access token is valid, the resource server 202 executes processing for providing the service in response to the service request received from the client 203 [Kishimoto ‘791, ¶¶61, 65]).
Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) and Kishimoto ‘791 are analogous art because they are from the same field of endeavor, namely that of verification of signed access tokens at a resource server using cryptographic keys identified by a key identification. For the reasons stated in claim 4, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) and Kishimoto ‘791 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) to include the teachings of Kishimoto ‘791.
As stated above, Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361, and further in view of Kishimoto ‘791 does not explicitly disclose the limitation “… causing the second resource server to initiate a request with a second authorization server for information associated with verifying the access token …”.
Kitagata ‘494, however, discloses:
… causing the second resource server to initiate a request with a second authorization server for information associated with verifying the access token … (an authentication/authorization server 111 that is a different server from the authentication/authorization server 110, where the authentication/authorization server 111 controls access to a resource server 121, where the authentication/authorization server 111 and the resource server 121 are located in the same data center, and where the authentication/authorization server 110 and the authentication/authorization server 111 are located in different data centers [Kitagata ‘494, ¶¶27-28]; the public key for verifying the JWS signature is provided in advance in the resource servers 120 and 121 which use the JWS access token, where, although belonging to a different security domain from the authentication/authorization server 110, the resource server 121 holds the public key for verifying the JWS access token, such that the resource server 121 holding the public key which verifies the JWS access token issued by the authentication/authorization server 110 can be used with that JWS access token [Kitagata ‘494, ¶58]; the resource servers 120 and 121 hold the public key for verifying the token issued by the authentication/authorization servers 110 and 111, and authorize the client by verifying the token, where whether the token signature is valid is verified using the public key [Kitagata ‘494, ¶64])
Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, Leibmann ‘361, and Kishimoto ‘791) and Kitagata ‘494 are analogous art because they are from the same field of endeavor, namely that of verification of signed access tokens at a resource server using cryptographic keys provided by an authorization server. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, Leibmann ‘361, and Kishimoto ‘791) and Kitagata ‘494 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, Leibmann ‘361, and Kishimoto ‘791) to include the teachings of Kitagata ‘494, namely to implement the distributed system such that a second authorization server, which is a different server from the authorization server that issued the access token, is associated with the second resource server, and such that the second resource server obtains from the second authorization server the cryptographic information used to verify the access token copy, as disclosed in Kitagata ‘494. A motivation for doing so would be to permit the service to be provided from multiple data centers located in different regions, such that the capacity to provide the service may be strengthened by adding resource servers in other data centers and such that a client may access a resource server in a nearby region, which is more efficient in terms of communication costs, while permitting a resource server belonging to a different security domain from the issuing authorization server to nonetheless verify an access token issued by that authorization server (see Kitagata ‘494, ¶¶5, 8, 58).
As per claim 14: Claim 14 defines a computer program product that recites substantially similar subject matter as the method of claim 6. Specifically, claim 14 is directed to a computer program product comprising one or more computer-readable storage media and program instructions stored on the one or more storage media to perform operations comprising the method of claim 6. Thus, the rejection of claim 6 is equally applicable to claim 14.
As per claim 20: Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 discloses all limitations of claim 17, as stated above, from which claim 20 is dependent upon. Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361 does not explicitly disclose the limitations of claim 20. Kishimoto ‘791, however, discloses:
wherein the operations further comprise: in response to the extracted key ID not matching one of the cryptographic keys previously received at the second resource server: causing the second resource server to initiate a request with (the resource server 202 comprises a public key management unit 502 that manages public keys obtained from the authentication/authorization server 201 in a public key management table constituted by a Key ID item and a public key item [Kishimoto ‘791, ¶¶47-48, 53]; the JWS access token verification unit 504 of the resource server 202 obtains the KeyID included in the header parameter of the obtained JWS access token [Kishimoto ‘791, ¶¶38-39, 65]; in step S702, the JWS access token verification unit 504 queries the public key management unit 502 as to whether or not a key matching the obtained KeyID is present, where the process moves to step S703 if there is no key matching the obtained KeyID [Kishimoto ‘791, ¶66]; in step S703, the public key management unit 502 makes a request to the authentication/authorization server 201 for obtaining a public key not held by the resource server 202 [Kishimoto ‘791, ¶67]); and
causing the second resource server to use the received cryptographic information to verify the access token copy and secondary access request (in step S704, the JWS access token verification unit 504 again queries the public key management unit 502 as to whether or not a key matching the obtained KeyID is present; in step S705, the JWS access token verification unit 504 verifies whether or not the access token is valid on the basis of the signature in the obtained JWS access token, by confirming the signature using the public key that matches the KeyID [Kishimoto ‘791, ¶¶68-69]; if the verification indicates that the JWS access token is valid, the resource server 202 executes processing for providing the service in response to the service request received from the client 203 [Kishimoto ‘791, ¶¶61, 65]).
Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) and Kishimoto ‘791 are analogous art because they are from the same field of endeavor, namely that of verification of signed access tokens at a resource server using cryptographic keys identified by a key identification. For the reasons stated in claim 4, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) and Kishimoto ‘791 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, and Leibmann ‘361) to include the teachings of Kishimoto ‘791.
As stated above, Lenglet ‘083 in view of Blasi ‘850, and further in view of Holt ‘115, and further in view of Leibmann ‘361, and further in view of Kishimoto ‘791 does not explicitly disclose the limitation “… causing the second resource server to initiate a request with a second authorization server for information associated with verifying the access token …”.
Kitagata ‘494, however, discloses:
… causing the second resource server to initiate a request with a second authorization server for information associated with verifying the access token … (an authentication/authorization server 111 that is a different server from the authentication/authorization server 110, where the authentication/authorization server 111 controls access to a resource server 121, and where the authentication/authorization server 110 and the authentication/authorization server 111 are located in different data centers [Kitagata ‘494, ¶¶27-28]; the public key for verifying the JWS signature is provided in advance in the resource servers 120 and 121 which use the JWS access token, where, although belonging to a different security domain from the authentication/authorization server 110, the resource server 121 holds the public key for verifying the JWS access token, such that the resource server 121 holding the public key which verifies the JWS access token issued by the authentication/authorization server 110 can be used with that JWS access token [Kitagata ‘494, ¶¶58, 64])
Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, Leibmann ‘361, and Kishimoto ‘791) and Kitagata ‘494 are analogous art because they are from the same field of endeavor, namely that of verification of signed access tokens at a resource server using cryptographic keys provided by an authorization server. For the reasons stated in claim 6, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, Leibmann ‘361, and Kishimoto ‘791) and Kitagata ‘494 before them, to modify the method in Lenglet ‘083 (modified by Blasi ‘850, Holt ‘115, Leibmann ‘361, and Kishimoto ‘791) to include the teachings of Kitagata ‘494.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Madden, US 20230239151 A1: delegating authorization to access a resource server contingent upon group membership confirmation by a third-party identity management provider. A client obtains a Macaroon Access Token with a third-party caveat that requires the client to obtain a one-time Discharge Macaroon Authorization.
Palanisamy et al., US 20230412382 A1: issuing, subsequent to validating the authentication request and by the authorization server, an access token to the client application; detecting, at a resource server, a request from the client application to access a resource, wherein the request comprises the access token.
Spelman et al., US 20040230831 A1: single sign-on capabilities for accessing a Web application through a passive client across multiple realms within a federation. A federation refers to different organizations or realms that have employed agreements, standards to make user identity and entitlements portable between the organizations.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Friday 8:00am-4:30pm EST.
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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights