Acknowledgements
This communication is in response to applicant’s response filed on 03/05/2026.
Claims 4, 11-18, and 20 have been cancelled.
Claims 1-3, 5-10, 19, and 21 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Regarding applicant’s arguments:
Applicant’s arguments, see pgs. 8-9, filed 03/05/2026, with respect to the rejection(s) of claims 1, 19, and 21 under Claim Rejections - 35 USC § 103 that Wu (CN110689332A) does not teach “generating, based on the first confirmation operation information, interface guidance information for directing rebinding of the card, wherein the interface guidance information comprises card information of the target bank card that needs to be rebound, quick payment agreement information which are stored in a blockchain system, and authorization request information; and receiving second confirmation operation information for the authorization request information, wherein the second confirmation operation information is used to authorize a server to rebind the target bank card” are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made under Claim Rejections - 35 USC § 103 in view of Cohen (US 11,410,165).
Priority
Applicant’s claim for the benefit of PCT Application PCT/CN2022/090132 filed on 04/09/2022 is acknowledged. Applicant’s claim for the benefit of People's Republic of China Application CN202110512497.5 filed on 05/11/2021 is acknowledged.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 9, 19, and 21 are rejected under 35 U.S.C. 103 as being anticipated by Gangapurkar (US 20170300913) in view of Cohen (US 11,410,165) in further view of Wu (CN110689332A).
Regarding Claims 1, 19, and 21, Gangapurkar teaches obtaining a payment operation for a target order by using a target bank card (Paragraph 0030 teaches the payment provider receives a payment request when the user selects a payment button or link from a merchant site); obtaining status information of a quick payment agreement of the target bank card (Paragraphs 0030, 0033, and 0035 teach upon receipt of the request, the payment provider determines whether the user has a quick pay account set up this can be determined using information about the user conveyed with the payment request, such as a device ID, user name, etc.; if the user has a quick pay account, the payment provider sends quick pay payment screen to the user device; the payment screen is a smaller pop-up window on the merchant page or the payment screen may be opened up in a new window or tab; the payment window may request the user enter the user identifier for the quick pay feature if the user wishes to pay using quick pay; once the payment provider receives the user response, a determination is made whether the payment is to be authorized; the payment provider may first check whether the user is correctly associated with the quick pay user identifier; if so, the payment provider may also check whether the requested payment amount is within the limits set for the quick pay account and/or whether the quick pay account has expired); generating first prompt information when the status information indicates that the quick payment agreement of the target bank card is in an invalid state, wherein the first prompt information is used to prompt the user to rebinding of the target bank card (Paragraph 0036 teaches if the payment cannot be authorized, the payment provider may send the user a message in an attempt to resolve the request; the message content may depend on the reason or reasons for not authorizing the request); receiving confirmation operation information based on the first prompt information, wherein the first confirmation operation information is used to confirm the rebinding of the target bank card (Paragraph 0037 teaches the payment provider then processes the payment or denies the request depending on the response received from the user); rebinding the target bank card based on the first confirmation operation information and using a card rebinding component that increases a payment success rate of the target bank card by rebinding the target bank card without interrupting the payment operation for the target order (Paragraphs 0036 and 0039 teach for example, if the reason for not authorization is because the quick pay has expired, the user may be asked to make the payment through a normal payment flow or set a new expiration date; the new expiration date may be effective immediately (i.e., for the current transaction); as a result, the user may quickly make a payment with minimal interruption from the merchant site; in one example, the user only needs to enter a user identifier, which if confirmed with the transaction/merchant/user data, to process and complete the payment; the payment screen then disappears and the user proceeds on the merchant site, along with any downloads or access from the payment); and completing a payment of the target order based on the rebound target bank card (Paragraph 0038 teaches if the payment can be authorized the payment provider processes the payment; the payment provider transfers the payment amount from the user's account into an account of the merchant or recipient (minus any fees that may be incurred); if the merchant has an account with the payment provider or the payment provider has merchant account information from a third party, such as bank, the payment provider may obtain the account information through merchant information communicated in the transaction request from the user).
However, Gangapurkar does not explicitly teach wherein the rebinding the target bank card based on the first confirmation operation information specifically comprises: generating, based on the first confirmation operation information, interface guidance information for directing rebinding of the card, wherein the interface guidance information comprises card information of the target bank card that needs to be rebound, quick payment agreement information, and authorization request information; receiving second confirmation operation information for the authorization request information, wherein the second confirmation operation information is used to authorize a server to rebind the target bank card; performing identity verification on a user based on the second confirmation operation information; and completing a rebinding operation of the target bank card when the identity verification on the user succeeds.
Cohen from same or similar field of endeavor teaches wherein the rebinding the target bank card based on the first confirmation operation information specifically comprises: generating, based on the first confirmation operation information, interface guidance information for directing rebinding of the card, wherein the interface guidance information comprises card information of the target bank card that needs to be rebound, quick payment agreement information, and authorization request information (Col. 19, lines 14-47, teaches a second deactivation event for the same financial account or card is detected; the deactivation event may be a failed transaction or suspected fraudulent activity; the first and second deactivation events may be caused by the same type of event; the current credential is deactivated for the card or financial account that had a second deactivation event occur; security questions are generated; a plurality of security questions may be generated; in some embodiments, the security questions are a yes or no question, based on location information, or based on other information obtained from a user device; the security questions may be based on information for which only a user should know the answer); receiving second confirmation operation information for the authorization request information, wherein the second confirmation operation information is used to authorize a server to rebind the target bank card (Col. 19, lines 47-51 teaches the user answers the security questions generated; the user may receive an alert to answer the security questions; the user can answer the security questions from the user device); performing identity verification on a user based on the second confirmation operation information (Col. 19, lines 52-57 teaches the security questions are determined to be answered correctly or incorrectly; in some embodiments, the user must answer all questions correctly; in another embodiment, the user needs to answer a certain percent of questions correctly; if it is determined that enough questions are answered correctly, the next operation may occur); and completing a rebinding operation of the target bank card when the identity verification on the user succeeds (Col. 19, lines 60-61 teaches the current credential is reactivated for the account or card associated with the deactivation event).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Gangapurkar to incorporate the teachings of Cohen for the rebinding the target bank card based on the first confirmation operation information specifically to comprise: generating, based on the first confirmation operation information, interface guidance information for directing rebinding of the card, wherein the interface guidance information comprises card information of the target bank card that needs to be rebound, quick payment agreement information, and authorization request information; receiving second confirmation operation information for the authorization request information, wherein the second confirmation operation information is used to authorize a server to rebind the target bank card; performing identity verification on a user based on the second confirmation operation information; and completing a rebinding operation of the target bank card when the identity verification on the user succeeds.
There is motivation to combine Cohen into Gangapurkar because the original credential may be reactivated if enough questions are answered correctly. In an alternative embodiment, a new credential is activated if enough questions are answered correctly. In some embodiments, the user must answer all questions correctly to reactivate the credentials. In another embodiment, the user needs to answer a certain percent of questions correctly to reactivate the credentials. In some embodiments, there is a limited time span that the user must answer the questions (e.g., if the questions are generated while the user is at a POS, the user must answer the questions within a certain number of minutes or the credentials will remain deactivated). In some embodiments, if not enough questions are answered correctly, the credentials will remain deactivated. The user may have to contact the financial institution to reactivate the credentials (Cohen Col. 16, lines 8-20).
However, the combination of Gangapurkar and Cohen does not explicitly teach quick payment agreement information which are stored in a blockchain system.
Wu from same or similar field of endeavor teaches quick payment agreement information which are stored in a blockchain system (Paragraphs 0157-0159 teach a blockchain may include a blockchain underlying platform, a platform product services layer, and an application services layer; the resource account binding method in this exemplary embodiment may be applied to the above block chain; for example, the target application platform may be a blockchain node of a platform product service layer; the bank platform can encrypt the resource account information through a consensus algorithm and store the encrypted resource account information to the blockchain network, so that the target application platform can acquire the resource account information from the blockchain network to bind the resource account; in detail: the block chain underlying platform can comprise processing modules such as user management, basic service, intelligent contract and operation monitoring; the user management module is responsible for identity information management of all blockchain participants, and comprises public and private key generation maintenance (account management), key management, user real identity and blockchain address corresponding relation maintenance (authority management) and the like, and under the authorization condition, the user management module supervises and audits the transaction condition of certain real identities and provides rule configuration (wind control audit) of risk control; the basic service module is deployed on all block chain node equipment and used for verifying the validity of the service request, recording the service request to storage after the effective request is identified in a consensus mode, for a new service request, the basic service firstly conducts interface adaptation analysis and authentication processing (interface adaptation), then encrypts resource account information through a consensus algorithm (consensus management), transmits the encrypted resource account information to a shared account book (network communication) in a complete and consistent mode, and records and stores the encrypted resource account information; the intelligent contract module is responsible for registering and issuing contracts, triggering the contracts and executing the contracts, developers can define contract logics through a certain programming language, issue the contract logics to a block chain (contract registration), call keys or other event triggering and executing according to the logics of contract clauses, complete the contract logics and simultaneously provide the function of upgrading and canceling the contracts; the operation monitoring module is mainly responsible for deployment, configuration modification, contract setting, cloud adaptation in the product release process and visual output of real-time states in product operation, such as: alarm, monitoring network conditions, monitoring node equipment health status, and the like; the platform product service layer provides basic capability and an implementation framework of typical application, and developers can complete block chain implementation of business logic based on the basic capability and the characteristics of the superposed business; the application service layer provides the application service based on the block chain scheme for the business participants to use).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar and Cohen to incorporate the teachings of Wu for the rebinding the target bank card based on the first confirmation operation information specifically to comprise: generating, based on the first confirmation operation information, interface guidance information for directing rebinding of the card, wherein the interface guidance information comprises card information of the target bank card that needs to be rebound, quick payment agreement information, and authorization request information; receiving second confirmation operation information for the authorization request information, wherein the second confirmation operation information is used to authorize a server to rebind the target bank card; performing identity verification on a user based on the second confirmation operation information; and completing a rebinding operation of the target bank card when the identity verification on the user succeeds.
There is motivation to combine Wu into the combination of Gangapurkar and Cohen because the bank platform can encrypt the resource account information through a consensus algorithm and store the encrypted resource account information to the blockchain network, so that the target application platform can acquire the resource account information from the blockchain network to bind the resource account (Wu Paragraph 0157).
Regarding Claim 1, Gangapurkar teaches a payment method (Paragraph 0030 teaches FIG. 2 is a flowchart 200 showing steps performed by a payment provider to process an on-line payment).
Regarding Claim 19, Gangapurkar teaches a payment device, comprising: a memory and a processor, wherein the memory stores executable instructions that, in response to execution by the processor, cause the processor to perform operations (Paragraphs 0050 and 0064 teach client device may include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein; a computer system performs specific operations by processor executing one or more sequences of instructions contained in system memory component, such as described above with respect to the consumer, merchant, and/or payment provider in FIGS. 1-3).
Regarding Claim 21, Gangapurkar teaches a non-transitory computer-readable storage medium, comprising instructions stored therein that, when executed by a processor of a computing device, cause the processor to perform operations (Claim 16 and Paragraph 0065 teaches a non-transitory computer-readable medium storing computer-executable instructions, that in response to execution by one or more hardware processors, causes a payment provider server of a payment provider to perform operations; logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor for execution).
Regarding Claim 3, the combination of Gangapurkar, Cohen, and Wu teaches all the limitations of claim 1; and Gangapurkar further teaches wherein the first prompt information comprises at least payment failure feedback information, option information of another payment method, and option information for rebinding the card (Paragraphs 0035-0036 and 0024 teach the payment provider may first check whether the user is correctly associated with the quick pay user identifier; if so, the payment provider may also check whether the requested payment amount is within the limits set for the quick pay account and/or whether the quick pay account has expired; the payment provider may send the user a message in an attempt to resolve the request; the message content may depend on the reason or reasons for not authorizing the request; for example, if the reason for not authorization is because the quick pay has expired, the user may be asked to make the payment through a normal payment flow or set a new expiration date; the new expiration date may be effective immediately (i.e., for the current transaction); if, for some reason, the payment request through quick pay cannot be authorized the payment provider informs the user; for example, if the user identifier did not match, the user may be requested to enter the identifier again; if the requested payment amount exceeds the quick pay limit, the user may be notified and asked to pay through the user's regular account or through a different funding instrument).
Regarding Claim 9, the combination of Gangapurkar, Cohen, and Wu teaches all the limitations of claim 1; and Gangapurkar further teaches wherein the completing a payment of the target order based on the rebound target bank card specifically comprises: determining status information of a quick payment agreement corresponding to the rebound target bank card, wherein the status information is used to indicate an effective status of the quick payment agreement of the rebound target bank card (Paragraph 0023 teaches assuming the user name is correct and the user wants to use the quick pay option, the user enters the identifier for quick pay and submits the information to the payment provider; the payment provider processes the information to determine whether to approve the payment; the processing may include matching the received user identifier with the user name, determining the merchant or recipient of the payment, and determining whether the payment amount is within the limits of the user quick pay settings associated with the particular merchant; the payment provider may also compare information about the device the request was transmitted from (such as a phone number from a mobile device) to information corresponding to an authorized account); and completing the payment of the target order based on the rebound target bank card when the status information indicates that the quick payment agreement of the rebound target bank card is valid (Paragraph 0026-0027 teach if the determination results in an authorized payment using quick pay, the user is returned fully to the merchant page; the payment window simply disappears and the user proceeds with any interactions on the merchant page or the payment window is replaced with a confirmation message to that the payment has been approved, where the confirmation message may automatically disappear after a certain period or the user may close the message manually; the payment is processed).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Gangapurkar (US 20170300913) in view of Cohen (US 11,410,165) in further view of Wu (CN110689332A) in further view of Muthukrishnan (US 20170169406).
Regarding Claim 2, the combination of Gangapurkar, Cohen, and Wu teaches all the limitations of claim 1 above; and Gangapurkar further teaches the obtaining status information of a quick payment agreement of the target bank card specifically comprises: obtaining the status information of the quick payment agreement of the target bank card when the error type indicates a payment failure caused by the quick payment agreement of the target bank card (Paragraph 0036 teaches if the reason for not authorization is because the quick pay has expired, the user may be asked to make the payment through a normal payment flow or set a new expiration date).
However, the combination does not explicitly teach before the obtaining status information of a quick payment agreement of the target bank card, further comprising: obtaining payment failure information corresponding to the target order, wherein the payment failure information comprises at least an error code and application scenario information; and determining an error type corresponding to the payment failure information based on the error code and the application scenario information.
Muthukrishnan from same or similar field of endeavor teaches before the obtaining status information of a quick payment agreement of the target bank card, further comprising: obtaining payment failure information corresponding to the target order, wherein the payment failure information comprises at least an error code and application scenario information (Paragraphs 0039 and 0046 teach the user selects on the payment service provider site a desired first payment instrument; in another embodiment, a particular payment instrument may be automatically provided by the payment service provider as a default payment means; when payment is declined by the issuer of the payment instrument, the payment service provider sends an error code to the merchant; the error code notifies the merchant that the failed transaction is recoverable if the user chooses a new funding source or payment instrument; the error code may be a preset code between the merchant and payment service provider, and may include letters, numbers, characters or a combination thereof; the error code operates as a request for the merchant to redirect the user, who is still logged on to the merchant's site, back to the payment service provider site); and determining an error type corresponding to the payment failure information based on the error code and the application scenario information (Paragraph 0050 teaches the payment service provider may further display on the redirected page various detailed error messages on why the first payment instrument was declined; the error message may have various degrees of specificity as to the cause of failure, depending on different embodiments; for example, the error message may state that “Your transaction was declined because we are unable to verify this credit card through our card validation process,” or the error message may state more specifically, “Your transaction was declined because we were unable to verify the billing address.”).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu to incorporate the teachings of Muthukrishnan to before the obtaining status information of a quick payment agreement of the target bank card, further comprising: obtain payment failure information corresponding to the target order, wherein the payment failure information comprises at least an error code and application scenario information; and determine an error type corresponding to the payment failure information based on the error code and the application scenario information.
There is motivation to combine Muthukrishnan into the combination of Gangapurkar, Cohen, and Wu because the present disclosure describes systems and methods that allow a user to select another payment instrument without requiring the user to login and re-enter previously provided information. The systems and methods remember the transaction state of the user so the user is kept in the same session and the same checkout flow. This allows the user to purchase items quickly and provides the user with a smooth, hassle-free experience (Muthukrishnan Paragraph 0057).
Claims 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Gangapurkar (US 20170300913) in view of Cohen (US 11,410,165) in further view of Wu (CN110689332A) in further view of Liu (US 20180150816) in further view of Brown (US 20190349361).
Regarding Claim 5, the combination of Gangapurkar, Cohen, and Wu teaches all the limitations of claim 1 above; however, the combination does not explicitly teach before the performing identity verification on the user based on the second confirmation operation information, further comprising: receiving a mobile phone number; obtaining a pre-stored reserved mobile phone number corresponding to the target bank card from a blockchain system, wherein the blockchain system stores a mapping relationship between bank card information and a reserved mobile phone number; comparing the mobile phone number with the reserved mobile phone number; and performing identity verification on the user when the mobile phone number is consistent with the reserved mobile phone number.
Liu from same or similar field of endeavor teaches before the performing identity verification on the user based on the second confirmation operation information, further comprising: receiving a mobile phone number (Paragraph 0030 teaches the consumer may provide the device identifier by inputting the device identifier into virtual terminal system; the consumer may also provide the device identifier by providing a biometric identifier associated with the consumer which has been associated with the device identifier and/or device; virtual terminal system may receive the device identifier; if the consumer has not registered his or her device with service system, the device identifier may be a mobile phone number, and upon receipt of the mobile phone number, service system may prompt device to download personal POS terminal; a mobile phone number may be used as a device identifier regardless of whether the device is pre-registered); obtaining a pre-stored reserved mobile phone number corresponding to the target bank card (Paragraphs 0022 and 0031 teach service system may comprise an information database; information database may store one or more device identifiers, wherein each device identifier is associated with at least one device, and each device is associated with a consumer or consumer profile; the consumer may pre-register his or her device with service system and/or information database; service system may match the received device identifier with a stored device identifier in information database); comparing the mobile phone number with the reserved mobile phone number (Paragraph 0031 teaches virtual terminal may receive the device identifier and transmit the device identifier to service system; service system may match the received device identifier with a stored device identifier in information database); and performing identity verification on the user when the mobile phone number is consistent with the reserved mobile phone number (Paragraphs 0031-0034 teach in response to matching the received device identifier with a stored device identifier, service system may activate personal POS terminal on the device associated with the device identifier; in response to personal POS terminal being activated, service system may instruct the device to display the transaction details; the consumer may be presented with an option to accept or reject the transaction by personal POS terminal; in response to the consumer accepting the transaction, service system and/or personal POS terminal may request payment from the consumer for the transaction; the consumer may either place a physical payment instrument (e.g., a credit or debit card) in proximity to or in contact with the PIAD of device as described herein, from which personal POS terminal will receive a payment token, or unlock electronic wallet to pay with a virtual payment instrument stored in electronic wallet; in response to consumer electing to pay using a virtual payment instrument in electronic wallet, in various embodiments, electronic wallet may require an account holder verification from the consumer, such as a passcode, password, a biometric identifier, or any other verification of the consumer associated with the virtual payment instrument, to unlock electronic wallet.
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu to incorporate the teachings of Liu to before the performing identity verification on the user based on the second confirmation operation information, further comprising: receiving a mobile phone number; obtaining a pre-stored reserved mobile phone number corresponding to the target bank card from a blockchain system, wherein the blockchain system stores a mapping relationship between bank card information and a reserved mobile phone number; comparing the mobile phone number with the reserved mobile phone number; and performing identity verification on the user when the mobile phone number is consistent with the reserved mobile phone number.
There is motivation to combine Liu into the combination of Gangapurkar, Cohen, and Wu because an issuing bank may issue a physical payment instrument or electronic wallet with secret payment credentials that are used to compute a cryptogram over the transaction details (e.g. transaction amount, date, the merchant information, etc.). Therefore, the in- person transaction, in which the physical payment instrument or electronic wallet is presented to a POS terminal at a physical merchant location, is with nonrepudiation assurance and may have a low fraud risk (Liu Paragraph 0003).
However, the combination of Gangapurkar, Cohen, and Wu, and Liu does not explicitly teach obtaining a pre-stored reserved mobile phone number corresponding to the target bank card from a blockchain system, wherein the blockchain system stores a mapping relationship between bank card information and a reserved mobile phone number.
Brown from same or similar field of endeavor teaches obtaining a pre-stored reserved mobile phone number corresponding to the target bank card from a blockchain system, wherein the blockchain system stores a mapping relationship between bank card information and a reserved mobile phone number (Paragraphs 0093, 0110, and 0112-0113 teach some or all of the stored information managed by the near-field item may be read by, or otherwise be transferred to, the near-field terminal device; the stored information may include at least an item identifier; the stored information may include data utilized to complete one or more transactions, or for use in verifying a user identity; for example, in some embodiments, the stored information may include payment information, identification information, a phone number; the user identification confirmation system may store an identification confirmation record in a repository, such as report repository; the report repository is a blockchain storage, which may be maintained by or otherwise accessible to the user identification confirmation system; the service provider device transmits an identification verification query to the user identification confirmation system; the user identification confirmation system transmits the identification confirmation indicator to the service provider device in response to the identification verification query).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu, and Liu to incorporate the teachings of Brown to obtain a pre-stored reserved mobile phone number corresponding to the target bank card from a blockchain system, wherein the blockchain system stores a mapping relationship between bank card information and a reserved mobile phone number.
There is motivation to combine Brown into the combination of Gangapurkar, Cohen, and Wu, and Liu because blockchain employs cryptographic techniques to secure data, making it extremely difficult for unauthorized parties to manipulate or access sensitive information. Thus, the pre-stored mobile phone number can be trusted.
Regarding Claim 7, the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown teaches all the limitations of claim 5 above; however the combination does not explicitly teach wherein the performing identity verification on the user specifically comprises: sending an SMS message to the mobile phone number, wherein the SMS message comprises a check code; receiving a check code; comparing whether the check code is consistent with the check code comprised in the SMS message; and determining, when the check code is consistent with the check code comprised in the SMS message, that the identity verification on the user succeeds.
Wu further teaches wherein the performing identity verification on the user specifically comprises: sending an SMS message to the mobile phone number, wherein the SMS message comprises a check code (Paragraph 0146-0147 teach after receiving the request information of the binding service page, the binding service background starts a communication number verification process for the current user; the binding service background requests the third-party payment platform server to send verification information, such as a verification code, to the communication number retained by the current user; the third-party payment platform server sends a verification code to the user's terminal device through the communication number reserved by the user; and notifies the binding service background after the sending is completed; the binding service background controls the binding service page to provide a verification code input interface; the binding service page displays a verification code input interface to the user); receiving a check code entered by the user (Paragraph 0147 teaches the binding service page receives the verification code input by the user through the verification code input interface and sends the verification code to the binding service background); comparing whether the check code is consistent with the check code comprised in the SMS message (Paragraphs 0082 and 0147 teach further, after the user enters the verification code that the user has received, the third-party payment platform can compare it with the verification code sent; the binding service background sends the verification code input by the user to the third-party payment platform server for verification; if the third-party payment platform server passes the verification code input by the user, the association relationship between the bank account and the third-party payment platform may be established and recorded, that is, the account binding is completed); and determining, when the check code is consistent with the check code comprised in the SMS message, that the identity verification on the user succeeds (Paragraphs 0082 and 147 teach after the verification code is verified, the bank account entered by the user is bound to a third-party payment platform; the binding service background sends a notification of account binding completion to the bank; the binding service background sends an account binding completion notification to the binding service page; the binding service page notifies the user that the account binding is completed).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown to incorporate the further teachings of Wu for the performing identity verification on the user to specifically comprises: sending an SMS message to the mobile phone number, wherein the SMS message comprises a check code; receiving a check code; comparing whether the check code is consistent with the check code comprised in the SMS message; and determining, when the check code is consistent with the check code comprised in the SMS message, that the identity verification on the user succeeds.
There is motivation to further combine Wu into the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown because of the same reasons listed above for claim 1.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Gangapurkar (US 20170300913) in view of Cohen (US 11,410,165) in further view of Wu (US CN110689332A) in further view of Liu (US 20180150816) in further view of Brown (US 20190349361) in further view of Xu (US 20190098491).
Regarding Claim 6, the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown teaches all the limitations of claim 5 above; however the combination does not explicitly teach uploading a new mapping relationship to the blockchain system for storage.
Brown further teaches uploading a new mapping relationship to the blockchain system for storage (Paragraph 0126 teaches the apparatus includes means such as repository management module to store the identification confirmation record to a record repository; the record repository may be a sub-repository, or otherwise associated with, a database or repository managed by the apparatus; the record repository is embodied by a blockchain storage configured to store one or more identification confirmation record(s); the blockchain storage may be managed directly by the apparatus, or associated with a remote device, server, or the like; for example, in some embodiments, the apparatus may store the identification confirmation record by communicating with the record repository, or a device associated with managing the record repository, via one or more APIs).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown to incorporate the further teachings of Brown to obtain a pre-stored reserved mobile phone number corresponding to the target bank card from a blockchain system, wherein the blockchain system stores a mapping relationship between bank card information and a reserved mobile phone number.
There is motivation to further combine Brown into the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown because of the same reasons listed above for claim 5.
However, the combination does not explicitly teach after the comparing the mobile phone number with the reserved mobile phone number, further comprising: generating second prompt information when the mobile phone number is inconsistent with the reserved mobile phone number, wherein the second prompt information is used to request re-entry of the mobile phone number; and receiving the mobile phone number re-entered by the user, and establishing a new mapping relationship between the re-entered mobile phone number and the target bank card.
Xu from same or similar field of endeavor teaches after the comparing the mobile phone number with the reserved mobile phone number, further comprising: generating second prompt information when the mobile phone number is inconsistent with the reserved mobile phone number, wherein the second prompt information is used to request re-entry of the mobile phone number (Paragraphs 0069-0072 teach performing a pre-examination on the information of the user according to the identification information of the user; if the pre-examination fails, display a prompt message to the user; the prompt message can be used to prompt the user to directly bundle the changed mobile phone number; the information of the user can comprise a mobile phone number bundled to the user's software system account; the failure of the pre-examination can be because that the mobile phone number bundled to the user's software system account is not detected); and receiving the mobile phone number re-entered by the user, and establishing a new mapping relationship between the re-entered mobile phone number and the target bank card (Paragraphs 0073, 0080, and 0082 teach switching to a webpage for inputting the changed mobile phone number, and receiving the changed mobile phone number input by the user; obtaining at least one piece of corresponding historical transaction record information from a storage unit according to the identification information of the user; executing a service operation to change the mobile phone number).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown to incorporate the teachings of Xu to after the comparing the mobile phone number with the reserved mobile phone number, further comprising: generating second prompt information when the mobile phone number is inconsistent with the reserved mobile phone number, wherein the second prompt information is used to request re-entry of the mobile phone number; and receiving the mobile phone number re-entered by the user, and establishing a new mapping relationship between the re-entered mobile phone number and the target bank card.
There is motivation to combine Xu into the combination of Gangapurkar, Cohen, and Wu, Liu, and Brown because no interaction with the user is needed according to the present disclosure when recognizing a service request to change a mobile phone number. Instead, historical transaction record information is obtained from a storage unit, and when current environment information carried in the service request matches historical environment information carried in the historical transaction record information, the service request is identified as a trusted service. As such, the process for changing a mobile phone number can be simplified, and the user experience can be improved (Xu Paragraph 0083).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Gangapurkar (US 20170300913) in view of Cohen (US 11,410,165) in further view of Wu (CN110689332A) in further view of Liu (US 20180150816) in further view of Brown (US 20190349361).
Regarding Claim 8, the combination of Gangapurkar, Cohen, and Wu teaches all the limitations of claim 1 above; however, Gangapurkar does not explicitly teach wherein the rebinding the target bank card based on the first confirmation operation information specifically comprises: obtaining user identification information of the user; obtaining bank card information of the target bank card and quick payment agreement information corresponding to the target bank card; and generating binding information among the user identification information, the bank card information of the target bank card, and the quick payment agreement.
Liu from same or similar field of endeavor teaches wherein the rebinding the target bank card based on the first confirmation operation information specifically comprises: obtaining user identification information of the user (Paragraphs 0314-0319 and 0062 teach under a condition that a program data package stored in the security element needs to be updated (i.e., rebound), the receiving module described above may further be configured to receive an update request message sent by the user terminal; the sending module described above may further be configured to: in response to the update request message, issue an updated program data package to the user terminal; the receiving module may further be configured to: receive a verification code acquisition request message sent by the user terminal; the sending module may further be configured to: in response to the verification code acquisition request message, feedback a first dynamic verification code to the user terminal; the receiving module may further be configured to receive a verification code request message sent by the user terminal; the verification code request message includes a second dynamic verification code; a password, a mobile phone number of a person to whom the card belongs, a card validity period, a credit card authentication password, etc.); obtaining bank card information of the target bank card and quick payment agreement information corresponding to the target bank card (Paragraphs 0048 and 0062 teach the program data package may specifically be in the form of a Cap package; such a program data package may be shared by internal operations on relevant information of a card, the first type of a universal card instance and the second type of a universal card instance, etc.; the binding card authentication information includes card authentication information of a binding card; a card that the card binding message requests to bind is a binding card; the card authentication information may be configured to identify the card; for example, in the case where a card is a bank card, the card authentication information may specifically include a card number of the bank card); generating binding information among the user identification information, the bank card information of the target bank card, and the quick payment agreement (Paragraph 0320 teaches the processing module may further be configured to activate the first mapping relationship under a condition that the second dynamic verification code is verified successfully).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu to incorporate the teachings of Liu for the rebinding the target bank card based on the first confirmation operation information to specifically comprises: obtaining user identification information of the user; obtaining bank card information of the target bank card and quick payment agreement information corresponding to the target bank card; and generating binding information among the user identification information, the bank card information of the target bank card, and the quick payment agreement.
There is motivation to combine Liu into the combination of Gangapurkar, Cohen, and Wu because in the case of deleting a card, the user terminal does not delete the first type of universal card instance and the second type of universal card instance, and does not delete a program data package either, thereby avoiding frequent deletion of personalization data and a program data package. Especially in the case of re-binding a previously deleted card, re-downloading of personalization data and program data package in the re-binding process can be avoided, thereby further reducing the complexity of the card binding process and the card deletion process (Liu Paragraph 0127).
However, the combination of Gangapurkar, Cohen, and Wu, and Liu does not explicitly teach uploading the binding information to the blockchain system for storage.
Brown from same or similar field of endeavor teaches uploading the binding information to the blockchain system for storage (Paragraph 0126 teaches the apparatus includes means such as repository management module to store the identification confirmation record to a record repository; the record repository may be a sub-repository, or otherwise associated with, a database or repository managed by the apparatus; the record repository is embodied by a blockchain storage configured to store one or more identification confirmation record(s); the blockchain storage may be managed directly by the apparatus, or associated with a remote device, server, or the like; for example, in some embodiments, the apparatus may store the identification confirmation record by communicating with the record repository, or a device associated with managing the record repository, via one or more APIs).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu, and Liu to incorporate the teachings of Brown to upload the binding information to a blockchain system for storage.
There is motivation to combine Brown into the combination of Gangapurkar, Cohen, and Wu, and Liu because of the same reasons listed above for claim 5.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Gangapurkar (US 20170300913) in view of Cohen (US 11,410,165) in further view of Wu (CN110689332A) in further view of Brown (US 20190349361).
Regarding Claim 10, the combination of Gangapurkar, Cohen, and Wu teaches all the limitations of claim 9 above; however, Gangapurkar does not explicitly teach after the determining status information of a quick payment agreement corresponding to the rebound target bank card, further comprising: uploading the status information of the quick payment agreement corresponding to the rebound target bank card to the blockchain system for storage when the status information indicates that the quick payment agreement of the rebound target bank card is valid.
Brown from same or similar field of endeavor teaches after the determining status information of a quick payment agreement corresponding to the rebound target bank card, further comprising: uploading the status information of the quick payment agreement corresponding to the rebound target bank card to the blockchain system for storage when the status information indicates that the quick payment agreement of the rebound target bank card is valid (Paragraphs 0055 and 0086 teach the term “identification confirmation record” refers to a data object configured for summarizing information associated with receiving of an electronic data transmission in response to a near-field verification prompt received from a service provider device in response to a near-field event between a near-field item and a near-field terminal device associated with the service provider device; the identification confirmation record includes at least the received identity-linked device information, and the determined identification confirmation indicator; the identification confirmation record additionally includes a service provider identifier that uniquely identifies the service provider device associated with the near-field event; the repository management module may generate, store, retrieve, and/or otherwise maintain one or more identification confirmation record(s) in a repository, such as a record repository; the repository management module may maintain one or more blockchain repositories, for example, for storing identification confirmation records).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Gangapurkar, Cohen, and Wu to incorporate the teachings of Brown to after the determining status information of a quick payment agreement corresponding to the rebound target bank card, further comprising: uploading the status information of the quick payment agreement corresponding to the rebound target bank card to a blockchain system for storage when the status information indicates that the quick payment agreement of the rebound target bank card is valid.
There is motivation to combine Brown into the combination of Gangapurkar, Cohen, and Wu because of the same reasons listed above for claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kushner et al. (US 11,295,297) teaches a computer-implemented method includes receiving, by a mobile wallet computing system, information relating to a usable object from a party and provisioning, by the mobile wallet computing system, the usable object to a mobile wallet associated with a user. The computer-implemented method further includes receiving, by the mobile wallet computing system, one or more rules relating to the usable object from the party, wherein the one or more rules define an activation condition for the usable object such that when the activation condition is fulfilled the usable object is active in the mobile wallet of the user; determining, by the mobile wallet computing system, whether the activation condition is fulfilled; and in response to the activation condition for the usable object being fulfilled, activating, by the mobile wallet computing system, the usable object in the mobile wallet of the user.
Grassadonia et al. (US 20210192502) teaches a payment service system-implemented method of assigning payment card numbers for individual user accounts associated with the payment service system includes receiving a request, in the context of an authorization for a payment transaction, to assign a payment card number to a user account associated with a user of the payment service system. The method includes retrieving, from a database associated with the payment service system, an account record associated with the user account. The method includes determining that the user account is not associated with an active payment card number. The method includes identifying an unassigned payment card number and modifying the account record to assign the unassigned payment card number to the user account as an active payment card number. The method includes authorizing the payment transaction using the active payment card number, causing a modification to an account balance of the user account.
Feldman (US 20160180330) teaches a method for reactivation of a lost payment card includes: storing an account profile including data related to a transaction account including an account identifier, account number, authentication data, and activation flag, the flag indicating that a payment card is active; receiving an authorization request for a payment transaction, the request including the account number and a data field indicative of a lost payment card; updating the activation flag in the account profile to indicate that the payment card is frozen; receiving a verification message, the message including the account identifier and authentication information; authenticating the received verification message based on the included authentication information and the authentication data included in the account profile; and updating the activation flag in the account profile i to indicate that the payment card is active, wherein the payment card is prohibited from use if the activation flag indicates that the card is frozen.
Balbus (US 20150170137) teaches a method of activating and deactivating credit cards or debit cards by initiating activation or deactivation of a credit card or debit card in an application, transmitting an activate signal or deactivate signal to a server of a card issuer, validating user information, and activating or deactivating the credit card or debit card. A method of preventing fraudulent charges on a credit card or debit card. A method of using credit cards and debit cards by deactivating a credit card or debit card when not in use, and activating the credit card or debit card when use is needed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information Regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
Prosecution Insights