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 response to Election/Restriction requirement on 11/22/2025. Claims 36-45 and 55 are elected for examination. Claims 46-54 are withdrawn. Claims 36-45 and 55 are pending.
Information Disclosure Statement
3. The information disclosure statements (IDS) submitted on 02/13/2024 and 12/19/2024. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Interpretation
Intended Use
4. Intended use language is generally not given patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” and “for.”
5. Claim 36 recites “accepting an access … calling a first application to scan an information…” and “interacting with a card issuing server… to complete a binding…”.
Claim 38 recites “sending … a card binding activation message … enabling the card issuing server to perform a card binding”.
Claim 39 recites “interacting with the card issuing server … to complete the binding …”.
Claim 41 recites “decrypting the encrypted card number … to obtain the card number”.
Claim 42 recites “interacting with the card issuing server … to complete the binding …” and “under a condition… interacting with the card issuing server … to complete the binding…”.
Claims 45 recites “receiving a management operation … to perform a management operation …”.
6. The underlined limitations represent intended use and are not given patentable weight.
Claim Rejections - 35 USC §101
7. 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.
8. 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.
9. In the instant case, claim 36 is directed “a method of a card binding”.
10. Claim 36 recites “binding a payment card”. Specifically, claim recites “accepting an access … to a first page address indicated … calling … to scan an information carrier pattern, and acquiring a card number of a target card indicated by the information carrier pattern; acquiring user information about a target user… wherein the target user is a user logging onto … and the user information comprises a user identifier of the target user …; sending … 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 … based on the card binding page; and interacting … by using the identity information, to complete a binding between a card identifier of the target card and a user identifier of the target user …”. 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)).
11. 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 user terminal”, “a first application”, “a back-end server of the first application”, and “a card issuing server and a back-end server of a 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” and “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” 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)).
12. 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.
13. Hence, claim 36 is not patent eligible.
14. Dependent claim 37 further describes the abstract idea of binding a payment card, as it recites “the information carrier pattern comprises … and information recorded … comprises the first page address and the card number of the target card, or the information recorded … comprises the first page address and … version of the card number of the target card; 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”. The additional elements such as “a Quick Response (QR) code” and “an encrypted version” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 38 further describes the abstract idea of binding a payment card, as it recites “sending … a card binding activation message comprising the card number of the target card and the identity information, enabling … to perform a card binding activation verification using the identity information; receiving card binding activation verification result information sent …; 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 … 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 … completes a binding between the card identifier of the target card and the user identifier of the target user …”. The additional elements such as “the card issuing server”, “the back-end server of the first application”, and “the first application” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “sending, to the card issuing server, a card binding activation message comprising the card number of the target card and the identity information, enabling the card issuing server to perform a card binding activation verification using the identity information” and “receiving card binding activation verification result information sent by the card issuing server” 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)).
Dependent claim 39 further describes the abstract idea of binding a payment card, as it recites “wherein the card binding page further comprises … the card binding confirmation message is further used to indicate…; and interacting with … by using the identity information, to complete the binding between the card identifier of the target card and the user identifier of the target user … further comprises: sending … a card binding matching message comprising the identity information, so that… looks up a user identifier matching the identity information; under a condition that the user identifier matching the identity information is found, receiving a card binding request message sent … wherein the card binding request message is used to request the card identifier of the target card; and sending … a second card binding notification message comprising the card identifier of the target card, so that … completes a binding between the card identifier of the target card and a user identifier of the target user … wherein the user identifier of the target user … is a user identifier matching the identity information”. The additional elements such as “one or more options of applications supported by the card binding server”, “a selected card binding application, and the card binding application further comprises a second application”, “the card issuing server and the back-end server of the card binding application”, “a back-end server of the second application”, and “the second application” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “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” 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” 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)).
Dependent claim 40 further describes the abstract idea of binding a payment card, as it recites “the card binding page further comprises an area for filling an identity information; or the user information further comprises the identity information, and the card binding page further comprises the identity information”.
Dependent claim 41 further describes the abstract idea of binding a payment card, as it recites “wherein acquiring the card number of the target card … comprises: receiving the card number of the target card, sent …; and …the … card number of the target card using … to obtain the card number of the target card”. The additional elements such as “the user terminal”, “encrypted with a first key” “decrypting the encrypted card number”, and “a pre-stored second key paired with the first key” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “receiving the card number of the target card, sent by the user terminal and encrypted with a first key” 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)).
Dependent claim 42 further describes the abstract idea of binding a payment card, as it recites “receiving a dynamic verification code request message sent …; sending a first dynamic verification code …; receiving a second dynamic verification code sent …; interacting with … by using the identity information, to complete the binding between the card identifier of the target card and the user identifier of the target user … comprises: under a condition that the first dynamic verification code coincides with the second dynamic verification code, interacting with … by using the identity information, to complete the binding between the card identifier of the target card and the user identifier of the target user …”. The additional elements such as “the user terminal”, “the card issuing server and the back-end server of the card binding application”, “the card binding application”, and “the card binding application” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “receiving a dynamic verification code request message sent by the user terminal” and “sending a first dynamic verification code to the user terminal” 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)).
Dependent claim 43 further describes the abstract idea of binding a payment card, as it recites “determining whether … belongs to applications supported …; and acquiring the user information about the target user … comprising: under a condition that … belongs to the applications supported … acquiring the user information about the target user …”. The additional elements such as “the first application”, “the card binding server”, and “the back-end server of the first application” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field.
Dependent claim 44 further describes the abstract idea of binding a payment card, as it recites “sending a third page address corresponding to a redirected card binding result page … 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; and accepting the access … to the third page address”. The additional element such as “the user terminal” represents the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “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” 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)).
Dependent claim 45 further describes the abstract idea of binding a payment card, as it recites “accepting an access … 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 …; and receiving a management operation instruction … to perform a management operation on a binding relationship indicated by the management operation instruction, wherein the management operation comprises one or more of a disabling operation, an enabling operation, and a payment limit setting operation”. The additional elements such as “the user terminal” and “the card binding application” represent the use of a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use. And, therefore, do not improve the functioning of a computer, or to any other technology or technical field. With respect to “receiving a management operation instruction of the user terminal to perform a management operation on a binding relationship indicated by the management operation instruction” 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)).
Conclusion
15. 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.
16. 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
17. 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.
18. 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.
19. 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.
20. Claim 36-45 and 55 are rejected under 35 U.S.C. 103 as being unpatentable over US9172693B2 to Griffin et al. in view of US20120209749A1 to Hammad et al.
21. As per claim 36:
Griffin et al. discloses the following limitations:
acquiring user information about a target user from a back-end server of the first application, 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 (Col.2, lines 56-62 “In one embodiment, a mobile device is bound, or undergoes binding, to an account—for example, with a service provider, merchant, bank, or other commercial entity—to enable a streamlined authentication flow so that customers do not always have to enter their password when going through a payment flow, or other financial transaction process”, col/line 2/66-3/4 “In one embodiment, a device is bound during an initial login, for example, through device interrogation to get a device identification (ID) which may include one or more device identifiers. Once logged in, the user can select an option to be remembered for future visits to any app or website that shares a service provider library.”, col.5, lines 10-25 “Service provider 120 may be an online payments provider, for example, providing processing for online financial and information transactions with a merchant 130 on behalf of a user 102. Service provider server 122 may include one or more identity apps 124, which may be adapted to interact with the client mobile device 104 as well as merchant server 132 over network 106 to facilitate the purchase of items, products, and services by user 102. Service provider server 122 may be configured to maintain multiple user and merchant accounts in an account database 126; each merchant account may include or be separate from account information 128 associated with individual users, including user 102 and one or more merchants 130. For example, account information 128 may include identity information of user 102 and merchants 130, such as one or more full names, business names, street addresses, email addresses and phone number”
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 (Fig.2, items 201, 202, fig.3B, item 304; col.5, lines 40-51 “At step 201, a user 102 may communicate over a network 106, using a mobile device 104, with a merchant 130, using the merchant's purchase app 134, for example, to browse the merchant's website and arrive at viewing a shopping cart page such as that shown in FIG. 3A. Tithe user clicks the pay button 302 in FIG. 3A, the user may be redirected to a page such as FIG. 3B, and method 200 may continue at step 202. At step 202, user 102 may login to an account 128 belonging to or associated with user 102 by entering, for example, a username (e.g., email address) and a password in an account login dialog box 304 of a non-option login page, as shown at FIG. 3B.”)
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 (Col.7, lines 37-53 “FIG. 2C illustrates an example of a subsequent (after the first time) authentication flow, for example, for a user 102 with a service provider 120 in a method 200 for binding a user device in a mobile payment system such as system 100. At step 231, a user 102 may communicate over a network 106, using a mobile device 104, with a merchant 130, using the merchant's purchase app 134, for example, to browse the merchant's website and arrive at viewing a shopping cart page such as that shown in FIG. 3A. If the user clicks the pay button 302 in FIG. 3A, because the user has opted in, method 200 may continue at step 203, skipping the login step of 202 to save the user time and provide convenience of not being required, for example, to re-enter a username and password. If, on the other hand the user 102 decides to log out, method 200 may continue at step 202 (e.g., the “regular” user name and password login) of FIG. 2, as shown in FIG. 2C, giving the user 102 the alternative to log back in again, if desired”, claim 7 “when the user device is bound to the user account and when a new account successfully logs in, the processor removes the user device as being actively associated with the user account and binds the user device to the new account”)
interacting with a card issuing server and a back-end server of a card binding application by using the identity information, to complete a binding between a card identifier of the target card and a user identifier of the target user in the card binding application, wherein the card binding application comprises the first application (Col.4, lines 27-51 “As seen in FIG. 1, a browser app 108 may run on mobile device 104 and may be used to provide a user interface to permit user 102 to browse information available over network 106. For example, browser app 108 may be implemented as a web browser to view information available over network 106. In one implementation, browser app 108 may comprise a software program such as a graphical user interface (GUI) executable by a processor that is configured to interface and communicate with merchant 130 and service provider 120 via network 106. For example, user 102 may access merchant websites via merchant 130 to find and purchase items. User 102, through client mobile device 104, may also communicate with service provider server 122 to create an account and make a payment to the merchant 130 via service provider 120. Mobile device 104 may include other apps 110 as may be desired to make additional features available to user 102, including making quick payments with service provider server 122. For example, apps 110 may include interfaces and communication protocols that allow the user 102 to receive and transmit information through online sites via network 106. Apps 110 may also include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 106 and various other types of generally known programs and applications.”, col.8, lines 16-35 “When the user 102 has successfully logged in, the service provider 120 can associate the user's account 128 with the user device 104 which was previously registered. At that moment, the user 102 is bound to this device 104. A risk management analysis may be performed by the service provider 120 to determine whether the device can be registered to the account. For example, there might be a blacklisted account or device that should not be bound. If the device cannot be registered with that particular account, the service provider 120 can display an error message and not let the transaction be completed. The account database 126 can be updated to reflect the new registration of the device 104 to the account 128. The app 108 or 110 can also be added to that device 104 on that account 128. This may enable the service provider 120 to see which apps are being used on a particular user's device 104. Note that this does not imply that binding is happening at the app level. A device 104 may be registered regardless of what happens with the payment once authentication is completed. An email or other suitable notification can then be sent to the user 102.”)
Griffin 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 indicated by the user terminal calling a first application to scan an information carrier pattern, and acquiring a card number of a target card indicated by the information carrier pattern ([0025] “…For example, the user may be viewing the website using a secure display that is part of a trusted computing device of the user, e.g., 113, or via a POS terminal in a brick-and-mortar store. Upon indicating that the user wishes to checkout the items in the virtual shopping cart, the user may generate, e.g., 114, a QR code 115b via a mobile app on the user's mobile device including information on the user payment methods, offers, rewards, and/or other aspects connected to the user's virtual wallet. The user may provide the QR code displayed on the user's mobile device to a webcam (or other QR code capture device and/or mechanism) installed on the trusted computing device (or POS terminal). The user's trusted computing device or POS terminal may obtain a snapshot of the QR code generated by the user's mobile device, e.g., 116, and utilize payment information from QR code generated by the user to create a purchase transaction request for processing by the payment network…”, [0033] “…The user may obtain a snapshot of the QR code, and provide the information embodied in the QR code along with information from the user's mobile device (e.g., subscriber account number linked to the user's virtual wallet, pay account information, and/or the like). Upon processing of the payment information by the payment network… As another example, a billboard, wall hanging, poster, in-store advertisement, hoarding, etc., e.g., 180, may include an offer for a product/service, and a QR code including merchant information and product information identifying a purchase amount, 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 teaching of Griffin et al. for secure device binding that provides user convenience through avoiding repetitive logging in when changing apps (application programs) or moving from website to website (‘693, col.2, lines 53-56) for viewing the website using a secure display that is part of a trusted computing device of the user and the user may provide the QR code displayed on the user's mobile device to a webcam installed on the trusted computing device (or POS terminal) (‘749, [0025]).
22. As per claim 37:
Griffin et al. does not disclose, however, Hammad et al., as shown, teaches the following limitations:
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 ([0025] “…in some implementations, the user may be able to utilize a QR code generated by the user's mobile device as a replacement for a plastic payment card (e.g., credit, debit, prepaid card)… In some implementations, the QR code may be representative of a one-time anonymized credit card number…”, [0052] “…the merchant server may utilize an API call to the pay network server to request generation of the QR code. The pay network server may generate the QR code for the merchant server, e.g., 416 c, and provide, e.g., 416 d, the QR code to the merchant server. For example, the pay network server may encode the information provided by the merchant into the QR code, and may also advantageously encode security information, time validity information, digital certificate information, anonymous shipping information, QR code generation/processing fee information, etc. into the QR code.”)
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 (Fig.11E, item 1152; [0121] “With reference to FIG. 11E, in one embodiment, the snap mode may also offer facilities for adding a funding source to the wallet application. In one implementation, 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. 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, and/or the like. In one implementation, the code may be found on a face of the physical pay card…”)
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 teaching of Griffin et al. for secure device binding that provides user convenience through avoiding repetitive logging in when changing apps (application programs) or moving from website to website (‘693, col.2, lines 53-56) 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, [0025], [0052], [0121]).
23. As per claim 38:
Griffin et al. discloses the following limitations:
sending, to the card issuing server, a card binding activation message comprising the card number of the target card and the identity information, enabling the card issuing server to perform a card binding activation verification using the identity information (Col.5, lines 22-35 “account information 128 may include identity information of user 102 and merchants 130, such as one or more full names, business names, street addresses, email addresses and phone numbers, website addresses, or other types of financial information, which may be used to facilitate online transactions between user 102 and merchants 130. Account information 128 or identity app 124 may also include device identifiers (e.g., unique device identifier present on the device, as described above, such as IMEI number) for user devices such as mobile device 104. Thus, identity app 124 may be configured to interact with a merchant server 132, a user 102, mobile device 104, or other payee to process, obtain, and store information for allowing quick payments.”; col.6, lines 10-34 “At step 204, if user 102 has at some point (e.g., at step 202 in FIG. 2 or step 212 in FIG. 2A) opted in, for example, by checking the check box on an option login page, such as checkbox 403 shown in FIG. 4, then the user's mobile device 104 has undergone binding to the user 102 and user's account information 128, and if the binding is still in effect the user can skip any further login process and may be returned to the merchant's app or another app running on device 104, so method 200 may continue at step 208 as shown in FIG. 2. Otherwise, method 200 may continue at step 205 as shown in FIG. 2.”)
receiving card binding activation verification result information sent by the card issuing server (Col.10, lines 26-41 “The service provider 120 may maintain a transaction history, such as which app 108, 110 and device 104 a payment was made from. This could be particularly important to help identify transactions made without user authentication. These details may be different for the buyer and seller. The buyer may want to see both the device 104 and app 108, 110 used. The seller may only see the app name. Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”)
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 (Col/line 8/54-9/2 “Returning to FIGS. 2A, 2B, and 2C, the following example illustrates a process for a subsequent authentication from the same user. Note that there could be cases where the service provider 120 allows multiple people to have the same device 104. If the next login on the device 104 is from same user as the first time, no further action is required for binding the device 104 to the account 128. The app name and app ID should be passed and stored in so they can be associated with the transaction and listed as an app that is being used by the device 104 (this information may be visible in the profile and in admin in database 126, for example, but may not be needed). Generally, the device 104 and app 108, 110 information may still be passed in as to associate the device and apps with a particular transaction.”, col.10, lines 33-41 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”)
24. As per claim 39:
Griffin et al. discloses 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 (Col/line 4/63-5/9 “Merchant server 132 may also run a browser app 136 and other applications 138. Browser app 136 and other applications 138 may enable the merchant to access a service provider 120 web site and communicate with service provider server 122; for example, to convey and receive information to allow a quick payment through the service provider 120. In accordance with one or more embodiments, consumers (e.g., user 102) may access apps for making transactions (e.g., payments) with a merchant 130 through a service provider 120) without having to log in, which may enable quicker service (e.g., completing payment processing) with service provider server 132.”, col.10, lines 33-41 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”
interacting with the card issuing server and the back-end server of the card binding application by using the identity information, to complete the binding between the card identifier of the target card and the user identifier of the target user in the card binding application (Col.4, lines 27-51 “As seen in FIG. 1, a browser app 108 may run on mobile device 104 and may be used to provide a user interface to permit user 102 to browse information available over network 106. For example, browser app 108 may be implemented as a web browser to view information available over network 106. In one implementation, browser app 108 may comprise a software program such as a graphical user interface (GUI) executable by a processor that is configured to interface and communicate with merchant 130 and service provider 120 via network 106. For example, user 102 may access merchant websites via merchant 130 to find and purchase items. User 102, through client mobile device 104, may also communicate with service provider server 122 to create an account and make a payment to the merchant 130 via service provider 120. Mobile device 104 may include other apps 110 as may be desired to make additional features available to user 102, including making quick payments with service provider server 122. For example, apps 110 may include interfaces and communication protocols that allow the user 102 to receive and transmit information through online sites via network 106. Apps 110 may also include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 106 and various other types of generally known programs and applications.”, col.8, lines 16-35 “When the user 102 has successfully logged in, the service provider 120 can associate the user's account 128 with the user device 104 which was previously registered. At that moment, the user 102 is bound to this device 104. A risk management analysis may be performed by the service provider 120 to determine whether the device can be registered to the account. For example, there might be a blacklisted account or device that should not be bound. If the device cannot be registered with that particular account, the service provider 120 can display an error message and not let the transaction be completed. The account database 126 can be updated to reflect the new registration of the device 104 to the account 128. The app 108 or 110 can also be added to that device 104 on that account 128. This may enable the service provider 120 to see which apps are being used on a particular user's device 104. Note that this does not imply that binding is happening at the app level. A device 104 may be registered regardless of what happens with the payment once authentication is completed. An email or other suitable notification can then be sent to the user 102.”)
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 (Col.3, lines 17-25 “Device binding may be based on a unique device identifier which is present on the device (e.g., international mobile equipment (IMEI) number, name of device, various date modified checks, and other variables, or a combination of identifiers). Use of such a device-unique identifier may enable the service provider to remember a user across apps on a device if the user wants to skip subsequent logins on a device. Multiple mobile devices may be bound to a single account.”)
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 (Col/line 8/54-9/2 “Returning to FIGS. 2A, 2B, and 2C, the following example illustrates a process for a subsequent authentication from the same user. Note that there could be cases where the service provider 120 allows multiple people to have the same device 104. If the next login on the device 104 is from same user as the first time, no further action is required for binding the device 104 to the account 128. The app name and app ID should be passed and stored in so they can be associated with the transaction and listed as an app that is being used by the device 104 (this information may be visible in the profile and in admin in database 126, for example, but may not be needed). Generally, the device 104 and app 108, 110 information may still be passed in as to associate the device and apps with a particular transaction.”, col.10, lines 33-41 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”)
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 (Col.5, lines 22-35 “account information 128 may include identity information of user 102 and merchants 130, such as one or more full names, business names, street addresses, email addresses and phone numbers, website addresses, or other types of financial information, which may be used to facilitate online transactions between user 102 and merchants 130. Account information 128 or identity app 124 may also include device identifiers (e.g., unique device identifier present on the device, as described above, such as IMEI number) for user devices such as mobile device 104. Thus, identity app 124 may be configured to interact with a merchant server 132, a user 102, mobile device 104, or other payee to process, obtain, and store information for allowing quick payments.”; col.6, lines 10-34 “At step 204, if user 102 has at some point (e.g., at step 202 in FIG. 2 or step 212 in FIG. 2A) opted in, for example, by checking the check box on an option login page, such as checkbox 403 shown in FIG. 4, then the user's mobile device 104 has undergone binding to the user 102 and user's account information 128, and if the binding is still in effect the user can skip any further login process and may be returned to the merchant's app or another app running on device 104, so method 200 may continue at step 208 as shown in FIG. 2. Otherwise, method 200 may continue at step 205 as shown in FIG. 2.”)
25. As per claim 40:
Griffin et al. discloses the following limitations:
the card binding page further comprises an area for filling an identity information (Col.5, lines 47-51 “At step 202, user 102 may login to an account 128 belonging to or associated with user 102 by entering, for example, a username (e.g., email address) and a password in an account login dialog box 304 of a non-option login page, as shown at FIG. 3B”, col.6, lines 21-34 “At step 205, if the user has a PIN (e.g., the PIN may have been created previously at step 207) then any further login process may be abbreviated through use of the PIN. The user's PIN may provide enhanced security by being associated to the user's mobile device 104 along with the user's mobile device 104 having undergone binding (as described further below) yet at the same time provide extra convenience by avoiding a complete re-login when switching apps or website. If the user 102 has a PIN, user 102 may, for example, enter the PIN and method 200 may continue at step 208 as shown in FIG. 2, similar to the case (e.g., step 204) in which the user 102 has elected to be remembered but this case (step 205) may require PIN entry rather than being simply automatic.”)
the user information further comprises the identity information, and the card binding page further comprises the identity information (Col.2, lines 56-62 “In one embodiment, a mobile device is bound, or undergoes binding, to an account—for example, with a service provider, merchant, bank, or other commercial entity—to enable a streamlined authentication flow so that customers do not always have to enter their password when going through a payment flow, or other financial transaction process”, col.11, lines 4-12 “For devices 104 that are registered, the authentication type may be either quick pay or a PIN or password. The device interrogation calls may also need to pass back additional information that can be used for the login flow, which can include opt-in preference (so method 200 may know if box 403, for example, should be pre-checked), primary email address (to pre-fill email box), name (to display for quick pay), and phone number (to use for PIN login if a PIN exists on the account).
26. As per claim 41:
Griffin et al. does not disclose, however, Hammad et al., as shown, teaches the following limitations:
receiving the card number of the target card, sent by the user terminal and encrypted with a first key ([0121] “With reference to FIG. 11E, in one embodiment, the snap mode may also offer facilities for adding a funding source to the wallet application. In one implementation, 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. 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, and/or the like. 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.”)
decrypting the encrypted card number of the target card using a pre-stored second key paired with the first key, to obtain the card number of the target card ([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. In some implementations, the pay network server may obtain the encrypted data from the card authorization request provided by the user device, and attempt to decrypt the encrypted data, e.g., using a RSA private/public that is complementary to the key the pay network server initially provided to the merchant server for encrypting the purchase data before embedding it into the QR code. If the pay network server is able to decrypt the purchase data, then the merchant is authenticated as being a valid merchant. In some implementations, the pay network server may compare the purchase data decrypted from the card authorization with data provided by the user/user device, to determine whether the data from these different sources (user/user device, and merchant) correspond properly to each other.”)
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 teaching of Griffin et al. for secure device binding that provides user convenience through avoiding repetitive logging in when changing apps (application programs) or moving from website to website (‘693, col.2, lines 53-56) having 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 and the 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, wherein a server is able to decrypt the purchase data, then the merchant is authenticated as being a valid merchant (‘749, [0061], [0121]).
27. As per claim 42:
Griffin et al. discloses the following limitations:
receiving a dynamic verification code request message sent by the user terminal (Col.3, lines 7-8 “A login may be required in certain situations, such as a high dollar amount purchase.”, lines 59-66 “The app or mobile website can be a shopping or commerce app, P2P (peer-to-peer) money transfer app, or any other type of service that needs to use the login provided by the financial service provider. FIG. 1 illustrates a system 100, in accordance with one or more embodiments, for making a payment (or other financial transaction needing security) with device binding by a user 102 using a mobile device 104”)
sending a first dynamic verification code to the user terminal (Col/line 7/62-8/11 “When authentication is happening, the service provider 120 may pass additional parameters for device binding. These parameters may be passed directly or as referenced in a token. The choice may differ on whether the device 104 is connecting to a web flow (e.g., EC, express checkout) or a pure API flow (e.g., MPL, mobile payment library). Examples of parameters for device binding from the service provider 120 mobile library include device information, such as device ID, device ID type (UDID) or IMEI, platform (e.g., Apple®, Android®), device name (e.g., Joe's iPhone®), device category (e.g., phone, computer), device model (e.g., iPod Touch®), operating system (OS) information, such as OS version and OS name, app information, such as app name (bundle display name), app ID (such as bundle ID used by Apple, Inc.), bundle name (different from above), and PayPal® x.com app”)
receiving a second dynamic verification code sent by the user terminal (Col.8, lines 19-31 “A risk management analysis may be performed by the service provider 120 to determine whether the device can be registered to the account. For example, there might be a blacklisted account or device that should not be bound. If the device cannot be registered with that particular account, the service provider 120 can display an error message and not let the transaction be completed. The account database 126 can be updated to reflect the new registration of the device 104 to the account 128. The app 108 or 110 can also be added to that device 104 on that account 128. This may enable the service provider 120 to see which apps are being used on a particular user's device 104”)
interacting with the card issuing server and the back-end server of the card binding application by using the identity information, to complete the binding between the card identifier of the target card and the user identifier of the target user in the card binding application (Col.4, lines 27-51 “As seen in FIG. 1, a browser app 108 may run on mobile device 104 and may be used to provide a user interface to permit user 102 to browse information available over network 106. For example, browser app 108 may be implemented as a web browser to view information available over network 106. In one implementation, browser app 108 may comprise a software program such as a graphical user interface (GUI) executable by a processor that is configured to interface and communicate with merchant 130 and service provider 120 via network 106. For example, user 102 may access merchant websites via merchant 130 to find and purchase items. User 102, through client mobile device 104, may also communicate with service provider server 122 to create an account and make a payment to the merchant 130 via service provider 120. Mobile device 104 may include other apps 110 as may be desired to make additional features available to user 102, including making quick payments with service provider server 122. For example, apps 110 may include interfaces and communication protocols that allow the user 102 to receive and transmit information through online sites via network 106. Apps 110 may also include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 106 and various other types of generally known programs and applications.”, col.8, lines 16-35 “When the user 102 has successfully logged in, the service provider 120 can associate the user's account 128 with the user device 104 which was previously registered. At that moment, the user 102 is bound to this device 104. A risk management analysis may be performed by the service provider 120 to determine whether the device can be registered to the account. For example, there might be a blacklisted account or device that should not be bound. If the device cannot be registered with that particular account, the service provider 120 can display an error message and not let the transaction be completed. The account database 126 can be updated to reflect the new registration of the device 104 to the account 128. The app 108 or 110 can also be added to that device 104 on that account 128. This may enable the service provider 120 to see which apps are being used on a particular user's device 104. Note that this does not imply that binding is happening at the app level. A device 104 may be registered regardless of what happens with the payment once authentication is completed. An email or other suitable notification can then be sent to the user 102.”)
under a condition that the first dynamic verification code coincides with the second dynamic verification code, interacting with the card issuing server and the back-end server of the card binding application by using the identity information, to complete the binding between the card identifier of the target card and the user identifier of the target user in the card binding application (Col.3, lines 7-8 “A login may be required in certain situations, such as a high dollar amount purchase.”, lines 59-66 “The app or mobile website can be a shopping or commerce app, P2P (peer-to-peer) money transfer app, or any other type of service that needs to use the login provided by the financial service provider. FIG. 1 illustrates a system 100, in accordance with one or more embodiments, for making a payment (or other financial transaction needing security) with device binding by a user 102 using a mobile device 104”, col.8, lines 19-31 “A risk management analysis may be performed by the service provider 120 to determine whether the device can be registered to the account. For example, there might be a blacklisted account or device that should not be bound. If the device cannot be registered with that particular account, the service provider 120 can display an error message and not let the transaction be completed”, col.10, lines 33-41 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”)
28. As per claim 43:
Griffin et al. discloses the following limitations:
determining whether the first application belongs to applications supported by the card binding server (Col.8, lines 28-43 “The app 108 or 110 can also be added to that device 104 on that account 128. This may enable the service provider 120 to see which apps are being used on a particular user's device 104. Note that this does not imply that binding is happening at the app level. A device 104 may be registered regardless of what happens with the payment once authentication is completed. An email or other suitable notification can then be sent to the user 102. After registration, the payment flow may continue normally (as outlined above, for example, with reference to FIGS. 3A through 3E). The transaction or information exchange can be associated with a particular app (e.g., an app 110) on a particular device (e.g., device 104) so that the service provider 120 can run reports and make this information visible for administration conducted by the service provider 120.”)
acquiring the user information about the target user from the back-end server of the first application (Col/line 2/66-3/4 “In one embodiment, a device is bound during an initial login, for example, through device interrogation to get a device identification (ID) which may include one or more device identifiers. Once logged in, the user can select an option to be remembered for future visits to any app or website that shares a service provider library.”)
under a condition that the first application belongs to the applications supported by the card binding server, acquiring the user information about the target user from the back-end server of the first application (Col/line 8/54-9/2 “Returning to FIGS. 2A, 2B, and 2C, the following example illustrates a process for a subsequent authentication from the same user. Note that there could be cases where the service provider 120 allows multiple people to have the same device 104. If the next login on the device 104 is from same user as the first time, no further action is required for binding the device 104 to the account 128. The app name and app ID should be passed and stored in so they can be associated with the transaction and listed as an app that is being used by the device 104 (this information may be visible in the profile and in admin in database 126, for example, but may not be needed). Generally, the device 104 and app 108, 110 information may still be passed in as to associate the device and apps with a particular transaction.”).
29. As per claim 44:
Griffin et al. discloses 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 (Col/line 8/54-9/2 “Returning to FIGS. 2A, 2B, and 2C, the following example illustrates a process for a subsequent authentication from the same user. Note that there could be cases where the service provider 120 allows multiple people to have the same device 104. If the next login on the device 104 is from same user as the first time, no further action is required for binding the device 104 to the account 128. The app name and app ID should be passed and stored in so they can be associated with the transaction and listed as an app that is being used by the device 104 (this information may be visible in the profile and in admin in database 126, for example, but may not be needed). Generally, the device 104 and app 108, 110 information may still be passed in as to associate the device and apps with a particular transaction.”, col.10, lines 33-41 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”)
accepting the access from the user terminal to the third page address (Col.5, lines 40-51 “At step 201, a user 102 may communicate over a network 106, using a mobile device 104, with a merchant 130, using the merchant's purchase app 134, for example, to browse the merchant's website and arrive at viewing a shopping cart page such as that shown in FIG. 3A. Tithe user clicks the pay button 302 in FIG. 3A, the user may be redirected to a page such as FIG. 3B, and method 200 may continue at step 202. At step 202, user 102 may login to an account 128 belonging to or associated with user 102 by entering, for example, a username (e.g., email address) and a password in an account login dialog box 304 of a non-option login page, as shown at FIG. 3B.”)
30. As per claim 45:
Griffin et al. discloses 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 (Col.8, lines 33-51 “A device 104 may be registered regardless of what happens with the payment once authentication is completed. An email or other suitable notification can then be sent to the user 102. After registration, the payment flow may continue normally (as outlined above, for example, with reference to FIGS. 3A through 3E). The transaction or information exchange can be associated with a particular app (e.g., an app 110) on a particular device (e.g., device 104) so that the service provider 120 can run reports and make this information visible for administration conducted by the service provider 120. Once the device 104 is registered, the service provider 120 can send an email or text to the user 102 (e.g., buyer) to let the user know what happened, what it means, and how the user can update it. The binding may happen before the payment is completed so the “your device is registered” email may come before the payment complete email. The registration email can also be sent even if the payment is not completed as long as the registration is completed during log in.”, col.10, lines 33-52 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly. The service provider 120 may also have the ability to manage settings, such as updating tables so that administration agents can see the status of a device 104 on an account 128 as active (or other relevant term), maintain the ability for an administration agent to look up a device 104 or click on a device ID in the table of a user's devices, which can load up a list of accounts 128 that have been bound to the device 104. This list may include devices 104 that have been removed. The service provider 120 may identify which app 108, 110 was used and which device 104 was used for each mobile payment library (MPL) transaction.”
receiving a management operation instruction of the user terminal to perform a management operation on a binding relationship indicated by the management operation instruction (Col.8, lines 44-52 “Once the device 104 is registered, the service provider 120 can send an email or text to the user 102 (e.g., buyer) to let the user know what happened, what it means, and how the user can update it. The binding may happen before the payment is completed so the “your device is registered” email may come before the payment complete email. The registration email can also be sent even if the payment is not completed as long as the registration is completed during log in. The email can inform the user that the device is registered.”)
wherein the management operation comprises one or more of a disabling operation, an enabling operation, and a payment limit setting operation (Col.10, lines 33-41 “Users may have the ability to manage settings, such as disable or enable an existing device 104 for staying logged in and view apps that have been used. Since the device binding can be at a device level or app level, users (e.g., user 102) do not need to be able to take action on these applications 108, 110, but they may want to know which apps have been used on their device 104. In embodiments where the device binding is at an app level, the users may take actions on the applications directly.”)
31. As per claim 55:
Griffin 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 (Col.2, lines 17-27 “In a further embodiment, a computer program product comprises a non-transitory computer readable medium having computer readable and executable code for instructing a processor to perform a method that includes: communicating over a network with a user device; binding the user device to a user account; and using the binding to maintain a secure connection with the user device when a user switches between a first app on the user device and a second app on the user device or when the user switches between a first website viewed on the user device and a second website viewed on the user device”)
Conclusion
32. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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.
33. 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
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692