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 .
DETAILED ACTION
This Office Action is in response to Applicant’s communication filed on May 19, 2025 for the patent application 19/034,419.
Status of Claims
Claims 1, 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 45, 46, 70, 75, 79, 83, 85, 88 and 91 are pending in the application.
Claims 1, 2, 4, 9, 15, 19, 25, 70, 75, 79, 83, 85, 88 and 91 are currently amended in the application.
Claims 3, 6 – 7, 10 – 14, 16 – 18, 20 – 24, 26, 28, 29, 31 – 44, 47 – 69, 71 – 74, 76 – 78, 80 – 82, 84, 86 – 87, 89 - 90 and 92 are cancelled in the application without prejudice or disclaimer.
Information Disclosure Statement
The Information Disclosure Statements (IDS) submitted on May 19, 2025, June 02, 2025 and January 27, 2026 were filed in compliance with the provisions of 37 CFR 1.97. Accordingly, these Information Disclosure Statements are being considered by the Examiner.
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.
Claim(s) 1, 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 45, 46, 70, 75, 79, 83, 85, 88 and 91 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 45, 46, 70, 75, 79, 83, 85, 88 and 91 are either directed to a method or system or computer readable medium, which are statutory categories of invention. (Step 1: YES).
The Examiner has identified method claim 1 as the claim that represents the claimed invention for analysis and is similar to system claim 45 and computer readable claim 79. Claim 1 recites the limitations of:
( A ) obtaining first agreement data associated with a first agreement between a first user and a second user;
( B ) verifying that the first agreement data associated with the first agreement is valid based on:
a first input received from a first device associated with the first user;
a second input received from a second device associated with the second user; or
a combination thereof;
( C ) after verification of the first agreement, sending a request to create, at an institution server, a financial account associated with the first agreement; and
( D ) storing, at a database, first entry information at a first entry associated with the first agreement, wherein the first entry information indicates the first user, the second user, the first agreement data, the financial account, or a combination thereof.
These limitations without the bolded limitations above, cover performance of the limitations as certain methods of organizing human activity under their broadest reasonable interpretation.
More specifically, these limitations cover performance of the limitations as a fundamental economic practice.
In summary, if claim 1 limitations, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Claims 45 and 79 are also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims are abstract).
The use of an institution server or any of the bolded limitations in claim 1 are just applying generic computer components to the recited abstract limitations. Similar arguments apply to claims 45 and 79.
Therefore, the above mentioned judicial exception is not integrated into a practical application by merely applying generic computer components (bolded elements).
Furthermore, the “obtaining” and “verifying” steps are recited at a high level of generality and amounts to mere data gathering/transmitting, which are forms of insignificant extra-solution activity (See MPEP 2106.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)).
In addition, supported by specification, the computer hardware are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component., see MPEP 2106.05(f), where applying a computer or using a computer is not indicative of a practical application).
Claim 1, limitation ( B ) above in Applicant’s specification para [0158], which discloses “In some implementations, a server (e.g., the clearance server 116) includes at least one processor (e.g., the processor 118) and a memory (e.g., the memory 120) coupled with the at least one processor. The memory stores processor-readable instructions that, when executed by the at least one processor, cause the at least one processor to obtain first agreement data (e.g., the agreement information 110) associated with a first agreement between a first user and a second user. The instructions, when executed by the at least one processor, further cause the at least one processor to verify that the first agreement data associated with the first agreement is valid based on a first input received from a first device (e.g., the producer device 102) associated with the first user, a second input received from a second device (e.g., the off taker device 130) associated with the second user, or a combination thereof. The instructions, when executed by the at least one processor, also cause the at least one processor to, after verification of the first agreement, send a request (e.g., the account request 172) to create, at an institution server (e.g., the institution server 150), a financial account (e.g., represented by the account information 158) associated with the first agreement. The instructions, when executed by the at least one processor, cause the at least one processor to store, at a database (e.g., the database 126), first entry information at a first entry associated with the first agreement. The first entry information indicates the first user, the second user, the first agreement data, the financial account, or a combination thereof.“.
Also, claim 1, limitation ( B ) above in Applicant’s specification para [0286], which discloses “At block 2904, the server verifies that the first agreement data associated with the first agreement is valid based on a first input received from a first device associated with the first user, a second input received from a second device associated with the second user, or a combination thereof. The first input may include an indication that the first agreement data or a summary (e.g., a standardized summary of the first agreement data) is correct, a first digital signature of the first user, or a combination thereof, as illustrative, non-limiting examples. Additionally, the second input may include an indication that the first agreement data or a summary (e.g., a standardized summary of the first agreement data) is correct, a second digital signature of the second user, or a combination thereof, as illustrative, non-limiting examples.“.
Also, claim 1, limitation ( C ) above in Applicant’s specification para [0045], which discloses “Referring to FIG. lA, a block diagram of an example clearance system 100 according to one or more aspects is depicted. System 100 includes user devices (such as a producer device 102, an offtake device 130, and a recipient device 140), a clearance server 116 (e.g., a clearance platform), and an institution server 150. In some implementations, system 100 may also include one or more bank devices (or servers), such as a first bank device 160, a second bank device 162, or a combination thereof. It is noted that in some implementations, the institution server 150 may be a bank device (e.g., a bank server). The producer device 102, the clearance server 116, the off taker device 130, the recipient device 140, the institution server 150, the first bank device 160, the second bank device 162, or a combination thereof, may include or correspond to an electronic device, such as a server or computer, as illustrative, non-limiting examples. In some implementations, the institution server 150 may include or correspond to a financial institution,
such as a bank.
“.
Also, claim 1, limitation ( D ) and ( E ) above in Applicant’s specification para [0055], which discloses “The memory 120 may be configured to store instructions 122, participant information 124 (e.g., user information, bank account information, etc.), a database 126, an API 128, or a combination thereof. In some implementations, the instructions 122, the participant information 124, the database 126, the API 128, or a combination thereof, may be stored externally from (e.g., remotely to) the clearance server 116. The instructions 122 may include or correspond to object code, source code, firmware, or combinations thereof that, when executed by the processor 118, cause the processor 118 to perform operations according to aspects of the present disclosure, as described herein.“. Similar arguments apply to claims 45 and 79.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Therefore, claims 1, 45 and 79 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application).
The claims 1, 45 and 79 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements (bolded elements above) amount to no more than mere instructions to apply the abstract idea using generic computer components. In conclusion, merely "applying" the exception using generic computer components cannot provide an inventive concept. Therefore, the claims 1, 45 and 79 are not patent eligible under 35 USC 101. (Step 2B: NO. The claims do not provide significantly more).
Dependent Claims
Dependent claims 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 46, 70, 75, 83, 85, 88 and 91 are also rejected under 35 U.S.C. 101. Dependent claims 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 46, 70, 75, 83, 85, 88 and 91 are further define the abstract idea or further define the extra-solution activities that are present in independent claim 1 thus abstract idea correspond to certain methods of organizing human activity as presented above. Claims 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 46, 70, 75, 83, 85, 88 and 91 clearly further define the abstract idea as stated above and further define extra-solution activities such as presenting data and transmitting/receiving data.
Furthermore, dependent claims 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 46, 70, 75, 83, 85, 88 and 91do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Regarding claim 2, this claim merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 2 states “generating a smart contract based on the first agreement, wherein: the database includes a blockchain ledger that stores the first entry; and the first entry includes the smart contract; at least a portion of the first entry is immutable; the first agreement is further between the first user, the second user, and an entity associated with the institution server; the first input includes a first digital signature and the second input includes a second digital signature; and obtaining the first agreement data includes receiving the first agreement data from the first device or generating the first agreement data.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)).
Regarding claim 4, this claim merely recite, "after verification of the first agreement, initiating formation of a second agreement associated with use of the financial account in association with the first agreement, the second agreement between the first user, the second user, and an entity associated with the institution server, wherein prior to verification of the second agreement, the financial account has a reserved status; verifying that the second agreement is complete; storing, at the database, second agreement data at the first entry, wherein the second agreement data is associated with the second agreement; and after verification of the second agreement, sending, to the institution server, a status change request to change the financial account from the reserved status to an active status.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 5, this claim merely provide further detail regarding the process, recited in claim 1. Merely stating, “generating a first version of the second agreement based on the first agreement, the financial account, or a combination thereof; and sending, to each of the first user, the second user, and the entity, a request to sign the first version of the second agreement, wherein the verified second agreement is a second version of the second agreement that is signed by each of the first user, the second user, and the entity.”. This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 8, this claim merely recite, "receiving, from the first device associated with the first user, first user information associated with the first user, wherein the first user information indicates: a first bank account associated with the first user, and a name of the first user, a company associated with the first user, a birthday of the first user, a nationality of the first user, a government identification number associated with the first user, an email address associated with the first user, a phone number associate with the first user, a fax number associated with the first user, an address associated with the first user, or a combination thereof; and storing, at the database, first bank account information that indicates the first bank account, a bank name, an account type, a holder name, or a combination thereof, and wherein the first agreement indicates that the second user owes the first user a payment amount.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claims 9, this claim merely provide further detail regarding the processing, recited in claim 1. Merely stating “receiving, from the second device associated with the second user, second user information associated with the second user, wherein the second user information indicates a second bank account associated with the second user; storing, at the database, second bank account information that indicates the second bank account, and wherein the first agreement indicates that the second user owes the first user a payment amount; receiving, from a third device associated with a third user, third user information associated with the third user, wherein the third user information indicates a third bank account associated with the third user; storing, at the database, third bank account information that indicates the third bank account receiving, from the third device associated with the third user, a payment request associated with the first agreement, wherein the payment request includes document data, a request amount, or a combination thereof; sending, to a first user device associated with the first user, an approval request based on the payment request; receiving, from the first user device, an approval message responsive to the approval request; and updating the first entry to indicate that the third user is to receive a portion of the payment amount paid by the second user in accordance with the first agreement.". This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 15, this claim merely add further description to the process of “identifying the financial account at the institution server, the financial account associated with the first agreement between the first user and the second user; determining, based on the first entry in the database, one or more disbursements from the financial account, the one or more disbursements including a first disbursement to a first account associated with first user, wherein the first entry is associated with the first agreement; sending, to the institution server, a request to perform the one or more disbursements; and sending a notification that indicates the first disbursement to the first account associated with the first user; receiving, from the institution server, a transfer request notification of a transfer request associated with the second user; and receiving, from the institution server, a transfer completion notification that indicates completion of a transfer to the financial account based on the transfer request; the transfer completion notification is received prior to delivery, from the first user to the second user, of an object associated with the first agreement; and determining the one or more disbursements is performed based on identification of a change in status of the object indicated by the first entry.” This amount to no more than mere data gathering/outputting as described in reference to claims 1, 10 and 16 (see analysis above). Merely describing the comparing the new claim information does not integrate the abstract idea into a practical application, or amount to significantly more than the judicial exception, because it does not impose any meaningful limitations on practicing the abstract idea.
Regarding claim 19, this claim merely recite, "receiving, from the institution server, an indicator associated with the financial account, wherein the indicator includes an account number of the financial account, a routing number, a quick response (QR) code, or a combination thereof; sending the indicator to the second device associated with the second user; and storing the indicator at the first entry.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 25, this claim merely add further description to the process of “sending, to a core server, a first indicator that indicates first user information associated with the first user; sending, to the core server, a request to verify the first user; receiving, from the core server, an indicator that indicates the first user is verified sending, to the core server, a request to create the financial account associated with the first agreement; receiving, from the core server, an identifier associated with the financial account; and sending the identifier to a device associated with the second user, the database for storage at the first entry, or a combination thereof,”, which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 27, this claim merely recite additional steps that amount to no more than insignificant extra-solution activity. Specifically, claim 27 states “receiving, from the first device or the second device, a status request associated with the first agreement; accessing the database to obtain first entry information based on the first entry; obtaining status information based on the first entry information, wherein the status information indicates an amount due associated with the first agreement, one or more distribution amounts, one or more fee amounts, or a combination thereof; and sending the status information to the first device or the second device.”. These steps amount to no more than mere data gathering/analysis, which is a form of insignificant extra- solution activity (See M PEP 2016.05(g): CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375 (Fed. Cir. 2011); and GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015)). Such limitations do not integrate the abstract idea into a practical application, or amount to significantly than the abstract idea, because the courts have found the concept of data gathering to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): GIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015); and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, (Fed. Cir. 2014)).
Regarding claim 30, this claim merely provide further detail regarding the processing, recited in claims 1. Merely stating “receiving sensor data associated with an object to be provided from the first user to the second user in accordance with the first agreement; storing, based on the sensor data, a status to the first entry; and determining, based on the status, the sensor data, or a combination thereof, whether to indicate one or more distributions associated with the financial account.". This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 46, this claim merely recite, " identify the financial account at the institution server, wherein the first user is a beneficiary of the financial account, and wherein an entity associated with the core server has agency over the financial account; identify a transfer made to the financial account; after identification of the transfer, send, to the institution server, a request to perform one or more disbursements from the financial account, the one or more disbursements determined based on a first entry in a database, wherein the first entry is associated with the first agreement and indicates the first user, the second user, the first agreement data, the financial account, or a combination thereof; and send a notification that indicates a first disbursement to a first account associated with the first user.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 70, this claim merely provide further detail regarding the processing the loss, recited in claim 45. Merely stating, “the request to create the financial account associated with the first agreement is sent to the institution server via a core server; and the clearance server is further configured to: sending, to a core server, a request to verify the first user, wherein the request includes first user information associated with the first user; receiving, from the core server, an indicator that indicates the first user is verified; and receive, from the core server, a notification that indicates a first disbursement from the financial account to a first account associated with the first user.”. This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 75, this claim merely recite, "receive, from the first device or the second device, a status request associated with the first agreement; access the database to obtain first entry information based on the first entry; in response to receiving the status request, send, to a core server, a status information request; receive status information from the core server in response to the status information request, wherein the status information is based on the first entry information, and wherein the status information indicates an amount due associated with the first agreement, one or more distribution amounts, one or more fee amounts, or a combination thereof; and send the status information to the first device or the second device.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claims 83, this claim merely provide further detail regarding the processing, recited in claim 79. Merely stating “access the database to obtain at least a portion of entry information, wherein the entry information indicates one or more payment amounts, one or more fees, or a combination thereof, and wherein the transfer is performed from a second account associated with the second user to the financial account; and identify, based on the entry information, a third user associated with the first agreement, wherein the one or more disbursements include a second disbursement to a third account associated with the third user.". This does not integrate the abstract idea into a practical application because it does not impose any meaningful limitation on practicing the abstract idea.
Regarding claim 85, this claim merely add further description to the process of “access the database to obtain at least the portion of the entry information, wherein the entry information indicates one or more payment amounts and one or more fees, and wherein the transfer is performed from a second account associated with the second user to the financial account; and determine, based on the entry information, a fee associated with the first agreement, wherein the fee includes a service fee, a regulatory fee, or a combination thereof, and wherein the one or more disbursements include a third disbursement to a fourth account associated with an entity associated with a clearance server, the server, or the institution server, and wherein the third disbursement is based on the fee.”. This amount to no more than mere data gathering/outputting as described in reference to claims 1, 10 and 16 (see analysis above). Merely describing the comparing the new claim information does not integrate the abstract idea into a practical application, or amount to significantly more than the judicial exception, because it does not impose any meaningful limitations on practicing the abstract idea.
Regarding claim 88, this claim merely recite, "receive, from a clearance server, a first indicator that indicates first user information associated with the first user; receive, from the clearance server, a request to create the financial account associated with the first agreement; send, to the institution server, an account creation request, wherein the account creation request is sent via an application program interface (API) of the institution server; receive, from the institution server, an identifier associated with the financial account, wherein the identifier associated with the financial account includes an account number, a routing number, a bank name, a beneficiary name, a quick response (QR) code, or a combination thereof; send, to the clearance server, a device associated with the second user, the database for storage at the first entry, or a combination thereof, the identifier; obtain, from the institution server, a confirmation of performance of the one or more disbursements; and send, to the institution server and based on the confirmation, a request to close the financial account.“. These limitation merely recites storing data in a server which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
Regarding claim 91, This claim merely add further description to the process of “receive, from a clearance server, a request to verify the first user, wherein the request includes first user information associated with the first user; send, to the institution server, the first user information; receive, from the institution server and based on the first user information, a verification response that indicates that the first user is verified; send, to the clearance server, an indicator that indicates the first user is verified; receive, from the clearance server, a status request associated with the first agreement; access the database to obtain entry information based on the first entry; generate status information based on the entry information, wherein the status information indicates an amount due associated with the first agreement, one or more distribution amounts, one or more fee amounts, or a combination thereof; and send the status information to the clearance server,”, which amounts to no more than gathering/storing data which is a form of insignificant extra-solution activity (See MPEP 2106.0S(g)(3)(iii): GIP Technologies, 788 F.3d at 1363). This does not integrate the abstract idea into a practical application because it has been determined, by the courts, that the concept of storing data is well-understood, routine, and conventional activity (See MPEP 2106.0S(d)(II): Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334 (Fed. Cir. 2015)).
As a result, such limitations do not overcome the requirements as described above. Therefore, claims 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 46, 70, 75, 83, 85, 88 and 91 are directed to an abstract idea. Thus, claims 1, 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 45, 46, 70, 75, 79, 83, 85, 88 and 91 are not patent eligible.
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 of this title, 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, 2, 4, 5, 8, 9, 15, 19, 25, 27, 30, 45, 46, 70, 75, 79, 83, 85, 88 and 91 are rejected under 35 U.S.C. 103 as being obvious over Jianghua Meng (Pat. # CN 110 659 977 A – herein referred to as Meng) in view of Lukasz J. Sliwka et al. (Pub. # US 2021/0082044 A1 – herein referred to as Sliwka).
Re: Claim 1, Meng discloses a method for implementing a clearance service, the method comprising:
obtaining first agreement data associated with a first agreement between a first user and a second user (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system Identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key} and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card Information, user biological identification code information or user Identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.);
verifying that the first agreement data associated with the first agreement is valid based on:
a first input received from a first device associated with the first user (Meng, page 4, lines 53 - 54 - generating first pledge liquidation asset query request information according to query requirements input and/or selected by the lender !n an asset query function interface on the chain, and then sending the first pledge liquidation asset query request information with the lender signature to the asset ledger system.);
a second input received from a second device associated with the second user (Meng, page 8, lines 58 - 61 - step S403: the borrower asset application terminal system displays an on-chain asset query function interface to the borrower on the borrower terminal device, generates second repayment condition query request information according to query requirements input and/or selected by the borrower in the on-chain asset query function interface, and then sends the second repayment condition query request Information with the borrower digital signature to a consensus ledger layer execution module of the asset ledger system.).
However, Meng does not expressly disclose:
after verification of the first agreement, sending a request to create, at an institution server, a financial account associated with the first agreement; and
storing, at a database, first entry information at a first entry associated with the first agreement, wherein the first entry information indicates the first user, the second user, the first agreement data, the financial account, or a combination thereof.
In a similar field of endeavor, Sliwka discloses:
after verification of the first agreement, sending a request to create, at an institution server, a financial account associated with the first agreement (Sliwka, [0099] – In some embodiments, the user management system 116 creates new accounts for users. In these embodiments, a new user may access the platform 100 and may request a new account. In embodiments, the platform 100 may allow a user to link their account to an account of an external system (e.g., Google®, Facebook®, Twitter®, etc.). Additionally, or alternatively, a user can provide an email address and login. In embodiments, the user management system 116 may request a user to provide additional authenticating information, such as a home address or business address, a passport number (and/or image of the passport), driver's license number (and/or an image thereof), state ID card (and/or an image thereof). The user management system 116 may further provide a mechanism for a user to link any financial information to the platform, including entering credit card numbers, banking information, cryptocurrency wallets (e.g., Coinbase® account), and the like. Upon receiving the requested information, the user management system 116 creates a new account for the user, including creating a new public address of the account corresponding to the user. Once the account is created, the user may begin participating in transactions on the platform 100.); and
storing, at a database, first entry information at a first entry associated with the first agreement, wherein the first entry information indicates the first user, the second user, the first agreement data, the financial account, or a combination thereof (Sliwka, [0118] – The distributed ledger 310 may store any suitable data relating to an item, a user, a seller, and the like. In embodiments, the distributed ledger 310 may store item-related data. Item-related data may include, but is not limited to, item identifiers, expiration dates of items, conditions or restrictions placed on the items, item descriptions, media content related to items (e.g., photographs, logos, videos, and the like), documentation of the item, customization options, available sizes, available colors, available materials, functionality options, ingredients, prices, special offers or discounts relating to the item, location information (e.g., where an item can be delivered/provided), hours available, owner/custodian data, reviews, item type, and the like. In embodiments, the distributed ledger 310 may store user data. User data may include, but is not limited to, identifying information (e.g., user ID, email address, name, and the like), public address, financial information (e.g., credit card information), transaction history, location data (e.g., a region of the user or country of the user), preferences, a wish list, subscriptions of the user, items belonging to the user, user connections or contacts, media content relating to the user (e.g., photos or videos of the user), an avatar of the user, and the like. In embodiments, the distributed ledger 310 may store merchant-related data. Merchant-related data may include, but is not limited to, identifying information (e.g., a name of the merchant, a merchant ID, and/or the like), contact information of the merchant, experience data, location data, hours available, reviews, media content (photo-graphs, videos, and the like), and/or any other suitable merchant-related data. A distributed ledger 310 may store additional and/or alternative data.).
Therefore, in light of the teachings of Sliwka, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the method of , Meng, motivation according to one KSR Exemplary Rationale where a known technique is used to improve similar methods and systems in the same way by provide an e-commerce platform with greater flexibility around all facets of a transaction including, but not limited to, purchase selection, payment, transfer
of possession, and location and timing of delivery.
Re: Claim 2, Meng discloses the method of claim 1, further comprising:
generating a smart contract based on the first agreement, wherein:
the database includes a blockchain ledger that stores the first entry; and the first entry includes the smart contract (Meng, page 6, lines 5 - 12 – In the embodiment of the invention. the borrower is a user of the digital assets on the chain owned by the pledge; the lender is given the digital assets on the chain of the borrower pledge, simultaneously provides financing money for the borrower, and appoints a repayment deadline with the borrower, and when the borrower does not repay the sufficient amount in the repayment deadline, the lender can pay the pledge assets. Based on the pledge financing transaction that the borrower and the lender have already agreed upon, they also agree upon the following transactions: the lender may use the pledge assets to pay the remaining debts when the borrower does not clear the ant ire debts to the lender according to the payment deadline. In order to Implement the pledge asset compensation and return transaction, a blockchain and an intelligent contract are Introduced in the embodiment. The Intelligent contract is distributed execution software which runs on a block chain shared account book and has the characteristics of automation, mandatory execution and credible safety. After the transaction is initiated, the intelligent contract can control the operations of compensation, return and the like of the pledge assets.);
at least a portion of the first entry is immutable (Meng, page 7, lines 57 - 62 - The intelligent contract execution process for generating the pledge return asset and the pledge liquidation asset by the pledge asset comprises the following steps: checking whether a first pledge asset subsequent transaction calling parameter contained in the first pledge asset compensation command meets pledge asset compensation triggering conditions specified in the intelligent contract or not by using an intelligent contract contained in pledge asset information; end if the specified pledge asset compensation triggering condition is met, spending the pledge asset, and generating the corresponding pledge return asset and pledge compensation asset according to the first pledge asset compensation command. And after the intelligent contract of the first pledge asset compensation command is executed, returning pledge assets paid by the borrower to the borrower, and compensating pledge assets not paid by the borrower to the borrower.);
the first agreement is further between the first user, the second user, and an entity associated with the institution server (Meng, page 9, lines 64 - 69 - The lender asset application terminal system can obtain the non-repayment amount of the pledged asset by inquiring repayment transaction information in the pledge asset information and the repayment due date, further obtain the repayment condition of the borrower on the pledged asset, and judge whether the borrower is full of a repayment based on the repayment condition; in the embodiment, when the unpaid amount is larger than 0, the borrower can be confirmed to be unpaid in the repay period; and if the borrower does not pay In the payment deadline, generating a first pledge asset compensation command according to pledge asset information, sign the first pledge asset compensation command by using the user private key of the lender, and sending the first pledge asset compensation command with the user private key signature of the lender to the asset account book system.);
the first input includes a first digital signature and the second input includes a second digital signature (Meng, page 8, lines 58 - 61 - step S403: the borrower asset application terminal system displays an on-chain asset query function interface to the borrower on the borrower terminal device, generates second repayment condition query request information according to query requirements input and/or selected by the borrower in the on-chain asset query function interface, and then sends the second repayment condition query request information with the borrower digital signature to a consensus ledger layer execution module of the asset ledger system.); and
obtaining the first agreement data includes receiving the first agreement data from the first device or generating the first agreement data (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card information, user biological identification code information or user Identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.).
Re: Claim 4, Meng in view of Sliwka discloses the method of claim 1, further comprising:
after verification of the first agreement, initiating formation of a second agreement associated with use of the financial account in association with the first agreement, the second agreement between the first user, the second user, and an entity associated with the institution server, wherein prior to verification of the second agreement, the financial account has a reserved status (Meng, page 2, lines 17 - 20 - the asset ledger system is further configured to; verifying the second repayment Inquiry request information with the borrower signature; after the verification is passed, determining second repayment condition query result information according to the pledge asset information, adding a signature to the repayment condition query result information, and returning the repayment condition query result information to the borrower asset application terminal system.);
verifying that the second agreement is complete (Meng, page 2, lines 21 - 22 - the borrower asset application terminal system is further configured to: and verifying the repayment condition Inquiry result information, and displaying the digital currency inquiry result information on the borrower chain to the borrower after the verification is passed.);
storing, at the database, second agreement data at the first entry, wherein the second agreement data is associated with the second agreement (Meng, page 8, lines 21 - 23 - The process of determining the first repayment condition query result information according to the pledge asset information may be: calculating the non-repayment amount of the pledged asset according to the repayment transaction information in the pledged asset information, and taking the non.-repayment amount of the pledged asset as a first repayment condition query result; the repayment transaction information may be stored In the form of a digital currency repayment list.); and
after verification of the second agreement, sending, to the institution server, a status change request to change the financial account from the reserved status to an active status (Sliwka, [0099] – In some embodiments, the user management system 116 creates new accounts for users. In these embodiments, a new user may access the platform 100 and may request a new account. In embodiments, the platform 100 may allow a user to link their account to an account of an external system (e.g., Google®, Facebook®, Twitter®, etc.). Additionally, or alternatively, a user can provide an email address and login. In embodiments, the user management system 116 may request a user to provide additional authenticating information, such as a home address or business address, a passport number (and/or image of the passport), driver's license number (and/or an image thereof), state ID card (and/or an image thereof). The user management system 116 may further provide a mechanism for a user to link any financial information to the platform, including entering credit card numbers, banking information, cryptocurrency wallets (e.g., Coinbase® account), and the like. Upon receiving the requested information, the user management system 116 creates a new account for the user, including creating a new public address of the account corresponding to the user. Once the account is created, the user may begin participating in transactions on the platform 100.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Re: Claim 5, Meng discloses the method of claim 4, further comprising:
generating a first version of the second agreement based on the first agreement, the financial account, or a combination thereof (Meng, page 4, lines 31 - 34 - the borrower asset application terminal system Is used for judging whether a borrower is sufficient for repayment according to the pledge asset information in the asset book system, generating a second pledge asset compensation commend containing pledge asset information according to the pledge asset information under the condition that the borrower is not sufficient for repayment, and sending the second pledge asset compensation command with a borrower signature to the asset book system.); and
sending, to each of the first user, the second user, and the entity, a request to sign the first version of the second agreement, wherein the verified second agreement is a second version of the second agreement that is signed by each of the first user, the second user, and the entity (Meng, page 2, lines 28 - 31 - the asset ledger system is used for executing an intelligent contract contained in the pledge asset information to verify the second pledge asset compensation command with the borrower signature, spending the pledge asset information after the verification is passed, and genera Ung pledge return asset information corresponding to the asset ledger address of the borrower and pledge compensation asset information corresponding to the asset ledger address of the lender; wherein the value amount corresponding to the amount of the pledge liquidation assets is equal to the amount of the un-repayment of the lender.).
Re: Claim 8, Meng discloses the method of claim 1, further comprising:
receiving, from the first device associated with the first user, first user information associated with the first user, wherein the first user information indicates:
a first bank account associated with the first user, and a name of the first user, a company associated with the first user, a birthday of the first user, a nationality of the first user, a government identification number associated with the first user, an email address associated with the first user, a phone number associate with the first user, a fax number associated with the first user, an address associated with the first user, or a combination thereof (Meng, page 6, lines 56 - 63- step S201: and the lender accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The asset application terminal system is system software which is installed in the terminal equipment and corresponds to the asset ledger system: a user may download and install asset application end system software from an asset hosting system by accessing the asset hosting system. The terminal device may be various electronic devices having a display screen and supporting web browsing, such as a mobile phone, a tablet computer, a desktop computer, and the like. The login identification mode can be a user name and password identification mode, a fingerprint identification mode, a face identification mode and the like, end the corresponding identification information can be: a user name and a password, or an identification code In a preset format corresponding to the user name. The identification code in the preset format maybe a password in the form of characters, or may be a biometric identification code, such as a fingerprint. facial information, iris information, etc. of the user.); and
storing, at the database, first bank account information that indicates the first bank account, a bank name, an account type, a holder name, or a combination thereof, and wherein the first agreement indicates that the second user owes the first user a payment amount (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system Identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key} and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card Information, user biological identification code information or user identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.).
Re: Claim 9, Meng discloses the method of claim 1, further comprising:
receiving, from the second device associated with the second user, second user information associated with the second user, wherein the second user information indicates a second bank account associated with the second user (Meng, page 5, lines 31 - 34 – The online pledge asset compensation method through on-line digital currency settlement according to the embodiment of the present invention includes: the borrower asset application terminal system judges whether the borrower is sufficient for repayment according to the pledge asset information in the asset book system, generates a second pledge asset compensation command containing pledge asset information according to the pledge asset information under the condition that the borrower is not sufficient for repayment, end sends the second pledge asset compensation command with borrower signature lo the asset book system;);
storing, at the database, second bank account information that indicates the second bank account, and wherein the first agreement indicates that the second user owes the first user a payment amount (Meng, page 4, lines 22 - 24 - generating second repayment condition query request information comprising borrower account information according to query requirements input and/or selected by the borrower in the asset query function interface on the chain; sending a second repayment condition query request message with the borrower signature to the asset account book system.);
receiving, from a third device associated with a third user, third user information associated with the third user, wherein the third user information indicates a third bank account associated with the third user (Meng, page 8, lines 53 – 56 - fig. 4 is a schematic view of the main flow of asset compensation by the chain pledge asset compensation system of the chain digital currency settlement according to the third embodiment of the present invention. As shown ln fig. 4, the main flow of asset compensation by the chain pledge asset compensation system in the third embodiment of the present invention, the steps S401 and S402 in the third embodiment ere the same as the steps S301 and S302 In the second embodiment, and will not be described again.);
storing, at the database, third bank account information that indicates the third bank account receiving, from the third device associated with the third user, a payment request associated with the first agreement, wherein the payment request includes document data, a request amount, or a combination thereof (Meng, page 3, lines 29 - 32 - At present, the blockchain technology is rapidly developed, and the blockchain is used as a decentralized novel distributed computing paradigm and provides technical support for the operation of various digital assets on a distributed network. The digital assets run on a distributed network of a blockchain, the global multi-node consensus accounting is carried out in a mode of sharing in account book without depend)ng on accounting of a specific third party or a central party, end a safety system of technical guarantee is realized through an encryption algorithm.);
sending, to a first user device associated with the first user, an approval request based on the payment request (Meng, page 10, lines 20 - 25 - the borrower asset application terminal system can obtain the non-repayment amount of the pledged asset by inquiring repayment transaction information in the pledged asset information on the repayment due date, further obtain the repayment condition of the borrower on the pledged asset, and judge whether the borrower Is full of the repayment condition or not.: in the embodiment, when the unpaid amount is larger than 0, the borrower can be confirmed to be unpaid in the repayment period; and if the borrower does not pay in the payment deadline, generating a second pledge asset compensation command according to pledge asset information, signing the second pledge asset compensation command by using the user private key of the borrower, and sending the second pledge asset compensation command with the user private key signature of the borrower to the asset account book system.);
receiving, from the first user device, an approval message responsive to the approval request (Meng, page 6, lines 50 - 53 - The meaning of 'cost' in "cost a message, generate corresponding B message can be understood as: and generating a corresponding B message according to the A message, marking the state of the A message as a spent stale, and establishing an incidence relation representing the expense with the 8 message. The meaning of 'cost' throughout can be understood as above.); and
updating the first entry to indicate that the third user is to receive a portion of the payment amount paid by the second user in accordance with the first agreement (Meng, page 8, lines 58 - 61 - step S403: the borrower asset application terminal system displays an on-chain asset query function interface to the borrower on the borrower terminal device, generates second repayment condition query request information according to query requirements input and/or selected by the borrower in the on-chain asset query function interface, and then sends the second repayment condition query request information with the borrower digital signature to a consensus ledger layer execution module of the asset ledger system.).
Re: Claim 15, Meng in view of Sliwka discloses the method of claim 1, further comprising:
identifying the financial account at the institution server, the financial account associated with the first agreement between the first user and the second user (Meng, page 6, lines 5 - 12 - In the embodiment of the invention. the borrower is a user of the digital assets on the chain owned by the pledge; the lender is given the digital assets on the chain of the borrower pledge, simultaneously provides financing money for the borrower, and appoints a repayment deadline with the borrower, and when the borrower does not repay the sufficient amount in the repayment deadline, the lender can pay the pledge assets. Based on the pledge financing transaction that the borrower and the lender have already agreed upon, they also agree upon the following transactions: the lender may use the pledge assets to pay the remaining debts when the borrower does not clear the ant ire debts to the lender according to the payment deadline. In order to implement the pledge asset compensation and return transaction, a blockchain and an intelligent contract are introduced in the embodiment. The intelligent contract is distributed execution software which runs on a blockchain shared account book and has the characteristics of automation, mandatory execution and credible safety. After the transaction is initiated, the intelligent contract can control the operations of compensation, return and the like of the pledge assets.);
determining, based on the first entry in the database, one or more disbursements from the financial account, the one or more disbursements including a first disbursement to a first account associated with first user, wherein the first entry is associated with the first agreement (Sliwka, [00232] – In embodiments, supporting data 2056 may be documentation and data that is provided in support of a task performed or other events that occur in connection with decentralized loan processes and/or the participants of the decentralized loan processes. As will be discussed, supporting data 2056 may include authentication reports and sup-porting photographs, videos, scans or the like; appraisal reports and supporting photographs, videos, scans or the like; safekeeping reports and supporting photographs, videos, scans or the like; loan negotiation records that indicate negotiation events during negotiation of a loan contract; disbursement records that correspond to disbursement events by a lender to the borrower; repayment records that indicate payment events by the lender; default records that indicate default events; and/or other suitable data.);
sending, to the institution server, a request to perform the one or more disbursements (Meng, page 6, lines 5 - 12 - In the embodiment of the invention, the borrower is a user of the digital assets on the chain owned by the pledge; the lender is given the digital assets on the chain of the borrower pledge, simultaneously provides financing money for the borrower, and appoints a repayment deadline with the borrower, and when the borrower does not repay the sufficient amount in the repayment deadline, the lender can pay the pledge assets. Based on the pledge financing transaction that the borrower and the lender have already agreed upon, they also agree upon the following transactions: the lender may use the pledge assets to per the remaining debts when the borrower does not clear the ant ire debts to the lender according to the payment deadline. In order to implement the pledge asset compensation and return transaction, a blockchain and an intelligent contract are introduced in the embodiment. The intelligent contract is distributed execution software which runs on a blockchain shared account book and has the characteristics of automation, mandatory execution and credible safety. After the transaction is initiated, the intelligent contract can control the operations of compensation, return and the like of the pledge assets.);
sending a notification that indicates the first disbursement to the first account associated with the first user (Meng, page 3, lines 29 - 32 - At present, the blockchain technology is rapidly developed, and the blockchain is used as a decentralized novel distributed computing paradigm and provides technical support for the operation of various digital assets on a distributed network. The digital assets run on a distributed network of a blockchain, the global multi-node consensus accounting is carried out in a mode of sharing in account book without depend)ng on accounting of a specific third party or a central party, end a safety system of technical guarantee is realized through an encryption algorithm.);
receiving, from the institution server, a transfer request notification of a transfer request associated with the second user (Meng, page 6, lines 32 - 37 - The lender asset application terminal system can actively obtain a repayment condition query result by querying the pledge asset information on the repayment due date, and then judge whether the borrower is sufficient for repayment or not based on the repayment condition query result and the repayment amount, wherein the repayment amount is the on-chain digital money which is transferred to the lender when the borrower performs the sufficient repayment aiming at the pledge asset; and if the borrower does not pay in the payment deadline, generating a first pledge asset compensation command according to pledge asset information, signing the first pledge asset compensation command by using the private key of the lender, end sending the first pledge asset compensation command with the private key signature of the lender to the asset account book system.); and
receiving, from the institution server, a transfer completion notification that indicates completion of a transfer to the financial account based on the transfer request (Meng, page 7, lines 40 - 48 - The lender asset application terminal system can actively obtain a repayment condition query result by querying the pledge asset information on the repayment due date, and then judge whether the borrower is sufficient for repayment or not based on the repayment condition query result and the repayment amount, wherein the repayment amount is the on-chain digital money which is transferred to the lender when the borrower performs the sufficient repayment aiming at the pledge asset; and if the borrower does not pay on the payment deadline, generating a first pledge asset compensation command according to pledge asset information, signing the first pledge asset compensation command by using the private key of the lender, end sending the first pledge asset compensation command with the private key signature of the lender to the asset account book system.);
the transfer completion notification is received prior to delivery, from the first user to the second user, of an object associated with the first agreement (Meng, page 7, lines 57 - 62 - The intelligent contract execution process for generating the pledge return asset and the pledge liquidation asset by the pledge asset comprises the following steps: checking whether a first pledge asset subsequent transaction calling parameter contained in the first pledge asset compensation command meets pledge asset compensation triggering conditions specified in the intelligent contract or not by using an intelligent contract contained in pledge asset information; end if the specified pledge asset compensation triggering condition is met, spending the pledge asset, and generating the corresponding pledge return asset and pledge compensation asset according to the first pledge asset compensation command. And after the intelligent contract of the first pledge asset compensation command is executed, returning pledge assets paid by the borrower to the borrower, and compensating pledge assets not paid by the borrower to the borrower.); and
determining the one or more disbursements is performed based on identification of a change in status of the object indicated by the first entry (Meng, page 7, lines 14 - 28 - Step S203: and the lender asset application terminal system generates a first pledge asset compensation command according to the pledge asset Information under the condition that the borrower does not pay enough, and then sends the first pledge asset compensation command with the lender signature to an intelligent contract layer execution module of the asset book system. The pledge asset compensation command is a compensation commend for pledge asset information, which indicates that the borrower can sand the pledge asset information to the Intelligent contract layer execution module, and the command is used for triggering the execution of an intelligent contract contained in the pledge asset information {i.e. the pledge asset is changed into an intelligent contract of pledge return asset information end pledge compensation asset information. In an alternative embodiment, the pledge asset redemption instructions Include: the system comprises the following steps of pledge asset information, pledge asset subsequent transaction calling parameters, pledge return asset information, pledge clearing asset information and the like. The pledge asset information refers to the information of the chain assets pledged by the borrower to the lender, and my include; the method comprises the following steps of {1) lending an asset account book address of a lender, a pledge asset index identification, an intelligent contract for controlling subsequent transaction of pledge assets, pledge asset quantity end repayment transaction information; the pledge asset subsequent transaction calling parameter refers to a parameter which needs to be called when an intelligent contract contained in pledge asset information is executed. the parameter coin be a pledge repayment state of pledge assets at a preset repayment due date, and the repayment due date can be set in the intelligent contract contained in pledge asset information; the pledge returned asset information refers to the digital assets belonging to the borrower and generated by the borrower according to the returned pledge assets which are paid after executing the intelligent contract contained in the pledge asset Information; the pledge liquidating asset information is digital assets which are generated by the borrower according to the unpaid amount and used for inquinating the debt of the borrower and belong to the lender after the intelligent contract contained in the pledge asset information is executed.).
Re: Claim 19, Meng discloses the method of claim 1, further comprising:
receiving, from the institution server, an indicator associated with the financial account, wherein the indicator includes an account number of the financial account, a routing number, a quick response (QR) code, or a combination thereof (Meng, page 6, lines 56 - 63- step S201: and the lender accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The asset application terminal system is system software which is installed in the terminal equipment and corresponds to the asset ledger system: a user may download and install asset application and system software from an asset hosting system by accessing the asset hosting system. The terminal device may be various electronic devices having a display screen and supporting web browsing, such as a mobile phone, a tablet computer, a desktop computer, and the like. The login identification mode can be a user name and password identification mode, a fingerprint identification mode, a face Identification mode and the like, end the corresponding identification information can be: a user name and a password, or an identification code In a preset format corresponding to the user name. The identification code in the preset format maybe a password in the form of characters, or may be a biometric identification code, such as a fingerprint. facial information, iris information, etc. of the user.);
sending the indicator to the second device associated with the second user (Meng, page 8, lines 4 - 6 - Step 5302: and the lander accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The implementation principle of this step is the same as step S201.); and
storing the indicator at the first entry (Meng, page 8, lines 1 - 3 - information according to a preset login identification mode and logs in the borrower asset application terminal system. This step is the same as the implementation of step 5201. And after the borrower asset application terminal system identifies the user, determining that the borrower is a user locally associated with a private key of the specific user. The borrower asset application terminal system includes a local security module in which a user private key and a user public key are stored.).
Re: Claim 25, Meng in view of Sliwka discloses the method of claim 1, further comprising:
sending, to a core server, a first indicator that indicates first user information associated with the first user (Meng, page 8, lines 4 - 6 - Step 5302: and the lander accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The implementation principle of this step is the same as step S201.);
sending, to the core server, a request to verify the first user (Meng, page 8, lines 16 - 20 - Step 5304: and the common identification ledger layer execution module of the asset ledger system verifies the first repayment condition query request information, determines first repayment condition query result information according to the pledge asset information after the first repayment condition query request information passes the verification, adds a signature to the first repayment condition query result information and returns the first repayment condition query result information to the lender asset application terminal system. Wherein the verifying the content comprises: and verifying the signature of the first repayment condition inquiry request information.);
receiving, from the core server, an indicator that indicates the first user is verified sending, to the core server, a request to create the financial account associated with the first agreement (Sliwka, [0222] – FIG. 17 depicts a flowchart showing a technique 1700 for facilitating user acquisition according to some embodiments of the present disclosure. At 1702, a referral code is generated, which corresponds to a user of the tokenization platform. The referral code may be generated by a processing system of the tokenization platform. At 1704, an instance of a smart contract is generated that corresponds to the user of the tokenization platform. The instance of the smart contract may be generated by the tokenization platform. The instance of the smart contract indicates an incentive to be provided to the user when the user successfully refers the tokenization platform. A 1706, the instance of the smart contract is deployed by the processing system. At 1708, a request to create a new account is received from a new user by the processing system. The request includes the referral code of the user. At 1710, the new account is created for the new user by the processing system. At 1712, the processing system provides a notification of the new account to the instance of the smart contract corresponding to the user. The smart contract then facilitates the transfer of a token representing the incentive in response to the notification.);
receiving, from the core server, an identifier associated with the financial account (Sliwka, [0226] - FIG. 19 depicts a flowchart showing a technique 1900 for video-game integration according to some embodiments of the present disclosure. At 1902, an inventory of available tokens is maintained. The available tokens are available for integration in a video game. Each token in the inventory of tokens represents a respective item. At 1904, a token request for a digital token is received by the processing system. The digital token is from an instance of the video game via an APL At 1906, the processing system selects the digital token from the inventory of available tokens based on the token request. At 1908, an indicator of the token is provided to the instance of the video game by the processing system. At 1910, the processing system receives a transaction request from the instance of the video game. The transaction request is configured to request a transfer of the token provided to the instance of the video game to an account of a user of the instance of the video game. At 1912, the ledger is updated to reflect that the user is the owner of the token.); and
sending the identifier to a device associated with the second user, the database for storage at the first entry, or a combination thereof (Meng, page 6, lines 56 - 63- step S201: and the lender accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The asset application terminal system is system software which is installed in the terminal equipment and corresponds to the asset ledger system: a user may download and install asset application end system software from an asset hosting system by accessing the asset hosting system. The terminal device may be various electronic devices having a display screen and supporting web browsing, such as a mobile phone, a tablet computer, a desktop computer, and the like. The login identification mode can be a user name and password identification mode, a fingerprint identification mode, a face Identification mode and the like, end the corresponding identification information can be: a user name and a password, or an identification code In a preset format corresponding to the user name. The identification code in the preset format maybe a password in the form of characters, or may be a biometric identification code, such as a fingerprint. facial information, iris information, etc. of the user.). The rationale for support of motivation, obviousness and reason to combine see claim 1 above.
Re: Claim 27, Meng discloses the method of claim 1, further comprising:
receiving, from the first device or the second device, a status request associated with the first agreement (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.);
accessing the database to obtain first entry information based on the first entry (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system Identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key} and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card Information, user biological identification code information or user identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.);
obtaining status information based on the first entry information, wherein the status information indicates an amount due associated with the first agreement, one or more distribution amounts, one or more fee amounts, or a combination thereof (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.); and
sending the status information to the first device or the second device (Meng, page 3, lines 17 - 19 - the borrower asset application terminal system judges whether the borrower is sufficient for repayment according to the pledge asset information In the asset book system, generates a second pledge asset compensation command containing pledge asset information according to the pledge asset information under the condition that the borrower is not sufficient for repayment, and sends the second pledge asset compensation command with borrower signature to the asset book system.).
Re: Claim 30, Meng discloses the method of claim 1, further comprising:
receiving sensor data associated with an object to be provided from the first user to the second user in accordance with the first agreement (Meng, page 4, lines 22 - 24 - generating second repayment condition query request information comprising borrower account information according to query requirements input and/or selected by the borrower in the asset query function interface on the chain; sending a second repayment condition query request message with the borrower signature to the asset account book system;);
storing, based on the sensor data, a status to the first entry (Meng, page 3, lines 17 - 19 - the borrower asset application terminal system judges whether the borrower is sufficient for repayment according to the pledge asset information In the asset book system, generates a second pledge asset compensation command containing pledge asset information according to the pledge asset information under the condition that the borrower is not sufficient for repayment, and sends the second pledge asset compensation command with borrower signature to the asset book system.); and
determining, based on the status, the sensor data, or a combination thereof, whether to indicate one or more distributions associated with the financial account (Meng, page 4, lines 25 - 27 - the asset ledger system is further configured to: verifying the second repayment inquiry request information with the borrower signature; after the verification is passed, determining repayment condition query result information according to the pledge asset intonation, adding e signature to the repayment condition query result information, and returning the repayment condition query result information to the borrower asset application terminal system.).
Re: Claim 45, claim 45 is a system claim corresponding to method claim 1. Therefore, claim 45 is analyzed and rejected as previously discussed with respect to claim 1.
Re: Claim 46, Meng in view of Sliwka discloses the system of claim 45, further comprising:
a core server communicatively coupled to the clearance server via a network, the core server configured to:
identify the financial account at the institution server, wherein the first user is a beneficiary of the financial account, and wherein an entity associated with the core server has agency over the financial account (Sliwka, [0204] – In embodiments, tokens may be tokenized (e.g., when generating a token representing an amount of funds). For example, the item information may be funds within the platform 100 or from third-party sources. The tokenized token can be generated in response to validation of receipt of the funds, and the funds may be held from transaction by the user. In some embodiments, the funds remain publicly attributed to the user and the ledger is updated with a hold or lien recorded against the funds to prevent user transaction of the tokenized funds without approval by the platform 100. In some embodiments, the ledger is updated to reflect a transfer of the funds from the user to the platform 100. Beneficially, transferred funds may be tradeable by the platform 100 (e.g., for depositing or investment with third parties), and the tokenized tokens are redeemable for an equivalent amount of the original funds even if the redeemed funds are not the originally tokenized funds such that the tokenized token may be used by transactions within the platform 100 while the deposited funds may participate in economic transactions between the platform 100 and third parties.);
identify a transfer made to the financial account (Sliwka, [0232] – In embodiments, supporting data 2056 may be documentation and data that is provided in support of a task performed or other events that occur in connection with decentralized loan processes and/or the participants of the decentralized loan processes. As will be discussed, supporting data 2056 may include authentication reports and sup-porting photographs, videos, scans or the like; appraisal reports and supporting photographs, videos, scans or the like; safekeeping reports and supporting photographs, videos, scans or the like; loan negotiation records that indicate negotiation events during negotiation of a loan contract; disbursement records that correspond to disbursement events by a lender to the borrower; repayment records that indicate payment events by the lender; default records that indicate default events; and/or other suitable data.);
after identification of the transfer, send, to the institution server, a request to perform one or more disbursements from the financial account, the one or more disbursements determined based on a first entry in a database, wherein the first entry is associated with the first agreement and indicates the first user, the second user, the first agreement data, the financial account, or a combination thereof (Sliwka, [0232] – In embodiments, supporting data 2056 may be documentation and data that is provided in support of a task performed or other events that occur in connection with decentralized loan processes and/or the participants of the decentralized loan processes. As will be discussed, supporting data 2056 may include authentication reports and sup-porting photographs, videos, scans or the like; appraisal reports and supporting photographs, videos, scans or the like; safekeeping reports and supporting photographs, videos, scans or the like; loan negotiation records that indicate negotiation events during negotiation of a loan contract; disbursement records that correspond to disbursement events by a lender to the borrower; repayment records that indicate payment events by the lender; default records that indicate default events; and/or other suitable data.); and
send a notification that indicates a first disbursement to a first account associated with the first user (Sliwka, [0232] – In embodiments, supporting data 2056 may be documentation and data that is provided in support of a task performed or other events that occur in connection with decentralized loan processes and/or the participants of the decentralized loan processes. As will be discussed, supporting data 2056 may include authentication reports and sup-porting photographs, videos, scans or the like; appraisal reports and supporting photographs, videos, scans or the like; safekeeping reports and supporting photographs, videos, scans or the like; loan negotiation records that indicate negotiation events during negotiation of a loan contract; disbursement records that correspond to disbursement events by a lender to the borrower; repayment records that indicate payment events by the lender; default records that indicate default events; and/or other suitable data.). The rationale for support of motivation, obviousness and reason to combine see claim 45 above.
Re: Claim 70, Meng in view of Sliwka discloses the system of claim 45,wherein:
the request to create the financial account associated with the first agreement is sent to the institution server via a core server (Sliwka, [0099] – In some embodiments, the user management system 116 creates new accounts for users. In these embodiments, a new user may access the platform 100 and may request a new account. In embodiments, the platform 100 may allow a user to link their account to an account of an external system (e.g., Google®, Facebook®, Twitter®, etc.). Additionally, or alternatively, a user can provide an email address and login. In embodiments, the user management system 116 may request a user to provide additional authenticating information, such as a home address or business address, a passport number (and/or image of the passport), driver's license number (and/or an image thereof), state ID card (and/or an image thereof). The user management system 116 may further provide a mechanism for a user to link any financial information to the platform, including entering credit card numbers, banking information, cryptocurrency wallets (e.g., Coinbase® account), and the like. Upon receiving the requested information, the user management system 116 creates a new account for the user, including creating a new public address of the account corresponding to the user. Once the account is created, the user may begin participating in transactions on the platform 100.); and
the clearance server is further configured to:
sending, to a core server, a request to verify the first user, wherein the request includes first user information associated with the first user (Meng, page 2, lines 17 - 20 - the asset ledger system is further configured to; verifying the second repayment Inquiry request information with the borrower signature; after the verification is passed, determining second repayment condition query result information according to the pledge asset information, adding a signature to the repayment condition query result information, and returning the repayment condition query result information to the borrower asset application terminal system.);
receiving, from the core server, an indicator that indicates the first user is verified (Sliwka, [0222] – FIG. 17 depicts a flowchart showing a technique 1700 for facilitating user acquisition according to some embodiments of the present disclosure. At 1702, a referral code is generated, which corresponds to a user of the tokenization platform. The referral code may be generated by a processing system of the tokenization platform. At 1704, an instance of a smart contract is generated that corresponds to the user of the tokenization platform. The instance of the smart contract may be generated by the tokenization platform. The instance of the smart contract indicates an incentive to be provided to the user when the user successfully refers the tokenization platform. At 1706, the instance of the smart contract is deployed by the processing system. At 1708, a request to create a new account is received from a new user by the processing system. The request includes the referral code of the user. At 1710, the new account is created for the new user by the processing system. At 1712, the processing system provides a notification of the new account to the instance of the smart contract corresponding to the user. The smart contract then facilitates the transfer of a token representing the incentive in response to the notification.); and
receive, from the core server, a notification that indicates a first disbursement from the financial account to a first account associated with the first user (Meng, page 3, lines 29 - 32 - At present, the blockchain technology is rapidly developed, and the blockchain is used as a decentralized novel distributed computing paradigm and provides technical support for the operation of various digital assets on a distributed network. The digital assets run on a distributed network of a blockchain, the global multi-node consensus accounting is carried out in a mode of sharing in account book without depend)ng on accounting of a specific third party or a central party, end a safety system of technical guarantee is realized through an encryption algorithm.). The rationale for support of motivation, obviousness and reason to combine see claim 45 above.
Re: Claim 75, Meng discloses the system of claim 45,wherein the clearance server is further configured to:
receive, from the first device or the second device, a status request associated with the first agreement (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.);
access the database to obtain first entry information based on the first entry (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system Identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key} and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card Information, user biological identification code information or user identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.);
in response to receiving the status request, send, to a core server, a status information request (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.);
receive status information from the core server in response to the status information request, wherein the status information is based on the first entry information, and wherein the status information indicates an amount due associated with the first agreement, one or more distribution amounts, one or more fee amounts, or a combination thereof (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.); and
send the status information to the first device or the second device (Meng, page 3, lines 17 - 19 - the borrower asset application terminal system judges whether the borrower is sufficient for repayment according to the pledge asset information In the asset book system, generates a second pledge asset compensation command containing pledge asset information according to the pledge asset information under the condition that the borrower is not sufficient for repayment, and sends the second pledge asset compensation command with borrower signature to the asset book system.).
Re: Claim 79, Claim 79 is an apparatus claim corresponding to method claim 1 and system claim 45. Therefore, claim 79 is analyzed and rejected as previously discussed with respect to claims 1 and 45.
Re: Claim 83, Meng discloses the server of claim 79, wherein the processor is further configured to:
access the database to obtain at least a portion of entry information, wherein the entry information indicates one or more payment amounts, one or more fees, or a combination thereof, and wherein the transfer is performed from a second account associated with the second user to the financial account (Meng, page 7, lines 9 - 13 - Step S202: and the !ender asset application terminal system judge a whether the borrower is sufficient for repayment according to 1he pledge asset information. The lender asset application terminal system can calculate the non-repayment amount of the pledge asset according to the repayment transaction information in the pledge asset information on the repayment due date, if the non-repayment amount of the pledge asset Is the borrower is proved to have sufficient repayment, and the pledge asset can be directly returned to the borrower; if the none payment amount of the pledge asset is more than the borrower is Indicated to be not fully repayed within the repayment period.); and
identify, based on the entry information, a third user associated with the first agreement, wherein the one or more disbursements include a second disbursement to a third account associated with the third user (Meng, page 6, lines 5 - 12 - In the embodiment of the invention. the borrower is a user of the digital assets on the chain owned by the pledge; the lender is given the digital assets on the chain of the borrower pledge, simultaneously provides financing money for the borrower, and appoints a repayment deadline with the borrower, and when the borrower does not repay the sufficient amount in the repayment deadline, the lender can pay the pledge assets. Based on the pledge financing transaction that the borrower and the lender have already agreed upon, they also agree upon the following transactions: the lender may use the pledge assets to pay the remaining debts when the borrower does not clear the ant ire debts to the lender according to the payment deadline. In order to implement the pledge asset compensation and return transaction, a blockchain and an intelligent contract are introduced in the embodiment. The intelligent contract is distributed execution software which runs on a blockchain shared account book and has the characteristics of automation, mandatory execution and credible safety. After the transaction is initiated, the intelligent contract can control the operations of compensation, return and the like of the pledge assets.).
Re: Claim 85, Meng in view of Sliwka discloses the server of claim 83, wherein the processor is further configured to:
access the database to obtain at least the portion of the entry information, wherein the entry information indicates one or more payment amounts and one or more fees, and wherein the transfer is performed from a second account associated with the second user to the financial account (Meng, page 6, lines 50 - 53 - The meaning of 'cost' in "cost a message, generate corresponding B message can be understood as: and generating a corresponding B message according to the A message, marking the state of the A message as a spent stale, and establishing an incidence relation representing the expense with the 8 message. The meaning of 'cost' throughout can be understood as above.); and
determine, based on the entry information, a fee associated with the first agreement, wherein the fee includes a service fee, a regulatory fee, or a combination thereof, and wherein the one or more disbursements include a third disbursement to a fourth account associated with an entity associated with a clearance server, the server, or the institution server, and wherein the third disbursement is based on the fee (Sliwka, [0286] – At 2502, an instance of a loan smart contract 2034 may receive the loan agreement terms and may establish a repayment schedule in accordance with the loan agreement terms. In some scenarios, the loan smart contract 2034 may receive the loan agreement terms from a computing system (e.g., the tokenization platform) that facilitated the negotiation of the loan agreement. The loan agreement terms may include a loan amount, a loan term, a loan repayment amount, an interest rate, late fee penalties, default condition definitions, and the like. In embodiments, the loan smart contract instance may determine the repayment schedule based on the repayment amount and the loan term. The loan smart contract instance may determine the repayment sched-ule such that the payments are equally distributed over the loan term. The loan smart contract instance may determine the repayment schedule in any other suitable manner.). The rationale for support of motivation, obviousness and reason to combine see claim 79 above.
Re: Claim 88, Meng in view of Sliwka discloses the server of claim 79, wherein the processor is further configured to:
receive, from a clearance server, a first indicator that indicates first user information associated with the first user (Meng, page 2, lines 17 - 20 - the asset ledger system is further configured to; verifying the second repayment Inquiry request information with the borrower signature; after the verification is passed, determining second repayment condition query result information according to the pledge asset information, adding a signature to the repayment condition query result information, and returning the repayment condition query result information to the borrower asset application terminal system.);
receive, from the clearance server, a request to create the financial account associated with the first agreement (Sliwka, [0099] – In some embodiments, the user management system 116 creates new accounts for users. In these embodiments, a new user may access the platform 100 and may request a new account. In embodiments, the platform 100 may allow a user to link their account to an account of an external system (e.g., Google®, Facebook®, Twitter®, etc.). Additionally, or alternatively, a user can provide an email address and login. In embodiments, the user management system 116 may request a user to provide additional authenticating information, such as a home address or business address, a passport number (and/or image of the passport), driver's license number (and/or an image thereof), state ID card (and/or an image thereof). The user management system 116 may further provide a mechanism for a user to link any financial information to the platform, including entering credit card numbers, banking information, cryptocurrency wallets (e.g., Coinbase® account), and the like. Upon receiving the requested information, the user management system 116 creates a new account for the user, including creating a new public address of the account corresponding to the user. Once the account is created, the user may begin participating in transactions on the platform 100.);
send, to the institution server, an account creation request, wherein the account creation request is sent via an application program interface (API) of the institution server (Sliwka, [0093] – In embodiments, the platform 100 includes an API system 106 that manages one or more application programming interfaces (APIs) of the platform, so as to expose the APIs to one or more related applications (e.g., native and/or web applications provided by the platform 100 provider), third party systems that are supported by or otherwise interact with the platform 100, and smart contracts that are configured to interface with the platform 100. The API system 106 may expose one or more APIs, such that the API system 106 may receive API calls from requesting devices or systems and/or may push data to subscribing devices or systems. The API system 106 may implement any suitable types of APIs, including REST, SOAP, and the like. In embodiments, the API system 106 may include a smart contract API that allows smart contracts to interface with the platform, a utility API, a merchant API that allows merchants to create tokens corresponding to virtual representation of items, and any other suitable APIs. In embodiments, the platform 100 may implement a micro services architecture such that services may be accessed by clients, such as by APIs and/or software development kits (SDKs). The services abstract away the complexities of blockchain creation, object handling, ownership transfers, data integration, identity management, and the like, so that platform users can easily build, deliver and/or consume platform capabilities. In embodiments, SDK types include, but are not limited to: an Android SDK, an iOS SDK, a Windows SDK, a JavaScript SDK, a PHP SDK, a Python SDK, a Swift SDK, a Ruby SDK, and the like.);
receive, from the institution server, an identifier associated with the financial account, wherein the identifier associated with the financial account includes an account number, a routing number, a bank name, a beneficiary name, a quick response (QR) code, or a combination thereof (Meng, page 6, lines 56 - 63- step S201: and the lender accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The asset application terminal system is system software which is installed in the terminal equipment and corresponds to the asset ledger system: a user may download and install asset application and system software from an asset hosting system by accessing the asset hosting system. The terminal device may be various electronic devices having a display screen and supporting web browsing, such as a mobile phone, a tablet computer, a desktop computer, and the like. The login identification mode can be a user name and password identification mode, a fingerprint identification mode, a face Identification mode and the like, end the corresponding identification information can be: a user name and a password, or an identification code In a preset format corresponding to the user’s name. The identification code in the preset format maybe a password in the form of characters, or may be a biometric identification code, such as a fingerprint. facial information, iris information, etc. of the user);
send, to the clearance server, a device associated with the second user, the database for storage at the first entry, or a combination thereof, the identifier (Meng, page 6, lines 56 - 63- step S201: and the lender accesses the lender asset application terminal system installed on the lender terminal equipment, submits the identification information according to a preset login identification mode and logs in the lender asset application terminal system. The asset application terminal system is system software which is installed in the terminal equipment and corresponds to the asset ledger system: a user may download and install asset application end system software from an asset hosting system by accessing the asset hosting system. The terminal device may be various electronic devices having a display screen and supporting web browsing, such as a mobile phone, a tablet computer, a desktop computer, and the like. The login identification mode can be a user name and password identification mode, a fingerprint identification mode, a face Identification mode and the like, end the corresponding identification information can be: a user name and a password, or an identification code In a preset format corresponding to the user name. The identification code in the preset format maybe a password in the form of characters, or may be a biometric identification code, such as a fingerprint. facial information, iris information, etc. of the user.);
obtain, from the institution server, a confirmation of performance of the one or more disbursements (Meng, page 9, lines 64 - 69 - The lender asset application terminal system can obtain the non-repayment amount of the pledged asset by inquiring repayment transacting information in the pledged asset information on the repayment due date, further obtain the repayment condition of the borrower on the pledged asset, and judge whether the borrower is full of the repayment based on the repayment condition; in the embodiment, when the unpaid amount Is larger than 0, the borrower can be confirmed to be unpaid in the repayment period; and if the borrower does not pay In the payment deadline, generating a first pledge asset compensation command according to pledge asset Information, signing the first pledge asset compensation command by using the user private key of the lender, and sending the first pledge asset compensation command with the user private key signature of the lender to the asset account book system.); and
send, to the institution server and based on the confirmation, a request to close the financial account (Meng, page 3, lines 18 - 19 - the interactive capability of the operation under the chain is lacked, all the operations can only be completed on the closed chain, the process of repayment on the chain and returning of the pledge assets to the chain cannot be supported, and the transaction risk of the whole process cannot be controlled.). The rationale for support of motivation, obviousness and reason to combine see claim 79 above.
Re: Claim 91, Meng discloses the server of claim 79, wherein the processor is further configured to:
receive, from a clearance server, a request to verify the first user, wherein the request includes first user information associated with the first user (Meng, page 8, lines 16 - 20 - Step 5304: and the common identification ledger layer execution module of the asset ledger system verifies the first repayment condition query request information, determines first repayment condition query result information according to the pledge asset information after the first repayment condition query request information passes the verification, adds a signature to the first repayment condition query result information and returns the first repayment condition query result information to the lender asset application terminal system. Wherein the verifying the content comprises: and verifying the signature of the first repayment condition inquiry request information.);
send, to the institution server, the first user information (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system Identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key} and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card Information, user biological identification code information or user identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.);
receive, from the institution server and based on the first user information, a verification response that indicates that the first user is verified (Meng, page 3, lines 12 - 15 - the asset ledger system executes an intelligent contract contained in the pledge asset information to verify the first pledge asset compensation command with the lender signature, and after the verification is passed, costs the pledge asset information and generates pledge return asset information corresponding to the borrower asset ledger address and pledge compensation asset information corresponding to the lender asset pledger address; wherein the value amount corresponding to the amount of the pledge liquidation assets ls equal to the amount of the un-repayment of the lender.);
send, to the clearance server, an indicator that indicates the first user is verified (Meng, page 8, lines 16 - 20 - Step 5304: and the common identification ledger layer execution module of the asset ledger system verifies the first repayment condition query request information, determines first repayment condition query result information according to the pledge asset information after the first repayment condition query request information passes the verification, adds a signature to the first repayment condition query result information and returns the first repayment condition query result information to the lender asset application terminal system. Wherein the verifying the content comprises: and verifying the signature of the first repayment condition inquiry request information.);
receive, from the clearance server, a status request associated with the first agreement (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.);
access the database to obtain entry information based on the first entry ; (Meng, page 6, lines 64 - 69 - And after the lender asset application terminal system Identifies the user, determining that the lender is the user locally associated with the private key of the specific user. The lender asset application terminal system includes a local security module in which a user private key and a user public key are stored. And the user public key} and the user private key are generated by the asset application terminal system locally by adopting an asymmetric encryption algorithm. The user private key can be used for signing data information such as user identity information, user bank card Information, user biological identification code information or user identity certificate and the like, and can also be used for signing digital asset information in subsequent asset transaction or financing process so as to confirm ownership of transaction; the user public key can be used for correspondingly verifying the data information signed by the user private key.)
generate status information based on the entry information, wherein the status information indicates an amount due associated with the first agreement, one or more distribution amounts, one or more fee amounts, or a combination thereof (Meng, page 6, lines 19 - 25 - The borrower performs on-chain digital currency repayment operation on the pledge assets, and updates repayment transaction information during each digital currency transfer into pledge asset information of the asset account book system; when the preset repayment due date is reached, but the borrower does not clear all the debts to the lender on time, the lender and/or the borrower can trigger an intelligent contract in the pledge asset information, a pledge asset cler1ng instruction is sent to the asset book system, the asset booking stem executes the indigent contract contained in the pledge asset clearing instruction, the pledge assets which are paid by the borrower are returned to the borrower, and the pledge assets which are not paid by the borrower are cleared and given to the borrower. In the implementation p1ocess, the transaction process of the two transaction parties (namely the borrower and the lender) is controlled through the intelligent contract, the transaction is safe and reliable, and the transaction risk Is prevented.); and
send the status information to the clearance server (Meng, page 3, lines 17 - 19 - the borrower asset application terminal system judges whether the borrower is sufficient for repayment according to the pledge asset information In the asset book system, generates a second pledge asset compensation command containing pledge asset information according to the pledge asset information under the condition that the borrower is not sufficient for repayment, and sends the second pledge asset compensation command with borrower signature to the asset book system.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN H. HOLLY whose telephone number is (571)270-3461. The examiner can normally be reached on MON. - FRI 10 AM - 8 PM.
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, MATTHEW S. GART can be reached on 571-272-3955. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/John H. Holly/Primary Examiner, Art Unit 3696
Prosecution Insights