DETAILED ACTION
Status of Claims
Claims 2-6 and 19-24 have been previously cancelled.
Claims 1, 7-18, and 25-34 are currently pending and have been considered by the examiner.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 29 December 2025 has been entered.
Response to Arguments
101 Rejection:
Applicant asserts that the claimed subject matter addresses a specific technical problem as outlined on pg. 10-11 of the remarks received 19 December 2025 and thus all claims should be found eligible under 35 USC 101. The examiner respectfully disagrees.
Specifically, applicant has provided no specific argument regarding the specific limitations of the claims directed towards the asserted technical improvements. Further, applicant’s assertions of technical improvements do not appear to be directed towards outlining how the claimed invention differs from a “Traditional CRDT”, merely stating the that claimed limitation reciting: “wherein the peers are arranged to maintain the Consensus of the network according to a Consensus Protocol including the application of the Belief Merge Function to Beliefs” addresses a specific technical problem and providing information regarding said “Traditional CRDTs” and their supposed deficiencies without providing explanation regarding how the claimed invention remedies said deficiencies. Additionally, on pg. 10 of the remarks, applicant cites broadly to Wikipedia, providing a quotation without providing a specific Wikipedia webpage or document.
Thus, as applicant has not provided any specific arguments regarding ineligibility of the claimed invention under 35 USC 101, the examiner must reassert that the claims are patent ineligible based upon the rationale provided in the following 101 rejection.
Prior Art Rejection:
Applicant asserts that the prior art of record fails to disclose the claimed invention because the claimed invention is directed towards a “Lattice CRDT” as opposed to a “Traditional CRDT” as supposedly disclosed by Merkle. When considering the BRI of the claims “Conflict-free Replicated Data Type”, the examiner must consider the contents of the specification. However, the specification makes no mention of the term “lattice” other than the use of the term “join-semilattice” when describing monotonic headers. Additionally, the Wikipedia page cited by applicant on pg. 12 of the remarks received 29 December 2025 is devoid of the term “Lattice CRDT”. Thus, the examiner is unpersuaded that the claimed invention is directed towards the supposed “Lattice CRDT” as asserted in the remarks. The examiner asserts that the BRI of the claimed “Conflict-free Replicated Data Type” encompasses the Conflict-free Replicated Data Type disclosed by Merkle as outlined in the previously issued final office action. As applicant has not provided any specific limitations which fail to be disclosed by the prior art of record, merely presenting blanket assertions and generalized statements, the examiner must maintain the previously issued prior art rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 7-18, and 25-34 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 18 and 25-34 are directed to a method and claims 1 and 7-17 are directed to an system/apparatus. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A system for achieving efficient Consensus comprising:
one or more nodes of various types arranged as arbitrary communication and functional participants in a Network, wherein at least a first node type is termed a Peer,
production of Beliefs by Peers such that each Belief contains data used for forming Consensus;
a Belief Merge Function which combines one or more Beliefs;
wherein the Peers are arranged to maintain the Consensus of the network according to a Consensus Protocol including the application of the Belief Merge Function to Beliefs;
wherein the Belief Merge Function is defined such that the Network exhibits the property of Convergence to a single Consensus.
wherein at least a second node type is termed a Client;
wherein the Clients are arranged to submit new Transactions that may affect the Consensus and query information resulting from the Consensus of the Network;
wherein the Belief Merge Function is defined using a computation that is idempotent, associative and commutative, such that the system is able to operate as a Conflict-free Replicated Data Type
a specific type of information units, known as Blocks;
full or partial Orderings of the specific type information units, Blocks, comprising Values and Cells, included as a constituent part of a Belief;
a State Transition Function capable of computing an updated State given some Ordering;
one or more Initial States;
wherein a Consensus State may be computed by repeated application of the State Transition Function to an Initial State and information unit(s) that may be included in the Ordering;
collections of zero or more information units known as Transactions which are included as constituent parts of each Block;
optional additional information supplied by the Peer, such as a timestamp or digital signatures;
wherein the Blocks and their constituent Transactions and any additional information are arranged to be included as part of the Ordering;
wherein the information units in an Ordering are defined not to contain references to one or more previous information units, such that it is possible to re-order the Blocks in the Consensus process.
Regarding Step 2A Prong One, the claims recite the abstract idea of performing a commercial interaction. Specifically, the claims recite the limitations underlined above which recite commercial interactions in the form of performing blockchain transaction which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of performing commercial blockchain transactions. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as “one or more nodes” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “one or more nodes” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of “one or more nodes” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “one or more nodes” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite performing commercial interactions. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-17 and 19-34 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claims 7-17 and 25-34 recite additional limitations which are also directed towards the recite abstract idea of performing commercial interactions in the form of blockchain transactions or are directed to steps required to perform the abstract idea such as achieving consensus.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 10-15, 17-18, 27-32, and 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merkle-CRDTs Merkle-DAGs meet CRDTs in view of Zamora Duran et al. (US 20190372985 A1), hereinafter simply referred to as Zamora.
Regarding Claims 1 and 18, Merkle discloses:
A system for achieving efficient Consensus comprising:
one or more nodes of various types arranged as arbitrary communication and functional participants in a Network, wherein at least a first node type is termed a Peer (See Merkle: Pg. 1, left column, Para. 2 – “The advent of blockchain technology has generalized the use of peer-to-peer networking along with cryptographically directed acyclic graphs, known as Merkle-DAGs, to implement globally distributed and eventually consistent data structures in applications such as cryptocurrencies”),
production of Beliefs by Peers such that each Belief contains data used for forming Consensus (See Merkle: Pg. 3, Section D – “CRDTs are data types which provide strong eventual consistency among different replicas in a distributed system by requiring certain properties from the state and/or the operations that modify it. Additionally, CRDTs also feature monotonicity. The concept of monotonicity applied to data types is the notion that every update is an inflation, making the state grow, not in size, but in respect to a previous state. This implies that there will always be an order between states”);
a Belief Merge Function which combines one or more Beliefs (See Merkle: Pg. 3-4, Section D – “There are two prominent types of CRDTs: state-based and operation-based CRDTs. In state-based CRDTs, all the states in the system —that is, the states in different replicas and different moments— form a monotonic join-semilattice. That means that, for any two states X and Y , both can be ”joined” (merged, or form a union) (⊔) and the result is a new state corresponding to the Least-Upper-Bound (LUB) of the two”);
wherein the Peers are arranged to maintain the Consensus of the network according to a Consensus Protocol including the application of the Belief Merge Function to Beliefs (See Merkle: Pg. 9, left column - “Merkle-CRDTs are a marriage between traditional blockchains, which need consensus to converge, and CRDTs, which converge by design, and thus inherit positive and negative aspects from both worlds”);
wherein the Belief Merge Function is defined such that the Network exhibits the property of Convergence to a single Consensus (See Merkle: Pg. 3, Section D – “Upon receiving the state, the other replicas merge it with the local state. The properties of the state ensure that, if the replicas have correctly received the states sent by other replicas—and vice-versa—, they will eventually converge.” And See Merkle: Pg. 9, left column – “Merkle-CRDTs are a marriage between traditional blockchains, which need consensus to converge, and CRDTs, which converge by design”).
wherein at least a second node type is termed a Client (See Merkle: Pg. 3, left column – “Merkle-DAGs are also the foundational block of blockchains—they can be seen as a Merkle-DAG with a single branch—and their most common application: cryptocurrencies (e.g., [3], [1], [18]). Cryptocurrencies like Bitcoin [26] benefit from the embedded causality information encoded in the chain: transactions in a block deeper in the chain always happened before those of earlier blocks. One of the main issues in cryptocurrencies is to make all participating peers agree about the tip/head/root of the chain. Among other things, the noncommutative nature of some transactions, requires a consensus mechanism which enforces that only valid blocks become the new roots.”); and
wherein the Clients are arranged to submit new Transactions that may affect the Consensus and query information resulting from the Consensus of the Network (See Merkle: Pg. 3, left column – “One commonality in many of these systems is that the Merkle-DAG implicitly embeds causality information. The DAG can show that a certain transaction precedes another or that a Git commit needs to be merged rather than fastforwarded”).
wherein the Belief Merge Function is defined using a computation that is idempotent, associative and commutative, such that the system is able to operate as a Conflict-free Replicated Data Type (See Merkle: Pg. 4, left column – “A join-semilattice is thus a partially ordered set and its LUB is the smallest state capable of containing all the states in the semilattice. This implies that the ⊔ operation must be idempotent (X ⊔ X = X), commutative (X⊔Y =Y⊔X)and associative ((X⊔Y)⊔Z = X⊔(Y ⊔Z))”).
a specific type of information units, known as Blocks (See Merkle: Pg. 3, left column – “Merkle-DAGs are also the foundational block of blockchains—they can be seen as a Merkle-DAG with a single branch—and their most common application: cryptocurrencies (e.g., [3], [1], [18]). Cryptocurrencies like Bitcoin [26] benefit from the embedded causality information encoded in the chain: transactions in a block deeper in the chain always happened before those of earlier blocks”);
full or partial Orderings of the specific type information units, Blocks, comprising Values and Cells, included as a constituent part of a Belief (See Merkle: Pg. 2, right column – “A Directed Acyclic Graph (DAG) is a type of graph in which edges have direction and cycles are not allowed. For example, a linked list like A → B → C is an instance of a DAG where A references B and so on. We say that B is a child or a descendant of A, and that node A has a link to B. Conversely A is a parent of B. We call nodes6 that are not children to any other node in the DAG as the root nodes. A Merkle-DAG is a DAG where each node has an identifier and this is the result of hashing the node’s contents —any opaque payload carried by the node and the list of identifiers of its children— using a cryptographic hash function like SHA256”);
a State Transition Function capable of computing an updated State given some Ordering (See Merkle: Pg. 3, left column – “Merkle-DAGs are widely used. Source control systems [13] like Git [17] use them to efficiently store the repository history in a way that enables de-duplicating the objects and detecting conflicts between branches. In distributed databases like Dynamo [19], Merkle-Trees are used for efficient comparison and reconciliation of the state between replicas. In Hash Histories [22], content addressing is used to refer to a Merkle-Tree representing a state”);
one or more Initial States (See Merkle: Pg. 3, left column – “Merkle-DAGs are widely used. Source control systems [13] like Git [17] use them to efficiently store the repository history in a way that enables de-duplicating the objects and detecting conflicts between branches. In distributed databases like Dynamo [19], Merkle-Trees are used for efficient comparison and reconciliation of the state between replicas. In Hash Histories [22], content addressing is used to refer to a Merkle-Tree representing a state”);
wherein a Consensus State may be computed by repeated application of the State Transition Function to an Initial State and information unit(s) that may be included in the Ordering (See Merkle: Pg. 2 – right column – “For example, in the previous linked list, assuming that the payload of each node is just the CID of its descendant would be: A = Hash(B) → B =Hash(C) → C = Hash(∅). The properties of the hash function ensure that no cycles can exist when creating Merkle-DAGs.”).
collections of zero or more information units known as Transactions which are included as constituent parts of each Block (See Merkle: Pg. 3, left column – “Merkle-DAGs are also the foundational block of blockchains—they can be seen as a Merkle-DAG with a single branch—and their most common application: cryptocurrencies (e.g., [3], [1], [18]). Cryptocurrencies like Bitcoin [26] benefit from the embedded causality information encoded in the chain: transactions in a block deeper in the chain always happened before those of earlier blocks. One of the main issues in cryptocurrencies is to make all participating peers agree about the tip/head/root of the chain. Among other things, the noncommutative nature of some transactions, requires a consensus mechanism which enforces that only valid blocks become the new roots.”);
optional additional information supplied by the Peer, such as a timestamp or digital signatures (See Merkle: Pg. 3, right column – “Tagging events with timestamps can give us this information: if all events are timestamped, any replica may establish the order in which they happened and use that information to decide what the final state should look like. However, In distributed systems, it is not possible to use timestamps reliably [27], as not every replica can be perfectly synced to a global time. “Wall clocks” can also easily be simulated or spoofed, which is problematic in peer-to-peer systems with no trust involved.”);
wherein the Blocks and their constituent Transactions and any additional information are arranged to be included as part of the Ordering (See Merkle: Pg. 2, right column – “A Directed Acyclic Graph (DAG) is a type of graph in which edges have direction and cycles are not allowed. For example, a linked list like A → B → C is an instance of a DAG where A references B and so on. We say that B is a child or a descendant of A, and that node A has a link to B. Conversely A is a parent of B. We call nodes6 that are not children to any other node in the DAG as the root nodes. A Merkle-DAG is a DAG where each node has an identifier and this is the result of hashing the node’s contents —any opaque payload carried by the node and the list of identifiers of its children— using a cryptographic hash function like SHA256”).
Merkle fails to explicitly disclose:
wherein the information units in an Ordering are defined not to contain references to one or more previous information units, such that it is possible to re-order the Blocks in the Consensus process.
However, in a similar field of endeavor, Zamora discloses:
wherein the information units in an Ordering are defined not to contain references to one or more previous information units, such that it is possible to re-order the Blocks in the Consensus process (See Zamora: Para. [0035] – “he miner 206 may include a miner node nested at various network levels. The miner 206 may have limited power, such as the ability to create a block using a transaction, reorder a transaction, remove a transaction or translate a blockchain from one node to a different node. The miner 206 may not, for example, provide consensus to create a blockchain from a list of transactions. The miner node may expend computing power to allow a node to be at one or more hierarchy levels simultaneously. A blockchain access program may use a non-centralized federation (i.e., decentralized network) based on compute power to allow a node to operate at one or more hierarchy levels simultaneously.”).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the information units disclosed by Merkle to function similarly to the reorderable blockchain information stored in the method disclosed by Zamora yielding the predictable result of a more robust system by enabling data to be organized more efficiently.
Regarding Claims 10 and 27, Merkle discloses:
further comprising: Novelty detection; wherein nodes observing Novelty may communicate Novelty to other nodes; wherein nodes may optionally omit communication of information that is not Novelty, in order to save network resources and processing costs (See Merkle: Pg. 3, left column – “The design of causally-convergent systems involves the reconciliation of diverging state versions among different replicas when, for example, events occur concurrently. This requires that we are able to identify whether two events actually happened concurrently and whether two states are actually different because of concurrent updates or other reasons, such as one replica having received more updates. The problem is, essentially, tracking the order in which different events happened. For example, given multiple writes of a value to a register in different replicas, we would expect the final value in the registry to be that of the last write. Ideally, we should be able to order all the events in the system9 so that we can identify which was the actual last update to the register.”).
Regarding Claims 11 and 28, Merkle discloses:
further comprising: representing information Values, which are represented as one or more Cells (See Merkle: Pg. 3, left column – “Merkle-DAGs are also the foundational block of blockchains—they can be seen as a Merkle-DAG with a single branch—and their most common application: cryptocurrencies (e.g., [3], [1], [18]). Cryptocurrencies like Bitcoin [26] benefit from the embedded causality information encoded in the chain”);
producing an Encoding for a Cell, preferably in a form suitable for storage or Network communication (See Merkle: Pg. 3, left column – “Merkle-DAGs are also the foundational block of blockchains—they can be seen as a Merkle-DAG with a single branch—and their most common application: cryptocurrencies (e.g., [3], [1], [18]). Cryptocurrencies like Bitcoin [26] benefit from the embedded causality information encoded in the chain”);
Smart References enabling a reference to a Cell to be included within the information and/or Encoding of another Cell (See Merkle: pg. 9, right column – “Another option is to make the payload (or parts of it) CIDs to reference the actual contents. If the payloads are big, this will greatly reduce the size of the Merkle-DAG and may increase the efficiency of the DAG fetching. This is especially relevant when some of the payloads are identical and can be de-duplicated, or when it is possible to access part of the data opportunistically.”);
embedding an Encoding within another Encoding thereby enabling any Value to be completely represented as a graph of Cells connected by Smart References (See Merkle: pg. 9, right column – “Additional pointers in nodes: One of the ways to work around the thin-DAG problem is to regularly introduce references to deeper parts of the DAG when issuing new nodes. This method is basically adding extra children to nodes. It allows more parallelism when fetching missing parts of the DAG by being able to jump to other sections of it, resulting in much faster traversals. The actual number of extra links and their destination will depend on the needs of the application.”).
Regarding Claims 12 and 29, Merkle discloses:
further comprising: producing a Value ID for a Cell, such as a cryptographic hash function applied to the Encoding (See Merkle: pg. 2, right column – “A Merkle-DAG is a DAG where each node has an identifier and this is the result of hashing the node’s contents —any opaque payload carried by the node and the list of identifiers of its children— using a cryptographic hash function like SHA256.”);
wherein the Value ID can be used as a unique reference for the information unit (See Merkle: pg. 2, right column – “Identifying a data object (like a Merkle-DAG node) by the value of its hash is referred to as content addressing. Thus, we name the node identifier as Content Identifier or CID.”).
Regarding Claims 13 and 30, Merkle discloses:
further comprising: a Convergent Storage for information values (See Merkle: pg. 1, right column – “By embedding CRDT objects inside Merkle-DAG nodes, we obtain the best properties of both worlds, that is, we obtain a convergent system that can leverage the DAG as a logical clock.”);
wherein only the information units currently in active use are required to be in the working memory of a node, and other information units can be persisted to permanent storage and/or deleted if not required for further processing, i.e., garbage collected (See Merkle: pg. 2, left column – “We define Merkle-CRDTs as a general purpose transport and persistence layer for CRDT payloads which leverages the properties of Merkle-Clocks, using the DAG-Syncer and the Broadcaster to provide per-object causal consistency by design. This enables the use of simple CRDT types in systems with weak messaging layer guarantees and large number of replicas.”);
wherein the addition of new information to Storage has the Convergence property, such that data inconsistencies may be avoided (See Merkle: pg. 1, right column – “By embedding CRDT objects inside Merkle-DAG nodes, we obtain the best properties of both worlds, that is, we obtain a convergent system that can leverage the DAG as a logical clock.”).
Regarding Claims 14 and 31, Merkle discloses:
further comprising: computing the Memory Size of a Cell or other information Value (See Merkle: pg. 9, right column – “A similar effect can be achieved by embedding version vectors in the payloads, as long as the application can tolerate the constraints they impose. Comparing version vectors between payloads is an inclusion check without the need to perform a DAG-walking.”);
Memory Accounting; wherein the Memory Accounting is used to assign Incentives to participants on the network, such as to conserve memory, storage and/or communication bandwidth (See Merkle: pg. 9, right column – “One of the ways to work around the thin-DAG problem is to regularly introduce references to deeper parts of the DAG when issuing new nodes. This method is basically adding extra children to nodes. It allows more parallelism when fetching missing parts of the DAG by being able to jump to other sections of it, resulting in much faster traversals. The actual number of extra links and their destination will depend on the needs of the application.”).
Regarding Claims 15 and 32, Merkle discloses:
further comprising: means of caching computed Memory Sizes for each Cell or information unit either in working memory and/or Storage; wherein cached Memory Sizes are used to reduce the computational complexity of computing the memory size for large data structures, such as only needing to compute the Memory Size for Novelty (See Merkle: pg. 9, right column – “This implies, however, that the implementation must be aware and have access to the local storage system for nodes. The DAG-Syncer, as currently defined, cannot differentiate between nodes available locally or remotely. Bloom filters, caches and some data structures can also improve efficiency, but they are usually part of the chosen storage backend.”).
Regarding Claims 17 and 32, Merkle discloses:
further comprising: one or more Monotonic Headers, which associate header information with information Values and/or Cells; wherein the Monotonic Header also provides the property of Convergence, such that is can be relied upon for caching, performance optimization and tagging the status of Cells (See Merkle: pg. 3, right column – “Tagging events with timestamps can give us this information: if all events are timestamped, any replica may establish the order in which they happened and use that information to decide what the final state should look like. However, In distributed systems, it is not possible to use timestamps reliably [27], as not every replica can be perfectly synced to a global time. “Wall clocks” can also easily be simulated or spoofed, which is problematic in peer-to-peer systems with no trust involved”).
Regarding Claims 7 and 24, the combination discloses:
Computation of Consensus Orderings; wherein the Computation of Consensus Ordering computes a Consensus Ordering as part of the Belief Merge Function (See Merkle: Pg. 3, Section D – “CRDTs are data types which provide strong eventual consistency among different replicas in a distributed system by requiring certain properties from the state and/or the operations that modify it. Additionally, CRDTs also feature monotonicity. The concept of monotonicity applied to data types is the notion that every update is an inflation, making the state grow, not in size, but in respect to a previous state. This implies that there will always be an order between states”, See Merkle: Pg. 3-4, Section D – “There are two prominent types of CRDTs: state-based and operation-based CRDTs. In state-based CRDTs, all the states in the system —that is, the states in different replicas and different moments— form a monotonic join-semilattice. That means that, for any two states X and Y , both can be ”joined” (merged, or form a union) (⊔) and the result is a new state corresponding to the Least-Upper-Bound (LUB) of the two”).
Regarding Claims 8 and 25, the combination discloses:
further comprising: assigning a Stake to Peers; a procedure for Stake Weighted Ordering Merge included as part of the Computation of Consensus Ordering; wherein the Stake Weighted Ordering Merge is utilized to resolve conflicts between Orderings proposed by different Peers (See Merkle: pg. 3, right column – “Logical clocks are representations of causal histories [12] and provide a partial ordering between events. That is, given two events a and b, logical clocks should be able to tell us if a happened before b (a → b), or vice-versa (b → a), or if both a and b happened concurrently (a b).”, See Merkle: pg. 2, right column – “Eventual Consistency (EC) in distributed systems refers to the situation where the state may not be the same across replicas of the system but, given enough time and perhaps after network partitions, downtime and other eventualities have been resolved, the system design will ensure that the state becomes the same everywhere.”).
Regarding Claims 9 and 26, the combination discloses:
further comprising: Common Prefix Computation; wherein the computation of a Common Prefix between Orderings is utilized to reduce the computational costs for Consensus (See Merkle: pg. 4, right column – “ChronoSync [35] is utilising the features of the NamedData Networking architecture [34] to synchronise state between different datasets. ChronoSync is a data-layer mechanism, which, however, takes advantage of the hierarchical and flexible naming scheme that NDN is building on. Inspired by Merkle Trees, ChronoSync is using cryptographic digests and filters to synchronise datasets between peers. ChronoSync takes advantage of the name-based nature of the underlying network (NDN) and is assigning a unique publishing prefix to each peer. This unique prefix, together with sequence numbers and network layer persisting/long-lived “Interest packets” is replacing much of what other approaches attempt to do with clocks and CRDTs. While integrating sync functionality at the network layer allows for more native designs, some features are inevitably lost. For example, ChronoSync cannot deal with simultaneous (concurrent) data publication. RoundSync [32] is partially solving this problem by splitting the sycnhronisation process in rounds.”).
Claim(s) 16 and 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Merkle in view of Zamora in further view of Mishra (US 11121859 B1).
Regarding Claims 16 and 33, Merkle and Zamora discloses the system of claim 1 but fails to explicitly disclose:
further comprising: Trusted Code Execution arranged to be part of the State Transition Function; wherein the Trusted Code Execution can be utilized to implement Smart Contracts or other programmable functionality that may affect the Consensus State.
However, in a similar field of endeavor, Mishra discloses:
further comprising: Trusted Code Execution arranged to be part of the State Transition Function; wherein the Trusted Code Execution can be utilized to implement Smart Contracts or other programmable functionality that may affect the Consensus State (See Mishra: col. 7-8, lines 66-67 and 1-19 – “To trigger generation of the proposed block 14, the attribution consensus system 100 may provide information to the blockchain network 2 indicating occurrence of the particular action described above. As an example, the attribution consensus system 100 may execute particular software (e.g., trusted code), which can interact with the blockchain network 2. The particular software may represent an oracle and the attribution consensus system 100 may communicate with a smart contract associated with the blockchain network 2. The smart contract may receive information from the attribution consensus system 100, and evaluate the information to cause triggering of proposed blocks. The received information may indicate occurrence of the particular action, and the smart contract may confirm the validity of the information. For example, the system 100 may sign the message, such as via public key/private key encryption. Upon validation of the received information, the smart contract may cause information to be provided to the attribution servers 110A-110D causing generation of block proposals 112A-112D.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the system of Merkle to additionally implement blockchain consensus via a trusted smart contract as disclosed by Mishra yielding the predictable result of an increase in the security strength of the invention by leveraging the use of only trusted computer code.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS K PHAN/Examiner, Art Unit 3699
/COURTNEY P JONES/Primary Examiner, Art Unit 3699