DETAILED ACTION
This action is in response to new application titled “DISTRIBUTED LEDGER APPLIANCE AND METHODS OF USE” filed 9/17/2019. Claims 1-9 and 14-24 are pending.
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 9/10/2024 and 10/09/0224 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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:
creating an ad hoc network between at least a first ledger appliance and a second 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 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);
negotiating one or more blockchain parameters between at least the first ledger appliance and the second ledger appliance (see Smith 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 proof-of-work at the first ledger appliance 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 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:
communicating, over an ad hoc network, with a second 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 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);
negotiating, with the second ledger appliance, one or more blockchain parameters (see Smith 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, based on the one or more blockchain parameters, a proof-of-work schema (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, based on the proof-of-work schema, proof-of-work at the first ledger appliance (See figure 5 element 508 and paragraph 0064 i.e....the broker 108-116 performs the PoW function to determine a result); and
transmitting, to the second ledger appliance, the proof-of-work (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: create an ad hoc network between at least the first ledger appliance and a second ledger appliance; negotiate, between at least the first ledger appliance and the second ledger appliance, at least one blockchain parameter; determine a proof-of-work schema at the first ledger appliance based on the at least one blockchain parameter; mine proof-of-work at the first ledger appliance based on the proof-of-work schema; and transmit the proof-of-work to the second ledger appliance.
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 the 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 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights