DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The IDS filed on 10/03/2024 and 09/25/2025 has been considered.
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-4, 6-15, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
As per claim 1, in step 1 of the 101 analysis, the examiner has determined that the claim
is directed to a system. Therefore, the claim is directed to one of the four statutory categories of
invention.
In step 2A prong 1 of the 101 analysis, the examiner has determined that the claim recites
a judicial exception. Specifically, the limitation "that preferentially allocates computing resources from the set of shared computing resources to participating blockchain nodes, from the set of blockchain nodes, participating in blockchain consensus on a blockchain associated with the respective blockchain node” recites a mental process. Humans can mentally assign resources to participating blockchain nodes.
In step 2A prong 2 of the 101 analysis, the examiner has determined that the additional
elements, alone or in combination do not integrate the judicial exceptions into a practical
application for the following rationale:
The limitations "a set of shared computing resources; a set of blockchain nodes executing on the set of shared computing resources; and a management system" apply judicial exceptions on a generic computer. "Alappat 's rationale that an otherwise ineligible algorithm or software could be made patent-eligible by merely adding a generic computer to the claim was superseded by the Supreme Court's Bilski and Alice Corp. decisions" so therefore applying judicial exceptions on a set of shared computing resources, a set of blockchain nodes, and a management system which are generic computers does not integrate the judicial exceptions into a practical application (MPEP 2106.05(b)).
In step 2B of the 101 analysis, the examiner has determined that the additional elements, alone or in combination do not recite significantly more than the abstract ideas identified above for the following rationale:
The limitations "a set of shared computing resources; a set of blockchain nodes executing on the set of shared computing resources; and a management system" apply judicial exceptions on a generic computer and therefore do not provide significantly more.
As per claim 2, it recites a mental process.
As per claim 3, it recites a mental process and a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 4, it recites a mental process and an attribute of the technological environment that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 6, it recites a mental process and a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 7, it recites a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 8, it recites an attribute of the technological environment that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 9, it recites a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 10, it is rejected for similar reasons that claim 1 is rejected for.
As per claim 11, it recites an attribute of the technological environment that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 12, it recites a mental process.
As per claim 13, it recites a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 14, it recites a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 15, it recites a mental process.
As per claim 17, it recites an attribute of the technological environment that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 18, it recites a mental process and an attribute of the technological environment that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 19, it recites an attribute of the technological environment that neither integrates the judicial exception into a practical application nor recites significantly more.
As per claim 20, it recites a mental process and a generic computing component that neither integrates the judicial exception into a practical application nor recites significantly more.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 1 and 10 (line numbers refer to claim 1):
Line 8 recites “the respective blockchain node” but it is unclear what this refers to.
Claims 2-9 and 11-20 are dependent claims of claims 1 and 10, and fail to resolve the deficiencies of claims 1 and 10, so they are rejected for the same reasons.
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 1-5, 7, 8, 10-16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US 20210152656 A1 hereinafter Wang) in view of Thaw et al. (US 20220129475 A1 hereinafter Thaw).
As per claim 1, Wang teaches the invention substantially as claimed including a system, comprising: a set of shared computing resources (Abstract It may also share storage for nodes; [0088] then the first server 3a is automatically instructed and/or automatically forced to destroy (or remove or temporary remove or transfer or temporarily transfer or etc.) a resource (e.g., 1b.sub.1) and is automatically instructed and/or automatically forced to shift that resource to the second server 3x; ); a set of blockchain nodes executing on the set of shared computing resources (abstract A system and method for enabling users to operate multiple blockchain (or distributed ledger) nodes efficiently, at a much lower cost, etc. For example, when one blockchain starts to take up resources, the system can automatically adjust by looking at the application container layer to see if it is possible to shift resources. It can also shift resources at the server layer to adjust for computation and memory resources to, for example, increase efficiency. It may also share storage for nodes); and preferentially allocates computing resources from the set of shared computing resources to participating blockchain nodes, from the set of blockchain nodes, participating in blockchain consensus on a blockchain associated with the respective blockchain node ([0088] For example, in the Figures e.g., in at least FIG. 3, when it is automatically determined that a second server like server 3x (e.g., a Virtual Machine 3x) has available resources and/or it is automatically determined that a first server like server 3a (e.g., a Virtual Machine 3a) does not have (any or enough) available resources and/or it is automatically determined that the first server needs additional resources and/or it is automatically determined that the second server has a certain predetermined % of available resources more than the first server (e.g., the second server has 20% or more available resources more than the first server), etc., then the first server 3a is automatically instructed and/or automatically forced to destroy (or remove or temporary remove or transfer or temporarily transfer or etc.) a resource (e.g., 1b.sub.1) and is automatically instructed and/or automatically forced to shift that resource to the second server 3x. [0089] It should be noted that while it is disclosed (e.g., in the example above) that the resource 1b.sub.1 is destroyed, any resource(s) may be determined to be destroyed (removed, transferred, etc.). For example, it may be determined to destroy one resource vs another based on resource efficiency (e.g., if a first resource is taking up more (or a lot more) resources and a second resource can fit more optimally somewhere else, then the second resource should be the resource that should be moved. Alternatively, or used in conjunction with other criteria (e.g., resource efficiency), it may be determined to destroy one resource vs another based on peak bandwidth for different ledgers. For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc; [0008] Because the dedicated amount of compute resources to validate increases the probability of getting a Bitcoin reward, the consensus model is called “Proof of Work”; [0109] Blockchain systems are responsible for validating transactions, and sometimes during times of validating transactions, systems are required not to have any downtime. Accordingly, by monitoring the blockchain system, e.g., monitoring for when the blockchain system is responsible for something (e.g., preforming validation, executing function(s), allocating resources, calculating system requirements, etc.), this system can determine when it is acceptable (or more beneficial) to schedule maintenance and/or downtime, or a moment(s) to shift resource(s) for any of the situations disclosed herewith; Validation involves blockchain consensus mechanisms.).
Wang fails to teach a management system that preferentially allocates computing resources from the set of shared computing resources.
However, Thaw teaches a management system that preferentially allocates computing resources from the set of shared computing resources ([0039] the execution layer 205 comprises a resource manager 310 for tracking and verifying distributed computational, storage and memory resources, allocating these resources to different components and nodes in the GPB ecosystem, scheduling and monitoring resources according to demand and resource availability).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wang with the teachings of Thaw to better schedule and monitor resources (see Thaw [0039] resource manager 310 for tracking and verifying distributed computational, storage and memory resources, allocating these resources to different components and nodes in the GPB ecosystem, scheduling and monitoring resources according to demand and resource availability).
As per claim 2, Wang and Thaw teach the system of claim 1. Wang teaches wherein preferentially allocating computing resources to a participating blockchain node comprises increasing a computing resource for the participating blockchain node ([0089] It should be noted that while it is disclosed (e.g., in the example above) that the resource 1b.sub.1 is destroyed, any resource(s) may be determined to be destroyed (removed, transferred, etc.). For example, it may be determined to destroy one resource vs another based on resource efficiency (e.g., if a first resource is taking up more (or a lot more) resources and a second resource can fit more optimally somewhere else, then the second resource should be the resource that should be moved. Alternatively, or used in conjunction with other criteria (e.g., resource efficiency), it may be determined to destroy one resource vs another based on peak bandwidth for different ledgers. For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc; [0109] Blockchain systems are responsible for validating transactions, and sometimes during times of validating transactions, systems are required not to have any downtime. Accordingly, by monitoring the blockchain system, e.g., monitoring for when the blockchain system is responsible for something (e.g., preforming validation, executing function(s), allocating resources, calculating system requirements, etc.), this system can determine when it is acceptable (or more beneficial) to schedule maintenance and/or downtime, or a moment(s) to shift resource(s) for any of the situations disclosed herewith.).
Additionally, Thaw teaches increasing a computing resource priority for the participating blockchain node ([0036] PoRt operates in similar way as a proof-of-authority (PoA) network with a threshold, where only nodes with a sufficiently high rating can sign and validate objects. In general, a more positive rating connotes a more trusted and active participant.).
As per claim 3, Wang and Thaw teach the system of claim 1. Wang teaches identifies the participating blockchain nodes by: determining a set of consensus participants for each of a set of blockchains associated with the set of blockchain nodes; and identifying blockchain nodes from the set of blockchain nodes within the sets of consensus participants ([0089] For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like; [0008] Because the dedicated amount of compute resources to validate increases the probability of getting a Bitcoin reward, the consensus model is called “Proof of Work”; [0109] Blockchain systems are responsible for validating transactions, and sometimes during times of validating transactions, systems are required not to have any downtime. Accordingly, by monitoring the blockchain system, e.g., monitoring for when the blockchain system is responsible for something (e.g., preforming validation, executing function(s), allocating resources, calculating system requirements, etc.), this system can determine when it is acceptable (or more beneficial) to schedule maintenance and/or downtime, or a moment(s) to shift resource(s) for any of the situations disclosed herewith; Validation involves blockchain consensus mechanisms).
Additionally, Thaw teaches management system identifies the participating blockchain nodes ([0039] the execution layer 205 comprises a resource manager 310 for tracking and verifying distributed computational, storage and memory resources, allocating these resources to different components and nodes in the GPB ecosystem, scheduling and monitoring resources according to demand and resource availability; page 3 table Light Node Purposes Benefit from participation in the GPB platform).
As per claim 4, Wang and Thaw teach the system of claim 1. Wang teaches wherein the participating blockchain nodes are participants in an upcoming blockchain consensus, wherein the computing resources are allocated to the participating blockchain nodes before the upcoming blockchain consensus ([0080] For example, in the Figures e.g., in at least FIG. 2, 2a represents a docker container hosting Tezo blockchain for Owner 1's (Jeff's) server 3a. When server 3a determines that 2a has available resources (e.g., due to low requirements for bandwidth, and/or due to a period of time where 1a.sub.1 is not required to take action, and/or etc.), server 3a automatically allocates (some of or all of) the resources of 2a to 2b. For example, server 3a automatically allocates CPU resources and/or RAM resources and/or a certain % of capacity (e.g., a certain % of memory capacity) of 2a to 2b so that 1b.sub.1 can utilize for example the extra computation power that 2b needs to host Harmony blockchain; [0088] For example, in the Figures e.g., in at least FIG. 3, when it is automatically determined that a second server like server 3x (e.g., a Virtual Machine 3x) has available resources and/or it is automatically determined that a first server like server 3a (e.g., a Virtual Machine 3a) does not have (any or enough) available resources and/or it is automatically determined that the first server needs additional resources and/or it is automatically determined that the second server has a certain predetermined % of available resources more than the first server (e.g., the second server has 20% or more available resources more than the first server), etc., then the first server 3a is automatically instructed and/or automatically forced to destroy (or remove or temporary remove or transfer or temporarily transfer or etc.) a resource (e.g., 1b.sub.1) and is automatically instructed and/or automatically forced to shift that resource to the second server 3x. [0089] It should be noted that while it is disclosed (e.g., in the example above) that the resource 1b.sub.1 is destroyed, any resource(s) may be determined to be destroyed (removed, transferred, etc.). For example, it may be determined to destroy one resource vs another based on resource efficiency (e.g., if a first resource is taking up more (or a lot more) resources and a second resource can fit more optimally somewhere else, then the second resource should be the resource that should be moved. Alternatively, or used in conjunction with other criteria (e.g., resource efficiency), it may be determined to destroy one resource vs another based on peak bandwidth for different ledgers. For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like; [0008] Because the dedicated amount of compute resources to validate increases the probability of getting a Bitcoin reward, the consensus model is called “Proof of Work”;).
As per claim 5, Wang and Thaw teach the system of claim 1. Wang teaches wherein each blockchain node executes in a different virtual machine executing on the set of shared computing resources, preferentially allocates computing resources from the set of shared computing resources to the respective virtual machine executing the participating blockchain nodes ([0076] Accordingly, the disclosure describes a system and method for at least supporting for multiple node runners. FIG. 1 for example describes the system and method at a high-level, with blockchains living on application containers, and living on top of virtual machines; [0088] For example, in the Figures e.g., in at least FIG. 3, when it is automatically determined that a second server like server 3x (e.g., a Virtual Machine 3x) has available resources and/or it is automatically determined that a first server like server 3a (e.g., a Virtual Machine 3a); abstract It may also share storage for nodes; [0089] It should be noted that while it is disclosed (e.g., in the example above) that the resource 1b.sub.1 is destroyed, any resource(s) may be determined to be destroyed (removed, transferred, etc.). For example, it may be determined to destroy one resource vs another based on resource efficiency (e.g., if a first resource is taking up more (or a lot more) resources and a second resource can fit more optimally somewhere else, then the second resource should be the resource that should be moved. Alternatively, or used in conjunction with other criteria (e.g., resource efficiency), it may be determined to destroy one resource vs another based on peak bandwidth for different ledgers. For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc; [0073] In this example, all of the first Owner's (Jeff's) blockchains (identified by “i”) and corresponding storage of the ledger are located on Virtual Machine 3a, for 3x).
Additionally, Thaw teaches wherein the management system preferentially allocates computing resources from the set of shared computing resources ([0039] the execution layer 205 comprises a resource manager 310 for tracking and verifying distributed computational, storage and memory resources, allocating these resources to different components and nodes in the GPB ecosystem, scheduling and monitoring resources according to demand and resource availability).
As per claim 7, Wang and Thaw teach the system of claim 1. Wang teaches wherein the set of shared computing resources comprises a set of virtualized physical resources ([0071] Server layers (3a, . . . , 3x) may represent different server layers, e.g., a virtual machine (VM) in a cloud provider, and/or a physical server; abstract It may also share storage for nodes; [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc;).
As per claim 8, Wang and Thaw teach the system of claim 1. Wang teaches wherein the blockchain nodes within the set of blockchain nodes are associated with different blockchains ([0063] A first server layer (3a) may include for example elements 1a.sub.1, 1b.sub.1, . . . 1x.sub.1 while a second server layer (3x) may include for example elements 1a.sub.2, 1b.sub.2, . . . 1x.sub.2; where the first character (e.g., “1” of 1a.sub.1, 1b.sub.1, . . . 1x.sub.1) represents a blockchain, where the second character (e.g., “a,” “b,” . . . “x” of 1a.sub.1, 1b.sub.1, . . . 1x.sub.1) represents the types of blockchains (for example, a=Tezos, b=Harmony, x=Cosmos)).
As per claim 10, Wang teaches a system managing a set of computing resources hosting a set of blockchain nodes ([0061] FIG. 1 is a functional high-level block diagram illustrating an arrangement of an infrastructure management of multiple blockchains (for example, Tezos, Harmony, Cosmos chains, etc.); [0089] For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc); identify a set of participating blockchain nodes, from the set of blockchain nodes, participating in a blockchain event on a blockchain of the respective blockchain node; and preferentially allocate computing resources to the set of participating blockchain nodes ([0088] For example, in the Figures e.g., in at least FIG. 3, when it is automatically determined that a second server like server 3x (e.g., a Virtual Machine 3x) has available resources and/or it is automatically determined that a first server like server 3a (e.g., a Virtual Machine 3a) does not have (any or enough) available resources and/or it is automatically determined that the first server needs additional resources and/or it is automatically determined that the second server has a certain predetermined % of available resources more than the first server (e.g., the second server has 20% or more available resources more than the first server), etc., then the first server 3a is automatically instructed and/or automatically forced to destroy (or remove or temporary remove or transfer or temporarily transfer or etc.) a resource (e.g., 1b.sub.1) and is automatically instructed and/or automatically forced to shift that resource to the second server 3x. [0089] It should be noted that while it is disclosed (e.g., in the example above) that the resource 1b.sub.1 is destroyed, any resource(s) may be determined to be destroyed (removed, transferred, etc.). For example, it may be determined to destroy one resource vs another based on resource efficiency (e.g., if a first resource is taking up more (or a lot more) resources and a second resource can fit more optimally somewhere else, then the second resource should be the resource that should be moved. Alternatively, or used in conjunction with other criteria (e.g., resource efficiency), it may be determined to destroy one resource vs another based on peak bandwidth for different ledgers. For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc; [0008] Because the dedicated amount of compute resources to validate increases the probability of getting a Bitcoin reward, the consensus model is called “Proof of Work”; [0109] Blockchain systems are responsible for validating transactions, and sometimes during times of validating transactions, systems are required not to have any downtime. Accordingly, by monitoring the blockchain system, e.g., monitoring for when the blockchain system is responsible for something (e.g., preforming validation, executing function(s), allocating resources, calculating system requirements, etc.), this system can determine when it is acceptable (or more beneficial) to schedule maintenance and/or downtime, or a moment(s) to shift resource(s) for any of the situations disclosed herewith).
Wang fails to teach that it is the system managing the set of computing resources hosting the set of blockchain nodes that is identifying a set of participating blockchain nodes; and preferentially allocating computing resources.
However, Thaw teaches a system managing a set of computing resources hosting a set of blockchain nodes, wherein the system is configured to: identify a set of participating blockchain nodes; and preferentially allocate computing resources ([0036] The platform consensus handler 308 manages GPB arbitrary object ownership and facilitates the governance of the GPB platform using a proof-of-rating (PoRt) model that depends on the aggregated rating of the participants (i.e. object signer or voter) in the GPB ecosystem. Rating is computed using the participant's resource telemetries, behavior, and the validity of the participant's objects. For example, if a participant frequently asserts the correct attributes of its objects, that participant's rating would increase. Likewise, a participant who makes fraudulent assertions regarding attributes of its objects, or who frequently asserts erroneous attributes about its objects, would have the participant's rating decreased. In other words, a participant's rating is the result of contributions having intrinsic values, where such values would be diminished if her rating were to drop as a result of fraudulent activity. PoRt operates in similar way as a proof-of-authority (PoA) network with a threshold, where only nodes with a sufficiently high rating can sign and validate objects; [0039] a resource manager 310 for tracking and verifying distributed computational, storage and memory resources, allocating these resources to different components and nodes in the GPB ecosystem; pg. 3 Table Light Node Purposes Benefit from participation in the GPB platform Functions validate GPB arbitrary objects).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wang with the teachings of Thaw to better schedule and monitor resources (see Thaw [0039] resource manager 310 for tracking and verifying distributed computational, storage and memory resources, allocating these resources to different components and nodes in the GPB ecosystem, scheduling and monitoring resources according to demand and resource availability).
As per claim 11, Wang and Thaw teach the system of claim 10. Wang teaches wherein the blockchain event comprises blockchain consensus ([0004] In other words, blockchain technology is built on an ordered series of blocks that contain a set of transactions and references to the previous block. There are numerous protocols that make use of this concept to reach a consensus about a total ordering on transactions.).
As per claim 12, Wang and Thaw teach the system of claim 10. Wang teaches wherein the set of participating blockchain nodes are identified by: determining a set of activity blockchain nodes for each of a set of blockchains associated with the set of blockchain nodes; and identifying the participating blockchain nodes based on an overlap between the set of blockchain nodes and the sets of activity blockchain nodes ([0089] For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0109] Blockchain systems are responsible for validating transactions, and sometimes during times of validating transactions, systems are required not to have any downtime. Accordingly, by monitoring the blockchain system, e.g., monitoring for when the blockchain system is responsible for something (e.g., preforming validation, executing function(s), allocating resources, calculating system requirements, etc.), this system can determine when it is acceptable (or more beneficial) to schedule maintenance and/or downtime, or a moment(s) to shift resource(s) for any of the situations disclosed herewith).
As per claim 13, Wang and Thaw teach the system of claim 10. Wang teaches wherein the set of computing resources comprises a set of shared physical resources ([0071] Server layers (3a, . . . , 3x) may represent different server layers, e.g., a virtual machine (VM) in a cloud provider, and/or a physical server, and/or a hosting computer, and/or etc.). The second character (e.g., a, . . . x) of the Server layers labeling (3a, . . . , 3x) represents the (different) owners. For example, 3a may be a server owned by a first owner/owner 1 (e.g., Jeff) that hosts docker(s) e.g., 3 dockers containing Tezos, Harmony, and Cosmos while 3x may be a server owned by a second owner/owner x (e.g., Tom) that hosts docker(s) e.g., 3 dockers also containing Tezos, Harmony, and Cosmos.).
As per claim 14, Wang and Thaw teach the system of claim 10. Wang teaches wherein the set of computing resources are from a single bare metal machine ([0071] Server layers (3a, . . . , 3x) may represent different server layers, e.g., a virtual machine (VM) in a cloud provider, and/or a physical server).
As per claim 15, Wang and Thaw teach the system of claim 10. Wang teaches wherein the computing resources are preferentially allocated to the set of participating blockchain nodes by assigning ([0089] It should be noted that while it is disclosed (e.g., in the example above) that the resource 1b.sub.1 is destroyed, any resource(s) may be determined to be destroyed (removed, transferred, etc.). For example, it may be determined to destroy one resource vs another based on resource efficiency (e.g., if a first resource is taking up more (or a lot more) resources and a second resource can fit more optimally somewhere else, then the second resource should be the resource that should be moved. Alternatively, or used in conjunction with other criteria (e.g., resource efficiency), it may be determined to destroy one resource vs another based on peak bandwidth for different ledgers. For example, peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation, smart contracts processing, heavy transaction volume and/or the like. [0090] In other words, because Virtual Machine 3x has resources to utilize, Owner 1's (Jeff's) 1b.sub.1 blockchain of Harmony is (temporarily and/or permanently) destroyed and (temporarily and/or permanently) recreated (or relocated) on Virtual Machine 3x to utilize the extra resources, etc. Thus, Virtual Machine 3a is now utilizing the extra computation power, etc. that was needed and/or provided a method for more efficiently uses resources, etc;).
Additionally, Thaw teaches assigning priorities above a threshold priority to each participating blockchain node ([0036] PoRt operates in similar way as a proof-of-authority (PoA) network with a threshold, where only nodes with a sufficiently high rating can sign and validate objects. In general, a more positive rating connotes a more trusted and active participant).
As per claim 16, it is a system claim of claim 5, so it is rejected for similar reasons.
As per claim 18, it is a system claim of claim 4, so it is rejected for similar reasons.
As per claim 19, Wang and Thaw teach the system of claim 10. Wang teaches wherein the blockchain nodes within the set of blockchain nodes are consensus nodes ([0004] In other words, blockchain technology is built on an ordered series of blocks that contain a set of transactions and references to the previous block. There are numerous protocols that make use of this concept to reach a consensus about a total ordering on transactions; [0008] Because the dedicated amount of compute resources to validate increases the probability of getting a Bitcoin reward, the consensus model is called “Proof of Work”; [0089] peak bandwidth may correspond to the maximum amount of resources required to run a distributed ledger or blockchain, and peak bandwidth may occur when a node encounters processing that is heavier than normal, which may include validation).
Claims 6 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang and Thaw, as applied to claims 1 and 10 above, in view of Li (US 20210234698 A1).
As per claim 6, Wang and Thaw teach the system of claim 1.
Wang and Thaw fail to teach wherein the management system reallocates the computing resources when consensus is complete.
However, Li teaches wherein the management system reallocates the computing resources when consensus is complete ([0023] In this way, after completing the service demand running on the local consensus instance, the administrator of the block chain can delete the local consensus instance in time, thereby releasing the corresponding network resources).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wang and Thaw with the teachings of Li to optimize resource utilization (see Li [0070] after completing the service demand running on the local consensus instance, the administrator of the block chain can delete the local consensus instance in time, thereby releasing the corresponding network resources, and thus to utilize this block chain network resource optimally.).
As per claim 20, it is a system claim of claim 6, so it is rejected for similar reasons.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Wang and Thaw, as applied to claim 1 above, in view of Jette et al. (US 11288736 B1 hereinafter Jette).
As per claim 9, Wang and Thaw teach the system of claim 1.
Wang and Thaw fail to teach wherein the management system comprises a hypervisor.
However, Jette teaches wherein the management system comprises a hypervisor (Col. 17 lines 59-61 a hypervisor or virtual machine monitor (VMM) may be implemented to create and run a virtual machine on the blockchain network.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wang and Thaw with the teachings of Jette to scale VMs (see Jette Col. 17 lines 59-61 a hypervisor or virtual machine monitor (VMM) may be implemented to create and run a virtual machine on the blockchain network).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Wang and Thaw, as applied to claim 10 above, in view of Matetic et al. (US 20200328889 A1 hereinafter Matetic).
As per claim 17, Wang and Thaw teach the system of claim 10. Wang teaches wherein a first blockchain node in the set of blockchain nodes is connected to an account-based blockchain (Abstract A system and method for enabling users to operate multiple blockchain (or distributed ledger) nodes efficiently).
Wang and Thaw fail to teach a second blockchain node in the set of blockchain nodes is connected to a UTXO-based blockchain.
However, Matetic teaches a second blockchain node in the set of blockchain nodes is connected to a UTXO-based blockchain ([0039] According to embodiments of the present invention new indexed database structures of unspent transactions (denoted ‘secure UTXO’ that resemble the ‘original UTXO’ maintained by the full blockchain node) are created).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Wang and Thaw with the teachings of Matetic to promote privacy and efficiency (see Matetic [0021] better privacy and efficiency is provided for lightweight blockchain clients.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights