Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/29/2025 has been entered.
Status of Claims
This action is in reply to the amendment filed on 12/29/2025.
Claims 1, 8, 10-11, 13 and 15 are currently amended.
Claims 1-21 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive.
Applicant argues that the claims are not directed to an abstract idea on pages 9-10 of the response. Examiner respectfully disagrees, The claims are directed to binding a bank card to a terminal, which is considered fundamental economic practice and therefore abstract.
Applicant further argues the claim amendments provide an improvement to technology and a specific limitation other than what is well-understood, routine, and conventional in the field.
Examiner respectfully disagrees, the newly amended element "displaying, by the first terminal and in response to the first terminal binding the to-be- bound bank card to the first terminal, a third user interface comprising a graphical indication that the to-be-bound bank card is bound to the first terminal." amounts to mere instruction to apply the exception Whether the claim invokes computers or other machinery merely as a tool to perform an existing process as invoking computers or other machinery merely as a tool to perform an existing process. (see MPEP 2016.05(f)(2)).
For at least the reasons stated above applicant's arguments regrading 35 U.S.C. § 101 are not persuasive.
Regarding the 102 and 103 rejection Applicant argues that Brown fail to teach the newly amended claims.
Examiner assets that the rejection now relies on Singh and Kurani to teach the amended claims limitations.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 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.
The claims recite a method, and system. For the purposes of this analysis, representative claim 1 is addressed.
displaying, by a first terminal, in response to a first operation to a first application, and before a first bank card associated with a first account of the first application is bound to the first terminal, a first user interface comprising an identifier of the first bank card, wherein the first bank card is not bound to the first terminal, and wherein the first bank card is bound to a second terminal when the first application is logged into the first account on the second terminal;
receiving, by the first terminal, a second operation to select the first bank card as a to-be-bound bank card;
displaying, by the first terminal and in response to the second operation, a second user interface prompting a user to enter verification information of the to-be-bound bank card;
receiving, by the first terminal and after displaying the second user interface, data related to the to-be-bound bank card;
binding, by the first terminal and based on the data, the to-be-bound bank card to the first terminal; and
displaying, by the first terminal and in response to the first terminal binding the to-be- bound bank card to the first terminal, a third user interface comprising a graphical indication that the to-be-bound bank card is bound to the first terminal.
The additional elements of claim 1 such as “…by a first terminal…”, “…second terminal when the first application is logged into the first account on the second terminal;“, “…by the first terminal and in response to the second operation, a second user interface…”, “…by the first terminal and after displaying the second user interface…”, “…by the first terminal and in response to the first terminal binding the to-be- bound bank card to the first terminal…” 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.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of fundamental economic practice.
dependent claims 2-7, 9-14, and 16 -21 recited additional details which only further narrow the abstract idea and do not add any additional features, alone or in combination, that would provide a practical application or provide significantly more.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect 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.
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
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
Claims 1-2, 5, 8 - 9, 12 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Brown et al. (US 2015/0348025 A1) I in view of Singh et al. (PG PUB US 2013/0152185 A1)
Regarding claims 1, and 8
Brown teaches
A method, comprising: …and wherein the first bank card is bound to a second terminal when the first application is logged into the first account on the second terminal; (See at least Brown [0075] and [0076]: [0075] In response to receiving input from the user at the primary device 10 indicating the desire to provision cards (or digital wallet passes) onto the secondary user device, a “ListCards” request may be sent from device 10 to broker module 114. In general, broker module 114 may maintain a list of cards that have been previously provisioned to that user. The list of cards may be linked to an account that the user holds with the service provider subsystem 112. The user may have to be logged in into his or her account using a username and associated password in order to access the list of cards (as an example). [0076] Assuming the user is logged in, broker module 114 may forward a “CardsList” to the primary user device 10 (at step 418). At step 420, a list of known cards may be presented to the user, and the user may be given an opportunity to select one or more cards from the CardsList to provision onto the secondary user device 102. In one suitable arrangement, only a subset of digits for each payment card (e.g., only the last four digits of the funding primary account number) is displayed on the CardsList to prevent fraud. In another suitable arrangement, only the name of each payment card is displayed (e.g., “myAmexCard,” “myStarbucksCard,” “mySouthwestBoardingPass,” “myAmazonGiftCard,” etc.).
Receiving, by a first terminal, a second operation to select the first bank card as a to-be-bound bank card; (See at least Brown [0076] Assuming the user is logged in, broker module 114 may forward a “CardsList” to the primary user device 10 (at step 418). At step 420, a list of known cards may be presented to the user, and the user may be given an opportunity to select one or more cards from the CardsList to provision onto the secondary user device 102. In one suitable arrangement, only a subset of digits for each payment card (e.g., only the last four digits of the funding primary account number) is displayed on the CardsList to prevent fraud. In another suitable arrangement, only the name of each payment card is displayed (e.g., “myAmexCard,” “myStarbucksCard,” “mySouthwestBoardingPass,” “myAmazonGiftCard,” etc.).
displaying, by a first terminal, and in response to the second operation, a second user interface prompting a user to enter verification information of the to-be-bound bank card; (See at least Brown [0009] and [0077]: [0009] The broker module may provide a list of payment cards to be displayed to a user at the primary user device. The user may select a payment card from the list and may be prompted to enter security information associated with the selected payment card at the primary user device. [0077] When a card is selected, additional input from the user may be required to provide an additional level of security without being overly burdensome to the user. For example, the user may select a payment card and then be required to enter a corresponding card verification value (CVV). As another example, the user may select a payment card and then be required to enter a corresponding expiration date. As yet another example, the user may select a payment card and then be required to enter a corresponding billing address. These examples are merely illustrative. If desired, other types of information may be requested from the user to verify that the intended user is in possession of the user devices.
receiving, by a first terminal, after displaying the second user interface, data related to the to-be- bound bank card; (See at least Brown [0079] In yet other suitable embodiments, the user may be required to enter other types of one time passwords (OTPs) provided from the service provider subsystem via other secure channels (e.g., the payment network subsystem may require the user to perform an additional verification step prior to fully activating the card at the payment network subsystem). For example, the payment network subsystem may send a list of available contact/verification methods on file (e.g., contact methods including text message, e-mail, automated telephone call, etc.) to the broker module as part of the CheckCardResp, which can then be forwarded to the primary device. The user may select a desired verification/contact method on the primary device from the list, and the selected verification method may then be relayed back to the payment network subsystem via the broker module. The payment network subsystem will then send a verification code “out-of-band” via the selected contact method. Once the user has received the verification code that was sent out-of-band by the payment network subsystem, the user may enter the verification code on the primary user device. The code is then delivered to the broker module, when then forwards the code to the payment network subsystem. In response, the payment network subsystem indicates to the broker module that the card is now active (as far as the payment network is concerned).
binding, by a first terminal, and based on the data, the to-be-bound bank card to the first terminal. (See at least Brown [0068] At step 306, the payment network subsystem may direct the service provider TSM 116 to write the desired credential information (e.g., a device primary account number associated with the provisioned payment card) onto the corresponding payment applet 206 in secure element 104. At this point, the payment applet has been personalized with the credentials necessary to carry out a financial transaction. At step 308, TSM 116 may then notify broker module 114 that a particular payment applet 206 on the secondary device has now been personalized. At step 310, broker module 114 may push an updated pass to the secondary user device via the primary device 10. At this point, the pass can be selected by the user to perform a mobile payment because the corresponding applet 206 has now been activated for payment.)
Additionally, regarding claim 8:
Brown teaches:
a memory configured to store instructions and one or more processors coupled to the memory and configured to execute the instructions to… (See at least Brown [0043] A schematic diagram showing illustrative components that may be used in device 10 is shown in FIG. 3. As shown in FIG. 3, device 10 may include control circuitry such as storage and processing circuitry 28. Storage and processing circuitry 28 may include storage such as hard disk drive storage, nonvolatile memory (e.g., flash memory or other electrically-programmable-read-only memory configured to form a solid state drive), volatile memory (e.g., static or dynamic random-access-memory), etc. Processing circuitry in storage and processing circuitry 28 may be used to control the operation of device 10. This processing circuitry may be based on one or more microprocessors, microcontrollers, digital signal processors, application specific integrated circuits, etc.
one or more processors couple to the memory and configured to execute the instructions (See at least Brown [0043] A schematic diagram showing illustrative components that may be used in device 10 is shown in FIG. 3. As shown in FIG. 3, device 10 may include control circuitry such as storage and processing circuitry 28. Storage and processing circuitry 28 may include storage such as hard disk drive storage, nonvolatile memory (e.g., flash memory or other electrically-programmable-read-only memory configured to form a solid state drive), volatile memory (e.g., static or dynamic random-access-memory), etc. Processing circuitry in storage and processing circuitry 28 may be used to control the operation of device 10. This processing circuitry may be based on one or more microprocessors, microcontrollers, digital signal processors, application specific integrated circuits, etc.
Brown does not specifically teach: displaying, by a first terminal, in response to a first operation to a first application and before a first bank card associated with a first account of the first application is bound to the first terminal, a first user interface comprising an identifier of the first bank card,
However, Singh teaches:
displaying, by a first terminal, in response to a first operation to a first application and before a first bank card associated with a first account of the first application is bound to the first terminal, a first user interface comprising an identifier of the first bank card,least Singh [0030] and Fig. 4: [0030] The controller 36 is running a mobile wallet application, which provides a graphical user interface (GUI) on the display 60. In the mobile wallet, a first "soft" debit card is already provisioned, namely a debit credit card from ABC Bank. When the security token 32 and mobile device 34 commence NFC communications, the mobile wallet application determines that the security token 32 is a credit card that is not already provisioned with the mobile wallet, and provides a GUI prompt inquiring whether this new credit card is to be added to the mobile wallet.)
PNG
media_image1.png
496
546
media_image1.png
Greyscale
displaying, by the first terminal and in response to the first terminal binding the to-be- bound bank card to the first terminal, a third user interface comprising a graphical indication that the to-be-bound bank card is bound to the first terminal. (see at least Singh fig 8)
PNG
media_image2.png
546
486
media_image2.png
Greyscale
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of method for transaction provisions for mobile wireless devices as taught by Singh in order be capable of performing secure payment transactions.” (Singh [0018])
Regarding claims 2 and 9
Brown does not specifically teach: further comprising displaying a bonding progress of the to-be-bound bank card.
However, Singh teaches:
The method of claim 1, further comprising displaying a bonding progress of the to-be-bound bank card. (See at least Singh Fig. 5 and [0030] The controller 36 is running a mobile wallet application, which provides a graphical user interface (GUI) on the display 60. In the mobile wallet, a first "soft" debit card is already provisioned, namely a debit credit card from ABC Bank. When the security token 32 and mobile device 34 commence NFC communications, the mobile wallet application determines that the security token 32 is a credit card that is not already provisioned with the mobile wallet, and provides a GUI prompt inquiring whether this new credit card is to be added to the mobile wallet. For example, the mobile wallet may determine, based upon an PAN number of the security token 32, bank identification information, or other information stored on the security token 32 the type of credit card with which it is communicating. From this information, the mobile wallet may determine not only that the credit card is not already provisioned with the mobile wallet, but it may also determine a location (e.g., website, etc.) from which to download a mobile wallet interface application for the given credit card, as shown in FIG. 5.
PNG
media_image3.png
536
406
media_image3.png
Greyscale
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of method for transaction provisions for mobile wireless devices as taught by Singh in order be capable of performing secure payment transactions.” (Singh [0018])
Regarding claims 5 and 12
Brown teaches:
The method of claim 1, wherein the data comprises a card application. (See at least Brown [0060] In one suitable arrangement, applications processor 200 on secondary user device 102 may be configured to run a mobile payments application. This payments application may allow the user to store credit cards, debit cards, retail coupons, boarding passes, event tickets, store cards, gift cards, loyalty cards, generic cards, and/or other forms of mobile payment. Each of these digital cards, coupons, or tickets is sometimes referred to as a “pass.” As a result, the mobile payments application is sometimes referred to as a “passbook” application or a digital wallet application. Passes may be loaded onto the secondary user device 102 using the broker module 114 (FIG. 1).
Regarding claim 21
Brown teaches:
wherein the first user interface further comprises identifiers of a plurality of other bank cards, and wherein the identifier of the first bank card and the identifiers of the plurality of other bank cards comprise graphic icons and text corresponding to the first bank card and the plurality of other bank cards. (See at least Brown [0075] and [0076]: [0075] In response to receiving input from the user at the primary device 10 indicating the desire to provision cards (or digital wallet passes) onto the secondary user device, a “ListCards” request may be sent from device 10 to broker module 114. In general, broker module 114 may maintain a list of cards that have been previously provisioned to that user. The list of cards may be linked to an account that the user holds with the service provider subsystem 112. The user may have to be logged in into his or her account using a username and associated password in order to access the list of cards (as an example). [0076] Assuming the user is logged in, broker module 114 may forward a “CardsList” to the primary user device 10 (at step 418). At step 420, a list of known cards may be presented to the user, and the user may be given an opportunity to select one or more cards from the CardsList to provision onto the secondary user device 102. In one suitable arrangement, only a subset of digits for each payment card (e.g., only the last four digits of the funding primary account number) is displayed on the CardsList to prevent fraud. In another suitable arrangement, only the name of each payment card is displayed (e.g., “myAmexCard,” “myStarbucksCard,” “mySouthwestBoardingPass,” “myAmazonGiftCard,” etc.).
Claims 3-4, 6-7, 10-11, and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Brown et al. (US 2015/0348025 A1) in view of Singh et al. (PG PUB US 2013/0152185 A1) and further in view of Kurani (PAT US 10,997,592 B1)
Regarding claims 3 and 10
Brown does not teach: The method of claim 1, further comprising obtaining, from a server of the first application, a historical card binding record associated with the first account, wherein the historical card binding record comprises identifiers of second bank cards associated with the first account.
However, Kurani teaches
obtaining, from a server of the first application, a historical card binding record associated with the first account, wherein the historical card binding record comprises identifiers of second bank cards associated with the first account. (See at least Kurani (Col 14 line 63-Col 15 line 1) “As will be appreciated, the arrangement of FIG. 3 facilitates keeping a list of source accounts that is up to date and accurate to the user. For example, each time a transaction is to be performed, the mobile wallet computer system 120 may access a list of accounts held by the user at the mobile wallet bank. “
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of the Mobile wallet account balance system as taught by Kurani in order for the mobile wallet to auto-provision the existing accounts of the user to the mobile wallet, without the user having to manually enter the 16-digit credit card account number or other account information (e.g., in the case of other types of financial accounts. (Kurani (Col 13 lines 38-42).
Regarding claims 4 and 11
Brown does not teach: The method of claim 1, further comprising obtaining, from a server of the first application, a historical card binding record associated with the first account, herein the historical card binding record comprises an identifier of a second bank card associated with the first account and not bound to the first terminal.
However, Kurani teaches
Obtaining, from a server of the first application, a historical card binding record associated with the first account, wherein the historical card binding record comprises an identifier of a second bank card associated with the first account and not bound to the first terminal. (Col 15 lines 30-34) (See at least Kurani When the mobile wallet computer system 120 accesses the list of accounts held by the user, the mobile wallet computer system 120 may identify the new credit card account as being an account that has not yet been provisioned to the mobile wallet.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of the Mobile wallet account balance system as taught by Kurani in order for the mobile wallet to auto-provision the existing accounts of the user to the mobile wallet, without the user having to manually enter the 16-digit credit card account number or other account information (e.g., in the case of other types of financial accounts. (Kurani (Col 13 lines 38-42).
Regarding claims 6 and 13
Brown does not teach: The method of claim 3, further comprising sending in response to the first operation, a first request to obtain the historical card binding record.
Kurani teaches
sending in response to the first operation, a first request to obtain the historical card binding record. (See at least Kurani (Col 14 line63-col 15 line 1) “the arrangement of FIG. 3 facilitates keeping a list of source accounts that is up to date and accurate to the user. For example, each time a transaction is to be performed, the mobile wallet computer system 120 may access a list of accounts held by the user at the mobile wallet bank.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of the Mobile wallet account balance system as taught by Kurani in order for the mobile wallet to auto-provision the existing accounts of the user to the mobile wallet, without the user having to manually enter the 16-digit credit card account number or other account information (e.g., in the case of other types of financial accounts. (Kurani (Col 13 lines 38-42).
Regarding claims 7 and 14
Brown teaches
sending, in response to the first operation, a second request to obtain the historical card binding record. (See at least Brown [0066] At step 302, the user is provided with the opportunity to select a card at the primary user device to activate (or “personalize”) a payment card. For example, the user may select one of the previously provisioned cards (e.g., cards that are already provisioned on the primary user device 10 or cards that have previously been associated with that user's account at the service provider subsystem) and optionally enter a card security code, answers to one or more challenging questions, the expiration date for the selected card, the billing address for the selected card, and/or provide other verification information.
Regarding claim 15
Brown teaches:
displaying, a first terminal and in response to a first operation, a second interface, wherein the first operation selects the first bank card as a to-be-bound bank card, and wherein the second interface prompts the user to enter verification information of the to-be-bound bank card; (See at least Brown [0009] and [0077]: [0009] The broker module may provide a list of payment cards to be displayed to a user at the primary user device. The user may select a payment card from the list and may be prompted to enter security information associated with the selected payment card at the primary user device. [0077] When a card is selected, additional input from the user may be required to provide an additional level of security without being overly burdensome to the user. For example, the user may select a payment card and then be required to enter a corresponding card verification value (CVV). As another example, the user may select a payment card and then be required to enter a corresponding expiration date. As yet another example, the user may select a payment card and then be required to enter a corresponding billing address. These examples are merely illustrative. If desired, other types of information may be requested from the user to verify that the intended user is in possession of the user devices.
receiving, a first terminal and after displaying the second user interface, data related to the to-be- bound bank card; (See at least Brown [0079] In yet other suitable embodiments, the user may be required to enter other types of one time passwords (OTPs) provided from the service provider subsystem via other secure channels (e.g., the payment network subsystem may require the user to perform an additional verification step prior to fully activating the card at the payment network subsystem). For example, the payment network subsystem may send a list of available contact/verification methods on file (e.g., contact methods including text message, e-mail, automated telephone call, etc.) to the broker module as part of the CheckCardResp, which can then be forwarded to the primary device. The user may select a desired verification/contact method on the primary device from the list, and the selected verification method may then be relayed back to the payment network subsystem via the broker module. The payment network subsystem will then send a verification code “out-of-band” via the selected contact method. Once the user has received the verification code that was sent out-of-band by the payment network subsystem, the user may enter the verification code on the primary user device. The code is then delivered to the broker module, when then forwards the code to the payment network subsystem. In response, the payment network subsystem indicates to the broker module that the card is now active (as far as the payment network is concerned).
binding, a first terminal and based on the data, the to-be-bound bank card to the first terminal. (See at least Brown [0068] At step 306, the payment network subsystem may direct the service provider TSM 116 to write the desired credential information (e.g., a device primary account number associated with the provisioned payment card) onto the corresponding payment applet 206 in secure element 104. At this point, the payment applet has been personalized with the credentials necessary to carry out a financial transaction. At step 308, TSM 116 may then notify broker module 114 that a particular payment applet 206 on the secondary device has now been personalized. At step 310, broker module 114 may push an updated pass to the secondary user device via the primary device 10. At this point, the pass can be selected by the user to perform a mobile payment because the corresponding applet 206 has now been activated for payment.)
Brown does not specifically teach: displaying, by the first terminal and in response to the first terminal binding the to-be- bound bank card to the first terminal, a third user interface comprising a graphical indication that the to-be-bound bank card is bound to the first terminal.
However, Singh teaches:
PNG
media_image2.png
546
486
media_image2.png
Greyscale
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of method for transaction provisions for mobile wireless devices as taught by Singh in order be capable of performing secure payment transactions.” (Singh [0018])
However Brown and Singh does not specifically teach: A method, comprising: sending, to a server when a user logs into a first application using a first account on a first terminal, a first request to obtain historical card binding information, wherein the first application is installed on the first terminal; receiving, from the server, the historical card binding information, ,wherein the historical card binding information comprises first bank card information of a first bank card, wherein, the first bank card is not bound to the first terminal, and wherein the first bank card is bound to a second terminal when the first application is logged into the first account on the second terminal; displaying, by a first terminal and before the first bank card associated with the first account of the first application is bound to the first terminal, a first interface comprising an identifier of the first
However, Kurani teaches:
A method, comprising: sending, by a first terminal and to a server when a user logs into a first application using a first account on the first terminal, a first request to obtain historical card binding information, wherein the first application is installed on the first terminal; (See at least Kurani (Col 14 line63-col 15 line 1) “the arrangement of FIG. 3 facilitates keeping a list of source accounts that is up to date and accurate to the user. For example, each time a transaction is to be performed, the mobile wallet computer system 120 may access a list of accounts held by the user at the mobile wallet bank.”
receiving, from the server, the historical card binding information, ,wherein the historical card binding information comprises first bank card information of a first bank card, wherein, the first bank card is not bound to the first terminal, and wherein the first bank card is bound to a second terminal when the first application is logged into the first account on the second terminal; (See at least Kurani (Col 15 lines 30-34) When the mobile wallet computer system 120 accesses the list of accounts held by the user, the mobile wallet computer system 120 may identify the new credit card account as being an account that has not yet been provisioned to the mobile wallet.”)
displaying, by a first terminal and before the first bank card associated with the first account of the first application is bound to the first terminal, a first interface comprising an identifier of the first(See at least Kurani (Col 15 lines 30-43) When the mobile wallet computer system 120 accesses the list of accounts held by the user, the mobile wallet computer system 120 may identify the new credit card account as being an account that has not yet been provisioned to the mobile wallet. When the screen display is generated showing the list of accounts held by the user, the list may then include the new credit card account, which may be selected by the user for provisioning to the mobile wallet. Again, the new credit card account may be provisioned to the mobile wallet without any manual entry by the user of account information regarding the new credit card account (other than the selection of the new credit card account by the user, indicating that the user wishes to add the new credit card account to the mobile wallet).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of the Mobile wallet account balance system as taught by Kurani in order for the mobile wallet to auto-provision the existing accounts of the user to the mobile wallet, without the user having to manually enter the 16-digit credit card account number or other account information (e.g., in the case of other types of financial accounts. (Kurani (Col 13 lines 38-42).
Regarding claim 16
Brown does not specifically teach “The method of claim 15, further comprising displaying a bounding progress of the to-be-bound bank card.”
However Singh Teaches:
The method of claim 15, further comprising displaying a bounding progress of the to-be-bound bank card. lication, which provides a graphical user interface (GUI) on the display 60. In the mobile wallet, a first "soft" debit card is already provisioned, namely a debit credit card from ABC Bank. When the security token 32 and mobile device 34 commence NFC communications, the mobile wallet application determines that the security token 32 is a credit card that is not already provisioned with the mobile wallet, and provides a GUI prompt inquiring whether this new credit card is to be added to the mobile wallet. For example, the mobile wallet may determine, based upon an PAN number of the security token 32, bank identification information, or other information stored on the security token 32 the type of credit card with which it is communicating. From this information, the mobile wallet may determine not only that the credit card is not already provisioned with the mobile wallet, but it may also determine a location (e.g., website, etc.) from which to download a mobile wallet interface application for the given credit card, as shown in FIG. 5.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of method for transaction provisions for mobile wireless devices as taught by Singh in order be capable of performing secure payment transactions.” (Singh [0018])
Regarding claim 17
Brown does not specifically teach: The method of claim 15, further comprising obtaining, from the server, a historical card binding record associated with the first account, wherein the card binding record comprises identifiers of second bank cards associated with the first account.
However, Kurani teaches
obtaining, from the server, a historical card binding record associated with the first account, wherein the card binding record comprises identifiers of second bank cards associated with the first account. (See at least Kurtani (Col 14 line 63-Col 15 line 1) As will be appreciated, the arrangement of FIG. 3 facilitates keeping a list of source accounts that is up to date and accurate to the user. For example, each time a transaction is to be performed, the mobile wallet computer system 120 may access a list of accounts held by the user at the mobile wallet bank.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of the Mobile wallet account balance system as taught by Kurani in order for the mobile wallet to auto-provision the existing accounts of the user to the mobile wallet, without the user having to manually enter the 16-digit credit card account number or other account information (e.g., in the case of other types of financial accounts. (Kurani (Col 13 lines 38-42).
Regarding claim 18
Brown does not specifically teach: The method of claim 15, further comprising obtaining, from the server, a historical card binding record associated with the first account, wherein the historical card binding record comprises an identifier of a second bank card associated with the first account and not bound to the first terminal
However, Kurani teaches
obtaining, from the server, a historical card binding record associated with the first account, wherein the historical card binding record comprises an identifier of a second bank card associated with the first account and not bound to the first terminal (See at least Kurtani (Col 15 lines 30-34) When the mobile wallet computer system 120 accesses the list of accounts held by the user, the mobile wallet computer system 120 may identify the new credit card account as being an account that has not yet been provisioned to the mobile wallet.”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for using a primary user device to provision credentials onto a secondary device of Brown in view of the Mobile wallet account balance system as taught by Kurani in order for the mobile wallet to auto-provision the existing accounts of the user to the mobile wallet, without the user having to manually enter the 16-digit credit card account number or other account information (e.g., in the case of other types of financial accounts. (Kurani (Col 13 lines 38-42).
Regarding claim 19
Brown teaches:
The method of(See at least Brown [0060] In one suitable arrangement, applications processor 200 on secondary user device 102 may be configured to run a mobile payments application. This payments application may allow the user to store credit cards, debit cards, retail coupons, boarding passes, event tickets, store cards, gift cards, loyalty cards, generic cards, and/or other forms of mobile payment. Each of these digital cards, coupons, or tickets is sometimes referred to as a “pass.” As a result, the mobile payments application is sometimes referred to as a “passbook” application or a digital wallet application. Passes may be loaded onto the secondary user device 102 using the broker module 114 (FIG. 1).
Regarding claim 20
Brown teaches:
The method of claim 15, wherein displaying the first interface comprises displaying the first interface on a display screen of the first terminal. (See at least Brown [0009] The broker module may provide a list of payment cards to be displayed to a user at the primary user device. The user may select a payment card from the list and may be prompted to enter security information associated with the selected payment card at the primary user device.
Prior Art of Record Not Currently Relied Upon
Lahkar (US 2017/0032362 A1) Teaches: streaming enrollment of credit cards in mobile wallets.
Kushevsky (US 2013/0221092 A1) Teaches: Method or loading a transaction card and processing repayments on a mobile device.
Wong et al. (US 2015/0046339 A1) Teaches: Method for provisioning mobile devices with payment credentials.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
March 24, 2026