DETAILED ACTION
Claims 1-20 are presented for consideration.
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.
Claim 12 is 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.
Claim 12 recites the limitation "an API endpoint" in line 5. There is insufficient antecedent basis for this limitation in the claim.
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) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Paul et al. [ US Patent Application No 2023/0136230 ], in view of Voth Andreas [ EP 4462730 A1 ].
As per claim 1, Paul discloses the invention as claimed including a method comprising:
receiving, from a first user device [ i.e. receive a call to an API backend at an authentication service ] [ 510, Figure 5; and paragraphs 0049 ], a first authorization token and a first application programming interface (API) call for a first service [ i.e. token from the new authentication service to a legacy token ] [ paragraphs 0039, and 0041 ], wherein the first service is configured with a legacy authentication scheme [ i.e. OneOPs is used as an example of a legacy authentication service ] [ paragraphs 0054, 0056 ], and wherein the first authorization token corresponds to a new authentication scheme, different than the legacy authentication scheme [ i.e. using Azure as an example of a new authentication service and OneOPs as an example of a legacy authentication service ] [ paragraphs 0038, 0042, and 0044 ];
obtaining, using the first authorization token and from an authorization server that generated the first authorization token, a first legacy token corresponding to the first service and the legacy authentication scheme [ i.e. forward the token and/or associated user credentials to the token converter, the token converter may generate a converted token in the format of the first authentication service ] [ Figure 4; and paragraphs 0045, and 0051 ];
forwarding, along with the first legacy token and to an API endpoint for the first service, the first API call [ i.e. the call and the token are forwarded to the API backend ] [ paragraph 0051 ];
receiving, from the API endpoint for the first service, a first API response for the first API call [ i.e. respond to the call by using the converted token to retrieve user information ] [ Figure 5; and paragraph 051 ]; and
forwarding the first API response to the first user device [ i.e. retrieve membership information for use in responding to calls from the user device ] [ paragraphs 0033, 0034, and 0051 ].
Paul does not specifically disclose receiving at an API gateway.
Voth Andreas discloses receiving at an API gateway [ i.e. API gateway ] [ 320, Figure 1; Abstract; and paragraphs 0036, and 0037 ].
It would have been obvious to a person skill in the art before the effective filing date of the claimed invention to combine the teaching of Paul and Voth Andreas because the teaching of Voth Andreas would enable to provide system for managing authentication related tokens for a personalized service [ Voth Andreas, paragraph 0001 ].
As per claim 2, Paul discloses receiving, from a second user device and while the first service is configured with the legacy authentication scheme, a second API call for the first service and the first legacy token [ i.e. receiving a second user from user device via the second authentication system ] [ Figure 4; and paragraphs 0014, and 0042 ], wherein the second user device corresponds to a legacy user of the first service [ i.e. using Azure as an example of a new authentication service and OneOPs as an example of a legacy authentication service ] [ paragraphs 0038, 0042, and 0044 ]; forwarding, along with the first legacy token and to the API endpoint for the first service, the second API call [ i.e. forward the second tokens to the retailer backend system ] [ paragraphs 0061 ]; receiving, from the API endpoint for the first service, a second API response for the second API call [ i.e. respond to the call by using the converted token to retrieve user information ] [ Figure 5; and paragraph 051 ]; and forwarding the second API response to the second user device [ i.e. retrieve membership information for use in responding to calls from the user device ] [ paragraphs 0033, 0034, and 0051 ].
As per claim 3, Paul discloses wherein the first authorization token includes a reference to the first legacy token [ i.e. based on the source of the call, the token type, and destination of the call ] [ paragraph 0044 ], and wherein obtaining the first legacy token comprises: sending, to the authorization server, the reference; and receiving, based on the reference, the first legacy token [ i.e. forward the token and/or associated user credentials to the token converter, the token converter may generate a converted token in the format of the first authentication service ] [ Figure 4; and paragraphs 0045, and 0051 ].
As per claim 4, Paul discloses wherein the first authorization token includes the first legacy token, and wherein obtaining the first legacy token comprises extracting, from the first authorization token, the first legacy token [ i.e. determine whether token conversion should be performed for the received token ] [ 514, Figure 5; and paragraph 0050 ].
As per claim 5, Paul discloses wherein obtaining the first legacy token comprises: sending, to the authorization server and based on the first API request, an indication of the first service and the first authorization token; and receiving, from the authorization server, the first legacy token [ i.e. forward the token and/or associated user credentials to the token converter, the token converter may generate a converted token in the format of the first authentication service ] [ Figure 4; and paragraphs 0045, and 0051 ].
As per claim 6, Paul discloses wherein the first legacy token is generated by the authorization server on demand and in response to receiving the indication of the first service and the first authorization token [ i.e. converting ] [ paragraph 0039 ].
As per claim 7, Paul discloses identifying, based on a service configuration corresponding to the first service, that all legacy users of the first service have transitioned to the new authentication scheme; and causing, for the first service, a reconfiguration from the legacy authentication scheme to the new authentication scheme [ i.e. migration of a web service from a legacy authentication service to a new authentication service ] [ paragraphs 0038, and 0041 ].
As per claim 8, Paul discloses receiving, from the first user device and after completion of the reconfiguration, a second API call for the first service and the first authorization token; forwarding, to the API endpoint for the first service, the first authorization token; based on validation of the first authorization token, receiving a second API response for the second API call; and forwarding the second API response to the first user device [ i.e. determine whether token conversion is needed, and if the token does not need to be converted, the system forwards the call and the token to the API backend ] [ paragraphs 0038, and 0051 ].
As per claim 9, Paul discloses wherein the first authorization token is configured for use in authenticating the first user device both during and after completion of the reconfiguration [ i.e. during the migration ] [ paragraphs 0038, and 0042 ].
As per claim 10, Voth Andreas discloses wherein the API gateway sends, for a predetermined period of time after completion of the reconfiguration, both the first authorization token and the first legacy token, and wherein authentication of the first user device is performed using one of the first authorization token or the first legacy token [ i.e. based on the token type, API gateway may transmit the access information to the management backend ] [ paragraphs 0014, and 0037 ].
As per claim 11, Paul discloses identifying, after completing the reconfiguration, that a second service has not completed the reconfiguration; receiving, a second API call for the second service and a second authorization token; obtaining, using the second authorization token and from the authorization server, a second legacy token corresponding to the second service and the legacy authentication scheme; sending, to an API endpoint for the second service, the second legacy token; based on validation of the second legacy token, receiving a second API response for the second API call; and forwarding the second API response to the first user device [ i.e. the second token may comprises a step-up token, the second token is forwarded back to the POS for use in subsequent communications ] [ Abstract; and paragraphs 0026, and 0027 ].
As per claim 12, Paul in view of Voth Andreas discloses the method of claim 1, furthermore, Paul discloses receiving, from the first user device, the first authorization token and a second API call for a second service, wherein the second service is configured with the new authentication scheme [ i.e. new authentication service during an authentication migration ] [ paragraph 0042 ]; forwarding, along with the first authorization token and to an API endpoint for the second service, the second API call [ i.e. determine whether token conversion is needed, and if the token does not need to be converted, the system forwards the call and the token to the API backend ] [ paragraphs 0038, and 0051 ]; receiving, from the API endpoint for the second service, a second API response for the second API call; and forwarding the second API response to the first user device [ paragraphs 0033, 0034, and 0051 ]; and Voth discloses receiving at the API gateway [ i.e. API gateway ] [ 320, Figure 1; Abstract; and paragraphs 0036, and 0037 ].
As per claims 13-19, they are rejected for similar reasons as stated above in claims 1-7.
As per claim 20, it is rejected for similar reason as stated above in claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Van den Dungen et al. [ US Patent Application No 2023/0098484 ] discloses transform a request to perform an entity operation from an interface specification for the first identity server (e.g. a legacy API) to an interface specification for the second identity service (e.g. SCIM)
Otranen [ US Patent Application No 2011/0209202 ] discloses federation gateway controls the interaction between the legacy authentication service and federated identity service, as well as interactions between SSO device and the service federated identity services
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUSTIN NGUYEN whose telephone number is (571)272-3971. The examiner can normally be reached Monday-Friday 9-6 PST.
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, Brian Gillis can be reached at 571-2727952. 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.
/DUSTIN NGUYEN/Primary Examiner, Art Unit 2445
Prosecution Insights