DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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 the claims
2. Applicant filed the amendment on 06/10/2026. Claims 36, 38-39, and 41-45 are amended. Claims 36-45 and 55 are pending.
Claim Rejections - 35 USC §101
3. 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.
4. Claims 36-45 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.
5. In the instant case, claim 36 is directed “a method of a card binding”.
6. Claim 36 recites “binding a payment card”. Specifically, claim recites (abstract ideas emphasized in bold) “accepting an access from a user terminal to a first page address of the card binding server indicated by an information carrier pattern scanned by the user terminal calling a first application, and receiving the card number of a target card, sent by the user terminal and encrypted with a first key, and obtaining the card number of the target card by decrypting the encrypted card number of the target card using a pre-stored second key paired with the first key;
after accepting the access from the user terminal to the first page address through the first application and obtaining the card number of the target card, determining whether the first application belongs to applications supported by the card binding server, and under a condition that the first application belongs to the applications supported by the card binding server, in response to the access from the user terminal, triggering an interaction with a back-end server of the first application to acquire user information about a target user, wherein the target user is a user logging onto the first application, and the user information comprises a user identifier of the target user in the first application;
sending, to the user terminal, a second page address corresponding to a redirected card binding page, wherein the card binding page comprises at least a part of the card number of the target card;
receiving a card binding confirmation message indicating identity information about the target user, wherein the card binding confirmation message is sent by the user terminal based on the card binding page;
receiving a dynamic verification code request message sent by the user terminal;
sending a first dynamic verification code to the user terminal;
receiving a second dynamic verification code sent by the user terminal; and
under a condition that the first dynamic verification code coincides with the second dynamic verification code, in response to receiving the card binding confirmation message, automatically executing a binding between a card identifier of the target card and a user identifier of the target user in a card binding application by interacting with a card issuing server and a back-end server of the card binding application using the identity information, wherein the card binding application comprises:
sending, to the card issuing server, a card binding activation message comprising the card number of the target card and the identity information, to cause the card issuing server to produce card binding activation verification result information using the identity information;
receiving the card binding activation verification result information sent by the card issuing server; and
under a condition that the card binding activation verification result information indicates a successful card binding activation verification, sending a first card binding notification message to the back-end server of the first application, wherein the first card binding notification message comprises the card binding activation verification result information and the card identifier of the target card, so that the back-end server of the first application completes a binding between the card identifier of the target card and the user identifier of the target user in the first application,
wherein the card binding application comprises the first application”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
7. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 36 such as “a card binding server”, “a user terminal”, “a first application”, “encrypted with a first key”, “a pre-stored second key paired with the first key”, “applications supported by the card binding server”, “a back-end server of the first application”, “a redirected card binding page”, “the card binding page”, and “automatically executing a binding between a card identifier of the target card and a user identifier of the target user in a card binding application by interacting with a card issuing server and a back-end server of the card binding application” represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to (i.e., automate) the acts of binding a payment card. And, with respect to “sending, to the user terminal, a second page address corresponding to a redirected card binding page, wherein the card binding page comprises at least a part of the card number of the target card”, “sending a first dynamic verification code to the user terminal”, and “sending, to the card issuing server, a card binding activation message comprising the card number of the target card and the identity information, to cause the card issuing server to produce card binding activation verification result information using the identity information” is simply transmitting data “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more, (MPEP 2106.05(f)(2)).
8. When analyzed under step 2B (MPEP 2106.04 II), as the additional elements do no more than represent the use of a computer, or computer technology, as a tool to perform binding a payment card and they do not improve computer functionality or provide an improvement to another technology or technological field.
9. Hence, claim 36 is not patent eligible.
10. The following dependent claims recent additional elements not addressed above:
claim 37 recites “a Quick Response (QR) code” and “an encrypted version”; and
claim 39 recites “a selected card binding application”, “a second application”, and “a back-end server of the second application”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the Quick Response (QR) code, the encrypted version, the selected card binding application, the second application, and the back-end server of the second application.
11. Dependent claims 37-45 merely expand upon the abstract ideas of the independent claim and are therefore rejected under the same rationale as claim 36.
Conclusion of 35 USC §101
12. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
13. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
14. 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.
15. 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.
16. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
17. Claims 36-38, 40-42, 44-45, and 55 are rejected under 35 U.S.C. 103 as being unpatentable over US20200097960A1 to Wong et al. in view of US20120209749A1 to Hammad et al.
18. As per claim 36:
Wong et al. discloses the following limitations:
[accepting]… obtaining the card number of the target card by decrypting the encrypted card number of the target card using a pre-stored second key paired with the first key ([0121] “…the issuer 240 may generate the DVV 602 by encrypting (with an issuer 240 private key) a clear text value that is based upon a value associated with the user (e.g., a PAN of the account, a user identifier, etc.) … the service provider 230 may have access to a public key of the issuer 240, decrypt the user-provided DVV, and determine whether the resulting clear text value includes the correct PAN and a correct date/time value.”, [0126] “…asymmetric cryptography techniques utilizing public/private key pairs are utilized for data protection…”)
after accepting the access from the user terminal to the first page address through the first application and obtaining the card number of the target card, determining whether the first application belongs to applications supported by the card binding server ([0052] “…The service provider 230 server computer 212, via its provisioning service module 225, may provide ‘provisioning as a service’ to one or more application provider 209 server computers 211, wherein the application provider 209 server computer 211 utilizes an application programming interface (API) to communicate with the service provider 230 server computer 212.”, [0051] “…An application provider 209 may be associated with an application installed on mobile device 101. For example, a Visa Checkout application on mobile device 101 may be configured to connect to an application provider 209 server computer 211 operated by Visa.”), and under a condition that the first application belongs to the applications supported by the card binding server, in response to the access from the user terminal, triggering an interaction with a back-end server of the first application to acquire user information about a target user, wherein the target user is a user logging onto the first application ([0060] “…The application provider 209 server computer 211 receives the request for provisioning message, and may perform a risk check or risk analysis for the requesting user 107, account, mobile device 101, or any other data that is present in the received request for provisioning message… If the risk check indicates that the risk of provisioning is acceptable, then application provider 209 server computer 211 may send the request for provisioning to provisioning service module 225 executing at service provider 230 server computer 212. The request for provisioning message may include any of the information included in the message received from mobile device 101, and may include additional information determined by application provider 209 server computer 211, such as a primary account number (PAN) associated with the user's account and a reference number associated with the request for provisioning.”, [0056] “…The request for provisioning may be sent to application provider 209 server computer 211. Application provider 209 server computer 211 may forward the request to service provider 230 server computer 212, and in particular, to provisioning service module 225…”), and the user information comprises a user identifier of the target user in the first application ([0060] “…The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information…”, [0055] “…issuer computer 106 may provide to service provider 230 server computer 212 personal information regarding users 107 associated with issuer computer 106. For example, issuer computer 106 may provide payment information, user information, account information, etc.”)
sending, to the user terminal, a second page address corresponding to a redirected card binding page, wherein the card binding page comprises at least a part of the card number of the target card ([0091] “…the provisioning service module 225 prepares and sends a message 376 to the wallet provider 210 including the token (received from the token service module 222) along with a set of one or more provisioning scripts… this message 376 includes one or more of the token (which may be encrypted), a token expiration date, a portion of the associated PAN (e.g., the last four digits), a portion of the token itself (e.g., the last four unencrypted digits), the associated card metadata, a token reference identifier, a PAN reference identifier… the wallet provider 210 may forward, in another message 378 back to the mobile device 101, some or all of the information from message 376…”)
receiving a card binding confirmation message indicating identity information about the target user … ([0060] “…The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information (e.g., a cryptogram such as a CVV2 for card verification based authentication processes, a ZIP code for geographic verification, etc.)…”, [0110] “…The payment credential 207 may include one or more of an account number of the account, a token associated with the account, an expiration date of the token or account number, personal information associated with the account, a public and/or private key to be used to encrypt and/or decrypt information associated with transactions with the account, card art…”)
receiving a dynamic verification code request message sent by the user terminal ([0099] “…The user 107 may select one of these options and thus the mobile device 101 will receipt the user's selected DVV delivery choice at block 408, and transmit a message 460 including the selected delivery choice to the wallet provider 210, which will forward the delivery choice on in another message 462 (e.g., in a “send OTP” message) to the service provider 230…”, [0098] “…will send a query message 458 to seek the user's selection as to a preferred way for the user to receive a dynamic verification value (DVV)…”)
sending a first dynamic verification code to the user terminal ([0101] “…the service provider 230 will generate a DVV at block 410, which may include generating a length of random characters/numbers/values…”, [0099] “…a set of delivery options for the DVV may be presented to the user, including but not limited to receipt through the mobile payment application, receipt of a text message (e.g., Short Message Service (SMS) or other similar messaging service message), placing or receiving a telephone call to acquire the DVV…”, [0103] “…the issuer 240 contacts the user 107 via the selected delivery choice mechanism (see message 466) to provide the user 107 with the generated DVV…”)
receiving a second dynamic verification code sent by the user terminal ([0104] “At some point, the DVV is provided to the user 107 according to the selected delivery mechanism, and the user may input the DVV into the mobile device 101 (e.g., via the mobile wallet application), which receives the entry of the DVV at block 412, and transmits the DVV in a DVV message 468 to the wallet provider 210.”, [0105] “…the wallet provider 210 may transmit a Resume Account message 470, which includes the entered-DVV (from message 468) along with an identifier of the respective account…”)
under a condition that the first dynamic verification code coincides with the second dynamic verification code ([0106] “At block 414, the service provider 230 then validates the DVV based upon a stored copy of the DVV (from when it was generated in block 410) or by generating a copy of the DVV…”, [0117] “…this determination comprises looking up a stored copy of the DVV (e.g., generated by the service provider 230, issuer 240, or third-party) and comparing it to the received DVV to determine if they are the same…”, [0108] “However, when (at block 414) the DVV is validated, the service provider 230 may update its records to indicate that the token is now active…”), in response to receiving the card binding confirmation message, automatically executing a binding between a card identifier of the target card and a user identifier of the target user in a card binding application ([0108] “…when (at block 414) the DVV is validated, the service provider 230 may update its records to indicate that the token is now active (e.g., update a status maintained by token service module 222 for the token), and may generate and/or provide an activation script to the wallet provider 210 in message 472, which is forwarded to the mobile device 101 as message 474…”, [0118] “…the service provider 230 server computer 212 may also transmit a token notification message 379 to the issuer 240 to inform the issuer 240 of the token and the account that it is associated with.”) by interacting with a card issuing server and a back-end server of the card binding application using the identity information ([0083] “…the service provider 230 identifies the issuer 240 of the account (e.g., based upon the PAN), transmits a token activation request message 370 (which may include a risk value indicating the service provider assigned risk 314 and/or a risk value generated by the wallet provider 210) to the issuer 240 such that the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.”, [0056] “provisioning service module 225 may instruct application provider 209 server computer 211 to cause an activation script to be executed on mobile device 101 to complete a provisioning, thereby completely an “installation” of a set of payment credentials 207 onto the mobile device 101 for use.”), wherein the card binding application comprises:
sending, to the card issuing server, a card binding activation message comprising the card number of the target card and the identity information ([0083] “…the service provider 230 identifies the issuer 240 of the account (e.g., based upon the PAN), transmits a token activation request message 370 (which may include a risk value indicating the service provider assigned risk 314 and/or a risk value generated by the wallet provider 210) to the issuer 240…”, [0055] “issuer computer 106 may provide to service provider 230 server computer 212 personal information regarding users 107 associated with issuer computer 106. For example, issuer computer 106 may provide payment information, user information, account information, etc.”), to cause the card issuing server to produce card binding activation verification result information using the identity information ([0083] “…the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.”, [0086] “…the token activation response message 372A/372B may indicate a level of risk. In some embodiments, at least three levels of risk may be generated, including a ‘low’ risk where the provisioning request is unconditionally approved, a ‘medium’ risk where the provisioning request is conditionally approved, and a ‘high’ risk where the provisioning request is declined…”)
receiving the card binding activation verification result information ([0083] “…will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.”, [0085] “…the service provider 230, after sending the token activation request message 370, may be configured to only wait for the corresponding token activation response message 372B for a period of time…”) sent by the card issuing server ([0083] “…the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230…”)
under a condition that the card binding activation verification result information indicates a successful card binding activation verification, sending a first card binding notification message to the back-end server of the first application, wherein the first card binding notification message comprises the card binding activation verification result information and the card identifier of the target card, so that the back-end server of the first application completes a binding between the card identifier of the target card and the user identifier of the target user in the first application ([0086] “a ‘low’ risk where the provisioning request is unconditionally approved, a ‘medium’ risk where the provisioning request is conditionally approved, and a ‘high’ risk where the provisioning request is declined. The depicted flow varies based upon which of these levels of risk were generated.”, [0091] “…the provisioning service module 225 prepares and sends a message 376 to the wallet provider 210 including the token (received from the token service module 222) along with a set of one or more provisioning scripts. In some embodiments, the this message 376 includes one or more of the token (which may be encrypted), a token expiration date, a portion of the associated PAN (e.g., the last four digits), a portion of the token itself (e.g., the last four unencrypted digits), the associated card metadata, a token reference identifier, a PAN reference identifier…”, [0056] “…provisioning service module 225 may instruct application provider 209 server computer 211 to cause an activation script to be executed on mobile device 101 to complete a provisioning…”)
wherein the card binding application comprises the first application ([0051] “…An application provider 209 may be associated with an application installed on mobile device 101. For example, a Visa Checkout application on mobile device 101 may be configured to connect to an application provider 209 server computer 211 operated by Visa.”, [0060] “…in a payment application 208C (e.g., digital wallet application), the user 107 may request provisioning of an account, credit card, or any other payment credentials for mobile device 101…”, [0108] “…may generate and/or provide an activation script to the wallet provider 210 in message 472, which is forwarded to the mobile device 101 as message 474. The mobile device 101 may then activate the token at block 416 by executing the token activation script…”)
Wong et al. does not disclose, however, Hammad et al., as shown, teaches the following limitations:
accepting an access from a user terminal to a first page address of the card binding server indicated by an information carrier pattern scanned by the user terminal calling a first application ([0084] “…the virtual wallet application may trigger the capture of an image frame by a camera operatively connected to the user device… the QR code could include an invoice/bill, a coupon, a money order (e.g., in a P2P transfer), a new account information packet, product information, purchase commands, URL navigation instructions, browser automation scripts…”, [0121] “…A user, in one implementation, may snap a picture of the code…”), and receiving the card number of a target card, sent by the user terminal and encrypted with a first key and ([0061] “…the card authorization request from a user device may include encrypted data extracted from the QR code, which may have been encrypted by the merchant server as part of a merchant authentication scheme… the pay network server may obtain the encrypted data from the card authorization request provided by the user device…”)
[receiving a card binding] … wherein the card binding confirmation message is sent by the user terminal based on the card binding page ([0121] “The wallet application may identify the pay card 1151 and may display the textual information 1152 encoded in the pay card. The user may then perform verification of the information 1152 by selecting the verify button 1153…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied to the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for capturing an image frame by camera on the user device, decoding the pattern, which contents are contemplated to include navigation instructions to a network address, confirming that a user scans a code carried on the face of a pay card as the entry point to adding that card as a funding source, receiving by a server encrypted data that arrives from the user device, displaying the card information to the user, and the user's confirmation is entered from it (‘749, [0061], [0084], [0121]).
19. As per claim 37:
Wong et al. does not disclose, however, Hammad et al., as shown, teaches the following limitations:
wherein the information carrier pattern comprises a Quick Response (QR) code, and information recorded in the QR code comprises the first page address and the card number of the target card, or the information recorded in the QR code comprises the first page address and an encrypted version of the card number of the target card ([0113] “…The snap mode may handle any machine-readable representation of data. Examples of such data may include linear and 2D bar codes such as UPC code and QR codes …”, [0084] “…the QR code could include an invoice/bill, a coupon, a money order (e.g., in a P2P transfer), a new account information packet, product information, purchase commands, URL navigation instructions, browser automation scripts…”, [0121] “…Such a code may have encoded therein pay card information including, but not limited to, name, address, pay card type, pay card account details, balance amount, spending limit, rewards balance…”)
or the information carrier pattern comprises a surface pattern of the target card, and the surface pattern comprises a page jump mark and the card number of the target card, and the page jump mark corresponds to the first page address ([0121] “…a pay card such as a credit card, debit card, pre-paid card, smart card and other pay accounts may have an associated code such as a bar code or QR code… In one implementation, the code may be found on a face of the physical pay card. In another implementation, the code may be obtained by accessing an associated online account or another secure location. In yet another implementation, the code may be printed on a letter accompanying the pay card. A user, in one implementation, may snap a picture of the code…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied to the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for utilizing a QR code generated by the user's mobile device as a replacement for a plastic payment card, the pay network server may encode the information provided by the merchant into the QR code, and may also advantageously encode security information, and a pay card such as a credit card may have an associated code such as a bar code or QR code which contains pay card information including, but not limited to, name, address, pay card type, pay card account details, and the like (‘749, [0084], [0113], [0121]).
20. As per claim 38:
Wong et al. discloses the following limitations:
wherein the card binding activation verification comprises determining whether the identity information about the target user coincides with identity information about a cardholder of the target card stored in the card issuing server ([0098] “performing a challenge/response test with the user via mobile device 101 (e.g., based upon information the legitimate user previously provided or is likely to know)… having the user click on a link within an email sent to an email address on file for the user…”, [0083] “…the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.”)
21. As per claim 40:
Wong et al. discloses the following limitations:
wherein the card binding page further comprises an area for filling an identity information ([0060] “…The request for provisioning message may include device information such as a mobile device 101 identifier, secure element 202 identifier, a secure element key identifier (or key), a user identifier (to identify a user or account), and user authentication information (e.g., a cryptogram such as a CVV2 for card verification based authentication processes, a ZIP code for geographic verification, etc.)…”, [0038] “…Examples of account information may include a PAN (Primary Account Number or "account number"), user name, expiration date, CVV (Card Verification Value), dCVV (Dynamic Card Verification Value), CVV2 (Card Verification Value 2)…”)
or the user information further comprises the identity information, and the card binding page further comprises the identity information ([0055] “…issuer computer 106 may provide to service provider 230 server computer 212 personal information regarding users 107 associated with issuer computer 106. For example, issuer computer 106 may provide payment information, user information, account information, etc.”, [0110] “…The payment credential 207 may include one or more of an account number of the account, a token associated with the account, an expiration date of the token or account number, personal information associated with the account, a public and/or private key to be used to encrypt and/or decrypt information associated with transactions with the account, card art (e.g., an image such as a depiction of an actual credit card or payment device) for the account, an identifier and/or name of a user associated with the account…”)
22. As per claim 41:
Wong et al. discloses the following limitations:
wherein the first key and the second key are asymmetric keys ([0126] “…in this depicted embodiment, asymmetric cryptography techniques utilizing public/private key pairs are utilized for data protection…”, [0127] “…the mobile device 101 provides a secure element encryption key (SEEK) in message 750A that may be a public key allowing other entities to encrypt messages that can only be read (i.e., decrypted) by the secure element 202 of the mobile device 101 (e.g., using an associated private key)…”, [0128] “…the service provider 230 may generate a public key and a private key to be used for communications with the mobile device 101…”)
23. As per claim 42:
Wong et al. discloses the following limitations:
wherein sending the first dynamic verification code to the user terminal comprises acquiring a mobile phone number of the target user from the identity information and sending the first dynamic verification code to the user terminal through a short message ([0009] “…The communication may include sending the user a one-time password over the second communication channel, which may be a SMS message, email, or HTTP message sent by an issuer to the user.”, [0099] “…a set of delivery options for the DVV may be presented to the user, including but not limited to receipt through the mobile payment application, receipt of a text message (e.g., Short Message Service (SMS) or other similar messaging service message)… some or all of the delivery options may include obfuscated information, such as a partially hidden/obscured telephone number (alongside one or more erroneous telephone numbers) or email address, for example.”)
24. As per claim 44:
Wong et al. discloses the following limitations:
after automatically executing the binding between the card identifier of the target card and the user identifier of the target user in the card binding application ([0108] “…the service provider 230 may update its records to indicate that the token is now active (e.g., update a status maintained by token service module 222 for the token), and may generate and/or provide an activation script to the wallet provider 210 in message 472, which is forwarded to the mobile device 101 as message 474…”, [0118] “…the service provider 230 server computer 212 may also transmit a token notification message 379 to the issuer 240 to inform the issuer 240 of the token and the account that it is associated with.”) by interacting with the card issuing server and the back-end server of the card binding application using the identity information ([0083] “…the service provider 230 identifies the issuer 240 of the account (e.g., based upon the PAN), transmits a token activation request message 370 (which may include a risk value indicating the service provider assigned risk 314 and/or a risk value generated by the wallet provider 210) to the issuer 240 such that the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.”, [0056] “provisioning service module 225 may instruct application provider 209 server computer 211 to cause an activation script to be executed on mobile device 101 to complete a provisioning, thereby completely an “installation” of a set of payment credentials 207 onto the mobile device 101 for use.”), the method further comprising:
Wong et al. does not disclose, however, Hammad et al., as shown, teaches the following limitations:
sending a third page address corresponding to a redirected card binding result page to the user terminal, wherein the card binding result page is used to characterize that the binding between the card identifier of the target card and the user identifier of the target user in the card binding application has been completed ([0121] “…When the pay card has been added to the wallet, the user interface may be updated to indicate that the importing is complete via the notification display 1156…”, [0121] “…The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 916…”)
and accepting the access from the user terminal to the third page address ([0121] “…The user may then access the wallet 1157 to begin using the added pay card as a funding source.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied t18683o the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for adding the card, updating the interface display that characterizing the operation completion, and which confirms the binding to the user, and the user accessing the result presentation after the binding completes (‘749, [0121]).
25. As per claim 45:
Wong et al. discloses the following limitations:
and in response to receiving a management operation instruction of the user terminal, performing a management operation on a binding relationship indicated by the management operation instruction ([0108] “…The mobile device 101 may then activate the token at block 416 by executing the token activation script, which may cause a protection flag of the token (e.g., within secure element 102) to be disabled (at block 418), or may decrypt the previously-encrypted token (at block 419)…”, [0115] “…in some embodiments the provisioned token is obfuscated (e.g., encrypted or otherwise transformed) to be invalid, in some embodiments a protection flag is set (e.g., within a mobile device 101 secure element 202) such that the mobile device 101 cannot access the payment credential 207…”)
wherein the management operation comprises one or more of a disabling operation, an enabling operation, and a payment limit setting operation ([0115] “…a protection flag is set (e.g., within a mobile device 101 secure element 202) such that the mobile device 101 cannot access the payment credential 207…”, [0108] “…which may cause a protection flag of the token (e.g., within secure element 102) to be disabled (at block 418)…”, [claim 22] “…the protection flag representing the inactive state of the first token; and the activation script, when executed on the first mobile device, disables the protection flag associated with the first token.”)
Wong et al. does not disclose, however, Hammad et al., as shown, teaches the following limitations:
accepting an access from the user terminal to a fourth page address corresponding to a card binding management page, wherein the card binding management page comprises a binding relationship between the card identifier of the target card and the user identifier of the target user in the card binding application ([0121] “…The instruction to add the pay card to the wallet may cause the pay card to appear as one of the forms of payment under the funds tab 916…”, [0097] “…The user may select the funds tab 916 to select one or more forms of payment 917, which may include various credit, debit, gift, rewards and/or prepaid cards…”, [0100] “…the user may scroll down the list of forms of payments 926 under the funds tab to select specialized accounts such as a flexible spending account (FSA) 927, health savings account (HAS), and/or the like…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied to the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for checking whether the cards bound to the user's wallet, listing the forms of payment held for that user, and adding a card by the card-binding operation so the interface presenting the binding between the card and the user in the application (‘749, [0097], [0100], [0121]).
26. As per claim 55:
Wong et al. discloses the following limitations:
A non-transitory computer readable storage medium having computer program instructions stored thereon, which when executed by a processor, cause the card binding method according to claim 36 to be implemented ([0011] “…In an embodiment, a non-transitory computer readable medium stores instructions that when executed by a processor of a server cause the server to perform this method…”, [0140] “… fixed disk 920 (or other memory comprising computer readable media, which may include a non-transitory computer readable storage medium)…”)
27. Claim 43 is rejected under 35 U.S.C. 103 as being unpatentable over US20200097960A1 to Wong et al. in view of US20120209749A1 to Hammad et al. and US20170201520A1 to Chandoor et al.
28. As per claim 43:
Neither Wong et al. nor Hammad et al. disclose, however, Chandoor et al., as shown, teaches the following limitations:
wherein the applications supported by the card binding server are applications in a white list ([0065] “…the remote server computer 430 can continue with the validation process because the first application 412 is a trusted application of the remote server computer 430. If the remote server computer 430 determines that the encrypted provisioning request did not originate from the first application 412, the remote server computer 430 may terminate the provisioning session.”, [0064] “…the second application 414 may send the unencrypted application ID of the first application 412 together with the encrypted provisioning request to the remote server computer 430 such that the remote server computer 430 can retrieve the appropriate key or shared secret to decrypt the encrypted provisioning request…”, [0056] “…the access data database 350 can be queried to retrieve the device ID and/or the application ID to validate that the access data is being used with the proper communication device and/or application that was provisioned with the access data.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied to the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]) and a method that provides techniques for provisioning access data from a first application to a second application installed on a communication device of Chandoor et al. (‘520, [0019]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for holding by the server application identifiers, retrieving that material by application identifier when a request arrives and an enumerated set of permitted applications, consulted by identifier and determining whether the operation continues (‘520, [0056], [0064], [0065]).
29. Claim 39 is rejected under 35 U.S.C. 103 as being unpatentable over US20200097960A1 to Wong et al. in view of US20120209749A1 to Hammad et al., US20170201520A1 to Chandoor et al., and US20190197527A1 to Agarwalla et al.
30. As per claim 39:
Wong et al. discloses the following limitations:
and automatically executing the binding between the card identifier of the target card and the user identifier of the target user in the card binding application ([0108] “…the service provider 230 may update its records to indicate that the token is now active (e.g., update a status maintained by token service module 222 for the token), and may generate and/or provide an activation script to the wallet provider 210 in message 472, which is forwarded to the mobile device 101 as message 474…”, [0118] “…the service provider 230 server computer 212 may also transmit a token notification message 379 to the issuer 240 to inform the issuer 240 of the token and the account that it is associated with.”) by interacting with the card issuing server and the back-end server of the card binding application using the identity information ([0083] “…the service provider 230 identifies the issuer 240 of the account (e.g., based upon the PAN), transmits a token activation request message 370 (which may include a risk value indicating the service provider assigned risk 314 and/or a risk value generated by the wallet provider 210) to the issuer 240 such that the issuer 240, at block 316, will determine/assign its own risk and return a token activation response message 372B back to the service provider 230.”, [0056] “provisioning service module 225 may instruct application provider 209 server computer 211 to cause an activation script to be executed on mobile device 101 to complete a provisioning, thereby completely an “installation” of a set of payment credentials 207 onto the mobile device 101 for use.”)
Neither Wong et al. nor Hammad et al. disclose, however, Chandoor et al., as shown, teaches the following limitations:
wherein the card binding page further comprises one or more options of applications supported by the card binding server, the card binding confirmation message is further used to indicate a selected card binding application, and the card binding application further comprises a second application ([0058] “…The first application 412 may present a list of other applications that the first application 412 can provision access data to. The other applications may include the second application 414. The user 410 may then select the second application 414 from the list of applications presented by the first application 412.”, [0065] “…the remote server computer 430 can continue with the validation process because the first application 412 is a trusted application of the remote server computer 430…”)
under a condition that the user identifier matching the identity information is found, receiving a card binding request message sent by the back-end server of the second application, wherein the card binding request message is used to request the card identifier of the target card ([0064] “…the second application 414 may send the encrypted provisioning request to the remote server computer 430 for validation of the provisioning request… The second application 414 may send the encrypted provisioning request to the remote server computer 430 via an enrollment Application Program Interface (API).”, [0061] “…the second application 414 may send the user ID of the user associated with the second application 414, a device ID identifying the communication device, and the session ID to the first application 412. The user ID may identify the user 410 that logged in to the second application 414…”)
and sending, to the back-end server of the second application, a second card binding notification message comprising the card identifier of the target card, so that the back-end server of the second application completes a binding between the card identifier of the target card and a user identifier of the target user in the second application, wherein the user identifier of the target user in the second application is a user identifier matching the identity information ([0068] “…the remote server computer 430 may generate access data that the second application 414 can use to access a resource, and send the access data to the second application 414…”, [0048] “…Both the access data provisioned to the first application 212 and the second application 214 can be linked to the same account of the user, and thus allowing either application to access the resource using the same account.”, [0056] “…if the access data is bound to a particular communication device and/or particular application, the access data can be stored together with the device ID of the communication device or application ID of the application that was received as part of the provisioning request data…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied to the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]) and a method that provides techniques for provisioning access data from a first application to a second application installed on a communication device of Chandoor et al. (‘520, [0019]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for presenting with a list of applications as options, making by the user a selection from that list which then determines where the credential is bound, originating a request on the side of the second application and asking the server for the credential that will stand for the card, and sending by the server the card identifier onward to the second application following successful validation, and the result is an association between that identifier and the user in that application (‘520, [0048], [0056], [0058], [0061], [0064], [0065], [0068]).
Neither Wong et al. nor Hammad et al. or Chandoor et al. disclose, however, Agarwalla et al., as shown, teaches the following limitations:
sending, to a back-end server of the second application, a card binding matching message comprising the identity information, so that the back-end server of the second application looks up a user identifier matching the identity information ([0008] “…The method receives, by a processor, personal contact information related to a user from an online merchant. The user is engaged in an online purchase transaction with the online merchant. The method determines, by the processor, if a record of the digital wallet account for the user exists in a database using the personal contact information…”, [0083] “…the online merchant 904 provides the personal contact information, such as phone number and/or Email address to the server system 906 to determine if a digital wallet account exists for the user 902…”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a mobile payment apparatus that may utilize the information extracted from the QR code, along with information on a virtual wallet tied to the user device to initiate a purchase transaction of Hammad et al. (‘749, [0021]), a method that provides techniques for provisioning access data from a first application to a second application installed on a communication device of Chandoor et al. (‘520, [0019]), and a method for facilitating digital wallet based payment card transactions of Agarwalla et al. (‘527, [0006]) with the teaching of Wong et al. for optimizing the provisioning of payment account credentials to mobile devices utilizing mobile wallets (‘960, [0026]) for checking of the user by identity information in order to find the account identifier that corresponds to that user and personal contact information for the user is transmitted between the merchant side and the server side for locating the user's account record (‘527, [0008], [0083]).
Response to Arguments
31. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 36-45 and 55 are rejected.
Rejection under 35 USC § 101
32. Applicant’s arguments toward 35 U.S.C. § 101 rejection are not persuasive. Amended independent claim 36 does not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
33. Applicant is of the opinion that “[amended] claim 36 is directed to a particular computer-networked security workflow for securely establishing a binding relationship between a card identifier and a user identifier across multiple coordinated systems. The claim does not merely recite a desired commercial result. Rather, it recites a specific sequence of technological operations” and lists amended claim 36 limitations. And Applicant concludes that “[these] steps reflect a specific technical protocol spanning user terminal behavior, application back-end behavior, and issuer-side behavior, and are not merely a business practice performed with pencil and paper”.
Examiner respectfully disagrees.
As a whole, amended claim 36 recites binding a payment card which is grouped under Certain methods of organizing human activity (e.g., commercial interactions) and an abstract idea in prong one of step 2A.
34. Applicant is of the opinion that “[even] assuming arguendo that some aspect of ‘binding a payment card’ could be viewed as an abstract idea, the additional elements of amended claim 36 integrate any such idea into a practical application. Claim 36 requires a particular sequence of technical operations that governs how card data and user identity data are securely processed in a distributed computing environment.” And Applicant lists features of amended independent claim 36, and dependent claims 37-45 and states “[these] are operative security and control steps that define how the distributed system functions to achieve secure card binding. The claim therefore applies computer and network components in a particular manner to obtain a concrete technical result, rather than merely linking an abstract idea to a generic technological environment.”
Examiner respectfully disagrees.
Mentioned above the claim features performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The steps of – an access to a first page address of the card binding server indicated by the scanned information carrier pattern, decrypting the encrypted card number of the target card using a pre-stored second key paired with the first key, sending a second page address corresponding to a redirected card binding page, the first dynamic verification code coincides with the second dynamic verification code, and sending a first card binding notification message to the back-end server of the first application – may facilitate commerce but does not improve computers or technology. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claim is directed to the abstract idea.
35. Applicant is of the opinion that “[under] Step 2B, the claims add significantly more than any purported abstract idea because they require a specific, ordered combination of operations across multiple computing components (user terminal, first application back-end, card binding server, and card issuing server) that effects a concrete technical result: securely establishing and managing a binding relationship between a card identifier and a user identifier across different systems under multiple security conditions.”
Examiner respectfully disagrees.
“Although the conclusion of whether a claim is eligible at Step 2B requires that all relevant considerations be evaluated, most of these considerations were already evaluated in Step 2A Prong Two”, MPEP 2106.05 II.
As per the identification of the “additional elements” under Step 2A Prong Two and Step 2B, the rejection properly identifies the elements which are recited in the claim beyond the abstract idea, including accepting an access to a first page address indicated by an information carrier pattern scanned, obtaining the card number of the target card, obtaining the card number of the target card, triggering an interaction to acquire user information about a target user, sending a second page address, wherein the card binding page comprises at least a part of the card number of the target card; receiving a card binding confirmation message indicating identity information about the target user; sending a first dynamic verification code; and under a condition that the first dynamic verification code coincides with the second dynamic verification code, in response to receiving the card binding confirmation message, executing a binding between a card identifier of the target card and a user identifier of the target user by interacting using the identity information, sending a card binding activation message comprising the card number of the target card and the identity information, to cause to produce card binding activation verification result information using the identity information; and under a condition that the card binding activation verification result information indicates a successful card binding activation verification, sending a first card binding notification message, so the first application completes a binding between the card identifier of the target card and the user identifier of the target user in the first application. Under Step 2A Prong Two, the “additional elements” have been identified and the limitations are not indicative of integration into a practical application. Under Step 2B, the additional elements have been evaluated and do not amount to “significantly more”. Note that Step 2A Prong Two overlaps with Step 2B, and thus, many of the considerations need not be reevaluated in Step 2B because the answer will be the same. The identification of the additional elements in the claim from Step 2A Prong Two is carried over as well as the conclusion from Step 2A Prong Two on the considerations discussed in MPEP 2106.05(a)-(c), (e), (f), and (h).
The claims are not patent eligible.
Rejections under 35 U.S.C. § 103
36. Applicant argues that the prior art references do not teach or suggest amended claim 36 limitations.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Conclusion
37. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US9172693B2 – Griffin et al. – Discloses methods and systems for secure device binding that provides user convenience through avoiding repetitive logging in when changing apps or moving from website to website, wherein a mobile device undergoes binding to an account so that customers do not always have to enter their password when going through a financial transaction process, on a known (e.g., registered) mobile device.
US20200372490A1 – Ding et al. – Discloses the card binding method applied to a terminal, wherein the method includes: displaying a first screen, where the first screen displays bank cards associated with an account number with which a digital wallet APP is currently logged in to; determining a to-be-verified bank card and at least one to-be-bound bank card from the bank cards.
US20160321628A1 – Xu – Discloses an online payment method, system, and an apparatus, which are applied to the field of information security, and can improve security of user information during online payment, and ensure capital security of a user, the online payment method is applied to a terminal device, and includes: generating a first binding request, where the first binding request includes first user information.
38. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
39. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/Examiner, Art Unit 3692 /DAVID P SHARVIN/Primary Examiner, Art Unit 3692
