Patent Application 18302489 - SYSTEMS AND METHODS FOR REAL-TIME IDENTITY - Rejection
Patent Application 18302489 - SYSTEMS AND METHODS FOR REAL-TIME IDENTITY
Title: SYSTEMS AND METHODS FOR REAL-TIME IDENTITY VERIFICATION USING A TOKEN CODE
Application Information
- Invention Title: SYSTEMS AND METHODS FOR REAL-TIME IDENTITY VERIFICATION USING A TOKEN CODE
- Application Number: 18302489
- Submission Date: 2025-05-20T00:00:00.000Z
- Effective Filing Date: 2023-04-18T00:00:00.000Z
- Filing Date: 2023-04-18T00:00:00.000Z
- National Class: 726
- National Sub-Class: 028000
- Examiner Employee Number: 89673
- Art Unit: 2432
- Tech Center: 2400
Rejection Summary
- 102 Rejections: 0
- 103 Rejections: 2
Cited Patents
The following patents were cited in the rejection:
Office Action Text
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 .
Information Disclosure Statement
The 4/18/2023 and 11/3/2023 IDS documents have been considered by the examiner.
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 21, 26-28, 33-35, and 39-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over at least claims 1-2 of U.S. Patent No. 11,652,813 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the patent claims are considered to anticipate the instant claims as per the table below. Instant claims 28, 33-35, and 39-40 are substantially similar to claims 21 and 26-27, and are therefore likewise rejected in view of respective patent claims.
Instant Application
US 11,652,813 B2
21. An identity authority computing device comprising a processor configured to:
communicate with a public network and a secure data processing domain, and prevent access from the public network to confidential user data stored in the secure data processing domain;
transmit, within the secure data processing domain, an encrypted service request to a service provider computing device, the encrypted service request including at least one persistent user identifier, the encrypted service request transmitted in response to a service request (i) including a token value associated with a user and (ii) received over the public network from an interface domain associated with an interface computing device;
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
filter the at least one persistent user identifier from the service response; and
transmit the filtered service response and the token value to the interface computing device.
1. An identity authority computing device comprising a processor programmed to:
communicate with a public network and with a secure data processing domain, and prevent access from the public network to confidential user data stored in the secure data processing domain;
… generate an updated service request including the at least one persistent user identifier;
generate an encrypted service request by using a public encryption key associated with the service provider identifier to encrypt the updated service request; and
transmit, within the secure data processing domain, the encrypted service request to a service provider computing device associated with the service provider identifier… receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device, the service request including a service provider identifier and a single-use token value associated with a user…
…wherein the interface domain is prevented from accessing confidential user data associated with the user including the persistent user identifier of the user…
2. The identity authority computing device of claim 1, wherein the processor is further programmed to:
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
filter the at least one persistent user identifier from the service response; and
transmit the filtered service response and the token value to the interface computing device.
26. The identity authority computing device of claim 21, wherein the interface computing device is in communication with a user computing device, and wherein the service request further includes a service provider identifier associated with the service provider computing device.
1. …receive a service request over the public network from an interface domain that includes an interface computing device in communication with a user computing device, the service request including a service provider identifier and a single-use token value associated with a user…
27. The identity authority computing device of claim 21, wherein the processor is further configured to, in response to the service request, access an identity database within the secure data processing domain, and wherein the identity database stores and indexes confidential information for a plurality users including a plurality of persistent user identifiers.
1. … in response to the service request, access an identity database within the secure data processing domain, wherein the identity database stores and indexes confidential information for a plurality of users including a plurality of persistent user identifiers…
Claims 22-25, 29-32, and 36-38 are rejected on the ground of nonstatutory double patenting as being unpatentable over U.S. Patent No. 11,652,813 B2 as applied to claims 21, 26-28, 33-35, and 39-40 above, and further in view of Keresman (US 2019/0172061 A1).
Regarding claim 22, the patent claims do not specify: wherein the processor is further configured to filter the at least one persistent user identifier from the service response by replacing the at least one persistent user identifier with the token value. However, the patent claims in view of at least [0050] of Keresman concerning replacing a user credential with a tokenized version are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include replacement with a tokenized value for at least the reasons specified in [0003] of Keresman concerning the advantages of tokenization (i.e., preventing entities from understanding private user data).
Regarding claim 23, it is rejected for substantially the same reasons as claim 22 above (e.g., the citations and obviousness rationale; also see [0032] of Keresman)
Regarding claim 24, the patent claims do not specify: wherein transmitting the filtered service response to the interface computing device causes the interface computing device to generate an application view based on the service response, and transmit the application view to a user computing device in communication with the interface computing device. However, the patent claims in view of at least [0052] and [0034] of Keresman concerning a merchant website, interactions with a checkout page, and subsequent response messages are considered to disclose this limitation. Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to include support for a checkout page and subsequent response because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 25, the patent claims in view of Keresman disclose: wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data (refer to at least patent claim 3 reciting “wherein the service response includes at least one of credit history data, personal background data, and vehicle insurance data”). Therefore it would have been obvious to one of ordinary skill in the art to modify the patent claims to implement the checkout page and response of Keresman as part of the service response for substantially the same reasons as claim 24 above.
Regarding claims 29-32 and 36-38, they are substantially similar to claims 22-25 above, and are therefore likewise rejected.
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 21-40 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. Each of independent claims 21, 28, and 35 are drawn to steps performed by an identity authority computing device, and further recite “[transmit/transmitting], within the secure data processing domain, an encrypted service request.” This limitation renders the claims indefinite because it is not clear how to interpret the claim language in the case where the identity authority computing device is not part of the secure data processing domain. Specifically, it is not clear how the identity authority computing device can transmit anything “within the secure data processing domain” if it is not already within the domain itself. The claims do not specify whether the identity authority computing device is actually part of the secure processing domain.
The dependent claims do not rectify this issue and are therefore rejected with their respective parent claims.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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) 21-24, 26-31, and 33-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman (US 2019/0172061 A1) in view of Raj (US 2014/0344153 A1).
Regarding claim 21, Keresman discloses: An identity authority computing device (Trusted Token Service Provider TTSP 140 in FIG. 9 of Keresman) comprising a processor configured to:
communicate with a public network (internet 110 in FIG. 9 of Keresman) and a secure data processing domain (payment network 160 in FIG. 9 of Keresman), and prevent access from the public network to confidential user data (e.g., [0031] of Keresman concerning sensitive user data, including a credential such as a PAN) stored in the secure data processing domain (e.g., [0037] of Keresman concerning a token vault; the payment network likewise needs to know user identifying credentials such as a PAN to actually proceed with payment);
Refer to at least [0032] of Kerseman with respect to, e.g., a merchant server being unable to access the user data.
transmit, within the secure data processing domain, an service request to a service provider computing device, the service request including at least one persistent user identifier,
Refer to at least [0048] of Keresman with respect to the TTSP sending a message with a corresponding PAN to the payment network.
the service request transmitted in response to a service request (i) including a token value associated with a user and (ii) received over the public network from an interface domain associated with an interface computing device;
Refer to at least [0041]-[0046] of Keresman with respect to the TTSP being sent a payment request message from the merchant, where the payment request message contains a tokenized version of a user’s PAN.
receive a service response from the service provider computing device, the service response including response data and the at least one persistent user identifier;
Refer to at least [0049] of Keresman with respect to the payment network sending a response with an included PAN.
filter the at least one persistent user identifier from the service response; and
Refer to at least [0050] of Keresman with respect to the TTSP replacing the PAN with the tokenized version of the PAN.
transmit the filtered service response and the token value to the interface computing device.
Refer to at least [0051]-[0052] of Keresman with respect to the TTSP forwarding the replaced-PAN message to the merchant.
Keresman does not specify: the service request to the service provider computer further comprising an encrypted service request. However, Keresman in view of Raj discloses: the service request to the service provider computer further comprising an encrypted service request.
Refer to at least [0042] and [0096] of Raj with respect to encrypted communications channels between participating entities (e.g., payment processing network, merchant, issuer, and tokenization hub).
The teachings of Keresman and Raj concern tokenization for payment processing, and are considered to be within the same field of endeavor and combinable as such. Further, the teachings of Raj concerning encrypted secure channels are applicable to typical network communications.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman to further implement secure encrypted channels between entities participating in transactions for at least the purpose of improving security according to best practices (i.e., encryption for preventing leakage of sensitive user data, man-in-the-middle attacks on financial institutions, and so forth).
Regarding claim 22, it is rejected for substantially the same reasons as claim 21 above (i.e., the citations concerning replacing the PAN with the tokenized PAN).
Regarding claim 23, it is rejected for substantially the same reasons as claim 21 above (i.e., the citations concerning obfuscating the PAN from the merchant while still allowing the transaction).
Regarding claim 24, Keresman-Raj discloses: The identity authority computing device of claim 21, wherein transmitting the filtered service response to the interface computing device causes the interface computing device to generate an application view based on the service response, and transmit the application view to a user computing device in communication with the interface computing device.
Refer to at least [0052] and [0034] of Keresman with respect to the transaction taking place on a merchant website accessed by a user and respective user device. Once the transaction is complete, the merchant may send an appropriate message indicating success or failure.
Regarding claim 26, Keresman-Raj discloses: The identity authority computing device of claim 21, wherein the interface computing device is in communication with a user computing device, and wherein the service request further includes a service provider identifier associated with the service provider computing device.
Refer to at least [0034]-[0035] of Keresman with respect to a user and respective user device used to proceed with checkout at the merchant’s website. The check out procedure includes entering payment data such as a PAN and/or other information identifying the payment processor associated with the user’s payment option. A PAN includes an issuer identification number as part of the standard.
Regarding claim 27, Keresman-Raj discloses: The identity authority computing device of claim 21, wherein the processor is further configured to, in response to the service request, access an identity database within the secure data processing domain, and wherein the identity database stores and indexes confidential information for a plurality users including a plurality of persistent user identifiers.
Refer to at least FIG. 9 and [0037] of Keresman with respect to a token vault storing token-to-credential information.
Regarding independent claim 28, it is substantially similar to independent claim 21 above, and is therefore likewise rejection (i.e., the citations and obviousness rationale).
Regarding claims 29-31 and 33-34, they are substantially similar to claims 22-24 and 26-27 above, and are therefore likewise rejected.
Regarding independent claim 35, it is substantially similar to independent claim 21 above, and is therefore likewise rejection (i.e., the citations and obviousness rationale).
Regarding claims 36-40, they are substantially similar to claims 22-24 and 26-27 above, and are therefore likewise rejected.
Claim(s) 25 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Keresman-Raj as applied to claims 21-24, 26-31, and 33-40 above, and further in view of Official Notice.
Regarding claim 25, Keresman-Raj does not specify: wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data. However, the examiner hereby takes official notice that that it was well known in the art before the filing date of Applicant’s invention for merchant websites to provide credit history data, personal background data, and/or vehicle insurance data responsive to a purchase. For example, purchasing vehicle insurance from an insurance website would take a user to a coverage page. Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Keresman-Raj to include support for wherein the application view includes at least one of credit history data, personal background data, and vehicle insurance data because design incentives or market forces provided a reason to make an adaptation (i.e., selling credit history, personal background data, and/or vehicle insurance on a website), and the invention resulted from application of the prior knowledge in a predictable manner (the tokenization and substitution in Keresman-Raj is generic to any kind of purchase and merchant website).
Claim 32 is substantially similar to claim 25 above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
