Acknowledgements
This communication is in response to applicant’s response filed on 05/19/2026.
Claims 2, 9, and 16 have been cancelled. Claims 21-22 have been added. Claims 1, 8, and 15 have been amended. Claims 1, 3-8, 10-15, and 17-22 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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/19/2026 has been entered.
Response to Arguments
Regarding the applicant’s arguments:
Regarding applicant’s arguments, see pg. 9, filed 05/19/2026, with respect to the rejection(s) of claim(s) 1, 8, and 15 under Claim Rejections - 35 USC § 112(a) that the claim amendments obviate the rejection have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
Regarding applicant’s arguments, see pgs. 9-11, filed 05/19/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 (US 20250111361) in view of Walters (US 20220300973) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783) does not teach the amended limitations “receiving, from a resource provider, a one-time key generated for the transaction, wherein the one-time key is valid only for the specific transaction and becomes invalid once the transaction is completed; transmitting the one-time key to a recipient account to indicate transaction completion without transmitting the resource data to the recipient account” 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 Liao (US 20240193600).
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, 4, 6, 8, 11, 13, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Liao (US 20240193600) 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); 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 encrypting the captured data using a secure encryption protocol; transmitting the encrypted data to a third-party processor for validation and processing; receiving an approval response from the third-party processor indicating that the transaction is complete; receiving, from a resource provider, a one-time key generated for the transaction, wherein the one-time key is valid only for the specific transaction and becomes invalid once the transaction is completed; and transmitting the one-time key to a recipient account to indicate transaction completion without transmitting the resource data to the recipient account.
Liao from same or similar field of endeavor teaches encrypting the captured data using a secure encryption protocol (Paragraph 0085 teaches a client device sends card image data or card data over secure channel to payment processor; a secure channel is a secure (e.g., encrypted) communication link utilized to transfer data between client device and payment processor; for example, secure channel communicates using a Transport Layer Security (TLS) protocol to protect transmitted data through cryptographic measures (e.g., end-to-end encryption)); transmitting the encrypted data to a third-party processor for validation and processing (Paragraphs 0045 and 0085 teach the customer's payment information is sent from the customer's browser to the payment processor, never touching the merchant servers; in this manner, the client-side application electronically sends payment information retrieved from the customer's electronic device to the payment processor; the client-side application does not send the payment information to the server-side application; the client device sends card image data or card data over secure channel to payment processor); receiving an approval response from the third-party processor indicating that the transaction is complete (Paragraphs 0046-0047 teach the payment processor submits the relevant transaction to a processor or directly to the card network for authorization or validation of the payment information; the card network sends the request to the card issuing bank, which authorizes the transaction; the payment processor and the processor/card network function together as a payment processor; in another example embodiment, this step is performed without any communication to the processor/card network; card issuing bank/payment processor authorizes the transaction); receiving, from a resource provider, a one-time key generated for the transaction, wherein the one-time key is valid only for the specific transaction and becomes invalid once the transaction is completed (Paragraph 0047 teaches if authorized, the payment processor will generate and return a secure, a single-use token to the customer's browser that represents the customer's payment information but does not leak any sensitive information); and transmitting the one-time key to a recipient account to indicate transaction completion without transmitting the resource data to the recipient account (Paragraphs 0048-0049 and 0042 teach the payment form is submitted to the merchant servers, including the single-use token; more specifically, the payment processor sends the token to the client-side application, which, in turn, sends the token to the server-side application for use by the server-side application in conducting the transaction; the merchant uses the single-use token to submit a charge request to the payment processor; when added to a merchant's payment form, the JavaScript library automatically intercepts the payment form submission, sending payment information directly to the payment processor and converting it to a single-use token; the single-use token can be safely passed to the merchant's systems and used later to charge customers; merchants have complete control of their customers' payment experience without ever handling, processing, or storing sensitive payment information).
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 Liao to encrypt the captured data using a secure encryption protocol; transmit the encrypted data to a third-party processor for validation and processing; receive an approval response from the third-party processor indicating that the transaction is complete; receive, from a resource provider, a one-time key generated for the transaction, wherein the one-time key is valid only for the specific transaction and becomes invalid once the transaction is completed; and transmit the one-time key to a recipient account to indicate transaction completion without transmitting the resource data to the recipient account.
There is motivation to combine Liao into Ricardo because advantageously provide verification of payment cards that facilitate improved user experiences in completing online transactions in a commercial setting (e.g., purchasing goods or services, and the like). Moreover, it is appreciated that the subject technology reduces utilization of computing resources by forgoing unnecessary verification of payment cards (e.g., where the online transaction has a high probability of not being fraudulent) that results in an improvement of the functionality of a computer (e.g., payment processor or server) (Liao Paragraph 0055).
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 4, 11, and 18, the combination of Ricardo, Liao, 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).
Liao further teaches wherein the encryption protocol used to encrypt the captured payment data is Transport Layer Security (TLS) (Paragraph 0085 teaches client device sends card image data or card data over secure channel to payment processor; secure channel is a secure (e.g., encrypted) communication link utilized to transfer data between client device and payment processor; for example, secure channel communicates using a Transport Layer Security (TLS) protocol to protect transmitted data through cryptographic measures (e.g., end-to-end encryption)).
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, Liao, Van Herp, and Mushing to incorporate the further teachings of Liao for the encryption protocol used to encrypt the captured payment data to be Transport Layer Security (TLS).
There is motivation to further combine Liao into the combination of Ricardo, Liao, Van Herp, and Mushing because TLS encrypts all data sent between the customer’s browser and the payment server, ensuring that sensitive information such as card numbers, expiration dates, and CVV codes cannot be read by attackers intercepting the connection. This prevents eavesdropping on public networks.
Regarding Claims 6 and 13, the combination of Ricardo, Liao, 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 Liao (US 20240193600) 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, Liao, 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, Liao, 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, Liao, 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, Liao, 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, Liao, 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, Liao, Van Herp, and Mushing because of the same reasons listed above for claims 2, 9, and 16.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Liao (US 20240193600) 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, Liao, 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, Liao, 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, Liao, Van Herp, and Mushing because the transaction may continue even if the NFC read is unsuccessful.
Claim 21 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Liao (US 20240193600) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783) in further view of Walters (US 20220300973).
Regarding Claim 21, the combination of Ricardo, Liao, Van Herp, and Mushing teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein upon selection of the manual entry of instrument details, the instructions further cause the processing device to perform the steps of: 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 wherein upon selection of the manual entry of instrument details, the instructions further cause the processing device to perform the steps of: 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 the combination of Ricardo, Liao, Van Herp, and Mushing to incorporate the teachings of Walters for upon selection of the manual entry of instrument details, the instructions to further cause the processing device to perform the steps of: 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 the combination of Ricardo, Liao, Van Herp, and Mushing 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).
Claim 22 are rejected under 35 U.S.C. 103 as being unpatentable over Ricardo (US 20250111361) in view of Liao (US 20240193600) in further view of Van Herp (US 20230144180) in further view of Mushing (US 20220318783) in further view of Ricardo (US 20250348876).
Regarding Claim 22, the combination of Ricardo ‘361, Liao, Van Herp, and Mushing teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein the secure virtual sandbox environment isolates the transaction process such that the resource data is communicated to a resource provider without being exposed to a recipient, and wherein the resource provider verifies authenticity of the transaction and transmits a confirmation to the recipient account without transmitting the resource data.
Ricardo ‘876 from same or similar field of endeavor teaches wherein the secure virtual sandbox environment isolates the transaction process such that the resource data is communicated to a resource provider without being exposed to a recipient, and wherein the resource provider verifies authenticity of the transaction and transmits a confirmation to the recipient account without transmitting the resource data (Paragraphs 0020 0082, and 0088 teach when the user “taps” the payment card to the device, the payment card, which can be equipped with an NFC tag, is brought within range for a sensor or NFC reader of the user device to receive account credential information from the NFC tag of the payment card; the SDK in the ride sharing application sandboxes the account credentials and creates a communication channel directly with the payment processor; the payment processor can then communicate with an issuer of the payment card to determine whether or not to authorize the transaction; the transaction processing request message and/or the first account credentials can bypass the resource provider computer; for example, the first user device can communicate, via the resource provider application, with the server computer to complete the requested transaction, without exposing the user's credential information to another system (e.g., the resource provider computer); in another example, the credential-reading capability is sandboxed within the SDK (e.g., the set of platform-specific scripts), such that the transaction occurs directly through the server computer, bypassing the resource provider computer; the SDK can read the NFC chip of a payment card (e.g., the credential storing device); 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 does not receive the account credentials read from the payment card).
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 ‘361, Liao, Van Herp, and Mushing to incorporate the teachings of Ricardo ‘876 for the secure virtual sandbox environment to isolate the transaction process such that the resource data is communicated to a resource provider without being exposed to a recipient, and wherein the resource provider verifies authenticity of the transaction and transmits a confirmation to the recipient account without transmitting the resource data.
There is motivation to combine Ricardo ‘876 into the combination of Ricardo ‘361, Liao, Van Herp, and Mushing because there is no transfer of information to the resource provider application backend 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 (Ricardo ‘876 Paragraph 0096).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Singh et al. (US 20190228408) teaches a method for facilitating a transaction with a one-time number includes: receiving a first transaction request, wherein the first transaction request includes a plurality of data elements including at least a first data element configured to store a zero transaction amount and a second data element configured to store a primary account number; parsing the primary account number stored in the second data element included in the received first transaction request; generating a one-time value, wherein the one-time value includes a predetermined number of digits and a subset of the predetermined number of digits is a reference to the processing server; storing a data entry comprised of at least the parsed primary account number and the generated one-time value; and transmitting the generated one-time value in response to the received first transaction request.
Lloyd et al. (US 20170091764) teaches embodiments of the invention are directed to systems, methods, and computer program products for non-intrusive geo-location determination associated with transaction authorization. The invention enables one or more transactions initiated by a user to be authenticated and/or validated based on, at least in part, determined locations of the user relative to the locations of the one or more transactions. The user location is determined by transmitting one or more queries to a user device. The system determines the validity of the one or more transactions based on at least comparing the transaction location to the user location, before enabling further processing of the one or more transactions. The present invention is advantageous since it enables authentication/authorization of one or more transactions associated with the user by utilizing the user location, while precluding any inadvertent privacy concerns.
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
Prosecution Insights