Acknowledgements
This communication is in response to applicant’s response filed on 12/30/2025.
Claims 2, 9, and 16 have been cancelled. Claims 1, 8, and 15 have been amended.
Claims 1, 3-8, 10-15, and 17-20 are pending and have been examined.
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 .
Response to Arguments
Regarding the applicant’s arguments:
Regarding applicant’s arguments, see pgs. 7-9, filed 12/30/2025, with respect to the rejection(s) of claim(s) 1, 8, and 15 under Claim Rejections - 35 USC § 103 that the combination of Ricardo in view of Van Herp in further view of Mushing does not teach the amended limitations “determining a geolocation of the user; comparing the geolocation of the user with historical transaction data for the user; verifying the transaction based on the comparison; causing the mobile device to take a picture of the resource transmission instrument; further verifying the transaction based on the picture” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Walters (US 20220300973). In addition, the addition of the new limitations has resulted in a new Claim Rejections - 35 USC §112(a) rejection. More detail is provided below.
Claim Rejections - 35 USC § 112(a)
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 1, 8, and 15 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. Claims 1, 8, and 15 comprise limitations “prompting a user to choose a method of transaction via the mobile device, wherein the user can select between manual entry of instrument details or a near field communication (NFC) enabled method…upon selection of the NFC enabled method, instructing the user via the mobile device to physically tap or hold a resource transmission instrument within proximity of the mobile device to initiate a secure data exchange.” However, Paragraphs [0030 and 0033] of applicant’s spec. teach geolocation verification and historical transaction data are used to ensure the legitimacy of transactions for non-NFC enabled devices. Therefore, the newly added limitations “determining a geolocation of the user; comparing the geolocation of the user with historical transaction data for the user; verifying the transaction based on the comparison; causing the mobile device to take a picture of the resource transmission instrument; further verifying the transaction based on the picture” are not taught in the written description because geolocation verification and historical transaction data should only be used with non-NFC enabled devices, but the device in claims 1, 8, and 15 is NFC-enabled.
Claims 3-7, 10-14, and 17-20 are rejected based on rejected based claims 1, 8, and 15.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6, 8, 13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Walters (US 20220300973) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783).
Regarding Claims 1, 8, and 15, Ricardo teaches initiating a transaction on a mobile device (Paragraph 0086 teaches the process can be initiated, for example, via a resource provider application stored on the user device); prompting a user to choose a method of transaction via the mobile device, wherein the user can select between manual entry of instrument details or a near field communication (NFC) enabled method (Paragraphs 0086-0087 and 0108-0109 teach a resource provider application can receive input from a user to cause the resource provider application to commence a transaction between the user and the resource provider; the SDK can read the NFC chip of a payment card; for example, the user can navigate the resource provider application installed on the user device, which may display an interface having a selectable “Tap to Pay” button as shown in FIG. 8A; other means of initiating the transaction via the interface are possible; in response to a user selecting “Tap to Pay,” the user device can display an interface that is configured to display transaction information as well as payment options, such as a “Tap to Pay” button; if the user selects the “Tap to Pay” button, a process for completing the transaction with a single payment method can be initiated); creating a secure virtual sandbox environment for the transaction (Paragraphs 0087 and 0113 teach the functionality can be enabled, for example, by the set of platform-specific scripts and can be sandboxed such that the resource provider computer, e.g., via the resource provider application backend 115B does not receive the account credentials read from the payment card; responsive to the first payment method being selected, the resource provider application can initiate the transaction via the SDK; as an example, this may cause the SDK to establish an API or another communication channel with the server computer; as described previously, the SDK may be included as part of the resource provider application provisioned on the user device); upon selection of the NFC enabled method, instructing the user via the mobile device to physically tap or hold a resource transmission instrument within proximity of the mobile device to initiate a secure data exchange (Paragraphs 0073 and 0114 teach requesting, by the first instance of the resource provider application, first account credentials for a user of the first user device; for example, via the first instance of the resource provider application, the user device can display or otherwise provide a prompt to the user; the prompt can instruct the user to, for example, bring a credential storing device near the user device or to “tap” the credential storing device on a particular location of the user device; once the first payment method is selected, the resource provider application can display, via the user device, an interface that may display a prompt to the user to “tap” the card to the user device as shown in FIG. 8B); detecting presence of the resource transmission instrument using an NFC reader embedded in the mobile device and capturing data (Paragraphs 0114 and 0074 teach by “tapping” the payment card (e.g., the credential storing device) the user brings the payment card within range for a sensor of the user device to receive account credentials from the payment card; receiving, by the first instance of the resource provider application using the set of platform-specific scripts, the first account credentials from a credential storing device via near field communication capability of the first user device; as an example, the user can bring the credential storing device near the user device such that a sensor of the user device can read or receive, via near field communication methods, information from the credential storing device, which can include an RFID tag, NFC tag, or other circuitry or device through which information can be transmitted to the user device); encrypting the captured data using a secure encryption protocol (Paragraphs 0116, 0088, and 0095 teach the SDK can read the NFC chip of the first payment card; this functionality can be enabled, for example, by the set of platform-specific scripts and can be sandboxed such that the resource provider computer, e.g., via the resource provider application backend 115B does not receive the account credentials read from the payment card; the account credentials (e.g., PAN, expiration date, and/or CVV code) can be transmitted to the server via a communication channel between the user device and the server computer, which is enabled by the set of platform-specific scripts of the SDK; the transaction processing request message can include a token, certificate key, or other device identifier; there is no transfer of information to the resource provider application backend 115B outside of the SDK; accordingly, security is improved because the user's account credentials are not being stored or transmitted to external systems or environments beyond the server computer); transmitting the encrypted data to a third-party processor for validation and processing (Paragraphs 0078-0079 and 0117 teach transmitting, by the first instance of the resource provider application using the set of platform-specific scripts, the transaction processing request message to the server computer for processing without storing the first account credentials on the first user device; the server computer can obtain an authorization decision associated with the transaction information of the first transaction using the first account credentials on behalf of the resource provider computer; the server computer can identify the first instance of the resource provider application as one of a plurality of access terminals associated with the resource provider computer based on the device certificate or certificate key; the account credentials associated with the first payment card (e.g., PAN, expiration date, and/or CVV code) can be transmitted to the server via a communication channel between the user device and the server computer, which is enabled by the set of platform-specific scripts of the SDK; the account credentials associated with the first payment card can be transmitted as part of a transaction processing request message generated by one or more of the platform-specific scripts of the SDK; in some embodiments, the transaction processing request message can include a token, certificate key, or other device identifier); receiving an approval response from the third-party processor indicating that the transaction is complete (Paragraphs 0090, 0094, and 0119 teach the SDK, can provide a status of the validation to the user, via the resource provider application; the SDK provides the results of the authorization to the user via the resource provider application; for example, the SDK can generate a user interface displaying the results of the authorization and/or a receipt including transaction information; the server computer can validate the user device based on the received token, certificate key, or other device identifier and transmit the results of the validation to the SDK via the communication channel; the SDK, can provide a status of the validation to the user, via the resource provider application); and notifying the user of a completed transaction (Paragraphs 0121-0123 teach the SDK can transmit the transaction information (e.g., the first payment amount and the account credentials associated with the first payment card) to the server computer; the server computer can obtain authorization for the transaction, for example, by communicating with an authorization entity which either authorizes or denies the transaction; the server computer transmits, via the communication channel, the results of the authorization to the SDK; the SDK provides the results of the authorization to the user via the resource provider application; for example, the SDK can generate a user interface displaying the results of the authorization and/or a receipt including transaction information).
However, Ricardo does not explicitly teach determining a geolocation of the user; comparing the geolocation of the user with historical transaction data for the user; verifying the transaction based on the comparison; causing the mobile device to take a picture of the resource transmission instrument; and further verifying the transaction based on the picture.
Walters from same or similar field of endeavor teaches determining a geolocation of the user (Paragraph 0028 teaches a system in accordance with the present disclosure may determine the geographic location of the user device used by the user to initiate the interaction; for example, this location may be determined by identifying and analyzing an internet protocol (“IP”) address corresponding to and associated with user device and provided in the first packet of interaction data; in accordance with the present disclosure, user device may be a smartphone or tablet, and the location of the device may be determined by obtaining location data from a mobile application stored in memory of user device); comparing the geolocation of the user with historical transaction data for the user (Paragraph 0030 teaches the system may receive the response indicative of the location of camera device; the received response is transmitted and received via an encrypted network; having received and determined the locations of both user device and camera device, the system may authenticate camera device as being associated with the user, based at least in part on a comparison of the two locations); verifying the transaction based on the comparison (Paragraph 0031 teaches the system may determine whether user device is within a predetermined proximity of camera device; this predetermined geographical proximity may be a distance determined by, for example, referring to one or more fraud criteria, such as a distance indicative that user device and camera device are at, for example, the same address; the predetermined geographical proximity may be based on one or more known geographic boundaries, such as the known boundaries of a building or buildings previously identified by the user, such as, for example, a user's home, school, or work); causing the mobile device to take a picture of the resource transmission instrument (Paragraphs 0033 and 0024 teach the system having authenticated camera device, the user may be prompted to scan or image authentication item; this prompt may take the form of a GUI discussed in further detail below with respect to FIG. 4; the scanning and/or imaging of authentication item may involve capturing one or more images of authentication item as indicated by the instructions provided; once authentication item has been imaged or scanned by camera device, the image or scan may be transmitted by camera device; camera device may use camera to scan authentication data and/or capture an image of authentication item, and processor may relay the scan and/or image to authentication server via network interface and network; authentication item may be an item or token that can be securely associated with a user, and may take the form of a credit card, driver's license or other identification, security badge, and/or an object chosen by the user or provided by an institution); and further verifying the transaction based on the picture (Paragraph 0034 teaches the system may receive an image or scan of authentication item as captured by authenticated camera device; once received, the system may verify that the user is in possession of authentication item; this verification may be based on, for example, and not limitation, detecting that image or scan was received from camera device and analyzing the image or scan by applying one or more computer vision object identification techniques; by comparing the received image (as analyzed by the application of computer vision object identification techniques) with the authentication item data, the system may be able to confirm both that the image is of authentication item and that the image was captured at the same location as was provided in the interaction data).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified Ricardo to incorporate the teachings of Walters to determine a geolocation of the user; compare the geolocation of the user with historical transaction data for the user; verify the transaction based on the comparison; cause the mobile device to take a picture of the resource transmission instrument; and further verify the transaction based on the picture.
There is motivation to combine Walters into Ricardo because the system is able to determine and verify that the user is in possession of authentication item, and the system may approve the interaction by providing the requested data (approval data) to interaction server and/or user device. By way of illustration, in some embodiments according to the present disclosure, the requested data may be a password or credit card number that interaction server may use to initiate a user login or complete a transaction (Walters Paragraph 0035).
However, the combination of Ricardo and Walters does not explicitly teach deleting the virtual sandbox environment upon completion of the transaction to ensure no residual data remains.
Van Herp from same or similar field of endeavor teaches deleting the virtual sandbox environment upon completion of the transaction to ensure no residual data remains (Paragraphs 0029-0030 teach the method furthermore comprises the step of cancelling the sandbox environment after the life span of the expiration parameter has finished; the sandbox may be created at the moment a transaction has to be performed and as soon as the expiration timer has expired, the sandbox will automatically be destroyed, in this case with all the data).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified Ricardo and Walters to incorporate the teachings of Van Herp to delete the virtual sandbox environment upon completion of the transaction to ensure no residual data remains.
There is motivation to combine Van Herp into Ricardo and Walters because, for additional security, the expiration parameter may be coupled to the existence of the sandbox (Van Herp Paragraph 0030).
However, the combination of Ricardo, Walters, and Van Herp does not explicitly teach logging transaction details in a merchant’s database for record-keeping and compliance.
Mushing from same or similar field of endeavor teaches logging transaction details in a merchant’s database for record-keeping and compliance (Paragraphs 0030 and 0038 teach once the computing device has the secure application program installed thereon and initialized with the back-end system, a user of the computing device (e.g., a small business owner or operator) may utilize the computing device as a point of sale device for an electronic payment transaction; the secure application program may be configured to store and maintain an audit log; the audit log may be a log comprised of entries that detail each action performed by the secure application program or another device or component of the computing device performed on behalf thereof (e.g., the NFC interface, an attestation program, etc.); the audit log may, for example, include entries for each time a secure communication channel is established, payment credentials are received, payment credentials are enciphered, session keys are generated, etc.).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Ricardo, Walters, and Van Herp to incorporate the teachings of Mushing to log transaction details in a merchant’s database for record-keeping and compliance.
There is motivation to combine Mushing into the combination of Ricardo, Walters, and Van Herp because the audit log may be used by the back-end system in attestation of the computing device or other action related to the verification of the security and genuineness of the secure application program and the computing device (Mushing Paragraph 0038).
Regarding Claim 1, Ricardo teaches a system for mobile data transmissions to remote data centers using near field communication, the system comprising: a processing device; a non-transitory storage device containing instructions when executed by the processing device, causes the processing device to perform the steps (Paragraphs 0054-0055 teach a user device may include a processor 110(a) operatively coupled to a computer readable medium 110(c) (e.g., one or more memory chips, etc.), input elements 110(b) such as buttons or the like, one or more sensors 110(d) (e.g., a contact chip reader, a contactless reader, a magnetic stripe reader, etc.), an output device 110(e) (e.g., a display, a speaker, etc.) and a network interface 110(f); a housing may house one or more of these components; the computer readable medium 110(c) may include instructions or code, executable by a processor, e.g., processor 110(a); the instructions may include instructions for communicating with a server computer, e.g., the server computer to complete transactions between a user and a resource provider, and instructions for any other suitable function as described herein).
Regarding Claim 8, Ricardo teaches a computer program product for mobile data transmissions to remote data centers using near field communication, the computer program product comprising a non-transitory computer-readable medium comprising code causing an apparatus to perform the steps (Paragraph 0129 teaches the inventive service may involve implementing one or more functions, processes, operations or method steps; in some embodiments, the functions, processes, operations or method steps may be implemented as a result of the execution of a set of instructions or software code by a suitably-programmed computing device, microprocessor, data processor, or the like; the set of instructions or software code may be stored in a memory or other form of data storage element which is accessed by the computing device, microprocessor, etc.; in other embodiments, the functions, processes, operations or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.).
Regarding Claim 15, Ricardo teaches a method for mobile data transmissions to remote data centers using near field communication (Paragraph 0065 teaches a method 400 according to examples of the present application can be described with respect to FIG. 4).
Regarding Claims 6 and 13, the combination of Ricardo, Walters, Van Herp, and Mushing teaches all the limitations of claims 1 and 8 above; and Ricardo further teaches wherein the user is notified of the completed transaction through a user interface update or a push notification to the mobile device (Paragraph 0123 teaches the SDK provides the results of the authorization to the user via the resource provider application; for example, the SDK can generate a user interface displaying the results of the authorization and/or a receipt including transaction information).
Claims 3, 5, 10, 12, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Walters (US 20220300973) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783) in further view of Poole (US 20220284437).
Regarding Claims 3, 10, and 17, the combination of Ricardo, Walters, Van Herp, and Mushing teaches all the limitations of claims 1, 8, and 15 above; however, the combination does not explicitly teach wherein the NFC reader complies with ISO/IEC 14443 standards for secure data transmission.
Poole from same or similar field of endeavor teaches wherein the NFC reader complies with ISO/IEC 14443 standards for secure data transmission (Paragraph 0031 teaches smartcard reader may be any electronic data input device that reads data from a smart card; smartcard reader may enable reading from contact or contactless smart cards; smartcard reader also may communicate using standard protocols including ISO/IEC 7816, ISO/IEC 14443 and/or the like or proprietary protocols).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Ricardo, Walters, Van Herp, and Mushing to incorporate the teachings of Poole for the NFC reader to comply with ISO/IEC 14443 standards for secure data transmission.
There is motivation to combine Poole into the combination of Ricardo, Walters, Van Herp, and Mushing because the standard defines authentication processes and encryption methods to protect sensitive data on contactless cards.
Regarding Claims 5, 12, and 19, the combination of Ricardo, Walters, Van Herp, and Mushing teaches all the limitations of claims 1, 8, and 15 above; however, the combination does not explicitly teach wherein the third-party payment processor communicates with the merchant's online system to verify transaction details, check availability of funds, and implement security and issue prevention measures.
Poole from same or similar field of endeavor teaches wherein the third-party payment processor communicates with the merchant's online system to verify transaction details, check availability of funds, and implement security and issue prevention measures (Paragraphs 0091-0092 teach the fraud system may receive transaction data associated with an attempted transaction as well as account holder data; the account holder data may be received from the financial institution system, where the account is maintained; attempted transaction data may be used to identify account holder data; for example, a credit card number that is part of the attempted transaction data may be used to identify an account at the financial institution and retrieve account holder data. Account holder data may include, for example, account holder name, address(es), company, telephone number(s), alias, account balance, account available funds, and account associates or other individuals that may be allowed to use the account; attempted transaction data may include, for example, a credit card, debit card or other account identifier, a transaction amount, a merchant name, a merchant location, and a date and time of transaction; upon receipt of the transaction data and account holder data, the fraud system may process the transaction data according to the selected fraud module(s) to determine a fraud module response; for example, fraud system may provide the account holder data and attempted transaction data to one or more of the fraud modules to determine a fraud module response; each of the fraud modules may compare the account holder data and attempted transaction data to respective fraud variables and/or analyze the account holder data and attempted transaction data against stored rules to determine a fraud response; where, for example, a fraud module detects that account holder approval is needed for a particular transaction, the fraud system may transmit a fraud module response to a communications device associated with the account holder at block; for example, the fraud system may transmit an alert to a communications device and await a confirmation and/or other authorization response from the communications device; once the confirmation and/or authorization response is received, the fraud system may authorize the transaction).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Ricardo, Walters, Van Herp, and Mushing to incorporate the teachings of Poole for the third-party payment processor to communicate with the merchant's online system to verify transaction details, check availability of funds, and implement security and issue prevention measures.
There is motivation to combine Poole into the combination of Ricardo, Walters, Van Herp, and Mushing because of the same reasons listed above for claims 2, 9, and 16.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Walters (US 20220300973) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783) in further view of Ronda (US 20140101734).
Regarding Claims 4, 11, and 18, the combination of Ricardo, Walters, Van Herp, and Mushing teaches all the limitations of claims 1, 8, and 15 above; however, the combination does not explicitly teach wherein the encryption protocol used to encrypt the captured payment data is Transport Layer Security (TLS).
Ronda from same or similar field of endeavor teaches wherein the encryption protocol used to encrypt the captured payment data is Transport Layer Security (TLS) (Paragraph 0091 teaches issuer server and application module establish a first secure channel; the first secure channel can be established using a suitable cryptographic protocol, such as Transport Layer Security (TLS) or the like; accordingly, subsequent communications between issuer server and application module are encrypted and take place via the first secure channel).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Ricardo, Walters, Van Herp, and Mushing to incorporate the teachings of Ronda for the encryption protocol used to encrypt the captured payment data to be Transport Layer Security (TLS).
There is motivation to combine Ronda into the combination of Ricardo, Walters, Van Herp, and Mushing because sensitive data, including the initial session data, and other data transmitted via the second secure channel, can be hidden from the application module. Each item of sensitive data may have an associated tag and value, which can be used to identify data that should not be revealed to untrusted or semi-trusted elements, as described herein (Ronda Paragraph 0102).
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Walters (US 20220300973) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783) in further view of Khalid (US 20140138435).
Regarding Claims 7, 14, and 20, the combination of Ricardo, Walters, Van Herp, and Mushing teaches all the limitations of claims 1, 8, and 15 above; however, the combination does not explicitly teach wherein the system is further configured to: prompt the user to proceed with an alternate transaction channel if the NFC read is unsuccessful.
Khalid from same or similar field of endeavor teaches wherein the system is further configured to: prompt the user to proceed with an alternate transaction channel if the NFC read is unsuccessful (Paragraph 0061 teaches in case of an error during the EMV communication, one or more reattempts can be made; if unsuccessful, after closing communication, the mobile device will prompt the user via an output element of the user interface to restart the procedure or manually enter missing information if enough information is not available to proceed with the desired account transaction).
It would have been prima facie obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Ricardo, Walters, Van Herp, and Mushing to incorporate the teachings of Khalid for the system to be further configured to: prompt the user to proceed with an alternate transaction channel if the NFC read is unsuccessful.
There is motivation to combine Khalid into the combination of Ricardo, Walters, Van Herp, and Mushing because the transaction may continue even if the NFC read is unsuccessful.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rule et al. (US 20210004802) teaches a method is provided for displaying an augmented reality image of account information associated with an indicialess transaction card having a card surface with a background pattern applied thereto. A real-time image of the card surface is captured and processed to determine if the background pattern matches a card background pattern associated with a cardholder account. Responsive to a positive determination, communication is established between the user device processor and a card processor carried by the indicialess transaction card. The user device processor receives from the card processor an encrypted verification block and transmits, to an authentication server, an authentication request including the verification block. Responsive to receiving a positive authentication response, the user device constructs an augmented reality image comprising account indicia and displays the augmented reality image superimposed over the real-time image of the background pattern on the card surface of the indicialess transaction card.
Lam et al. (US 20200143377) teaches systems and methods for user identity authentication, for example in know your customer (KYC) procedures are described. A method for user identity authentication comprises: receiving user authentication data from a user device, the user authentication data comprising data indicative of a payment card account or bank account associated with the user, data indicative of an identity card of the user, and an image of the user captured by the user device; determining a name associated with the payment card or bank account associated with the user; determining a name associated with the identity card of the user; performing a name verification by comparing the name associated with the payment card or bank account associated with the user with the name associated with the identity card of the user; performing an image verification by comparing the image of the user with an image associated with the identity card of the user; performing an account verification by generating a transaction on the payment card or bank account associated with the user and receiving an account verification response; and generating a user identity verification indication indicating that the identity of user has been authenticated if the name verification, the image verification and the account verification were successful.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699