/6Notice 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 .
DETAILED ACTION
This Final action is in reply to the arguments/remarks filed 1/13/2026.
Claims 1, 2, 4, 8, 11, 15, 18 and 23 have been amended.
Claims 3, 5-7, 17, 19 and 22 have been cancelled.
Claims 1, 2, 4, 8-16, 18, 20, 21 and 23 are pending.
Information Disclosure Statement
The Information Disclosure Statement (IDS) submitted on 1/13/2026 has been considered and initialed by the examiner.
Response to Arguments/Amendments
Applicant’s declaration traversing rejections filed 1/13/2026 is acknowledged.
The declaration under 37 CFR 1.132 filed 1/13/2026 is insufficient to overcome the rejection of claims 1-23 as being directed to an abstract idea without significantly more under 35USC101, and as being unpatentable over Batra et al., US Patent Application Publication No US 2018/0137465 A1 in view of Wentz US Patent Application Publication No US2020/0162268 A1 as applied under 35USC103 set forth in the last Office action because: It includes statements which amount to an affirmation that the claimed subject matter functions as it was intended to function. This is not relevant to the issue of nonobviousness of the claimed subject matter and provides no objective evidence thereof. Examiner established a prima facie case of obviousness, supported by evidence, showing why the claims at issue would have been obvious in light of the prior art references (noted above) before the effective filing date of the claimed invention; and further evaluated the claims based upon Mayo/Alice analysis under USC 101 two-step framework and provided the results of the analysis in the Non Final action dated 8/13/2025. Applicant’s declaration fails to provide rebuttal evidence since it refers only to the system described in the above referenced application and not to the individual claims of the application. As such the declaration does not show that the objective evidence of nonobviousness is commensurate in scope with the claims. Applicant’s conclusory statements have been considered but are not of substantial evidentiary value when considered in light of all the evidence of record in the application. In re Brandstadter, 484 F.2d 1395, 179 USPQ 286 (CCPA 1973).
In view of the foregoing, when all of the evidence is considered, the totality of the rebuttal evidence of nonobviousness fails to outweigh the evidence of obviousness.
With respect to the 35USC101 rejection applicant argues, “the embodiments of the invention…represent an improvement to existing technologies…These improvements stem from the ability to separately manage distinct, but linked, chains of claim elements and evidence elements”, and that, “the orthogonal chain structure…will reduce ‘both the storage and processing resources required to store and access the OSDS/CSDS”. Applicant then states the claims recite additional elements that reflect an improvement in the functioning of a computer, or an improvement to other technology or field and are directed to patentable subject matter. Applicant’s arguments have been reconsidered but are not persuasive.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “orthogonal chain structure”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). As noted in the declaration (page 2) submitted 1/13/2026, it discusses that the invention is directed to “establishing a set of predefined conditions associated with an object story data structure (OSDS) and subsequently accessing the OSDS to determine whether the predefined conditions are met”. It also discusses that, “The OSDS was specifically designed to store information about an object” …and one or more chains of evidence elements”, “The OSDS may be fully recursive and may include or contain links to component story data structures (CSDS) that include information about a component of the object” and that, “the system is to ‘determine whether the plurality of conditions are met based on the claims/evidence chains for the recursive object story data structure and the recursive component story data structure”. In addition, applicant’s disclosure also emphasizes methods/systems for maintaining information about various subjects of a marketplace whereby information is created, provided and claimed. Claims are accompanied by evidence information that proves the validity of the claim, which is aggregated and stored during the lifetime of the product (¶42), and ¶63 discusses that the object story represents the collection of information (in particular claims and evidence) about aspects of a lifecycle of an object embodied in an object story data structure stored in one or more of a set of networked, distributed computing nodes and data structures. While ¶126 and ¶127, and Fig 14 describes operations of an electronic contract between two entities which specifies conditions the electronic contract takes if conditions are/are not met. Examiner contends that the invention is directed toward the abstract idea for identifying a plurality of conditions, accessing a recursive object story data structure, accessing a recursive component story data structure, determining whether a plurality of conditions are met and outputting an indication of whether the plurality of conditions are met in a computing environment. Hence, pertains to (i) mental processes grouping of abstract ideas (concepts performed in the human mind (including an observation, evaluation, judgment, opinion) or by a human being with a pen and paper, and (ii) commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising; marketing; or sales activities or behaviors; business relations) and (iii) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) and directed to certain methods of organizing human activity groupings of abstract ideas. Applicant’s computing components (“non-transitory, computer-readable storage media”, “one or more processors”, “one or more modules of a system”, “object story data structure”, “component story data structure”, “distributed ledger”, “blockchain”, “cryptographic hash” [claim 1]; and “system”, “memory”, “a network interface”, “processing circuitry”, [claim 11]) for identifying, accessing, determining, and outputting, are well-known, performing routine and conventionally activity, and generically used as a tool (see at least ¶58, ¶63, ¶65, ¶77, ¶90, ¶151, ¶155, ¶305, ¶307, ¶308, ¶311, ¶342 of applicant’s disclosure) for data gathering, and analysis based on rules logic to further process received information and to implement the abstract idea. Moreover, giving the broadest reasonable interpretation of applicant’s (recursive) object story data and (recursive) component story data structure in light of the specification, the claimed elements are merely used to store, share and/or update data based on user permissions (see ¶58: “Object story data structure: a data structure that includes or incorporates elemental aspects of an object story, the data structure or elemental aspects may be distributed across set of networked, distributed nodes”; ¶63: “The object story represents the collection of information (in particular claims and evidence) about aspects of a lifecycle of an object. This information constituting an object story is embodied in an object story data structure that may be stored in one or more of a set of networked, distributed computing nodes and data structures… The object story may represent elemental aspects over the development and functional lifetime of the object. It may also be recursive in its nature.”; ¶77: “The computing information system 260 implement, in software and hardware, the roles of the various actors in Figure 1, accessing (for example, reading or writing) the object story or elements thereof as necessary”; ¶155: “The component object story may include information about a component (for example, an ingredient, a part, or subassembly) of a product or about a sub-part of a larger entity/location/facility (for example a building as a part of a facility, or a department as part of a company)”; ¶307: processors 3801 may access object story code 3807 stored in the memory/storage 3802. Upon executing the object story code 3807 the device 3800 may manage (including generating, accessing, storing, etc.) object story data structures 3808 as described herein”). Hence, the recursive object data structure and component data structure merely maintain information in the lifecycle process of an object in a customized manner utilizing generic computing components in a manner that is well-understood, routine and conventional (storing, updating, managing data) in the field and recited at a high level of generality. Examiner again reiterates that there is no improvement to the computer functionality itself, nor is there evidence in the disclosure to suggest achieving an actual improvement to the blockchain technology. Applicant’s In addition, the disclosure only generically teaches using distributed ledgers/blockchains to incorporate claims and evidence elements in a manner that is also well-understood, routine and conventional activities (a (secured) shared distributed database) to perform the abstract idea. Collecting and organizing data is mere automation of a manual process that was performed before computers and thus not an improvement to a computer or any specific computer technology-see MPEP 2106.05. Similarly, “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer” does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ22d 1636, 1639 (Fed. Cir. 2015).
Considering applicant’s claim(s) both individually and as an ordered combination they fail to add subject matter beyond the judicial exception that is not well-understood, routine, and conventional in the field. Therefore, applicant has not shown an improvement in the computer functionality itself, or any specific computer technology (distributed ledger or blockchain); nor do the claim limitations integrate the abstract idea into any practical application under the guidance of MPEP section 2106.04(d) or 2106.05(a). In view of the above, Examiner maintains that the claimed invention is directed to an abstract idea.
With respect to the 35USC 103 rejection applicant argues, “Wentz fails to teach or suggest the recursive object/component data structures as recited in claim 1… a recursive object story data structure that includes a first chain of claim elements and a first chain of evidence elements”. Applicant then states, “The digitally signed assertion of Wentz is not ‘a first statement about a product’ as recited in claim 1, nor is the confidence level ‘a first evidence element that supports the first statement with a first level of evidence. Thus, Wentz does not teach or suggest storing the different types of information recited in claim 1 at all, much less storing them in an orthogonal chain structure as specifically recited in claim 1” Applicant’s arguments have been considered but are unpersuasive, Examiner does not consider Wentz to be as limiting as applicant avers. Examiner points applicant to Wentz, Fig 6A, ¶34 where it discusses ‘the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements’ and ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… may describe a transfer of virtual currency, such as crypto currency…The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity. Item of value may be an interest in a fungible negotiable financial instrument representing ownership in a public or private corporation, a creditor relationship with a governmental body or a corporation, rights to ownership represented by an option, derivative financial instrument, commodity, debt-backed security such as a bond or debenture or other security…may describe the transfer of a physical good; for instance, at least a digitally signed assertion 200 may describe the sale of a product”. Wentz further discloses in ¶57: “Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries”; ¶64: “utilizing a separate chain”; 88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like”; and ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “. Batra teaches a block chain configuration for storing smart contracts including but not limited to identifying smart contract information from a blockchain and more particularly to anticipating and monitoring transactions in the blockchain to determine whether the smart contract requirements can be enforced. Wentz discloses a method/system for at least receiving a communication from any suitable data structure, including a first digitally signed assertion which may be recorded in a second temporally sequential listing, via a blockchain or distributed ledger. Wentz further discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz also teaches that a sequence of digitally signed assertions may be created and may refer to previously entered data that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions and that authenticating may include verifying earlier hashes in a hash chain, block chain and/or verifying back to a genesis block. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries. Barta and Wentz are directed to the same endeavor since they are related to recording/storing and authenticating data/information in a distributed ledger/blockchain computing environment. Further it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to use the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz for authenticating and importing digitally signed assertions and files from a first distributed network, or first block chain to a second block chain or second distributed network cryptographic immutable ledgers, such as another block chain or immutable ledger using a side chain, hash tree or the like. The known techniques/tools for receiving, authenticating, generating and importing digitally signed assertions of Wentz would have predictably resulted in an improved architecture and process for maintaining and controlling access to a cryptographically secured ledger where each link in the chain contains encrypted or hashed information and a timestamp of the entry (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶64, ¶65, ¶101-111). Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz since it allows for providing digitally signed assertions and files including an attestation conferring proof of endorsement, modifying and/or verifying back to a genesis block, maintaining and controlling access to a cryptographically secured ledger, block chain, side chain, hash tree or the like, (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶61,¶64, ¶65, ¶88, ¶98-111). Moreover, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “storing them in an orthogonal chain structure as specifically recited in claim 1”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant subsequently states, Batra and Wentz further fail to teach or suggest that "a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”, and that, “the combination of Batra and Wentz cannot be said to teach or suggest that one of the predefined conditions is that an "evidence element ... supports the statement about the object with at least a threshold level of evidence” Examiner notes that applicant argues the amended claim limitations which were not previously presents. Applicant’s amendments necessitated new grounds of rejection, therefore the respective arguments are moot. Examiner has modified the rejection to further explain how the claim limitations are being interpreted and has addressed each of the claims as noted below in this Final action.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 2, 4, 8-16, 18, 20, 21 and 23 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 11 and 18 recite in part, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”. Examiner was unable to find support in the disclosure for this limitation, nor does the specification demonstrate that applicant has made an invention that achieves the claimed function since the invention is not described in sufficient details such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention. For example, the specification as filed does not properly convey how “a threshold level of evidence” is determined. The disclosure at ¶88, ¶120 and ¶121 appears to be a general guideline about various levels of evidence and/or importance. However, it does not support or adequately describe how a threshold level of evidence is determined and used, as it relates to the limitation, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence” nor does it allow a person of ordinary skill in the art to recognize that the applicant has invented what is claimed. The respective dependent claims do not remedy this flaw; therefore, they are also rejected.
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 1, 2, 4, 8-16, 18, 20, 21 and 23 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.
Claims 1, 11 and 18 recite in part, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”, however, the limitation is ambiguous. Examiner is unable to determine the metes and bounds of this limitation. Applicant fails to clearly and distinctly describe the steps for how “a threshold level of evidence” is determined, used and/or calculated with respect to the limitation, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”? The respective dependent claims do not remedy this flaw; therefore, they are also rejected. For purposes of prior art, Examiner interprets this limitation as, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with a level of evidence”.
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, 2, 4, 8-16, 18, 20, 21 and 23 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1, 2, 4, 8-16, 18, 20, 21 and 23 are directed to a non-transitory computer-readable storage media [claims 1, 2, 4, and 8-10], a system [claims 11-16], and a process (an act, or series of acts or steps) [claims 18, 20, 21 and 23]. Thus claims 1, 2, 4, 8-16, 18, 20, 21 and 23 fall within one of the four statutory categories.
Step 2A-Prong 1:
Claim 1 recites in part, “identify a plurality of conditions; access a recursive object story data structure that includes a first chain of claim elements, a first chain of evidence elements, and a recursive component story data structure
wherein a first claim element of the first chain of claim elements includes: a cryptographic hash of one or more previous claim elements in the chain of claim elements; a link to a subsequent claim element in the chain of claim elements; a statement about an object that is a facility, an entity, or a location; and an indication of a first evidence element of the first chain of evidence elements,
wherein the first evidence element is cryptographically linked with the first claim element, supports the statement about the object with a first level of evidence selected from a plurality of levels of evidence; and includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements,
wherein individual evidence elements of the first chain of evidence elements support the statement about the object with individual levels of evidence and each of the first chain of claim elements and the first chain of evidence elements are implemented in a distributed ledger or blockchain;
access the recursive component story data structure that includes a second chain of claim elements and a second chain of evidence elements wherein a claim element of the second chain of claim elements includes: a statement about a component of the object; and an indication of an evidence element of the second chain of evidence elements that supports the statement about the component,
with a second level of evidence selected from the plurality levels of evidence, wherein individual evidence elements of the second chain of evidence elements support the statement about the component with individual levels of evidence,
wherein: the object is an entity and the component is a department, team, or individual of the entity; the object is a facility and the component is a sub-facility; or the object is a first location and the component is a second location within the first location;
determine whether the plurality of conditions are met based on the first chain of claim elements the first chain of evidence elements, the second chain of claim elements, and the second chain of evidence elements;
wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence;
output an indication of whether the plurality of conditions are met,
The underlined limitations above demonstrate independent claim 1 is directed toward the abstract idea for identifying a plurality of conditions, accessing a recursive object story data structure, accessing a recursive component story data structure, determining whether a plurality of conditions are met and outputting an indication of whether the plurality of conditions are met in a computing environment. Applicant’s specification ¶42 emphasizes methods/systems for maintaining information about various subjects of a marketplace whereby information is created, provided and claimed. Claims are accompanied by evidence information that proves the validity of the claim, which is aggregated and stored during the lifetime of the product. ¶63 discusses that the object story represents the collection of information (in particular claims and evidence) about aspects of a lifecycle of an object embodied in an object story data structure stored in one or more of a set of networked, distributed computing nodes and data structures. While ¶126 and ¶127, and Fig 14 describes operations of an electronic contract between two entities which specifies conditions the electronic contract takes if conditions are/are not met.
Claim 1 is considered an abstract idea because the (underlined) limitations as claimed, pertains to (i) mental processes grouping of abstract ideas (concepts performed in the human mind (including an observation, evaluation, judgment, opinion) or by a human being with a pen and paper; (ii) commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) information regarding subjects of a marketplace; lifecycle of a product (which may refer to a good or service); and operations of an electronic contract in a data structure and (iii) managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) whereby information regarding an object (facility, entity, or location) is identified, accessed and stored; and conditions for access to a recursive data structure are determined based on rules or instructions; hence directed to certain methods of organizing human activity groupings of abstract ideas. With the exception of generic computing components, the limitations are merely using computing component (all used in a manner that is well-understood, routine, and conventional in the field) as a tool for data gathering/analysis, and to perform and automate the abstract idea. A human being with a pen and paper can identify a plurality of conditions, identify an action associated with the conditions, access a recursive object story data structure, access a recursive component story data structure, determine whether the plurality of conditions are met based on the first chain of claim elements, the first chain of evidence elements, the second chain of claim elements, and the second chain of evidence elements, perform an action if the plurality of conditions are met and output an indication of whether the plurality of conditions are not met. Therefore, there is nothing in the claims themselves that foreclose them from being performed by a human being with a pen and paper. Further the limitations are related to organizing human activity in maintaining an aggregated collection of information about various subjects (facilities, companies, and the like) of a marketplace, and/or aspects of a lifecycle of an object stored during the lifetime of the product (which may refer to a good or service) in a data structure based on rules or instructions. The claims are also drawn to operations of an electronic contract, and identifying conditions the electronic contract takes if conditions are/are not satisfied which is similarly directed to the certain methods of organizing human activity grouping of abstract ideas. Hence, the claim recites an abstract idea--see MPEP 2106.04(II).
Step 2A-Prong 2: This judicial exception is not integrated into a practical application because the additional elements “non-transitory, computer-readable storage media”, “one or more processors”, “one or more modules of a system”, “object story data structure”, “component story data structure”, “distributed ledger”, “blockchain”, “cryptographic hash” [claim 1]; and “memory”, “a network interface”, “processing circuitry”, [claim 11]; for (identifying, accessing, determining, performing, transmitting), data gathering and analysis and merely to provide instructions for determining an action based on access of a recursive data structure associated with a plurality of conditions and to implement the abstract idea recited above utilizing “a non-transitory, computer-readable storage media”, “one or more processors”, “one or more modules of a system”, “object story data structure”, “component story data structure”, “distributed ledger”, “blockchain”, “cryptographic hash” [claim 1]; and “memory”, “a network interface”, “processing circuitry”, [claim 11], as a tool to perform the abstract idea, and generally links the abstract idea to a particular technological environment. See MPEP 2106.05 (f-h).
Independent claim 1 fails to operate the “non-transitory, computer-readable storage media”, “one or more processors”, “one or more modules of a system”, “object story data structure”, “component story data structure”, “distributed ledger”, “blockchain”, “cryptographic hash” [claim 1]; and “memory”, “a network interface”, “processing circuitry”, [claim 11]; (which is/are merely a nominal recitation of a standard computer technology, database and hardware/software components) in any exceptional manner, and there is no evidence in the disclosure to suggest achieving an actual improvement in the computer functionality itself, or improvement in any specific computer technology other than utilizing ordinary computational tools to automate and perform the abstract idea for identifying a plurality of conditions, accessing a recursive object story data structure, accessing a recursive component story data structure, determining whether a plurality of conditions are met and outputting an indication of whether the plurality of conditions are met in a computing environment —see MPEP 2106.05(a). Accordingly, applicant has not shown an improvement or practical application under the guidance of MPEP section 2106.04(d) or 2106.05(a). Applicant’s limitations as recited above do nothing more than supplement the abstract idea using generic computer components performing generic computer functions (identifying, accessing, determining, and outputting (data)), such that it amounts to no more than mere instruction to apply the exception using a generic computer component-see MPEP 2106.05(f) and linking the use of the judicial exception to a particular technological environment or field of use as discussed in MPEP 2106.05(h). Independent claims 11 and 18 recite substantially similar limitations as independent claim 1 and therefore also recite the same abstract idea.
Dependent claims 2, 4, 8-10, 12-16, 20, 21 and 23 fail to cure the deficiencies of the above noted independent claim from which they depend and are therefore rejected under the same grounds. The dependent claims further recite the abstract idea without imposing any meaningful limits on practicing the abstract idea. Dependent claims 2 and 4 recite in part, “further cause the one or more modules to:…”; claim 5 recites in part, “wherein the action is a fist action of transferring…; claim 9 recites in part, “wherein to transmit the indication the device is to transmit…”; claim 10 recites in part, “wherein the object is…”, claims 12-14 recite in part, wherein to detect the trigger event the...”; claim 15 recites in part, “wherein one or modules are further…”; claim 16 recites in part, “wherein to incorporate the second claim element…”,claim 20 recites in part, “wherein accessing the recursive object story data structure comprises…”; claim 21 recites in part, “wherein accessing elements incorporated into the object story data comprises…”; claim 23 recites in part, “incorporating into the first chain of claim elements…”, which is still directed toward the abstract idea identified previously and are no more than mere instructions to apply the exception using a computer or with computing components. Therefore, the abstract idea fails to integrate into any practical application. Thus, under Step 2A-Prong Two the claims are directed to an abstract idea.
Step 2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above, with respect to integration of the abstract idea into a practical application, and giving the broadest reasonable interpretation of the claim limitations in light of the specification, applicant’s “non-transitory, computer-readable storage media”, “one or more processors”, “one or more modules of a system”, “object story data structure”, “component story data structure”, “distributed ledger”, “blockchain”, “cryptographic hash” [claim 1]; and “memory”, “a network interface”, “processing circuitry”, [claim 11] amounts to no more than applying the judicial exception using generic computing components, and linking the use of the judicial exception to a computing environment (see ¶58: “object story data structure: a data structure that includes or incorporates elemental aspects of an object story, the data structure or elemental aspects may be distributed across set of networked, distributed nodes”; ¶77: “The computing information system 260 implement, in software and hardware, the roles of the various actors in Figure 1, accessing (for example, reading or writing) the object story or elements thereof as necessary”; ¶90: “One embodiment of a process to secure linked evidence and claim elements is as a set of distributed blockchains or a distributed ledger secured by cryptographic hashes”; ¶151: “Portions of the object story data structure, including portions incorporated through one or more links, may be stored in a common database, a distributed database across multiple sites, or in one or more distributed ledgers”; ¶305: “The device 3800 may include processors 3801,memory/storage circuitry 3802, a user interface 3803, a network interface 3804, and sensors 3805. The components of the device 3800 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof”; ¶307 “The processors 3801 may include processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory/storage 3802 to cause the device 3800 to perform operations as described herein. For example, in some embodiments, the processors 3801 may access object story code 3807 stored in the memory/storage 3802. Upon executing the object story code 3807 the device 3800 may manage (including generating, accessing, storing, etc.) object story data structures 3808”; ¶308: “The memory/storage 3802 may include any type of volatile or non-volatile memory that may be distributed throughout the device 3800. In some embodiments, some of the memory/storage 3802 may be located on the processors 3801 themselves (for example, L1 and L2 cache), while other memory/storage 3802 is external to the processors 3801 but accessible thereto via a memory interface, which may be part of I/O interface 3804”; ¶311: “The network interface 3804 may be any type of wired/wireless network interface capable of facilitating communication with databases and other systems (including other computing information systems, OSM systems, or legacy systems)”; ¶342: “an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process”).
Further, giving the broadest reasonable interpretation of applicant’s (recursive) “object story data structure”, (recursive) “component story data structure”, and additional claim element, “object story manager” [dependent claim 16] in light of the specification, the claimed element(s) is merely used to store, share and/or update data (based on user permissions) (see ¶57: object story: information about lifecycle aspects of an object…can mean that the information refers to any of the objects…refers to information about a product, a facility object story refers to information about a facility and so forth”; ¶58: “object story data structure: a data structure that includes or incorporates elemental aspects of an object story, the data structure or elemental aspects may be distributed across set of networked, distributed nodes”; ¶63: “The object story represents the collection of information (in particular claims and evidence) about aspects of a lifecycle of an object. This information constituting an object story is embodied in an object story data structure that may be stored in one or more of a set of networked, distributed computing nodes and data structures. The object story data structure may be constructed in a distributed fashion and may be sharable between the different actors based on their authorized role in the process… An object story for a facility may contain component object story structures specifying each of the warehouses at that site. Those object stories may contain object stories for the module, pod, or pallet rack containing products and they would contain or link to the product object stories for the products currently stored there.”; ¶65: “story manager: computing element responsible for storing object story data structure”; ¶75: “story manager 201 may be responsible for maintaining the storage of the information about a subject of the object story and ensuring that other entities can view or alter only those portions that their role allows…may store the information in a database that is centralized on a single server, replicated on multiple servers, or distributed across multiple systems sites/entities”; ¶155: “The component object story may include information about a component (for example, an ingredient, a part, or subassembly) of a product or about a sub-part of a larger entity/location/facility (for example a building as a part of a facility, or a department as part of a company)”; ¶305: “The device 3800 may include processors 3801,memory/storage circuitry 3802, a user interface 3803, a network interface 3804, and sensors 3805. The components of the device 3800 may be implemented as integrated circuits (ICs), portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof”; ¶307: “processors 3801 may include processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory/storage 3802 to cause the device 3800 to perform operations as described herein. For example, in some embodiments, the processors 3801 may access object story code 3807 stored in the memory/storage 3802. Upon executing the object story code 3807 the device 3800 may manage (including generating, accessing, storing, etc.) object story data structures 3808 as described herein”); hence, the (recursive) object data structure, (recursive) component data structure and object story manager is/are merely used in a manner that is well-understood, routine and conventional (storing, updating, managing data) in the field and recited at a high level of generality. The additional elements amount to no more than applying the judicial exception using generic computing components, and linking the use of the judicial exception to a computing environment. Therefore, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Accordingly, even when considered as a whole, the claims do not transform the abstract idea into a patent-eligible invention since the claim limitations do not amount to a practical application or significantly more than an abstract idea fo identifying a plurality of conditions, accessing a recursive object story data structure, accessing a recursive component story data structure, determining whether a plurality of conditions are met and outputting an indication of whether the plurality of conditions are met in a computing environment.
Hence, claims 1, 2, 4, 8-16, 18, 20, 21 and 23 are directed to non-statutory subject matter and are rejected as ineligible subject matter under 35 USC 101. See 2019 PEG and MPEP 2106.
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, 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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 2, 4, 8-16, 18, 20, 21 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Batra et al., US Patent Application Publication No US 2018/0137465 A1 in view of Wentz US Patent Application Publication No US2020/0162268 A1.
With respect to claim 1,
Batra discloses,
One or more non-transitory, computer-readable storage media having instructions that, when executed by one or more processors, cause one or more modules of a system to: identify a plurality of conditions (Fig 6B, ¶6: “a non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform at least one of identifying a metric configuration associated with a smart contract stored in a blockchain”; Fig 5, ¶20: “an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶30: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur”; ¶33: a system signaling diagram 500 of a blockchain smart contract management configuration …contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance”; ¶34: “one or more of identifying a configuration of metric associated with a blockchain 612, determining whether the metric configuration supports requirements of a contract 614, and logging the contract on the blockchain when the requirements of the contract are supported by the metric configuration 616. Additionally, the method may include identifying the requirements of the contract after the contract is logged in the blockchain”; ¶35: “one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 652, logging an event which is part of the metric configuration 654, determining whether the event supports requirements of the smart contract 656 and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event 658”; ¶41: “the capabilities of the system of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture”) Examiner interprets the smart contract requirements/terms of Batra as teaching applicant’s conditions.
determine whether the plurality of conditions are met based on the first chain of claim elements, the first chain of evidence elements, the second chain of claim elements, and the second chain of evidence elements; (¶20: “a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶22: “the smart contract stored in the blockchain can include a physical infrastructure that supports the contract terms, especially when a purchase for a product is involved in the process. For instance, shipping links 210 may include entities on the shipping party end, such as an exporter 212, a trucker 214, a port authority 216 and an exporter's bank 218, for exiting a country ‘A’. The receiving side may be located in another country ‘B’ and have a custom's authority 222 and importer business 224. Any of the entities may be part of a blockchain. Certain ‘states’ may be used to describe where a shipment is presently located and in whose possession the shipment is currently held. Events may include a particular shipment changing custody or being moved to a new location. This may be identified via the parties and/or sensors configured to provide information to the parties and logged in the blockchain. a sensor tracking a shipment location or an action taken by a party accompanying or receiving shipment. In such an event, the contract specification should be parsed to ensure that events leading to the actions in the given states meet desired assurance levels. An extract operation may identify an <event, state> list from a smart contract stored in the blockchain. The event generators may be determined along with the parties and the sensors that report changes and make attestations. Next, specified generators may be matched with assurance policies, event generators may be flagged that do not satisfy policy requirements, ¶34-¶36; ¶34: the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and triggering an alarm when the metric configuration does not support the requirements of the contract. Also, the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”)
wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence (¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed”; Fig 6A, ¶34: “the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements”)
Applicant’s specification as filed does not properly convey how “a threshold level of evidence” is determined. The disclosure at ¶85, ¶88, ¶120 and ¶121 appears to be a general guideline about various levels of evidence and/or importance. Hence, Examiner interprets the limitation as, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at a level of evidence”. Giving the broadest reasonable interpretation of the claim limitation in light of the specification, Examiner interprets the smart contracts include agreements about a process or workflow, terms, obligations, to be met by certain parties; as well as recording signatures and other non-revocable data on a shared ledger (i.e. a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment) The proof agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed as taught by Batra as teaching applicant’s limitation, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”
output an indication of whether the plurality of conditions are met (¶19: “a contract can be scanned and terms can be identified/parsed and backend system entities, such as supply chain entities, finance entities, etc., can be identified and examined before deployment on a blockchain to detect whether associated technology is sufficient to support/enforce the contractual terms. At each stage of contract execution, monitoring operations may include evaluating associated third-party system technology for availability and operational validity. In the event that a mismatch between contract terms and another entity or process is discovered or identified, for example, between a contract term and a third party, an alert, alarm, notification, etc., can be created and used to identify interested parties, such as a seller, purchaser, and financer, that the standards have not been met and that the contract requires attention”; ¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed”; ¶22: “FIG. 2 illustrates an example 200 of a smart contract operating in a blockchain according to example embodiments. Referring to FIG. 2, the smart contract stored in the blockchain can include a physical infrastructure that supports the contract terms, especially when a purchase for a product is involved in the process.. Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment… contract specification should be parsed to ensure that events leading to the actions in the given states meet desired assurance levels. An extract operation may identify an <event, state> list from a smart contract stored in the blockchain. The event generators may be determined along with the parties and the sensors that report changes and make attestations”; ¶33: “An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance”; Fig 6A, ¶34: the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements.”; ¶35: “certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
Batra discloses all of the above limitations, Batra does not distinctly disclose the following limitations, but Wentz however as shown discloses,
access a recursive object story data structure that includes a first chain of claim elements, a first chain of evidence elements and a recursive component story data structure, wherein a first claim element of the first chain of claim elements includes: a cryptographic hash of one or more previous claim elements in the chain of claim elements; a link to a subsequent claim element in the chain of claim elements (Fig 1, Fig 2, ¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks… various ways in which steps, sequences of steps, processing tasks, and/or data may be subdivided, shared, or otherwise dealt with using iteration, recursion, and/or parallel processing”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain” ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Fig 3, ¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”)
a statement about an object that is a facility, an entity or a location; and an indication of a first evidence element of the first chain of evidence elements, wherein the first evidence element is cryptographically linked with the first claim element, supports the statement about the object with a first level of evidence selected from a plurality of levels of evidence and includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements (¶2-5; ¶2: “the present invention is directed to recording a digitally signed assertion using an authorization token”; ¶4: “assigning, by the evaluating device, a confidence level to the first digitally signed assertion. The method includes authenticating, by the evaluating device, the first digitally signed assertion as a function of the confidence level”; ¶15-¶20; ¶15: “authentication of digitally signed assertions and files containing digitally signed assertions, including cryptographic immutable ledgers, such as block chains or the like”; ¶16: “authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain”; ¶17: “Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score; numerical score may be a score on a scale having one extremum representing a maximal degree of reliability, and a second extremum representing a minimum degree of reliability”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… , at least a digitally signed assertion 200 may describe a transfer of virtual currency, such as crypto currency as described below. The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity. Item of value may be an interest in a fungible negotiable financial instrument representing ownership in a public or private corporation, a creditor relationship with a governmental body or a corporation, rights to ownership represented by an option, derivative financial instrument, commodity, debt-backed security such as a bond or debenture or other security as described in further detail below. At least a digitally signed assertion 200 may describe the transfer of a physical good; for instance, at least a digitally signed assertion 200 may describe the sale of a product”; ¶64: “ In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “; ¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408… Evaluating device 404 may alternatively or additionally receive at least a communication by retrieving it from memory where it has been stored either entirely or in a representation such as a cryptographic hash as described above. Retrieval may include retrieval from any suitable data structure; for instance, and without limitation, retrieval may include receiving a transaction recorded in a temporally sequential listing”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
wherein individual evidence elements of the first chain of evidence elements support the statement about the object with individual levels of evidence and each of the first chain of claim elements and the first chain of evidence elements are implemented in a distributed ledger or blockchain;( ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… , at least a digitally signed assertion 200 may describe a transfer of virtual currency, such as crypto currency as described below. The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity”; ¶64: “ In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408… Evaluating device 404 may alternatively or additionally receive at least a communication by retrieving it from memory where it has been stored either entirely or in a representation such as a cryptographic hash as described above. Retrieval may include retrieval from any suitable data structure; for instance, and without limitation, retrieval may include receiving a transaction recorded in a temporally sequential listing”)
access the recursive component story data structure that includes a second chain of claim elements, a second chain of evidence elements, wherein a claim element of the second chain of claim elements includes: a statement about a component of the object, and an indication of an evidence element of the second chain of evidence elements that supports the statement about the component (Abstract: “the first digitally signed assertion as a function of the confidence level, generating, by the evaluating device, a second digitally signed assertion as a function of the first digitally signed assertion, and entering, by the evaluating device, the second digitally signed assertion in at least an instance of a first temporally sequential listing”; ¶2-5; ¶2: “the present invention is directed to recording a digitally signed assertion using an authorization token”; ¶4: “at least a communication including a first digitally signed assertion recorded in a Second temporally sequential listing… assigning, by the evaluating device, a confidence level to the first digitally signed assertion. The method includes authenticating, by the evaluating device, the first digitally signed assertion as a function of the confidence level”; ¶15-¶20; ¶15: “authentication of digitally signed assertions and files containing digitally signed assertions, including cryptographic immutable ledgers, such as block chains or the like”; ¶16: “authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain”; ¶17: “Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score; numerical score may be a score on a scale having one extremum representing a maximal degree of reliability, and a second extremum representing a minimum degree of reliability”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain” ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like. In an embodiment, where a digitally signed assertion is used to perform a transaction, authorization token 124 may confer the right to perform that transaction on evaluating device 104. Where a transaction has a given transaction amount and/or type, authorization token 124 may confer the right to engage in a transaction having that transaction amount and/or type”; ¶74: “an authorization datum may include a digital certificate as described above; digital certificate may, for instance and without limitation, associate an identity of a user or entity operating evaluating device 104 with an identifier of remote device, confer upon remote device access rights to one or more resources incorporated in or connected to system 100, associate evaluating device 104 with a given confidence level, grant a transfer of assets, data, and/or access rights from one device to another, or the like. An authorization datum may confer a right to access one or more resources incorporated in or connected to system 100. An authorization datum may associate an identity of a user or entity operating evaluating device 104 with an identifier of remote device”; ¶84: “Still viewing FIG. 1, each device in system 100 determining whether evaluating device 104 is authorized to perform an action may use a threshold cryptography protocol, as described above. In other words, a plurality of devices enacting methods as described above may be treated as a group of certificate authorities acting to authenticate in coordination, with the requirement that a threshold number of the group of certificate authorities, and/or a threshold proportion of the group of certificate authorities, agree (e.g., “threshold cryptography”) for authorization to be valid; threshold may include a number of verifying nodes. Threshold may include an aggregate confidence level threshold”; ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
with a second level of evidence selected from the plurality levels of evidence, wherein individual evidence elements of the second chain of evidence elements support the statement about the component with individual levels of evidence, (¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain”; ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like”; ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
Applicant’s disclosure discusses examples and variable levels of evidence- see ¶85: “Each claim may also contain evidence elements that are a form of proof that the claim can be trusted"; ¶88 “Assertion, Self-Certification, Basic Audit, Third Party certification, Third Party certification with audit, and at ¶89: “additional/alternative levels of evidence may be used that are useful for a specific field”, and ¶91: “One embodiment of a process to secure linked evidence and claim elements is as a set of distributed blockchains or a distributed ledger secured by cryptographic hashes”. Wentz discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz further discloses that a first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing… including without limitation blockchains and the like. Giving the broadest reasonable interpretation of applicant’s claim limitation, in light of the specification, Examiner interprets at least the authenticated digitally signed assertions and files, cryptographic immutable ledgers/blockchains sequentially linked, and/or a digital signed assertions including an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token and order preserving protocol (i.e. Merkle trees or other has trees) as taught by Wentz as teaching applicant’s limitation, “an indication of a first evidence element, cryptographically linked with the first claim element (digitally signed assertions and files…including cryptographic immutable ledgers/block chains), to support veracity of the assertion with a first level of evidence selected from a plurality of levels of evidence (including an attestation conferring proof of endorsement by a third party.. providing confidence level, level of access, authorization token), and includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements (order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries).
Batra teaches a block chain configuration for storing smart contracts including but not limited to identifying smart contract information from a blockchain and more particularly to anticipating and monitoring transactions in the blockchain to determine whether the smart contract requirements can be enforced. Wentz discloses a method/system for at least receiving a communication from any suitable data structure, including a first digitally signed assertion which may be recorded in a second temporally sequential listing, via a blockchain or distributed ledger. Wentz further discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz also teaches that a sequence of digitally signed assertions may be created and may refer to previously entered data that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions and that authenticating may include verifying earlier hashes in a hash chain, block chain and/or verifying back to a genesis block. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries. Barta and Wentz are directed to the same endeavor since they are related to recording/storing and authenticating data/information in a distributed ledger/blockchain computing environment. Further it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to use the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz for authenticating and importing digitally signed assertions and files from a first distributed network, or first block chain to a second block chain or second distributed network cryptographic immutable ledgers, such as another block chain or immutable ledger using a side chain, hash tree or the like. The known techniques/tools for receiving, authenticating, generating and importing digitally signed assertions of Wentz would have predictably resulted in an improved architecture and process for maintaining and controlling access to a cryptographically secured ledger where each link in the chain contains encrypted or hashed information and a timestamp of the entry (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶64, ¶65, ¶101-111). Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz since it allows for providing digitally signed assertions and files including an attestation conferring proof of endorsement, modifying and/or verifying back to a genesis block, maintaining and controlling access to a cryptographically secured ledger, block chain, side chain, hash tree or the like, (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶61,¶64, ¶65, ¶88, ¶98-111).
With respect to claim 2,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
the instructions, when executed, further cause the one or more modules to: incorporate a second claim element of the first chain of claim elements and a second evidence element of the first chain of evidence elements into the recursive object story data structure, (Fig 2, ¶22: “a smart contract operating in a blockchain… shipping links 210 may include entities on the shipping party end, such as an exporter 212, a trucker 214, a port authority 216 and an exporter's bank 218, for exiting a country ‘A’. The receiving side may be located in another country ‘B’ and have a custom's authority 222 and importer business 224. Any of the entities may be part of a blockchain. Certain ‘states’ may be used to describe where a shipment is presently located and in whose possession the shipment is currently held. Events may include a particular shipment changing custody or being moved to a new location. This may be identified via the parties and/or sensors configured to provide information to the parties and logged in the blockchain”)
the second claim element to include a statement related to an outcome of the determination of whether the plurality of conditions are met and the second evidence element to support the statement of the second claim element (¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. …The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶22: “Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment. One example of a failure or dispute may include attestation of a shipment's location by a possessor being audited as inaccurate… The event generators may be determined along with the parties and the sensors that report changes and make attestations. Next, specified generators may be matched with assurance policies, event generators may be flagged that do not satisfy policy requirements. Also, a contract amendment may be performed to promote policy resolution and to recommend suggestions for meeting required assurance levels”; ¶24: “a GPS sensor accompanying the shipment may emit events containing information about the shipment's current location and/or condition. The smart contract on the blockchain may update the shared ledger state when it receives these events”; ¶32: “a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensors, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time”; Fig 5, ¶33: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc”)
With respect to claim 4,
Barta and Wentz disclose all of the above limitations, Batra further discloses,
wherein the instructions, when executed, further cause the one or more modules to: detect creation of the claim element of the first chain of claim elements with the statement about the object; and determine whether the plurality of conditions are met based on detection of the creation of the claim element of the first chain of claim elements with the statement about the object. (¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. …The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶22: “Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment. One example of a failure or dispute may include attestation of a shipment's location by a possessor being audited as inaccurate… The event generators may be determined along with the parties and the sensors that report changes and make attestations. Next, specified generators may be matched with assurance policies, event generators may be flagged that do not satisfy policy requirements. Also, a contract amendment may be performed to promote policy resolution and to recommend suggestions for meeting required assurance levels”; ¶24: “a GPS sensor accompanying the shipment may emit events containing information about the shipment's current location and/or condition. The smart contract on the blockchain may update the shared ledger state when it receives these events”; ¶28: “Shipment progress through multiple stages and authorities (i.e., truckers, ports, and customs) can be tracked and smart contract terms can be compared. In this scenario, a smart contract would be created and encoded to include an importer which may apply for and obtain a letter of credit from a bank and present it as a promise of future payment to an exporter… The carrier, and the various stages through which the shipment passes, attest to the shipment having passed through certain stages, such as reaching a port, clearing customs, etc. When the goods reach their destination and the importer's bank receives the documentation from the exporter, a money transfer may then be accepted to pass to that exporter”; Fig 2, Fig 3, ¶29: “The smart contract code may have a workflow encoded into its structure similar to that depicted FIG. 3. The code is compiled and deployed onto the blockchain nodes, which are distributed and are under the control of the various parties described in FIG. 2… The code is event-driven, in that when a party performs a certain action (e.g., an exporter dispatching goods), the blockchain nodes execute the code, for example, in parallel and update a shared ledger state through consensus procedures in the blockchain. The contract has a number of designated end states, one of which is a successful shipment followed by payment, and others where different parties fail to execute their part faithfully (e.g., shipper fails to transport goods for some reason)”; ¶32: “a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensors, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time”; ¶33-¶36; Fig 5, ¶33: “The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance. Any subsequent actions or contract terms 534, which, for example, can be identified as being a potential hazard, are noted and included in an additional monitoring operation. An event may be logged 535 from a supply chain member, such as a carrier, custodian, etc. The event may be a change in plans or other event”; Fig 6A, ¶34: “the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain. The events may include one or more of a date, a time, a location, a shipping requirement, other shipping information, and a financial transaction.¶35: “Referring to FIG. 6B, the example method 650 includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 652, logging an event which is part of the metric configuration 654, determining whether the event supports requirements of the smart contract 656 and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event 658. In this example, certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
With respect to claim 8,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein the instructions, when executed, further cause the one or more modules to: transmit, to an entity associated with the plurality of conditions, the indication of whether the plurality of conditions are met (¶30: “an event may cause a log to be written which stores information regarding the parties and the current state along with the recent event. An action may include an importer's bank approving a letter of credit application, an exporter dispatching a shipment and obtaining documents, and/or an importer's bank paying an exporter. Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc”; ¶Fig 5, ¶33: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc”; ¶35: “Referring to FIG. 6B, the example method 650 includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 652, logging an event which is part of the metric configuration 654, determining whether the event supports requirements of the smart contract 656 and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event 658. In this example, certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
With respect to claim 9,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein to transmit the indication the device is to transmit an e-mail, a text message, or a business automation message (¶32: “an alert can be sent in the form of notifications (e-mail, SMS, etc.) to administrators (users) specified in the contract”)
With respect to claim 10,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein: the object is an entity and the component is a department, team, or individual of the entity; or the object is a facility and the component is a sub-facility (¶32: “Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy. For example, a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running… a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensors, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time… Depending on a desired assurance level, faulty sensor B may or may not be flagged for remediation action, as two attesters are operational at such a time. The failures can be flagged which trigger a remediation action. As a result, an alert can be sent in the form of notifications (e-mail, SMS, etc.) to administrators (users) specified in the contract”; ¶33: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc.”)
With respect to claim 11,
Batra discloses,
memory to store a plurality of conditions, an indication of an action that is associated with the plurality of conditions, and one or more entities associated with the plurality of conditions; and a network interface; and processing circuitry, coupled with the memory and the network interface, the processing circuitry to implement one or more modules to: (Fig 5, Fig 7, ¶33: FIG. 5 illustrates a system signaling diagram 500 of a blockchain smart contract management configuration according to example embodiments. Referring to FIG. 5, the example includes a contract auditor entity 510, such as a monitoring entity or other entity designated or permitted to monitor contract events and actions in the blockchain. In operation, a contract is stored in the blockchain 512 on a blockchain designated server 520. An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance. “; ¶34: “method 600 may include one or more of identifying a configuration of metric associated with a blockchain 612, determining whether the metric configuration supports requirements of a contract 614, and logging the contract on the blockchain when the requirements of the contract are supported by the metric configuration 616… the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”; Fig 7, ¶40: “a memory 710 and a processor 720 may be discrete components of a network entity 700 that are used to execute an application or set of operations as described herein. The application may be coded in software in a computer language understood by the processor 720, and stored in a computer readable medium, such as, a memory 710”; ¶41: “the capabilities of the system of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture”)
detect a trigger event; access, based on the trigger event, (Fig 6B, ¶35: “certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
wherein: the object is an entity and the component is a department, team, or individual of the entity; the object is a facility and the component is a sub-facility; or the object is a first location and the component is a second location within the first location (¶32: “Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy. For example, a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running… a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensors, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time… Depending on a desired assurance level, faulty sensor B may or may not be flagged for remediation action, as two attesters are operational at such a time. The failures can be flagged which trigger a remediation action. As a result, an alert can be sent in the form of notifications (e-mail, SMS, etc.) to administrators (users) specified in the contract”; ¶33: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc.”)
determine, based on access of the recursive object story data structure, and the recursive component story data structure, whether the plurality of conditions are met (¶19: “a contract can be scanned and terms can be identified/parsed and backend system entities, such as supply chain entities, finance entities, etc., can be identified and examined before deployment on a blockchain to detect whether associated technology is sufficient to support/enforce the contractual terms. At each stage of contract execution, monitoring operations may include evaluating associated third-party system technology for availability and operational validity. ¶20: “an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes.”; Fig 2, ¶22: “Events may include a particular shipment changing custody or being moved to a new location. This may be identified via the parties and/or sensors configured to provide information to the parties and logged in the blockchain. Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment”; ¶33-¶36; ¶33: “An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance”; ¶34: “method 600 may include one or more of identifying a configuration of metric associated with a blockchain 612, determining whether the metric configuration supports requirements of a contract 614, and logging the contract on the blockchain when the requirements of the contract are supported by the metric configuration 616… the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”; ¶36: “logging an event which is part of the metric configuration 664, determining a risk associated with the event 668, determining whether the risk exceeds a predetermined threshold level 672, and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event and the risk does not exceed the predetermined threshold level 674. If the risk level calculated does exceed the threshold level, then the transaction may not be logged in the blockchain and instead an alert may be created and used to alert an interested party regarding the failure and why the contract is not maintained in this event”)
wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence (¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed”; Fig 2, ¶22: “a smart contract operating in a blockchain according to example embodiments. Referring to FIG. 2, the smart contract stored in the blockchain can include a physical infrastructure that supports the contract terms, especially when a purchase for a product is involved in the process… Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment… the contract specification should be parsed to ensure that events leading to the actions in the given states meet desired assurance levels. An extract operation may identify an <event, state> list from a smart contract stored in the blockchain. The event generators may be determined along with the parties and the sensors that report changes and make attestations. Next, specified generators may be matched with assurance policies”;.Fig 6A, ¶34: “the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements”)
Applicant’s specification as filed does not properly convey how “a threshold level of evidence” is determined. The disclosure at ¶85, ¶88, ¶120 and ¶121 appears to be a general guideline about various levels of evidence and/or importance. Hence, Examiner interprets the limitation as, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at a level of evidence”. Giving the broadest reasonable interpretation of the claim limitation in light of the specification, Examiner interprets the smart contracts include agreements about a process or workflow, terms, obligations, to be met by certain parties; as well as recording signatures and other non-revocable data on a shared ledger (i.e. a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment) The proof agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed as taught by Batra as teaching applicant’s limitation, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”
output an indication of whether the plurality of conditions are met (¶19: “a contract can be scanned and terms can be identified/parsed and backend system entities, such as supply chain entities, finance entities, etc., can be identified and examined before deployment on a blockchain to detect whether associated technology is sufficient to support/enforce the contractual terms. At each stage of contract execution, monitoring operations may include evaluating associated third-party system technology for availability and operational validity. In the event that a mismatch between contract terms and another entity or process is discovered or identified, for example, between a contract term and a third party, an alert, alarm, notification, etc., can be created and used to identify interested parties, such as a seller, purchaser, and financer, that the standards have not been met and that the contract requires attention”; ¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed”; ¶22: “ Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment”; ¶26: “Upon discovery of a contract violation (e.g., the desired assurance levels for location tracking sensors is not being met), parties may choose to deploy new sensors and/or add human verifiers”; ¶33: “An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance”; ¶30: “In the event of a failure, notifications may be sent out to one or more parties”; Fig 6A, ¶34: the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and triggering an alarm when the metric configuration does not support the requirements of the contract. Also, the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”; ¶35: “certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
Batra discloses all of the above limitations, Batra does not distinctly disclose the following limitations, but Wentz however as shown discloses,
access, based on the trigger event, a recursive object story data structure that includes a first chain of claim elements, a first chain of evidence elements, and a recursive component story data structure, wherein a first claim element of the first chain of claim elements includes: a cryptographic hash of one or more previous claim elements in the chain of claim elements; a link to a subsequent claim element in the chain of claim elements (Fig 1, Fig 2, ¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks …various ways in which steps, sequences of steps, processing tasks, and/or data may be subdivided, shared, or otherwise dealt with using iteration, recursion, and/or parallel processing”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain” ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like”; Fig 3, ¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”)
a statement about an object that is a facility, an entity or a location, and an indication of a first evidence element of the first chain of evidence elements, wherein the first evidence element is cryptographically linked with the first claim element, supports veracity of the assertion about the object with a first level of evidence selected from a plurality of levels of evidence; includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements (¶2-5; ¶2: “the present invention is directed to recording a digitally signed assertion using an authorization token”; ¶4: “assigning, by the evaluating device, a confidence level to the first digitally signed assertion. The method includes authenticating, by the evaluating device, the first digitally signed assertion as a function of the confidence level”; ¶15-¶20; ¶15: “authentication of digitally signed assertions and files containing digitally signed assertions, including cryptographic immutable ledgers, such as block chains or the like”; ¶16: “authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain”; ¶17: “Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score; numerical score may be a score on a scale having one extremum representing a maximal degree of reliability, and a second extremum representing a minimum degree of reliability”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… , at least a digitally signed assertion 200 may describe a transfer of virtual currency, such as crypto currency as described below. The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity. Item of value may be an interest in a fungible negotiable financial instrument representing ownership in a public or private corporation, a creditor relationship with a governmental body or a corporation, rights to ownership represented by an option, derivative financial instrument, commodity, debt-backed security such as a bond or debenture or other security as described in further detail below. At least a digitally signed assertion 200 may describe the transfer of a physical good; for instance, at least a digitally signed assertion 200 may describe the sale of a product”; ¶64: “ In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation“;¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408… Evaluating device 404 may alternatively or additionally receive at least a communication by retrieving it from memory where it has been stored either entirely or in a representation such as a cryptographic hash as described above. Retrieval may include retrieval from any suitable data structure; for instance, and without limitation, retrieval may include receiving a transaction recorded in a temporally sequential listing”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
wherein individual evidence elements of the first chain of evidence elements support the statement about the object with individual levels of evidence and each of the first chain of claim elements and the first chain of evidence elements are implemented in a distributed ledger or blockchain (¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… , at least a digitally signed assertion 200 may describe a transfer of virtual currency, such as crypto currency as described below. The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity”; ¶64: “ In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408… Evaluating device 404 may alternatively or additionally receive at least a communication by retrieving it from memory where it has been stored either entirely or in a representation such as a cryptographic hash as described above. Retrieval may include retrieval from any suitable data structure; for instance, and without limitation, retrieval may include receiving a transaction recorded in a temporally sequential listing”)
access the recursive object story data structure that includes a second chain of claim elements, and a second chain of evidence elements wherein a first claim element of the second chain of claim elements includes: a statement about a component of the object, and an indication of a first evidence element of the second chain of evidence elements that supports the statement about the component (Abstract: “the first digitally signed assertion as a function of the confidence level, generating, by the evaluating device, a second digitally signed assertion as a function of the first digitally signed assertion, and entering, by the evaluating device, the second digitally signed assertion in at least an instance of a first temporally sequential listing”; ¶2-5; ¶2: “the present invention is directed to recording a digitally signed assertion using an authorization token”; ¶4: “at least a communication including a first digitally signed assertion recorded in a Second temporally sequential listing… assigning, by the evaluating device, a confidence level to the first digitally signed assertion. The method includes authenticating, by the evaluating device, the first digitally signed assertion as a function of the confidence level”; ¶15-¶20; ¶15: “authentication of digitally signed assertions and files containing digitally signed assertions, including cryptographic immutable ledgers, such as block chains or the like”; ¶16: “authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain”; ¶17: “Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score; numerical score may be a score on a scale having one extremum representing a maximal degree of reliability, and a second extremum representing a minimum degree of reliability”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain” ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like. In an embodiment, where a digitally signed assertion is used to perform a transaction, authorization token 124 may confer the right to perform that transaction on evaluating device 104. Where a transaction has a given transaction amount and/or type, authorization token 124 may confer the right to engage in a transaction having that transaction amount and/or type”; ¶74: “an authorization datum may include a digital certificate as described above; digital certificate may, for instance and without limitation, associate an identity of a user or entity operating evaluating device 104 with an identifier of remote device, confer upon remote device access rights to one or more resources incorporated in or connected to system 100, associate evaluating device 104 with a given confidence level, grant a transfer of assets, data, and/or access rights from one device to another, or the like. An authorization datum may confer a right to access one or more resources incorporated in or connected to system 100. An authorization datum may associate an identity of a user or entity operating evaluating device 104 with an identifier of remote device”; ¶84: “Still viewing FIG. 1, each device in system 100 determining whether evaluating device 104 is authorized to perform an action may use a threshold cryptography protocol, as described above. In other words, a plurality of devices enacting methods as described above may be treated as a group of certificate authorities acting to authenticate in coordination, with the requirement that a threshold number of the group of certificate authorities, and/or a threshold proportion of the group of certificate authorities, agree (e.g., “threshold cryptography”) for authorization to be valid; threshold may include a number of verifying nodes. Threshold may include an aggregate confidence level threshold”; ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
with a second level of evidence selected from the plurality levels of evidence, wherein individual evidence elements of the second chain of evidence elements support the statement about the component with individual levels of evidence (¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain”; ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like”; ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
Applicant’s disclosure discusses examples and variable levels of evidence- see ¶85: “Each claim may also contain evidence elements that are a form of proof that the claim can be trusted"; ¶88 “Assertion, Self-Certification, Basic Audit, Third Party certification, Third Party certification with audit, and at ¶89: “additional/alternative levels of evidence may be used that are useful for a specific field”, and ¶91: “One embodiment of a process to secure linked evidence and claim elements is as a set of distributed blockchains or a distributed ledger secured by cryptographic hashes”. Wentz discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz further discloses that a first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing… including without limitation blockchains and the like. Giving the broadest reasonable interpretation of applicant’s claim limitation, in light of the specification, Examiner interprets at least the authenticated digitally signed assertions and files, cryptographic immutable ledgers/blockchains sequentially linked, and/or a digital signed assertions including an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token and order preserving protocol (i.e. Merkle trees or other has trees) as taught by Wentz as teaching applicant’s limitation, “an indication of a first evidence element, cryptographically linked with the first claim element (digitally signed assertions and files…including cryptographic immutable ledgers/block chains), to support veracity of the assertion with a first level of evidence selected from a plurality of levels of evidence (including an attestation conferring proof of endorsement by a third party.. providing confidence level, level of access, authorization token), and includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements (order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries).
Batra teaches a block chain configuration for storing smart contracts including but not limited to identifying smart contract information from a blockchain and more particularly to anticipating and monitoring transactions in the blockchain to determine whether the smart contract requirements can be enforced. Wentz discloses a method/system for at least receiving a communication from any suitable data structure, including a first digitally signed assertion which may be recorded in a second temporally sequential listing, via a blockchain or distributed ledger. Wentz further discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz also teaches that a sequence of digitally signed assertions may be created and may refer to previously entered data that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions and that authenticating may include verifying earlier hashes in a hash chain, block chain and/or verifying back to a genesis block. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries. Barta and Wentz are directed to the same endeavor since they are related to recording/storing and authenticating data/information in a distributed ledger/blockchain computing environment. Further it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to use the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz for authenticating and importing digitally signed assertions and files from a first distributed network, or first block chain to a second block chain or second distributed network cryptographic immutable ledgers, such as another block chain or immutable ledger using a side chain, hash tree or the like. The known techniques/tools for receiving, authenticating, generating and importing digitally signed assertions of Wentz would have predictably resulted in an improved architecture and process for maintaining and controlling access to a cryptographically secured ledger where each link in the chain contains encrypted or hashed information and a timestamp of the entry (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶64, ¶65, ¶101-111). Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz since it allows for providing digitally signed assertions and files including an attestation conferring proof of endorsement, modifying and/or verifying back to a genesis block, maintaining and controlling access to a cryptographically secured ledger, block chain, side chain, hash tree or the like, (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶61,¶64, ¶65, ¶88, ¶98-111).
With respect to claim 12,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein to detect the trigger event the processing circuitry is to: monitor the recursive object story data structure and the recursive component story data structure to detect a change; and detect the trigger event based on detection of the change (Fig 5, ¶33: “. An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance… An event may be logged 535 from a supply chain member, such as a carrier, custodian, etc. The event may be a change in plans or other event. The event may cause a failure or alert to be created 536. The alert may be transmitted 538 to the blockchain server 520 and the contract member who is registered to receive such alerts may receive a notification of the contract violation 539. Any changes or events are logged in the blockchain 542.”; Fig 6A, ¶34: “responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”; ¶35: “FIG. 6B, the example method 650 includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 652, logging an event which is part of the metric configuration 654, determining whether the event supports requirements of the smart contract 656 and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event 658. In this example, certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”; Fig 6C, ¶36: “a method 660 that includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 662, logging an event which is part of the metric configuration 664, determining a risk associated with the event 668, determining whether the risk exceeds a predetermined threshold level 672… If the risk level calculated does exceed the threshold level, then the transaction may not be logged in the blockchain and instead an alert may be created and used to alert an interested party regarding the failure and why the contract is not maintained in this event”)
Wentz further discloses,
a recursive object story data and a recursive component data structure (¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “;¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”)
Batra and Wentz are directed to the same inventive concept since they are related to recording, storing and authenticating data/information in a computing environment. Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured of Wentz since it allows for providing digitally signed assertions and files including an attestation conferring proof of endorsement, modifying, repeating, maintaining and controlling access to a cryptographically secured ledger (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶64, ¶65, ¶99, 101-111).
With respect to claim 13,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein to detect the trigger event the one or more modules are to: receive a request from a user or an automated process; and detect the trigger event based on receipt of the request (¶25: “ Sensors, such as GPS sensors can be periodically probed to ensure that they are not malfunctioning…”;Fig 4, ¶27: “The policy specification may include trust information which contains maps of sensors as they relate to the product shipment and parties having certain trust levels”; ¶32: “Contract monitoring may be performed via XML, logic programs, etc. Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy. For example, a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running. Also, a periodic check may be performed to determine whether assurance levels are meeting desired thresholds of accuracy… The failures can be flagged which trigger a remediation action. As a result, an alert can be sent in the form of notifications (e-mail, SMS, etc.) to administrators (users) specified in the contract. The events/attestations can be disabled until a designated administrator fixes the problem and triggers resumption of the workflow”; ¶35: “FIG. 6B, the example method 650 includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 652, logging an event which is part of the metric configuration 654, determining whether the event supports requirements of the smart contract 656 and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event 658. In this example, certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”; ¶41: “the capabilities of the system of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture”)
With respect to claim 14,
Batra and Wentz discloses all of the above limitations, Batra further discloses,
wherein to detect the trigger the one or more modules are to: (Fig 4, ¶27: “a contract admission audit procedure according to example embodiments. Referring to FIG. 4, a policy management example 400 may include an admission check 410 being performed to include an examination 412 and recommendations 414 based on the types and number of policies in a policy database 416. As policies are matched 422 and resolved 424, the contract may be continually executed until resolution. Policies can be stored on the blockchain and/or in a separated database. Policies and a policy manager can be part of the contract specification”; ¶32: “Contract monitoring may be performed via XML, logic programs, etc. Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy… The failures can be flagged which trigger a remediation action. As a result, an alert can be sent in the form of notifications (e-mail, SMS, etc.) to administrators (users) specified in the contract”; Fig 5, ¶33: “a system signaling diagram 500 of a blockchain smart contract management configuration according to example embodiments. Referring to FIG. 5, the example includes a contract auditor entity 510, such as a monitoring entity or other entity designated or permitted to monitor contract events and actions in the blockchain. In operation, a contract is stored in the blockchain 512 on a blockchain designated server 520”; ¶41: “)
authenticate the request based on the access rights; (¶33: “FIG. 5 illustrates a system signaling diagram 500 of a blockchain smart contract management configuration according to example embodiments. Referring to FIG. 5, the example includes a contract auditor entity 510, such as a monitoring entity or other entity designated or permitted to monitor contract events and actions in the blockchain. In operation, a contract is stored in the blockchain 512 on a blockchain designated server 520. An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance… The event may cause a failure or alert to be created 536. The alert may be transmitted 538 to the blockchain server 520 and the contract member who is registered to receive such alerts may receive a notification of the contract violation 539. Any changes or events are logged in the blockchain 542. Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur”)
perform, based on authentication of the request, an access operation based on the request to access; and detect the trigger based on performance of the access operation (Fig 5, ¶33-¶35; ¶33: “a system signaling diagram 500 of a blockchain smart contract management configuration according to example embodiments. Referring to FIG. 5, the example includes a contract auditor entity 510, such as a monitoring entity or other entity designated or permitted to monitor contract events and actions in the blockchain. In operation, a contract is stored in the blockchain 512 on a blockchain designated server 520. An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance… The event may cause a failure or alert to be created 536. The alert may be transmitted 538 to the blockchain server 520 and the contract member who is registered to receive such alerts may receive a notification of the contract violation 539. Any changes or events are logged in the blockchain 542. Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur”; Fig 6B, ¶35: “certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
Wentz further discloses,
receive, in a message, a request to access the recursive object story data structure or the recursive component story data structure and a security token associated with access rights (Figs 1-4, ¶16: “processes for authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain… sharing and importing of information between distributed networks”; ¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks… various ways in which steps, sequences of steps, processing tasks, and/or data may be subdivided, shared, or otherwise dealt with using iteration, recursion, and/or parallel processing”; ¶64: “the ledger is a secured ledger; in one embodiment, a secured ledger is a ledger having safeguards against alteration by unauthorized parties. The ledger may be maintained by a proprietor, such as a system administrator on a server, that controls access to the ledger; for instance, the user account controls may allow contributors to the ledger to add at least a digitally signed assertion 200 to the ledger but may not allow any users to alter at least a digitally signed assertion 200 that have been added to the ledger”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like”; ¶74: “A device generating authorization token 124 may confirm authenticity of a manufacturer endorsing signature and/or signature made using identifier, and then provides authorization token 124 following confirmation; token may be a time limited token as described in further detail below, such that the evaluating device 104 must be re-authenticated before expiration continue performing actions as permitted by authorization token 124. As described further below, an authorization token 124 may include a signed timestamp and counter value, a passphrase required to decrypt messages on the network, or some combination”; ¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; ¶127: “tokens, digitally signed assertions, chains of attestation, and/or any other authentication and/or authorization decisions and/or other data and/or data structures evaluated and/or created according to any process described in this disclosure may be stored in and/or indexed by a library, which any device participating in and/or performing any action described in this disclosure may utilize to verify authentication, authorization, identification, chains of trust, and/or attestation chains
Barta and Wentz are directed to the same inventive concept since they are related to recording/storing and authenticating data, information in a distributed ledger/blockchain computing environment. Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured of Wentz since it allows for providing digitally signed assertions and files including an attestation conferring proof of endorsement, modifying, maintaining and controlling access to a cryptographically secured ledger (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶64, ¶65, ¶99, 101-111).
With respect to claim 15,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
the instructions, when executed, further cause the one or more modules to: incorporate a second claim element of the first chain of claim elements and a second evidence element of the first chain of evidence elements into the recursive object story data structure, (Fig 2, ¶22: “a smart contract operating in a blockchain… shipping links 210 may include entities on the shipping party end, such as an exporter 212, a trucker 214, a port authority 216 and an exporter's bank 218, for exiting a country ‘A’. The receiving side may be located in another country ‘B’ and have a custom's authority 222 and importer business 224. Any of the entities may be part of a blockchain. Certain ‘states’ may be used to describe where a shipment is presently located and in whose possession the shipment is currently held. Events may include a particular shipment changing custody or being moved to a new location. This may be identified via the parties and/or sensors configured to provide information to the parties and logged in the blockchain”)
the second claim element to include a statement related to an outcome of the determination of whether the plurality of conditions are met and the second evidence element to support the statement of the second claim element (¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. …The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶22: “Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment. One example of a failure or dispute may include attestation of a shipment's location by a possessor being audited as inaccurate… The event generators may be determined along with the parties and the sensors that report changes and make attestations. Next, specified generators may be matched with assurance policies, event generators may be flagged that do not satisfy policy requirements. Also, a contract amendment may be performed to promote policy resolution and to recommend suggestions for meeting required assurance levels”; ¶24: “a GPS sensor accompanying the shipment may emit events containing information about the shipment's current location and/or condition. The smart contract on the blockchain may update the shared ledger state when it receives these events”; ¶32: “a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensors, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time”; Fig 5, ¶33: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc”)
With respect to claim 16,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein to incorporate the second claim element the one or modules are to: send an access request to an object story manager via the network interface (Fig 4, ¶27: “The policy specification may include trust information which contains maps of sensors as they relate to the product shipment and parties having certain trust levels. Also, threshold trust levels can be set which are based on a particular <event, state>, for example, a freight shipping customer may have a trust level that is not high enough for the contractual terms, or may degrade an overall trust level by a certain amount”; ¶32: “Contract monitoring may be performed via XML, logic programs, etc. Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy. For example, a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running. Also, a periodic check may be performed to determine whether assurance levels are meeting desired thresholds of accuracy”; ¶33: “a contract is stored in the blockchain 512 on a blockchain designated server 520. An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance. Any subsequent actions or contract terms 534, which, for example, can be identified as being a potential hazard, are noted and included in an additional monitoring operation. An event may be logged 535 from a supply chain member, such as a carrier, custodian, etc”; ¶41: “the capabilities of the system of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture”)
With respect to claim 18,
Batra discloses,
receiving one or more conditions; (¶28: “Parties, states, events, and actions are described with reference to FIG. 2 for, as an example only, an international deal. Such an example can involve goods being exported from one party to another, and the financial transaction being mediated by the buyer's and seller's respective banks. Shipment progress through multiple stages and authorities (i.e., truckers, ports, and customs) can be tracked and smart contract terms can be compared…When the goods reach their destination and the importer's bank receives the documentation from the exporter, a money transfer may then be accepted to pass to that exporter”; ¶34: “responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain. The events may include one or more of a date, a time, a location, a shipping requirement, other shipping information, and a financial transaction”; ¶36: “FIG. 6C illustrates a method 660 that includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 662, logging an event which is part of the metric configuration 664, determining a risk associated with the event 668, determining whether the risk exceeds a predetermined threshold level 672, and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event and the risk does not exceed the predetermined threshold level 674. If the risk level calculated does exceed the threshold level, then the transaction may not be logged in the blockchain and instead an alert may be created and used to alert an interested party regarding the failure and why the contract is not maintained in this event. For example, the alert may include the variable which had the highest weight, the variables which were violated, etc.”)
wherein: the object is an entity and the component is a department, team, or individual of the entity; the object is a facility and the component is a sub-facility; or the object is a first location and the component is a second location within the first location; (¶32: “Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy. For example, a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running… a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensor, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time… Depending on a desired assurance level, faulty sensor B may or may not be flagged for remediation action, as two attesters are operational at such a time. The failures can be flagged which trigger a remediation action. As a result, an alert can be sent in the form of notifications (e-mail, SMS, etc.) to administrators (users) specified in the contract”; ¶33: “Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc.”)
determine whether the plurality of conditions are met based on the first chain of claim elements, the first chain of evidence elements, the second chain of claim elements, and the second chain of evidence elements; (¶20: “a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶22: “the smart contract stored in the blockchain can include a physical infrastructure that supports the contract terms, especially when a purchase for a product is involved in the process. For instance, shipping links 210 may include entities on the shipping party end, such as an exporter 212, a trucker 214, a port authority 216 and an exporter's bank 218, for exiting a country ‘A’. The receiving side may be located in another country ‘B’ and have a custom's authority 222 and importer business 224. Any of the entities may be part of a blockchain. Certain ‘states’ may be used to describe where a shipment is presently located and in whose possession the shipment is currently held. Events may include a particular shipment changing custody or being moved to a new location. This may be identified via the parties and/or sensors configured to provide information to the parties and logged in the blockchain. a sensor tracking a shipment location or an action taken by a party accompanying or receiving shipment. In such an event, the contract specification should be parsed to ensure that events leading to the actions in the given states meet desired assurance levels. An extract operation may identify an <event, state> list from a smart contract stored in the blockchain. The event generators may be determined along with the parties and the sensors that report changes and make attestations. Next, specified generators may be matched with assurance policies, event generators may be flagged that do not satisfy policy requirements, ¶34-¶36; ¶34: the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and triggering an alarm when the metric configuration does not support the requirements of the contract. Also, the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”)
wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence (¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed”; Fig 6A, ¶34: “the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements”)
Applicant’s specification as filed does not properly convey how “a threshold level of evidence” is determined. The disclosure at ¶85, ¶88, ¶120 and ¶121 appears to be a general guideline about various levels of evidence and/or importance. Hence, Examiner interprets the limitation as, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at a level of evidence”. Giving the broadest reasonable interpretation of the claim limitation in light of the specification, Examiner interprets the smart contracts include agreements about a process or workflow, terms, obligations, to be met by certain parties; as well as recording signatures and other non-revocable data on a shared ledger (i.e. a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment) The proof agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed as taught by Batra as teaching applicant’s limitation, “wherein a first condition of the plurality of conditions is that at least one evidence element of the first chain of evidence elements supports the statement about the object with at least a threshold level of evidence”
output an indication of whether the plurality of conditions are met (¶19: “a contract can be scanned and terms can be identified/parsed and backend system entities, such as supply chain entities, finance entities, etc., can be identified and examined before deployment on a blockchain to detect whether associated technology is sufficient to support/enforce the contractual terms. At each stage of contract execution, monitoring operations may include evaluating associated third-party system technology for availability and operational validity. In the event that a mismatch between contract terms and another entity or process is discovered or identified, for example, between a contract term and a third party, an alert, alarm, notification, etc., can be created and used to identify interested parties, such as a seller, purchaser, and financer, that the standards have not been met and that the contract requires attention”; ¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed”; ¶26: “Upon discovery of a contract violation (e.g., the desired assurance levels for location tracking sensors is not being met), parties may choose to deploy new sensors and/or add human verifiers”; ¶33: “An auditor may enact an operation that causes the contract to be retrieved 524 to identify the terms 526 and/or metrics 528, such as current operating conditions including any of the supply chain terms described. The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance”; ¶30: “In the event of a failure, notifications may be sent out to one or more parties”; Fig 6A, ¶34: the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and triggering an alarm when the metric configuration does not support the requirements of the contract. Also, the method may include identifying the requirements of the contract after the contract is logged in the blockchain, and logging a transaction on the blockchain corresponding to the contract when the existing configuration supports the requirements of the contract. Additionally, the method may provide logging events on the blockchain as such events occur, and retrieving the requirements and comparing the events to the requirements responsive to the events being logged on the blockchain. Further to this example, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain”; ¶35: “certain portions of the metric configuration may be acceptable in the smart contract while others may be impermissible and may require an alert or alarm to notify the parties. The event may serve as the trigger which causes the metric configuration to be identified and compared to the smart contract information”)
Batra discloses all of the above limitations, Batra does not distinctly disclose the following limitations, but Wentz however as shown discloses,
accessing a recursive object story data structure that includes first chain of claim elements, a first chain of evidence elements and a recursive component story data structure wherein a first claim element of the first chain of claim elements includes: a cryptographic hash of one or more previous claim elements in the chain of claim elements; a link to a subsequent claim element in the chain of claim elements (Fig 1, Fig 2, ¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks… various ways in which steps, sequences of steps, processing tasks, and/or data may be subdivided, shared, or otherwise dealt with using iteration, recursion, and/or parallel processing”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain” ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Fig 3, ¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”)
a statement about an object that is a facility, an entity, or a location and an indication of a first evidence element of the first chain of evidence elements, wherein the first evidence element is cryptographically linked with the first claim element, supports the statement about the object with a first level of evidence selected from a plurality of levels of evidence; and includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements (¶2-5; ¶2: “the present invention is directed to recording a digitally signed assertion using an authorization token”; ¶4: “assigning, by the evaluating device, a confidence level to the first digitally signed assertion. The method includes authenticating, by the evaluating device, the first digitally signed assertion as a function of the confidence level”; ¶15-¶20; ¶15: “authentication of digitally signed assertions and files containing digitally signed assertions, including cryptographic immutable ledgers, such as block chains or the like”; ¶16: “authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain”; ¶17: “Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score; numerical score may be a score on a scale having one extremum representing a maximal degree of reliability, and a second extremum representing a minimum degree of reliability”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… , at least a digitally signed assertion 200 may describe a transfer of virtual currency, such as crypto currency as described below. The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity. Item of value may be an interest in a fungible negotiable financial instrument representing ownership in a public or private corporation, a creditor relationship with a governmental body or a corporation, rights to ownership represented by an option, derivative financial instrument, commodity, debt-backed security such as a bond or debenture or other security as described in further detail below. At least a digitally signed assertion 200 may describe the transfer of a physical good; for instance, at least a digitally signed assertion 200 may describe the sale of a product”; ¶64: “ In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “; ¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408… Evaluating device 404 may alternatively or additionally receive at least a communication by retrieving it from memory where it has been stored either entirely or in a representation such as a cryptographic hash as described above. Retrieval may include retrieval from any suitable data structure; for instance, and without limitation, retrieval may include receiving a transaction recorded in a temporally sequential listing”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
wherein individual evidence elements of the first chain of evidence elements support the statement about the object with individual levels of evidence and each of the first chain of claim elements and the first chain of evidence elements are implemented in a distributed ledger or blockchain;( (¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof… , at least a digitally signed assertion 200 may describe a transfer of virtual currency, such as crypto currency as described below. The virtual currency may be a digital currency. Item of value may be a transfer of trust, for instance represented by a statement vouching for the identity or trustworthiness of the first entity”; ¶64: “ In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408… Evaluating device 404 may alternatively or additionally receive at least a communication by retrieving it from memory where it has been stored either entirely or in a representation such as a cryptographic hash as described above. Retrieval may include retrieval from any suitable data structure; for instance, and without limitation, retrieval may include receiving a transaction recorded in a temporally sequential listing”)
accessing the recursive component story data structure that includes a second chain of claim elements and a second chain of evidence elements implemented in the distributed ledger or blockchain, wherein a first claim element of the second chain of claim elements includes: a statement about a component of the object; and an indication of a first evidence element of the second chain of evidence elements that supports the statement about the component (Abstract: “the first digitally signed assertion as a function of the confidence level, generating, by the evaluating device, a second digitally signed assertion as a function of the first digitally signed assertion, and entering, by the evaluating device, the second digitally signed assertion in at least an instance of a first temporally sequential listing”; ¶2-5; ¶2: “the present invention is directed to recording a digitally signed assertion using an authorization token”; ¶4: “at least a communication including a first digitally signed assertion recorded in a Second temporally sequential listing… assigning, by the evaluating device, a confidence level to the first digitally signed assertion. The method includes authenticating, by the evaluating device, the first digitally signed assertion as a function of the confidence level”; ¶15-¶20; ¶15: “authentication of digitally signed assertions and files containing digitally signed assertions, including cryptographic immutable ledgers, such as block chains or the like”; ¶16: “authenticating and importing digitally signed assertions from a first distributed network, or a first block chain, to a second distributed network, or second block chain”; ¶17: “Confidence level, as used herein, is an element of data expressing a degree to which the safety, security, or authenticity of a process, device, or datum may be relied upon. As used herein, a confidence level may include a numerical score; numerical score may be a score on a scale having one extremum representing a maximal degree of reliability, and a second extremum representing a minimum degree of reliability”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain” ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like. In an embodiment, where a digitally signed assertion is used to perform a transaction, authorization token 124 may confer the right to perform that transaction on evaluating device 104. Where a transaction has a given transaction amount and/or type, authorization token 124 may confer the right to engage in a transaction having that transaction amount and/or type”; ¶74: “an authorization datum may include a digital certificate as described above; digital certificate may, for instance and without limitation, associate an identity of a user or entity operating evaluating device 104 with an identifier of remote device, confer upon remote device access rights to one or more resources incorporated in or connected to system 100, associate evaluating device 104 with a given confidence level, grant a transfer of assets, data, and/or access rights from one device to another, or the like. An authorization datum may confer a right to access one or more resources incorporated in or connected to system 100. An authorization datum may associate an identity of a user or entity operating evaluating device 104 with an identifier of remote device”; ¶84: “Still viewing FIG. 1, each device in system 100 determining whether evaluating device 104 is authorized to perform an action may use a threshold cryptography protocol, as described above. In other words, a plurality of devices enacting methods as described above may be treated as a group of certificate authorities acting to authenticate in coordination, with the requirement that a threshold number of the group of certificate authorities, and/or a threshold proportion of the group of certificate authorities, agree (e.g., “threshold cryptography”) for authorization to be valid; threshold may include a number of verifying nodes. Threshold may include an aggregate confidence level threshold”; ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
with a second level of evidence selected from the plurality levels of evidence, wherein individual evidence elements of the second chain of evidence elements support the statement about the component with individual levels of evidence, (¶61: “In one embodiment, at least a digitally signed assertion 200 is a collection of textual data signed a secure proof”; ¶64: “temporally sequential listing 204 may preserve the order in which the at least a digitally signed assertion 200 took place by listing them in chronological order; alternatively or additionally, temporally sequential listing 204 may organize digitally signed assertions 200 into sub-listings 208 such as “blocks” in a blockchain, which may be themselves collected in a temporally sequential order; digitally signed assertions 200 within a sub-listing 208 may or may not be temporally sequential. The ledger may preserve the order in which at least a digitally signed assertion 200 took place by listing them in sub-listings 208 and placing the sub-listings 208 in chronological order. The temporally sequential listing 204 may be a distributed, consensus-based ledger… In some embodiments, ledger is cryptographically secured; in one embodiment, a ledger is cryptographically secured where each link in the chain contains encrypted or hashed information that makes it practically infeasible to alter the ledger without betraying that alteration has taken place, for instance by requiring that an administrator or other party sign new additions to the chain with a digital signature. Temporally sequential listing 204 may be incorporated in, stored in, or incorporate, any suitable data structure, including without limitation any database, datastore, file structure, distributed hash table, or the like. In some embodiments, the timestamp of an entry is cryptographically secured and validated via trusted time, either directly on the chain or indirectly by utilizing a separate chain”; ¶65: “Each new sub-listing 208 may be required to contain a cryptographic hash describing the previous sub-listing 208”; ¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof. Similarly, receiving first dataset may include receiving a reference to a second dataset. Such references to second digitally signed assertion 200, second secure proof, and/or second dataset may perform various functions, including linking first digitally signed assertion 200 to one or more past digitally signed assertions 200, so as to permit evolution of terms in a smart contract, exchanges of crypto-currency, or the like. References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation as explained in further detail below, providing parties with a way of assessing authenticity of first dataset and/or first digitally signed assertion 200”; ¶98: “entering first digitally signed assertion 200 in currently active sub-listing 208 further includes authenticating currently active sub-listing 208; authenticating may include verifying that a hash of at least one previous sub-listing 208 is correct, verifying earlier hashes in a hash chain, block chain, or the like, and/or verifying back to a genesis block “; ¶99: “a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”; Fig 4, Fig 5, ¶104-¶111; ¶104: “evaluating device 404 receives at least a communication from a cryptographic evaluator, verified device, or any other computing device including a first digitally signed assertion 412, which may be recorded in a second temporally sequential listing 408”; ¶106: “first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token, which may be any authorization token”; ¶107: “evaluating device 404 assigns a confidence level to first digitally signed assertion”)
Applicant’s disclosure discusses examples and variable levels of evidence- see ¶85: “Each claim may also contain evidence elements that are a form of proof that the claim can be trusted"; ¶88 “Assertion, Self-Certification, Basic Audit, Third Party certification, Third Party certification with audit, and at ¶89: “additional/alternative levels of evidence may be used that are useful for a specific field”, and ¶91: “One embodiment of a process to secure linked evidence and claim elements is as a set of distributed blockchains or a distributed ledger secured by cryptographic hashes”. Wentz discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz further discloses that a first digitally signed assertion may include an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing… including without limitation blockchains and the like. Giving the broadest reasonable interpretation of applicant’s claim limitation, in light of the specification, Examiner interprets at least the authenticated digitally signed assertions and files, cryptographic immutable ledgers/blockchains sequentially linked, and/or a digital signed assertions including an attestation conferring proof of endorsement by a third party conferring a confidence level, level of access, authorization token and order preserving protocol (i.e. Merkle trees or other has trees) as taught by Wentz as teaching applicant’s limitation, “an indication of a first evidence element, cryptographically linked with the first claim element (digitally signed assertions and files…including cryptographic immutable ledgers/block chains), to support veracity of the assertion with a first level of evidence selected from a plurality of levels of evidence (including an attestation conferring proof of endorsement by a third party.. providing confidence level, level of access, authorization token), and includes a cryptographic hash of one or more previous evidence elements in the chain of evidence elements and a link to a subsequent evidence element in the chain of evidence elements (order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries).
Batra teaches a block chain configuration for storing smart contracts including but not limited to identifying smart contract information from a blockchain and more particularly to anticipating and monitoring transactions in the blockchain to determine whether the smart contract requirements can be enforced. Wentz discloses a method/system for at least receiving a communication from any suitable data structure, including a first digitally signed assertion which may be recorded in a second temporally sequential listing, via a blockchain or distributed ledger. Wentz further discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz also teaches that a sequence of digitally signed assertions may be created and may refer to previously entered data that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions and that authenticating may include verifying earlier hashes in a hash chain, block chain and/or verifying back to a genesis block. Wentz further teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs. Wentz additionally discloses order preserving memory storage protocols may include, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries. Barta and Wentz are directed to the same endeavor since they are related to recording/storing and authenticating data/information in a distributed ledger/blockchain computing environment. Further it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to use the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz for authenticating and importing digitally signed assertions and files from a first distributed network, or first block chain to a second block chain or second distributed network cryptographic immutable ledgers, such as another block chain or immutable ledger using a side chain, hash tree or the like. The known techniques/tools for receiving, authenticating, generating and importing digitally signed assertions of Wentz would have predictably resulted in an improved architecture and process for maintaining and controlling access to a cryptographically secured ledger where each link in the chain contains encrypted or hashed information and a timestamp of the entry (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶64, ¶65, ¶101-111). Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured as taught by Wentz since it allows for providing digitally signed assertions and files including an attestation conferring proof of endorsement, modifying and/or verifying back to a genesis block, maintaining and controlling access to a cryptographically secured ledger, block chain, side chain, hash tree or the like, (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶61,¶64, ¶65, ¶88, ¶98-111).
With respect to claim 20,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein accessing the object story data structure comprises accessing elements incorporated into the object story data structure from a plurality of local or remote data sources (¶32: “Contract monitoring may be performed via XML, logic programs, etc. Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy …a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running … a periodic check may be performed to determine whether assurance levels are meeting desired thresholds of accuracy. For example, policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects those various sensors, such as sensors A and B, are reporting different locations”; Fig 5, ¶33: “The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance… Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc.”)
Wentz further discloses,
recursive object story data structure (¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “;¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”)
Batra and Wentz are directed to the same field of endeavor since they are related to storing, authenticating data/information in a distributed ledger/blockchain computing environment. Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured of Wentz since it allows for providing and authenticating digitally signed assertions and files including an attestation conferring proof of endorsement, maintaining and controlling access to a cryptographically secured ledger/blockchain (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶57, ¶64, ¶65, ¶99, ¶101-111).
With respect to claim 21,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
wherein accessing elements incorporated into the object story data structure comprises: sending, to a remote data source, a request for an element incorporated into the object story data structure, (¶25: “Sensors, such as GPS sensors can be periodically probed to ensure that they are not malfunctioning…”, ¶32: “Monitoring code may be monitored for each event generator. The status of each generator may be periodically checked for accuracy… a generator may be a location sensor and a test may be performed to determine whether a GPS sensor is up and running. Also, a periodic check may be performed to determine whether assurance levels are meeting desired thresholds of accuracy. For example, a policy may dictate that two independent attesters must report a shipment location at particular assurance level. A probe detects that various sensors, such as sensors A and B, are reporting different locations, and a human attester, for example C, reports a location identical to what A reported, and B has reported no change in location for a certain period of time”)
Wentz further discloses,
a recursive object story data structure (¶35: “FIG. 1, evaluating device 104 may be designed and/or configured to perform any method, method step, or sequence of method steps in any embodiment described in this disclosure, in any order and with any degree of repetition. For instance, Evaluating device 104 may be configured to perform a single step or sequence repeatedly until a desired or commanded outcome is achieved; repetition of a step or a sequence of steps may be performed iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs of repetitions to produce an aggregate result, reduction or decrement of one or more variables such as global variables, and/or division of a larger processing task into a set of iteratively addressed smaller processing tasks”; ¶57: “Secure computing module 108 may use one or more order-preserving memory storage protocols to detect “reset attacks” or fraudulent data entries presented out of order; such order preserving memory storage protocols may include, without limitation, Merkle trees or other hash trees in which each new entry contains a hash of a recently stored data entry and a hash of earlier Merkle tree and/or hash tree entries, rendering false or out-of-order entries computationally infeasible, or any temporally sequential listing as described above, including without limitation blockchains and the like”; ¶88: “second digitally signed assertion 200 may be entered in a second temporally sequential listing 204, such as another block chain or immutable ledger; reference to such an entry may be performed using a side chain, hash tree, or the like. Where evaluating device 104 produces a first secure proof as described in further detail below, dataset may include a reference to a second secure proof… References may also enable additional parties, such as one or more additional cryptographic evaluators, to evaluate a confidence level in evaluating device 104 and/or first digitally signed assertion 200 by reference to additional data; for instance, second secure proof may be signed by a evaluating device 104 associated with a high degree of confidence, as a voucher for the authenticity of the data contained therein, or may include a secure timestamp, element of attested memory, or output and/or state of an attested computation “;¶99: “any step or steps of method 300 as described above may be repeated, omitted, or modified consistently with any description of steps, components, modules, or means disclosed in this disclosure. For instance, and without limitation, a sequence of digitally signed assertions 200 may be created and entered using any processes, modules, and/or components as described herein; digitally signed assertions 200 in the sequence may refer to previously entered digitally signed assertions 200”)
wherein the request includes a security token to provide access authorization to the element (¶73: “an authorization token 124 is an element of data, digitally signed by a first device, containing an authorization datum conferring an access right, authority, and/or confidence level on a second device. An authorization token 124 received by evaluating device 104 may confer the authority on cryptographic evaluator to generate a digitally signed assertion, enter a digitally signed assertion in a temporally sequential listing, generate an additional authorization token 124, or the like. In an embodiment, where a digitally signed assertion is used to perform a transaction, authorization token 124 may confer the right to perform that transaction on evaluating device 104. Where a transaction has a given transaction amount and/or type, authorization token 124 may confer the right to engage in a transaction having that transaction amount and/or type”; ¶74: “an identifier of evaluating device 104 may be incorporated in at least an authorization datum; identifier may be specific to evaluating device 104 or may be a group identifier as described above, including without limitation a group public key; in other words, authorization token 124 may not be tied to a unique identifier of evaluating device 104. A device generating authorization token 124 may confirm authenticity of a manufacturer endorsing signature and/or signature made using identifier, and then provides authorization token 124 following confirmation; token may be a time limited token as described in further detail below, such that the evaluating device 104 must be re-authenticated before expiration continue performing actions as permitted by authorization token 124. As described further below, an authorization token 124 may include a signed timestamp and counter value, a passphrase required to decrypt messages on the network, or some combination”; ¶127: “tokens, digitally signed assertions, chains of attestation, and/or any other authentication and/or authorization decisions and/or other data and/or data structures evaluated and/or created according to any process described in this disclosure may be stored in and/or indexed by a library, which any device participating in and/or performing any action described in this disclosure may utilize to verify authentication, authorization, identification, chains of trust, and/or attestation chains”)
Batra discloses a blockchain configuration used to at least store smart contracts including identifying a metric configuration associated with the smart contract, logging an event which is part of the metric configuration, determining if the an event supports requirements of the contract, if a smart contract policy in the smart contract matches a system policy and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event and the smart contract policy matches the system policy. Batra further discloses triggering an alarm to notify parties/administrators/users specified in the contract and/or suspending the contract in the blockchain if the requirements/metrics/metric configuration(s) of the contract are not supported or not in compliance with contract compliance. Wentz discloses a method/system for at least receiving a communication from any suitable data structure, including a first digitally signed assertion which may be recorded in a second temporally sequential listing, via a blockchain or distributed ledger. Wentz further discloses creating, maintaining, authenticating, importing/recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured were each link in the chain contains encrypted or hashed information. Wentz teaches that the system may perform the method/system step(s) iteratively and/or recursively using outputs of previous repetitions as inputs to subsequent repetitions, aggregating inputs and/or outputs and that digitally signed assertions in a sequence may refer to previously entered digitally signed assertions. Wentz also teaches a method/system including at least an evaluating device, secure computing module, certificate authority, authorization token communicating via a network interface with one or more additional devices, and distributing one or more computing tasks across a plurality of computing devices for creating, maintaining, authenticating, importing/recording data and/or data structures and digitally signed assertions via a blockchain or distributed ledger.
Batra and Wentz are directed to the same field of endeavor since they are related to storing, authenticating data/information in a distributed ledger/blockchain computing environment. Therefore, it would have been obvious to one of ordinary skill in the art at the time of applicant’s invention to combine the method/system for monitoring transactions in blockchain configuration of Batra with the method/system for recording digitally signed assertions via a blockchain or distributed ledger that is cryptographically secured of Wentz since it allows for providing and authenticating digitally signed assertions and files including an attestation conferring proof of endorsement, maintaining and controlling access to a cryptographically secured ledger/blockchain (Figs 1-6, ¶2, ¶4, ¶15-¶20, ¶35, ¶64, ¶65, ¶99, ¶101-111).
With respect to claim 23,
Batra and Wentz disclose all of the above limitations, Batra further discloses,
incorporating, into the first chain of claim elements, a second claim element that includes a statement relating to an outcome of said determining whether the one or more conditions are satisfied and incorporating, into the first chain of evidence elements, a second evidence element to support the statement of the second claim element. (Fig 2, ¶20: “smart contracts include agreements about a process or workflow and describe terms and obligations to be met by certain parties. In operation, an event-driven state machine may be used to examine contract terms. Parties may record signatures and other non-revocable data on a shared ledger. In one example, a delivery of a shipment can be attested by the receiver or by a sensor attached to the shipment. The proof must be obtained and meet an agreed-upon level of assurance that is dictated by the contract terms in the blockchain in order for the contract workflow to proceed, and to avoid potential (and future) disputes”; ¶22: “a smart contract operating in a blockchain… shipping links 210 may include entities on the shipping party end, such as an exporter 212, a trucker 214, a port authority 216 and an exporter's bank 218, for exiting a country ‘A’. The receiving side may be located in another country ‘B’ and have a custom's authority 222 and importer business 224. Any of the entities may be part of a blockchain. Certain ‘states’ may be used to describe where a shipment is presently located and in whose possession the shipment is currently held. Events may include a particular shipment changing custody or being moved to a new location. This may be identified via the parties and/or sensors configured to provide information to the parties and logged in the blockchain. Certain actions may include but are not limited to a transfer of money from one entity to another, such as from an importer's account to an exporter's account, after an action is taken, such as a shipment is received, which may be confirmed, for example by a last shipping link. Another example may include a transfer of a shipment to the importer's possession after an exporter's bank receives a payment. One example of a failure or dispute may include attestation of a shipment's location by a possessor being audited as inaccurate”; ¶28: “Shipment progress through multiple stages and authorities (i.e., truckers, ports, and customs) can be tracked and smart contract terms can be compared. In this scenario, a smart contract would be created and encoded to include an importer which may apply for and obtain a letter of credit from a bank and present it as a promise of future payment to an exporter… The carrier, and the various stages through which the shipment passes, attest to the shipment having passed through certain stages, such as reaching a port, clearing customs, etc. When the goods reach their destination and the importer's bank receives the documentation from the exporter, a money transfer may then be accepted to pass to that exporter”; Fig 5, ¶33: “The contract terms are compared 532 to the metrics either instantly or over time to ensure contract compliance… Metrics or a metric configuration may be a combination of parties, current states and events which have recently occurred or are about to occur. Examples of parties may include exporters, shipping entities, port authorities, manufacturers, purchasers, government entities, customs, banks, etc. The states may be a current status, such as a particular time, location, current item or possessor. The events may include a change in possession, a transfer of funds from one party to another, a new shipment status, a change in the shipment status, etc.”; ¶34: “, the method may provide, responsive to comparing the events in the blockchain, identifying whether the events match the requirements of the contract, and continuing to log the events on the blockchain when the events match the requirements. As a result, when the event does not match the requirements of the contract, triggering an alarm and suspending the contract in the blockchain. The events may include one or more of a date, a time, a location, a shipping requirement, other shipping information, and a financial transaction”; ¶36: “FIG. 6C illustrates a method 660 that includes one or more of identifying a metric configuration associated with a smart contract stored in a blockchain 662, logging an event which is part of the metric configuration 664, determining a risk associated with the event 668, determining whether the risk exceeds a predetermined threshold level 672, and updating the smart contract on the blockchain when the requirements of the smart contract are supported by the event and the risk does not exceed the predetermined threshold level 674”)
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
NPL 2020 Gao et al., Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains”, Z. Gao, H. Li, K. Xiao and Q. Wang, "Cross-chain Oracle Based Data Migration Mechanism in Heterogeneous Blockchains," 2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS), Singapore, Singapore, 2020, pp. 1263-1268, doi: 10.1109/ICDCS47774.2020.00162. https://ieeexplore.ieee.org/document/9355678
2019 NPL, The World Bank Group Information and Technology Lab and IMF’s Digital Advisory Unit, “Blockchain Interoperability”, A Framework for Blockchain Interoperabilityhttps://documents1.worldbank.org/curated/en/373781615365676101/pdf/Blockchain-Interoperability.pdf
NPL 2020 Zhang et al., “Research on Cross-Chain Technology Architecture System Based on Blockchain” https://doi.org/10.1007/978-981-13-9409-6_318
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 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 of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Kimberly L. Evans whose telephone number is 571.270.3929. The Examiner can normally be reached on Monday-Friday, 9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Lynda Jasmin can be reached at 571.272.6782.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov >. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). Any response to this action should be mailed to: Commissioner of Patents and Trademarks, P.O. Box 1450, Alexandria, VA 22313-1450 or faxed to 571-273-8300. Hand delivered responses should be brought to the United States Patent and Trademark Office Customer Service Window: Randolph Building 401 Dulany Street, Alexandria, VA 22314.
/KIMBERLY L EVANS/Examiner, Art Unit 3629
/NATHAN C UBER/Supervisory Patent Examiner, Art Unit 3626