DETAILED ACTION
This is a non-final office action on the merits. The U.S. Patent and Trademark Office (the Office) has received claims 1 – 21 in application 19/013,504.
The “Preliminary Amendment” is acknowledged as received on 1/31/2025.
Claim 1 is canceled.
Claims 2-21 are new.
Claims 2-21 are pending and have been examined on the merits.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-12 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the following limitation: “wherein the smart contract when processed selectively transfers funds from the accounts to satisfy installment payments from the user to the creditor;” It is not clear whether "selectively" seems to be modifying "transfers" rather than "processed.” Therefore, the claim is indefinite and rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. For the purpose of compact prosecution, Examiner is interpreting the claim as modifying transfers.
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 2-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.
Step 1
Claims 2 –21 fall within at least one of the four categories of patent eligible subject matter, such as processes, machines, manufactures and compositions of matter, because claims 2-19 are directed to a method while claims 20 and 21 each recite an apparatus. Therefore, the claims pass Step 1 of the Subject Matter Eligibility Test (see MPEP § 2106, subsection I).
The claims, however, are directed to an abstract idea without significantly more. The claim, as a whole, fall under the methods of organizing human activity grouping of the Subject Matter Groupings of Abstract Ideas enumerated in MPEP § 2106.04(a).
Step 2A, Prong 1
Claim 2 recites the following elements (emphasis added on abstract idea):
A method, comprising:
receiving accounts of a user from a provider that services installment payments from the user to a creditor;
providing a secure token based on the receiving;
designating a first account of the accounts as a default account preferred by the user;
designating remaining accounts of the accounts as secondary accounts preferred by the user;
providing a first access token that identifies the default account;
providing a second access token that identifies the secondary accounts;
generating instructions for a smart contract with conditions that include the first access token and the second access token, wherein the smart contract when processed selectively transfers funds from the accounts to satisfy installment payments from the user to the creditor; and
instantiating the smart contract on a blockchain using the secure token for access by the provider.
As drafted, the elements that are not bolded represent a process that, under its broadest reasonable interpretation, is directed to automating a financial transaction/installment payment collection, which is a form of commercial interaction related to manage interactions between people; therefore, the process falls under Certain Method of Organizing Human Activity. Accordingly, this Step 2A Prong 1 analysis concludes that claim 1 recites an abstract idea.
Step 2A, Prong 2
Claim 2 does not include additional elements (when considered individually, as an ordered combination, and/or within the claim as a whole) that are sufficient to integrate the abstract idea into a practical application. The additional elements are bolded above.
The additional elements are: secure token, token, smart contract, blockchain. These elements does no more than generally link the use of the abstract idea to a particular technological environment, i.e., a blockchain environment. Therefore, this element individually does not provide a practical application.
The additional elements does not provide a practical application of the abstract idea. Furthermore, the additional element amount to a processing environment of the abstract idea.
Step 2B
Claim 2 does not include additional elements, when considered individually and as an ordered combination, that are sufficient to amount to significantly more than the abstract idea explained above with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment. Mere instructions to implement the abstract idea on a computer, or merely using the computer as a tool to perform an abstract idea to apply the exception using a generic computer component cannot provide an inventive concept. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually.
For these reasons, the independent claims (including claims 13 and 20) are rejected under 35 U.S.C. § 101 as being directed to non- statutory subject matter.
The remaining dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claims, when analyzed individually, and in combination, are also held to be patent ineligible under 35 U.S.C. 101. The additional recited limitations of the dependent claims fail to establish that the claims do not recite an abstract idea because the additional recited limitations of the dependent claims merely further narrow the abstract idea. The limitations of the dependent claims fail to integrate an abstract idea into a practical application because the dependent claims do not introduce additional elements; and performing the further narrowed abstract ideas of the dependent claims on the additional elements of independent claims, individually or in combination, does not impose any meaningful limits on practicing the abstract ideas and does not provide improvements to the functioning of computing systems or to another technology or technical field; therefore, the claims amount to merely using a computer, in its ordinary capacity, as a tool to perform the abstract idea. Similarly, the additional recited limitations of the dependent claims fail to establish that the claims provide an inventive concept because claims that merely use a computer, in its ordinary capacity, as a tool to perform the abstract idea cannot provide an inventive concept.
Regarding Claim 3. The method of claim 2, wherein receiving further includes receiving the accounts from the provider, wherein the user registers the accounts with the provider for use on the blockchain. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 4. The method of claim 2, wherein providing the secure token further includes providing the secure token to the provider for subsequent delivery to the user. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 5. The method of claim 2, wherein designating the first account further includes: receiving the secure token from the user; authenticating the secure token; linking the secure token to the accounts; and presenting the accounts within a user interface for selection of the first account as the default account by the user. The additional element is user interface. The additional element does not integrate the abstract idea into a practical application.
Regarding Claim 6. The method of claim 2, wherein providing the first access token further includes providing the first access token to the user for delivery to the provider. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 7. The method of claim 2, wherein providing the second access token further includes providing the second access token to the user for delivery to the provider. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 8. The method of claim 2, wherein generating further includes configuring the instructions with an algorithm for determining how to apportion available funds from each of the accounts to satisfy an amount due by a particular installment payment when the amount due exceeds a current account balance of the default account. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 9. The method of claim 8, wherein configuring further includes configuring the instructions to obtain account histories and current balances of the accounts as input to the algorithm. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 10. The method of claim 8, wherein configuring further includes configuring the instructions to use a machine-learning model as the algorithm. The additional element is a machine-learning model. The additional element does not integrate the abstract idea into a practical application.
Regarding Claim 11. The method of claim 8, wherein configuring further includes configuring the instructions to provide user designated priorities or rules for apportioning between the accounts as input to the algorithm. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 12. The method of claim 2, wherein instantiating further includes using the secure token as a key for obtaining an address of the smart contract on the blockchain. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 14. The method of claim 13, wherein configuring further includes configuring the instructions to apportion funds transferred from the registered accounts to satisfy a particular installment payment when a current balance of the default account is insufficient to make the particular installment payment. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 15. The method of claim 13, wherein configuring further includes configuring the instructions to maintain up-to-date balance totals for each of the registered accounts. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 16. The method of claim 13, wherein configuring further includes configuring the instructions to transfer funds from the default account to an account associated with the provider or the creditor when a current balance of the default account is sufficient to pay a particular installment payment. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 17. The method of claim 13, wherein configuring further includes configuring the instructions to validate and authenticate the first access token and the second access token provided by the provider to the smart contract for a given installment payment. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 18. The method of claim 13, wherein configuring further includes obtaining user- defined priorities from a profile linked to the user for determining how to apportion funds between accounts. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 19. The method of claim 13, wherein instantiating further includes preventing modification of the conditions associated with the installment payments after initial creation of the smart contract. There are no additional elements that integrate the abstract idea into a practical application.
Regarding Claim 21. The system of claim 20, wherein the operations further include configuring the instructions to obtain account histories and current balances for each of the registered accounts each time a given installment payment is requested by the provider. There are no additional elements that integrate the abstract idea into a practical application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 2-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hockey (US20190182233A1) in view of Wu (US20200143466A1) and in further view of Dresner (US20200097928A1) and in further view of Cavoto (US20190353685A1).
Regarding Claim 2. Hockey teaches (in BOLD):
A method, comprising: receiving accounts of a user from a provider that services installment payments from the user to a creditor;
Note – Hockey teaches a provider/API that works with user accounts and supports transactions which included scheduling payments.
Hockey - banks, credit card providers, investment services, loan providers, and/or other suitable financial institutions or user account holding institutions (¶ 0194). initiate transactions (such as a transfer of funds between accounts, schedule payments, etc.) (¶ 0231).
designating a first account of the accounts as a default account preferred by the user;
Hockey - one institution is set as a primary account (¶ 0249).
designating remaining accounts of the accounts as secondary accounts preferred by the user;
Hockey - another account managed by the same entity is set as a secondary account (¶ 0249).
providing a first access token that identifies the default account;
Hockey - access account (¶ 0250).
providing a second access token that identifies the secondary accounts;
Hockey - access account (¶ 0250).
Hockey does not teach, however Wu discloses:
A method, comprising: receiving accounts of a user from a provider that services installment payments from the user to a creditor;
Note – Wu teaches the installment loan context.
Wu - loan parameter values (¶ 0006). a number of installments (¶ 0007).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey with the installments of Wu because doing so connects different accounts to pay back loans.
The combination of Hockey and Wu does not disclose, however Dresner discloses:
providing a secure token based on the receiving;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
providing a first access token that identifies the default account;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
providing a second access token that identifies the secondary accounts;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
instantiating the smart contract on a blockchain using the secure token for access by the provider.
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu with the token-based service authentication of Dresner because doing so controls access to network services to improve and harden authorization boundaries for different resources.
The combination of Hockey, Wu, and Dresner does not disclose, however Cavoto discloses:
generating instructions for a smart contract with conditions that include the first access token and the second access token, wherein the smart contract when processed selectively transfers funds from the accounts to satisfy installment payments from the user to the creditor; and
Note – Cavoto teaches smart contract code is executed when conditions are satisfied and it transfers a “funds amount” between wallets (accounts).
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
instantiating the smart contract on a blockchain using the secure token for access by the provider.
Cavoto - chaincode sends an authorization key to the requested service (¶ 0046). prepares a smart contract based on that value and deposits the contract on the blockchain (¶ 0065). smart contract execution may be written to a blockchain as a blockchain transaction (¶ 0077).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 3. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein receiving further includes receiving the accounts from the provider, wherein the user registers the accounts with the provider for use on the blockchain.
Hockey - The user may provide some account credentials that can be used in an initial registration of the proxy instance with the non-public or public API of the institution. The proxy instance may be characterized as a set of properties that can be stored and maintained. Some of those properties may be automatically generated, may be provided from the institution during negotiating registration, may be properties of the application that is being simulated, and/or may include any suitable identifying and authenticating information (¶ 0209).
Regarding Claim 4. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein providing the secure token further includes providing the secure token to the provider for subsequent delivery to the user.
Hockey - At block 350, which includes returning results, the system 100 functions to deliver the results as a response to the request. Returning the results includes transforming the data obtained from the external institution into a normalized form. The information is formatted into a standardized format that is substantially similar in representation between different institutions served by the system 100 (¶ 0221).
Regarding Claim 5. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein designating the first account further includes: receiving the secure token from the user;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
authenticating the secure token;
Dresner - The token vault may then verify that the third-party ID matches the token, and the token may then be de-tokenized to reveal the true account number. The debit or credit may then be posted to the correct customer account, and the transaction proceeds as normal (¶ 0027).
linking the secure token to the accounts; and
account (¶ 0004).
presenting the accounts within a user interface for selection of the first account as the default account by the user.
Dresner - In step 210, the third party may engage the trusted party to interface with the user's financial institution to obtain token and account details and may provide the trusted party with the third-party identifier (e.g., the third party's ACH Company ID) (¶ 0032).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 6. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein providing the first access token further includes providing the first access token to the user for delivery to the provider.
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 7. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein providing the second access token further includes providing the second access token to the user for delivery to the provider.
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 8. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein generating further includes configuring the instructions with an algorithm for determining how to apportion available funds from each of the accounts to satisfy an amount due by a particular installment payment when the amount due exceeds a current account balance of the default account.
Wu - The offers displayed may be based on offer data from the off-chain computing system 152. Each offer in the offer data may include information, or parameters, such as: a principal amount, a principal unit type (e.g., a type of crypto asset), a collateral amount, a collateral unit type (e.g., a type of crypto asset, which may be different than the principal unit type), an interest rate, a loan term, a loan total cost, and a number of installments. The offer data received using the user interface system 150. The processing circuitry may display an offer interface 400 (see FIG. 9) for the user to input offer data (¶ 0073).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 9. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 8, wherein configuring further includes configuring the instructions to obtain account histories and current balances of the accounts as input to the algorithm.
Hockey - In another optional stage, the account may be processed for fraud patterns. For example, the age of the account may be accessed. Newly created accounts may be less trustworthy than established accounts with significant history. Similarly transaction history may be assessed for fraudulent behavior. If the account is used for a diverse range of transactions indicative of normal behavior then the account may be identified as normal. If the account only participates in repeated high value transactions or other fraud patterns, then the account may be flagged as fraudulent. Additionally, the entities involved in the transaction may be indicative of fraud (¶ 0243).
Regarding Claim 10. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 8, wherein configuring further includes configuring the instructions to use a machine-learning model as the algorithm.
Hockey - It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. For example, any of the processes, methods, algorithms, elements, blocks, applications, or other functionality (or portions of functionality) described in the preceding sections may be embodied in, and/or fully or partially automated via, electronic hardware (¶ 0412)
Regarding Claim 11. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 8, wherein configuring further includes configuring the instructions to provide user designated priorities or rules for apportioning between the accounts as input to the algorithm.
Hockey - According to another aspect, the electronic token further includes a history of transactions associated with the external application, and wherein the comparing further comprises comparing the one or more transaction details with the history of transactions (¶ 0083).
Regarding Claim 12. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 2, wherein instantiating further includes using the secure token as a key for obtaining an address of the smart contract on the blockchain.
Dresner - Systems and methods for conducting account tokenized transactions are disclosed. In one embodiment, a method may include: receiving a third-party identifier, login credentials for a user, and an identification of a user account to tokenize from a trusted party; generating a token for the user account and associating the token with the user account and the third-party identifier; providing the token, a token-specific routing number, and the third-party identifier to the trusted party; receiving, from the third party's financial institution, a transaction comprising the token, the token-specific routing number, and the third-party identifier; identifying the transaction as involving a tokenized account based on the token-specific routing number; verifying that the third-party identifier received from the third party's financial institution matches the third-party identifier associated with the token; identifying the account associated with the token; posting the transaction to the account; and settling the transaction with the third party (Abstract).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 13. Hockey teaches (in BOLD)
A method, comprising: receiving registered accounts of a user from a provider that services installment payments due from the user to a creditor;
Note – Hockey teaches a provider/API that works with user accounts and supports transactions which included scheduling payments.
Hockey - banks, credit card providers, investment services, loan providers, and/or other suitable financial institutions or user account holding institutions (¶ 0194). initiate transactions (such as a transfer of funds between accounts, schedule payments, etc.) (¶ 0231).
generating a first access token associated with the default account and a second access token associated with the secondary accounts;
Hockey - access account (¶ 0250).
Hockey does not teach, however Wu discloses:
A method, comprising: receiving registered accounts of a user from a provider that services installment payments due from the user to a creditor;
Note – Wu teaches the installment loan context.
Wu - loan parameter values (¶ 0006). a number of installments (¶ 0007).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey with the installments of Wu because doing so connects different accounts to pay back loans.
The combination of Hockey and Wu does not discloses, however Dresner discloses:
providing the provider a secure token for delivery to the user and creation of a smart contract that manages the installment payments on a blockchain;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
receiving the secure token from the user and linking the secure token to the registered accounts;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
receiving selections from the user that designate a default account and secondary accounts from the registered accounts;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
generating a first access token associated with the default account and a second access token associated with the secondary accounts;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu with the token-based service authentication of Dresner because doing so controls access to network services to improve and harden authorization boundaries for different resources.
The combination of Hockey, Wu, and Dresner does not disclose, however Cavoto discloses:
configuring instructions with conditions associated with the installment payments, the default account, the secondary accounts, the first access token, and the second access token; and
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
instantiating the instructions on the blockchain as a smart contract that is reachable by the provider on the blockchain via the secure token.
Cavoto - chaincode sends an authorization key to the requested service (¶ 0046). prepares a smart contract based on that value and deposits the contract on the blockchain (¶ 0065). smart contract execution may be written to a blockchain as a blockchain transaction (¶ 0077).
providing the provider a secure token for delivery to the user and creation of a smart contract that manages the installment payments on a blockchain;
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 14. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 13, wherein configuring further includes configuring the instructions to apportion funds transferred from the registered accounts to satisfy a particular installment payment when a current balance of the default account is insufficient to make the particular installment payment.
Wu - Systems may include an off-chain computing system and an on-chain computing system. Methods may include receiving a principal amount to lend or borrow based on input from a first user, storing offer data in an off-chain data structure, requesting recordation of a smart contract on a blockchain based on the offer data, confirming a first transaction of the principal amount or the collateral amount from the second user to the smart contract has been recorded on the blockchain, confirming a second transaction of the principal amount or the collateral amount complementary to the first transaction from the first user to the smart contract has been recorded on the blockchain, and confirming the smart contract has recorded a third transaction releasing the principal amount on the blockchain in response to confirming both the first transaction and the second transaction (Abstract).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 15. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 13, wherein configuring further includes configuring the instructions to maintain up-to-date balance totals for each of the registered accounts.
Hockey - the trusted third-party processor system 1212 may optionally communicate with the permissions management system 1204 to determine that the external user-facing system/application 1208 is authorized to cause the transaction to be executed (e.g., permissions may be checked, an account balance may be checked, etc.); and the trusted third-party processor system 1212 may initiate execution of the transaction (e.g., by sending a request to the external user account system 1206) (¶ 0359).
Regarding Claim 16. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 13, wherein configuring further includes configuring the instructions to transfer funds from the default account to an account associated with the provider or the creditor when a current balance of the default account is sufficient to pay a particular installment payment.
Hockey - A transaction endpoint can be abstracted to a user entity, which may be associated with multiple optional transactional endpoints (e.g., different bank accounts). Accordingly, the method may include selecting an institution, which functions to dynamically select a connected account to participate in a transaction. Various conditions may be set to respond to events when receiving a transaction request, collecting information for the transaction, and/or executing a transaction. In one variation, one institution is set as a primary account and another account managed by the same entity is set as a secondary account. If the primary account is not able to complete a transaction, the method may detect an error condition and automatically fails over to the secondary account. In another variation, a set of accounts may be preconfigured to be used depending on properties of the request. In combination with the proxy transfer endpoint, the identifying information for the proxy endpoint can be used, but the underlying service automatically will use an automatically selected account to use for the funds. For example, a set of entities and/or category of entities/transactions may be set to use particular accounts. Similarly, transactions to one proxy account may be automatically split into transactions with multiple associated accounts. For example, an account holder may set a proxy account to automatically split deposits between two accounts in a 30/70 balance (¶ 0249).
Regarding Claim 17. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 13, wherein configuring further includes configuring the instructions to validate and authenticate the first access token and the second access token provided by the provider to the smart contract for a given installment payment.
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 18. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 13, wherein configuring further includes obtaining user- defined priorities from a profile linked to the user for determining how to apportion funds between accounts.
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 19. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The method of claim 13, wherein instantiating further includes preventing modification of the conditions associated with the installment payments after initial creation of the smart contract.
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 20. Hockey teaches (in BOLD):
A system, comprising: a server comprising at least one processor and a non-transitory computer-readable storage medium;
Hockey - the main memory (e.g., a random access memory (RAM)) 1122, a read only memory (ROM) 1104, a computer readable storage medium 1105 (e.g., a non-transitory computer readable storage medium), a display device 1107, a user input device 1108, and a network device 1111 (¶ 0278).
the non-transitory computer-readable storage medium comprises executable instructions;
Hockey - the main memory (e.g., a random access memory (RAM)) 1122, a read only memory (ROM) 1104, a computer readable storage medium 1105 (e.g., a non-transitory computer readable storage medium), a display device 1107, a user input device 1108, and a network device 1111 (¶ 0278).
the executable instructions when executed by the at least one processor cause the at least one processor to perform operations comprising:
Hockey - the main memory (e.g., a random access memory (RAM)) 1122, a read only memory (ROM) 1104, a computer readable storage medium 1105 (e.g., a non-transitory computer readable storage medium), a display device 1107, a user input device 1108, and a network device 1111 (¶ 0278).
identifying a default account from the registered accounts;
Hockey - one institution is set as a primary account (¶ 0249).
identifying remaining accounts that are not the default account as secondary accounts;
Hockey - another account managed by the same entity is set as a secondary account (¶ 0249).
generating a first access token associated with the default account;
Hockey - access account (¶ 0250).
generating a second access token associated with the secondary accounts;
Hockey - access account (¶ 0250).
Hockey does not teach, however Wu discloses:
configuring instructions for a smart contract to manage installment payments made by the user through the registered accounts to a provider who collects the installment payments on behalf of a creditor; and
Wu - loan parameter values (¶ 0006). a number of installments (¶ 0007).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey with the installments of Wu because doing so connects different accounts to pay back loans.
The combination of Hockey and Wu does not discloses, however Dresner discloses:
linking registered accounts of a user to a secure token;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
generating a first access token associated with the default account;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
generating a second access token associated with the secondary accounts;
Dresner - generating a token for the user account and associating the token with the user account (¶ 0004).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu with the token-based service authentication of Dresner because doing so controls access to network services to improve and harden authorization boundaries for different resources.
The combination of Hockey, Wu, and Dresner does not disclose however Cavoto discloses:
configuring instructions for a smart contract to manage installment payments made by the user through the registered accounts to a provider who collects the installment payments on behalf of a creditor; and
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
installing and initiating the instructions as a smart contract on a blockchain accessible via the secure token.
Cavoto - chaincode sends an authorization key to the requested service (¶ 0046). prepares a smart contract based on that value and deposits the contract on the blockchain (¶ 0065). smart contract execution may be written to a blockchain as a blockchain transaction (¶ 0077).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Regarding Claim 21. The combination of Hockey, Wu, Dresner, and Cavoto further discloses:
The system of claim 20, wherein the operations further include configuring the instructions to obtain account histories and current balances for each of the registered accounts each time a given installment payment is requested by the provider.
Cavoto - A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied (¶ 0044). funds amount to be transferred from the device wallet to the…provider wallet (¶ 0046).
Therefore, it would have been obvious to one of ordinary skilled of the art before the effective filing date of the claimed invention to modify the permissions and management system of Hockey and the installments of Wu and the token-based service authentication of Dresner with the preparing the smart contract of Cavoto because doing so automates satisfaction of an amount due using the blockchain.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ginter – (US20060218651A1) - The present inventions provide an integrated, modular array of administrative and support services for electronic commerce and electronic rights and transaction management. These administrative and support services supply a secure foundation for conducting financial management, rights management, certificate authority, rules clearing, usage clearing, secure directory services, and other transaction related capabilities functioning over a vast electronic network such as the Internet and/or over organization internal Intranets.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINA C whose telephone number is (571)270-7280. The examiner can normally be reached on Monday-Friday from 8am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick Mcatee, can be reached at telephone number 571-272-7575. 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.
/C.C.S./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698