DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
1. Applicant's arguments filed 11/20/2025 with respect to the rejection(s) of claim(s) 1, 3, 5, 7-8, 10-14, 16 and 18-25 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
Status of Claims
This is the office action on the merits in response to the application filed on 11/20/2025. Claims 1, 3, 5, 7-8, 10-14, 16 and 18-25 are currently pending and have been examined.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
5. Claims 1, 3-5, 7-14, and 16-23 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ortiz et al. (US 20210117962 A1), in view of Swamidurai et al. (US 20190311392 A1), in view of Gutierrez-Sheris et al. (US 20200396065 A1), in view of Black et al. (US 20200051072 A1), and further in view of Harrison et al. (US 20200034869 A1).
6. Regarding claim 1, Ortiz discloses a method of processing an information, applied to a blockchain network, the method comprising:
verifying a transaction request in response to the transaction request being received, wherein the transaction request comprises a transaction information and an incentive information for the transaction information, the transaction information comprises an information of a digital asset that needs to be issued to a blockchain or an information of a digital asset that needs to be transferred, (Para. 0006, the interface layer adapted for receiving electronic instructions at payment transaction devices operatively linked to the corresponding node computing device, the electronic instructions including at least data transmissions representative of an electronic transaction; wherein the interface layer is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens stored in a digital wallet linked to a user profile… wherein the interface layer is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens stored in a digital wallet linked to a user profile, the one or more control commands adapted to interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation through the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices, the propagation updating each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.)
the transaction information further comprises a signature of a transaction request account and a public key of the transaction request account, and the public key is configured to decrypt the signature; encrypting and storing the transaction information on the blockchain in response to the transaction request being verified successfully, so as to obtain an updated blockchain, wherein the storing is performed by a consensus node in the blockchain network;
updating a first existing incentive point according to the incentive information, so as to obtain an updated incentive point, wherein the first existing incentive point is an existing incentive point of the consensus node; (Para. 0008, In accordance with another aspect, the system the control command generator is configured to encrypt at least a portion of each of the one or more data payloads using at least a public key corresponding to the merchant identifier; and wherein a corresponding private key to the public key is made available to a corresponding merchant, the corresponding private key usable by the corresponding merchant to decrypt the one or more data payloads; and Para. 0006, the one or more control commands adapted to interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation through the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices, the propagation updating each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.; and Para. 0007, In accordance with another aspect, the system further comprises a control command generator operatively coupled to the interface layer configured to encapsulate one or more data payloads that are propagated to the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices, the one or more data payloads encapsulated to include at least: (i) a transaction amount, (ii) a transaction type, (iii) an originating account identifier, (iv) a counterparty account identifier, and (v) a merchant identifier; and Para. 0072, The one or more control commands are used to then interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation to update each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.; and Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program.)
wherein the incentive information comprises a first point transfer path, (Para. 0070, These electronic instructions may be extracted, for example, based on spending behavior, transaction details, promotions, etc. For example, transactions may be provided in encoded formats whereby the system may extract details relating to qualifying spend and/or other activities and rewards provisioning logical conditions and operators may be utilized to either generate corresponding new virtual tokens on the distributed ledger or facilitate a transfer or otherwise cause a transaction to be posted on the distributed ledger.; and Para. 0074, In other embodiments, a control command generator is further included to encapsulate data payloads for propagation across the distributed ledgers, and these data payloads may relate to transactions and record transaction information, such as a transaction amount, a type of transaction, account identifiers, merchant information, etc.; and Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).; and Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).).
wherein the verifying a transaction request in response to the transaction request being received comprises: calling a smart contract for incentive points to verify the incentive information, so as to determine whether the first point transfer path belongs to a whitelist, (Para. 0075, Public and private key mechanisms are utilized to maintain (or in some embodiments bypass) privacy/security settings as between merchants (e.g., Store A may be prevented from querying/viewing/decrypting records stored in relation to Store B's loyalty rewards program). In some embodiments, key pairs are utilized to establish transactions and trades as between loyalty rewards programs. For example, each merchant/participating program may be associated with one or more key pairs that are utilized to validate transactions that convert from one virtual currency to another. In the context of conversions of one virtual currency to another, specially configured key pairs may be utilized such that both of the originating merchant/loyalty program and the recipient merchant/loyalty program are both able to see various aspects of the data payloads that are associated with points conversions.; and Para. 0078, To obtain comfort that a transaction has been processed and exists as an immutable (or difficult to modify) record on the distributed ledgers, a minimum number of confirmations (i.e., successful queries) may be required by the system to determine whether it should mark or otherwise flag a transaction as successfully completed. Such a process helps mitigate race conditions and double spending issues that could occur in a decentralized distributed system.; and Para. 0102, The distributed ledger may be one or more cryptographically linked chains of sequential entries, each of the cryptographically linked chains relating to one or more virtual tokens, or groups (blocks) of virtual tokens that may have associated data payloads, such as value, quantity, conditions, type of virtual token, etc.)
Ortiz does not disclose wherein the incentive information comprises a first quantity of incentive points, and each incentive point corresponds to a first predetermined quantity of resources, the incentive point comes from the transaction request account, to achieve an incentive to a blockchain account storing the transaction information in the blockchain, and the resources comprise a legal currency.
However, Swamidurai teaches wherein the incentive information comprises a first quantity of incentive points, and each incentive point corresponds to a first predetermined quantity of resources, the incentive point comes from the transaction request account, to achieve an incentive to a blockchain account storing the transaction information in the blockchain, and the resources comprise a legal currency, (Para. 0046-0048, a process 301 for generating and writing a reward transfer message to a transfer blockchain is shown according to various embodiments. A user may interact with user terminal 105, via a mobile application, IoT communication, web browser, or the like, to access rewards portal 110. For example, the user may access rewards portal 110 to review a user points balance; to redeem user points for travel, cash, gift cards, or the like; and/or to initiate a rewards transfer request to transfer user reward points to a rewards partner (e.g., rewards partner 150-1, 150-2, 150-3). Rewards portal 110 receives a rewards transfer request (step 302). The rewards transfer request may comprise a user transaction account identifier (e.g., a user transaction account ID, transaction account number, etc.), a points transfer amount, a user rewards partner account identifier (e.g., a username or ID the user associated with the user's rewards account at the rewards partner), and/or a rewards partner identifier (e.g., a rewards partner ID). Rewards portal 110 transmits the rewards transfer request to rewards redemption module 120 (step 304). In response to receiving the rewards transfer request, rewards redemption module 120 queries rewards database 115 (step 306). Rewards redemption module 120 may query rewards database 115 based on the user identifier to determine and verify the user points balance associated with the user identifier. Rewards redemption module 120 updates the user points balance in rewards database 115 (step 308). Rewards redemption module 120 may compare the user points balance to the points transfer amount to ensure that the user points balance is sufficient to complete the rewards transfer request. Rewards redemption module 120 may update the user points balance to reflect the points transfer amount being transferred to the rewards partner. As used herein, the transfer of points may include the system also conducting any type of conversions of points, conversions of country currencies (or monetary values) related to the points or normalization of points, such that the points have similar or equivalent value in different systems. The system may also acquire updated country currency conversion rates or updated rewards program value, prior to converting the points. For example, 10 points in one system may be equivalent to 500 points in another system. The points transfers may also include a “loan” of points to a second party, wherein the second party may eventually pay back the points to the first party.; and Para. 0051, With specific reference to FIG. 4, and continued reference to FIG. 1, a process 401 for retrieving reward transfer messages from the transfer blockchain is shown according to various embodiments. Rewards partner 150-1, 150-2, 150-3 queries transfer blockchain 140 (step 402). Rewards partner 150-1, 150-2, 150-3 may query transfer blockchain 140 via each respective transfer blockchain node 135-2, 135-3, 135-4. In various embodiments, rewards partner 150-1, 150-2, 150-3 may query transfer blockchain 140 in response to any suitable event or instruction.; and Para. 0062, In various embodiments, partner transfer system 270 generates a second rewards transfer message hash (step 518) based on the decrypted rewards transfer message. The second rewards transfer message hash may be generated using any cryptographic hash function such as, for example, SHA-1, SHA-256, checksum, or MD5 (e.g., similar to step 410, with brief reference to FIG. 4). The second rewards transfer message hash may be generated using the same cryptographic hash function used to generate the rewards transfer message hash (e.g., step 312, with brief reference to FIG. 3). Partner transfer system 270 compares the (first) rewards transfer message hash to the second rewards transfer message hash (step 520). Partner transfer system 270 may compare the (first) rewards transfer message hash to the second rewards transfer message hash to determine whether the (first) rewards transfer message hash matches the second rewards transfer message hash)
One of ordinary skill in the art would have recognized that applying the known technique of Swamidurai to the known invention of Ortiz would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the incentive information comprises a first quantity of incentive points, and each incentive point corresponds to a first predetermined quantity of resources, the incentive point comes from the transaction request account, to achieve an incentive to a blockchain account storing the transaction information in the blockchain, and the resources comprise a legal currency result in an improved invention because applying said technique will ensure that all users have a consistent record of transactions and incentives, thus improving the overall performance of the invention.
Ortiz does not disclose wherein the updating a first existing incentive point according to the incentive information, so as to obtain an updated incentive point comprises adding a quantity of the first existing incentive point to the first quantity to obtain the updated incentive point.
However, Swamidurai teaches wherein the updating a first existing incentive point according to the incentive information, so as to obtain an updated incentive point comprises adding a quantity of the first existing incentive point to the first quantity to obtain the updated incentive point, (Para. 0053, In various embodiments, rewards partner 150-1, 150-2, 150-3 decrypts the encrypted rewards transfer message (step 408). Rewards partner 150-1, 150-2, 150-3 may decrypt the encrypted rewards transfer message using the private key from the asymmetric key pair (e.g., the rewards partner private key) and the public key associated with transaction network 101 (e.g., the transaction network public key. In that respect, the encrypted rewards transfer message may only be decrypted by the rewards partner 150-1, 150-2, 150-3 associated with the public key used to encrypt the rewards transfer message (e.g., in step 314, with brief reference to FIG. 3).; and Para. 0063, Partner transfer system 270 generates a rewards transfer response message (step 522). The rewards transfer response message may be generated similar to step 414, with brief reference to FIG. 4. The rewards transfer response message may comprise the user rewards account partner identifier, the rewards partner identifier, and/or a transfer status. The rewards transfer response message may also comprise the unique transaction ID. The transfer status may comprise data indicating the status of the rewards transfer request, such as, for example, “transfer complete,” “transfer failed,” “transfer pending,” “transfer pending for 10 days,” and/or any other suitable status message)
One of ordinary skill in the art would have recognized that applying the known technique of Swamidurai to the known invention of Ortiz would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the updating a first existing incentive point according to the incentive information, so as to obtain an updated incentive point comprises adding a quantity of the first existing incentive point to the first quantity to obtain the updated incentive point, result in an improved invention because applying said technique will ensure that all users have a consistent record of transactions and incentives, thus improving the overall performance of the invention.
Ortiz as modified does not disclose broadcasting the updated blockchain and the updated incentive point to a plurality of blockchain nodes in the blockchain network.
However, Gutierrez-Sheris teaches broadcasting the updated blockchain and the updated incentive point to a plurality of blockchain nodes in the blockchain network, (Para. 0036-0037, The blockchain processing device 110 may be a computer such as a mobile phone, smartphone, tablet, laptop, desktop computer, server computer, purpose-built computation device, or other type of computation device, with one or more computer processors 112, computer memory 114 for storing computer instructions, a database 116 for processing blockchain information (including records and/or transactions), and a communication module 118 for connecting to the Internet 190 and/or the distributed network. The blockchain processing device may also optionally include a display 155 (not shown), and may consist of multiple computers or a network of computers (either directly connected or distributed), all of the same type or of different types. The wallet device 120, the blockchain data browsing device 130, the vendor device 140, and the combination device 150 typically have the same components as the blockchain processing device 110The blockchain processing device 110 functions as a “Block-Building Node”, which is also referred to as a “miner” in proof-of-work blockchains. Block-Building Nodes are responsible for assembling new blocks that reflect the inclusion of new records or transactions in the blockchain, and for linking those blocks to the blockchain. Block-Building Nodes are also responsible for algorithmically confirming whether the blocks that have been linked to the blockchain are valid, and whether records or transactions are validly included in the blockchain. Block-Building Nodes are also responsible for propagating blocks and data records within the network. In at least one embodiment of the present invention, each Block-Building Node is associated with an account or address on the blockchain, to which account or address block mining rewards may be assigned. Such an account or address can also be used by a Block Building Node to securely identify itself and its activities within the network and on the chain through the use of cryptographic signatures.)
One of ordinary skill in the art would have recognized that applying the known technique of Gutierrez-Sheris to the known invention of Ortiz as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include broadcasting the updated blockchain and the updated incentive point to a plurality of blockchain nodes in a blockchain network, result in an improved invention because applying said technique will ensure that all users have a consistent record of transactions and incentives, thus improving the overall performance of the invention.
Ortiz as modified does not disclose wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block,
However, Gutierrez-Sheris teaches wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block, (Para. 0013-0014, Another object and a feature of the present invention is use of different record types, including token genesis records, transfer records, trade order records, settlement records, proposition records, determination records, and pattern linkage records. These different records, and the Fitness Gradient consensus methodology and its variants are useful in (1) implementing real-world event-driven smart contract execution systems that utilize blockchains and blockchain-based systems; (2) identity confirmation processing using blockchains and blockchain-based systems; (3) asset title and tracking blockchains and blockchain-based systems; (4) currency-based asset tokens, foreign exchange trading and remittances processes utilizing blockchains and blockchain-based systems; and (5) implementing an automated system for the issuance, sale, transfer and trading of tokens that may be characterized as securities, and which are regulated as securities in accordance with multiple security regulations, rules and restrictions governing securities transactions. Yet another object and a feature of the present invention is utilization of different record types, including without limitation token genesis records, transfer records, trade order records, settlement records, proposition records, determination records and/or pattern linkage records to implement derived and base tokens, and controlling the supply and value of tokens, as well as transfer and trading of tokens.; and Claim 10, further utilizing at least one genesis record, which record declares and defines a new user-specified token type, wherein transfers of one or more tokens sent from one address or user account to another is tracked using at least one transfer record.; and Claim 11, wherein the genesis record that declares and defines at least one new user-specified token type is valid within the blockchain if it is cryptographically signed by an account or an address that has previously been authorized to declare and define at least one new user-specified token type.).
One of ordinary skill in the art would have recognized that applying the known technique of Gutierrez-Sheris to the known invention of Ortiz as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate genesis block features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block, result in an improved invention because applying said technique will ensure that the total of points are predefined, thus improving the overall performance of the invention.
Ortiz as modified does not disclose determining that the incentive information is verified successfully, in response to the blockchain account in the first point transfer path belonging to the whitelist.
However, Black teaches determining that the incentive information is verified successfully, in response to the blockchain account in the first point transfer path belonging to the whitelist, (Para. 0003, The at least one processor is further configured to verify that the at least one of the target transaction address or the target public key associated with the target transaction address is associated with the private key. The at least one processor is further configured to verify that the at least one of the target transaction address or the target public key associated with the target transaction address is whitelisted to purchase the token. The at least one processor is further configured to allow purchase of the token into the target transaction address when the at least one of the target transaction address or the target public key associated with the target transaction address is both: (1) associated with the private key and (2) whitelisted to purchase the token.; and Para. 0016, To address the above problem, the examples described herein implement validation/verification of a particular transaction address being on the whitelist before allowing a transaction of the token to occur. In one example, the verification can be implemented by an asset exchange (such as, for example, asset exchange 104). The verification includes requiring a potential purchaser of the regulated tokens (that require the user to be whitelisted) to send signed data to a system, where the data is signed with a private key corresponding to the particular transaction address the potential purchaser wants to transact into. The asset exchange verifies that the data was signed with the private key that corresponds to the transaction address the user indicated was the intended destination for the regulated token and that the transaction address is on the appropriate whitelist. In some examples, the asset exchange could verify that the data was signed with the private key that corresponds to a public key associated with the transaction address. The asset exchange allows the transfer to proceed when the private key corresponds to the target transaction address or target public key and the target transaction address or the target public key is on the whitelist. If these conditions are not met, the asset exchange rejects or otherwise denies the transfer.)
One of ordinary skill in the art would have recognized that applying the known technique Black to the known invention of Ortiz as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate whitelist features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include determining that the incentive information is verified successfully, in response to the blockchain account in the first point transfer path belonging to the whitelist result in an improved invention because applying said technique will ensure that making sure that only approved accounts are earning incentives, thus improving the overall performance of the invention.
Ortiz does not disclose wherein each application is provided with at least two blockchain accounts, the at least two blockchain accounts comprise one management account, the whitelist comprises the management account of each of at least two applications, and only the management account in the at least two blockchain accounts provided for each application is used to maintain incentive points; and wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block.
However, Harrison teaches wherein each application is provided with at least two blockchain accounts, the at least two blockchain accounts comprise one management account, the whitelist comprises the management account of each of at least two applications, and only the management account in the at least two blockchain accounts provided for each application is used to maintain incentive points; and wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block, (Para. 0123-0125, FIG. 17 depicts an example of a cardholder ledger that may be maintained by a cryptocurrency rewards platform. As noted above, the platform could be used by individuals who are not cardholders to buy, sell, or transfer cryptocurrency, so the cardholder ledger may also be referred to as a “customer ledger.” The ledger may be used as an accounting ledger to track all requests for transactions that are received by the platform and all requests for transactions that are generated by the platform. This allows the platform to track a specific amount of cryptocurrency from its purchase (or when it was received) through its disbursement or sale… Since each transaction could potentially originate from multiple corporate wallets at any given time, the platform may track all purchases of cryptocurrencies and which corporate wallet(s) include those cryptocurrencies. The platform could also link each purchase to a distribution in order to utilize the best purchasing/distribution policies for each transaction. For example, a corporate wallet held by a first exchange (“Exchange A”) may contain cryptocurrency that was purchased at a much lower price than the cryptocurrency contained in another corporate wallet held by a second exchange (“Exchange B”). Even though the cardholder may request that cryptocurrency be disbursed into a personal wallet on Exchange B, the platform may opt to send cryptocurrency from Exchange A based on the data maintained in the ledger.; and Para. 0011, FIG. 5 illustrates how a corporate wallet can be comprised of online external wallets (also referred to as “hot external wallets”), offline external wallets (also referred to as “cold external wallets”), and/or corporate accounts with various exchanges.)
One of ordinary skill in the art would have recognized that applying the known technique Harrison to the known invention of Ortiz as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate whitelist features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein each application is provided with at least two blockchain accounts, the at least two blockchain accounts comprise one management account, the whitelist comprises the management account of each of at least two applications, and only the management account in the at least two blockchain accounts provided for each application is used to maintain incentive points; and wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block result in an improved invention because applying said technique will ensure that incentive points are maintained in one account and other accounts, thus improving the overall performance of the invention.
7. Regarding claims 3 and 16, Ortiz discloses further comprising:
broadcasting a point exchange request to at least some of the plurality of blockchain nodes in response to the point exchange request being received, wherein the point exchange request comprises a second point transfer path, (Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).; and Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).
calling a smart contract for incentive points to verify the point exchange request, so as to determine whether the second point transfer path belongs to a predetermined path, (Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).; and Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).
determining that the point exchange request is verified successfully, in response to the second point transfer path belonging to the predetermined path, (Para. 0102, The distributed ledger may be one or more cryptographically linked chains of sequential entries, each of the cryptographically linked chains relating to one or more virtual tokens, or groups (blocks) of virtual tokens that may have associated data payloads, such as value, quantity, conditions, type of virtual token, etc.)
and updating the first existing incentive point according to the point exchange request, in response to a target information being received from a predetermined proportion of nodes in the at least some nodes, wherein the target information indicates that the point exchange request is verified successfully, wherein the point exchange request further comprises a second quantity of incentive points requested for exchange and a third quantity of resources, and the third quantity of resources corresponds to the second quantity of incentive points, (Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).; and Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).; and Para. 0075, Public and private key mechanisms are utilized to maintain (or in some embodiments bypass) privacy/security settings as between merchants (e.g., Store A may be prevented from querying/viewing/decrypting records stored in relation to Store B's loyalty rewards program). In some embodiments, key pairs are utilized to establish transactions and trades as between loyalty rewards programs. For example, each merchant/participating program may be associated with one or more key pairs that are utilized to validate transactions that convert from one virtual currency to another. In the context of conversions of one virtual currency to another, specially configured key pairs may be utilized such that both of the originating merchant/loyalty program and the recipient merchant/loyalty program are both able to see various aspects of the data payloads that are associated with points conversions.; and Para. 0102, The distributed ledger may be one or more cryptographically linked chains of sequential entries, each of the cryptographically linked chains relating to one or more virtual tokens, or groups (blocks) of virtual tokens that may have associated data payloads, such as value, quantity, conditions, type of virtual token, etc.; and Para. 0070-0074, These electronic instructions may be extracted, for example, based on spending behavior, transaction details, promotions, etc. For example, transactions may be provided in encoded formats whereby the system may extract details relating to qualifying spend and/or other activities and rewards provisioning logical conditions and operators may be utilized to either generate corresponding new virtual tokens on the distributed ledger or facilitate a transfer or otherwise cause a transaction to be posted on the distributed ledger…In other embodiments, a control command generator is further included to encapsulate data payloads for propagation across the distributed ledgers, and these data payloads may relate to transactions and record transaction information, such as a transaction amount, a type of transaction, account identifiers, merchant information, etc.)
8. Regarding claims 4, 9, and 17, Ortiz discloses wherein: the predetermined path comprises a predetermined blockchain account; the predetermined blockchain account comprises a management account of each application in at least two applications (Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).
and each application is provided with at least two blockchain accounts, and the at least two blockchain accounts comprise one of the management accounts, (Para. 0104, The distributed ledgers can be utilized as a query-able event log that provides increased security and traceability of transactions, and in some embodiments, provides enhanced and independent query capabilities where any computing device can connect to any node and perform a query on one or more local distributed ledgers (e.g., to obtain a present balance, to confirm whether a transaction was processed).).
9. Regarding claim 5, Ortiz discloses wherein: the transaction request is broadcast to a consensus node in the blockchain network by a node in the plurality of blockchain nodes, (Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).
and the transaction information is stored on the blockchain by the consensus node, and the first existing incentive point is an existing incentive point of the consensus node storing the transaction information, (Para. 0070-0072, These electronic instructions may be extracted, for example, based on spending behavior, transaction details, promotions, etc. For example, transactions may be provided in encoded formats whereby the system may extract details relating to qualifying spend and/or other activities and rewards provisioning logical conditions and operators may be utilized to either generate corresponding new virtual tokens on the distributed ledger or facilitate a transfer or otherwise cause a transaction to be posted on the distributed ledger. The interface layer (e.g., as provided by an interface unit) extracts, from the electronic instructions, control commands indicative of requests to generate, provision or process virtual tokens stored in a digital wallet linked to a user profile. In some embodiments, the interface layer is further configured for facilitating queries through conducting one or more traversals of the distributed ledgers, for example, by traversing linked sequential or related entries through their cryptographic linkages. The one or more control commands are used to then interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation to update each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.)
10. Regarding claim 7, Ortiz discloses wherein the transaction request comprises at least one selected from: a first request to issue a digital asset to the blockchain; and/or a second request to transfer a digital asset from a first blockchain account to a second blockchain account, (Para. 0075, Public and private key mechanisms are utilized to maintain (or in some embodiments bypass) privacy/security settings as between merchants (e.g., Store A may be prevented from querying/viewing/decrypting records stored in relation to Store B's loyalty rewards program). In some embodiments, key pairs are utilized to establish transactions and trades as between loyalty rewards programs. For example, each merchant/participating program may be associated with one or more key pairs that are utilized to validate transactions that convert from one virtual currency to another. In the context of conversions of one virtual currency to another, specially configured key pairs may be utilized such that both of the originating merchant/loyalty program and the recipient merchant/loyalty program are both able to see various aspects of the data payloads that are associated with points conversions.; and Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).)
11. Regarding claim 8, Ortiz discloses wherein the transaction information comprises a signature of a transaction request account and a public key of the transaction request account; and wherein the verifying a transaction request comprises calling a smart contract for digital assets to verify the transaction information according to the signature and the public key, (Para. 0075, Public and private key mechanisms are utilized to maintain (or in some embodiments bypass) privacy/security settings as between merchants (e.g., Store A may be prevented from querying/viewing/decrypting records stored in relation to Store B's loyalty rewards program). In some embodiments, key pairs are utilized to establish transactions and trades as between loyalty rewards programs. For example, each merchant/participating program may be associated with one or more key pairs that are utilized to validate transactions that convert from one virtual currency to another. In the context of conversions of one virtual currency to another, specially configured key pairs may be utilized such that both of the originating merchant/loyalty program and the recipient merchant/loyalty program are both able to see various aspects of the data payloads that are associated with points conversions.; and Para, 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).).
12. Regarding claim 9, Ortiz discloses wherein: the predetermined path comprises a predetermined blockchain account, (Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).).
the predetermined blockchain account comprises a management account of each application in at least two applications; and each application is provided with at least two blockchain accounts, and the at least two blockchain accounts comprise one of the management accounts. )
13. Regarding claim 10, Ortiz discloses a method of processing an information, applied to a blockchain network, the method comprising: determining an incentive information for a transaction information in response to the transaction information being received, (Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).; and Para. 0078, To obtain comfort that a transaction has been processed and exists as an immutable (or difficult to modify) record on the distributed ledgers, a minimum number of confirmations (i.e., successful queries) may be required by the system to determine whether it should mark or otherwise flag a transaction as successfully completed. Such a process helps mitigate race conditions and double spending issues that could occur in a decentralized distributed system.)
wherein the incentive information comprises a first point transfer path, (Para. 0070, These electronic instructions may be extracted, for example, based on spending behavior, transaction details, promotions, etc. For example, transactions may be provided in encoded formats whereby the system may extract details relating to qualifying spend and/or other activities and rewards provisioning logical conditions and operators may be utilized to either generate corresponding new virtual tokens on the distributed ledger or facilitate a transfer or otherwise cause a transaction to be posted on the distributed ledger.; and Para. 0074, In other embodiments, a control command generator is further included to encapsulate data payloads for propagation across the distributed ledgers, and these data payloads may relate to transactions and record transaction information, such as a transaction amount, a type of transaction, account identifiers, merchant information, etc.); and Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program. The blockchain implementation provides improvements in event ordering (e.g., transactions are ordered based on their timestamp, in a FIFO queue), block creation (e.g., transactions are stored in immutable corresponding blocks), block chaining (e.g., blocks are chained using the previous block hash, before being codified in a system chain, improving the integrity of the events stored in the blockchain and permits for easy queries by way of traversal), preventing double-spend (e.g., transactions are checked to see if their output was not previously claimed by another transaction (account balance validation)).; and Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).).
the transaction information comprises an information of a digital asset that needs to be issued to a blockchain or an information of a digital asset that needs to be transferred, the transaction information further comprises a signature of a transaction request account and a public key of the transaction request account, and the public key is configured to decrypt the signature; (Para. 0006, the interface layer adapted for receiving electronic instructions at payment transaction devices operatively linked to the corresponding node computing device, the electronic instructions including at least data transmissions representative of an electronic transaction; wherein the interface layer is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens stored in a digital wallet linked to a user profile… wherein the interface layer is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens stored in a digital wallet linked to a user profile, the one or more control commands adapted to interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation through the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices, the propagation updating each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries. Para. 0008, In accordance with another aspect, the system the control command generator is configured to encrypt at least a portion of each of the one or more data payloads using at least a public key corresponding to the merchant identifier; and wherein a corresponding private key to the public key is made available to a corresponding merchant, the corresponding private key usable by the corresponding merchant to decrypt the one or more data payloads; and Para. 0006, the one or more control commands adapted to interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation through the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices, the propagation updating each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.; and Para. 0007, In accordance with another aspect, the system further comprises a control command generator operatively coupled to the interface layer configured to encapsulate one or more data payloads that are propagated to the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices, the one or more data payloads encapsulated to include at least: (i) a transaction amount, (ii) a transaction type, (iii) an originating account identifier, (iv) a counterparty account identifier, and (v) a merchant identifier; and Para. 0072, The one or more control commands are used to then interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation to update each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.; and Para. 0064, In some embodiments, a blockchain implementation is described wherein virtual tokens are stored on a series of decentralized devices acting as node computing devices each having a copy of a distributed ledger managed on the node computing device in accordance with electronic propagation mechanisms (e.g., consensus mechanisms used to effect state transitions in relation to the updating of the nodes such that the distributed ledgers contain the same entries across the decentralized network) that are used to validate and verify transactions/activities that relate to a loyalty reward program.)
wherein the transaction request is verified by: calling a smart contract for incentive points to verify the incentive information, so as to determine whether the first point transfer path belongs to a predetermined path; and determining that the incentive information is verified successfully, in response to the first point transfer path belonging to the predetermined path, (Para. 0075, Public and private key mechanisms are utilized to maintain (or in some embodiments bypass) privacy/security settings as between merchants (e.g., Store A may be prevented from querying/viewing/decrypting records stored in relation to Store B's loyalty rewards program). In some embodiments, key pairs are utilized to establish transactions and trades as between loyalty rewards programs. For example, each merchant/participating program may be associated with one or more key pairs that are utilized to validate transactions that convert from one virtual currency to another. In the context of conversions of one virtual currency to another, specially configured key pairs may be utilized such that both of the originating merchant/loyalty program and the recipient merchant/loyalty program are both able to see various aspects of the data payloads that are associated with points conversions.; and Para. 0078, To obtain comfort that a transaction has been processed and exists as an immutable (or difficult to modify) record on the distributed ledgers, a minimum number of confirmations (i.e., successful queries) may be required by the system to determine whether it should mark or otherwise flag a transaction as successfully completed. Such a process helps mitigate race conditions and double spending issues that could occur in a decentralized distributed system.; and Para. 0102, The distributed ledger may be one or more cryptographically linked chains of sequential entries, each of the cryptographically linked chains relating to one or more virtual tokens, or groups (blocks) of virtual tokens that may have associated data payloads, such as value, quantity, conditions, type of virtual token, etc.; and Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).; and Para. 0078, To obtain comfort that a transaction has been processed and exists as an immutable (or difficult to modify) record on the distributed ledgers, a minimum number of confirmations (i.e., successful queries) may be required by the system to determine whether it should mark or otherwise flag a transaction as successfully completed. Such a process helps mitigate race conditions and double spending issues that could occur in a decentralized distributed system.)
Ortiz does not explicitly disclose sending a transaction request to the blockchain network to verify the transaction request in response to the transaction request being received and to encrypt and store the transaction information on the blockchain after the transaction request is verified successfully, wherein the transaction request comprises the transaction information and the incentive information, and the transaction information is stored by a consensus node in the blockchain network; and updating a second existing incentive point according to the incentive information, wherein the second existing incentive point is an existing incentive point of a target account, wherein the updating a second existing incentive point according to the incentive information comprises subtracting the first quantity from a quantity of the second existing incentive point to complete the updating of the second existing incentive point.
However, Swamidurai teaches sending a transaction request to the blockchain network to verify the transaction request in response to the transaction request being received and to encrypt and store the transaction information on the blockchain after the transaction request is verified successfully, wherein the transaction request comprises the transaction information and the incentive information, and the transaction information is stored by a consensus node in the blockchain network; and updating a second existing incentive point according to the incentive information, wherein the second existing incentive point is an existing incentive point of a target account, wherein the updating a second existing incentive point according to the incentive information comprises subtracting the first quantity from a quantity of the second existing incentive point to complete the updating of the second existing incentive point, (Para. 0003-0004,The system may receive, by a first transfer blockchain node in a blockchain network, an encrypted rewards transfer message and a rewards transfer message hash. The encrypted rewards transfer message may comprise a points transfer amount and a user rewards account partner identifier. The rewards transfer message hash may be based on the rewards transfer message. The encrypted rewards transfer message may be encrypted using a rewards partner public key and a transaction network private key. The system may write the rewards transfer message hash and the encrypted rewards transfer message to a transfer blockchain. The system may propagate the rewards transfer message hash and the encrypted rewards transfer message to the blockchain network… a second transfer blockchain node in the blockchain network may retrieve the rewards transfer message hash and the encrypted rewards transfer message from the transfer blockchain. The second transfer blockchain node may be associated with a rewards partner system, and wherein the rewards partner system retrieves the rewards transfer message hash and the encrypted rewards transfer message from the second transfer blockchain node. The rewards partner system may decrypt the encrypted rewards transfer message using a rewards partner private key and a transaction network public key, generates a second rewards transfer message hash based on the decrypted rewards transfer message, and determines whether the second rewards transfer message hash matches the first rewards transfer message hash. The rewards partner system may generate a rewards transfer response message comprising the user rewards account partner identifier and a transfer status, generates a rewards transfer response message hash based on the rewards transfer response message, and encrypts the rewards transfer response message using the rewards partner private key and the transaction network public key. The second transfer blockchain node may receive the encrypted rewards transfer response message and the rewards transfer response message hash from the rewards partner system, write the encrypted rewards transfer response message and the rewards transfer response message hash to the transfer blockchain, and propagate the encrypted rewards transfer response message and the rewards transfer response message hash to the blockchain network.; and Para. 0007, In various embodiments, a method for receiving reward point transfers from a transaction network is disclosed. The method may comprise: retrieving, by a rewards partner system in electronic communication with a blockchain node, a rewards transfer message hash and an encrypted rewards transfer message from a transfer blockchain; decrypting, by the rewards partner system, the encrypted rewards transfer message using a rewards partner private key and a transaction network public key, wherein the decrypted rewards transfer message comprises a points transfer amount and a user rewards partner account identifier; generating, by the rewards partner system, a rewards transfer response message comprising the user rewards partner account identifier and a transfer status; generating, by the rewards partner system, a rewards transfer response message hash based on the rewards transfer response message; encrypting, by the rewards partner system, the rewards transfer response message using the rewards partner private key and the transaction network public key; and transmitting, by the rewards partner system, the rewards transfer response message hash and the encrypted rewards transfer response message to the blockchain node for writing to the transfer blockchain.; and Para. 0018, the blockchain driven reward points transfer system may provide a technical solution to the problem of customer fraud caused by the delay in transferring points and the lack of common ledger or acknowledgment system between the parties. The blockchain driven network may also enable instant or near-instant reward points transfers, as discussed further herein. The system may also enable visibility transparency between transaction account issuers and rewards partners wherein each party can view data concerning reward points transfers, including the current status of the transfer.)
One of ordinary skill in the art would have recognized that applying the known technique of Swamidurai to the known invention of Ortiz would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include sending a transaction request to the blockchain network to verify the transaction request in response to the transaction request being received and to encrypt and store the transaction information on the blockchain after the transaction request is verified successfully, wherein the transaction request comprises the transaction information and the incentive information, and the transaction information is stored by a consensus node in the blockchain network; and updating a second existing incentive point according to the incentive information, wherein the second existing incentive point is an existing incentive point of a target account, wherein the updating a second existing incentive point according to the incentive information comprises subtracting the first quantity from a quantity of the second existing incentive point to complete the updating of the second existing incentive point result in an improved invention because applying said technique will ensure that all users have a consistent record of transactions and incentives and maintaining an accurate record of transactions, thus improving the overall performance of the invention.
Ortiz does not explicitly disclose wherein the incentive information comprises a first quantity of incentive points, and each incentive point corresponds to a first predetermined quantity of resources, the incentive point comes from the transaction request account, to achieve an incentive to a blockchain account storing the transaction information in the blockchain, and the resources comprise a legal currency.
However, Swamidurai teaches wherein the incentive information comprises a first quantity of incentive points, and each incentive point corresponds to a first predetermined quantity of resources, the incentive point comes from the transaction request account, to achieve an incentive to a blockchain account storing the transaction information in the blockchain, and the resources comprise a legal currency, (Para. 0046-0048, a process 301 for generating and writing a reward transfer message to a transfer blockchain is shown according to various embodiments. A user may interact with user terminal 105, via a mobile application, IoT communication, web browser, or the like, to access rewards portal 110. For example, the user may access rewards portal 110 to review a user points balance; to redeem user points for travel, cash, gift cards, or the like; and/or to initiate a rewards transfer request to transfer user reward points to a rewards partner (e.g., rewards partner 150-1, 150-2, 150-3). Rewards portal 110 receives a rewards transfer request (step 302). The rewards transfer request may comprise a user transaction account identifier (e.g., a user transaction account ID, transaction account number, etc.), a points transfer amount, a user rewards partner account identifier (e.g., a username or ID the user associated with the user's rewards account at the rewards partner), and/or a rewards partner identifier (e.g., a rewards partner ID). Rewards portal 110 transmits the rewards transfer request to rewards redemption module 120 (step 304). In response to receiving the rewards transfer request, rewards redemption module 120 queries rewards database 115 (step 306). Rewards redemption module 120 may query rewards database 115 based on the user identifier to determine and verify the user points balance associated with the user identifier. Rewards redemption module 120 updates the user points balance in rewards database 115 (step 308). Rewards redemption module 120 may compare the user points balance to the points transfer amount to ensure that the user points balance is sufficient to complete the rewards transfer request. Rewards redemption module 120 may update the user points balance to reflect the points transfer amount being transferred to the rewards partner. As used herein, the transfer of points may include the system also conducting any type of conversions of points, conversions of country currencies (or monetary values) related to the points or normalization of points, such that the points have similar or equivalent value in different systems. The system may also acquire updated country currency conversion rates or updated rewards program value, prior to converting the points. For example, 10 points in one system may be equivalent to 500 points in another system. The points transfers may also include a “loan” of points to a second party, wherein the second party may eventually pay back the points to the first party.; and Para. 0051] With specific reference to FIG. 4, and continued reference to FIG. 1, a process 401 for retrieving reward transfer messages from the transfer blockchain is shown according to various embodiments. Rewards partner 150-1, 150-2, 150-3 queries transfer blockchain 140 (step 402). Rewards partner 150-1, 150-2, 150-3 may query transfer blockchain 140 via each respective transfer blockchain node 135-2, 135-3, 135-4. In various embodiments, rewards partner 150-1, 150-2, 150-3 may query transfer blockchain 140 in response to any suitable event or instruction.; and Para. 0062, In various embodiments, partner transfer system 270 generates a second rewards transfer message hash (step 518) based on the decrypted rewards transfer message. The second rewards transfer message hash may be generated using any cryptographic hash function such as, for example, SHA-1, SHA-256, checksum, or MD5 (e.g., similar to step 410, with brief reference to FIG. 4). The second rewards transfer message hash may be generated using the same cryptographic hash function used to generate the rewards transfer message hash (e.g., step 312, with brief reference to FIG. 3). Partner transfer system 270 compares the (first) rewards transfer message hash to the second rewards transfer message hash (step 520). Partner transfer system 270 may compare the (first) rewards transfer message hash to the second rewards transfer message hash to determine whether the (first) rewards transfer message hash matches the second rewards transfer message hash)
One of ordinary skill in the art would have recognized that applying the known technique of Swamidurai to the known invention of Ortiz would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the incentive information comprises a first quantity of incentive points, and each incentive point corresponds to a first predetermined quantity of resources, the incentive point comes from the transaction request account, to achieve an incentive to a blockchain account storing the transaction information in the blockchain, and the resources comprise a legal currency, result in an improved invention because applying said technique will ensures that only valid transactions are approved and transactions, thus improving the overall performance of the invention.
14. Regarding claim 11, Ortiz discloses further comprising: sending a point exchange request to the blockchain network in response to the second existing incentive point being less than a predetermined value, wherein the point exchange request comprises a second quantity of incentive points requested for exchange and a third quantity of resources; (Para. 0070, These electronic instructions may be extracted, for example, based on spending behavior, transaction details, promotions, etc. For example, transactions may be provided in encoded formats whereby the system may extract details relating to qualifying spend and/or other activities and rewards provisioning logical conditions and operators may be utilized to either generate corresponding new virtual tokens on the distributed ledger or facilitate a transfer or otherwise cause a transaction to be posted on the distributed ledger.; and Para. 0074, In other embodiments, a control command generator is further included to encapsulate data payloads for propagation across the distributed ledgers, and these data payloads may relate to transactions and record transaction information, such as a transaction amount, a type of transaction, account identifiers, merchant information, etc.)
and updating the second existing incentive point according to the second quantity, wherein the third quantity of resources corresponds to the second quantity of incentive points, (Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).; and Para. 0074] In other embodiments, a control command generator is further included to encapsulate data payloads for propagation across the distributed ledgers, and these data payloads may relate to transactions and record transaction information, such as a transaction amount, a type of transaction, account identifiers, merchant information, etc.; and Para. 0102, The distributed ledger may be one or more cryptographically linked chains of sequential entries, each of the cryptographically linked chains relating to one or more virtual tokens, or groups (blocks) of virtual tokens that may have associated data payloads, such as value, quantity, conditions, type of virtual token, etc.)
15. Regarding claim 12, Ortiz discloses wherein: the second existing incentive point is an existing incentive point of a target account, and the target account is a management account of an application in at least two applications, (Para. 0070, These electronic instructions may be extracted, for example, based on spending behavior, transaction details, promotions, etc. For example, transactions may be provided in encoded formats whereby the system may extract details relating to qualifying spend and/or other activities and rewards provisioning logical conditions and operators may be utilized to either generate corresponding new virtual tokens on the distributed ledger or facilitate a transfer or otherwise cause a transaction to be posted on the distributed ledger.)
each application in the at least two applications is provided with at least two blockchain accounts, and the at least two blockchain accounts comprise one of the management accounts; and wherein the transaction information is transmitted by a blockchain account contained in the application the target account belongs to, ( Para. 0078, To obtain comfort that a transaction has been processed and exists as an immutable (or difficult to modify) record on the distributed ledgers, a minimum number of confirmations (i.e., successful queries) may be required by the system to determine whether it should mark or otherwise flag a transaction as successfully completed. Such a process helps mitigate race conditions and double spending issues that could occur in a decentralized distributed system.; and Para. 0072, The one or more control commands are used to then interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation to update each of the plurality distributed ledgers by generating new sequential entries cryptographically linked to existing sequential entries.)
16. Regarding claim 13, Ortiz discloses wherein the transaction information comprises an identification information of a digital asset to be traded, (Para. In other embodiments, a control command generator is further included to encapsulate data payloads for propagation across the distributed ledgers, and these data payloads may relate to transactions and record transaction information, such as a transaction amount, a type of transaction, account identifiers, merchant information, etc.; and Para. 0102, The distributed ledger may be one or more cryptographically linked chains of sequential entries, each of the cryptographically linked chains relating to one or more virtual tokens, or groups (blocks) of virtual tokens that may have associated data payloads, such as value, quantity, conditions, type of virtual token, etc.)
and further comprising determining, according to the identification information, a state information of the digital asset to be traded, wherein the incentive information is determined in response to the state information indicating that the digital asset to be traded is allowed to be traded. (Para. 0075, Public and private key mechanisms are utilized to maintain (or in some embodiments bypass) privacy/security settings as between merchants (e.g., Store A may be prevented from querying/viewing/decrypting records stored in relation to Store B's loyalty rewards program). In some embodiments, key pairs are utilized to establish transactions and trades as between loyalty rewards programs. For example, each merchant/participating program may be associated with one or more key pairs that are utilized to validate transactions that convert from one virtual currency to another. In the context of conversions of one virtual currency to another, specially configured key pairs may be utilized such that both of the originating merchant/loyalty program and the recipient merchant/loyalty program are both able to see various aspects of the data payloads that are associated with points conversions.; and Para. 0093, Ledger consensus may be provided by way of propagation rules, which, for example, control whether a particular update or record should be posted to a particular distributed ledger. Each of the nodes is configured to propagate transactions to neighboring nodes such that over time, each of the distributed ledgers contains a difficult to modify record of sequential entries. These sequential entries are cryptographically linked together whereby the linkages can be utilized to efficiently verify records by processing predecessor records (e.g., using cascading hashes or application of cryptographic techniques).)
17. Regarding claim 14, Ortiz discloses an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions, when executed by the at least one processor, configured to cause the at least one processor to implement at least the method of claim 1, (Para. 0255-0257, FIG. 27 is a schematic diagram of computing device 2700, exemplary of an embodiment. As depicted, computing device 2700 includes at least one processor 2702, memory 2704, at least one I/O interface 2706, and at least one network interface 2708. Each processor 2702 may be, for example, any type of general-purpose microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, a programmable read-only memory (PROM), or any combination thereof. Memory 2704 may include a suitable combination of any type of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like.)
18. Regarding claim 18, Ortiz discloses an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions, when executed by the at least one processor, configured to cause the at least one processor to implement at least the method of claim 10, (Para. 0135-0136, Interface layer 300 may include, for example, a blockchain integration unit 306, a request processing unit 308, and an interface unit 310. The various nodes 302a-302e and computing devices may interface through network 350. Data may be stored on various types of storage technologies at data storage 324, such as physical storage devices (e.g., hard drives, solid state drives, flash memory, random access memory, read only memory), shared network resources that may be provided on an on-demand basis, etc. Data may be stored in the form of database records, flat files, relational records, non-relational records, text files, spreadsheets, extended markup language files, etc. The interface layer 300 is provided at some or all of the nodes of the node computing devices, the interface layer adapted 300 for receiving electronic instructions at payment transaction devices operatively linked to the corresponding node computing device. The electronic instructions include at least data transmissions representative of an electronic transaction, and the interface layer 300 is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens (e.g., virtual currencies) stored in a digital wallet linked to a user profile (e.g., a set of database records which may, for example, be related to corresponding digital locations and/or keys).
19. Regarding claim 19, Ortiz discloses a non-transitory computer-readable storage medium having computer instructions therein, the computer instructions configured to cause a computer system to implement at least the method of claim 1, (Para. 0136, The interface layer 300 is provided at some or all of the nodes of the node computing devices, the interface layer adapted 300 for receiving electronic instructions at payment transaction devices operatively linked to the corresponding node computing device. The electronic instructions include at least data transmissions representative of an electronic transaction, and the interface layer 300 is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens (e.g., virtual currencies) stored in a digital wallet linked to a user profile (e.g., a set of database records which may, for example, be related to corresponding digital locations and/or keys).
20. Regarding claim 20, Ortiz discloses an-transitory computer-readable storage medium having computer instructions therein, the computer instructions configured to cause a computer system to implement at least the method of claim 10, (Para. 0136, The interface layer 300 is provided at some or all of the nodes of the node computing devices, the interface layer adapted 300 for receiving electronic instructions at payment transaction devices operatively linked to the corresponding node computing device. The electronic instructions include at least data transmissions representative of an electronic transaction, and the interface layer 300 is configured to extract, from the electronic instructions, one or more control commands indicative of requests to generate, provision or process virtual tokens (e.g., virtual currencies) stored in a digital wallet linked to a user profile (e.g., a set of database records which may, for example, be related to corresponding digital locations and/or keys).
21. Regarding claim 21, Ortiz does not explicitly disclose wherein the instructions are further configured to cause the computer system to: sending a point exchange request to the blockchain network in response to the second existing incentive point being less than a predetermined value, wherein the point exchange request comprises a second quantity of incentive points requested for exchange and a third quantity of resources; update the second existing incentive point according to the second quantity, wherein the third quantity of resources corresponds to the second quantity of incentive points.
However, Swamidurai teaches wherein the instructions are further configured to cause the computer system to: sending a point exchange request to the blockchain network in response to the second existing incentive point being less than a predetermined value, wherein the point exchange request comprises a second quantity of incentive points requested for exchange and a third quantity of resources; update the second existing incentive point according to the second quantity, wherein the third quantity of resources corresponds to the second quantity of incentive points, (Para. 0009-0011. One example embodiment provides a system that includes a processor and memory, wherein the processor is configured to perform one or more of acquire consumer exploration of a product data from a blockchain, determine features of the product, receive a promotion plan from at least one product retailer node, and execute a smart contract to generate a plurality of promotion tokens based on the features of the product and the promotion plan. Another example embodiment provides a system that includes a processor and memory, wherein the processor is configured to perform one or more of detect a delivery of a trade promotion token by a retailer node on a blockchain, and execute a smart contract to: apply the trade promotion token to a purchase item and transfer incentive assets based on the trade promotion token to the retailer node and to a corresponding manufacturer node. Another example embodiment provides a method that includes one or more of acquiring, by a promotion processor node, consumer exploration of a product data from a blockchain, determining, by the promotion processor node, features of the product, receiving, by the promotion processor node, a promotion plan from at least one product retailer node, and executing a smart contract to generate a plurality of promotion tokens based on the features of the product and the promotion plan.)
One of ordinary skill in the art would have recognized that applying the known technique of Swamidurai to the known invention of Ortiz would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the computer-readable storage medium to include wherein the instructions are further configured to cause the computer system to: sending a point exchange request to the blockchain network in response to the second existing incentive point being less than a predetermined value, wherein the point exchange request comprises a second quantity of incentive points requested for exchange and a third quantity of resources; update the second existing incentive point according to the second quantity, wherein the third quantity of resources corresponds to the second quantity of incentive points result in an improved invention because applying said technique will ensure that all users keep their reward balances accurate, thus improving the overall performance of the invention.
22. Regarding claim 22, Ortiz does not explicitly disclose wherein the instructions are further configured to cause the computer system to: broadcast a point exchange request to at least some of the plurality of blockchain nodes in response to the point exchange request being received, wherein the point exchange request comprises a second point transfer path; call the smart contract for incentive points to verify the point exchange request, so as to determine whether the second point transfer path belongs to the predetermined path; determine that the point exchange request is verified successfully, in response to the second point transfer path belonging to the predetermined path; and update the first existing incentive point according to the point exchange request, in response to a target information being received from a predetermined proportion of nodes in the at least some nodes, wherein the target information indicates that the point exchange request is verified successfully, wherein the point exchange request further comprises a second quantity of incentive points requested for exchange and a third quantity of resources, and the third quantity of resources corresponds to the second quantity of incentive points.
However, Swamidurai teaches wherein the instructions are further configured to cause the computer system to: broadcast a point exchange request to at least some of the plurality of blockchain nodes in response to the point exchange request being received, wherein the point exchange request comprises a second point transfer path; call the smart contract for incentive points to verify the point exchange request, so as to determine whether the second point transfer path belongs to the predetermined path; determine that the point exchange request is verified successfully, in response to the second point transfer path belonging to the predetermined path; and update the first existing incentive point according to the point exchange request, in response to a target information being received from a predetermined proportion of nodes in the at least some nodes, wherein the target information indicates that the point exchange request is verified successfully, wherein the point exchange request further comprises a second quantity of incentive points requested for exchange and a third quantity of resources, and the third quantity of resources corresponds to the second quantity of incentive points, (Para. 0012-0014, Another example embodiment provides a method that includes one or more of detecting, by a promotion processor node, a delivery of a trade promotion token by a retailer node on a blockchain, and executing, by the promotion processor node, a smart contract to: apply the trade promotion token to a purchase item and transfer incentive assets based on the trade promotion token to the retailer node and to a corresponding manufacturer node. A further example embodiment provides a non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to perform one or more of acquiring consumer exploration of a product data from a blockchain, determining features of the product, receiving a promotion plan from at least one product retailer node, and executing a smart contract to generate a plurality of promotion tokens based on the features of the product and the promotion plan. A further example embodiment provides a non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to perform one or more of detecting a delivery of a trade promotion token by a retailer node on a blockchain, and executing a smart contract to: apply the trade promotion token to a purchase item and transfer incentive assets based on the trade promotion token to the retailer node and to a corresponding manufacturer node.
One of ordinary skill in the art would have recognized that applying the known technique of Swamidurai to the known invention of Ortiz would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate networking features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the computer-readable storage medium to include wherein the instructions are further configured to cause the computer system to: broadcast a point exchange request to at least some of the plurality of blockchain nodes in response to the point exchange request being received, wherein the point exchange request comprises a second point transfer path; call the smart contract for incentive points to verify the point exchange request, so as to determine whether the second point transfer path belongs to the predetermined path; determine that the point exchange request is verified successfully, in response to the second point transfer path belonging to the predetermined path; and update the first existing incentive point according to the point exchange request, in response to a target information being received from a predetermined proportion of nodes in the at least some nodes, wherein the target information indicates that the point exchange request is verified successfully, wherein the point exchange request further comprises a second quantity of incentive points requested for exchange and a third quantity of resources, and the third quantity of resources corresponds to the second quantity of incentive points result in an improved invention because applying said technique will ensure that requests are on the correct route to avoid fraudulent activity, thus improving the overall performance of the invention.
23. Regarding claim 23, Ortiz discloses wherein the transaction request comprises at least one selected from: a first request to issue the digital asset to the blockchain; and/or a second request to transfer the digital asset from a first blockchain account to a second blockchain account, (Para. 0006, one or more control commands indicative of requests to generate, provision or process virtual tokens stored in a digital wallet linked to a user profile, the one or more control commands adapted to interface with the plurality of distributed ledgers by recording electronic transactions to the distributed ledger corresponding to the node computing device that the interface layer is operating on, the electronic transactions representative of data records corresponding to the one or more control commands and adapted for propagation through the plurality of distributed ledgers through the communication links established between the individual node computing devices of the plurality of node computing devices,; and Claim 1. process transactions between a first digital wallet and a second digital wallet, the first digital wallet corresponding to a first merchant, and the second digital wallet corresponding to a second merchant by: receiving, from authentication interfaces associated with each of the first and the second merchant, a first private key associated with the first merchant and a second private key associated with the second merchant; determining, from a conversion table, a conversion rate to be applied as between transaction amounts from the first digital wallet and the second digital wallet; recording a first transaction on the first digital wallet using the first private key and the recordation of a second transaction on the second digital wallet using the second private key, the transaction amounts determined based at least on the conversion rate; and confirming the recordation of the first transaction and the second transaction by monitoring received confirmations related to both of the first and the second transaction until a total number of confirmations required in a variable confirmation requirement fields is satisfied.)
24. 24-25 are rejected under 35 U.S.C. 103(a) as being unpatentable over Ortiz et al. (US 20210117962 A1), in view of Swamidurai et al. (US 20190311392 A1), in view of Gutierrez-Sheris et al. (US 20200396065 A1), in view of Black et al. (US 20200051072 A1), in view of Harrison et al. (US 20200034869 A1), and further in view of Wu et el. (US 20210073815 A1).
25. Regarding claim 24, Ortiz as modified does not disclose wherein the verification of a transaction request comprises call of a smart contract for digital assets to verify the transaction information according to the signature and the public key.
However, Black teaches wherein the verification of a transaction request comprises call of a smart contract for digital assets to verify the transaction information according to the signature and the public key, (Para. 0009, According to one aspect, a blockchain-based transaction processing method may comprise: in response to a designated account being logged in through an application client, generating, according to input to-be-operated account information and configured operation content, an operation instruction comprising the to-be-operated account information and the operation content; and sending the operation instruction to a node in a blockchain network, causing the node in the blockchain network to invoke a smart contract corresponding to the designated account upon receiving the operation instruction, and to execute an operation according to the operation content on another account corresponding to the to-be-operated account information.; and Para. 0029, In one embodiment, when generating the operation instruction, the method may further comprises: using an algorithm to determine a summary of the operation instruction, and using a private key in a public-private key pair corresponding to the designated account to encrypt the summary to obtain an encrypted summary; and Para. 0045, In one embodiment, when an operation instruction is acquired, the account issuing the operation instruction (the issuing account herein can be interpreted as the designated account in S101) is determined, an algorithm (e.g., a pre-selected or set algorithm) is used to determine a summary of the operation instruction, and a public key in a public-private key pair corresponding to the issuing account is used to encrypt the summary to obtain an encrypted summary.; and Para. 0049, In one embodiment, to ensure the validity of subsequent operations, after an operation instruction is acquired, a digital signature (e.g., the encrypted summary) of the operation instruction can be further used to perform identity verification (also referred to as signature verification) on the designated account that sends the operation instruction to determine whether the account sending the operation instruction is a preset issuing account having the authority to send the operation instruction.)
One of ordinary skill in the art would have recognized that applying the known technique Wu to the known invention of Ortiz as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate smart conttact features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the verification of a transaction request comprises call of a smart contract for digital assets to verify the transaction information according to the signature and the public key result in an improved invention because applying said technique will ensure that transactions are verified by using public/private keys in smart contracts, thus improving the overall security of the invention.
26. Regarding claim 25, Ortiz as modified does not disclose wherein: the target account is a management account of an application in at least two applications; and the transaction information is transmitted by a blockchain account contained in the application the target account belongs to.
However, Wu teaches wherein: the target account is a management account of an application in at least two applications; and the transaction information is transmitted by a blockchain account contained in the application the target account belongs to,
(Para. 0076, In one embodiment, furthermore, different states can be set for the accounts. When the state of the account is set to be an opening state, the account can normally execute transactions; when the state of the account is set to be a closed state, the account stops execution of transactions. Here, the states of the accounts are controlled through the closing instruction and the opening instruction. When closing is needed, a management account of a securities agency can send a closing instruction to invoke a corresponding smart contract, such that the states of the accounts are adjusted to the closing state; when opening is needed, the management account of the securities agency can send an opening instruction to invoke a corresponding smart contract, such that the states of the accounts are adjusted to the opening state, thereby achieving an effect to control opening and closing of the blockchain.; and Para. 0023, S101: providing an application client for a designated account. The designated account in embodiments of the present disclosure may comprise a special account with administrative supervision capabilities. To ensure the security of the designated account, a dedicated application client (e.g., a software application) may be provided for the designated account. A designated account may use the same application client or different application clients for different administrative supervision capabilities. In other words, an application client can be provided to support the use thereon by designated accounts with a variety of administrative supervision capabilities, and different designated accounts can invoke corresponding functions according to their own needs. Furthermore, different application clients can be provided according to the needs of designated accounts, and each application client is used exclusively for a designated account, which is not limited herein.)
One of ordinary skill in the art would have recognized that applying the known technique Wu to the known invention of Ortiz as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate whitelist features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein each application is provided with at least two blockchain accounts, the at least two blockchain accounts comprise one management account, the whitelist comprises the management account of each of at least two applications, and only the management account in the at least two blockchain accounts provided for each application is used to maintain incentive points; and wherein the incentive point is issued with a generation of a genesis block of the blockchain, and a total quantity of the incentive points is a second predetermined quantity after the generation of the genesis block result in an improved invention because applying said technique will ensure that incentive points are maintained in one account and other accounts and making it restricted from unauthorized users, thus improving the overall security of the invention.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Systems and Method for Validation of Distributed Data Storage Systems (US 20210224792 A1) teaches a risk framework tool for a distributed ledger-based computing system (i.e., blockchain) that can present a common risk framework to a user that can then allow for the user to determine what risks are important for it to manage. The risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. In one or more examples, the risk framework can provide a graphical user interface to user that allows them specify the risks they wish to manage within the blockchain computing system, and based on the user's inputs, can determine one or more continuous real-time validation tests to be performed on the blockchain computing system so as to characterize the risk specified by user using the risk framework.
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
In addition to the foregoing, other aspects are described in the claims, drawings, and text. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/D.L.K./Examiner, Art Unit 3699
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699