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 .
Applicant filed a response dated April 29, 2021 in which claims 1, 4, and 15 have been amended. Therefore, claims 1-20 are currently pending in the application.
Priority
Application 18/967,092 was filed on December 3, 2024.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method and system which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A method, comprising: capturing, via an NFC-enabled device, a QR code enabling a physical payment card payment for an online transaction at an online merchant, wherein the QR code comprises a soft-point-of-sale (soft-POS) instance identifier with details comprising transaction details of the online transaction;
decoding the QR code; and
executing the soft-POS instance by: directing a browser to open on the NFC-enabled device;
sending, via the browser, a soft-POS instance launch request comprising the soft-POS identifier;
receiving, via the browser, an interface for the soft-POS instance and a payment pin;
in response to receiving the payment pin, activating a near field communication (NFC) element of the NFC-enabled device;
receiving, via the NFC element of the NFC-enabled device, a card-present (CP) payment credential from a physical payment card; and
sending, by the soft-POS instance, the CP payment credential and the transaction details associated with the online transaction to a payment network.
Claim 8 recites the limitations of:
A method, comprising:
receiving, at a soft-point-of-sale (soft-POS) service, a soft-POS instance launch request from an NFC-enabled device for an online transaction at an online merchant;
sending a soft-POS instance and a payment pin to a browser of the NFC-enabled device to execute the soft-POS instance via the browser of an NFC-enabled device and activate a near field communication (NFC) element of the NFC-enabled device, wherein the soft-POS instance comprises transaction details of the online transaction; and
receiving, at the soft-POS service, a card-present (CP) payment credential from a physical payment card from the NFC-enabled device.
Claim 14 recites the limitations of:
A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least:
receive, at a soft-POS service, a card-not-present to card-present (CNP-to-CP) transaction type conversion request associated with an online transaction, wherein the CNP-to-CP transaction type conversion request requests to convert a transaction type for the online transaction from a CNP transaction to a CP transaction, and wherein the CNP-to-CP transaction type conversion request comprises transaction details associated with the online transaction at an online merchant;
in response to receiving the CNP-to-CP transaction type conversion request, generate, at the soft-POS service, a soft-POS instance associated with the online transaction;
generate a QR code including a soft-POS instance identifier for the soft-POS instance associated with the online transaction;
send the QR code including the soft-POS instance identifier to a user device, wherein the online transaction was initiated at the user device;
receive, at a soft-point-of-sale (soft-POS) service, a soft-POS instance launch request from an NFC-enabled device for an online transaction at an online merchant;
send a soft-POS instance and a payment pin to a browser of the NFC-enabled device to execute the soft-POS instance via the browser of the NFC-enabled device and activate a near field communication (NFC) element of the NFC-enabled device, wherein the soft-POS instance comprises transaction details of the online transaction; and
receive, at the soft-POS service, a card-present (CP) payment credential from a physical payment card from the NFC-enabled device.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “an NFC-enabled device”, “soft-point-of-sale (soft-POS) instance”, “soft-point-of-sale (soft-POS) service”, “a browser”, “an interface for the soft-POS”, “a near field communication (NFC) element of the NFC-enabled device”, “a payment network”, “A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least:”, and “a user device”, to perform the steps of “decoding”, “executing”, and “generating”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate a financial transaction in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0101] The NFC-enabled device 550 can be a computing device, for example (e.g., user device 354 and NFC-enabled device 358 described with respect to Figures 3A-3B, user device 455 and NFC-enabled device 460 described with respect to Figures 4A-4C). The NFC-enabled device 550 may represent a computing device such as, but not limited to, a personal computer, a reader, a mobile device, a personal digital assistant, a wearable computer, a smart phone, a tablet, a laptop computer (notebook or netbook), a gaming device or console, an entertainment device, a hybrid computer, a desktop computer, or a smart television. [0102] The processor 570 can includeof one or more processors to transform or manipulate data according to the instructions of softwarestored on a storage 572.Examples of processors of the processor 570 can include general purpose central processing units, application specific processors, and logic devices, as well as any other type of processing device, combinations, or variations thereof. [0103] The storage 572 may comprise any computer readable storage media readable by the processor 570 and capable of storing software. Storage 572 may include volatile and nonvolatile memories, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of storage media of storage 572 can include random access memory, read only memory, magnetic disks, optical disks, CDs, DVDs, flash memory, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other suitable storage media. In no case is the storage medium a transitory propagated signal.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “an NFC-enabled device”, “soft-point-of-sale (soft-POS) instance”, “soft-point-of-sale (soft-POS) service”, “a browser”, “an interface for the soft-POS”, “a near field communication (NFC) element of the NFC-enabled device”, “a payment network”, “A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least:”, and “a user device”, to perform the steps of “decoding”, “executing”, and “generating”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, transmitting, and posting to an account ledger, various balance transfer data records in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claim 4 recites the additional elements of “a camera of the NFC-enabled device . . . a graphical user interface (GUI) of a user device”.
Claims 13 and 18 recite the additional elements of “a storage resource”.
Claim 15 recites the additional elements of “a payment network”.
For similar reasons as explained above with regard to claims 1, 8, and 14, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1, 8, and 14.
Dependent claims 2-7, 9-13, and 15-18 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-18 are not patent-eligible.
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, 3-5, 7-10, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over van den Berg, U.S. Patent Application Publication Number 2022/0084008; in view of Griffin, U.S. Patent Application Publication Number 2016/0086164.
As per claim 1,
van den Berg explicitly teaches:
A method, comprising: capturing, via an NFC-enabled device, a QR code enabling a physical payment card payment for an online transaction at an online merchant, wherein the QR code comprises a soft-point-of-sale (soft-POS) instance identifier with details comprising transaction details of the online transaction; decoding the QR code; and executing the soft-POS instance by: directing a browser to open on the NFC-enabled device;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc." "[0145] The communication service 208 may transmit a message (e.g., an SMS message, a notification, an email, etc.) to the buyer mobile device 210. The message may be transmitted based on the mobile phone number and/or any other identifier corresponding to the buyer mobile device 210, such as a device ID or application ID. The message may comprise a hyperlink and/or executable content which may be clicked and/or activated by the buyer after being received by the buyer mobile device 210. In some embodiments, selecting the hyperlink included in the message causes the mobile device 210 to send a request to obtain a payment applet, such as from the server 206. In some embodiments, the sending of the request may also comprise a request to obtain a configuration for conducting a transaction via the payment applet (e.g., an identifier of a transaction, an amount of the transaction, a particular configuration of the payment applet etc.). After receiving the request to obtain the payment applet, the server 206 may transmit and/or remotely install and provision the payment applet on the buyer mobile device 210. In some embodiments, the payment applet may be preinstalled on the buyer mobile device 210 (e.g., be part of the OS of the buyer mobile device 210 and/or be preinstalled by the OS). In some embodiments, if the payment applet is preinstalled, the server 206 might transmit data relating to a configuration to be used by the payment applet to conduct the transaction, instead of transmitting the entire payment applet. In some embodiments, data relating to the configuration to be used by the payment applet may be pushed via push notification or acquired through a reading, by the buyer mobile device 210, of a QR code. Although described herein as a payment applet, it should be understood that a POS application or other payment module may be used.")
sending, via the browser, a soft-POS instance launch request comprising the soft-POS identifier;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 156-160) ("[0156] If the buyer is not a known user, at step 515 a message may be sent to the buyer's mobile device. The message may request that the buyer download a payment applet, POS application, and/or any other application for making a payment. The message may be a text message, notification, email, and/or any other type of message. If the buyer requested to make the purchase at step 505 on their mobile device, the message may be displayed to the buyer by the seller's website." "[0159] At step 525 payment data may be sent to the buyer's mobile device. The payment data may be sent to an application and/or applet of the buyer's mobile device. The payment data may be sent by a server associated with the seller, a website associated with the seller, a server associated with the OS of the mobile device, and/or by any other device. The payment data may include configuration data for the payment applet. The payment data may include a transaction amount, identifier of the seller, text, one or more images, and/or any other data related to the transaction. The payment data may indicate where the transaction should be paid, such as a financial account of the seller. The payment data may configure the payment applet to read a payment card of the buyer. The payment data may include data related to the seller, such as an encryption key corresponding to the seller and/or an entity related to the seller. The encryption key may be used to encrypt all, or a portion, of the data being transmitted at step 540, described below. The seller, or an entity related to the seller, may maintain a key corresponding to the encryption key. The seller's key may be used to decrypt the encrypted data.")
receiving, via the browser, an interface for the soft-POS instance and
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 157-162) ("[0161] At step 535 the buyer's mobile device may read payment card data. The payment card data may be captured from a payment card and/or any other type of payment device, such as a mobile device executing a mobile wallet. The payment card data may be acquired via a contactless interface, such as an NFC reader of the mobile device. The payment card data may be acquired by the payment applet. The payment card data may include any information related to the payment card, such as payment card number, expiration date, name associated with the payment card, and/or any other data. The payment card data may include dynamic, verifiable code (e.g., a cryptogram) which can solely be accessed through a physical interaction with the payment card.")
receiving, via the NFC element of the NFC-enabled device, a card-present (CP) payment credential from a physical payment card; and
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 157-162) ("[0160] At step 530 the buyer's mobile device may request that the buyer present a payment card to the buyer's mobile device. Receipt of the payment data may cause the buyer's mobile device to display the request. A message may be displayed, an interface may be displayed, a notification may be displayed, and/or any other indication may be displayed to the user to request that the user place their payment card near the mobile device so that their mobile device can contactlessly read payment card data from the payment card. The request may be displayed by an OS of the mobile device, by the payment applet, by a POS application, and/or by an application associated with the seller. [0161] At step 535 the buyer's mobile device may read payment card data. The payment card data may be captured from a payment card and/or any other type of payment device, such as a mobile device executing a mobile wallet. The payment card data may be acquired via a contactless interface, such as an NFC reader of the mobile device. The payment card data may be acquired by the payment applet. The payment card data may include any information related to the payment card, such as payment card number, expiration date, name associated with the payment card, and/or any other data. The payment card data may include dynamic, verifiable code (e.g., a cryptogram) which can solely be accessed through a physical interaction with the payment card.")
sending, by the soft-POS instance, the CP payment credential and the transaction details associated with the online transaction to a payment network.
(van den Berg US20220084008 at Figs. 10-15, paras. 162-164) ("[0163] At step 540 the payment card data may be transmitted. The payment card data may be transmitted to a server of the issuer and/or any other entity for performing a transaction. All or a portion of the payment card data may be transmitted. A terminal ID, identifier of the mobile device, data identifying the buyer, data identifying the seller, transaction amount, and/or any other data associated with the transaction may be transmitted.")
van den Berg does not explicitly teach, however, Griffin teaches:
a payment pin; in response to receiving the payment pin, activating a near field communication (NFC) element of the NFC-enabled device;
(Griffin US20160086164 at paras. 17-18, 51-53) ("[0018] In another embodiment, a method of activation and authorization of a near field communication (NFC) enabled device comprises receiving login information from an NFC enabled device; sending packet data via a network in response to receiving the login information from the NFC enabled device; and receiving corresponding data from the NFC enabled device in response to the sending of the packet data, the sending of the packet data and the receiving of the corresponding code facilitates the activation and authorization of the NFC enabled device, and the subsequent activation of the NFC device via a NFC link without further authorization of the NFC enabled device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg and Griffin, because it allows for improved peer-to-peer payments between mobile devices using near field communication in a network environment and an activation and authorization process that may provide security features, as well as check NFC device compatibility and pre-configure the device accordingly. (Griffin at Abstract and paras. 2-18).
As per claim 3,
van den Berg explicitly teaches:
further comprising: during the executing of the soft-POS instance, obtaining an NFC-enabled device identifier associated with the NFC-enabled device.
(van den Berg US20220084008 at Figs. 10-15, paras. 157-159) ("[0158] If the buyer is determined at step 510 to be a known user, an identifier of the buyer's mobile device may be retrieved at step 520. The identifier may be a device ID, application ID, telephone number associated with the mobile device, and/or any other identifier corresponding to the mobile device. If the buyer is known to have the payment applet already installed on their mobile device, the method may proceed to step 525. Otherwise, the method may proceed to step 515 or otherwise cause the payment applet to be installed on the buyer's mobile device.")
As per claim 4,
van den Berg explicitly teaches:
wherein capturing, via the NFC-enabled device, the QR code comprises capturing, via a camera of the NFC-enabled device, the QR code displayed at a graphical user interface (GUI) of a user device, wherein the online transaction was initiated at the user device.
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145) ("[0143] The buyer, using the buyer device 202, provides the mobile phone number to the seller platform 204. Other embodiments may also be envisioned, such as an email to be opened on the buyer mobile device 210 or an audio tone generated by the seller platform 204 which is then received by the buyer mobile device 210 providing that the buyer mobile device 210 has an app to receive and decipher such a sound—e.g. an OS of the buyer mobile device 210 having a built-in decipher application. Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc. The seller platform 204 may already be aware of the mobile device ID or other identifying information of the buyer, such as if the buyer has previously engaged in a transaction with the seller and/or if the buyer is logged in to an account at the seller. In that case, the seller platform 204 may retrieve the mobile device ID and/or other identifying information associated with the buyer.")
As per claim 5,
van den Berg explicitly teaches:
wherein the soft-POS instance is time-limited.
(van den Berg US20220084008 at Figs. 10-15, paras. 145-146) ("[0146] The payment applet, once installed and provisioned (and/or configured as the case may be), allows the buyer mobile device 210 to temporarily (e.g., for a predetermined number of transactions and/or for a predetermined amount of time), or permanently in some embodiments, operate as a mobile point of sale (mPOS) terminal for the seller.")
As per claim 7,
van den Berg does not explicitly teach, however, Griffin teaches:
further comprising: displaying, at the interface for the soft-POS instance at the NFC-enabled device, a personal identification number (PIN) entry request; receiving, at the NFC-enabled device, a PIN entered at the interface of the soft-POS instance; and sending, by the soft-POS instance, the entered PIN to a soft-POS service.
(Griffin US20160086164 at paras. 51, 56) ("[0051] In one embodiment, an initial payment provider application activation process may be required to be completed prior to utilizing the application(s) 126-129 for the first time. In this regard, as shown in FIG. 7, application(s) activation may begin with the user entering login information such as phone number, pin number, email address and/or password, etc., in the mobile device 105, 110. The application forwards the information and a public key (unique identifier) 125 based on the NFC mobile device's chip to the payment provider system 120.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg and Griffin, because it allows for improved peer-to-peer payments between mobile devices using near field communication in a network environment and an activation and authorization process that may provide security features, as well as check NFC device compatibility and pre-configure the device accordingly. (Griffin at Abstract and paras. 2-18).
As per claim 8,
van den Berg explicitly teaches:
A method, comprising: receiving, at a soft-point-of-sale (soft-POS) service, a soft-POS instance launch request from an NFC-enabled device for an online transaction at an online merchant;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 156-160) ("[0156] If the buyer is not a known user, at step 515 a message may be sent to the buyer's mobile device. The message may request that the buyer download a payment applet, POS application, and/or any other application for making a payment. The message may be a text message, notification, email, and/or any other type of message. If the buyer requested to make the purchase at step 505 on their mobile device, the message may be displayed to the buyer by the seller's website." "[0159] At step 525 payment data may be sent to the buyer's mobile device. The payment data may be sent to an application and/or applet of the buyer's mobile device. The payment data may be sent by a server associated with the seller, a website associated with the seller, a server associated with the OS of the mobile device, and/or by any other device. The payment data may include configuration data for the payment applet. The payment data may include a transaction amount, identifier of the seller, text, one or more images, and/or any other data related to the transaction. The payment data may indicate where the transaction should be paid, such as a financial account of the seller. The payment data may configure the payment applet to read a payment card of the buyer. The payment data may include data related to the seller, such as an encryption key corresponding to the seller and/or an entity related to the seller. The encryption key may be used to encrypt all, or a portion, of the data being transmitted at step 540, described below. The seller, or an entity related to the seller, may maintain a key corresponding to the encryption key. The seller's key may be used to decrypt the encrypted data.")
sending a soft-POS instance [and a payment pin] to a browser of the NFC-enabled device to execute the soft-POS instance via the browser of an NFC-enabled device and activate a near field communication (NFC) element of the NFC-enabled device, wherein the soft-POS instance comprises transaction details of the online transaction; and
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 157-162) ("[0161] At step 535 the buyer's mobile device may read payment card data. The payment card data may be captured from a payment card and/or any other type of payment device, such as a mobile device executing a mobile wallet. The payment card data may be acquired via a contactless interface, such as an NFC reader of the mobile device. The payment card data may be acquired by the payment applet. The payment card data may include any information related to the payment card, such as payment card number, expiration date, name associated with the payment card, and/or any other data. The payment card data may include dynamic, verifiable code (e.g., a cryptogram) which can solely be accessed through a physical interaction with the payment card.")
receiving, at the soft-POS service, a card-present (CP) payment credential from a physical payment card from the NFC-enabled device.
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 157-162) ("[0160] At step 530 the buyer's mobile device may request that the buyer present a payment card to the buyer's mobile device. Receipt of the payment data may cause the buyer's mobile device to display the request. A message may be displayed, an interface may be displayed, a notification may be displayed, and/or any other indication may be displayed to the user to request that the user place their payment card near the mobile device so that their mobile device can contactlessly read payment card data from the payment card. The request may be displayed by an OS of the mobile device, by the payment applet, by a POS application, and/or by an application associated with the seller. [0161] At step 535 the buyer's mobile device may read payment card data. The payment card data may be captured from a payment card and/or any other type of payment device, such as a mobile device executing a mobile wallet. The payment card data may be acquired via a contactless interface, such as an NFC reader of the mobile device. The payment card data may be acquired by the payment applet. The payment card data may include any information related to the payment card, such as payment card number, expiration date, name associated with the payment card, and/or any other data. The payment card data may include dynamic, verifiable code (e.g., a cryptogram) which can solely be accessed through a physical interaction with the payment card.")
van den Berg does not explicitly teach, however, Griffin teaches:
and a payment pin
(Griffin US20160086164 at paras. 17-18, 51-53) ("[0018] In another embodiment, a method of activation and authorization of a near field communication (NFC) enabled device comprises receiving login information from an NFC enabled device; sending packet data via a network in response to receiving the login information from the NFC enabled device; and receiving corresponding data from the NFC enabled device in response to the sending of the packet data, the sending of the packet data and the receiving of the corresponding code facilitates the activation and authorization of the NFC enabled device, and the subsequent activation of the NFC device via a NFC link without further authorization of the NFC enabled device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg and Griffin, because it allows for improved peer-to-peer payments between mobile devices using near field communication in a network environment and an activation and authorization process that may provide security features, as well as check NFC device compatibility and pre-configure the device accordingly. (Griffin at Abstract and paras. 2-18).
As per claim 9,
van den Berg explicitly teaches:
further comprising: sending, via a payment network, an authorization request for the online transaction to an issuer, wherein the authorization request comprises the CP payment credential; and receiving, at the soft-POS service via the payment network, authorization approval from the issuer.
(van den Berg US20220084008 at Figs. 10-15, paras. 138-139, 148-149) ("[0138] Once acquired, the payment card data may be securely transmitted to the server 206. The server 206 may execute various steps in collaboration with the ID verification service 214, the communication service 208, the buyer device 202 and/or the buyer mobile device 210 to securely complete a financial transaction between the seller and the buyer. The issuer 216 may approve or decline the transaction. The issuer 216 may determine the amount of funds in the buyer's financial account and determine whether to approve or decline the transaction based on the amount of funds. If the buyer has insufficient funds, the issuer 216 may decline the transaction. If the buyer has sufficient funds, the issuer 216 may approve the transaction. The request for approval may be routed to the issuer 216 via the payment card company 218 and/or financial institution 220. In some embodiments, the buyer mobile device 210 is associated with one or more unique identifiers (ID). Examples of unique IDs may comprise a mobile phone number, a MAC address, a serial number, an ID associated with an operating system (OS) installed on the buyer mobile device 210.")
As per claim 10,
van den Berg explicitly teaches:
further comprising: receiving, at the soft-POS service, a card-not-present to card-present (CNP-to-CP) transaction type conversion request associated with the online transaction, wherein the CNP-to-CP transaction type conversion request requests to convert a transaction type for the online transaction from a CNP transaction to a CP transaction, and wherein the CNP-to-CP transaction type conversion request comprises the transaction details associated with the online transaction at the online merchant;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0152] At step 505 a buyer may request to make a purchase. The buyer may request to make the purchase via a platform of the seller. The buyer may request to make the purchase using a website of the seller, an application of the seller, and/or any other method for performing a purchase. The buyer may be remote from the seller rather than being present in a physical location of the seller, such as a retail store of the seller. [0153] To complete the transaction, the buyer may enter their address, name, telephone number, e-mail address, payment card information, and/or any other information related to the buyer. In some instances all or a portion of the buyer's information may be automatically populated, such as if the buyer's information is saved on the device the buyer is using to make the purchase and/or if the buyer has a pre-existing account with the seller's platform. [0154] After the buyer has requested to make the purchase, a payment request may be generated and/or transmitted. The payment request may be sent to a server, such as the server 206. The payment request may include a transaction amount, text provided by the seller, one or more imaged, and/or an identifier of the seller such as a merchant ID, application programming interface (API) key assigned to the seller, and/or name of the seller.")
in response to receiving the CNP-to-CP transaction type conversion request, generating, at the soft-POS service, the soft-POS instance associated with the online transaction;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0156] If the buyer is not a known user, at step 515 a message may be sent to the buyer's mobile device. The message may request that the buyer download a payment applet, POS application, and/or any other application for making a payment. The message may be a text message, notification, email, and/or any other type of message. If the buyer requested to make the purchase at step 505 on their mobile device, the message may be displayed to the buyer by the seller's website.")
generating a QR code including a soft-POS instance identifier for the soft-POS instance associated with the online transaction; and
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
sending the QR code including the soft-POS instance identifier a user device, wherein the online transaction was initiated at the user device.
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
As per claim 14,
van den Berg explicitly teaches:
A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least: receive, at a soft-POS service, a card-not-present to card-present (CNP-to-CP) transaction type conversion request associated with an online transaction, wherein the CNP-to-CP transaction type conversion request requests to convert a transaction type for the online transaction from a CNP transaction to a CP transaction, and wherein the CNP-to-CP transaction type conversion request comprises transaction details associated with the online transaction at an online merchant;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0152] At step 505 a buyer may request to make a purchase. The buyer may request to make the purchase via a platform of the seller. The buyer may request to make the purchase using a website of the seller, an application of the seller, and/or any other method for performing a purchase. The buyer may be remote from the seller rather than being present in a physical location of the seller, such as a retail store of the seller. [0153] To complete the transaction, the buyer may enter their address, name, telephone number, e-mail address, payment card information, and/or any other information related to the buyer. In some instances all or a portion of the buyer's information may be automatically populated, such as if the buyer's information is saved on the device the buyer is using to make the purchase and/or if the buyer has a pre-existing account with the seller's platform. [0154] After the buyer has requested to make the purchase, a payment request may be generated and/or transmitted. The payment request may be sent to a server, such as the server 206. The payment request may include a transaction amount, text provided by the seller, one or more imaged, and/or an identifier of the seller such as a merchant ID, application programming interface (API) key assigned to the seller, and/or name of the seller.")
in response to receiving the CNP-to-CP transaction type conversion request, generate, at the soft-POS service, a soft-POS instance associated with the online transaction;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0156] If the buyer is not a known user, at step 515 a message may be sent to the buyer's mobile device. The message may request that the buyer download a payment applet, POS application, and/or any other application for making a payment. The message may be a text message, notification, email, and/or any other type of message. If the buyer requested to make the purchase at step 505 on their mobile device, the message may be displayed to the buyer by the seller's website.")
generate a QR code including a soft-POS instance identifier for the soft-POS instance associated with the online transaction;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
send the QR code including the soft-POS instance identifier to a user device, wherein the online transaction was initiated at the user device;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
receive, at a soft-point-of-sale (soft-POS) service, a soft-POS instance launch request from an NFC-enabled device for an online transaction at an online merchant;
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 156-160) ("[0156] If the buyer is not a known user, at step 515 a message may be sent to the buyer's mobile device. The message may request that the buyer download a payment applet, POS application, and/or any other application for making a payment. The message may be a text message, notification, email, and/or any other type of message. If the buyer requested to make the purchase at step 505 on their mobile device, the message may be displayed to the buyer by the seller's website." "[0159] At step 525 payment data may be sent to the buyer's mobile device. The payment data may be sent to an application and/or applet of the buyer's mobile device. The payment data may be sent by a server associated with the seller, a website associated with the seller, a server associated with the OS of the mobile device, and/or by any other device. The payment data may include configuration data for the payment applet. The payment data may include a transaction amount, identifier of the seller, text, one or more images, and/or any other data related to the transaction. The payment data may indicate where the transaction should be paid, such as a financial account of the seller. The payment data may configure the payment applet to read a payment card of the buyer. The payment data may include data related to the seller, such as an encryption key corresponding to the seller and/or an entity related to the seller. The encryption key may be used to encrypt all, or a portion, of the data being transmitted at step 540, described below. The seller, or an entity related to the seller, may maintain a key corresponding to the encryption key. The seller's key may be used to decrypt the encrypted data.")
send a soft-POS instance [and a payment pin] to a browser of the NFC-enabled device to execute the soft-POS instance via the browser of the NFC-enabled device and activate a near field communication (NFC) element of the NFC-enabled device, wherein the soft-POS instance comprises transaction details of the online transaction; and
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 157-162) ("[0161] At step 535 the buyer's mobile device may read payment card data. The payment card data may be captured from a payment card and/or any other type of payment device, such as a mobile device executing a mobile wallet. The payment card data may be acquired via a contactless interface, such as an NFC reader of the mobile device. The payment card data may be acquired by the payment applet. The payment card data may include any information related to the payment card, such as payment card number, expiration date, name associated with the payment card, and/or any other data. The payment card data may include dynamic, verifiable code (e.g., a cryptogram) which can solely be accessed through a physical interaction with the payment card.")
receive, at the soft-POS service, a card-present (CP) payment credential from a physical payment card from the NFC-enabled device.
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 157-162) ("[0160] At step 530 the buyer's mobile device may request that the buyer present a payment card to the buyer's mobile device. Receipt of the payment data may cause the buyer's mobile device to display the request. A message may be displayed, an interface may be displayed, a notification may be displayed, and/or any other indication may be displayed to the user to request that the user place their payment card near the mobile device so that their mobile device can contactlessly read payment card data from the payment card. The request may be displayed by an OS of the mobile device, by the payment applet, by a POS application, and/or by an application associated with the seller. [0161] At step 535 the buyer's mobile device may read payment card data. The payment card data may be captured from a payment card and/or any other type of payment device, such as a mobile device executing a mobile wallet. The payment card data may be acquired via a contactless interface, such as an NFC reader of the mobile device. The payment card data may be acquired by the payment applet. The payment card data may include any information related to the payment card, such as payment card number, expiration date, name associated with the payment card, and/or any other data. The payment card data may include dynamic, verifiable code (e.g., a cryptogram) which can solely be accessed through a physical interaction with the payment card.")
van den Berg does not explicitly teach, however, Griffin teaches:
and a payment pin
(Griffin US20160086164 at paras. 17-18, 51-53) ("[0018] In another embodiment, a method of activation and authorization of a near field communication (NFC) enabled device comprises receiving login information from an NFC enabled device; sending packet data via a network in response to receiving the login information from the NFC enabled device; and receiving corresponding data from the NFC enabled device in response to the sending of the packet data, the sending of the packet data and the receiving of the corresponding code facilitates the activation and authorization of the NFC enabled device, and the subsequent activation of the NFC device via a NFC link without further authorization of the NFC enabled device.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg and Griffin, because it allows for improved peer-to-peer payments between mobile devices using near field communication in a network environment and an activation and authorization process that may provide security features, as well as check NFC device compatibility and pre-configure the device accordingly. (Griffin at Abstract and paras. 2-18).
As per claim 15,
van den Berg explicitly teaches:
wherein the instructions further direct the processing system to: send, via a payment network, an authorization request for the online transaction to an issuer, wherein the authorization request comprises the CP payment credential; and receive, at the soft-POS service via the payment network, authorization approval from the issuer.
(van den Berg US20220084008 at Figs. 10-15, paras. 138-139, 148-149) ("[0138] Once acquired, the payment card data may be securely transmitted to the server 206. The server 206 may execute various steps in collaboration with the ID verification service 214, the communication service 208, the buyer device 202 and/or the buyer mobile device 210 to securely complete a financial transaction between the seller and the buyer. The issuer 216 may approve or decline the transaction. The issuer 216 may determine the amount of funds in the buyer's financial account and determine whether to approve or decline the transaction based on the amount of funds. If the buyer has insufficient funds, the issuer 216 may decline the transaction. If the buyer has sufficient funds, the issuer 216 may approve the transaction. The request for approval may be routed to the issuer 216 via the payment card company 218 and/or financial institution 220. In some embodiments, the buyer mobile device 210 is associated with one or more unique identifiers (ID). Examples of unique IDs may comprise a mobile phone number, a MAC address, a serial number, an ID associated with an operating system (OS) installed on the buyer mobile device 210.")
Claims 2, 11-12, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over van den Berg, U.S. Patent Application Publication Number 2022/0084008; in view of Griffin, U.S. Patent Application Publication Number 2016/0086164; in view of Drechsler, U.S. Patent Application Publication Number 2024/0305628.
As per claim 2,
van den Berg explicitly teaches:
wherein the details encoded by the QR code further comprise
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
van den Berg and Griffin do not explicitly teach, however, Drechsler teaches:
a mixed CNP/CP flag indicating that a transaction type of the online transaction is a CNP-to-CP transaction type.
(Drechsler US20240305628 at paras. 92-94, 115-117) ("[0093] In some embodiments, the access device (or another resource provider computer) sends an authorization request message for a card present (CP) transaction to a processing network computer via a transport computer associated with an acquirer. The payment processing network may convert the authorization request message from a first transaction data format (e.g., a CP transaction format) to a second transaction data format (e.g., a card-not-present (CNP) transaction format). The authorization request message may be then sent to an authorizing entity computer (e.g., operated by or on behalf of an issuer associated with the credential). According to various embodiments, the processing network computer may include a transaction-by-identity identifier (e.g. flag) to the authorization request message. Upon receiving a transaction authorization response message from the issuer for the CNP transaction, the processing network computer may convert the authorization response message from the second transaction data format to the first transaction data format before sending the response to the resource provider (e.g., the access device) via the transport computer." "[0116] At step 14, the processing network computer 116 may transmit the authorization response message to the transport computer 114. It should be appreciated that, in some embodiments, the processing network computer 116 may convert the authorization response message from a second transaction data format to a first transaction data format prior to the transmission.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, and Drechsler, because it allows for improved systems to enable a user to conduct a transaction using their credentials stored on a secure server computer (e.g., a computer associated with a partner such as another merchant) by merely presenting their authentication data at a physical location via an auxiliary device. (Drechsler at Abstract and paras. 2-6).
As per claim 11,
van den Berg explicitly teaches:
wherein generating, at the soft-POS service, the QR code comprises [including the mixed CNP/CP flag] in the QR code.
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
van den Berg and Griffin do not explicitly teach, however, Drechsler teaches:
further comprising: in response to receiving, at the soft-POS service, the CNP-to-CP transaction type conversion request, generating a mixed CNP/CP flag indicating that a transaction type of the online transaction is a CNP-to-CP transaction type;
(Drechsler US20240305628 at paras. 92-94, 115-117) ("[0093] In some embodiments, the access device (or another resource provider computer) sends an authorization request message for a card present (CP) transaction to a processing network computer via a transport computer associated with an acquirer. The payment processing network may convert the authorization request message from a first transaction data format (e.g., a CP transaction format) to a second transaction data format (e.g., a card-not-present (CNP) transaction format). The authorization request message may be then sent to an authorizing entity computer (e.g., operated by or on behalf of an issuer associated with the credential). According to various embodiments, the processing network computer may include a transaction-by-identity identifier (e.g. flag) to the authorization request message. Upon receiving a transaction authorization response message from the issuer for the CNP transaction, the processing network computer may convert the authorization response message from the second transaction data format to the first transaction data format before sending the response to the resource provider (e.g., the access device) via the transport computer." "[0116] At step 14, the processing network computer 116 may transmit the authorization response message to the transport computer 114. It should be appreciated that, in some embodiments, the processing network computer 116 may convert the authorization response message from a second transaction data format to a first transaction data format prior to the transmission.")
including the mixed CNP/CP flag
(Drechsler US20240305628 at paras. 92-94, 115-117) ("[0093] the processing network computer may include a transaction-by-identity identifier (e.g. flag) to the authorization request message.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, and Drechsler, because it allows for improved systems to enable a user to conduct a transaction using their credentials stored on a secure server computer (e.g., a computer associated with a partner such as another merchant) by merely presenting their authentication data at a physical location via an auxiliary device. (Drechsler at Abstract and paras. 2-6).
As per claim 12,
van den Berg explicitly teaches:
wherein the transaction details comprise a user device identifier associated with the user device.
(van den Berg US20220084008 at Figs. 10-15, paras. 128-130) ("[0129] The issuer 216 may provide the buyer with a token to provide authentication during financial transactions. Such a token may be, for example, a payment card 212 and/or a secured unique identification component which may be embedded in the buyer device 202 and/or the buyer mobile device 210 (e.g. as a virtualized payment card in a mobile wallet), including but not limited to, a quick response (QR) code, a barcode, an alphanumeric code, an audible sound, an image, a NFC or Bluetooth communication, or any other audio/visual/digital ‘token’ which may be communicated between buyer device 202 or buyer mobile device 210 and the server 206.")
As per claim 16,
van den Berg explicitly teaches:
wherein the QR code
(van den Berg US20220084008 at Figs. 10-15, paras. 140-145, 152-157) ("[0143] Other embodiments may also include a code to be entered on a website accessed through the buyer mobile device 210, a QR code to scan on the seller site by the buyer mobile device 210, etc.")
van den Berg and Griffin do not explicitly teach, however, Drechsler teaches:
wherein the instructions to receive, at the soft-POS service, the CNP-to-CP transaction type conversation request further directs the processing system to: generate a mixed CNP/CP flag indicating that a transaction type of the online transaction is a CNP-to-CP transaction type;
(Drechsler US20240305628 at paras. 92-94, 115-117) ("[0093] In some embodiments, the access device (or another resource provider computer) sends an authorization request message for a card present (CP) transaction to a processing network computer via a transport computer associated with an acquirer. The payment processing network may convert the authorization request message from a first transaction data format (e.g., a CP transaction format) to a second transaction data format (e.g., a card-not-present (CNP) transaction format). The authorization request message may be then sent to an authorizing entity computer (e.g., operated by or on behalf of an issuer associated with the credential). According to various embodiments, the processing network computer may include a transaction-by-identity identifier (e.g. flag) to the authorization request message. Upon receiving a transaction authorization response message from the issuer for the CNP transaction, the processing network computer may convert the authorization response message from the second transaction data format to the first transaction data format before sending the response to the resource provider (e.g., the access device) via the transport computer." "[0116] At step 14, the processing network computer 116 may transmit the authorization response message to the transport computer 114. It should be appreciated that, in some embodiments, the processing network computer 116 may convert the authorization response message from a second transaction data format to a first transaction data format prior to the transmission.")
comprises the mixed CNP/CP flag.
(Drechsler US20240305628 at paras. 92-94, 115-117) ("[0093] the processing network computer may include a transaction-by-identity identifier (e.g. flag) to the authorization request message.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, and Drechsler, because it allows for improved systems to enable a user to conduct a transaction using their credentials stored on a secure server computer (e.g., a computer associated with a partner such as another merchant) by merely presenting their authentication data at a physical location via an auxiliary device. (Drechsler at Abstract and paras. 2-6).
As per claim 17,
van den Berg explicitly teaches:
wherein the transaction details comprise a user device identifier associated with the user device.
(van den Berg US20220084008 at Figs. 10-15, paras. 128-130) ("[0129] The issuer 216 may provide the buyer with a token to provide authentication during financial transactions. Such a token may be, for example, a payment card 212 and/or a secured unique identification component which may be embedded in the buyer device 202 and/or the buyer mobile device 210 (e.g. as a virtualized payment card in a mobile wallet), including but not limited to, a quick response (QR) code, a barcode, an alphanumeric code, an audible sound, an image, a NFC or Bluetooth communication, or any other audio/visual/digital ‘token’ which may be communicated between buyer device 202 or buyer mobile device 210 and the server 206.")
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over van den Berg, U.S. Patent Application Publication Number 2022/0084008; in view of Griffin, U.S. Patent Application Publication Number 2016/0086164; in view of Kothandaraman, U.S. Patent Application Publication Number 2012/0005074.
As per claim 6,
van den Berg explicitly teaches:
further comprising: receiving, by the soft-POS instance, confirmation of approval of the online transaction; and
(van den Berg US20220084008 at Figs. 10-15, paras. 175-176) ("[0176] FIG. 15 illustrates a notification presented by the buyer's mobile device and the seller's website indicating that transaction result. FIG. 15 illustrates interfaces that may be displayed at step 560 of the method 500 and step 760 of the method 700.")
van den Berg and Griffin do not explicitly teach, however, Kothandaraman teaches:
in response to receiving, by the soft-POS instance, confirmation of the approval of the online transaction, closing the soft-POS instance at the NFC-enabled device.
(Kothandaraman US20120005074 at paras. 21-29) ("[0028] After payment, the user is returned to the original content site at step 116. The user may manually exit or close the payment window or select a link in the payment window. In another embodiment, after payment is processed, the payment window may automatically close and return the user to the original content site or page. Communication of the above information may be by any means, such as through the Internet, Bluetooth, NFC, or a wired connection, using suitable components such as antennas and processors.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, and Kothandaraman, because it allows for improved systems wherein a user can easily make a payment from a content site and the user can quickly return to the original content. (Kothandaraman at Abstract and paras. 2-10, 29).
Claims 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over van den Berg, U.S. Patent Application Publication Number 2022/0084008; in view of Griffin, U.S. Patent Application Publication Number 2016/0086164; in view of Drechsler, U.S. Patent Application Publication Number 2024/0305628; in view of Grassadonia, U.S. Patent Application Publication Number 2022/0188782.
As per claim 13,
van den Berg explicitly teaches:
the user device identifier, and
(van den Berg US20220084008 at Figs. 10-15, paras. 128-130) ("[0129] The issuer 216 may provide the buyer with a token to provide authentication during financial transactions. Such a token may be, for example, a payment card 212 and/or a secured unique identification component which may be embedded in the buyer device 202 and/or the buyer mobile device 210 (e.g. as a virtualized payment card in a mobile wallet), including but not limited to, a quick response (QR) code, a barcode, an alphanumeric code, an audible sound, an image, a NFC or Bluetooth communication, or any other audio/visual/digital ‘token’ which may be communicated between buyer device 202 or buyer mobile device 210 and the server 206.")
the NFC-enabled device identifier.
(van den Berg US20220084008 at Figs. 10-15, paras. 157-159) ("[0158] If the buyer is determined at step 510 to be a known user, an identifier of the buyer's mobile device may be retrieved at step 520. The identifier may be a device ID, application ID, telephone number associated with the mobile device, and/or any other identifier corresponding to the mobile device. If the buyer is known to have the payment applet already installed on their mobile device, the method may proceed to step 525. Otherwise, the method may proceed to step 515 or otherwise cause the payment applet to be installed on the buyer's mobile device.")
van den Berg and Griffin do not explicitly teach, however, Drechsler teaches:
the mixed CNP/CP flag,
(Drechsler US20240305628 at paras. 92-94, 115-117) ("[0093] the processing network computer may include a transaction-by-identity identifier (e.g. flag) to the authorization request message.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, and Drechsler, because it allows for improved systems to enable a user to conduct a transaction using their credentials stored on a secure server computer (e.g., a computer associated with a partner such as another merchant) by merely presenting their authentication data at a physical location via an auxiliary device. (Drechsler at Abstract and paras. 2-6).
van den Berg, Griffin, and Drechsler do not explicitly teach, however, Grassadonia teaches:
wherein receiving, at the soft-POS service, the CP payment credential from the physical payment card from the NFC-enabled device comprises receiving an NFC-enabled device identifier associated with the NFC-enabled device, further comprising: storing, at a storage resource, the CP payment credential,
(Grassadonia US20220188782 at paras. 128-130) ("[0129] Each of the DBs 620, 622, and 624 can include, for example, one or more hard drives (which may be further coupled together using RAID-0, 1, 5, 10, etc.), a centralized or distributed data cluster, a cloud-storage service provider, or other suitable storage systems suitable for storing digital data. The DB 622 can store various fields of data, such as user identifiers (IDs) (e.g., email addresses, telephone numbers, usernames, payment proxies associated with the customers and merchants (e.g., $alex), device IDs, etc.), user profile information, shipping address, billing address, risk score associated with a customer or a merchant, where the risk score indicates the likelihood of entering a fraudulent transactions, and/or the like. The DBs may also include an indicator or flag to indicate whether a payment transaction was an offline transaction or an online transaction. In other words, whether the customer device or the POS terminal participating in a payment transaction was offline. The DB 622 can store various fields of data, such as user identifiers associated with payment cards, payment card/account numbers, expiration dates, card/account type, CVVs, billing addresses, and/or the like. The DB 624 can store various fields of data, such as transaction identifiers (IDs), user identifiers (IDs), transaction dates/times, amounts, transaction participant identification information (e.g., email addresses or telephone numbers associated with the senders and recipients of money transfer transactions), and/or the like.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, Drechsler, and Grassadonia, because it allows for improved systems for providing security and risk-rating features to customers who utilize mobile devices to conduct transactions, the security features protecting the merchant from fraudulent transactions.. (Grassadonia at Abstract and paras. 30).
As per claim 18,
van den Berg explicitly teaches:
the user device identifier, and
(van den Berg US20220084008 at Figs. 10-15, paras. 128-130) ("[0129] The issuer 216 may provide the buyer with a token to provide authentication during financial transactions. Such a token may be, for example, a payment card 212 and/or a secured unique identification component which may be embedded in the buyer device 202 and/or the buyer mobile device 210 (e.g. as a virtualized payment card in a mobile wallet), including but not limited to, a quick response (QR) code, a barcode, an alphanumeric code, an audible sound, an image, a NFC or Bluetooth communication, or any other audio/visual/digital ‘token’ which may be communicated between buyer device 202 or buyer mobile device 210 and the server 206.")
the NFC-enabled device identifier.
(van den Berg US20220084008 at Figs. 10-15, paras. 157-159) ("[0158] If the buyer is determined at step 510 to be a known user, an identifier of the buyer's mobile device may be retrieved at step 520. The identifier may be a device ID, application ID, telephone number associated with the mobile device, and/or any other identifier corresponding to the mobile device. If the buyer is known to have the payment applet already installed on their mobile device, the method may proceed to step 525. Otherwise, the method may proceed to step 515 or otherwise cause the payment applet to be installed on the buyer's mobile device.")
van den Berg, Griffin, and Drechsler do not explicitly teach, however, Grassadonia teaches:
wherein the instructions to receive, at the soft-POS service, the CP payment credential from the physical payment card from the NFC-enabled device further direct the processing system to receive a NFC-enabled device identifier associated with the NFC-enabled device, wherein the instructions further direct the processing system to: store, at a storage resource, the CP payment credential,
(Grassadonia US20220188782 at paras. 128-130) ("[0129] Each of the DBs 620, 622, and 624 can include, for example, one or more hard drives (which may be further coupled together using RAID-0, 1, 5, 10, etc.), a centralized or distributed data cluster, a cloud-storage service provider, or other suitable storage systems suitable for storing digital data. The DB 622 can store various fields of data, such as user identifiers (IDs) (e.g., email addresses, telephone numbers, usernames, payment proxies associated with the customers and merchants (e.g., $alex), device IDs, etc.), user profile information, shipping address, billing address, risk score associated with a customer or a merchant, where the risk score indicates the likelihood of entering a fraudulent transactions, and/or the like. The DBs may also include an indicator or flag to indicate whether a payment transaction was an offline transaction or an online transaction. In other words, whether the customer device or the POS terminal participating in a payment transaction was offline. The DB 622 can store various fields of data, such as user identifiers associated with payment cards, payment card/account numbers, expiration dates, card/account type, CVVs, billing addresses, and/or the like. The DB 624 can store various fields of data, such as transaction identifiers (IDs), user identifiers (IDs), transaction dates/times, amounts, transaction participant identification information (e.g., email addresses or telephone numbers associated with the senders and recipients of money transfer transactions), and/or the like.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of van den Berg, Griffin, Drechsler, and Grassadonia, because it allows for improved systems for providing security and risk-rating features to customers who utilize mobile devices to conduct transactions, the security features protecting the merchant from fraudulent transactions.. (Grassadonia at Abstract and paras. 30).
Response to Arguments
Applicant’s arguments filed on May 6, 2026 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1-18, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
Examiner disagrees, however, and notes that the claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate a financial transaction. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea.
Regarding the applicant's argument that the amended features would integrate the abstract idea into a practical application, the examiner respectfully disagrees.
Examiner that the additional elements of the computer system - a “an NFC-enabled device”, “soft-point-of-sale (soft-POS) instance”, “soft-point-of-sale (soft-POS) service”, “a browser”, “an interface for the soft-POS”, “a near field communication (NFC) element of the NFC-enabled device”, “a payment network”, “A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least:”, and “a user device”, to perform the steps of “decoding”, “executing”, and “generating”, in all steps is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The claims at issue covers collecting, analyzing, and transmitting data to facilitate a financial transaction. The claims invoke the “an NFC-enabled device”, “soft-point-of-sale (soft-POS) instance”, “soft-point-of-sale (soft-POS) service”, “a browser”, “an interface for the soft-POS”, “a near field communication (NFC) element of the NFC-enabled device”, “a payment network”, “A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least:”, and “a user device”, to perform the steps of “decoding”, “executing”, and “generating” merely as tools to execute the abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a certain method of organizing human activity or mental process or mathematical calculation) does not integrate a judicial exception into a practical application. (MPEP 2106.05 (f))
Additionally, Examiner notes that, the stated problems of insecure financial transactions is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of performing more efficient financial transaction is part of the abstract idea, as it is merely involves collecting, analyzing, and transmitting data to facilitate a financial transaction. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea.
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the additional elements do not amount to an inventive concept. The additional elements of the computer system - “an NFC-enabled device”, “soft-point-of-sale (soft-POS) instance”, “soft-point-of-sale (soft-POS) service”, “a browser”, “an interface for the soft-POS”, “a near field communication (NFC) element of the NFC-enabled device”, “a payment network”, “A system comprising: a processing system; one or more storage media; and instructions stored on the one or more storage media that, when executed by the processing system, direct the processing system to at least:”, and “a user device”, to perform the steps of “decoding”, “executing”, and “generating” are merely generic computer components performing their well-known basic functions of collecting, analyzing, and transmitting data to facilitate a financial transaction. Per the specification, the recited computer elements and machine learning steps and model are described only at a high level of generality, (see Spec. at paras. [0101]-[0103]). In view of the specification, the application of the computer elements and is merely being applied to the abstract idea.
The other limitations which are simply supporting the abstract idea correspond to insignificant extra-solution activity which do not transform the abstract idea into a patent eligible subject matter. Also, the functionality here is already present in the recited hardware, which is merely routine and conventional. Collecting, analyzing, and transmitting data is routine and conventional. There is no technological problem or solution identified. This is merely a business solution to transfer data between devices. (MPEP 2106.05 (f))
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-18, Examiner notes the following:
Applicant’s arguments are not persuasive because they rely on isolated embodiments of van den Berg rather than the teachings of van den Berg as a whole. Van den Berg expressly discloses browser-based embodiments and/or application-based embodiments (see e.g., paras. 135, 143). Additionally, Applicant’s arguments address limitations that are not claimed, e.g., “executing a transaction within a transient browser session without installation” or “a transient, browser-executed soft-POS instance” are not recited in the claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights