DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on July 26, 2024, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Examiner interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. Interviews conducted solely for the purpose of “sounding out” the examiner, including by local counsel acting only as a conduit for another practitioner, are not permitted under MPEP § 713.03. The Office is strictly enforcing established interview practice, and applicants should ensure that every interview request is directed toward advancing prosecution on the merits in compliance with MPEP §§ 713 and 713.03.
For after-final Interview requests, supervisory approval is required before an interview may be granted. Each AIR should specifically explain how the After-Final Interview request will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. If the AIR form’s character limits prevent inclusion of all pertinent details, Applicants may send a contemporaneous email to the examiner at James.Miller1@uspto.gov.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. EST.
For any GRANTED Interview Request, Applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for the denial.
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 .
Priority
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994); MPEP § 211.05.
The disclosure of the prior-filed applications, Applicant Nos. 16/569,350, 13/868,656, and 61/641,723, fail to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Examiner is unable to locate support, for example, for the following claims terms recited in each Independent Claim in the prior as-filed applications: hash, token, blockchain, or ledger (collectively, the blockchain components). Accordingly, the priority date for applying prior art is Sept. 21, 2022, which is filing date of Application No. 17/949,733.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on Jul. 26, 2024, was filed before the mailing of a first office action on the merits and therefore, is in compliance with the provisions of 37 CFR 1.97(b)(3). Accordingly, the IDS has been considered.
Claim Status
The status of claims is as follows:
Claims 1–18 are pending and examined with Claims 1, 7, and 13 in independent form.
This is a first action on the merits.
Examiner’s Statement of Eligibility Under 35 U.S.C. § 101
The claims are eligible under 35 USC § 101. Independent Claims are directed to a statutory category, recite an abstract idea exception, but integrate the abstract idea exception into a practical application in some other meaningful way through additional meaningful limitations when viewed as an ordered combination. MPEP § 2106.05(e) (citing Diamond v. Diehr, 450 U.S. 175, 188, 209 USPQ2d 1, 9 (1981) ("a new combination of steps in a process may be patentable even though all the constituents of the combination were well known and in common use before the combination was made")); see also BASCOM Global Internet Servs. v. AT&T Mobility LLC, 827 F.3d 1341, 1349, 119 USPQ2d 1236, 1242 (Fed. Cir. 2016). In combination, the additional meaningful limitations of exemplary Claim 1 are:
hashing, by a computing entity of a computing system in accordance with a securely passing process, a transaction record of a secure first token of a blockchain on an object distributed ledger to establish control over the secure first token […]
obtaining, by the computing entity, a copy of the object distributed ledger;
hashing, by the computing entity, an updated first set of smart contracts utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value, […]
encrypting, by the computing entity, the next transaction hash value utilizing a private key of the computing entity to produce a next transaction signature;
generating, by the computing entity, an updated secure first token for the blockchain of the object distributed ledger to include the updated first set of smart contracts, the next transaction signature, and a nonce, wherein the nonce is generated based on a remaining portion of the updated secure first token such that a number of zeroes of an updated secure first token hash value matches a desired characteristic for the updated secure first token, wherein the desired characteristic for the updated secure first token provides trust with regards to the updated secure first token; and
causing, by the computing entity, inclusion of the updated secure first token in the object distributed ledger.
These are meaningful computer system operations that are more than an instruction to apply the abstract idea with a computer. These limitations, in combination, are indicative of practical application. MPEP § 2106.05(e). Claims 1–18, in ordered combination, are integrated into a practical application by specifying a particular encryption scheme, involving multiple instances of nested encryption, using a public key, a private key and the characteristics of the token. MPEP § 2106.05(e). Furthermore, as an ordered combination, the clam limitations are also not well-understood routine or conventional.
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 (i.e., changing from AIA to pre-AIA ) 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, 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–18 are rejected under 35 U.S.C. 103 as being unpatentable over Perez et al. (U.S. Pat. Pub. No. 2022/0366358) [“Perez”] in view of Robyak et al. (U.S. Pat. No. 10,755,226) [“Robyak”] and further in view of Witchey (U.S. Pat. Pub. No. 2015/0332283) [“Witchey”].
Regarding Claim 1, Perez discloses disclose:
A computer-implemented method, the method comprises:
(See at least ¶ 2, “This disclosure relates generally to systems and methods for facilitating, controlling, and/or verifying manufacturing of products in a distributed supply chain.” See also, ¶ 4.)
hashing, by a computing entity [verification module 102] of a computing system in accordance with a securely passing process [keys + encrypted data], a transaction record [digital record] of a secure first token [encrypted, secure identifier] of a blockchain on an object distributed ledger to establish control over the secure first token representing a first product component [precursors] of a plurality of product components that are each required for manufacturing of a product, wherein only a device possessing control over the secure first token may modify the secure first token,
(See at least ¶ 43, “the verification module 102 may generate the encrypted, secure identifier for the product to be manufactured and update the blockchain.” The “distributed transaction ledger” are implemented using blockchains (¶ 139). ¶ 25, “the encrypted, secure identifier may include a hash value, which may be utilized to chain subsequently generated data relevant to the product together, forming an at least substantially unique, inalterable fingerprint for verifying the data and its association with the product.” ¶ 30, “Updating the blockchain with the data may involve … generating a hash … and incorporating a hash from a previous block in the blockchain to chain the block including the data to the previous block.” Access and updates are “securely passed” via encryption and keys. ¶ 28 (verification module 102 may utilize a public key to encrypt data … and a private key held solely by that participant … may be required to decrypt the data.”) ¶¶ 25, 30 describe the claimed “hashing … a transaction record of a first secure token … in accordance with a securely passing process.”)
The transaction record for the token is the data “relevant to the product” that gets chained together using the hash in the encrypted identifier (¶ 25). The verification module acting as the computing entity hashes that record (or data/updated data) into the identifier’s hash value “to chain subsequently generated data” (¶ 25). The verification module does this “in accordance with a securely passing process” because the data is passed/updated under encryption with pubic/[private keys and only authorized recipients with the keys can perform these operations (¶¶ 25, 28). ¶ 151, “granting selective access to identification of product designs in the first secure, distributed transaction ledger only upon receipt of an encrypted, secure identifier.” Thus, the updates to the blockchain are controlled by keys (¶ 28) and consensus. ¶ 46 (“updating the blockchain, particularly to add a new block to the blockchain, may require acceptance of the relevant data to be by consensus”). Accordingly, only the entity that possess the encrypted, secure identifier and the necessary keys can have the hashed updates accepted by consensus and can access the product record (date) and update the chained data on the blockchain. ¶ 4, “A third secure, distributed transaction ledger including a digital record of precursors for manufacturing the product designs in the digital inventory of the first secure, distributed transaction ledger may be maintained.”)
wherein records of each product component [industrial products – second ledger] of the plurality of product components links to records of a set of product sub-components [precursors – third ledger],
(See at least ¶ 4, “A third secure, distributed transaction ledger including a digital record of precursors for manufacturing the product designs in the digital inventory of the first secure, distributed transaction ledger may be maintained. The first, second, and third secure, distributed transaction ledgers may be interrelated and updated to associate digital records of at least some industrial products in the physical inventory of the second
secure, distributed transaction ledger with corresponding product designs in the digital inventory of the first secure, distributed transaction ledger and digital records of corresponding precursors in the third secure, distributed transaction ledger.” See also ¶ 115.)
wherein the secure first token [is generated by] a first set of smart contracts of the first product component,
(See at least ¶ 20, The system may automatically track and verify fulfillment of the terms (e.g., utilizing the one or more smart contracts enabled by the blockchain).” ¶ 33, “the ordering module 104 may include smart contract functionality enabled by the blockchain. For example, when an order is accepted via the ordering module 104, a smart contract incorporating the required product characteristics and any other required terms may be sent … The verification module 102 may update the blockchain to include a smart contract incorporating the required product characteristics and any other required terms.” ¶ 43, “the verification module 102 may generate a "digital twin" of the product to be manufactured, including the encrypted, secure identifier, sufficient information to identify the product, sufficient information to facilitate manufacturing the product, and any other terms in the order, and store the digital twin in the secure, distributed transaction ledger with the encrypted, secure identifier. Any smart contract to be executed in connection with the product may also be stored on the blockchain in connection with the digital twin.” Thus, for each product (or component) there exists a smart contract on the blockchain associated with that product’s encrypted identifier so the “first secure token” (identifier) has associated smart contracts.)
wherein the first set of smart contracts pertains to records of inventory management for the first product component and a corresponding set of product subcomponents,
(See at least ¶ 4, “A second secure, distributed transaction ledger including a digital record of an entity's physical inventory of industrial products may be maintained.” ¶ 40, “the physical inventory module 108 may be configured to track and analyze stock of precursor materials, precursor components, products, or any combination of these inventory items in a physical inventory of each respective entity granting authorization for the physical inventory module 108 of the system 100 to access that entity's physical inventory.” See also ¶ 41 (the physical inventory module 108 may proactively analyze an entity's physical inventory and a rate of depletion of the entity's physical inventory.”) ¶ 144, “track a stock of the at least some industrial products utilizing the second secure, distributed transaction ledger; and send a recommendation to replenish inventory of the at least some industrial products when the stock of the at least some industrial products is below a threshold.” See also ¶ 155 (tracking and sending recommendation to replenish). ¶ 20, “The system may automatically track and verify fulfillment of the terms (e.g., utilizing the one or more smart contracts enabled by the blockchain).)
wherein the records of inventory management includes entries to manage maintaining inventory of the first product component at an available volume level to facilitate the manufacturing of the product;
(See at least ¶ 41, the physical inventory module 108 may send a notification to a user of a current quantity of a given product and an estimated time at which stock is predicted to fall below a predetermined minimum with sufficient lead time for the user to place an order for one or more products utilizing the ordering module 104 and for those products to be manufactured and delivered before stock falls below the predetermined minimum.” ¶ 113, “track a stock of the at least some industrial products … send a recommendation to replenish inventory of the at least some industrial products when the stock of the at least some industrial products is below a threshold.” See also, ¶¶ 144, 145, 155.)
obtaining, by the computing entity, a copy of the object distributed ledger second secure, distributed transaction ledger];
(See at least ¶ 148, “syncing the second secure, distributed transaction ledger with a remote copy of the second secure, distributed transaction ledger via a network”)
hashing, by the computing entity, an updated [block] utilizing a receiving public key of the object distributed ledger to produce a next transaction hash value,
(See at least ¶ 30, “Updating the blockchain with the data may involve, for example, collecting the data in a block, generating a hash to verify the data, and incorporating a hash from a previous block in the blockchain to chain the block including the data to the previous block. … When acceptance by the relevant node or nodes has been received, a hash may be generated and applied to the block along with the hash from any preceding block, and the block with the applied hashes may be distributed to the nodes to add the block and update the blockchain.” ¶ 28, “the verification module 102 may utilize a public key to encrypt data to be sent to a given participant in the system 100 (e.g., a customer, a designer, a manufacturer, an auditor) … and a private key held solely by that participant and/or module may be required to decrypt the data.” In any standard blockchain transaction directed to a receiving party. The receiver’s public key (or an address derived from it) is included in the transaction data that is hashed to produce the transaction hash. Since Perez teaches standard blockchain hashing (¶ 28) directed to identified participants using public keys (¶¶ 28, 30), the has is produced “utilizing” the receiving public key as part of the transaction data. This is how “DSS” and “ECDSA” digital signature algorithms work. ¶ 28)
wherein the updated [block] represents subsequent estimated time-based inventory availability
(See at least ¶ 41, “the physical inventory module 108 may proactively analyze an entity's physical inventory and a rate of depletion of the entity's physical inventory. For example, the physical inventory module 108 may send a notification to a user of a current quantity of a given product and an estimated time at which stock is predicted to fall below a predetermined minimum with sufficient lead time for the user to place an order for one or more products utilizing the ordering module 104 and for those products to be manufactured and delivered before stock falls below the predetermined minimum. ... the physical inventory module 108 may automatically place an order with the ordering module 104 for a given product at a predetermined interval before a predicted depletion of stock of the product in the physical inventory, such as, for example, timed so that the product will likely be manufactured and delivered before stock falls below the predetermined minimum.”)
for the first product component and the corresponding set of product subcomponents to provide the available volume level to facilitate the manufacturing of the product;
(See at least Abstract, “A third secure, distributed transaction ledger including a digital record of precursors for manufacturing the product designs in the digital inventory may be maintained.” ¶ 32, “requested or required precursors for manufacturing the product (e.g., source materials, preformed components).” ¶ 113, “track a stock of the at least some industrial products utilizing the second secure, distributed transaction ledger. The system may be configured to send a recommendation to replenish inventory of the at least some industrial products when the stock of the at least some industrial products is below a threshold.”)
encrypting, by the computing entity, the next transaction hash value utilizing a private key of the computing entity to produce a next transaction signature;
(See at least ¶ 28, “the verification module 102 may utilize a public key to encrypt data … and a private key held solely by that participant and/or module may be required to decrypt the data. … Illustrative asymmetric encryption techniques usable by the verification module 102 may include, for example, Digital Signature Standard (DSS), Elliptic Curve Digital Signature Algorithm (ECDSA), Paillier cryptosystem, Rivest-Shamir-Adleman (RSA) encryption algorithm, etc.” ¶ 30, “When acceptance by the relevant node or nodes has been received, a hash may be generated and applied to the block along with the hash from any preceding block, and the block with the applied hashes may be distributed to the nodes to add the block and update the blockchain.” DSS and ECDSA algorithms produce digital signatures from hash and the private key in blockchain consensus.)
generating, by the computing entity, an updated secure first token for the blockchain of the object distributed ledger to include […, Robyak], the next transaction signature, [… See, Witchey]; and
(See at least ¶ 27, “the encrypted, secure identifier may be or include a token (e.g., a non-fungible token) operable in multiple blockchains (e.g., based on the same or different cryptographic algorithms) … the encrypted, secure identifier may be generated by invoking a token template defined by a set of attributes and control functions representative of a given asset (e.g., the product). When a token is created by the template, the token may incorporate the attributes and control functions of the template, which may then be deployed across multiple blockchains and recognized as a cross-chain token.” ¶ 29, “the verification module 102 may establish a new block in the blockchain including the data and a link or reference to the block including the encrypted, secure identifier, may update a not-yet-complete block in the blockchain already including the encrypted, secure identifier to incorporate the data, or may update a blockchain dedicated to the product with the [d]ata.” The “updated” refers to “UPDATE BLOCKCHAIN IN REAL TIME TO ASSOCIATE AT LEAST SOME VERIFICATION DATA WITH IDENTIFIER UTILIZING SECURE, DISTRIBUTED TRANSACTIONLEDGER” Fig. 4, step 408. See prior limitation mapping where Perez teaches digital signatures via DSS, ECDSA, and RSA and each communication is authenticated by a private key (¶ 82, “Each communication from the manufacturer may be authenticated, for example, by the manufacturer's use of a private key put in place during prequalification of the manufacturer to participate in the system 100.”). A digital signature produced by encrypting the hash with a private key would be included in or associated with the block/token in standard blockchain operation.)
causing, by the computing entity, inclusion of the updated secure first token in the object distributed ledger.
(See at least ¶ 30, “When acceptance by the relevant node or nodes has been received, a hash may be generated and applied to the block along with the hash from any preceding block, and the block with the applied hashes may be distributed to the nodes to add the block and update the blockchain.” ¶ 29, “the verification module 102 may update a blockchain with the data, and associate the data with, or link the data to, the encrypted, secure identifier, to update and maintain the record verifying the workflows for the product utilizing the secure, distributed transaction ledger. More specifically, the verification module 102 may establish a new block in the blockchain including the data and a link or reference to the block including the encrypted, secure identifier, may update a not-yet-complete block in the blockchain already including the encrypted, secure identifier to incorporate the data, or may update a blockchain dedicated to the product with the [d]ata.” See also, Fig. 4, steps 408, 410 (updating the distributed ledger with data associated with the token).
Perez discloses updating the blockchain ledger with verification data but the smart contract themselves are not described as being updated. Perez’s smart contracts are created at order time and execute upon verification of terms—they are not updated to reflect changing data. Perez discloses tokens generated by smart contracts but does not explicitly disclose tokens include smart contracts. Thus, Perez does not explicitly teach but Robyak discloses:
updated first set of smart contracts
(See at least col. 10:11–3, “These smart contracts are updated throughout the life Cycle of the asset, allowing for a complete tracking of all changes, upgrade, replaced failed parts, etc.” See also, Claims 1, 11, Fig. 4, steps 404, 406, 412, 416, 422, 426, 430, 432.
wherein the secure first token includes a first set of smart contracts of the first product component,
(See at least col.1:32–6, “The information management system comprises a blockchain infrastructure configured to maintain a blockchain for one or more smart contracts generated for one or more assets managed by the information management system.” Col. 4:37–42, “Such an information management system is configured to tie every asset shipped by a company, whether it is a hardware asset, a software asset, or combinations thereof, with a smart contract. The system is configured to provide granularity down to a single asset such as, for example, a drive or a single LCC (link control card).” Col. 5:8–10, “Smart contracts are respectively maintained for each asset in a composition of assets, as well as for the composition itself.” Col. 7:51–3, “The smart contract tracks any components and subcomponents through their hardware identifiers (IDs) and/or serial numbers.” See also, Fig. 5.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined iteratively updating smart contracts throughout an assets lifecycle and the secure first token includes a first set of smart contracts of the first product component, as explained in Robyak, to the known blockchain-based manufacturing inventory management system of Perez, in the same field of invention, with the motivation to have a “single source of accurate information (i.e., truth) for all systems that access the information management system such as, but not limited to, supply chain management and/or asset tracking systems” to improve the manufacturing inventory management system of Perez. Robyak, col. 4:61–4. Perez already uses smart contracts and updates blockchain records so combining the approaches would be a predictable application of known techniques. A PHOSITA would be motivated to adopt Robyak’s token that includes a smart contract structure to “not only secure the entire lifecycle tracking process, but also simplifies the reporting and tracking of all aspects of the given asset.” Robyak, col. 7:58–60.
Perez does not disclose but Witchey discloses:
generating, by the computing entity, an updated secure first token [validity block] for the blockchain of the object distributed ledger [HHBS 130]
(See at least Fig. 3, step 301, “For each of one or more transactions, assemble current candidate validity block including a nonce and the following healthcare parameters: historical block identifier, health care token(s), validity token(s), and digital signature(s) of va!idator(s).” Claim 1, “calculating, by the validation device, a validity block for at least the healthcare transaction according the validity requirement as a function of the following healthcare parameters: the validity token, historical block identifier, the set of healthcare tokens, and the digital signature.”)
to include … the next transaction signature, and a nonce,
(See at least ¶ 50, “Step 240 continues by obtaining a digital signature of a validator.” See also, Fig. 3, step 301, “assemble current candidate validity block including a nonce
and the following healthcare parameters: historical block identifier, health care token(s), validity token(s), and digital signature(s) of va!idator(s).” See also, Claim 30 (nonce).
wherein the nonce is generated based on a remaining portion of the updated secure first token such that a number of zeroes of an updated secure first token hash value matches a desired characteristic for the updated secure first token,
(This is a PoW mining puzzle. See at least Fig. 3, nonce iteration loop, steps 302, 304, 305. The nonce is incremented based on the remaining portion of the block and the block is re-hashed until the requirement is met. ¶ 40, “peer 120B can increment a nonce value until a hash is generated having the desired proof-of-work characteristics, perhaps a number of leading zero bits among other factors.” ¶ 48, “The validity requirement can provide a proof-of-work difficulty such as requiring a number of leading zero bits in a hash value generated based on the transaction information.” ¶ 57, “One example of a typical proof-of-work validity requirement in this context is that the hash result has a certain number of leading zeros.” Claim 16, “the first hash is selected from the group consisting of: SHA, Scrypt, MD5, RIPEMD, and WHIRLPOOL.” The PoW requirement is the “desired characteristic”)
wherein the desired characteristic for the updated secure first token provides trust with regards to the updated secure first token; and
(See at least Abstract, “The devices establish a validity of the transaction and generate a new block via a proof-of-work principle. Once the new block has been calculated it can be appended to the stakeholder's health care blockchain.” ¶ 17, “Such a validation approach ensures that all entities are held responsible for their transactions by peer review while also preserving a record of healthcare transactions.” ¶ 55, “by providing the information other peers in the network, the peer can validate the proof-of-work.” The PoW requirement is the “desired characteristic” that establishes trust.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined generating an updated secure first token including the next transaction signature, and a nonce wherein the nonce is generated based on a remaining portion of the updated secure first token such that a number of zeroes of an updated secure first token hash value matches a desired characteristic for the updated secure first token and wherein the desired characteristic for the updated secure first token provides trust with regards to the updated secure first token, as explained in Witchey, to the known blockchain-based manufacturing inventory management system of Perez, in the same field of invention, with the motivation to enhance the trustworthiness and immutability of Perez's manufacturing verification blockchain by implementing a proof-of-work consensus mechanism that validates blocks through computational difficulty rather than relying solely on multi-party consensus, thereby providing cryptographic proof that computational resources were expended to validate each manufacturing transaction and preventing malicious actors from easily rewriting the blockchain history. Witchey, Abstract. Alternatively, an additional motivation is to provide another layer of fraud prevention and accountability in Perez's manufacturing verification system by requiring validators to expend computational resources to add blocks to the blockchain, thereby making it economically infeasible for any single party to fraudulently modify historical manufacturing records. Witchey, ¶¶ 44, 71.)
Regarding Claim 2, Perez, Robyak, and Witchey discloses:
The method of claim 1
Perez does not disclose but Witchey discloses:
further comprises: generating, by the computing entity, the nonce based on the remaining portion of the updated secure first token such that a number of preceding zeroes of the updated secure first token hash value matches a desired number of preceding zeros [leading zero bits].
(See at last Fig. 3, step 301 (cited supra) disclosing the iterative nonce generation process. See also, Fig. 3, steps 302, 304. The nonce is generated iteratively based on the remaining portion (the other data in the block) by incrementing it until the hash meets the requirement. ¶ 40, “peer 120B can increment a nonce value until a hash is generated having the desired proof-of-work characteristics, perhaps a number of leading zero bits among other factors.” ¶ 48, “The validity requirement can provide a proof-of-work difficulty such as requiring a number of leading zero bits in a hash value generated based on the transaction information.” ¶ 57, “One example of a typical proof-of-work validity requirement in this context is that the hash result has a certain number of leading zeros.” Claim 16, “the first hash is selected from the group consisting of: SHA, Scrypt, MD5, RIPEMD, and WHIRLPOOL.” The PoW requirement is the “desired characteristic”) The “number” is the difficulty target (the desired characteristic that can be set.)).
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 2.
Regarding Claim 3, Perez, Robyak, and Witchey discloses:
The method of claim 1
Perez further discloses
further comprises: establishing, by the computing entity, the secure first token
(See at least ¶ 25, “The verification module 102 may be programmed and configured to generate an encrypted, secure identifier for each product to be made, the encrypted, secure identifier configured to identify the physical product, once made, and enable data verifying workflows for manufacturing the product to be collected and verified.” ¶ 27, “the encrypted, secure identifier may be or include a token (e.g., a non-fungible token) operable in multiple blockchains (e.g., based on the same or different cryptographic algorithms).” ¶ 29, “the verification module 102 may update a blockchain with the data, and associate the data with, or link the data to, the encrypted, secure identifier, to update and maintain the record verifying the workflows for the product utilizing the secure, distributed transaction ledger
in accordance with the securely passing process
(See at least ¶ 28, “the verification module 102 may utilize a public key to encrypt data to be sent to a given participant in the system 100 (e.g., a customer, a designer, a manufacturer, an auditor) or otherwise to be used by a module of the system 100, and a private key held solely by that participant and/or module may be required to decrypt the data.” ¶ 30, “Updating the blockchain with the data may involve, for example, collecting the data in a block, generating a hash to verify the data, and incorporating a hash from a previous block in the blockchain to chain the block including the data to the previous block. When a node (i.e., a computer system authorized to participate in the blockchain) generates a block to be added to the blockchain, consensus from at least one other node on the blockchain network may be requested (e.g., required) to validate the block and officially add it to the blockchain.”)
to represent [blocks] of the first product component associated with the inventory management for the first product component and the corresponding set of product subcomponents.
(See at least ¶ 4, “A third secure, distributed transaction ledger including a digital record of precursors for manufacturing the product designs in the digital inventory” ¶ 32, “requested or required precursors for manufacturing the product (e.g., source materials, preformed components).” ¶ 40, “the system 100 may include a physical inventory module 108 programmed and configured to track and analyze a physical inventory of one or more entities participating in the system. For example, the physical inventory module 108 may be configured to track and analyze stock of precursor materials, precursor components, products, or any combination of these inventory items in a physical inventory of each respective entity granting authorization for the physical inventory module 108 of the system 100 to access that entity's physical inventory.”
Perez does not disclose but Robyak discloses
establishing … the secure first token to represent the first set of smart contracts of the first product component
(See at least col.1:32–6, “The information management system comprises a blockchain infrastructure configured to maintain a blockchain for one or more smart contracts generated for one or more assets managed by the information management system.” Col. 4:37–42, “Such an information management system is configured to tie every asset shipped by a company, whether it is a hardware asset, a software asset, or combinations thereof, with a smart contract. The system is configured to provide granularity down to a single asset such as, for example, a drive or a single LCC (link control card).” Col. 5:8–10, “Smart contracts are respectively maintained for each asset in a composition of assets, as well as for the composition itself.” Col. 7:51–3, “The smart contract tracks any components and subcomponents through their hardware identifiers (IDs) and/or serial numbers.” See also, Fig. 5.)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 3.
Regarding Claim 4, Perez, Robyak, and Witchey discloses:
The method of claim 1
Perez further discloses
further comprises: issuing a secure first token update request to an object ledger computing entity of the computing system serving as a blockchain node of the object distributed ledger,
(See at least ¶ 29, “the verification module 102 may accept the data from another module, optionally encrypt the data, and update the blockchain to include the data in such a way that the data is associated with the encrypted, secure identifier of the product.” See also, Fig. 4, steps 408, 410. ¶ 30, “When a node (i.e., a computer system authorized to participate in the blockchain) generates a block to be added to the blockchain, consensus from at least one other node on the blockchain network may be requested (e.g., required) to validate the block and officially add it to the blockchain. … When acceptance by the relevant node or nodes has been received, a hash may be generated and applied to the block along with the hash from any preceding block, and the block with the applied hashes may be distributed to the nodes to add the block and update the blockchain.” ¶ 46, “each party hosting a node of the blockchain.”)
Perez discloses sending smart contracts to the verification module and adding them to the blockchain but doesn’t explicitly describe the update request itself including updated smart contracts. Thus, Perez does not disclose but Robyak discloses:
wherein the secure first token update request includes the updated first set of smart contracts.
(See at least Col. 5: 1–4, “Any additions, subtractions, or other changes to the asset are required to submit a secured transaction back to the private chain for validation before updating the smart contract associated with the asset.” Col. 7:9–12, “when new transaction data (transaction) is received by the smart contract 310 for a given asset, the transaction is first verified by the blockchain nodes 224-1, 224-2, ... , 224-X”).
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 4.
Regarding Claim 5, Perez, Robyak, and Witchey discloses:
The method of claim 1 and hashing, in accordance with the securely passing process, the transaction record of the secure first token of the blockchain on the object distributed ledger to establish control over the secure first token
Perez further discloses
wherein the hashing, in accordance with the securely passing process, the transaction record of the secure first token of the blockchain on the object distributed ledger to establish control over the secure first token further comprises: receiving an indication of the control [nodes requesting to add/update] over the secure first token from a requesting computing entity; and
(See at least ¶ 30, When a node (i.e., a computer system authorized to participate in the blockchain) generates a block to be added to the blockchain, consensus from at least one other node on the blockchain network may be requested (e.g., required) to validate the
block and officially add it to the blockchain … the verification module 102 may query at least one other node (and potentially all other nodes) participating on the blockchain to confirm acceptance of the data, potentially prompting review of the data. When acceptance by the relevant node or nodes has been received, a hash may be generated and applied to the block along with the hash from any preceding block, and the block with the applied hashes may be distributed to the nodes to add the block and update the blockchain.”)
establishing an identity of the computing entity to have control over the secure first token.
(See at least ¶ 28, “the verification module 102 may utilize a public key to encrypt data to be sent to a given participant in the system 100 (e.g., a customer, a designer, a manufacturer, an auditor) or otherwise to be used by a module of the system 100, and a private key held solely by that participant and/or module may be required to decrypt the data. The private key, and optionally the public key, may be selected and distributed when screening and authenticating potential participants for participation in the system 100. … The private keys may be selected and distributed in advance, such as, for example, when screening and authenticating potential participants for participation in the system 100.” ¶ 82, “Each communication from the manufacturer may be authenticated, for example, by the manufacturer's use of a private key put in place during prequalification of the manufacturer to participate in the system 100.” See also, ¶¶ 34, 36.)
Regarding Claim 6, Perez, Robyak, and Witchey discloses:
The method of claim 1
Perez further discloses
further comprises: modifying the first set of [blockchain records/blocks] to produce the updated first set of [blockchain records/blocks]
(See at least ¶ 4, “The first, second, and third secure, distributed transaction ledgers may be interrelated and updated.” See also, Fig. 4, steps 408, 410.
to facilitate subsequent estimated time-based inventory availability for the first product component and the corresponding set of product subcomponents to provide the available volume level to facilitate the manufacturing of the product, wherein the modifying includes:
(See at least ¶¶ 2, 4, 118, 41 (all cited supra).
interpreting a digital record of the first product component to determine when the subsequent estimated time-based inventory availability for the first product component and the corresponding set of product subcomponents fails to provide the available volume level to facilitate the manufacturing of the product;
(See at least ¶ 41, “the physical inventory module 108 may proactively analyze an entity's physical inventory and a rate of depletion of the entity's physical inventory. For example, the physical inventory module 108 may send a notification to a user of a current quantity of a given product and an estimated time at which stock is predicted to fall below a predetermined minimum with sufficient lead time for the user to place an order for one or more products utilizing the ordering module 104 and for those products to be manufactured and delivered before stock falls below the predetermined minimum.” ¶ 118, “send a recommendation to replenish inventory of the precursors when the first stock of the at least some industrial products is below a first threshold, the second stock of the precursors is below a second threshold, or both.” See also, ¶ 4.
interpreting the digital record of the first product component to identify an element [digital record] associated with the one or more of the first product component and a particular product sub component of the corresponding set of product subcomponents;
(See at least ¶ 82, “Before proceeding to manufacture, the system 100 may require receipt of verification of precursor materials and/or components 218 from a client device of the manufacturer. For example, the system 100 may require receipt of images and/or digital records of the source and composition of materials to be utilized during manufacturing. The system 100 may also require receipt of images and/or digital records
of the source and identification of any premade components to be used when manufacturing and/or assembling the product. Each communication from the manufacturer may be authenticated, for example, by the manufacturer's use of a private key put in place during prequalification of the manufacturer to participate in the system 100.” ¶ 4, “The first, second, and third secure, distributed transaction ledgers may be interrelated and updated to associate digital records of at least some industrial products in the physical inventory of the second secure, distributed transaction ledger with corresponding product designs in the digital inventory of the first secure, distributed transaction ledger and digital records of corresponding precursors in the third secure, distributed transaction ledger for end-to-end verification of sourcing and design for the at least some industrial products.”
determining a modification to the digital record of the first product component for the element of the first set of [digital records] to facilitate the subsequent estimated time-based inventory availability for the first product component in the corresponding set of product subcomponents to provide the available volume level to facilitate the manufacturing of the product; and
(See at least ¶ 118, “send a recommendation to replenish inventory of the precursors when the first stock of the at least some industrial products is below a first threshold, the second stock of the precursors is below a second threshold, or both.” See also, ¶¶ 40, 41 (cited supra).)
[…] updating the first set of [digital records] to include the modification to the digital record of the first product component for the element of the first set of [digital records] to produce the updated first set of [digital records].
(See at least Fig. 4, step 408 and ¶ 29 (cited supra).)
Perez updates blockchain records, not specifically, “smart contracts” as claimed. Perez identifies digital records but doesn’t explicitly identify “an element of a smart contract” as claimed. Perez determines modifications to inventory/ledger records, but not explicitly to “smart contracts.” Perez updates blockchain records but nor explicitly smart contracts as claimed.
modifying the first set of smart contracts to produce the updated first set of smart contracts
(See at least col. 10:11–3, “These smart contracts are updated throughout the life cycle of the asset, allowing for a complete tracking of all changes, upgrade, replaced failed parts, etc.”
identify an element of the first set of smart contracts
(See at least col. 5:8–10, “Smart contracts are respectively maintained for each asset in a composition of assets, as well as for the composition itself.” Col. 7:51–3, “The smart contract tracks any components and subcomponents through their hardware identifiers (IDs) and/or serial numbers.” Abstract, “one or more application programming interfaces configured to provide access to the one or more smart contracts of the blockchain enabling input of data to a given smart contract for a given asset and retrieval of data from the given smart contract of the given asset.”)
determining a modification to the digital record of the first product component for the element of the first set of smart contracts
(See at least col. 5:1–4, “Any additions, subtractions, or other changes to the asset are required to submit a secured transaction back to the private chain for validation before updating the smart contract associated with the asset.”)
updating the first set of smart contracts to include the modification to the digital record of the first product component for the element of the first set of smart contracts to produce the updated first set of smart contracts.
(See at least Claim 11, “updating the given smart contract for the given asset throughout a lifecycle of the given asset.” Col. 10: 11–3, “These smart contracts are updated throughout the lifecycle of the asset, allowing for a complete tracking of all changes, upgrade, replaced failed parts, etc.” Col. 7:9–15, “when new transaction data (transaction) is received by the smart contract 310 for a given asset, the transaction is first verified by the blockchain nodes 224-1, 224-2, ... , 224-X and only when consensus, i.e., at least 50% of the nodes have reached the same result ( e.g., the transaction is verified as legitimate), is the transaction committed to the blockchain,” effectively “updating the smart contract associated with the asset.” Col. 5:3–4.)
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 6.
Regarding Claim 7, Perez teaches:
A computing entity of a computing system comprises: an interface; a local memory; and a processor operably coupled to the interface and the local memory, wherein the processor performs functions to:
(See at least ¶¶ 4, 30)
The remaining limitations of Claim 7 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Perez, Robyak, and Witchey for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 7.
Regarding Claims 8, 9, 10, 11, and 12, Perez, Robyak, and Witchey disclose:
The computing entity of claim 7
The remaining limitations of Claims 8, 9, 10, 11, and 12 are not substantively different than those presented in Claims 2, 3, 4, 5, and 6, respectively, and are therefore, rejected, mutatis mutandis, based on Perez, Robyak, and Witchey for the same rationale presented in Claims 2, 3, 4, 5, and 6, respectively, supra.
Regarding Claim 13, Perez teaches:
A non-transitory computer readable memory of a computing system comprises: a first memory element that stores operational instructions that, when executed by a processor of a computing entity, causes the processor to:
(See at least ¶¶ 23, 24,)
The remaining limitations of Claim 13 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Perez, Robyak, and Witchey for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 13.
Regarding Claims 14, 15, 16, 17, and 18, Perez, Robyak, and Witchey disclose:
The non-transitory computer readable memory of claim 13
The remaining limitations of Regarding Claims 14, 15, 16, 17, and 18 are not substantively different than those presented in Claims 2, 3, 4, 5, and 6, respectively, and are therefore, rejected, mutatis mutandis, based on Perez, Robyak, and Witchey for the same rationale presented in Claims 2, 3, 4, 5, and 6, respectively, supra.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694