DETAILED ACTION
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 8/26/2026 has been entered.
This action is in response to arguments filed 3/3/2026. Claims 1-9 and 14-24 are pending with claims 5, 18, 22 and 24 having been amended.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/26/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed 3/3/2026 have been fully considered.
Applicant's arguments with respect to the 35 U.S.C. 102(a)(2) rejection of claim 1 that Smith et al do not disclose “negotiating between at least a first ledger appliance configured to mine proof-of-work and a second ledger appliance configured to receive the proof-of-work, one or more blockchain parameters for mining the proof-of-work” have been fully considered but they are not persuasive.
Smith teaches “negotiating between at least a first ledger appliance configured to mine proof-of-work and a second ledger appliance configured to receive the proof-of-work, one or more blockchain parameters for mining the proof-of-work” in paragraph 0056 i.e. At 412, the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc., based on an increase or decrease in message delivery time (e.g., egress and/or ingress latency) to the subscriber 118. In certain examples, system 100 behavior can be monitored over a period of time (e.g., a day, a week, several weeks, etc.) to determine whether a correction factor (e.g., d, r, c, etc.) is warranted and to what extent the correction factor is to be applied. For example, if a broker 108-116 completes its PoW more quickly than others, the difficulty correction factor d can be applied to correct for the disparity. In certain examples, the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116".
This clearly states the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116 and is a collective decision among the brokers 108-116. Also see figure 1 and paragraphs 0028-0030. The 'PoW algorithm’ corresponds to the ‘one or more blockchain parameters’ of the present invention and the different brokers 108-116 corresponds to the ‘first ledger appliance’ and the ‘second ledger appliance’.
Also see paragraphs 0047-0049 i.e. certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.). The PoW processor 306 computes a PoW function associated with the broker 108 and/or the particular message, etc. The PoW function can vary based on the capability of the processor 306, the available communication mechanism(s) 310, etc. Once the PoW processor 306 has computed the hash, the hash can be verified by the broker 108 (e.g., based on content in the ledger module 304) and/or other broker 110-116 in the system 100. Using the PoW processor 306 and the ledger module 304, the PoW for the broker 108 and/or a PoW calculated by another broker 110-116 can be verified.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4-6, 14, 17-19, 21 and 24 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Smith et al (US 2018/0287915).
With respect to claim 1 Smith teaches the method, comprising:
negotiating between at least a first ledger appliance configured to mine proof-of-work and a second ledger appliance configured to receive the proof-of-work, one or more blockchain parameters for mining the proof-of-work (see Smith paragraphs 0056 i.e. At 412, the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc., based on an increase or decrease in message delivery time (e.g., egress and/or ingress latency) to the subscriber 118. In certain examples, system 100 behavior can be monitored over a period of time (e.g., a day, a week, several weeks, etc.) to determine whether a correction factor (e.g., d, r, c, etc.) is warranted and to what extent the correction factor is to be applied. For example, if a broker 108-116 completes its PoW more quickly than others, the difficulty correction factor d can be applied to correct for the disparity. In certain examples, the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116, paragraphs 0047-0049 i.e. certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.). The PoW processor 306 computes a PoW function associated with the broker 108 and/or the particular message, etc. The PoW function can vary based on the capability of the processor 306, the available communication mechanism(s) 310, etc. Once the PoW processor 306 has computed the hash, the hash can be verified by the broker 108 (e.g., based on content in the ledger module 304) and/or other broker 110-116 in the system 100. Using the PoW processor 306 and the ledger module 304, the PoW for the broker 108 and/or a PoW calculated by another broker 110-116 can be verified and paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers..."; the 'PoW algorithm’ of D1 corresponds to the ‘one or more blockchain parameters’ of the present invention);
determining a proof-of-work schema at the first ledger appliance based on the one or more blockchain parameters (See Smith figure 5 element 512 and paragraph 0056 i.e. the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc. and paragraphs 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback);
mining, by the first ledger appliance, the proof-of-work based on the proof-of-work schema (See figure 5 element 508 and paragraph 0064 i.e....the broker 108-116 performs the PoW function to determine a result); and
transmitting the proof-of-work mined by the first ledger appliance to the second ledger appliance (Smith paragraph 0064 i.e. The result can be verified by the broker 108-116 performing the PoW calculation and/or by another broker 108-116 monitoring the result; it is clear from this passage of D1 that for another broker to verify the PoW calculation result, the result must be transmitted to the other broker).
With respect to claim 4 Smith teaches the method of claim 1, further comprising: providing, responsive to discovering a third ledger appliance, the one or more blockchain parameters to the third ledger appliance; and forming a community of ledger appliances from the first ledger appliance, the second ledger appliance, and the third ledger appliance (see Smith paragraph 0028 i.e. FIG. 1 depicts an example system conceptual model of a network 100 in which a set of (see Smith paragraph 0028 i.e. FIG. 1 depicts an example system conceptual model of a network 100 in which a set of publishers 102, 104, 106 produce messages (e.g., stock ticker messages m1, m2, m3, etc.), respectively, that are shared among a collection of broker nodes 108, 110, 112, 114, 116 forming a blockchain in which some of the broker nodes 108-116 host subscribers 118, 120, 122 that subscribe to a subset of the ticker messages m1, m2, m3)publishers 102, 104, 106 produce messages (e.g., stock ticker messages m1, m2, m3, etc.), respectively, that are shared among a collection of broker nodes 108, 110, 112, 114, 116 forming a blockchain in which some of the broker nodes 108-116 host subscribers 118, 120, 122 that subscribe to a subset of the ticker messages m1, m2, m3).
With respect to claim 5 Smith teaches the method of claim 4, further comprising: receiving a proposed proof-of-work from the third ledger appliance; validating the proposed proof-of-work; and adding the proposed proof-of-work to a blockchain data structure based on that the community of ledger appliances achieve consensus on validity of the proposed proof-of-work (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 6 Smith teaches the method of claim 5, further comprising: settling, based on the blockchain data structure, one or more transactions with a trusted database (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 14 Smith teaches a non-transitory computer storage medium storing instructions which, when executed on a first ledger appliance, causes the first ledger appliance to perform a method, comprising:
negotiating between at least a first ledger appliance configured to mine proof-of-work and a second ledger appliance configured to receive the proof-of-work, one or more blockchain parameters for mining the proof-of-work (see Smith paragraphs 0056 i.e. At 412, the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc., based on an increase or decrease in message delivery time (e.g., egress and/or ingress latency) to the subscriber 118. In certain examples, system 100 behavior can be monitored over a period of time (e.g., a day, a week, several weeks, etc.) to determine whether a correction factor (e.g., d, r, c, etc.) is warranted and to what extent the correction factor is to be applied. For example, if a broker 108-116 completes its PoW more quickly than others, the difficulty correction factor d can be applied to correct for the disparity. In certain examples, the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116, paragraphs 0047-0049 i.e. certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.). The PoW processor 306 computes a PoW function associated with the broker 108 and/or the particular message, etc. The PoW function can vary based on the capability of the processor 306, the available communication mechanism(s) 310, etc. Once the PoW processor 306 has computed the hash, the hash can be verified by the broker 108 (e.g., based on content in the ledger module 304) and/or other broker 110-116 in the system 100. Using the PoW processor 306 and the ledger module 304, the PoW for the broker 108 and/or a PoW calculated by another broker 110-116 can be verified and paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers..."; the 'PoW algorithm’ of D1 corresponds to the ‘one or more blockchain parameters’ of the present invention);
determining a proof-of-work schema at the first ledger appliance based on the one or more blockchain parameters (See Smith figure 5 element 512 and paragraph 0056 i.e. the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc. and paragraphs 0067-0068 i.t. the PoW for the broker 108-116 can be adjusted based on the feedback);
mining, by the first ledger appliance, the proof-of-work based on the proof-of-work schema (See figure 5 element 508 and paragraph 0064 i.e....the broker 108-116 performs the PoW function to determine a result); and
transmitting the proof-of-work mined by the first ledger appliance to the second ledger appliance (Smith paragraph 0064 i.e. The result can be verified by the broker 108-116 performing the PoW calculation and/or by another broker 108-116 monitoring the result; it is clear from this passage of D1 that for another broker to verify the PoW calculation result, the result must be transmitted to the other broker).
With respect to claim 17 Smith teaches the non-transitory computer storage medium of claim 14, wherein the method further comprises: providing, responsive to discovering a third ledger appliance, the one or more blockchain parameters to the third ledger appliance to form a community of ledger appliances from the first ledger appliance, the second ledger appliance, and the third ledger appliance (see Smith paragraph 0028 i.e. FIG. 1 depicts an example system conceptual model of a network 100 in which a set of (see Smith paragraph 0028 i.e. FIG. 1 depicts an example system conceptual model of a network 100 in which a set of publishers 102, 104, 106 produce messages (e.g., stock ticker messages m1, m2, m3, etc.), respectively, that are shared among a collection of broker nodes 108, 110, 112, 114, 116 forming a blockchain in which some of the broker nodes 108-116 host subscribers 118, 120, 122 that subscribe to a subset of the ticker messages m1, m2, m3)publishers 102, 104, 106 produce messages (e.g., stock ticker messages m1, m2, m3, etc.), respectively, that are shared among a collection of broker nodes 108, 110, 112, 114, 116 forming a blockchain in which some of the broker nodes 108-116 host subscribers 118, 120, 122 that subscribe to a subset of the ticker messages m1, m2, m3).
With respect to claim 18 Smith teaches the non-transitory computer storage medium of claim 17, wherein the method further comprises: receiving a proposed proof-of-work from the third ledger appliance; validating the proposed proof-of-work; and adding the proposed proof-of-work to a blockchain data structure based on consensus on validity of the proposed proof-of-work (see Smith paragraph 0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 19 Smith teaches the non-transitory computer storage medium of claim 18, wherein the method further comprises: settling, based on the blockchain data structure, one or more transactions with a trusted database (see Smith paragraph 0046-0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
With respect to claim 21 Smith teaches an apparatus, comprising: a processor; at least one characterized memory configured to provide a first performance with a first operating parameter; and a non-transitory computer readable medium storing instructions programmed to configure the processor to implement a first ledger appliance to: negotiate between at least a first ledger appliance configured to mine proof-of-work and a second ledger appliance configured to receive the proof-of-work, one or more blockchain parameters for mining the proof-of-work (see Smith paragraphs 0056 i.e. At 412, the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc., based on an increase or decrease in message delivery time (e.g., egress and/or ingress latency) to the subscriber 118. In certain examples, system 100 behavior can be monitored over a period of time (e.g., a day, a week, several weeks, etc.) to determine whether a correction factor (e.g., d, r, c, etc.) is warranted and to what extent the correction factor is to be applied. For example, if a broker 108-116 completes its PoW more quickly than others, the difficulty correction factor d can be applied to correct for the disparity. In certain examples, the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers 108-116, so the generation and application of the difficulty correction factor d to a particular broker 1-8-116 is a collective decision among the brokers 108-116, paragraphs 0047-0049 i.e. certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.). The PoW processor 306 computes a PoW function associated with the broker 108 and/or the particular message, etc. The PoW function can vary based on the capability of the processor 306, the available communication mechanism(s) 310, etc. Once the PoW processor 306 has computed the hash, the hash can be verified by the broker 108 (e.g., based on content in the ledger module 304) and/or other broker 110-116 in the system 100. Using the PoW processor 306 and the ledger module 304, the PoW for the broker 108 and/or a PoW calculated by another broker 110-116 can be verified and paragraph 0056 i.e. the PoW algorithm for a given broker 108-116 is jointly approved by all the brokers..."; the 'PoW algorithm’ of D1 corresponds to the ‘one or more blockchain parameters’ of the present invention);
determine a proof-of-work schema at the first ledger appliance based on the one or more blockchain parameters (See Smith figure 5 element 512 and paragraph 0056 i.e. the PoW algorithm can be adjusted based on the feedback. For example, a difficulty correction factor, d, a random adjustment factor, r, and/or a control value, c, can be added, removed, adjusted, etc. and paragraphs 0067-0068 i.e. the PoW for the broker 108-116 can be adjusted based on the feedback);
mine by the first ledger appliance, the proof-of-work based on the proof-of-work schema (See figure 5 element 508 and paragraph 0064 i.e....the broker 108-116 performs the PoW function to determine a result); and
transmit the proof-of-work mined by the first ledger appliance to the second ledger appliance (Smith paragraph 0064 i.e. The result can be verified by the broker 108-116 performing the PoW calculation and/or by another broker 108-116 monitoring the result; it is clear from this passage of D1 that for another broker to verify the PoW calculation result, the result must be transmitted to the other broker).
With respect to claim 24 Smith teaches the apparatus of claim 21, wherein the first ledge appliance is further configured to: provide, responsive to discovering a third ledger appliance, the at least one blockchain parameter to the third ledger appliance; receive a proposed proof-of-work from the third ledger appliance; validate the proposed proof-of-work; and add the proposed proof-of-work to a blockchain data structure based on that a community of ledger appliances achieve consensus on validity of the proposed proof-of-work (see Smith paragraph 0047 i.e. In certain examples, brokers 108-116 can validate new messages and/or other message updates according to a validation protocol. For example, the validation protocol defines a process by which devices (e.g., brokers 108-122) of the computer network 100 agree on changes and/or additions to the distributed ledger 304. For example, the validation protocol may include the proof-of-work (PoW) protocol and/or other public consensus protocol, private validation protocol, custom validation protocol, etc. The distributed ledger 304 enables brokers 108-122 in the computer network 100 to agree, via the verification protocol, on the validity and timeliness of a message to subscriber(s) 118-122 and/or other additions to the distributed ledger (e.g., to include updates, to delete updates, to reject updates, etc.)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 3, 7-9, 15, 16, 20, 22 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Smith et al (US 2018/0287915) in view of Madisetti et al (US 2019/0018888).
With respect to claim 2 Smith teaches the method of claim 1, but does not disclose wherein the negotiating of the one or more blockchain parameters includes a prioritization of at least one of: scalability, security and immutability.
Madisetti teaches wherein the negotiating of the one or more blockchain parameters includes a prioritization of at least one of: scalability, security and immutability (see Madisetti paragraphs 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc∝(1/L.sub.D).sup.a∝(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 3 Smith teaches the method of claim 2, but does not disclose wherein the negotiating of the one or more blockchain parameters further includes a de-prioritization of at least one of: scalability, security and immutability.
Madisetti teaches wherein the negotiating of the one or more blockchain parameters further includes a de-prioritization of at least one of: scalability, security and immutability (see Madisetti paragraphs 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc∝(1/L.sub.D).sup.a∝(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 7 Smith teaches the method of claim 6, but does not disclose wherein the one or more blockchain parameters ensure a minimum security of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum security of the blockchain data structure (see Madisetti paragraphs 0116 i.e. Referring now to FIG. 4, for example, and without limitation, the decentralization, scalability and security parameters and paragraphs 0137-0140 i.e. The level of Security (L.sub.Se) is quantified in terms of the following blockchain parameters 254: [0135] S.sub.r: Stale block rate 276; and [0136] Tb.sub.p: Block propagation delay 278. [0137] The level of Security (L.sub.Se) is specified as:
L.sub.Se=fn(S.sub.r, T.sub.bp) [0138] where: 0<=L.sub.Se<=0 [0139] L.sub.Se=0: No security [0140] L.sub.Se=10: Highly secure ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 8 Smith teaches the method of claim 6, but does not disclose wherein the one or more blockchain parameters ensure a minimum scalability of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum scalability of the blockchain data structure (see Madisetti paragraphs 0116 i.e. Referring now to FIG. 4, for example, and without limitation, the decentralization, scalability and security parameters and paragraphs 0127-0133 i.e. The level of Scalability (L.sub.Sc) is quantified in terms of the following blockchain parameters 252: [0128] P.sub.tx: Transaction throughput 272; and [0129] T.sub.tx: Transaction latency 274. [0130] The level of Scalability (L.sub.Sc) is specified as: L.sub.Sc=fn(P.sub.tx, T.sub.tx) [0131] where: 0<=L.sub.Sc<=10 [0132] L.sub.Sc=0: No scalability [0133] L.sub.Sc=10: Highly scalable).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 9 Smith teaches the method of claim 6, but does not disclose wherein the one or more blockchain parameters ensure a minimum immutability of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum immutability of the blockchain data structure
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 15 Smith teaches the non-transitory computer storage medium of claim 14, wherein the negotiating of the one or more blockchain parameters includes a prioritization of at least one of: scalability, security and immutability.
Madisetti teaches wherein the negotiating of the one or more blockchain parameters includes a prioritization of at least one of: scalability, security and immutability (see Madisetti paragraphs 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc∝(1/L.sub.D).sup.a∝(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 16 Smith teaches the non-transitory computer storage medium of claim 15, wherein the negotiating of the one or more blockchain parameters further includes a de-prioritization of at least one of: scalability, security and immutability.
Madisetti teaches wherein the negotiating of the one or more blockchain parameters further includes a de-prioritization of at least one of: scalability, security and immutability (see Madisetti paragraphs 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc∝(1/L.sub.D).sup.a∝(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 20 Smith teaches the non-transitory computer storage medium of claim 18, wherein the one or more blockchain parameters ensure a minimum security, scalability, or immutability of the blockchain data structure.
Madisetti teaches wherein the one or more blockchain parameters ensure a minimum security, scalability, or immutability of the blockchain data structure (see Madisetti paragraphs 0116 i.e. Referring now to FIG. 4, for example, and without limitation, the decentralization, scalability and security parameters and paragraphs 0137-0140 i.e. The level of Security (L.sub.Se) is quantified in terms of the following blockchain parameters 254: [0135] S.sub.r: Stale block rate 276; and [0136] Tb.sub.p: Block propagation delay 278. [0137] The level of Security (L.sub.Se) is specified as: L.sub.Se=fn(S.sub.r, T.sub.bp) [0138] where: 0<=L.sub.Se<=0 [0139] L.sub.Se=0: No security [0140] L.sub.Se=10: Highly secure).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 22 Smith teaches the apparatus of claim 21, but does not disclose wherein negotiating of the at least one blockchain parameter includes a prioritization of at least one of: scalability, security and immutability.
Madisetti teaches wherein the negotiating of the one or more blockchain parameters includes a prioritization of at least one of: scalability, security and immutability (see Madisetti paragraphs 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc∝(1/L.sub.D).sup.a∝(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
With respect to claim 23 Smith teaches the apparatus of claim 22, but does not disclose wherein the negotiating of the at least one blockchain parameter further includes a de-prioritization of at least one of: scalability, security and immutability.
Madisetti teaches wherein the negotiating of the one or more blockchain parameters further includes a de-prioritization of at least one of: scalability, security and immutability (see Madisetti paragraphs 0111-0113 i.e. The levels of Decentralization (L.sub.D), Scalability (L.sub.Sc) and Security (L.sub.Se) for blockchain networks are tunable subject to the following constraints: L.sub.Sc∝(1/L.sub.D).sup.a∝(1/L.sub.Se).sup.b. where exponents a and b are dependent on the blockchain platform. The Decentralization, Scalability and Security (DSS) constraints according to an embodiment of the present invention are described as follows: Scalability and Security: The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases 214. For example, a scaling-up measure such as reducing block interval period (to decrease transaction latency) reduces the level of security due to larger number of stale blocks being produced which do not contribute to the network security. Inversely, as scalability decreases, security increases 212).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Smith in view of Madisetti to have tuned the blockchain network to prioritization scalability or security based of the needs of the blockchain. The level of scalability in a blockchain network is inversely proportional to the level of security. If a blockchain network is scaled-up to increase transaction throughput or decrease transaction latency, the level of security of the network decreases. Inversely, as scalability decreases, security increases (see Madisetti paragraphs 0111-0113). Therefore one would have been motivated to have prioritized at least one of: scalability, security.
Prior Art
Kinnaird et al (US 2018/0144340) titled “TRIGGERING ACTIONS RESPONSIVE TO BLOCKCHAIN TRANSACTIONS”.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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://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).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492
Prosecution Insights