DETAILED ACTIONNotice 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 . This is a Final Office Action in response to application 15/923,310 entitled "SYSTEMS AND METHODS FOR HYBRID BLOCKCHAIN PLATFORM" amended on December 23, 2025.
Status of Claims
Claims 1, 16, 30, and 37 have been amended and are hereby entered.
Claims 5, 20, and 31 were previously cancelled.
Claims 1-4, 6-19, 21-30 and 32-37 are pending and have been examined.
Response to Amendment
The amendment filed June 10, 2025, has been entered. Claims 1-4, 6-19, 21-30 and 32-37 remain pending in the application. Applicant’s amendments to the Specification, Drawings, and/or Claims have been noted in response to the Final Office Action mailed March 11, 2025.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on July 16, 2018 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement was considered by the examiner.
Claim Interpretation
In the interest of compact prosecution, Applicant should be aware that there is claim language that does not serve to differentiate the claims from the prior art and/or provide an additional element that can be a consideration for eligibility. See MPEP 2103(c):
The Examiner interprets the term “node” as any computer device connected to a network.
The Examiner interprets the term “block” as any data storage record.
Examiner’s Note
Intended use language is generally given limited patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” and “for.” The following limitations are interpreted as intended use limitations:
The Examiner would like to note that the claims are replete with intended use, however, to provide compact prosecution, the examiner has provided the mapping and rejections.
Claim 1: “distributed ledger for data integrity and validation”
Claim 1: “distributed ledger for reconciliation”
Claim 1: “distributed ledger for loyalty points management”
Claim 3: “distributed ledger for clearing and settlement”
Claim 10: “distributed ledger for loyalty points management”
Claim 16: “distributed ledger for data integrity and validation”
Claim 16: “distributed ledger for reconciliation”
Claim 16: “distributed ledger for loyalty points management”
Claim 18: “distributed ledger for clearing and settlement.”
Claim 24: “distributed ledger for loyalty points management”
Claim 30: “distributed ledger for data integrity and validation”
Claim 30: “distributed ledger for reconciliation”
Claim 30: “distributed ledger for loyalty points management”
Claim 34: “so that the loyalty account for the customer is no longer available for loyalty transactions.”
The Examiner determines the aforementioned intended use statements do not result in any structural nor manipulative difference between the claimed invention and the prior art. Therefore, the intended use statements are afforded limited patentable weight.
Claim Objections
Claim 1 is objected to because of the following informalities: the amended claim reads, “and does not permit access by non authorized devices information stored on the private distributed ledger.” Examiner interprets the language to read, “and does not permit access by non authorized device information stored on the private distributed ledger.” Appropriate correction is required.
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.
Claims 1-4, 6-19, 21-30 and 32-35 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Vijayvergia (“MANAGING BLOCKCHAIN ACCESS”, US Patent Number: US 10833843 B1), in view of Valencia (“METHOD OF, SYSTEM FOR, DATA PROCESSING DEVICE, AND INTEGRATED CIRCUIT DEVICE FOR IMPLEMENTING A DISTRIBUTED, LEDGER-BASED PROCESSING AND RECORDING OF AN ELECTRONIC FINANCIAL TRANSACTION”, US Publication Number: US 20190303931 A1),in view of Taylor (“LOYALTY PROMOTION APPARATUSES, METHODS AND SYSTEMS”, U.S. Publication Number: US 20120101881 A1).
Regarding Claim 1,
Vijayvergia teaches,
A computer-implemented system having a private distributed ledger
(Vijayvergia [Col 2, Lines 36-40] access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain
Vijayvergia [Col 1, Lines 20-21] A business may employ blockchains to store data)
the system comprising: a plurality of trusted computing devices
(Vijayvergia [Col 4, Lines 26-28] system may include one or more access management devices 102. The access management device(s) 102 may include any type of computing device
Vijayvergia [Col 5, Lines 48-55] the accessor ID 208 may include an identifier of a computing device, such as an internet protocol (IP) address, media access control (MAC) address, or other device identifier. In some examples, the accessor ID 208 may include a device identifier previously established between the external computing device and the access management module(s) 104.
Vijayvergia [Abstract] An authorized entity may employ the key
Vijayvergia [Col 1, Lines 60-61] identifies a computing system that is authorized to access)
platform of a plurality of private nodes, each private node including at least one trusted computing device
(Vijayvergia [Col 10, Lines 8-12] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate
Vijayvergia [Col 3, Lines 44-45] from either public or private entities)
configured to maintain and update a private distributed ledger
(Vijayvergia [Col 8, Lines 2-4] An external party, such as a body shop, may wish to update the private blockchain 110 to verify that a repair was complete and receive payment)
the private distributed ledger having a block storing a … profile for a customer identifier with a status of active
(Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts
Vijayvergia [Col 8, Lines 2-4] may wish to update the private blockchain
Vijayvergia [Col 9, Lines 56-57] A block 302 may include, or be associated with a list of transaction(s)
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login)
and a unique … profile identifier,
(Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login
Vijayvergia [Col 8, Lines 44-47] key 118 is associated with a particular accessor ID 208 of the body shop, such as an IP address, MAC address, or a unique address or identifier)
wherein the plurality of private nodes are in communication with one another to store and maintain replicated private distributed ledgers that are synchronized across the plurality of private nodes,
(Vijayvergia [Col 10, Lines 8-12] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate
Vijayvergia [Col 3, Lines 44-45] from either public or private entities
Vijayvergia [Col 10, Lines 15-18] blockchain protocol provides a secure and reliable method of updating the blockchain, copies of which are distributed across the peer-to-peer network
Vijayvergia [Col 11, Lines 21-23] all copies of the blockchain are updated across the peer-to-peer network )
wherein the private distributed ledger only permits access by trusted computing devices to information stored on the private distributed ledger and does not permit access by non authorized devices information stored on the private distributed ledger,
(Vijayvergia [Col 6, Lines 23-25] The external blockchain(s) 114 may also include private blockchain(s) for which access is restricted to authorized entities.
Vijayvergia [Col 11, Lines 53-55 ] may specify the particular blockchain 110 to be accessible using the key 118, the portion(s) of the blockchain 110 to be accessible, the time constraints, the accessor ID, the access type, or other restrictions on the access.
Vijayvergia [Col 2, Lines 37-41] access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain, or between two private blockchains associated with different entities.)
the private distributed ledger links the block to the other blocks of the private distributed ledger to provide data integrity and validation,
(Vijayvergia [Col 9, Lines 52-55] a blockchain 300 may include any number of blocks 302, in this example numbered 1 through N where N is any number.
Vijayvergia [Col 10, Lines 2-3] A blockchain constantly grows as completed blocks are added with a new set of transactions.
Vijayvergia [Col 2, Lines 43-45] blockchains to communicate with other blockchains (e.g., the Bitcoin™ blockchain or other public or private blockchains) over a network
Vijayvergia [Col 10, Lines 42-44] Validation of transactions includes verifying digital signatures associated with respective transactions)
enables one or more … devices to interact with the plurality of private nodes, wherein transaction data is provided to the … platform
(Vijayvergia [Col 4, Lines 27-42] The access management device(s) 102 may include any type of computing device, such as server computers, distributed computing devices (e.g., cloud servers), network management appliances (e.g., hubs, routers, gateway devices, etc.), and so forth. ....access management module(s) 104 may control whether external users, processes, devices, blockchains, or other external entities are permitted to access data stored on one or more internal blockchains 110.
Vijayvergia [Col 9, Lines 56-59] A block 302 may include, or be associated with a list of transaction(s) 304. The transaction(s) 304 may include the data stored in the blockchain)
providing a plurality of public nodes which maintain and update a public distributed ledger with blocks that correspond to transactions
(Vijayvergia [Abstract] entity may be an external (e.g., public) blockchain, device
Vijayvergia [Col 6, Lines 21-22] may include public blockchain(s) that store data generally accessible by users, devices
Vijayvergia [Col 10, Lines 10-11] peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device
Vijayvergia [Col 10, Lines 13-17] Each node maintains a copy of the blockchain, which is automatically downloaded to the node upon joining the peer-to-peer network. The blockchain protocol provides a secure and reliable method of updating the blockchain
Vijayvergia [Col 10, Lines 2-3] A blockchain constantly grows as completed blocks are added with a new set of transactions)
wherein the plurality of public nodes are in communication with one another to store and maintain replicated public distributed ledgers
(Vijayvergia [Col 10, Lines 10-11] peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device
Vijayvergia [Col 6, Lines 21-22] may include public blockchain(s) that store data generally accessible by users, devices
Vijayvergia [Col 10, Lines 15-18] The blockchain protocol provides a secure and reliable method of updating the blockchain, copies of which are distributed across the peer-to-peer network)
that are synchronized across the plurality of public nodes,
(Vijayvergia [Col 10, Lines 12-14] each node being a computing device that uses a client to validate and relay transactions (e.g., deposits of checks). Each node maintains a copy of the blockchain, which is automatically downloaded)
wherein the publicly distributed ledger stores a mirrored set of transaction blocks with the privately distributed ledger
(Vijayvergia [Col 10, Lines 12-14] each node being a computing device that uses a client to validate and relay transactions (e.g., deposits of checks). Each node maintains a copy of the blockchain)
wherein the public distributed ledger interoperates with the private distributed ledger…for reconciliation
(Vijayvergia [Col 2, Liens 36-40] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain)
to ensure the mirrored set of transaction blocks of the public distributed ledger mirror blocks of the private distributed ledger and integrity validation to ensure the blocks are not corrupt,
(Vijayvergia [Col 10, Lines 12-14] each node being a computing device that uses a client to validate and relay transactions (e.g., deposits of checks). Each node maintains a copy of the blockchain
Vijayvergia [Col 10, Lines 19-29] Because all users (e.g., financial institutions) need to know all previous transactions (e.g., check deposits) to validate a requested transaction (e.g., check deposit), all users must agree on which transactions have actually occurred, and in which order.... The blockchain enables all users to come to an agreement as to transactions that have already occurred, and in which order. In short, and as described in further detail below, a ledger of transactions is agreed
Vijayvergia [Col 2, Liens 36-40] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain)
wherein the private distributed ledger privately and securely onboards a plurality of merchants and issues .... points, wherein the private distributed ledger such that the private distributed ledger maintains private data for ...transactions and the public distributed ledger allows certain elements of the private data for the loyalty transactions to be publicly available;
(Vijayvergia [Col 2, Lines 34-41] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain, or between two private blockchains associated with different entities.
Vijayvergia [Col 3, Lines 47-52] determine access rights and determine the particular private information to be accessible by external (e.g., public) blockchains. The access management module(s) may also control communications between two private blockchains with differing access permissions
Vijayvergia [Col 6, Line 63 to Col 7, Line 7] access management module(s) 104 also control the communication of data from the (e.g., private) blockchain 110 to external device(s) 112, external blockchain(s) 114, or other external entities. The access management module(s) 104 employ a set of rules 126 that govern the external (e.g., outbound) communication of data from internal blockchain(s) 110. ... that govern when, to whom, and under what conditions data from the blockchain(s) 110 may be communicated externally.
Vijayvergia [Col 12, Lines 54-51] The access management module(s) 104 may also control the communication of data from the (e.g., private) blockchain 110 to external entities. In some implementations, the access management module(s) 104 employ a set of rules 126 that govern the external communication of data... access management module(s) 104 may permit such public dissemination of information)
wherein the public distributed ledger validates the ... transactions and then forwards the transactions to the private distributed ledger, wherein the private distributed ledger to processes the ... transactions;
(Vijayvergia [Col 10, Lines 10-14] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate and relay transactions
Vijayvergia [Col 10, Lines 41-43] Validation of transactions includes verifying digital signatures associated with respective transactions.)
at least one communication interface between a trusted computing device of at least one of the plurality of private nodes and a device of at least one public node of the plurality of public nodes to enable the trusted computing devices of the private nodes to exchange data with the public nodes
(Vijayvergia [Col 4, Lines 26-28] system may include one or more access management devices 102. The access management device(s) 102 may include any type of computing device
Vijayvergia [Col 5, Lines 48-55] the accessor ID 208 may include an identifier of a computing device, such as an internet protocol (IP) address, media access control (MAC) address, or other device identifier. In some examples, the accessor ID 208 may include a device identifier previously established between the external computing device and the access management module(s) 104.
Vijayvergia [Col 1, Lines 60-61] identifies a computing system that is authorized to access
Vijayvergia [Col 13, Lines 37-38] one or more input/output (I/O) devices 750 controllable via one or more I/O interfaces
Vijayvergia [Col 2, Liens 36-40] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain
Vijayvergia [Col 7, Lines 42-49] an environment may include multiple private, public, and/or consortium blockchains and communications among the different blockchains may be controlled by different access management modules 104 or the same access control module(s) 104. The different access management modules 104 may execute on different access management device(s) 102, or on a same set of one or more access management devices)
wherein the at least one communication interface exchanges data between the trusted computing devices of the private nodes data and the public nodes, wherein the at least one communication interface transmits notification messages
(Vijayvergia [Col 9, Lines 24-25] may receive a notification (e.g., a push notification) from the access management module(s))
wherein at least one private node is configured for: receives from the device of at least one of the public nodes, via the at least one communication interface, a notification message
(Vijayvergia [Col 9, Lines 24-25] may receive a notification (e.g., a push notification) from the access management module(s)
Vijayvergia [Col 10, Lines 8-12] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate
Vijayvergia [Col 3, Lines 44-45] from either public or private entities)
identifying a transaction for posting; monitors at least one of the public nodes for a confirmation record that the transaction has been cleared on the public distributed ledger,
(Vijayvergia [Col 5, Lines 11-16] may be employed to manage access to data stored in a blockchain 110, according to implementations of the present disclosure. As shown in the example of FIG. 2, a portion of metadata 106 may include a key 118. In some examples, the metadata 106 includes a reference to, or an identifier of, the key 118 instead of or in addition to the key 118 itself.
Vijayvergia [Col 10, Lines 2-13] A blockchain constantly grows as completed blocks are added with a new set of transactions. In some examples, a single block is provided from multiple transactions (e.g., multiple deposits of different checks by different people). In general, blocks are added to the blockchain ...each node being a computing device that uses a client to validate and relay transactions
Vijayvergia [Col 10, Lines 21-24] to validate a requested transaction (e.g., check deposit), all users must agree on which transactions have actually occurred
Vijayvergia [Col 2, Lines 36-40] access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain)
the confirmation record indicating a transaction identifier for the transaction; and upon obtaining the confirmation record that the transaction has been cleared
(Vijayvergia [Col 8, Lines 54-64] The access management module(s) 104 may verify that the access request 116 satisfies the restrictions in the metadata 106 governing use of the key 118. For example, the access management module(s) 104 may confirm...the target blockchain area ID(s) 204 for the key 118. The access management module(s) 104 may confirm that the key 118 is being used according to the prescribed time constraint(s) 206, and that the access request 116 is coming from an address associated with the accessor ID 208.
Vijayvergia [Col 10, Lines 59-62] details of the transaction(s) that are to be included in the to be created block, and a nonce value (e.g., a random number used only once).)
on the public distributed ledger,
(Vijayvergia [Col 2, Lines 36-40] access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain)
generating signals to initiate propagation of the transaction to the plurality of private nodes,
(Vijayvergia [Col 15, Lines 57-67] a composition of matter effecting a machine-readable propagated signal...A propagated signal is an artificially generated signal
Vijayvergia [Col 10, Lines 13-18] Each node maintains a copy of the blockchain, which is automatically downloaded to the node upon joining the peer-to-peer network. The blockchain protocol provides a secure and reliable method of updating the blockchain, copies of which are distributed across the peer-to-peer network
Vijayvergia [Col 10, Lines 8-12] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate
Vijayvergia [Col 3, Lines 44-45] from either public or private entities)
wherein the propagation of the transaction is based on a plurality of propagation rules that are applied and maintained at each private node, wherein the plurality of propagation rules control the addition of the transaction to the private distributed ledger;
(Vijayvergia [Abstract] key may be associated with metadata that includes constraints, conditions, or rules governing access to the blockchain.
Vijayvergia [Col 2, Lines 56-58] The implementations described herein provide an access control mechanism for controlling access to data stored on a private blockchain
Vijayvergia [Col 3, Lines 49-51] access management module(s) may also control communications between two private blockchains with differing access permissions
Vijayvergia [Col 3, Line 67 to Col 4, Line 2] access management module(s) enable internal (private) blockchains to communicate and transfer data with external (public) or internal (private) blockchains
Vijayvergia [Col 10, Lines 8-12] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate
Vijayvergia [Col 10, Lines 2-13] A blockchain constantly grows as completed blocks are added with a new set of transactions. In some examples, a single block is provided from multiple transactions (e.g., multiple deposits of different checks by different people). In general, blocks are added to the blockchain ...each node being a computing device that uses a client to validate and relay transactions)
receive a … event notification indicating a … event for a … transaction with the token, the … event in relation to the transaction, wherein the … event notification
(Vijayvergia [Col 9, Lines 24-25] may receive a notification (e.g., a push notification) from the access management module(s)
Vijayvergia [Col 4, Lines 8-14] may include ephemeral (e.g., expiring) tokens, which throttle write permissions.
Vijayvergia [Col 1, Lines 21-23] blockchains provide a publicly accessible record of transactions regarding stored data
Vijayvergia [Col 9, Lines 56-57] a list of transaction(s))
transmit the … event notification and the customer identifier to the communication interface
(Vijayvergia [Col 9, Lines 24-25] may receive a notification (e.g., a push notification) from the access management module(s)
Vijayvergia [Col 4, Lines 8-14] may include ephemeral (e.g., expiring) tokens, which throttle write permissions.
Vijayvergia [Col 1, Lines 21-23] blockchains provide a publicly accessible record of transactions regarding stored data
Vijayvergia [Col 9, Lines 56-57] a list of transaction(s)
Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login
Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts
Vijayvergia [Col 13, Lines 37-38] one or more input/output (I/O) devices 750 controllable via one or more I/O interfaces)
for provision to at least one of the plurality of trusted computing devices providing the … platform using the token;
(Vijayvergia [Col 4, Lines 26-28] system may include one or more access management devices 102. The access management device(s) 102 may include any type of computing device
Vijayvergia [Col 5, Lines 48-55] the accessor ID 208 may include an identifier of a computing device, such as an internet protocol (IP) address, media access control (MAC) address, or other device identifier.
Vijayvergia [Abstract] An authorized entity may employ the key
Vijayvergia [Col 1, Lines 60-61] identifies a computing system that is authorized to access
Vijayvergia [Col 4, Lines 8-14] may include ephemeral (e.g., expiring) tokens, which throttle write permissions. )
and wherein the at least one of the plurality of trusted computing devices creates, using the … identifier, a block for the … transaction for the … event notification
(Vijayvergia [Abstract] An authorized entity may employ the key
Vijayvergia [Col 1, Lines 60-61] identifies a computing system that is authorized to access
Vijayvergia [Col 1, Line 65 to Col 2, Line 2] the metadata identifies the computing system using one or more of: an internet protocol (IP) address of the computing system; a media access control (MAC) address of the computing system; or an identifier associated with an operator of the computing system
Vijayvergia [Col 10, Lines 59-60] details of the transaction(s) that are to be included in the to be created block
Vijayvergia [Col 9, Lines 24-25] may receive a notification (e.g., a push notification) from the access management module(s))
using a private node to maintain and update the private distributed ledger for … points management, the block for the … transaction indicating the … identifier, the customer identifier,
(Vijayvergia [Col 6, Lines 53-55] access management module(s) 104 to be used for updating the blockchain
Vijayvergia [Col 8, Lines 2-3] may wish to update the private blockchain
Vijayvergia [Col 1, Line 65 to Col 2, Line 2] the metadata identifies the computing system using one or more of: an internet protocol (IP) address of the computing system; a media access control (MAC) address of the computing system; or an identifier associated with an operator of the computing system
Vijayvergia [Col 1, Lines 16-17] store information regarding customer accounts
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login
Vijayvergia [Col 12, Lines 55-56] the individual customer (e.g., policy holder) associated with the data)
the transaction identifier for the transaction,
(Vijayvergia [Col 10, Lines 59-62] details of the transaction(s) that are to be included in the to be created block, and a nonce value (e.g., a random number used only once).)
wherein the plurality of trusted computing devices providing the … platform maintain a … account for the customer using the block for the … transaction indicating the customer identifier, the transaction identifier for the transaction
(Vijayvergia [Col 1, Lines 16-17] store information regarding customer accounts
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login
Vijayvergia [Col 10, Lines 59-62] details of the transaction(s) that are to be included in the to be created block, and a nonce value (e.g., a random number used only once).)
the block storing the … profile for the customer identifier
(Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login
Vijayvergia [Col 8, Lines 44-47] key 118 is associated with a particular accessor ID 208 of the body shop, such as an IP address, MAC address, or a unique address or identifier)
with the status of active
(Vijayvergia [Col 7, Lines 54-62] consortium blockchains may be governed by proof of stake rules. For example, a consortium member may provide a stake to “buy in” to a blockchain, and that stake may be surrendered if the consortium member violates terms of use of the blockchain. In some implementations, the access management module(s) 104 may be configured to police use of the blockchain(s) and determine violations that may necessitate loss of stake by consortium member(s)
Vijayvergia [Col 10, Lines 44-46] a miner must demonstrate a proof of work before their proposed block of transactions is accepted by the peer-to-peer network)
and the unique … profile identifier
(Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts
Vijayvergia [Col 5, Lines 56-60] accessor ID 208 may also identify particular user(s)....may include one or more of a user name, user ID, user login
Vijayvergia [Col 8, Lines 44-47] key 118 is associated with a particular accessor ID 208 of the body shop, such as an IP address, MAC address, or a unique address or identifier)
wherein the trusted computing device has smart contract code providing an exchange contract that automatically implements an exchange function for … account management
(Vijayvergia [Col 3, Lines 53-55] access management module(s) are implemented as a smart contract or other software
Vijayvergia [Col 15, Lines 63-64] code that creates an execution environment for the computer program
Vijayvergia [Col 4, Lines 4-8] Making use of smart contracts, the access management module(s) may be smart contract(s), upon which a blockchain and smart contract infrastructure sits. This allows more fine-grained access control
Vijayvergia [Col 7, Lines 51-53] smart contracts, and may interact with one another to reach consensus regarding the communication of blockchain data to various entities
Vijayvergia [Col 1, Lines 16-17] generate and store information regarding customer accounts)
Vijayvergia does not teach wherein the system processes and settles transactions relating to loyalty points using the private distributed ledger and a public distributed ledger; providing a loyalty; for and manage loyalty points; merchant; wherein a merchant application programming interface; by the merchant application programming interface; wherein the public distributed ledger interacts with the private distributed ledger by way of a clearing adaptor and communications are provided via a notification application programming interface;a clearing and settlement platform of devices; and loyalty points; allows a plurality of merchants to privately and securely onboard and issue loyalty points; for loyalty events; non-transitory computer readable storage medium storing an electronic wallet application with computer- executable instructions for causing a processor of a mobile device to: store an electronic loyalty card token for mobile payment, the token linking the loyalty platform to the customer identifier; is linked to a merchant identifier to identify the loyalty transaction for the merchant application programming interface; and an amount of loyalty points for the loyalty event; and the amount of loyalty points for the loyalty event; wherein the merchant application programming interface; retrieves a merchant loyalty identifier corresponding to a loyalty program of the merchant and the customer's points balance for the merchant, wherein the merchant application programming interface maps the merchant loyalty identifier to the loyalty profile for the customer identifier to register the customer with the merchant's loyalty program on the loyalty platform, wherein the merchant loyalty identifier represents a loyalty card for the merchant owned by the customer to access the merchant's loyalty program; to convert the amount of loyalty points for the loyalty event by applying configured rates and rules stored on the private distributed ledger for loyalty points management or dynamic exchange, wherein the exchange contract performs a balance check before responding to exchange requests to ensure the merchant has sufficient points for the loyalty event, wherein the exchange contract responds to exchange requests using the merchant identifier and the merchant application interface by converting the amount of loyalty points for the loyalty event and returning the converted amount of loyalty points for the event; and wherein the trusted computing device transmits a notification message for the loyalty event to the communication interface, the notification message indicating the customer identifier, the transaction identifier for the transaction, and the amount of loyalty points for the loyalty event.
Valencia teaches,
wherein the system processes and settles transactions relating to loyalty points using the private distributed ledger and a public distributed ledger;
(Valencia [0125] e-wallet account can take multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points).
Valencia [0012] payment or transaction cycle is required ... to clearing and settlement of accounts .... clearing and settlement processes using the infrastructure of the technology network;
Valencia [0011] by interacting with other ledgers representing the accounts of the acquirer, merchant, issuer, and the clearing and settlement bank.
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system.)
providing a loyalty; for loyalty points management; loyalty; and loyalty points; for loyalty events; loyalty transactions;
(Valencia [Abstract] a distributed, ledger-based processing and recording of an electronic financial transaction
Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)...for performing cross-border transactions)
merchant;
(Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0011] by interacting with other ledgers representing the accounts of the acquirer, merchant, issuer, and the clearing and settlement bank.)
wherein a merchant application programming interface; by the merchant application programming interface;
(Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface)
wherein the public distributed ledger interacts with the private distributed ledger by way of a clearing adaptor
(Valencia [Absract] may be private ledgers, public ledgers, or hybrids of private and public ledgers.
Valencia [0046] a public or private data network, a hybrid public and private data network
Valencia [0009] it is back-end dependent in that the authorization, clearing and settlement processes go through the backend infrastructure a number of times to ensure completion of the transaction
Valencia [0011] by interacting with other ledgers representing the accounts of the acquirer, merchant, issuer, and the clearing and settlement bank.)
a clearing and settlement platform of devices;
(Valencia [0045] Automatic debit and credit among the various accounts and the ledgers associated with the accounts of the participants (e.g., subscribers, issuers, acquirers, merchants, clearing and settlement banks) until all the transactions are fully cleared and settled.
Valencia [0166] a process for settling the banking and financial transactions is also described herein. Settlement involves the actual exchange of funds.)
allows a plurality of merchants to privately and securely onboard and issue loyalty points;
(Valencia [0012] payment of merchants and the community may be done efficiently in clusters
Valencia [0142] To link the subscriber's SIM card to his issuer accounts, the subscriber may register his e-passbook and e-wallet accounts
Valencia [0143] Upon validation, the issuer may link the subscriber's SIM card with his issuer accounts...the subscriber may be able to access his issuer accounts, as well as transfer funds from his issuer accounts to his e-wallet application
Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0142] may register his e-passbook and e-wallet accounts via encrypted SMS (short messaging service) or secured TCP/IP connection
Valencia [0086] transact in a hassle-free manner, not to mention discrete and private manner.)
non-transitory computer readable storage medium storing an electronic wallet application with computer- executable instructions for causing a processor of a mobile device to: store an electronic loyalty card token for mobile payment,
(Valencia [0171] computer program product which comprises a further non-transitory computer usable medium having a computer readable program code embodied therein
Valencia [Abstract] itself or incorporated in or linked to other devices like a mobile phone
Valencia [0098] for storing information
Valencia [0099] IC memory system 232 a for storing information about the e-wallet account
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).)
the token linking the loyalty platform to the customer identifier;
(Valencia [0056] a recipient transaction account, and a secure transaction token
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0064] various information such as account IDs, personal information, transaction history information)
is linked to a merchant identifier to identify the loyalty transaction for the merchant application programming interface;
(Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface)
and an amount of loyalty points for the loyalty event; and the amount of loyalty points for the loyalty event;
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0045] debits and credits columns may be automatically generated and/or updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account)
wherein the merchant application programming interface;
(Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface)
retrieves a merchant loyalty identifier corresponding to a loyalty program of the merchant and the customer's points balance for the merchant, wherein the merchant application programming interface maps the merchant loyalty identifier to the loyalty profile for the customer identifier
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account which is distinct from the source transaction account, and debit and credit related data associated with the source and recipient transaction accounts
Valencia [0045] debits and credits columns may be automatically generated and/or updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account)
to register the customer with the merchant's loyalty program on the loyalty platform,
(Valencia [0142] To link the subscriber's SIM card to his issuer accounts, the subscriber may register his e-passbook and e-wallet accounts
Valencia [0143] Upon validation, the issuer may link the subscriber's SIM card with his issuer accounts...the subscriber may be able to access his issuer accounts, as well as transfer funds from his issuer accounts to his e-wallet application
Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.)
wherein the merchant loyalty identifier represents a loyalty card for the merchant owned by the customer to access the merchant's loyalty program;
(Valencia [0011] the distributed ledger system or similar technology, and may be incorporated into an integrated circuit device (e.g., a chip in a card, NFC-enabled SIM card, SIM card) which, by itself or incorporated in or linked to other devices like a mobile phone, a POS reader, tablet, computer or similar devices
Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account)
to convert the amount of loyalty points for the loyalty event by applying configured rates and rules stored on the private distributed ledger for loyalty points management or dynamic exchange,
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0045] the term “ledger” may refer to a computer-generated and/or computer-based principal book or “digital passbook” for recording monetary values which are associated with transactions conducted using transaction accounts. The digital passbook may be a computer-based file which is provided with debits and credits in separate columns....updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account ... Automatic debit and credit among the various accounts and the ledgers associated with the accounts of the participants
Valencia [0009] processes, rules, and players (such as tokenization, payment gateways, etc.) have been added to the existing payment system
Valencia [0060] In order to ensure the integrity of these virtual currencies, established protocols, which are implemented as software algorithms, may be followed by participating entities or nodes for various transactions including currency production and exchange.)
wherein the exchange contract performs a balance check before responding to exchange requests to ensure the merchant has sufficient points for the loyalty event,
(Valencia [0012] wherein the subscriber, knowing his available balance for payment in his digital passbook or ledger...the account balances associated with it, may be synchronized... its associated balance to the subscriber enables the subscriber to authorize a merchant to debit his transaction account
Valencia [0045] may include a beginning balance and an ending balance for each transaction account
Valencia [0085] guarantees the monetary value that is associated with the source transaction account owned by a subscriber and hence the balance associated with the source transaction account is known and/or available on-demand to the subscriber
Valencia [0009] enable the transaction to push through and be cleared and settled; ...dependent in that the authorization, clearing and settlement processes go through the backend infrastructure a number of times to ensure completion of the transaction; and (iv) over time, more processes, rules, and players (such as tokenization, payment gateways, etc.) have been added to the existing payment system thus preventing friction costs
Valencia [0043] data recording and tracking system for ensuring validity of the transactions performed
Valencia [0122] ensure completeness of transactions, prevent overloading, and enable reliable auditing)
wherein the exchange contract responds to exchange requests using the merchant identifier and the merchant application interface
(Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface)
by converting the amount of loyalty points for the loyalty event and returning the converted amount of loyalty points for the event;
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0045] the term “ledger” may refer to a computer-generated and/or computer-based principal book or “digital passbook” for recording monetary values which are associated with transactions conducted using transaction accounts. The digital passbook may be a computer-based file which is provided with debits and credits in separate columns....updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account ... Automatic debit and credit among the various accounts and the ledgers associated with the accounts of the participants
Valencia [0009] processes, rules, and players (such as tokenization, payment gateways, etc.) have been added to the existing payment system
Valencia [0060] In order to ensure the integrity of these virtual currencies, established protocols, which are implemented as software algorithms, may be followed by participating entities or nodes for various transactions including currency production and exchange.)
and wherein the trusted computing device transmits a notification message for the loyalty event to the communication interface, the notification message
(Valencia [0043] may include blocks containing data which are represented by transactions and/or transaction messages
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface)
indicating the customer identifier, the transaction identifier for the transaction, and the amount of loyalty points for the loyalty event.
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0059] Whether the extracted source transaction account identifier (ID)
Valencia [0087] identifiers associated with the transaction message 404 a (e.g., source account ID, recipient account ID, and transaction token ID)
Valencia [0045] debits and credits columns may be automatically generated and/or updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Valencia does not teach communications are provided via a notification application programming interface.
Taylor teaches,
communications are provided via a notification application programming interface
(Taylor [0224] Dedicated communication systems 81020, 81022 (e.g., private communication network(s)) facilitate communication between the transaction handler (th) 81002 and each issuer (i) 81004 and each acquirer (a) 81006. A Network 81012, via e-mail, the World Wide Web, cellular telephony, and/or other optionally public and private communications systems, can facilitate communications
Taylor [0103] integrate APIs
Taylor [0142] provide APIs... to facilitate rapid on-boarding and campaign implementation... for ongoing offers/loyalty campaign management, partners are open platforms (e.g., Facebook, Twitter, Foursquare and other open platforms can be leveraged to provide retailer benefits and spread the application virally).)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the loyalty program hybrid public-private blockchain ledgers of Valencia to incorporate the notifications of Taylor for “Dedicated communication systems 81020, 81022 (e.g., private communication network(s)) facilitate communication” (Taylor [0224]). The modification would have been obvious, because it is merely applying a known technique (i.e. notifications) to a known concept (i.e. loyalty hybrid public-private blockchain ledgers) ready for improvement to yield predictable result (i.e. “to facilitate communication between the transaction handler (th) 81002 and each issuer (i) 81004 and each acquirer.” Taylor [0224])
Regarding Claim 2,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the loyalty platform is configured to maintain loyalty rules for calculating a loyalty point amount for the loyalty transaction for the loyalty event notification and store the loyalty point amount as part of the block for the loyalty transaction.
Valencia teaches,
wherein the loyalty platform is configured to maintain loyalty rules for calculating a loyalty point amount for the loyalty transaction for the loyalty event notification and store the loyalty point amount as part of the block for the loyalty transaction.
(Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0012] account balances associated with it
Valencia [0149] as long as the POS reader has a balance of money or tokens, it may be arranged to dispense such balance in an online or offline mode.
Valencia [0009] many rules to protect the stability, security and integrity of the system... processes, rules, and players (such as tokenization, payment gateways, etc.)
Valencia [0053] transmitting, ...the transaction authorization message
Valencia [0092] ledger associated with the subscriber's account may also be recorded on the device-resident ledger system which is preferably stored on the subscriber's payment device and is preferably tracked by the distributed ledger system)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 3,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach at least one communication interface between at least one of the plurality of nodes and at least one public node of a plurality of public nodes which maintain and update a public distributed ledger for clearing and settlement for transactions relating to loyalty points; wherein the loyalty platform is configured to receive a clearing and settlement notification for a transaction notification from the public distributed ledger; and transmit the loyalty event notification to the electronic wallet application.
Valencia teaches,
at least one communication interface between at least one of the plurality of nodes and at least one public node of a plurality of public nodes which maintain and update a public distributed ledger for clearing and settlement for transactions relating to loyalty points;
(Valencia [0010] a distributed ledger system associated with the cluster of participating nodes. The distributed ledgers associated with the distributed ledger system may be .... public ledgers
Valencia [0012] ledger system...may be synchronized and updated
Valencia [0057] one or more distributed nodes 402 may be located in a distributed network on which a distributed ledger system 400 resides and/or with which the distributed ledger system 400 is interfaced through any suitable API (application programming interface).
Valencia [0155] process the transactions for clearing and settlement
Valencia [0151] secured network of electronic devices
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).)
wherein the loyalty platform is configured to receive a clearing and settlement notification for a transaction notification from the public distributed ledger; and transmit the loyalty event notification to the electronic wallet application.
(Valencia [0155] process the transactions for clearing and settlement
Valencia [0043] transaction messages, linking data
Valencia [0053] a transaction authorization message in response to a second input signal received at the transaction device
Valencia [0036] an electronic wallet account associated with the integrated circuit device.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 4,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 3 as described earlier.
Vijayvergia does not teach wherein the transaction notification is linked to the merchant identifier and the loyalty platform is configured to use the merchant identifier for generating the block.
Valencia teaches,
wherein the transaction notification is linked to the merchant identifier and the loyalty platform is configured to use the merchant identifier for generating the block.
(Valencia [0043] may include blocks containing data which are represented by transactions and/or transaction messages
Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account
Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points))
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 6,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach further comprising an adaptor for managing communications between the electronic wallet application and the loyalty platform, the communications involving at least one call to an application programming interface.
Valencia teaches,
comprising an adaptor for managing communications between the electronic wallet application and the loyalty platform, the communications involving at least one call to an application programming interface.
(Valencia [0012] payment of merchants and the community may be done efficiently in clusters
Valencia [0142] To link the subscriber's SIM card to his issuer accounts, the subscriber may register his e-passbook and e-wallet accounts
Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0060] In order to ensure the integrity of these virtual currencies, established protocols, which are implemented as software algorithms, may be followed by participating entities or nodes for various transactions including currency production and exchange.
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 7,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the loyalty event is a earn event to earn loyalty points for a transaction, wherein the electronic wallet application is configured to: receive a transaction notification; wherein the loyalty platform is configured to receive a clearing and settlement notification for the transaction notification from the public distributed ledger; record an amount of loyalty points for the transaction notification as part of the block for the loyalty transaction.
Valencia teaches,
wherein the loyalty event is a earn event to earn loyalty points for a transaction, wherein the electronic wallet application is configured to: receive a transaction notification; wherein the loyalty platform is configured to receive a clearing and settlement notification for the transaction notification from the public distributed ledger; record an amount of loyalty points for the transaction notification as part of the block for the loyalty transaction.
(Valencia [0155] process the transactions for clearing and settlement
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0124] The e-wallet application ...enables the subscriber to: (i) accept deposits or money in his e-wallet;
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages
Valencia [0165] data required to identify the subscriber's account with the issuer and to provide the dollar amount of the sales)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 8,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia teaches,
initiate the display
(Vijayvergia [Col 14, Lines 60-61] may also include one or more output devices such as a display, LED(s)
Vijayvergia [Col 16, Lines 56-59] implementations may be realized on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user)
Vijayvergia does not teach wherein the electronic wallet application is configured to: receive a view loyalty point balance request; transmit a loyalty point balance request to the loyalty platform, the loyalty point balance request indicating the customer identifier; receive a loyalty point balance for the customer identifier from the loyalty platform; and initiate the display a loyalty point balance.
Valencia teaches,
wherein the electronic wallet application is configured to: receive a view loyalty point balance request; transmit a loyalty point balance request to the loyalty platform, the loyalty point balance request indicating the customer identifier; receive a loyalty point balance for the customer identifier from the loyalty platform; and … a loyalty point balance..
(Valencia [0097] an electronic wallet (e-wallet) account... e-wallet
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages
Valencia [0059] Whether the extracted source transaction account identifier (ID)
Valencia [0087] identifiers associated with the transaction message 404 a (e.g., source account ID, recipient account ID, and transaction token ID)
Valencia [0045] “ledger” may refer to a computer-generated and/or computer-based principal book or “digital passbook” for recording monetary values which are associated with transactions ... may include a beginning balance and an ending balance for each transaction
Valencia [0012] knowing his available balance... account balances )
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 9,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 3 as described earlier.
Vijayvergia does not teach wherein the electronic wallet application is configured to: transmit payment authorization for the transaction notification.
Valencia teaches,
wherein the electronic wallet application is configured to: transmit payment authorization for the transaction notification.
(Valencia [0168] transmitting the transaction authorization message to the transaction processing system
Valencia [Claim 1] generating...a transaction authorization message
Valencia [0097] transaction may use .... an electronic wallet (e-wallet) account... e-wallet, and e-checkbook accounts.
Valencia [0099] for storing information about the e-wallet account incident to or based on any one or more of the processing procedures and associated with the application software programs)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 10,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the electronic wallet application is configured to: transmit a view transaction history request to the loyalty platform, the loyalty point balance request indicating the customer identifier; receive transaction history data from the loyalty platform, the transaction history data generate from data on a plurality of blocks from the distributed ledger for loyalty points management, each of the plurality of blocks linked to the customer identifier.
Valencia teaches,
wherein the electronic wallet application is configured to: transmit a view transaction history request to the loyalty platform, the loyalty point balance request indicating the customer identifier; receive transaction history data from the loyalty platform, the transaction history data generate from data on a plurality of blocks from the distributed ledger for loyalty points management, each of the plurality of blocks linked to the customer identifier.
(Valencia [0099] for storing information about the e-wallet account incident to or based on any one or more of the processing procedures and associated with the application software programs
Valencia [0064] transaction history information
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0045] “ledger” may refer to a computer-generated and/or computer-based principal book or “digital passbook” for recording monetary values which are associated with transactions ... may include a beginning balance and an ending balance for each transaction
Valencia [0087] identifiers associated with the transaction message 404 a (e.g., source account ID, recipient account ID, and transaction token ID)
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 11,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the loyalty event is a redeem event to redeem a number of loyalty points, the block for the loyalty transaction indicating a debit operation for the number of points from the loyalty account for the customer.
Valencia teaches,
wherein the loyalty event is a redeem event to redeem a number of loyalty points, the block for the loyalty transaction indicating a debit operation for the number of points from the loyalty account for the customer.
(Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0121] debit column for payments or withdrawals;
Valencia [0129] is configured to reflect the balance of the credit, debit, or pre-paid account that the subscriber may want to use to pay for goods and/or services he wants to purchase from a merchant or an individual.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 12,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the loyalty event is an exchange event to exchange a number of loyalty points into another currency, the block for the loyalty transaction indicating an exchange operation based on a pre-configured conversion rate for the number of loyalty points, wherein the pre-configured conversion rate can be stored on the block using a storage function.
Valencia teaches,
wherein the loyalty event is an exchange event to exchange a number of loyalty points into another currency, the block for the loyalty transaction indicating an exchange operation
(Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0060] digital currency units that can be integrated or incorporated ... examples and not by way of limitation, any of Bitcoins, Metacoins, Peercoins, Appcoins, Quarkcoins, Namecoins, Dogecoins, and Litecoins. These virtual currencies may be decentralized....by participating entities or nodes for various transactions including... exchange.
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages
Valencia [0059] pre-stored in the distributed ledger database.
Valencia [0043] included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages)
based on a pre-configured conversion rate for the number of loyalty points, wherein the pre-configured conversion rate can be stored on the block using a storage function.
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0045] the term “ledger” may refer to a computer-generated and/or computer-based principal book or “digital passbook” for recording monetary values which are associated with transactions conducted using transaction accounts. The digital passbook may be a computer-based file which is provided with debits and credits in separate columns....updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account ... Automatic debit and credit among the various accounts and the ledgers associated with the accounts of the participants
Valencia [0009] processes, rules, and players (such as tokenization, payment gateways, etc.) have been added to the existing payment system
Valencia [0060] In order to ensure the integrity of these virtual currencies, established protocols, which are implemented as software algorithms, may be followed by participating entities or nodes for various transactions including currency production and exchange.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 13,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the loyalty event is a transfer event to transfer a number of loyalty points from the loyalty account to a target loyalty account, the block for the loyalty transaction indicating a debit operation for the number of loyalty points from the loyalty account and a credit operation for the number of loyalty points to the target loyalty account.
Valencia teaches,
wherein the loyalty event is a transfer event to transfer a number of loyalty points from the loyalty account to a target loyalty account, the block for the loyalty transaction indicating a debit operation for the number of loyalty points from the loyalty account and a credit operation for the number of loyalty points to the target loyalty account.
(Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0060] digital currency units that can be integrated or incorporated ... examples and not by way of limitation, any of Bitcoins, Metacoins, Peercoins, Appcoins, Quarkcoins, Namecoins, Dogecoins, and Litecoins. These virtual currencies may be decentralized....by participating entities or nodes for various transactions including... exchange.
Valencia [0121] debit column for payments or withdrawals;
Valencia [0129] is configured to reflect the balance of the credit, debit, or pre-paid account that the subscriber may want to use to pay for goods and/or services he wants to purchase from a merchant or an individual.
Valencia [0045] recording monetary values which are associated with transactions conducted using transaction accounts.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 14,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the loyalty platform is configured to generate a loyalty profile for the customer identifier, the loyalty profile having a loyalty point balance and a transaction history, the loyalty profile being linked to a plurality of blocks in the distributed ledger for loyalty points management, each of the plurality of blocks indicating the customer identifier, a loyalty event and an amount of loyal points.
Valencia teaches,
wherein the loyalty platform is configured to generate a loyalty profile for the customer identifier, the loyalty profile having a loyalty point balance and a transaction history, the loyalty profile being linked
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account which is distinct from the source transaction account, and debit and credit related data associated with the source and recipient transaction accounts
Valencia [0098] The IC device 200 a preferably includes an e-passbook account information area
Valencia [0012] a digital passbook may be an extension of the subscriber's account
Valencia [0045] may include a beginning balance and an ending balance for each transaction account
Valencia [0064] transaction history information
Valencia [0011] incorporated in or linked to other devices ...can enable and/or implement a financial transaction (e.g., payment, reimbursement, lending) through automatic debit/credit system or by interacting with other ledgers representing the accounts of the acquirer, merchant, issuer, and the clearing and settlement bank.)
to a plurality of blocks in the distributed ledger for loyalty points management, each of the plurality of blocks indicating the customer identifier, a loyalty event and an amount of loyal points.
(Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages
Valencia [0087] identifiers associated with the transaction message 404 a (e.g., source account ID, recipient account ID, and transaction token ID)
Valencia [0165] data required to identify the subscriber's account with the issuer and to provide the dollar amount of the sales)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 15,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia teaches,
wherein the block comprises smart contract code
(Vijayvergia [Col 3, Lines 53-55] access management module(s) are implemented as a smart contract or other software
Vijayvergia [Col 15, Lines 63-64] code that creates an execution environment for the computer program
Vijayvergia [Col 4, Lines 4-8] Making use of smart contracts, the access management module(s) may be smart contract(s), upon which a blockchain and smart contract infrastructure sits. This allows more fine-grained access control)
Vijayvergia does not teach for computing an amount of loyalty points for the loyalty transaction, the block indicating the amount of loyalty points.
Valencia teaches,
for computing an amount of loyalty points for the loyalty transaction, the block indicating the amount of loyalty points.
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0045] debits and credits columns may be automatically generated and/or updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account
Valencia [0043] in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages
=============================
https://patents.google.com/patent/US20130103484A1/en?oq=US+20130103484+A1+McLaughlin
McLaughlin [0025] loyalty points conversion table indicating various loyalty points providers, their rates of conversion of loyalty-points to dollars
McLaughlin [0060] the number of customer's loyalty points are less the amount needed to redeem
McLaughlin [0162] each loyalty points redemption program applies different conversion rates for converting member's loyalty points into a dollar value amount.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Vijayvergia does
Claim 16 is rejected on the same basis as Claim 1.
Claim 17 is rejected on the same basis as Claim 2.
Claim 18 is rejected on the same basis as Claim 3.
Claim 19 is rejected on the same basis as Claim 4.
Claim 21 is rejected on the same basis as Claim 7.
Claim 22 is rejected on the same basis as Claim 8.
Claim 23 is rejected on the same basis as Claim 9.
Claim 24 is rejected on the same basis as Claim 10.
Claim 25 is rejected on the same basis as Claim 11.
Claim 26 is rejected on the same basis as Claim 12.
Claim 27 is rejected on the same basis as Claim 13.
Claim 28 is rejected on the same basis as Claim 14.
Claim 29 is rejected on the same basis as Claim 15.
Claim 30 is rejected on the same basis as Claim 1 with the added limitation of “wherein the public distributed ledger performs validation for the … transactions before forwarding the transactions to the private distributed ledger to process the … transactions”:
(Vijayvergia [Col 10, Lines 10-14] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate and relay transactions
Vijayvergia [Col 10, Lines 41-43] Validation of transactions includes verifying digital signatures associated with respective transactions)
Claim 32 is rejected on the same basis as Claim 31.
Claim 33 is rejected on the same basis as Claim 31.
Regarding Claim 34,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia teaches,
with the status of active to a status of inactive so that the … account for the customer is no longer available for … transactions
(Vijayvergia [Col 7, Lines 54-62] consortium blockchains may be governed by proof of stake rules. For example, a consortium member may provide a stake to “buy in” to a blockchain, and that stake may be surrendered if the consortium member violates terms of use of the blockchain. In some implementations, the access management module(s) 104 may be configured to police use of the blockchain(s) and determine violations that may necessitate loss of stake by consortium member(s)
Vijayvergia [Col 10, Lines 44-46] a miner must demonstrate a proof of work before their proposed block of transactions is accepted by the peer-to-peer network)
Vijayvergia does not teach wherein the at least one trusted computing devices updates the block storing the loyalty profile for the customer identifier
Valencia teaches,
wherein the at least one trusted computing devices updates the block storing the loyalty profile for the customer identifier
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0151] secured network of electronic devices
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data
Valencia [0012] the device-resident ledger system, and as well as the account balances associated with it, may be synchronized and updated on-demand
Valencia [0012] the device-resident ledger system may be activated, updated and loaded/credited
Valencia [0045] debits and credits columns may be automatically generated and/or updated upon successfully conducting an electronic financial transaction
Valencia [0056] a recipient transaction account, and a secure transaction token
Valencia [0125] account can take multi-currencies ....and multi-tokens (e.g., ... loyalty points).
Valencia [0064] various information such as account IDs, personal information, transaction history information)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 35,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 4 as described earlier.
Vijayvergia does not teach wherein an exchange rate is assigned to the merchant identifier, wherein the trusted computing device implements the exchange function for loyalty account management to convert the amount of loyalty points for the loyalty event by identifying and applying the exchange rate assigned to the merchant identifier.
Taylor teaches,
wherein an exchange rate is assigned to the merchant identifier, wherein the trusted computing device implements the exchange function for loyalty account management to convert the amount of loyalty points for the loyalty event by identifying and applying the exchange rate assigned to the merchant identifier.
(Taylor [0072] may determine an exchange rate of each of the source and destination points. ... may retrieve currency and/or points exchange rates of the various types of currency and/or points sources in a relational database
Taylor [0028] the merchant 110 may submit a merchant ID
Taylor [0056] the Crossroads Café may provide an offer entitled “freaky Fridays” having “50% off between 10 am and 3 pm on Fridays.”... For another example, the Crossroads Cafe may issue an offer based on loyalty purchase, such as “5th purchase of equal or lesser value free.”
Taylor [0057] loyalty unit may determine whether the instant purchase transaction is eligible for any of the offers provided by the merchant ID. If yes, e.g., it is the 5th purchase of the same latte from the consumer, the L-PROMO loyalty unit may apply the offer “5th purchase of equal or lesser value free” to the transaction.....may provide a real-time rebate of the purchasing amount to the consumer's bank account, which may be reflected in the bank statement 285.)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the loyalty program hybrid public-private blockchain ledgers of Valencia to incorporate the loyalty identifiers of Taylor to “identify offers based on consumer transactions” (Taylor [0039]). The modification would have been obvious, because it is merely applying a known technique (i.e. loyalty identifiers) to a known concept (i.e. loyalty hybrid public-private blockchain ledgers) ready for improvement to yield predictable result (i.e. “To conduct the transaction, the item is identified. Instead of processing the transaction by financial messaging in a closed loop system, the transaction is processed in an open loop system where there is an issuer and a different acquirer that communicate financial messaging for the transaction on the private label or co-branded account through a transaction handler (e.g.; Visa Inc., MasterCard, etc.). As such, the private label or co-branded account transaction will be processed so as to realize efficiency through an open loop system.” Taylor [0143])
Regarding Claim 36,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the merchant application programming interface registers a merchant using the merchant identifier, provides transactions for the merchant for viewing, and provides balances for the merchant for viewing.
Valencia teaches,
wherein the merchant application programming interface registers a merchant using the merchant identifier, provides transactions for the merchant for viewing, and provides balances for the merchant for viewing.
(Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface
Valencia [0142] To link the subscriber's SIM card to his issuer accounts, the subscriber may register his e-passbook and e-wallet accounts
Valencia [0143] Upon validation, the issuer may link the subscriber's SIM card with his issuer accounts...the subscriber may be able to access his issuer accounts, as well as transfer funds from his issuer accounts to his e-wallet application
Valencia [0043] blocks containing data which are represented by transactions and/or transaction messages
Valencia [0045] debits and credits columns may be automatically generated and/or updated upon successfully conducting an electronic financial transaction, and may include a beginning balance and an ending balance for each transaction account
Valencia [0135] The NFC reader is an application program for reading NFC transactions or messages)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Regarding Claim 37,
Vijayvergia, Valencia, and Taylor teach the public-private blockchain loyalty platform of Claim 1 as described earlier.
Vijayvergia does not teach wherein the electronic wallet application retrieves a merchant card identifier for the loyalty platform using the merchant identifier and a client identifier using a function of the merchant application programming interface.
Valencia teaches,
wherein the electronic wallet application retrieves a merchant card identifier for the loyalty platform using the merchant identifier and a client identifier using a function of the merchant application programming interface.
(Valencia [0125] multi-tokens (e.g., stored values, chits, loyalty points)
Valencia [0091] payment flow may be characterized by a merchant selling goods and/or services to the subscriber.
Valencia [0099] IC memory system 232 a for storing information about the e-wallet account
Valencia [0093] The computers may be used to access the one or more ledger systems through any suitable API or application programming interface
Valencia [0142] To link the subscriber's SIM card to his issuer accounts, the subscriber may register his e-passbook and e-wallet accounts
Valencia [0053] wherein the transaction authorization message includes identifiers of at least a source transaction account and a recipient transaction account which is distinct from the source transaction account, and debit and credit related data associated with the source and recipient transaction accounts)
It is prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the public-private blockchain of Vijayvergia to incorporate the blockchain loyalty exchange platform of Valencia for “multi-currencies (e.g. Dollar, Pesos, Yen) and multi-tokens (e.g., stored values, chits, loyalty points)… for performing cross-border transactions.” (Valencia [0125]). The modification would have been obvious, because it is merely applying a known technique (i.e. blockchain loyalty exchange platform ) to a known concept (i.e. public-private blockchain) ready for improvement to yield predictable result (i.e. “Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data which are represented by transactions and/or transaction messages, linking data which are arranged to link a current block to a previous block in a chain of the blocks provided with transactions and/or transaction messages, data recording and tracking system for ensuring validity of the transactions performed through the chain of the blocks with proof of work data” Valencia [0043])
Response to Remarks
Applicant's arguments filed on December 23, 2025, have been fully considered and Examiner’s remarks to Applicant’s amendments follow.
Response Remarks on Claim Rejections - 35 USC § 112
Applicant's amendments rectify the previous rejections under 35 USC § 112.
The rejection under 35 USC § 112 is lifted.
Response Remarks on Claim Rejections - 35 USC § 101
By today’s measure, the presented claims regarding a public/private hybrid (permissioned) distributed ledger are well-understood, routine, and conventional. However, at the time of the provisional application filing date of March 17, 2017, utilization of hybrid (permissioned) distributed ledgers were unconventional, burgeoning, and considered a technological innovation.
Therefore, the rejection under 35 USC § 101 remains lifted.
Response Remarks on Claim Rejections - 35 USC § 103
Applicant's amendments required the application of NO new/additional prior art.
One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In reMerck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Where a rejection of a claim is based on two or more references, a reply that is limited to what a subset of the applied references teaches or fails to teach, or that fails to address the combined teaching of the applied references may be considered to be an argument that attacks the reference(s) individually. Where an applicant’s reply establishes that each of the applied references fails to teach a limitation and addresses the combined teachings and/or suggestions of the applied prior art, the reply as a whole does not attack the references individually as the phrase is used in Keller and reliance on Keller would not be appropriate. This is because "[T]he test for obviousness is what the combined teachings of the references would have suggested to [a PHOSITA]." In re Mouttet, 686 F.3d 1322, 1333, 103 USPQ2d 1219, 1226 (Fed. Cir. 2012).
The Applicant states:
“Vijayvergia does not teach a public distributed ledger interoperating with a private distributed ledger to mirror transaction blocks between the ledgers."
Examiner responds:
Vijayvergia teaches, “a public distributed ledger interoperating with a private distributed ledger to mirror transaction blocks between the ledgers”:
Vijayvergia [Col 10, Lines 12-14] each node being a computing device that uses a client to validate and relay transactions (e.g., deposits of checks). Each node maintains a copy of the blockchain
Vijayvergia [Col 10, Lines 19-29] Because all users (e.g., financial institutions) need to know all previous transactions (e.g., check deposits) to validate a requested transaction (e.g., check deposit), all users must agree on which transactions have actually occurred, and in which order.... The blockchain enables all users to come to an agreement as to transactions that have already occurred, and in which order. In short, and as described in further detail below, a ledger of transactions is agreed
Vijayvergia [Col 2, Liens 36-40] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain
Valencia also teaches the same matter:
Valencia [0043] Public, private, or a hybrid of public and private ledgers included in the distributed ledger system may include blocks containing data
Valencia [0054] The device-resident ledger system is a mirror of an issuer-resident ledger system maintained at the transaction processing system 300 and corresponding to the node-resident ledger system.
Valencia [0084] each of the nodes 402 is able to monitor and, in fact, obtain and keep a copy of any of the distributed ledgers within the distributed ledger system
The Applicant states:
“ Vijayvergia does not teach a clearing adaptor and a notification application programming interface."
Examiner responds:
Valencia and Taylor, in combination, teach this limitation.
Valencia teaches, “a clearing adaptor”:
Valencia [0009] it is back-end dependent in that the authorization, clearing and settlement processes go through the backend infrastructure a number of times to ensure completion of the transaction
Valencia [0011] by interacting with other ledgers representing the accounts of the acquirer, merchant, issuer, and the clearing and settlement bank.
Taylor teaches, “and a notification application programming interface”:
Taylor [0224] Dedicated communication systems 81020, 81022 (e.g., private communication network(s)) facilitate communication between the transaction handler (th) 81002 and each issuer (i) 81004 and each acquirer (a) 81006. A Network 81012, via e-mail, the World Wide Web, cellular telephony, and/or other optionally public and private communications systems, can facilitate communications
Taylor [0103] integrate APIs
Taylor [0142] provide APIs... to facilitate rapid on-boarding and campaign implementation... for ongoing offers/loyalty campaign management, partners are open platforms (e.g., Facebook, Twitter, Foursquare and other open platforms can be leveraged to provide retailer benefits and spread the application virally).
The Applicant states:
“Vijayvergia does not disclose the private distributed ledger and the public distributed ledger interoperating to perform reconciliation to ensure blocks of the two ledgers mirror each other and integrity validation to ensure the blocks are not corrupt.."
Examiner responds:
Vijayvergia teaches, “the private distributed ledger and the public distributed ledger interoperating to perform reconciliation to ensure blocks of the two ledgers mirror each other and integrity validation to ensure the blocks are not corrupt”:
Vijayvergia [Col 10, Lines 12-14] each node being a computing device that uses a client to validate and relay transactions (e.g., deposits of checks). Each node maintains a copy of the blockchain
Vijayvergia [Col 10, Lines 19-29] Because all users (e.g., financial institutions) need to know all previous transactions (e.g., check deposits) to validate a requested transaction (e.g., check deposit), all users must agree on which transactions have actually occurred, and in which order.... The blockchain enables all users to come to an agreement as to transactions that have already occurred, and in which order. In short, and as described in further detail below, a ledger of transactions is agreed
Vijayvergia [Col 2, Liens 36-40] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain
The Applicant states:
“Vijayvergia does not disclose the private distributed ledger maintaining private data for loyalty transactions and the public distributed ledger allowing certain elements of the private loyalty transaction data to be made publicly available."
Examiner responds:
Vijayvergia teaches, “the private distributed ledger maintaining private data for … transactions and the public distributed ledger allowing certain elements of the private … transaction data to be made publicly available”:
Vijayvergia [Col 2, Lines 34-41] Implementations provide one or more access control modules that control and mediate the communication of data between different blockchains, such as between an internal, private blockchain and an external, public blockchain, or between two private blockchains associated with different entities.
Vijayvergia [Col 3, Lines 47-52] determine access rights and determine the particular private information to be accessible by external (e.g., public) blockchains. The access management module(s) may also control communications between two private blockchains with differing access permissions
Vijayvergia [Col 6, Line 63 to Col 7, Line 7] access management module(s) 104 also control the communication of data from the (e.g., private) blockchain 110 to external device(s) 112, external blockchain(s) 114, or other external entities. The access management module(s) 104 employ a set of rules 126 that govern the external (e.g., outbound) communication of data from internal blockchain(s) 110. ... that govern when, to whom, and under what conditions data from the blockchain(s) 110 may be communicated externally.
Vijayvergia [Col 12, Lines 54-51] The access management module(s) 104 may also control the communication of data from the (e.g., private) blockchain 110 to external entities. In some implementations, the access management module(s) 104 employ a set of rules 126 that govern the external communication of data... access management module(s) 104 may permit such public dissemination of information
The Applicant states:
“Vijayvergia further does not disclose the public distributed ledger performing validation for the loyalty transactions before forwarding the transactions to the private distributed ledger for further processing."
Examiner responds:
Vijayvergia teaches, “wherein the public distributed ledger performs validation for the … transactions before forwarding the transactions to the private distributed ledger to process the … transactions:
Vijayvergia [Col 10, Lines 10-14] the peer-to-peer network can be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate and relay transactions
Vijayvergia [Col 10, Lines 41-43] Validation of transactions includes verifying digital signatures associated with respective transactions.
Therefore, the rejection under 35 USC § 103 remains.
Prior Art Cited But Not Applied
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kurian (“SYSTEM FOR CONTROL OF SECURE ACCESS AND COMMUNICATION WITH DIFFERENT PROCESS DATA NETWORKS WITH SEPARATE SECURITY FEATURES”, U.S. Publication Number: 20170230353 A1) provides a distributed block chain network having at least a private block chain portion, and in some cases a public block chain portion, allows users to take actions (e.g., accessing, viewing, storing, disseminating, validating, or the like) with respect to event information associated with events. In some aspects of the invention the distributed block chain network with the private block chain portion may be utilized to verify events and separate the private information associated with the events from the public information associated with the events. As such, the present invention provides systems for centralized control of secure access to process data networks by utilizing a private block chain; and moreover, provide systems for control of secure access and communication with different process data networks with different security requirements by utilizing one or more block chains with private block chain portions and/or public block chain portions
Haldenby (“SYSTEMS AND METHODS FOR ESTABLISHING AND ENFORCING TRANSACTION-BASED RESTRICTIONS USING HYBRID PUBLIC-PRIVATE BLOCKCHAIN LEDGERS”, U.S. Publication Number: US 20170046698 A1) generates secured blockchain-based ledger structures that facilitate event-based control of tracked assets. In one embodiment, an apparatus associated with a rules authority of the secured blockchain-based ledger may obtain data indicative of an initiated transfer of funds between parties, and may access and decrypt a set of restrictions imposed on the initiated transfer and a set of rules associated with the restrictions, which may hashed into the secured blockchain-based ledger using a confidentially-held master cryptographic key. The apparatus may determine that the initiated transfer violates at least one of the restrictions, and may perform operations consistent with at least one of the rules associated with the at least one violated restriction.
Tran (“SMART DEVICE”, U.S. Publication Number: 20180117447 A1) provides a permissioned blockchain where predetermined trusted parties are authorized to initiate individuals or organizations onto the blockchain and thus vouched for by a trusted point. Individuals can initiate their own identity if they wish. [0207] in response to the service or item becoming compromised or to create a reward or incentive for finding the service or item and/or the key data embedded therein. [0412] In one embodiments, private blockchains which are tightly controlled, with rights to modify and/or read the blockchain restricted to a small number of users, can be used for certification and/or collective trademarks, which the added bonus that fake certificates could almost immediately be identified as such. [1053] Still further features of the system provide for the blockchain address to be controlled or managed by a party capable of monitoring the shared public ledger to determine whether a transaction against the store of value has occurred;
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHINEDU EKECHUKWU whose telephone number is (571)272-4493. The examiner can normally be reached on Mon-Fri 9 AM ET to 3:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Behncke, can be reached on (571) 272-8103. 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.
/CHINEDU U. EKECHUKWU/Examiner, Art Unit 3695 /CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695