DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Receipt of Applicant’s amendments filed on February 16, 2026 is acknowledged.
Response to Amendment
Applicant amended claim 1.
Applicant cancelled claims 2, 3, and 42.
Applicant previously cancelled claims 14-41, 43 and 44
Claims 1 and 4-13 are pending and have been examined.
Response to Arguments
Applicant's arguments filed February 16, 2026 have been fully considered but they are not persuasive.
Regarding 112 Rejections
Examiner initially rejected claim 42 under 35 USC 112(b) / 2nd paragraph as being indefinite. Applicant cancelled this claim. In view of the cancelled claim, Examiner withdraws this rejection.
Regarding 101 Rejections
Examiner initially rejected claims 1-13 and 42 under 35 USC 101 as being directed to non-statutory subject matter.
Applicant argued that the claims do not recite an abstract idea. Examiner does not find this argument persuasive. Applicant merely alleges the claims do not recite an abstract idea and provides no analysis as to why the claims are not directed to Certain Methods of Organizing Human Activity. Merely having a different opinion as to how to describe the thrust of the claims does not change what the claims actually recite. Examiner identified the limitations which define the abstract idea and how they are directed to a commercial interaction. Since they are a commercial interaction the claims fall into the grouping of Certain Methods of Organizing Human Activity and therefore constitute an abstract idea (and thus a judicial exception). It is not persuasive to argue that the specific use of a dust transaction amounts to a non-abstract idea. Applicant merely alleges the technical nature/advantages of the this and only points out the utility of the claim rather than explain how they amount to an improvement in technology.
Applicant argued that the claims a recite a practical application of the judicial exception. Applicant argued the claims present a technical improvement. Examiner does not find this argument persuasive. Applicant’s claims do not improve technology; the underlying technology remains unaffected by the claims. Applicant is addressing a business problem (transactions not being recorded sequentially) with a business solution. Applicant is merely using existing technology (for its intended purpose) to implement the business solution. Any improvements lie in the abstract idea itself, not in underlying technology. It is not a technical solution to use a nonce/dust transaction to ensure that transactions are recording in a preferred order. The identified limitations do no amount to a practical application because they are a part of the abstract idea. Outside of the abstract idea there remains only the computer implementation of the abstract idea and extra-solution activity. Neither of these are indicative of a practical application. Applicant’s claims do not address a technical limitation/deficiency in the art and thus does not amount to a practical application.
Examiner maintains this rejection.
Regarding Prior Art Rejections
Examiner initially rejected claims 1-13 and 42 as being unpatentable over the prior art.
Applicant argued that the prior art does not teach the newly amended claims. Applicant’s arguments with respect to claims 1 and 4-13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Examiner has incorporated a new reference Melika which teaches the aspect of using crypto dust to ensure transaction chronology (see below rejection).
Examiner maintains this rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 and 4-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite the abstract idea which may be summarized as tracking clients interacting with an asset.
Step 1 Analysis
Applicants claims are directed to a process (claims 1 and 4-13).
Step 2A, Prong 1 Analysis
Claim 1 recite the abstract idea/limitations of:
tracking at least two clients independently interacting with an asset,
a set of transactions associated with the asset,
a first set of transactions associated with a first client of the at least two clients,
and a second set of transactions associated with a second client of the at least two clients,
receiving an asset interaction event request comprising data indicative of at least two clients associated with an asset interaction event and data indicative of the asset,
generating an event transaction based on:
at least one reference to the set of transactions associated with the asset;
wherein a first reference of the at least one reference to the set of transactions associated with the asset comprises an asset transaction outpoint associated with the set of transactions associated with the asset,
wherein the asset transaction outpoint points to a next transaction in the set of transactions associated with the asset,
and the next transaction in the set of transaction spends an output configured for ensuring transaction chronology,
at least one reference to the set of transactions associated with the first client;
and at least one reference to the set of transactions associated with the second client,
and submitting the event transaction.
As drafted these limitations are a process that falls within the “Certain Methods of Organizing Human Activity grouping of abstract ideas; but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, recites performance of the limitation as commercial/legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. By reciting/claiming a certain method of organizing human activity, Applicant’s claims recite to an abstract idea.
Step 2A, Prong 2 Analysis
This judicial exception is not integrated into a practical application because the claims only recite generic system components for implementing the abstract idea and insignificant extra-solution activity. The claims recite the additional limitations of a blockchain, a dust output; and they are recited at a high level of generality. These system components amount to no more than mere instructions to apply the exception using a generic computer. These limitations generally link the use of the judicial exception to a technological environment and are not indicative of integration into a practical application. The limitations of:
receiving an asset interaction event request;
submitting the event transaction;
amount to insignificant extra-solution activity. These steps are mere sending and receiving of data, which courts have recognized as insignificant extra-solution activities see MPEP 2106.05(d)(II)(i). These additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims as a whole do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea without a practical application.
Step 2B Analysis
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a blockchain, a dust output; amount to no more than mere components to implement the judicial exception using a generic computer components. For the same reason these elements are not sufficient to provide an inventive concept. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The limitations of:
receiving an asset interaction event request;
submitting the event transaction;
amount to the sending and receiving data between devices, claimed at a high level of generality. These insignificant extra-solution activities are also well-understood, routine, and conventional as recognized by the federal courts See MPEP 2106.05(d)(II)(i). See Applicant’s specification pages 20 and 21 about implementation of the abstract idea using general purpose or special purpose computing devices; and MPEP 2106.05(f) where applying a computer as a tool is not indicative of significantly more. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus Applicant’s claims are not patent eligible.
Dependent Claims Analysis
As for dependent claims 4-13, these claims recite limitations that further define the same abstract idea noted in independent claim 1. Therefore, claims 4-13 are considered ineligible subject matter for the reasons given above.
Thus, the dependent claims 4-13 and 42 are not patent-eligible either.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) or 35 USC 112 first paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 and 4-13 are rejected under 35 U.S.C. 103 as being unpatentable over Werner, US Patent Application Publication No 2021/0089514 in view of Melika, US Patent Application Publication No 2016/0350728.
Regarding claim 1;
A computer-implemented method for tracking, on a blockchain, at least two clients independently interacting with an asset,
See Werner [0079] FIG. 4A illustrates a process 400A of registering a physical object for tracking via a blockchain according to example embodiments. Referring to FIG. 4A, a manufacturing device 404 registers a physical object 402 for the first time on a blockchain 406. In 411, the manufacturing device 404 may establish an initial setup with the blockchain 406 by exchanging keys thus providing the blockchain with its public key and receive the blockchain's public key. In 412, the manufacturing device 404 may trigger generation of a unique ID (UID) of the object 402 by HSM of the object 402. In response, the HSM may generate a key pair (public key and private key), and extract a unique ID of the object 402 from memory, etc.
wherein the blockchain comprises a set of transactions associated with the asset, a first set of transactions associated with a first client of the at least two clients, and a second set of transactions associated with a second client of the at least two clients, the method comprising the steps:
See Werner [0098] FIG. 7A illustrates a process 700 of a new block being added to a distributed ledger 720, according to example embodiments, and FIG. 7B illustrates contents of a new data block structure 730 for blockchain, according to example embodiments. Referring to FIG. 7A, clients (not shown) may submit transactions to blockchain nodes 711, 712, and/or 713.
[0039] The blockchain may operate arbitrary, programmable logic, tailored to a decentralized storage scheme and referred to as “smart contracts” or “chaincodes.” In some cases, specialized chaincodes may exist for management functions and parameters which are referred to as system chaincode. The application can further utilize smart contracts that are trusted distributed applications which leverage tamper-proof properties of the blockchain database and an underlying agreement between nodes, which is referred to as an endorsement or endorsement policy. Blockchain transactions associated with this application can be “endorsed” before being committed to the blockchain while transactions, which are not endorsed, are disregarded. An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.
receiving an asset interaction event request comprising data indicative of at least two clients associated with an asset interaction event and data indicative of the asset,
See Werner [0082] In 424, the client device 408 may request data of the object 402 stored in the blockchain 406 based on the UID [[UID, pub key of HSM, n-signature.sub.HSM key]signature.sub.MFG key] and pub key MFG from the blockchain 406 with a signature.
[0074] A sender 356 desires to send payment or some other form of value (e.g., a deed, medical records, a contract, a good, a service, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352.
generating an event transaction based on: at least one reference to the set of transactions associated with the asset;
See Werner [0083] FIG. 4C illustrates a process 400C of modifying a security value of the tracked physical object according to example embodiments. In this example, the client device 408 may update the nonce value of the physical asset (object 402) to prevent a prior owner from attempt to reclaim ownership over the object 402 using an old nonce value. In 431, the client device 408 may modify the nonce value. For example, the client device 408 may increment a nonce value (e.g., by one, etc.) or otherwise modify the value by a random number, a predetermined number, etc. so as to prevent guessing of the changed secret. In 432, the client device 408 requests the HSM of the object 402 as challenge to sign it and, in 433, the HSM returns the signed value [n+1, signature.sub.HSM]…. In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
wherein a first reference of the at least one reference to the set of transactions associated with the asset comprises an asset transaction outpoint associated with the set of transactions associated with the asset.
See Werner [0083] In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
wherein the asset transaction outpoint points to a next transaction in the set of transactions associated with the asset.
See Werner [0083] In response to successfully authenticating the signature, in 435, the client device 408 may transmit a blockchain transaction request to the blockchain 406 which includes [[UID, pubkey.sub.HSM n+1, n+1-signature.sub.HSM key]signature.sub.Client key]. In 436, the blockchain 406 may validate the request signature of the transaction, and validate the signature of the HSM on the secret. In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
at least one reference to the set of transactions associated with the first client; and at least one reference to the set of transactions associated with the second client,
See Werner [0083] FIG. 4C illustrates a process 400C of modifying a security value of the tracked physical object according to example embodiments. In this example, the client device 408 may update the nonce value of the physical asset (object 402) to prevent a prior owner from attempt to reclaim ownership over the object 402 using an old nonce value. In 431, the client device 408 may modify the nonce value. For example, the client device 408 may increment a nonce value (e.g., by one, etc.) or otherwise modify the value by a random number, a predetermined number, etc. so as to prevent guessing of the changed secret. In 432, the client device 408 requests the HSM of the object 402 as challenge to sign it and, in 433, the HSM returns the signed value [n+1, signature.sub.HSM]…. In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
and submitting the event transaction to the blockchain.
See Werner [0083] In response to successfully authenticating the signature, in 435, the client device 408 may transmit a blockchain transaction request to the blockchain 406 which includes [[UID, pubkey.sub.HSM n+1, n+1-signature.sub.HSM key]signature.sub.Client key]. In 436, the blockchain 406 may validate the request signature of the transaction, and validate the signature of the HSM on the secret. In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
Werner does not teach
and the next transaction in the set of transactions spends a dust output configured for ensuring transaction chronology
Melika teaches
and the next transaction in the set of transactions spends a dust output configured for ensuring transaction chronology
See Melika Figures 5 and 6
[0050] In this example, the Figure will be described with reference to a car, though titles are used for other assets as well. In step 502, the encoded paper title is transmitted to an owner. In this case, with a car, this title come from the DMV, the manufacturer, the dealer, or perhaps stored in a wallet onboard the car's computer. In such cases, the issuing address (input) may not be directly associated with the original owner, but rather generated and managed by the web application as a placeholder. The dust amount is transferred in to the transaction and to the transaction an encoded hash is applied such that with the hash key, this transaction will always show proof of the existence of the encoded information recorded at the time of this issuance transaction 52A.
[0052] In step 508, the output address of the first issuance transaction 52A becomes one of the input addresses of the recipient transaction 52B. The dust amount that was transferred to this address is once again used in order to encode new data pertaining to the car's paper title. In step 510, the backend once again funds the transaction; however, this time, an additional dust amount is provided with the transaction fees to enable a DMV notification transaction. The output of the recipient transaction 52B is an bitcoin address associated with the new buyer for the car. In step 512, the consensus network extracts the fee from the transaction.
[0054] FIG. 6 is a flowchart for a method of transferring paper title assets making use of cryptographic public ledgers via a processor-operated web application that tracks title chain. In step 602, a web server records into a database, a receipt record for a paper title for a non-monetary asset stored with a physical caretaker from an owner. In step 604, a web application encodes identifying information associated with the paper title to a distributed consensus network maintaining a cryptographically verifiable ledger utilizing a proof-of-work process to enforce a chronological order amongst logistic transaction records in the cryptographically verifiable ledger. Information associated with the paper title includes; identification of the physical caretaker; identification of the non-monetary asset; and identification of the current owner of the non-monetary asset.
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the blockchain transaction of the primary reference, the ability to utilize dust amounts of cryptocurrency to ensure transaction chronology as taught by Melika since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additional motivation includes by ensuring chronology the ledger reflects the correct sequence of transactions.
Regarding claim 4;
The method of claim 1, wherein a second reference of the at least one reference to the set of transactions associated with the asset comprises data stored on the latest transaction in the set of transactions associated with the asset.
See Werner [0083] FIG. 4C illustrates a process 400C of modifying a security value of the tracked physical object according to example embodiments. In this example, the client device 408 may update the nonce value of the physical asset (object 402) to prevent a prior owner from attempt to reclaim ownership over the object 402 using an old nonce value. In 431, the client device 408 may modify the nonce value. For example, the client device 408 may increment a nonce value (e.g., by one, etc.) or otherwise modify the value by a random number, a predetermined number, etc. so as to prevent guessing of the changed secret. In 432, the client device 408 requests the HSM of the object 402 as challenge to sign it and, in 433, the HSM returns the signed value [n+1, signature.sub.HSM]. In 434, the client device 408 may verify the signature of the object 402 (HSM) added to the signed secret. In response to successfully authenticating the signature, in 435, the client device 408 may transmit a blockchain transaction request to the blockchain 406 which includes [[UID, pubkey.sub.HSM n+1, n+1-signature.sub.HSM key]signature.sub.Client key]. In 436, the blockchain 406 may validate the request signature of the transaction, and validate the signature of the HSM on the secret. In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
[0063] FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.
Regarding claim 5;
The method of claim 4, wherein the second reference of the at least one reference to the set of transactions associated with the asset is part of a data payload stored of the latest transactions in the set of transactions associated with the asset.
See Werner [0063] FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.
[0083] In 432, the client device 408 requests the HSM of the object 402 as challenge to sign it and, in 433, the HSM returns the signed value [n+1, signature.sub.HSM]. In 434, the client device 408 may verify the signature of the object 402 (HSM) added to the signed secret. In response to successfully authenticating the signature, in 435, the client device 408 may transmit a blockchain transaction request to the blockchain 406 which includes [[UID, pubkey.sub.HSM n+1, n+1-signature.sub.HSM key]signature.sub.Client key].
Regarding claim 6;
The method of claim 1, wherein each of a first of the at least one references to the sets of transactions associated with the first client and the second client comprises a transaction outpoint associated with each of the set of transactions associated with first client and the second client.
See Werner [0083] FIG. 4C illustrates a process 400C of modifying a security value of the tracked physical object according to example embodiments. In this example, the client device 408 may update the nonce value of the physical asset (object 402) to prevent a prior owner from attempt to reclaim ownership over the object 402 using an old nonce value. In 431, the client device 408 may modify the nonce value. For example, the client device 408 may increment a nonce value (e.g., by one, etc.) or otherwise modify the value by a random number, a predetermined number, etc. so as to prevent guessing of the changed secret. In 432, the client device 408 requests the HSM of the object 402 as challenge to sign it and, in 433, the HSM returns the signed value [n+1, signature.sub.HSM]. In 434, the client device 408 may verify the signature of the object 402 (HSM) added to the signed secret. In response to successfully authenticating the signature, in 435, the client device 408 may transmit a blockchain transaction request to the blockchain 406 which includes [[UID, pubkey.sub.HSM n+1, n+1-signature.sub.HSM key]signature.sub.Client key]. In 436, the blockchain 406 may validate the request signature of the transaction, and validate the signature of the HSM on the secret. In response to validating the signatures, the blockchain 406 may add the updated secret to the blockchain. In some embodiments, the blockchain 406 may also trigger contract fulfillment (e.g., payment, etc.)
Regarding claim 7;
The method of claim 6, wherein each transaction outpoint points towards a next transaction in each respective set of transactions associated with the clients.
See Werner [0083] In 432, the client device 408 requests the HSM of the object 402 as challenge to sign it and, in 433, the HSM returns the signed value [n+1, signature.sub.HSM]. In 434, the client device 408 may verify the signature of the object 402 (HSM) added to the signed secret. In response to successfully authenticating the signature, in 435, the client device 408 may transmit a blockchain transaction request to the blockchain 406 which includes [[UID, pubkey.sub.HSM n+1, n+1-signature.sub.HSM key]signature.sub.Client key].
Regarding claim 8;
The method of claim 1, wherein the set of transactions associated with the asset pertains to an event stream associated with the asset and each set of transactions associated with a given client among the at least two clients pertains to an event stream associated with said given client.
See Werner [0063] FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.
Regarding claim 9;
The method of claim 8, wherein each event stream represents a respective smart contract such that the event stream tracks a sequence of events associated with the smart contract.
See Werner [0039] The blockchain may operate arbitrary, programmable logic, tailored to a decentralized storage scheme and referred to as “smart contracts” or “chaincodes.” In some cases, specialized chaincodes may exist for management functions and parameters which are referred to as system chaincode. The application can further utilize smart contracts that are trusted distributed applications which leverage tamper-proof properties of the blockchain database and an underlying agreement between nodes, which is referred to as an endorsement or endorsement policy…. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.
Regarding claim 10;
The method of claim 1, wherein the event transaction comprises data based on the asset interaction event.
See Werner [0039] The blockchain may operate arbitrary, programmable logic, tailored to a decentralized storage scheme and referred to as “smart contracts” or “chaincodes.” In some cases, specialized chaincodes may exist for management functions and parameters which are referred to as system chaincode. The application can further utilize smart contracts that are trusted distributed applications which leverage tamper-proof properties of the blockchain database and an underlying agreement between nodes, which is referred to as an endorsement or endorsement policy…. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.
[0154] The operation of the blockchain 852 is based on two procedures (i) creation of transactions, and (ii) construction of blocks that aggregate the new transactions. New transactions may be created similar to a traditional blockchain network. Each transaction may contain information about a sender, a receiver, a time of creation, an amount (or value) to be transferred, a list of reference transactions that justifies the sender has funds for the operation, and the like. This transaction record is then sent to all other nodes where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854-860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to every transaction making it exceedingly difficult to tamper with. Each node checks their entries with respect to a local copy of the blockchain 852 to verify that each transaction has sufficient funds. However, the transactions are not yet confirmed.
Regarding claim 11;
The method of claim 10, wherein the data indicative of the asset interaction event is stored on an unspendable output of the event transaction.
See Werner [0074] FIG. 3C illustrates a process 350 of a transaction being processed by a permissionless blockchain 352 including a plurality of nodes 354. A sender 356 desires to send payment or some other form of value (e.g., a deed, medical records, a contract, a good, a service, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the recipient device 358 may have digital wallets (associated with the blockchain 352) that provide user interface controls and a display of transaction parameters. In response, the transaction is broadcast throughout the blockchain 352 to the nodes 354. Depending on the blockchain's 352 network parameters the nodes verify 360 the transaction based on rules (which may be pre-defined or dynamically allocated) established by the permissionless blockchain 352 creators. For example, this may include verifying identities of the parties involved, etc. The transaction may be verified immediately or it may be placed in a queue with other transactions and the nodes 354 determine if the transactions are valid based on a set of network rules.
Regarding claim 12;
The method of claim 1, wherein the asset is a song and/or the asset interaction event is to exchange ownership of the asset between the at least two clients.
See Werner [0058] Cryptographic trust services 218 may be used to verify transactions such as asset exchange transactions and keep information private.
Regarding claim 13;
The method of claim 1, further comprising the steps of: obtaining a reference to the set of transactions associated with the asset, and obtaining references to each set of transactions associated with the clients associated with the asset interaction event.
See Werner [0063] FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.
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 MICHAEL J WARDEN whose telephone number is (571)272-9602. The examiner can normally be reached M-F; 9-6 CDT.
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, Bennett M Sigmond can be reached at 303-297-4411. 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.
/MICHAEL J. WARDEN/
Examiner
Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694