Detailed Action
Claims 27-46 are pending and are 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 .
Status of Claims
Claims 27, 29,-38, 40-42, and 44-46 are currently amended.
Response to Remarks
35 U.S.C. § 101
Remark 1: Applicant argues the claims integrate single-user virtual cards into a practical digital-wallet architecture rather than merely reciting card management. Applicant contends the zero balance card improves security because the card stored on the device has no intrinsic monetary value and only becomes useful after issuer approval of a specific POS transaction. Applicant further argues that pre-positioning the zero-balance card in the wallet improves POS efficiency by avoiding on-the-fly card generation and reducing transaction latency.
Response to Remark 1: The rejection is maintained because the claims remain directed to the commercial practice of approving, funding, and canceling a single use virtual payment credential, which is a certain method of organizing human activity. The recited zero-balance, single-use, pre-positioning, issuer approval, and cancellation features are payment rules that limit financial risk and govern transaction flow, not improvements to the operation of the computer, wallet, POS terminal, or network itself. Indeed, the claim use generic payment components as tools to implement the abstract payment lifecycle, and therefore do not integrate the judicial exception into a practical application.
Remark 2: Applicant argues that, even if the claims recite an abstract idea, the ordered combination amounts to significantly more because it is allegedly not well-understood, routine, or conventional. Applicant identifies the inventive concept as the combination of zero-balance virtual card, location-based card-number generation, unrestricted later usage, pre-positioning in the digital wallet, funding only upon POS request, and cancellation after single use. Applicant further asserts that dependent limitations such as NFC transfer, territory-based fraud detection, and location-unit data provide technical implementation details.
Response to Remark 2: The rejection is maintained because the claim limitations recite conventional payment-network functions, issuing credentials, storing them in a wallet, receiving an authorization request, checking funds, transferring value, and cancelling the credential, performed by generic servers, wallet software, POS terminals, and communication links. The alleged benefits of security, fraud reduction, and speed arise from the abstract business rules themselves, not from any unconventional technological mechanism or improvement to computer functionality.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “As amended, claim 27 recites a system that issues a virtual single-use payment card having a zero-balance where the location is used as a basis for generating a number of the card, while the card's subsequent usage is unrestricted to the location. This card is downloaded to the wallet and later used to initiate a transaction, with the issuer server approving the transaction based on the user's available funds. . . Fonseca does not teach or suggest a "zero-balance" card. The OTVCN in Fonseca is inherently tied to a pre-authorized simulation of an installment plan. It represents a pre- approved line of credit for that specific purchase amount and plan. . . . Fonseca does not teach using location as a basis for generating the card number itself, while allowing unrestricted usage. Fonseca merely suggests that location data could optionally be transmitted to be used "in the determination of suitable installment conditions, and/or in the updating of the consumer risk profile" (Fonseca, [0051]). This is fundamentally different from the claimed invention, where the location is a direct input to the algorithm that generates the card number. Furthermore, because Fonseca's OTVCN is tied to a specific merchant transactor its usage is inherently restricted to that transaction, not unrestricted.” (id).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Fonseca, Mendes, McGuiness, and Redberg) still teach the currently amended independent claims, as shown at least in paragraphs 35-36-, 51, 59, and 64 of Fonseca, and as further outlined in paragraph 35 of this action. Indeed, Fonseca teaches the single-use virtual card framework, including generation and transmission of a one-time virtual card number to a user device, use of that credential in a POS transaction, issuer authorization, and settlement. Fonseca teaches a virtual credential that does itself carry stored funds but is authorized and funded only when the issuer approves a specific transaction request. Accordingly, this contention is unpersuasive.
Claim Rejections - 35 USC § 101
Claims 27-46 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Claims 27-37 are directed to a computer-implemented system/apparatus (i.e., machine, and manufacture). Claims 38-46 are directed to a non-transitory computer-readable storage medium (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claims 27 and 38 and recite (i.e., sets forth or describes) an abstract idea of an issuing device approving and canceling a single-use virtual card.
But for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Here, the claim limitations reciting the abstract idea of an issuing device approving and canceling a single-use virtual card are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations recite commercial or legal interactions, as they recite sales activities or behaviors (e.g., sale activities/behaviors of digital wallets).
More specifically, the following underlined claim elements recite the abstract idea(s) while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
Claim 27:
A system for making payments at a point of sale (POS) comprising an issuer server and a digital wallet application on a computing device, wherein the issuer server is configured to:
issue a virtual single-use payment card having a zero-balance associated with a location of the computing device, wherein the location is used as a basis for generating a number of the virtual single-use payment card, and wherein subsequent usage of the virtual single-use payment card is unrestricted to the location;
download the virtual single-use payment card having the zero-balance to the digital wallet application installed on the computing device;
receive a single transaction approval request from a payment terminal at the point of sale (POS) which is initiated by the digital wallet application on the computing device, wherein the single transaction request comprises at least a unique identifier of the virtual single-use payment card, merchant details and a transaction amount;
send an approval for the single transaction approval request to the payment terminal at the POS based on available funds of a user account linked to the virtual single-use payment card and transfer the transaction amount to the merchant; and
after a completion of the transaction, change a status of the virtual single-use payment card to canceled.
Claim 38:
A product comprising one or more tangible computer-readable non-transitory storage media comprising program instructions for making payments with a digital wallet application, wherein execution of the program instructions by one or more processors of an issuer server comprising:
issuing a virtual single-use payment card having a zero-balance associated with a location of the computing device, wherein the location is used as a basis for generating a number of the virtual single-use payment card, and wherein subsequent usage of the virtual single-use payment card is unrestricted to the location;
downloading the virtual single-use payment card having the zero-balance to the digital wallet application installed on the computing device;
receiving a single transaction approval request from a payment terminal at a point of sale which is initiated by the digital wallet application, wherein the single transaction request comprises at least a unique identifier of the virtual single-use payment card, merchant details and a transaction amount;
sending an approval for the single transaction approval request to the payment terminal at the point of sale based on available funds of a user account linked to the virtual single-use payment card and transferring the transaction amount to a merchant; and
after a completion of the transaction, changing a status of the virtual single-use payment card to cancelled.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claims 27 and 38 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements (“digital wallet”, “computing device”, etc) merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claims 27 and 38, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea.
Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims
Claims 28-37, and 39-46 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claims 28-37, and 39-46 further recite the abstract idea of an issuing device approving and canceling a single-use virtual card. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claim 28 and 39 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the single transaction approval request is transmitted to the issuer server after being verified by a payment server.
Claim 29 and 40 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the issuer server is configured to instruct the digital wallet application to remove the virtual single-use payment card after the single transaction approval request is declined.
Claim 30 and 41 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein when the issuer server is configured to:
receive a new location from the computing device when the computing device is in the location not associated with the virtual single-use payment card;
change the status of the virtual single-use payment card to cancelled; and
download a new virtual single-use payment card associated with the new location of the computing device.
Claim 31 and 42 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the issuer server is configured to download a new virtual single-use payment card associated with the location after the completion of the transaction.
Claim 32 and 43 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the issuer server is configured to receive the location from a location unit of the computing device and determine a number of the virtual single-use payment card based on the location.
Claim 33 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the virtual single-use payment card comprises a payment card number according to a Europay, Mastercard, Visa (EMV) standard based on the location.
Claim 34 and 45 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the virtual single-use payment card comprises a credit card number, a credit card date of issue, and a credit card security code.
Claim 35 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the virtual single-use payment card comprises user data.
Claim 36 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the issuer server is configured to transfer virtual single-use payment card data to the payment terminal by using a near field communication (NFC).
Claim 37 and 46 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the issuer server is configured to:
detect an attempt of fraud by detecting that usage of the virtual single-use payment card is out of a territory of usage.
Claim 44 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computing device comprises a cellphone, wherein the execution of the program instructions by one or more processors of the issuer server comprises: receiving a cellphone identification (ID) and determining the number of the virtual single-use payment card based on the location of the cellphone ID.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 27-28, 30, 32-39, and 43-46 are rejected under 35 U.S.C. 103 as being unpatentable over Fonseca et al. (US20180374088A1) (hereinafter “Fonseca”) in view of Mendes et al. (US20130346305A1) (hereinafter “Mendes”) in further view of McGuinness et al. (US20140012688A1).
As per Claim 27 and 38, Fonseca teaches:
A system for making payments at a point of sale (POS) comprising an issuer server and a digital wallet application on a computing device, wherein the issuer server is configured to: (“The issuer server 150 can also communicate with the user device 110, for example via an API (application programming interface) to an application stored on the user device.” (Para. 0042); “The user device 110 can communicate, whether over the internet or via an in-store, e.g., contactless, link, with a merchant point of sale (POS). In the e-commerce example, the POS could be virtual.” (Para. 0038); “Also part of the payment network and thus capable of communication with the card association server 140 is an issuer server 150, the server of the bank with which the consumer's payment account is held.” (Para. 00))
download the virtual single-use payment card having the zero-balance . . .; (“obtaining a one-time virtual card number (OTVCN), and transmitting the OTVCN to the user device.” (Abstract); “at step 250 the OTVCN is transmitted to the user device.” (Para. 0046); “The card association server 140 then likewise receives the token at step 349 and relays it to the user device 110 at step 350, where it is received at step 351.” (Para. 0057))
receive a single transaction approval request from a payment terminal at the point of sale (POS) which is initiated by the digital wallet application on the computing device, wherein the single transaction request comprises at least a unique identifier of the virtual single-use payment card, merchant details . . .; (“the user device 110 indicates to the consumer that pre-authorization has been given and gives the consumer the opportunity to confirm that they wish the transaction to go ahead. The user provides their approval via a user interface device, so that the user device obtains their approval at step 353. The transaction can then proceed as for a normal payment card transaction, but with the tokenized OTVCN replacing the usual payment account credentials.” (Para. 0058); “the card association server 140 receives the request at step 366 then relays it on to the issuer server 150 at step 367. The transaction request is received by the issuer server 150 at step 368.” (Para. 0060); “The POS 120 can communicate with an acquirer server 130, the server of the bank with which the merchant's account for receipt of payments is held.” (Para. 0039))
send an approval for the single transaction approval request to the payment terminal at the POS based on available funds of a user account linked to the virtual single-use payment card (“The issuer server then checks the consumer's payment account and, provided all is well, provides authorization of the transaction request to the POS 120 via relay through the card association server 140 and the acquirer server 130.” (Para. 0043); “the issuer server 150 receives the OTVCN, then at step 376 confirms that it has not expired or already been used. The transaction request is authorized at step 380 and the authorization transmitted to the card association server 140 at step 381. The authorization is received by the card association server 140 at step 382, relayed on to the acquirer server 130 at step 383, where it is received at step 384 and relayed onto the POS at step 385.” (Para. 0062))
and transfer the transaction amount to the merchant; and (“The transaction is settled by the issuer paying the acquirer in a lump sum in the usual manner. The issuer recoups the purchase amount (together with any interest and/or fees) in installments from the consumer's payment account per the installment conditions of the simulation.” (Para. 0064))
after a completion of the transaction, change a status of the virtual single-use payment card to canceled. (“one-time virtual card numbers (OTVCNs). Herein, “one-time” indicates single use only.” (Para. 0035); “confirms that it has not expired or already been used.” (Para. 0062); “the consumer's user device is provided with an OTVCN, which can be used to complete the transaction in the same manner as a traditional payment card number (e.g., primary account number, PAN).” (Para. 0036)).
Fonseca does not disclose:
“issue a virtual single-use payment card having a zero-balance associated with a location of the computing device, wherein the location is used as a basis for generating a number of the virtual single-use payment card, and wherein subsequent usage of the virtual single-use payment card is” (claim 27).
However, as per Claim 27, McGuinness in the analogous art of location based payment systems, teaches: “issue a virtual single-use payment card having a zero-balance associated with a location of the computing device, wherein the location is used as a basis for generating a number of the virtual single-use payment card, and wherein subsequent usage of the virtual single-use payment card is”. (“a virtual payment system including a customer-specific, customer geolocation responsive, limited time duration payment identifier generator operative to generate a customer-specific, customer geolocation responsive, limited time duration payment identifier, a customer-specific limited time duration payment identifier communicator operative to communicate the customer-specific, customer geolocation responsive, limited time duration payment identifier to a customer and a limited time duration payment identifier validator, operative to verify genuineness and timeliness of the customer-specific, customer geolocation responsive, limited time duration payment identifier presented by the customer at a point of sale.” (Para. 0003); “The application preferably automatically sends the SPEEDCODE ID from the mobile communicator 118 to the system server 100 and may also send an account verification code, which may be selected by the customer and may be provided as part of a wallet application. The system server 100 verifies the SPEEDCODE ID and preferably ascertains the current location of the customer, preferably by interaction between the mobile communicator 118 and the geolocation server 110.” (Para. 0035); “The system server 100 generates and communicates to the customer's mobile communicator 118 a limited duration, single use purchase/payment (LDSU) code.” (Para. 0041))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Fonseca, generating and transmitting a one-time virtual card number (OTVCN) to a user device for use in a POS transaction, with the technique of McGuinness, generating a customer-specific, customer-geolocation-responsive, limited-duration payment identifier, to include using the location of the computing device as basis for generating the number of the virtual single-use payment card. Therefore, the incentives of improving fraud control, tailoring the single-use credential to the user’s current transaction context, and reducing unauthorized or stale credential use provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Fonseca does not disclose:
“to the digital wallet application installed on the computing device” (claim 27).
However, as per Claim 27, Mendes in the analogous art of mobile wallets, teaches: “to the digital wallet application installed on the computing device”. (See “This virtual card 118 may then be stored in the mobile wallet 116 for use in the current and/or future transactions.” (Para. 0041); “At 316, the new virtual credit card 118 is received into the mobile wallet 116 of the mobile device 102. That is, the new virtual credit card 118 is linked to the mobile wallet 116 on the mobile device 102 for use in completing mobile payments, as set forth herein. Accordingly, this new credit card may be electronically communicated to the mobile wallet 116 as the virtual credit card 118 referenced above.” (Para. 0059).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Fonseca’s system, where the issuer server generates a one time virtual card and causes a tokenized version to be delivered to an application on the user device, by implementing that application as the mobile wallet of Mendes, which explicitly receives and stores a virtual credit card that is communicated from the payment processor to the mobile wallet and received into the mobile wallet on the device. Using a known wallet app to hold Fonseca’s single use virtual card is routine substitution that leverages existing wallet infrastructure and produces predictable results of increased token security.
Fonseca does not disclose:
“and a transaction amount” (claim 27).
However, as per Claim 27, Mendes in the analogous art of mobile wallets, teaches: “and a transaction amount”. (See “, the vendor 142 may be configured to communicate a request 148 for authorization of a purchase to the mobile device 102, which request 148 includes details 150 [associated] with the current transaction.” (Para. 0041); “the vendor communicates a payment request 154 including the virtual card information 118, device identification 122, and transaction details 150 to the payment processor 132 for approval to complete the transaction.” (Para. 0043))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Fonseca’s transaction request, sent from the user device to the POS and relayed through the acquirer and card association to the issuer with the tokenized OTVCN in place of normal card credentials, as being initiated by a mobile wallet and to structure it with explicit fields for the card ID, merchant details, and transaction amount, as Mendes teaches where the wallet/phone participates in a authorization flow that includes the virtual card information 118 and transaction details 150 for the purchase. Aligning Fonseca’s conventional authorization message with Mendes’s explicit transaction detail structure is simply standardizing known data elements in a wallet-initiated request, yielding a predictable payment flow.
Fonseca does not disclose:
“unrestricted to the location” (claim 27).
However, as per Claim 27, Mendes in the analogous art of mobile wallets, teaches: “unrestricted to the location”. (See “the embodiments set forth in greater detail below include mobile wallet payment processing operations that may be implemented independent of specific infrastructure or network acceptance.” (Para. 0018); “the payment processor 132 is capable of processing closed-loop accounts (accounts that are only accepted at a single retailer or subset of retailers) or open-loop (branded card, such as MASTERCARD, VISA, etc., acceptable wherever such brands are accepted).” (Para. 0034))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Fonseca’s issuer-driver one-time virtual card number flow, where an issuer server generates a single-use card surrogate and drives a standard POS authorization/settlement path with no merchant POS changes, with Mendes’s teaching that mobile wallet payments are implemented independent of specific infrastructure or network acceptance and can use open-loop and closed-loop rails, thereby rendering use of the issued single-use credential unrestricted by the devices associated location. The motivations include increasing acceptance and reducing friction for mobile payments, which Mendes identifies as key improvements, and leveraging open-loop ubiquity to meet consumers and merchants in ordinary POS environments with specific restraints, producing predictable results in the combined system.
As per Claim 28 and 39, Fonseca teaches:
The system of claim 27, wherein the single transaction approval request is transmitted to the issuer server after being verified by a payment server. (“A transaction request is then made of the issuer server 150 via relay through the acquirer server 130 and the card association server 140.” (Para. 0043); “The transaction request is received by the POS 120 at step 362 then relayed to the acquirer server 130 at step 363. It is received at step 364 then relayed on to the card association server 140 at step 365. Similarly, the card association server 140 receives the request at step 366 then relays it on to the issuer server 150 at step 367.” (Para. 0060); “The token provider 160 receives the token at step 372, detokenizes it to recover the OTVCN at step 373, then transmits the OTVCN to the issuer server 150 at step 374.” (Para. 0061)).
As per Claim 30 and 41, Fonseca teaches:
The system of claim 27, wherein when the issuer server is configured to:. . . (“additional data could be transmitted with the price and identifier, for example data indicating the merchant (e.g., as determined via geolocation of the user device if it is mobile), or data indicating the product or service the consumer wishes to purchase.” (Para. 0051); “At step 375 the issuer server 150 receives the OTVCN, then at step 376 confirms that it has not expired or already been used.” (Para. 0062); “At step 342 the issuer server 150 generates an OTVCN. This may be done in response to the pre-authorization, or before or in parallel with it. At step 343 the OTVCN is then transmitted to the token provider 160, where it is received at step 344. . . The card association server 140 then likewise receives the token at step 349 and relays it to the user device 110.” (Para. 0056-0057))
Fonseca does not disclose:
“receive a new location from the computing device when the computing device is in the location not associated with the virtual single-use payment card; change the status of the virtual single-use payment card to cancelled; and download a new virtual single-use payment card associated with the new location of the computing device.” (claim 30).
However, as per Claim 30, McGuinness in the analogous art of virtual payment systems, teaches: “receive a new location from the computing device when the computing device is in the location not associated with the virtual single-use payment card; change the status of the virtual single-use payment card to cancelled; and download a new virtual single-use payment card associated with the new location of the computing device”. (See “ascertains the current location of the customer, preferably by interaction between the mobile communicator 118 and the geolocation server 110.” (Para. 0035); “After the limited duration, the code expires and can no longer be used for a transaction. Once the code is used, it expires.” (Para. 0043); “An LDSU code valid for a predetermined limited time duration, for example, 10 minutes, is generated by system server 100 and communicated to the customer's mobile communicator 118.” (Para. 0053)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Fonseca, using geolocation/merchant data and one-time virtual card numbers, while McGuinness teaches generating location specific, single use payment codes based on the users current location and letting those codes expire. In view of McGuinness, it would have been obvious in Fonseca to treat a card as cancelled when the device is detected in a new location and issue/download a new single use virtual card associated with that new location, as routine way to enforce location based usage and reduce fraud or out-of-region declines.
As per Claim 31 and 42, Fonseca teaches:
The system of claim 27, wherein the issuer server is configured to . . . associated with the location . . .. (“the consumer's user device is provided with an OTVCN, which can be used to complete the transaction in the same manner as a traditional payment card number (e.g., primary account number, PAN).” (Para. 0036); “At step 342 the issuer server 150 generates an OTVCN.” (Para. 0056); “The card association server 140 then likewise receives the token at step 349 and relays it to the user device 110 at step 350, where it is received at step 351.” (Para. 0057))
Fonseca does not disclose:
“download a new virtual single-use payment card . . . after the completion of the transaction” (claim 31).
However, as per Claim 31, Mendes in the analogous art of mobile wallets, teaches: “download a new virtual single-use payment card . . . after the completion of the transaction”. (See when the wallet does not include a suitable virtual card 118 or the card lacks sufficient funds, the mobile device contacts the payment processor and “payment processor 132 may generate a new virtual card 118 on the fly, top up an amount on the card 118 using the predefined payment source 120, or the like. That is, a valid credit card may be dynamically issued as needed by the payment processor 132 for use by the mobile device 102 in making a payment for a transaction. The new or updated virtual credit card 118 is then sent to the mobile device 102 for use by the mobile wallet 116.” (Para. 0045); See Fig. 2 teaching “Receive New Virtual Card Information [214] . . . [and] Link New Virtual Card To Wallet [216].” (Fig. 2))
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Fonseca’s system of one-time virtual card numbers, where each OTVCN is single use and new OTVCN is generated when the consumer wants to make another purchase, using Mendes teaching that, when a mobile wallet lacks a suitable virtual card, the processor dynamically issues and sends a new virtual card to the wallet. Once Fonseca’s single use card has been consumed by a completed transaction, the wallet is in the same ‘no suitable card available’ state described in Mendes, so it would be a routine, predictable design choice to automatically request and download a new virtual single use payment card after completion of the transaction to keep the wallet ready for the next purchase and reduce user friction.
As per Claim 32 and 43, Fonseca teaches:
The system of claim 27, wherein . . .
Fonseca does not disclose:
“the issuer server is configured to receive the location from a location unit of the computing device and determine a number of the virtual single-use payment card based on the location.” (claim 31).
However, as per Claim 31, McGuinness in the analogous art of location based payment systems, teaches: “the issuer server is configured to receive the location from a location unit of the computing device and determine a number of the virtual single-use payment card based on the location.”. (“Geolocation server 110 may provide location data for fixed locations 113, such as convenience stores 114 and gas stations 116, as well as current location data for a plurality of mobile devices which may be in motion, such as vehicles and hand-held mobile communicators 118.” (Para. 0020); “The system server 100 verifies the SPEEDCODE ID and preferably ascertains the current location of the customer, preferably by interaction between the mobile communicator 118 and the geolocation server 110.” (Para. 0035); “The system server 100 generates and communicates to the customer's mobile communicator 118 a limited duration, single use purchase/payment (LDSU) code.” (Para. 0041))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Fonseca, generating a one-time virtual card number for use in a POS transaction, with the technique of McGuiness, determining a customer/mobile-device location and generating a customer-geolocation-responsive, limited-duration single-use payment identifier, to determine the number of the virtual single-use payment card based on the location received from the computing device. Therefore, the incentives of improving fraud control, tailoring the credential to the user’s current transaction context, and reducing use of stale or authorized credentials provided a reason to make the adaptation, and invention resulted from application of the prior knowledge in a predicable manner.
As per Claim 33, Fonseca teaches:
The system of claim 27, wherein the virtual single-use payment card comprises a payment card number according to a Europay, Mastercard, Visa (EMV) standard based on the location. (“used to complete the transaction in the same manner as a traditional payment card number (e.g., primary account number, PAN).” (Para. 0036); “in-store payments, for example using contactless (e.g., near field communication, NFC) technology.” (Para. 0037); “tap the user device 110 on an NFC reader of the POS 120.” (Para. 0059))
As per Claim 34 and 45, Fonseca teaches:
The system of claim 27, wherein the virtual single-use payment card comprises a credit card number, a credit card date of issue, and a credit card security code. (“traditional payment card number (e.g., primary account number, PAN).” (Para. 0036); “At step 375 the issuer server 150 receives the OTVCN, then at step 376 confirms that it has not expired or already been used.” (Para. 0062); “The OTVCN could be obtained, transmitted, and/or received in a tokenized form.” (Para. 0015))
As per Claim 35, Fonseca teaches:
The system of claim 27, wherein the virtual single-use payment card comprises user data. (“Data indicating the price of a desired purchase are provided, together with an identifier to allow the consumer's payment account to be identified.” (Para. 0036); “the identifier comprises at least two of a user device identifier, an application identifier, a user identifier, and an account identifier.” (Claim 4); “additional data could be transmitted with the price and identifier, for example data indicating the merchant (e.g., as determined via geolocation of the user device if it is mobile), or data indicating the product or service the consumer wishes to purchase.” (Para. 0051))
As per Claim 36, Fonseca teaches:
The system of claim 27, wherein the issuer server is configured to transfer virtual single-use payment card data to the payment terminal by using a near field communication (NFC). (“tap the user device 110 on an NFC reader of the POS 120 to confirm they wish to go ahead, or if a single click is all that is required to confirm they wish to go ahead with an e-commerce transaction, and to transmit the transaction request.” (Para. 0059); “The user device 110 can communicate, whether over the internet or via an in-store, e.g., contactless, link, with a merchant point of sale (POS). In the e-commerce example, the POS could be virtual.” (Para. 0038); “in-store payments, for example using contactless (e.g., near field communication, NFC) technology.” (Para. 0037))
As per Claim 37 and 46, Fonseca teaches:
The system of claim 27, wherein the issuer server is configured to: detect an attempt of fraud by detecting that usage of the virtual single-use payment card is out of a territory of usage. (“additional data could be transmitted with the price and identifier, for example data indicating the merchant (e.g., as determined via geolocation of the user device if it is mobile), or data indicating the product or service the consumer wishes to purchase. Such additional data can be used later in the determination of suitable installment conditions, and/or in the updating of the consumer risk profile.” (Para. 0051); “payments by installment are only accepted where the conditions are determined according to an up to date consumer risk profile.” (Para. 0055); “confirms that it has not expired or already been used.” (Para. 0062))
As per Claim 44, Fonseca teaches:
The product of claim 38, wherein the computing device comprises a cellphone, wherein the execution of the program instructions by one or more processors of the issuer server comprises: receiving a cellphone identification (ID) and determining the number of the virtual single-use payment card based on the location of the cellphone ID. (“This may be a mobile device such as a smartphone, smartwatch or tablet, or a fixed device such as a personal computer (PC). Either way, the device may be capable of making e-commerce payments over an internet connection. In the case of a mobile device, it may alternatively or additionally be capable of making in-store payments, for example using contactless (e.g., near field communication, NFC) technology.” (Para. 0037); “At step 210, data indicating a price is received together with an identifier from a user device.” (Para. 0046); “the identifier comprises at least two of a user device identifier, an application identifier, a user identifier, and an account identifier.” (Claim 4); “At step 342 the issuer server 150 generates an OTVCN. This may be done in response to the pre-authorization, or before or in parallel with it.” (Para. 0056); “additional data could be transmitted with the price and identifier, for example data indicating the merchant (e.g., as determined via geolocation of the user device if it is mobile), or data indicating the product or service the consumer wishes to purchase.” (Para. 0051)).
Claims 29 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Fonseca et al. in view of Mendes et al. and McGuinness in further view of Redberg et al. (US20150312250A1) (hereinafter “Redberg”)
As per Claim 29 and 40, Fonseca teaches:
The system of claim 27,wherein the issuer server is configured to instruct the digital wallet application to . . . (“making use of one-time virtual card numbers (OTVCNs). Herein, “one-time” indicates single use only.” (Para. 0035); “At step 375 the issuer server 150 receives the OTVCN, then at step 376 confirms that it has not expired or already been used.” (Para. 0062); “each set of installment conditions may be provided at step 323 together with an expiry time.” (Para. 0055))
Fonseca does not disclose:
“remove the virtual single-use payment card after the single transaction approval request is declined” (claim 29).
However, as per Claim 29, Redberg in the analogous art of tokenized transaction systems, teaches: “remove the virtual single-use payment card after the single transaction approval request is declined”. (See “the token application allows a predefined number of tokens to be provisioned per soft token application instance. In accordance with an embodiment of the present invention, the tokens to be provisioned depend upon the storage capacity of the device. In accordance with an exemplary embodiment of the present invention, each token application instance is associated with a predefined number of tokens, for example, 12.” (Para. 0127); “the token application has a function to delete tokens. Accordingly, the “Delete Token” function removes all seed material for that token and all references to that token serial name. In case no tokens are installed within the token application, then the token application automatically invokes the function to request new tokens from the provisioning server.” (Para. 0146); “the token application provides a screen to “Delete Existing Token”. If the user selects “Delete Existing Token”, then the application presents a list of all available tokens to the user. If the user selects one of the tokens on the list above, then the application asks confirmation for the token to be deleted. If the user confirms deletion of the token, then the application invokes the feature to delete the token completely from the application.” (Para. 0159)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Fonseca, where a virtual card is expressly single use and treated as invalid once used or rejected, with the technique of Redberg, which teaches a token app that can delete a token completely from the application and request new ones, it would been obvious to have obvious to have the issuer (or wallet logic) instruct the wallet to delete/remove a declined single use virtual card. Doing so simply applies Redberg standard token deletion lifecycle to Fonseca’s single use credential so the wallet no longer displays or stores a useless, invalid card, an obvious housekeeping and security improvement with predictable results.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20140019352A1 (Shrivastava), discussing “the Pay Network Server may generate a WIP virtual credit card number 6825. Then the Pay Network Server may associate the WIP cards with the user identifier 6827. Then the Pay Network Server may retrieve the user's client device address 6829. Then the Pay Network Server may send the WIP virtual credit card number to the user 6831. Then the Pay Network Server may generate a WIP card generation completion and wallet addition message 6833 to add the generate WIP card to the user's wallet account.” (Para. 0474).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697
Prosecution Insights