DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 11/21/2025.
Claims 1 and 9 are amended.
Claims 3, 7, 8, 11, 15 and 16 are cancelled.
Claims 1, 2, 4-6, 9, 10 and 12-14 are pending.
Claims 1, 2, 4-6, 9, 10 and 12-14 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant's arguments filed 11/21/2025 have been fully considered but they are not persuasive.
112
The claims are unclear and indefinite. The system claim contains 2 entities, the node and the external computing device that includes a receiver. The claim language is unclear and indefinite as the wherein clauses describe the possible functions of a processor, but it is unclear whether it is claiming the functions of the processor included in the external computing device or the functions of the receiver receiving a processor that is identifying….” The “wherein” clauses are unclear and indefinite. The rejection is maintained.
103
Irazabal discusses “The blockchain may be formed in various ways. In one embodiment, the digital content may be included in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., header, value, etc.) along the associated digital content… In one embodiment, the digital content may be not included in the blockchain. For example, the blockchain may store the encrypted hashes of the content of each block without any of the digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file… The first block 778 1 in the blockchain is referred to as the genesis block and includes the header 772 1, original file 774 1, and an initial value 776 1. The hashing scheme used for the genesis block, and indeed in all subsequent blocks, may vary. For example, all the information in the first block 778 1 may be hashed together and at one time, or each or a portion of the information in the first block 778 1 may be separately hashed and then a hash of the separately hashed portions may be performed.” (¶ 96, 98, 100, 111)
The original file, to be pruned, is stored in a block on the blockchain, and is then pruned.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9, 10 and 12-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 9 recites “said computing device including a receiver receiving the subset of blocks from the blockchain node… and a processor identifying….” The claims are unclear and indefinite. The system claim contains 2 entities, the node and the external computing device that includes a receiver. The claim language is unclear and indefinite as the wherein clauses describe the possible functions of a processor, but it is unclear whether it is claiming the functions of the processor included in the external computing device or the functions of the receiver receiving a processor that is identifying….” The “wherein” clauses are unclear and indefinite. Dependent claims 10 and 12-14 are also rejected.
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.
Claims 1, 2, 4-6, 9, 10 and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Irazabal et al. (US 20220138181) (“Irazabal”), and further in view of Gilson (US 20190028278) (“Gilson”).
Regarding claims 1 and 9, Irazabal discloses storing, by a blockchain node within a blockchain network, a plurality of blockchain transactions on a blockchain in a local data store of the blockchain node, wherein each stored blockchain transaction is associated with a transaction value and is to be pruned (¶ 34-40, 49, 58, 65, 66, 83-93, 95-114, 138);
Irazabal- The blockchain may be formed in various ways. In one embodiment, the digital content may be included in and accessed from the blockchain itself. For example, each block of the blockchain may store a hash value of reference information (e.g., header, value, etc.) along the associated digital content… In one embodiment, the digital content may be not included in the blockchain. For example, the blockchain may store the encrypted hashes of the content of each block without any of the digital content. The digital content may be stored in another storage area or memory address in association with the hash value of the original file… The first block 778 1 in the blockchain is referred to as the genesis block and includes the header 772 1, original file 774 1, and an initial value 776 1. The hashing scheme used for the genesis block, and indeed in all subsequent blocks, may vary. For example, all the information in the first block 778 1 may be hashed together and at one time, or each or a portion of the information in the first block 778 1 may be separately hashed and then a hash of the separately hashed portions may be performed. For example, the peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain over the blocks. This process forms the ledger by ordering the storage transactions,.. This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one (¶ 34, 38, 96, 98, 100)
identifying, by the blockchain node, a stored to-be-pruned blockchain transaction, from the plurality of stored to-be-pruned blockchain transactions, (¶ 30-40, 49, 58, 65, 66, 83-114);
Irazabal- The pruning process replaces values of data with hash values, while leaving identifiers of the data such that the content within the data item can still be validated by the blockchain. …As a result, the amount of data that is stored on the blockchain can be significantly reduced (e.g., collapsed, etc.) by replacing actual content with hash values….For example, the peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain over the blocks. This process forms the ledger by ordering the storage transactions,.. This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one (¶ 30, 34, 38)
pruning, by the blockchain node, the blockchain by removing the transaction value from the local data store of the blockchain node (¶ 30, 41-44, 70, 71);
Irazabal- The pruning process replaces values of data with hash values, while leaving identifiers of the data such that the content within the data item can still be validated by the blockchain. As a simple example, document may be stored on the blockchain. Prior to storing the document, a client may decompose the document into a plurality of fields. For example, the document may include a header, a drawing, a description, and a timestamp which are each assigned their fields within the pruned data structure. (¶ 30)
posting, by the blockchain node, a plurality of new blocks to the blockchain, wherein a plurality of data chunks for the pruned blockchain and corresponding portions of an authentication code are stored across the plurality of new blocks (¶ 41-50, 70-76, 83-94, 114-124);
Claim Interpretation - According to the disclosure(¶ 32), “The authentication code may be any value that may be unique to a transaction value and used for identification thereof, such as an integer or alphanumeric value of sufficient size. In cases where the blockchain is a provenance blockchain, unique product identifiers, such as a serial number, may be used as authentication codes.”.
Irazabal- the identifying may include identifying the schema based on a data value included with the pruned data structure from the client….a client 110 submitting a pruned data structure 120 to a blockchain 130 according to example embodiments…a process 100B of a blockchain peer 132 validating a schema of the pruned data structure according to example embodiments. In this example, the blockchain peer 132 is one of many possible blockchain peers that may be include a copy of and manage the blockchain 130 shown in FIG. 1A. Here, the client 110 may submit the pruned data structure 120 in the form of a blockchain transaction. The blockchain network may perform an endorsement process… a new data block 730 (also referred to as a data block) that is stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments such as a block header 740, block data 750 (block data section), and block metadata 760 … The root hash 147 is a single hash value that represents the entire pruned data structure 120. Here, the blockchain peer 132 can store the root hash 147 as the representative value of the pruned data structure 120 to the blockchain 130… When the client 110 (or some other entity with access to the blockchain) desires to prove that the data item was previously stored to the blockchain 130, the client 110 can decompose the original data item and recreate the pruned data structure 120. The client 110 can then use the same hash function (e.g., the hash tree 140, etc.) used by the blockchain peer 132 to recreate the root hash 147. (¶ 41, 44, 46, 74, 91)
decoding, by the processor of the computing device, the transaction value (¶ 59, 66, 75, 76, 87, 98, 102-113, 121-126);
Claim Interpretation - According to the disclosure(¶ 29), a fountain code algorithm is defined as “When a transaction value is to be pruned from the blockchain, the blockchain node 102, or a separate blockchain node 102 that may be configured to perform encoding processes on behalf of other blockchain nodes 102, may encode the transaction value into a plurality of verifiable data chunks using a fountain code algorithm, such as Raptor code or RaptorQ, which are fountain codes that encode a given source block of data consisting of a number k of equal size symbols into a sequence of encoding symbols.”
Irazabal- This query, or tracking procedure, may begin with decrypting the value of the block that is most currently included (e.g., the last (Nth) block), and then continuing to decrypt the value of the other blocks until the genesis block is reached and the original file is recovered. … the blocks 778 1, 778 2, . . . 778 N are subject to a hash function which produces n-bit alphanumeric outputs (where n is 256 or another number) from inputs that are based on information in the blocks. Examples of such a hash function include, but are not limited to, a SHA-type (SHA stands for Secured Hash Algorithm) algorithm, Merkle-Damgard algorithm, HAIFA algorithm, Merkle-tree algorithm, nonce-based algorithm, and a non-collision-resistant PRF algorithm…The value 776 1 in the genesis block is an initial value generated based on one or more unique attributes of the original file 774 1. In one embodiment, the one or more unique attributes may include the hash value for the original file 774 1, metadata for the original file 774 1, and other information associated with the file. (¶ 98, 103-109, 125)
verifying, by the processor of the computing device, the decoded transaction value (¶ 30-34, 40, 49, 65-69, 75, 83, 94);
Irazabal- The transaction filter may include a byte array of a size equal to the number of transactions that are included in the block data 750 and a validation code identifying whether a transaction was valid/invalid…When a blockchain peer receives the pruned data structure, the blockchain peer can verify the schema of the pruned data structure matches a predefined schema associated with the client, the data, the blockchain, etc... The client can also request the previously stored root hash from the blockchain and compare the recreated root hash to the previously stored root hash to verify that the data item was previously stored to the blockchain. (¶ 31, 32, 94)
Irazabal does not disclose that is to be pruned from the blockchain based on the transaction value associated with the stored to-be-pruned blockchain transaction not having been accessed for a predetermined period of time; encoding, by the blockchain node, the transaction value by applying a fountain code algorithm to the transaction value to obtain a plurality of verifiable data chunks for the transaction value; receiving, by the blockchain node, a request from a computing device external to said blockchain node, said request requesting the transaction value; transmitting, by the blockchain node, to the computing device, a subset of blocks included in the blockchain, wherein each block of the subset of blocks includes one or more blockchain data values; receiving, by a receiver of the computing device, the subset of blocks from the blockchain node; receiving, by the receiver of the computing device, the authentication code from a participant system that is external to the blockchain network; identifying, by a processor of the computing device, a plurality of data chunks in the subset of blocks using the authentication code; decoding, by the processor of the computing device, the transaction value by applying the fountain code algorithm to the identified plurality of data chunks; and.
Gilson teaches that is to be pruned from the blockchain based on the transaction value associated with the stored to-be-pruned blockchain transaction not having been accessed for a predetermined period of time (¶ 75-85)
Gilson- The transaction may be configured to be available on the distributed database for a limited time. For example, the transaction may be configured to remain the memory pool for a period of time and be pruned from the memory pool… The transaction may be pruned from the memory pool after the period of time. The transaction may not comprise an incentive, such as a fee value. The transaction may comprise a fee value that may not be sufficient to entice one or nodes to validate the transaction. (¶ 75, 82)
encoding, by the blockchain node, the transaction value by applying a fountain code algorithm to the transaction value to obtain a plurality of verifiable data chunks for the transaction value (¶ 121)
Claim Interpretation - According to the disclosure(¶ 29), a fountain code algorithm is defined as “When a transaction value is to be pruned from the blockchain, the blockchain node 102, or a separate blockchain node 102 that may be configured to perform encoding processes on behalf of other blockchain nodes 102, may encode the transaction value into a plurality of verifiable data chunks using a fountain code algorithm, such as Raptor code or RaptorQ, which are fountain codes that encode a given source block of data consisting of a number k of equal size symbols into a sequence of encoding symbols.”
Gilson- The rights holder 801 may apply a code 803, such as a raptor code or a fountain code, to the content asset 802 to parse the content asset into a plurality of data chunks 804. (¶ 121)
receiving, by the blockchain node, a request from a computing device external to said blockchain node, said request requesting the transaction value (¶ 116-128)
Gilson- The user 806 may pay to access the content asset 802…The user may request the chunks c3, c7, c8, c11, and c13 from the distributor 805. (¶ 123, 126)
transmitting, by the blockchain node, to the computing device, a subset of blocks included in the blockchain, wherein each block of the subset of blocks includes one or more blockchain data values (¶ 116-128)
Gilson- The rights holder 801 may transmit a plurality of lists 807 of chunks to a plurality of users 806. The rights holder 801 may transmit different list 807 to one or more of the plurality of users…The list 807 of chunks 804 may comprise a plurality of links to select chunks 804. The list 807 of chunks 804 may comprise identification information associated with the select chunks 804. (¶ 124, 125)
receiving, by a receiver of the computing device, the subset of blocks from the blockchain node (¶ 116-128)
Gilson- The rights holder 801 may transmit different list 807 to one or more of the plurality of users. The lists 807 may be randomized. The lists 807 may comprise a mechanism to prevent a user 806 from downloading a chunk 804 from the distributor 805 more than once. For example, the lists 807 may comprise unique links, such as application programming interface (API) keys. A single unique link may only allow one access to a select chunk 804…The user 806 may access the select chunks 804 in the list 807, such as the chunks c3, c7, c8, c11, and c13. The user may request the chunks c3, c7, c8, c11, and c13 from the distributor 805. The distributor 805 may transmit the requested chunks c3, c7, c8, c11, and c13 to the user 806. (¶ 125, 126)
receiving, by the receiver of the computing device, the authentication code from a participant system that is external to the blockchain network (¶ 116-128)
Gilson- The chunks 804 may comprise a sequence. The rights holder 801 may know which chunks 804 in the sequence are valid and which chunks 804 in the sequence are invalid….The list 807 may comprise identification of select chunks 804 by their location in the sequence of chunks 804. …The rights holder 801 may make a decryption key associated with the content asset 802 available to the user 806. The rights holder 801 may make a decryption key associated with the content asset 802 available to the user 806 via a distributed database or directly. (¶ 121, 123, 124)
identifying, by a processor of the computing device, a plurality of data chunks in the subset of blocks using the authentication code (¶ 116-128)
Gilson- The chunks 804 may comprise a sequence. The rights holder 801 may know which chunks 804 in the sequence are valid and which chunks 804 in the sequence are invalid…The rights holder 801 may use the tally 808 to confirm that the chunks 804 in the lists 807 to the plurality of users 806 were provided by the distributor 805. For example, the rights holder 801 may compare the tally 808 to the record of the chunks 804 included in the lists 807 sent to the plurality of users 806. The verification of the tally 808 may serve as a provable billing system. The rights holder 801 may pay the distributor 805 based on the confirmation that the distributor 805 provided the chunks 804 in the lists 807. The distributor 805 may be deterred from falsifying the tally 808 because the distributor may not have knowledge of which chunks 804 were valid. (¶ 121, 128)
decoding, by the processor of the computing device, the transaction value by applying the fountain code algorithm to the identified plurality of data chunks; and (¶ 116-135)
Claim Interpretation - According to the disclosure(¶ 29), a fountain code algorithm is defined as “When a transaction value is to be pruned from the blockchain, the blockchain node 102, or a separate blockchain node 102 that may be configured to perform encoding processes on behalf of other blockchain nodes 102, may encode the transaction value into a plurality of verifiable data chunks using a fountain code algorithm, such as Raptor code or RaptorQ, which are fountain codes that encode a given source block of data consisting of a number k of equal size symbols into a sequence of encoding symbols.”
Gilson- The rights holder 801 may apply a code 803, such as a raptor code or a fountain code, to the content asset 802 to parse the content asset into a plurality of data chunks 804…. the rights holder 701 may make a decryption key 703 available to the user 705. The decryption key 703 may be like the decryption key 303 in FIG. 3. The decryption key 703 may be configured to decrypt the encrypted content asset 702. At step 750 a, the rights holder 701 may distribute the decryption key 703 across a network…The user 806 may decrypt the chunks c3, c7, c8, c11, and c13. The user 806 may combine the chunks c3, c7, c8, c11, and c13 to comprise the content asset 802… At step 840, the rights holder 801 may perform a proof of distribution to verify that the distributor 805 distributed the correct data chunks 804 to the one or more users 806. For example, if the distributor 805 charges the rights holder 801 for distributing data, the rights holder 801 may verify that the distributor 805 is charging the rights holder 801 for the correct amount of data. (¶ 119, 121, 126, 127)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Irazabal and Gilson(¶ 121), which teaches “the rights holder 801 may apply a code 803, such as a raptor code or a fountain code, to the content asset 802 to parse the content asset into a plurality of data chunks 804. A subset of the data chunks 804 may comprise valid parts of the content asset 802. Another subset of the data chunks 804 may comprise invalid data” in order to provide further protection to determine content that is valid and invalid (Gilson; ¶ 1-5, 121).
Regarding claims 2 and 10, Irazabal discloses displaying, by a display device interfaced with the computing device, a result of verifying the decoded transaction value (¶ 65).
Regarding claims 4 and 12, Irazabal discloses wherein verifying the decoded transaction value includes validating a digital signature included in the decoded transaction value using a public key of a cryptographic key pair (¶ 54-58, 79, 94, 125-127).
Regarding claims 5 and 13, Irazabal discloses wherein the authentication code is a product identifier associated with a product, and the decoded transaction value includes data indicating transfer of possession of the product (¶ 30-32, 40, 41, 47, 71-73, 92, 93).
Regarding claims 6 and 14, Irazabal discloses wherein the blockchain is a pruned blockchain (¶ 40-47, 70-76, 93-95).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tobin (US 20220103584) teaches pruning data and validating older blocks.
Joo (US 20220278858) teaches a verifiable pruning system.
Davies (US 20220216997) teaches a node verifying pruned transaction data, by providing a hash of the pruned data.
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, NEHA H PATEL can be reached on (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699