DETAILED ACTION
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 .
This communication is in response to the application filed on 06/24/2026. Claims 1-20 are currently pending. It is noted that claims 16-20 are newly added to the previous claims.
Response to Arguments
Applicant’s arguments with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim 20 is 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.
Applicant claimed C3N score in claim 20. C3N score is not known in the art outside C3N technology which is the applicant for the present application. This makes the claim
indefinite as the score may change anytime in the future as technology improves. For the purpose of the prosecution of this application, examiner equates C3N score to be any reputation or trustworthiness score.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6-8, 11-13, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al. (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to Matican et al. (hereinafter Matican).
NOTE: JAYASINGHE NPL was supplied by the applicant in one of the IDS on 11/25/2024.
Regarding claim 1, MATURI discloses a method (abstract, “Methods, systems and computer program products…”), comprising:
providing container images comprising application service logic for a cloud service to a plurality of computer systems (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.). Some hyperconverged systems implement certain aspects of virtualization. For example, in a hypervisor-assisted virtualization environment, certain of the autonomous entities of a distributed system can be implemented as virtual machines. As another example, in some virtualization environments, autonomous entities of a distributed system can be implemented as executable containers…”), (¶0128, “…An executable container instance can be executed by a processor. Runnable portions of an executable container instance sometimes derive from an executable container image…”), (¶0129, “An executable container instance can serve as an instance of an application container or as a controller executable container. Any executable container of any sort can be rooted in a directory system and can be configured to be accessed by file system commands (e.g., “ls” or “ls-a,” etc.). The executable container might optionally include operating system components 778, however such a separate set of operating system components need not be provided. As an alternative, an executable container can include runnable instance 758, which is built (e.g., through compilation and linking, or just-in-time compilation, etc.) to include all of the library and OS-like functions needed for execution of the runnable instance. In some cases, a runnable instance can be built with a virtual disk configuration manager, any of a variety of data IO management functions, etc. In some cases, a runnable instance includes code for, and access to, container virtual disk controller 776. Such a container virtual disk controller can perform any of the functions that the aforementioned CVM virtual disk controller 726 can perform”, wherein a software container that bundles application code, runtimes, system libraries, and dependencies serves as the core compute unit for hosting application service logic in a cloud environment.),
provisioning the plurality of computer systems to collectively run a plurality of nodes in a containerized environment (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.)…”), (¶0142, “executable containers may be implemented at the nodes in an operating system-based virtualization environment or in a containerized virtualization environment. The executable containers are implemented at the nodes in an operating system virtualization environment or container virtualization environment…”), wherein the plurality of nodes execute the application service logic as containerized application services of a distributed peer-to-peer cloud infrastructure (¶0083, “…This leader node loads the other nodes of the to-be-configured cluster. More specifically, the leader node instantiates a node-specific instance of the cluster management service onto each of the nodes that are to be used in the to-be-configured computing cluster 316. After that, when the leader node broadcasts bring-up instructions 106B over the Intranet, then each of the nodes that are to be used in the to-be-configured computing cluster 316 can respond to the broadcasted instructions. Alternatively or additionally, a leader node can multicast to specific to-be-configured cluster nodes by carrying out a protocol that is implemented within each instance of the cluster management services running on the other to-be-configured cluster nodes.”), (¶0040-¶0044, “As shown, any of the nodes of the distributed virtualization system can implement one or more user virtualized entities (e.g., VE 788.sub.111, . . . , VE 788.sub.11K, . . . , VE 788.sub.1M1, . . . , VE 788.sub.1MK), such as virtual machines (VMs) and/or executable containers. The VMs can be characterized as software-based computing “machines” implemented in a container-based or hypervisor-assisted virtualization environment that emulates the underlying hardware resources (e.g., CPU, memory, etc.) of the nodes. For example, multiple VMs can operate on one physical machine (e.g., node host computer) running a single host operating system (e.g., host operating system 787.sub.11, . . . , host operating system 787.sub.1M), while the VMs run multiple applications on various respective guest operating systems…executable containers may be implemented at the nodes in an operating system-based virtualization environment or in a containerized virtualization environment. The executable containers are implemented at the nodes in an operating system virtualization environment or container virtualization environment. The executable containers comprise groups of processes and/or resources (e.g., memory, CPU, disk, etc.) that are isolated from the node host computer and other containers. Such executable containers directly interface with the kernel of the host operating system (e.g., host operating system 787.sub.11, . . . , host operating system 787.sub.1M) without, in most cases, a hypervisor layer. This lightweight implementation can facilitate efficient distribution of certain software components, such as applications or services (e.g., micro-services). Any node of a distributed virtualization system can implement both a hypervisor-assisted virtualization environment and a container virtualization environment for various purposes…”);
selecting, from the plurality of nodes, a leader node (¶0059, “To explain, for the purpose of electing a leader node from among themselves (step 266), each member of the to-be-configured cluster executes its own instance of the cluster management service. Once a leader is elected, the leader may perform additional operations (step 270) that are included in the leader's instance of the cluster management service so as to manage additional bring-up processing…”), (¶0071, “…The cluster management service code that is loaded onto the respective nodes can self-invoke. In some cases, and as shown in this particular embodiment, self-invocation results in each node commencing into a protocol to elect a leader (step 212).”), (¶0072, “One result of carrying out the protocol to elect a leader is to establish a leader-follower relationship among the nodes….”);
configuring other nodes of the plurality of nodes as follower nodes (¶0071, “…The cluster management service code that is loaded onto the respective nodes can self-invoke. In some cases, and as shown in this particular embodiment, self-invocation results in each node commencing into a protocol to elect a leader (step 212).”), (¶0072, “One result of carrying out the protocol to elect a leader is to establish a leader-follower relationship among the nodes….”), (¶0075, “a leader can send a pre-prepared intent specification to each of the follower nodes. Each of the nodes can then reconfigure themselves (e.g., in parallel) and add themselves as members of the cluster in accordance with the pre-prepared intent specification. Cluster membership can be configured independently, node-by-node by each of the follower nodes (e.g., by adding themselves to the cluster) or, each of the follower nodes can coordinate with the leader such that the leader configures the follower nodes into the membership of the cluster…”);
processing cloud service requests at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes (¶0061, “In some cases, the leader may communicate a cluster specification to the follower members of the cluster such that each follower node can independently perform additional bring-up operations. In some cases the leader node and follower node(s) cooperate to configure the cloud provider's networking infrastructure (e.g., switches, routers, router tables, etc.). The configuration of the cloud provider's networking infrastructure serves to accommodate differences between the virtualization system's networking constructs and the actual networking infrastructure of the cloud provider. Strictly as an example, a leader node may initialize actual networking components of the cloud provider by allocating IP addresses from the cloud provider's infrastructure, then may assign the allocated IP addresses to networking interfaces of respective nodes...”), (¶0072, “…Having such a leader-follower relationship facilitates certain types of bring-up operations, including distribution of software modules, time-sharing of licenses, and inter-node distribution of instructions….”), (¶0074, “…Once the leader-follower relationships have been established, performance of bring-up operations commence (step 214). In some embodiments, the leader directs each follower to perform one or more of the list of cluster management operations 207…”).
However, MATURI does not explicitly disclose the following limitations:
a publicly available container registry,
wherein the plurality of computer systems are collectively owned by at least two separate entities;
forming, from the leader node and the follower nodes, a service-specific node group configured to provide the cloud service; and
processing cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service.
JAYASINGHE discloses wherein the plurality of computer systems are collectively owned by at least two separate entities (page 10, left col. second paragraph, “…no single party can own 51% of a global trust network in TrustChain technology, as the selection of TBs based on trustworthiness in contrast to factors like computing power, authority and wealth, which can be controlled to gain unfair advantages...”).
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MAURI to include plurality of computer systems collectively owned by at least two separate entities as disclosed by JAYASINGHE and be motivated in doing so in order to make it difficult for a malicious miner to interfere with the voting process-JAYASINGHE page 10, left col. Second paragraph in parts.
However, the combination of MAURI and JAYASINGHE does not explicitly disclose the following limitation:
a publicly available container registry,
forming, from the leader node and the follower nodes, a service-specific node group configured to provide the cloud service; and
processing cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service.
Matican discloses a publicly available container registry (¶0031, “…Examples of such diverse cloud infrastructures include, but are not limited to, public clouds such as Amazon Web Services (AWS) Cloud available from Amazon.com, Inc., Google Cloud Platform (GCP) available from Google LLC, Kubernetes etc., and private clouds such as On-Premises clouds owned by the customers.”, wherein AWS provides a publicly available container registry called Amazon Elastic Container registry Public (Amazon ECR Public),
forming, from the leader node and the follower nodes, a service-specific node group
configured to provide the cloud service (¶0008, “…a large scale distributed data service may be designed as several cooperating parts, with each part being replicated (distributed) in each node of a group of nodes (hereinafter referred to as “a cluster of nodes” implementing each part) and a leader node in the cluster providing a central essential task for that cluster. One of such central essential tasks is to operate as a point of interface to the external applications for using the service corresponding to the part, which is desirable as the part is replicated among the cluster of nodes…”), (¶0024, “…the nodes based on which a distributed data service is operative are grouped into multiple clusters, with a corresponding leader node for each cluster being elected. However, if the elected leader node of a cluster is not organized into the preferred zone (specified by a user), one of the preferred set of nodes (specified by the user) is set as the leader node of the cluster.”), see also ¶0052
processing cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service (¶0041, “a large-scale distributed data service is commonly designed as several cooperating parts, with a cluster of nodes implementing each part and a leader node in the cluster providing central essential tasks for that cluster. In one embodiment, a leader node is selected to operate as a point of interface to external applications (executing outside the cluster) for using the service corresponding to the part. Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node. For read requests for retrieving data items, the leader node provides the latest values for the requested data items as is needed for a strong consistent data service, while the other nodes in the cluster provide potentially older, though timeline consistent, values.”), (¶0065-¶0069, GIGs. 3A and 3B).
Thus, one of ordinary skill in the art would have found obvious before the effective filing
date of applicant’s claimed invention to modify the method of MAURI and JAYASINGHE to include forming, from the leader node and the follower nodes, a service-specific node group
configured to provide the cloud service as disclosed by Matican and be motivated in doing so in order to have a structured, highly efficient architecture for cloud services.
Regarding claim 6, MATURI discloses a system (abstract, Methos and systems and computer program products for intra-footprint computing cluster bring-up within a virtual private cloud), comprising:
one or more processors (¶0014, “Such a sequence of instructions, when stored in memory and executed by one or more processors...”); and
one or more memories storing executable instructions that, as a result of execution, cause the system (¶0014, “Some embodiments include a sequence of instructions that are stored on a non-transitory computer readable medium. Such a sequence of instructions, when stored in memory and executed by one or more processors, cause the one or more processors to perform a set of acts…”):
provide container images comprising application service logic for a cloud service to a plurality of computer systems (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.). Some hyperconverged systems implement certain aspects of virtualization. For example, in a hypervisor-assisted virtualization environment, certain of the autonomous entities of a distributed system can be implemented as virtual machines. As another example, in some virtualization environments, autonomous entities of a distributed system can be implemented as executable containers…”), (¶0128, “…An executable container instance can be executed by a processor. Runnable portions of an executable container instance sometimes derive from an executable container image…”), (¶0129, “An executable container instance can serve as an instance of an application container or as a controller executable container. Any executable container of any sort can be rooted in a directory system and can be configured to be accessed by file system commands (e.g., “ls” or “ls-a,” etc.). The executable container might optionally include operating system components 778, however such a separate set of operating system components need not be provided. As an alternative, an executable container can include runnable instance 758, which is built (e.g., through compilation and linking, or just-in-time compilation, etc.) to include all of the library and OS-like functions needed for execution of the runnable instance. In some cases, a runnable instance can be built with a virtual disk configuration manager, any of a variety of data IO management functions, etc. In some cases, a runnable instance includes code for, and access to, container virtual disk controller 776. Such a container virtual disk controller can perform any of the functions that the aforementioned CVM virtual disk controller 726 can perform”, wherein a software container that bundles application code, runtimes, system libraries, and dependencies serves as the core compute unit for hosting application service logic in a cloud environment.),
provision the plurality of computer systems to collectively run a plurality of nodes in a containerized environment (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.)…”), (¶0142, “executable containers may be implemented at the nodes in an operating system-based virtualization environment or in a containerized virtualization environment. The executable containers are implemented at the nodes in an operating system virtualization environment or container virtualization environment…”), wherein the plurality of nodes execute the application service logic as containerized application services of a distributed peer-to-peer cloud infrastructure (¶0083, “…This leader node loads the other nodes of the to-be-configured cluster. More specifically, the leader node instantiates a node-specific instance of the cluster management service onto each of the nodes that are to be used in the to-be-configured computing cluster 316. After that, when the leader node broadcasts bring-up instructions 106B over the Intranet, then each of the nodes that are to be used in the to-be-configured computing cluster 316 can respond to the broadcasted instructions. Alternatively or additionally, a leader node can multicast to specific to-be-configured cluster nodes by carrying out a protocol that is implemented within each instance of the cluster management services running on the other to-be-configured cluster nodes.”), (¶0040-¶0044, “As shown, any of the nodes of the distributed virtualization system can implement one or more user virtualized entities (e.g., VE 788.sub.111, . . . , VE 788.sub.11K, . . . , VE 788.sub.1M1, . . . , VE 788.sub.1MK), such as virtual machines (VMs) and/or executable containers. The VMs can be characterized as software-based computing “machines” implemented in a container-based or hypervisor-assisted virtualization environment that emulates the underlying hardware resources (e.g., CPU, memory, etc.) of the nodes. For example, multiple VMs can operate on one physical machine (e.g., node host computer) running a single host operating system (e.g., host operating system 787.sub.11, . . . , host operating system 787.sub.1M), while the VMs run multiple applications on various respective guest operating systems…executable containers may be implemented at the nodes in an operating system-based virtualization environment or in a containerized virtualization environment. The executable containers are implemented at the nodes in an operating system virtualization environment or container virtualization environment. The executable containers comprise groups of processes and/or resources (e.g., memory, CPU, disk, etc.) that are isolated from the node host computer and other containers. Such executable containers directly interface with the kernel of the host operating system (e.g., host operating system 787.sub.11, . . . , host operating system 787.sub.1M) without, in most cases, a hypervisor layer. This lightweight implementation can facilitate efficient distribution of certain software components, such as applications or services (e.g., micro-services). Any node of a distributed virtualization system can implement both a hypervisor-assisted virtualization environment and a container virtualization environment for various purposes…”);
select, from the plurality of nodes, a leader node (¶0059, “To explain, for the purpose of electing a leader node from among themselves (step 266), each member of the to-be-configured cluster executes its own instance of the cluster management service. Once a leader is elected, the leader may perform additional operations (step 270) that are included in the leader's instance of the cluster management service so as to manage additional bring-up processing…”), (¶0071, “…The cluster management service code that is loaded onto the respective nodes can self-invoke. In some cases, and as shown in this particular embodiment, self-invocation results in each node commencing into a protocol to elect a leader (step 212).”), (¶0072, “One result of carrying out the protocol to elect a leader is to establish a leader-follower relationship among the nodes….”);
configure other nodes of the plurality of nodes as follower nodes (¶0071, “…The cluster management service code that is loaded onto the respective nodes can self-invoke. In some cases, and as shown in this particular embodiment, self-invocation results in each node commencing into a protocol to elect a leader (step 212).”), (¶0072, “One result of carrying out the protocol to elect a leader is to establish a leader-follower relationship among the nodes….”), (¶0075, “a leader can send a pre-prepared intent specification to each of the follower nodes. Each of the nodes can then reconfigure themselves (e.g., in parallel) and add themselves as members of the cluster in accordance with the pre-prepared intent specification. Cluster membership can be configured independently, node-by-node by each of the follower nodes (e.g., by adding themselves to the cluster) or, each of the follower nodes can coordinate with the leader such that the leader configures the follower nodes into the membership of the cluster…”);
process cloud service requests at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes (¶0061, “In some cases, the leader may communicate a cluster specification to the follower members of the cluster such that each follower node can independently perform additional bring-up operations. In some cases the leader node and follower node(s) cooperate to configure the cloud provider's networking infrastructure (e.g., switches, routers, router tables, etc.). The configuration of the cloud provider's networking infrastructure serves to accommodate differences between the virtualization system's networking constructs and the actual networking infrastructure of the cloud provider. Strictly as an example, a leader node may initialize actual networking components of the cloud provider by allocating IP addresses from the cloud provider's infrastructure, then may assign the allocated IP addresses to networking interfaces of respective nodes...”), (¶0072, “…Having such a leader-follower relationship facilitates certain types of bring-up operations, including distribution of software modules, time-sharing of licenses, and inter-node distribution of instructions….”), (¶0074, “…Once the leader-follower relationships have been established, performance of bring-up operations commence (step 214). In some embodiments, the leader directs each follower to perform one or more of the list of cluster management operations 207…”).
However, MATURI does not explicitly disclose the following limitations:
a publicly available container registry,
wherein the plurality of computer systems are collectively owned by at least two separate entities;
form, from the leader node and the follower nodes, a service-specific node group configured to provide the cloud service; and
process cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service.
JAYASINGHE discloses wherein the plurality of computer systems are collectively owned by at least two separate entities (page 10, left col. second paragraph, “…no single party can own 51% of a global trust network in TrustChain technology, as the selection of TBs based on trustworthiness in contrast to factors like computing power, authority and wealth, which can be controlled to gain unfair advantages...”).
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MAURI to include plurality of computer systems collectively owned by at least two separate entities as disclosed by JAYASINGHE and be motivated in doing so in order to make it difficult for a malicious miner to interfere with the voting process-JAYASINGHE page 10, left col. Second paragraph in parts.
However, the combination of MAURI and JAYASINGHE does not explicitly disclose the following limitation:
a publicly available container registry,
form, from the leader node and the follower nodes, a service-specific node group configured to provide the cloud service; and
process cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service.
Matican discloses a publicly available container registry (¶0031, “…Examples of such diverse cloud infrastructures include, but are not limited to, public clouds such as Amazon Web Services (AWS) Cloud available from Amazon.com, Inc., Google Cloud Platform (GCP) available from Google LLC, Kubernetes etc., and private clouds such as On-Premises clouds owned by the customers.”, wherein AWS provides a publicly available container registry called Amazon Elastic Container registry Public (Amazon ECR Public),
form, from the leader node and the follower nodes, a service-specific node group
configured to provide the cloud service (¶0008, “…a large scale distributed data service may be designed as several cooperating parts, with each part being replicated (distributed) in each node of a group of nodes (hereinafter referred to as “a cluster of nodes” implementing each part) and a leader node in the cluster providing a central essential task for that cluster. One of such central essential tasks is to operate as a point of interface to the external applications for using the service corresponding to the part, which is desirable as the part is replicated among the cluster of nodes…”), (¶0024, “…the nodes based on which a distributed data service is operative are grouped into multiple clusters, with a corresponding leader node for each cluster being elected. However, if the elected leader node of a cluster is not organized into the preferred zone (specified by a user), one of the preferred set of nodes (specified by the user) is set as the leader node of the cluster.”), see also ¶0052
process cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service (¶0041, “a large-scale distributed data service is commonly designed as several cooperating parts, with a cluster of nodes implementing each part and a leader node in the cluster providing central essential tasks for that cluster. In one embodiment, a leader node is selected to operate as a point of interface to external applications (executing outside the cluster) for using the service corresponding to the part. Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node. For read requests for retrieving data items, the leader node provides the latest values for the requested data items as is needed for a strong consistent data service, while the other nodes in the cluster provide potentially older, though timeline consistent, values.”), (¶0065-¶0069, GIGs. 3A and 3B).
Thus, one of ordinary skill in the art would have found obvious before the effective filing
date of applicant’s claimed invention to modify the system of MAURI and JAYASINGHE to include forming, from the leader node and the follower nodes, a service-specific node group
configured to provide the cloud service as disclosed by Matican and be motivated in doing so in order to have a structured, highly efficient architecture for cloud services.
Regarding claim 11, MATURI discloses One or more non-transitory computer-readable mediums storing executable instructions that, as a result of execution by one or more processors, cause the one or more processors to (¶0014, “Some embodiments include a sequence of instructions that are stored on a non-transitory computer readable medium. Such a sequence of instructions, when stored in memory and executed by one or more processors, cause the one or more processors to perform a set of acts…”):
provide container images comprising application service logic for a cloud service to a plurality of computer systems (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.). Some hyperconverged systems implement certain aspects of virtualization. For example, in a hypervisor-assisted virtualization environment, certain of the autonomous entities of a distributed system can be implemented as virtual machines. As another example, in some virtualization environments, autonomous entities of a distributed system can be implemented as executable containers…”), (¶0128, “…An executable container instance can be executed by a processor. Runnable portions of an executable container instance sometimes derive from an executable container image…”), (¶0129, “An executable container instance can serve as an instance of an application container or as a controller executable container. Any executable container of any sort can be rooted in a directory system and can be configured to be accessed by file system commands (e.g., “ls” or “ls-a,” etc.). The executable container might optionally include operating system components 778, however such a separate set of operating system components need not be provided. As an alternative, an executable container can include runnable instance 758, which is built (e.g., through compilation and linking, or just-in-time compilation, etc.) to include all of the library and OS-like functions needed for execution of the runnable instance. In some cases, a runnable instance can be built with a virtual disk configuration manager, any of a variety of data IO management functions, etc. In some cases, a runnable instance includes code for, and access to, container virtual disk controller 776. Such a container virtual disk controller can perform any of the functions that the aforementioned CVM virtual disk controller 726 can perform”, wherein a software container that bundles application code, runtimes, system libraries, and dependencies serves as the core compute unit for hosting application service logic in a cloud environment.),
provision the plurality of computer systems to collectively run a plurality of nodes in a containerized environment (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.)…”), (¶0142, “executable containers may be implemented at the nodes in an operating system-based virtualization environment or in a containerized virtualization environment. The executable containers are implemented at the nodes in an operating system virtualization environment or container virtualization environment…”), wherein the plurality of nodes execute the application service logic as containerized application services of a distributed peer-to-peer cloud infrastructure (¶0083, “…This leader node loads the other nodes of the to-be-configured cluster. More specifically, the leader node instantiates a node-specific instance of the cluster management service onto each of the nodes that are to be used in the to-be-configured computing cluster 316. After that, when the leader node broadcasts bring-up instructions 106B over the Intranet, then each of the nodes that are to be used in the to-be-configured computing cluster 316 can respond to the broadcasted instructions. Alternatively or additionally, a leader node can multicast to specific to-be-configured cluster nodes by carrying out a protocol that is implemented within each instance of the cluster management services running on the other to-be-configured cluster nodes.”), (¶0040-¶0044, “As shown, any of the nodes of the distributed virtualization system can implement one or more user virtualized entities (e.g., VE 788.sub.111, . . . , VE 788.sub.11K, . . . , VE 788.sub.1M1, . . . , VE 788.sub.1MK), such as virtual machines (VMs) and/or executable containers. The VMs can be characterized as software-based computing “machines” implemented in a container-based or hypervisor-assisted virtualization environment that emulates the underlying hardware resources (e.g., CPU, memory, etc.) of the nodes. For example, multiple VMs can operate on one physical machine (e.g., node host computer) running a single host operating system (e.g., host operating system 787.sub.11, . . . , host operating system 787.sub.1M), while the VMs run multiple applications on various respective guest operating systems…executable containers may be implemented at the nodes in an operating system-based virtualization environment or in a containerized virtualization environment. The executable containers are implemented at the nodes in an operating system virtualization environment or container virtualization environment. The executable containers comprise groups of processes and/or resources (e.g., memory, CPU, disk, etc.) that are isolated from the node host computer and other containers. Such executable containers directly interface with the kernel of the host operating system (e.g., host operating system 787.sub.11, . . . , host operating system 787.sub.1M) without, in most cases, a hypervisor layer. This lightweight implementation can facilitate efficient distribution of certain software components, such as applications or services (e.g., micro-services). Any node of a distributed virtualization system can implement both a hypervisor-assisted virtualization environment and a container virtualization environment for various purposes…”);
select, from the plurality of nodes, a leader node (¶0059, “To explain, for the purpose of electing a leader node from among themselves (step 266), each member of the to-be-configured cluster executes its own instance of the cluster management service. Once a leader is elected, the leader may perform additional operations (step 270) that are included in the leader's instance of the cluster management service so as to manage additional bring-up processing…”), (¶0071, “…The cluster management service code that is loaded onto the respective nodes can self-invoke. In some cases, and as shown in this particular embodiment, self-invocation results in each node commencing into a protocol to elect a leader (step 212).”), (¶0072, “One result of carrying out the protocol to elect a leader is to establish a leader-follower relationship among the nodes….”);
configure other nodes of the plurality of nodes as follower nodes (¶0071, “…The cluster management service code that is loaded onto the respective nodes can self-invoke. In some cases, and as shown in this particular embodiment, self-invocation results in each node commencing into a protocol to elect a leader (step 212).”), (¶0072, “One result of carrying out the protocol to elect a leader is to establish a leader-follower relationship among the nodes….”), (¶0075, “a leader can send a pre-prepared intent specification to each of the follower nodes. Each of the nodes can then reconfigure themselves (e.g., in parallel) and add themselves as members of the cluster in accordance with the pre-prepared intent specification. Cluster membership can be configured independently, node-by-node by each of the follower nodes (e.g., by adding themselves to the cluster) or, each of the follower nodes can coordinate with the leader such that the leader configures the follower nodes into the membership of the cluster…”);
process cloud service requests at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes (¶0061, “In some cases, the leader may communicate a cluster specification to the follower members of the cluster such that each follower node can independently perform additional bring-up operations. In some cases the leader node and follower node(s) cooperate to configure the cloud provider's networking infrastructure (e.g., switches, routers, router tables, etc.). The configuration of the cloud provider's networking infrastructure serves to accommodate differences between the virtualization system's networking constructs and the actual networking infrastructure of the cloud provider. Strictly as an example, a leader node may initialize actual networking components of the cloud provider by allocating IP addresses from the cloud provider's infrastructure, then may assign the allocated IP addresses to networking interfaces of respective nodes...”), (¶0072, “…Having such a leader-follower relationship facilitates certain types of bring-up operations, including distribution of software modules, time-sharing of licenses, and inter-node distribution of instructions….”), (¶0074, “…Once the leader-follower relationships have been established, performance of bring-up operations commence (step 214). In some embodiments, the leader directs each follower to perform one or more of the list of cluster management operations 207…”).
However, MATURI does not explicitly disclose the following limitations:
a publicly available container registry,
wherein the plurality of computer systems are collectively owned by at least two separate entities;
form, from the leader node and the follower nodes, a service-specific node group configured to provide the cloud service; and
process cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service.
JAYASINGHE discloses wherein the plurality of computer systems are collectively owned by at least two separate entities (page 10, left col. second paragraph, “…no single party can own 51% of a global trust network in TrustChain technology, as the selection of TBs based on trustworthiness in contrast to factors like computing power, authority and wealth, which can be controlled to gain unfair advantages...”).
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MAURI to include plurality of computer systems collectively owned by at least two separate entities as disclosed by JAYASINGHE and be motivated in doing so in order to make it difficult for a malicious miner to interfere with the voting process-JAYASINGHE page 10, left col. Second paragraph in parts.
However, the combination of MAURI and JAYASINGHE does not explicitly disclose the following limitation:
a publicly available container registry,
form, from the leader node and the follower nodes, a service-specific node group configured to provide the cloud service; and
process cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service.
Matican discloses a publicly available container registry (¶0031, “…Examples of such diverse cloud infrastructures include, but are not limited to, public clouds such as Amazon Web Services (AWS) Cloud available from Amazon.com, Inc., Google Cloud Platform (GCP) available from Google LLC, Kubernetes etc., and private clouds such as On-Premises clouds owned by the customers.”, wherein AWS provides a publicly available container registry called Amazon Elastic Container registry Public (Amazon ECR Public),
form, from the leader node and the follower nodes, a service-specific node group
configured to provide the cloud service (¶0008, “…a large scale distributed data service may be designed as several cooperating parts, with each part being replicated (distributed) in each node of a group of nodes (hereinafter referred to as “a cluster of nodes” implementing each part) and a leader node in the cluster providing a central essential task for that cluster. One of such central essential tasks is to operate as a point of interface to the external applications for using the service corresponding to the part, which is desirable as the part is replicated among the cluster of nodes…”), (¶0024, “…the nodes based on which a distributed data service is operative are grouped into multiple clusters, with a corresponding leader node for each cluster being elected. However, if the elected leader node of a cluster is not organized into the preferred zone (specified by a user), one of the preferred set of nodes (specified by the user) is set as the leader node of the cluster.”), see also ¶0052
process cloud service requests directed to the cloud service provided by the service- specific node group at the leader node, wherein the processing comprises utilizing at least a portion of the follower nodes by coordinating execution of the application service logic by the at least a portion of the follower nodes to perform one or more operations of the cloud service (¶0041, “a large-scale distributed data service is commonly designed as several cooperating parts, with a cluster of nodes implementing each part and a leader node in the cluster providing central essential tasks for that cluster. In one embodiment, a leader node is selected to operate as a point of interface to external applications (executing outside the cluster) for using the service corresponding to the part. Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node. For read requests for retrieving data items, the leader node provides the latest values for the requested data items as is needed for a strong consistent data service, while the other nodes in the cluster provide potentially older, though timeline consistent, values.”), (¶0065-¶0069, GIGs. 3A and 3B).
Thus, one of ordinary skill in the art would have found obvious before the effective filing
date of applicant’s claimed invention to modify the system of MAURI and JAYASINGHE to include forming, from the leader node and the follower nodes, a service-specific node group
configured to provide the cloud service as disclosed by Matican and be motivated in doing so in order to have a structured, highly efficient architecture for cloud services.
Regarding claim 2, MATURI in view of JAYASINGHE and further in view of
Matican discloses the method of claim 1.
JAYASINGHE further discloses wherein the leader node is selected based on having a
highest trust score of the plurality of nodes (page 10, right col to page 11, left col. first paragraph. Second paragraph “…Where TrustTB represents the trustworthiness of TB and KTB, ETB, andRTB denote the TMs based on knowledge, experience, and reputation. Based on the trust value of TBs, one who has the highest trustworthiness is chosen as the leader for a specific TBP and broadcast it to other nodes in the pool with the leader’s digital signature. Upon receiving the signature from the leader, other nodes can verify it and then acknowledge it with their own signatures. The leader is mainly responsible for managing the consensus process until its term period has expired. Once the term of a leader has expired, a new leader must be chosen based on the highest trustworthiness value of a node.”).
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MAURI, JAYASINGHE, and Matican to include electing the leader node based on the highest trust score of the plurality of nodes as disclosed by JAYASINGHE and be motivated in doing so in order to realize trustworthy services in a distributed environment -JAYASINGHE page 2, right col. second paragraph in parts.
Regarding claim 7, MATURI in view of JAYASINGHE and further in view of Matican discloses the system of claim 6.
JAYASINGHE further discloses wherein the leader node is selected based on having a
highest trust score of the plurality of nodes (page 10, right col to page 11, left col. first paragraph. Second paragraph “…Where TrustTB represents the trustworthiness of TB and KTB, ETB, andRTB denote the TMs based on knowledge, experience, and reputation. Based on the trust value of TBs, one who has the highest trustworthiness is chosen as the leader for a specific TBP and broadcast it to other nodes in the pool with the leader’s digital signature. Upon receiving the signature from the leader, other nodes can verify it and then acknowledge it with their own signatures. The leader is mainly responsible for managing the consensus process until its term period has expired. Once the term of a leader has expired, a new leader must be chosen based on the highest trustworthiness value of a node.”).
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MAURI, JAYASINGHE, and Matican to include electing the leader node based on the highest trust score of the plurality of nodes as disclosed by JAYASINGHE and be motivated in doing so in order to realize trustworthy services in a distributed environment -JAYASINGHE page 2, right col. second paragraph in parts.
Regarding claim 12, MATURI in view of JAYASINGHE and further in view of Matican discloses the one or more non-transitory computer-readable mediums of claim 11.
JAYASINGHE further discloses wherein the leader node is selected based on having a
highest trust score of the plurality of nodes (page 10, right col to page 11, left col. first paragraph. Second paragraph “…Where TrustTB represents the trustworthiness of TB and KTB, ETB, andRTB denote the TMs based on knowledge, experience, and reputation. Based on the trust value of TBs, one who has the highest trustworthiness is chosen as the leader for a specific TBP and broadcast it to other nodes in the pool with the leader’s digital signature. Upon receiving the signature from the leader, other nodes can verify it and then acknowledge it with their own signatures. The leader is mainly responsible for managing the consensus process until its term period has expired. Once the term of a leader has expired, a new leader must be chosen based on the highest trustworthiness value of a node.”).
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MAURI, JAYASINGHE, and Matican to include electing the leader node based on the highest trust score of the plurality of nodes as disclosed by JAYASINGHE and be motivated in doing so in order to realize trustworthy services in a distributed environment -JAYASINGHE page 2, right col. second paragraph in parts.
Regarding claim 3, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
Matican further discloses wherein the cloud service request comprises a write request; the leader node performs an initial write (¶0041, “Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node...”);
the follower nodes perform replica copies of the initial write (¶0069, “upon receiving a write request, performs the write operation indicated in the write request on its copy of data (“tablet 1, peer 2”) while obtaining the necessary locks, initiates replication of the data to its peers (331 and 333) and sends a response to the write request. Leader node 332 upon receiving a read request, performs the read operation indicated in the read request on its copy of data and sends a response to the read request (with the results of the read operation)…”);
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MATURI, JAYASINGHE, and Matican to include the cloud service request comprises a write request as disclosed by Matican and be motivated in doing so in order to select a leader node to operate as a point of interface to external applications (executing outside the cluster) for using the service corresponding to the part-Matican ¶0041 in parts.
Regarding claim 8, MATURI in view of JAYASINGHE and further in view of Matican discloses the system of claim 6.
Matican further discloses the cloud service request comprises a write request; the leader node performs an initial write (¶0041, “Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node...”);
the follower nodes perform replica copies of the initial write (¶0069, “upon receiving a write request, performs the write operation indicated in the write request on its copy of data (“tablet 1, peer 2”) while obtaining the necessary locks, initiates replication of the data to its peers (331 and 333) and sends a response to the write request. Leader node 332 upon receiving a read request, performs the read operation indicated in the read request on its copy of data and sends a response to the read request (with the results of the read operation)…”);
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MATURI, JAYASINGHE, and Matican to include the cloud service request comprises a write request as disclosed by Matican and be motivated in doing so in order to select a leader node to operate as a point of interface to external applications (executing outside the cluster) for using the service corresponding to the part-Matican ¶0041 in parts.
Regarding claim 13, MATURI in view of JAYASINGHE and further in view of Matican discloses the one or more non-transitory computer-readable mediums of claim 11.
Matican further discloses the cloud service request comprises a write request; the leader node performs an initial write (¶0041, “Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node...”);
the follower nodes perform replica copies of the initial write (¶0069, “upon receiving a write request, performs the write operation indicated in the write request on its copy of data (“tablet 1, peer 2”) while obtaining the necessary locks, initiates replication of the data to its peers (331 and 333) and sends a response to the write request. Leader node 332 upon receiving a read request, performs the read operation indicated in the read request on its copy of data and sends a response to the read request (with the results of the read operation)…”);
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MATURI, JAYASINGHE, and matican to include the cloud service request comprises a write request as disclosed by Matican and be motivated in doing so in order to select a leader node to operate as a point of interface to external applications (executing outside the cluster) for using the service corresponding to the part-Matican ¶0041 in parts.
Regarding claim 16, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
MATURI further discloses wherein the cloud service comprises a backend service for a mobile application or website (¶0137, “In example embodiments, some or all of the servers or nodes run virtualization software. Such virtualization software might include a hypervisor (e.g., as shown in configuration 751 of FIG. 7A) to manage the interactions between the underlying hardware and user virtual machines or containers that run client software.”), and wherein utilizing the at least a portion of the follower nodes comprises, responsive to load on the backend service, selecting a follower node that is running the containerized application service and has additional compute capability, and causing the selected follower node to run an additional container instance of the containerized application service to accommodate the load (¶0068-¶0069, “…Given the expressed intent, “Configure a cluster having three nodes, with the three nodes being collectively capable of processing at least 50K database transactions per second,” and by using any heuristics or other techniques, the expressed intent can be codified into a cluster specification 137, which is in turn processed, possibly in combination with applicable business logic 205. The intent can be codified into a cluster specification using any known technique that can serve to codify any as aspect of the to-be-configured cluster. For example, a performance-related intent of “must process 50K database transactions per second” might be codified as, “each of three nodes of a cluster are to be selected from nodes that are configured with at least 65 GB of memory and at least 2T of local storage capacity; three licenses to the database server are required.””).
Claims 4, 9, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to matican et al. (hereinafter Matican) and further in view of PGPub. No. 20060206943 to Ellison et al. (hereinafter Ellison).
Regarding claim 4, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
MATURI further discloses wherein the containerized environment comprises a plurality of rings of trust that includes (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.)…”):
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose the following limitations:
a first ring of trust for operating system (OS)-level functionality; and
a second ring of trust for one or more application programming interfaces (APIs) to access the first ring of trust.
Ellison discloses:
a first ring of trust for operating system (OS)-level functionality; and a second ring of trust for one or more application programming interfaces (APIs) to access the first ring of trust (¶0023, “The isolated execution architecture includes logical and physical definitions of hardware and software components that interact directly or indirectly with an operating system of the computer system or platform. An operating system and the processor may have several levels of hierarchy, referred to as rings, corresponding to various operational modes. A ring is a logical division of hardware and software components that are designed to perform dedicated tasks within the operating system. The division is typically based on the degree or level of privilege, namely, the ability to make changes to the platform. For example, a ring-0 is the innermost ring, being at the highest level of the hierarchy. Ring-0 encompasses the most critical, privileged components. In addition, modules in Ring-0 can also access to lesser privileged data, but not vice versa. Ring-3 is the outermost ring, being at the lowest level of the hierarchy. Ring-3 typically encompasses users or applications level and has the least privilege. Ring-1 and ring-2 represent the intermediate rings with decreasing levels of privilege.”), (¶0025, “Ring-0 10 includes two portions: a normal execution Ring-0 11 and an isolated execution Ring-0 15. The normal execution Ring-0 11 includes software modules that are critical for the operating system, usually referred to as kernel. These software modules include primary operating system (e.g., kernel) 12, software drivers 13, and hardware drivers 14…”),
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MATURI, JAYASINGHE, and Matican to include a first ring of trust for operating system (OS)-level functionality as disclosed by Ellison and be motivated in doing so in order to manage a secure platform-Ellison ¶0047 in parts.
Regarding claim 9, MATURI in view of JAYASINGHE and further in view of Matican discloses the system of claim 6.
MATURI further discloses wherein the containerized environment comprises a plurality of rings of trust that includes (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.)…”):
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose the following limitations:
a first ring of trust for operating system (OS)-level functionality; and
a second ring of trust for one or more application programming interfaces (APIs) to access the first ring of trust.
Ellison discloses:
a first ring of trust for operating system (OS)-level functionality; and a second ring of trust for one or more application programming interfaces (APIs) to access the first ring of trust (¶0023, “The isolated execution architecture includes logical and physical definitions of hardware and software components that interact directly or indirectly with an operating system of the computer system or platform. An operating system and the processor may have several levels of hierarchy, referred to as rings, corresponding to various operational modes. A ring is a logical division of hardware and software components that are designed to perform dedicated tasks within the operating system. The division is typically based on the degree or level of privilege, namely, the ability to make changes to the platform. For example, a ring-0 is the innermost ring, being at the highest level of the hierarchy. Ring-0 encompasses the most critical, privileged components. In addition, modules in Ring-0 can also access to lesser privileged data, but not vice versa. Ring-3 is the outermost ring, being at the lowest level of the hierarchy. Ring-3 typically encompasses users or applications level and has the least privilege. Ring-1 and ring-2 represent the intermediate rings with decreasing levels of privilege.”), (¶0025, “Ring-0 10 includes two portions: a normal execution Ring-0 11 and an isolated execution Ring-0 15. The normal execution Ring-0 11 includes software modules that are critical for the operating system, usually referred to as kernel. These software modules include primary operating system (e.g., kernel) 12, software drivers 13, and hardware drivers 14…”),
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the system of MATURI, JAYASINGHE, and Matican to include a first ring of trust for operating system (OS)-level functionality as disclosed by Ellison and be motivated in doing so in order to manage a secure platform-Ellison ¶0047 in parts.
Regarding claim 14, MATURI in view of JAYASINGHE and further in view of Matican discloses the one or more non-transitory computer readable mediums of claim 11.
MATURI further discloses wherein the containerized environment comprises a plurality of rings of trust that includes (¶0109, “Physical and/or logical collections of such autonomous entities can sometimes be referred to as nodes. In some hyperconverged systems, compute and storage resources can be integrated into a unit of a node. Multiple nodes can be interrelated into an array of nodes, which nodes can be grouped into physical groupings (e.g., arrays) and/or into logical groupings or topologies of nodes (e.g., spoke-and-wheel topologies, rings, etc.)…”):
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose the following limitations:
a first ring of trust for operating system (OS)-level functionality; and
a second ring of trust for one or more application programming interfaces (APIs) to access the first ring of trust.
Ellison discloses:
a first ring of trust for operating system (OS)-level functionality; and a second ring of trust for one or more application programming interfaces (APIs) to access the first ring of trust (¶0023, “The isolated execution architecture includes logical and physical definitions of hardware and software components that interact directly or indirectly with an operating system of the computer system or platform. An operating system and the processor may have several levels of hierarchy, referred to as rings, corresponding to various operational modes. A ring is a logical division of hardware and software components that are designed to perform dedicated tasks within the operating system. The division is typically based on the degree or level of privilege, namely, the ability to make changes to the platform. For example, a ring-0 is the innermost ring, being at the highest level of the hierarchy. Ring-0 encompasses the most critical, privileged components. In addition, modules in Ring-0 can also access to lesser privileged data, but not vice versa. Ring-3 is the outermost ring, being at the lowest level of the hierarchy. Ring-3 typically encompasses users or applications level and has the least privilege. Ring-1 and ring-2 represent the intermediate rings with decreasing levels of privilege.”), (¶0025, “Ring-0 10 includes two portions: a normal execution Ring-0 11 and an isolated execution Ring-0 15. The normal execution Ring-0 11 includes software modules that are critical for the operating system, usually referred to as kernel. These software modules include primary operating system (e.g., kernel) 12, software drivers 13, and hardware drivers 14…”),
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the system of MATURI, JAYASINGHE, and Matican to include a first ring of trust for operating system (OS)-level functionality as disclosed by Ellison and be motivated in doing so in order to manage a secure platform-Ellison ¶0047 in parts.
Claims 5, 10, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al. (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to Matican et al. (hereinafter Matican) and further in view of PGPub. No. 20170262519 to Horowitz et al. (hereinafter Horowitz).
Regarding claim 5, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
MATURI further discloses wherein, in response to a failure of a follower node to communicate a heartbeat the leader node drops the follower node from the service-specific node group and requests a replacement node from the distributed peer-to-peer cloud infrastructure (¶0071-¶0072, “…Strictly as examples, during bring-up of the to-be-configured cluster, the management layer can detect loss of communication with a cluster member, and can remediate such a loss by invoking code that reconfigures the cluster with a replacement member. In various example scenarios, even the leader node of a to-be-configured cluster may fail, and yet, the management layer of a non-failed member can detect the loss of communication with the failed cluster member, and can then remediate that loss by invoking code that reconfigures the cluster with (1) a new leader, and (2) a replacement node to replace the failed node…”).
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose wherein the follower nodes communicate heartbeats to the leader node, and
a failure of a follower node to communicate a heartbeat within a time period,
Horowitz discloses wherein the follower nodes communicate heartbeats to the leader node (¶0010, “…the method further comprises communicating a no-operation command from the plurality of secondary nodes to the primary node, wherein the no-operation command is a valid command that causes the primary node to perform the valid command as a non-operation and treats the receipt of the no-operation command as a heartbeat signal, and communicating, in a response to the no-op command, database state information as metadata to the plurality of secondary nodes.”), (¶0068, “… According to one implementation, such a command may comprise a no-operation (no-op) database command that relays heartbeat information. A no-operation database command may comprise a version of a normal database command that does not perform any operations on the database (e.g. write no-op command). The primary node 110 may utilize receipt of liveness commands to determine whether the secondary nodes are healthy and/or whether the primary node 110 is in communication with the secondary nodes. For example, secondary nodes 140 and 150 may communicate liveness commands to primary node 110….”).
a failure of a follower node to communicate a heartbeat within a time period (¶0006, “…However, in one implementation, the command may be issued in a no-op form during extended periods of writelessness (e.g., conveying heartbeat information without a useful write to perform). For example, by keeping track of how long it has been since the primary has heard an replSetUpdatePosition (e.g., indirectly) from all secondaries, the primary node can track how many secondaries are still responding and replicating…”), (¶0017, “… According to another embodiment, the act of detecting, by the primary node, the failure to communicate with the threshold number of secondary nodes comprises: calculating, by the primary node, an amount of time that has passed since a last received indication of liveness for each of the plurality of secondary nodes, and determining, by the primary node, that the amount of time exceeds a limit for the threshold number of the plurality of secondary nodes.”)
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the method of MATURI, JAYASINGHE, and Matican to include the follower nodes communicate heartbeats to the leader node as disclosed by Horowitz and be motivated in doing so in order to detect the health of communication between a primary node and the secondary nodes-Horowitz ¶0063 in parts.
Regarding claim 10, MATURI in view of JAYASINGHE and further in view of Matican discloses the system of claim 6.
MATURI further discloses wherein, in response to a failure of a follower node to communicate a heartbeat the leader node drops the follower node from the service-specific node group and requests a replacement node from the distributed peer-to-peer cloud infrastructure (¶0071-¶0072, “…Strictly as examples, during bring-up of the to-be-configured cluster, the management layer can detect loss of communication with a cluster member, and can remediate such a loss by invoking code that reconfigures the cluster with a replacement member. In various example scenarios, even the leader node of a to-be-configured cluster may fail, and yet, the management layer of a non-failed member can detect the loss of communication with the failed cluster member, and can then remediate that loss by invoking code that reconfigures the cluster with (1) a new leader, and (2) a replacement node to replace the failed node…”).
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose wherein the follower nodes communicate heartbeats to the leader node, and
a failure of a follower node to communicate a heartbeat within a time period,
Horowitz discloses wherein the follower nodes communicate heartbeats to the leader node (¶0010, “…the method further comprises communicating a no-operation command from the plurality of secondary nodes to the primary node, wherein the no-operation command is a valid command that causes the primary node to perform the valid command as a non-operation and treats the receipt of the no-operation command as a heartbeat signal, and communicating, in a response to the no-op command, database state information as metadata to the plurality of secondary nodes.”), (¶0068, “… According to one implementation, such a command may comprise a no-operation (no-op) database command that relays heartbeat information. A no-operation database command may comprise a version of a normal database command that does not perform any operations on the database (e.g. write no-op command). The primary node 110 may utilize receipt of liveness commands to determine whether the secondary nodes are healthy and/or whether the primary node 110 is in communication with the secondary nodes. For example, secondary nodes 140 and 150 may communicate liveness commands to primary node 110….”).
a failure of a follower node to communicate a heartbeat within a time period (¶0006, “…However, in one implementation, the command may be issued in a no-op form during extended periods of writelessness (e.g., conveying heartbeat information without a useful write to perform). For example, by keeping track of how long it has been since the primary has heard an replSetUpdatePosition (e.g., indirectly) from all secondaries, the primary node can track how many secondaries are still responding and replicating…”), (¶0017, “… According to another embodiment, the act of detecting, by the primary node, the failure to communicate with the threshold number of secondary nodes comprises: calculating, by the primary node, an amount of time that has passed since a last received indication of liveness for each of the plurality of secondary nodes, and determining, by the primary node, that the amount of time exceeds a limit for the threshold number of the plurality of secondary nodes.”)
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the system of MATURI, JAYASINGHE, and Matican to include the follower nodes communicate heartbeats to the leader node as disclosed by Horowitz and be motivated in doing so in order to detect the health of communication between a primary node and the secondary nodes-Horowitz ¶0063 in parts.
Regarding claim 15, MATURI in view of JAYASINGHE and further in view of Matican discloses the one or more non-transitory computer-readable mediums of claim 11.
MATURI further discloses wherein, in response to a failure of a follower node to communicate a heartbeat the leader node drops the follower node from the service-specific node group and requests a replacement node from the distributed peer-to-peer cloud infrastructure (¶0071-¶0072, “…Strictly as examples, during bring-up of the to-be-configured cluster, the management layer can detect loss of communication with a cluster member, and can remediate such a loss by invoking code that reconfigures the cluster with a replacement member. In various example scenarios, even the leader node of a to-be-configured cluster may fail, and yet, the management layer of a non-failed member can detect the loss of communication with the failed cluster member, and can then remediate that loss by invoking code that reconfigures the cluster with (1) a new leader, and (2) a replacement node to replace the failed node…”).
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose wherein the follower nodes communicate heartbeats to the leader node, and
a failure of a follower node to communicate a heartbeat within a time period,
Horowitz discloses wherein the follower nodes communicate heartbeats to the leader node (¶0010, “…the method further comprises communicating a no-operation command from the plurality of secondary nodes to the primary node, wherein the no-operation command is a valid command that causes the primary node to perform the valid command as a non-operation and treats the receipt of the no-operation command as a heartbeat signal, and communicating, in a response to the no-op command, database state information as metadata to the plurality of secondary nodes.”), (¶0068, “… According to one implementation, such a command may comprise a no-operation (no-op) database command that relays heartbeat information. A no-operation database command may comprise a version of a normal database command that does not perform any operations on the database (e.g. write no-op command). The primary node 110 may utilize receipt of liveness commands to determine whether the secondary nodes are healthy and/or whether the primary node 110 is in communication with the secondary nodes. For example, secondary nodes 140 and 150 may communicate liveness commands to primary node 110….”).
a failure of a follower node to communicate a heartbeat within a time period (¶0006, “…However, in one implementation, the command may be issued in a no-op form during extended periods of writelessness (e.g., conveying heartbeat information without a useful write to perform). For example, by keeping track of how long it has been since the primary has heard an replSetUpdatePosition (e.g., indirectly) from all secondaries, the primary node can track how many secondaries are still responding and replicating…”), (¶0017, “… According to another embodiment, the act of detecting, by the primary node, the failure to communicate with the threshold number of secondary nodes comprises: calculating, by the primary node, an amount of time that has passed since a last received indication of liveness for each of the plurality of secondary nodes, and determining, by the primary node, that the amount of time exceeds a limit for the threshold number of the plurality of secondary nodes.”)
Thus, one of ordinary skill in the art would have found obvious before the effective filing date of applicant’s claimed invention to modify the one or more non-transitory computer-readable mediums of MATURI, JAYASINGHE, and Matican to include the follower nodes communicate heartbeats to the leader node as disclosed by Horowitz and be motivated in doing so in order to detect the health of communication between a primary node and the secondary nodes-Horowitz ¶0063 in parts.
Claims 17 is rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al. (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to Matican et al. (hereinafter Matican) and further in view of PGPub. No. 20190075130 to Petry et al. (hereinafter Petry).
Regarding claim 17, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 16.
Matican further discloses wherein selecting the follower node comprises:
determining, from a cloud service request received from an end user, a generalized locality associated with the end user (¶0079-¶0080, “…It may be appreciated that such hints are useful in situations where the requests (from the user applications) to the distributed data service are known to be originating from a particular geographical location, and it is desirable to optimize for read/write latencies by avoiding unnecessary network overheads…”);
selecting the follower node based at least in part on the generalized locality, wherein the generalized locality identifies no more than a country, region, or state associated with the end user (¶0073-¶0075, “Referring to FIG. 4B, display area 330 depicts a “Create Universe” web page that is displayed in the browser in response to the user/customer clicking/selecting display area 415 in FIG. 4A. Display area 440 facilitates the user/customer to specify a name for the universe (e.g. “xdc-read-replicas”), the specific provider (e.g. “GCP-config”), the specific regions (e.g. “GCP-Oregon”), the number of nodes (e.g. 3) and the replication factor (e.g. 3)… It may be appreciated that the user/customer may select any desired number and/or combination of desired providers and/or regions and/or nodes in the interface of display area 440. For example, to create a universe in AWS, the user may specify the provider as “AWS-new” and the specific region(s) as “AWS-Oregon”…”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE and Matican to include selecting the follower node based at least in part on the generalized locality as disclosed by Matican and be motivated in doing so in order to ensure low-latencies for the nodes read/write operations-Matican ¶0085 in parts.
However, the combination of MATURI, JAYASINGHE, and Matican does not explicitly disclose the following limitation:
suppressing an exact Internet Protocol address and an exact geographic location of the end user from information provided to the selected follower node; and
Petry discloses suppressing an exact Internet Protocol address and an exact geographic location of the end user from information provided to the selected follower node (¶0166, “The cloud browser described herein may include a variety of policy controls for giving administrators an ability to limit, monitor, and/or otherwise govern utilization of computing resources. As elaborated upon above, the cloud browser may include an administrative portal that enables a user to set various parameters for one or more browsing sessions. The administrative portal may also enable an administrator and/or end user to set parameters for other users, individually and/or across an entire agency or organization. In some embodiments, a cloud browser and/or administrative portal thereof may provide centralized visibility into cloud browser activity and/or usage, and/or may provide centralized control of cloud browser and/or associated computing device resource access and/or usage. In some embodiments a cloud browser environment (which, e.g., may comprise an administrative portal) may provide full audit, logging, visibility, and/or traceability of cloud browser activity. In some embodiments, a cloud browser environment may provide misattribution (e.g. modify information associated with a web browsing session, such as point of geographic location and/or IP address, from computing resources providing web content) and/or non-attribution (e.g. hide and/or obscure information associated with a web browsing session from computing resources providing web content) features for enablement by an administrator and/or end user, e.g., via one or more egress nodes.”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE and Matican to include suppressing an exact Internet Protocol address and an exact geographic location of the end user from information provided to the selected follower node as disclosed by Petry and be motivated in doing so in order to provide an enhanced security and user privacy in distributed networks.
Claims 18 is rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al. (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to Matican et al. (hereinafter Matican) and further in view of PGPub. No. 20170180346 to Suarez et al. (hereinafter Suarez).
Regarding claim 18, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
However, MATURI in view of JAYASINGHE, and Matican does not explicitly disclose the following limitation:
further comprising: maintaining, in a container registry, a plurality of tagged versions of a container image that includes application service code for the cloud service;
determining, for each of the leader node and the follower nodes, whether a version of the container image running at the node satisfies a version requirement for the cloud service; and
causing a node that does not satisfy the version requirement to retrieve, from the container registry, an updated tagged version of the container image before the node processes requests for the cloud service as part of the service-specific node group.
Suarez discloses maintaining, in a container registry (¶0021, “a system including a container registry comprising one or more repositories may receive a first application programming interface request to store a container image in a repository of a customer of a computing resource service provider…”), a plurality of tagged versions of a container image that includes application service code for the cloud service (¶0028, “…TABLE-US-00001 Queries Registry , “…Returns a list of tags for images Yes in the repository; tags being used to associate container images with each other as a group (e.g., “version 1,” “version 2,” etc.) SearchRepositories( ) Allows searching of repositories Yes for files or container images”), (¶0052, “Tags may be applied to one or more container images by the customer. In some examples, a “tag” may refer to a label associated with one or more container images for the purpose of grouping the container images. For example, a tag may be created with the label “latest version.” In this example, at an initial time (time t.sub.1), a set of container images, including the initial version 346A may be tagged as the “latest version.” At the next time (time t.sub.2), another set of container images, including the second version 346B, may be updated (e.g., per request from the customer uploading the other set of container images) to be the “latest version.”…”);
determining, for each of the leader node and the follower nodes, whether a version of the container image running at the node satisfies a version requirement for the cloud service (¶0126-¶0127, “…Another example of an event of this kind may be detection by a security sweep or scanning mechanism, such as the security sweep 454 or scanning mechanism 554 of FIGS. 4 and 5 respectively, that the current running version of the software of the container image is noncompliant or contains a vulnerability such that the current running version must be updated or rolled back to a different version of the software of the container image. Still another example of an event of this kind may be that the customer has uploaded a new version of source code of the container image to an automated build service, such as the automated build service 1184 of FIG. 11, and the automated build service communicates to the system performing the process 1600 that the new version should be automatically deployed to replace the current version running in the container instance of the system.”);
causing a node that does not satisfy the version requirement to retrieve, from the container registry, an updated tagged version of the container image before the node processes requests for the cloud service as part of the service-specific node group (¶0050, “The system of the present disclosure contemplates garbage collection functionality to clean out unreferenced layers and versions from the registry 302. Unreferenced layers may include layers that have been flagged/marked as containing a security vulnerability (e.g., in the manner described in FIGS. 4 and 5… Garbage collection additionally may be performed as a security precaution; for example, in an event where a customer inadvertently uploads an insecure version of the container image (e.g., credentials embedded in a file, etc.), the customer may upload a corrected version of the container image and then call a garbage collection application programming interface to delete/remove the previous version (i.e., the insecure version) of the container image from the repository. Alternatively, rather than uploading a corrected version of the container image, the customer may call the garbage collection application programming interface to delete/remove the most recent uploaded container image (i.e., the insecure container image), and then go back to using the previous version of the container image; effectively performing a rollback….”), (¶0053, “…Returning to FIG. 3, a process for garbage collection may begin by reading the most recent manifest for the container image 352 (e.g., the one tagged “latest version”) to determine the locations of the layers for the current version of the container image 352. Then, the process may walk backwards through the previous manifests and versions of the container image 352 to locate layers not referenced by the most recent manifest. Depending on the particular implementation, these located layers may be immediately deleted or may be flagged/marked for deletion (e.g., corresponding metadata in the metadata store may be updated to include/append a code, label, or symbol signifying that the layer is to be deleted) at a later date (e.g., according to a predetermined schedule or scheme). At the later date, a deletion service or process may go through the repository, identify the layers flagged for deletion, and delete the identified layers. If all layers for an image are unlinked, the entire image may be flagged as un-referenceable, and, to the customer, may appear as though it has been deleted (e.g., the image may be inaccessible and unlistable/unviewable to the user).”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE and Matican to include whether a version of the container image running at the node satisfies a version requirement for the cloud service as disclosed by Suarez and be motivated in doing so in order to minimize deployment failures and strengthen cloud security.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al. (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to Matican et al. (hereinafter Matican) and further in view of US. PGPub. No. 20180302270 to Schreter, Ivan (hereinafter Schreter) and further in view of US. Pat. No. 6931016 to Andersson et al. (hereinafter Andersson).
Regarding claim 19, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
MATURI further discloses wherein utilizing the at least a portion of the follower nodes comprises maintaining availability of the cloud service (¶0072, “… having an established leader-follower relationships between the nodes of the cluster serves for maintaining high availability of the cluster. Specifically, clusters that are deployed in a high availability configuration can be made to be fault tolerant (e.g., tolerant to a single node failure, tolerant to a two node failure), etc. That is, if for some reason a particular node fails, the fault-tolerant configuration of such a high availability cluster is brought to bear..”) by:
requesting that the distributed peer-to-peer cloud infrastructure assign a replacement node to the service- specific node group (¶0072-¶0073, “…Strictly as examples, during bring-up of the to-be-configured cluster, the management layer can detect loss of communication with a cluster member, and can remediate such a loss by invoking code that reconfigures the cluster with a replacement member. In various example scenarios, even the leader node of a to-be-configured cluster may fail, and yet, the management layer of a non-failed member can detect the loss of communication with the failed cluster member, and can then remediate that loss by invoking code that reconfigures the cluster with (1) a new leader, and (2) a replacement node to replace the failed node. In still other example scenarios, the management layer can initiate and/or perform fault-tolerance operations that restore the cluster to a specified target intent. Such fault-tolerance operations including adding a node, removing a node, upgrading a node, rebooting a node, etc.”);
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose
receiving, at the leader node, heartbeat messages from non-leader nodes of the service- specific node group;
determining, by the leader node, that a first follower node has failed to provide a heartbeat within a predetermined time period;
transmitting, from the leader node to one or more remaining follower nodes, a query requesting whether the one or more remaining follower nodes have communicated with the first follower node;
after receiving responses from more than a minimum viable quorum of nodes, requesting that the distributed peer-to-peer cloud infrastructure assign a replacement node to the service- specific node group; and
transmitting, to the remaining follower nodes, an instruction to cease communication with the first follower node.
Schreter discloses receiving, at the leader node, heartbeat messages from non-leader nodes of the service- specific node group (¶0020, “the partition implementing the topology manager 125 can have a leader (L) and followers (F)…”), (¶0024, “summary statistics or data representative of a current level of usage of partition replicas hosted by individual nodes can be sent to the topology manager using periodic messages from each respective node to the topology manager. If such status messages are sent at some regular interval (e.g., one second for smaller clusters, several seconds for larger clusters), other the messages can be also used as liveness messages that facilitate the topology manager determining “liveness” of a node. In this manner, the topology manager may not be required to explicitly ask individual nodes of the system for a ping upon supposed unreachability of a node in the system. In this case, the liveness of the node can be determined by the time since last status message received. For example, if no status message has been received by the topology manager from a given node for some preset number of messaging periods (i.e. the regular interval at which status messages are supposed to be sent), the topology manager can consider the node to be dead and determine that a corrective action needs to be taken.”);
determining, by the leader node, that a first follower node has failed to provide a heartbeat within a predetermined time period (¶0028, “…When a node (or a client) detects a possible loss of communication, the source node (or client) detecting the potential communication break can contact the topology manager, which can make a determination of the liveness of the destination node experiencing the potential loss of communication. This determination can occur via querying other nodes in the system to obtain a quorum decision regarding liveness of the destination node in question and/or via checking at the topology manager whether a status message has been received from the destination node within some threshold time period.”), see also ¶0030;
transmitting, from the leader node to one or more remaining follower nodes, a query requesting whether the one or more remaining follower nodes have communicated with the first follower node (¶0021, “the topology manager 125 will be informed about potential failure of the destination node by the source node (assuming communication loss from the source node to a destination node that the source node finds to be unresponsive). Upon receiving such a notification, the topology manager 125 then requests from a set of other nodes in the system a confirmation of the failure. This request may be made to a full set of nodes or just a subset of nodes (e.g., a randomly-chosen subset of the nodes)…”, wherein the source node is interpreted as the claimed leader node and the destination node is the claimed follower node), see also ¶0028;
after receiving responses from more than a minimum viable quorum of nodes, requesting that the distributed peer-to-peer cloud infrastructure assign a replacement node to the service- specific node group (¶0021, “… If a quorum of these nodes in the system deems the potentially problematic node (e.g. the unresponsive destination node) to be unreachable, then that node is retired by action of the topology manager 125, and any partition replicas hosted on the now-retired node are rebalanced over other nodes of the distributed computing system, so that a replication factor is maintained after retiring the node…”), (¶0022, “After a node is retired, administrative action can occur to “fix” the retired node, for example to remedy whatever caused the retired node to lose communication with other nodes and to thereby return it to productive service, and/or to add a new node to the system…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE, and Matican to include requesting that the distributed peer-to-peer cloud infrastructure assign a replacement node to the service- specific node group as disclosed by Schreter and be motivated in doing so in order to provide load balancing of replicas of data partitions in the distributed computing system to compensate for loss of the retired computing node- Schreter abstract in parts.
The combination of MATURI, JAYASINGHE, Matican, and Schreter does not explicitly disclose the following limitation:
transmitting, to the remaining follower nodes, an instruction to cease communication with the first follower node.
Andersson discloses transmitting, to the remaining follower nodes, an instruction to cease communication with the first follower node (Coln. 6, lines 44-67 to Coln. 7, lines 1-22, “…Upon receipt of a status message from a given router 18, the manager server 14 may generate and transmit an acknowledgment of receipt of the status message. Accordingly, the manager server 14 has a poll timer that is set to count down during each given time interval. If a status message is not received from any of the routers 18 (i.e., a "non-responsive router 18") in the given VPN during one given time interval, then the Internet Protocol address of the non-responsive router 18 is deleted from the database 22a in the manager server 14. The manager server 14 then generates and transmits a second message (described above with reference to FIG. 5) to each of the routers 18 in the VPN, causing them to terminate communication with the non-responsive router 18.”, wherein having just a non-responsive router 18 is an indication that a quorum has been formed).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE, Matican, and Schreter to include transmitting, to the remaining follower nodes, an instruction to cease communication with the first follower node as disclosed by Andersson and be motivated in doing so in order to maintain the system integrity.
Claim 20 rejected under 35 U.S.C. 103 as being unpatentable over US PGPub. No. 20220138014 to MATURI et al. (hereinafter MATURI) in view of an NPL “Trustchain: A privacy preserving blockchain with edge computing” to JAYASINGHE et al. (hereinafter JAYASINGHE) and further in view of US. PGPub. No. 20190342383 to Matican et al. (hereinafter Matican) and further in view of PGPub. No. 20190020657 to Egner et al. (hereinafter Egner) and further in view of US. PGPub. No. 20040156495 to Chava et al. (hereinafter Chava).
Regarding claim 20, MATURI in view of JAYASINGHE and further in view of Matican discloses the method of claim 1.
MATURI further discloses further comprising:
storing, for each of a plurality of available nodes in the distributed peer-to-peer cloud infrastructure, a node resource profile comprising at least processor capacity, memory capacity, storage capacity, network bandwidth (¶0068-¶0069, “…Configure a cluster having three nodes, with the three nodes being collectively capable of processing at least 50K database transactions per second,” and by using any heuristics or other techniques, the expressed intent can be codified into a cluster specification 137, which is in turn processed, possibly in combination with applicable business logic 205. The intent can be codified into a cluster specification using any known technique that can serve to codify any as aspect of the to-be-configured cluster. For example, a performance-related intent of “must process 50K database transactions per second” might be codified as, “each of three nodes of a cluster are to be selected from nodes that are configured with at least 65 GB of memory and at least 2T of local storage capacity; three licenses to the database server are required…”), (¶0108, “… Adding a hyperconverged unit to a hyperconverged system expands the system in multiple dimensions. As an example, adding a hyperconverged unit to a hyperconverged system can expand the system in the dimension of storage capacity while concurrently expanding the system in the dimension of computing capacity and also in the dimension of networking bandwidth …”),
storing, for the cloud service, a service deployment profile identifying a container image for the cloud service and one or more resource requirements for executing the cloud service (¶0052-¶0053, “… the client instructions 202 may comprise (1) a request for the initiating module to configure a computing cluster in the cloud computing infrastructure 103, and (2) a general description of the intended configuration of the to-be-configured cluster. Such a request and description might be of the form, “Configure a cluster that has three nodes.” Any known techniques can be used to determine the number of nodes. At step 260, a set of nodes are drawn from the cloud infrastructure. In some cases, the initiating module allocates bare-metal nodes of the cloud computing infrastructure. In some cases, the initiating module allocates pre-imaged nodes of the cloud computing infrastructure (e.g., pre-imaged with an operating system, pre-imaged with an operating system and a virtualization system, etc.). The nodes can be allocated using APIs as may be provided by the purveyor of the cloud computing infrastructure. When step 260 completes, an allocated nodes list 138 is provided to downstream processing. In some cases, the exact number of nodes as was requested are allocated. In other cases, any number of additional nodes might be allocated so as to provide fault tolerance. Such fault tolerance is operable during bring-up as well as for ongoing operation.”);
comparing the service deployment profile with the node resource profiles to identify eligible nodes having sufficient available resources to execute the cloud service without over- provisioning the eligible nodes (¶0056, “… More specifically, each instance of the cluster management service is configured (1) to receive a cluster specification, which includes the identities of the allocated nodes that will become assigned members of the to-be-configured cluster; (2) to elect an initial leader from among the member of the to-be-configured cluster; (3) to begin autonomous operation upon receipt of a start signal; and (4) to manage self-assembly into a cluster having the specified characteristics.”), (¶0061-¶0062, “…the networking infrastructure portion of the cloud computing infrastructure has been so sufficiently configured that any node of the cluster can carry out network communications with any other node of the intended cluster over the virtualization systems networking constructs. In many cases, the specification of the intended cluster includes a virtualization system that in turn includes a hypervisor and means for executing virtual machines.”);
assigning at least a subset of the eligible nodes to the service-specific node group for the cloud service (¶0121, “A cluster is often embodied as a collection of computing nodes that can communicate between each other through a local area network (e.g., LAN or virtual LAN (VLAN)) or a backplane. Some clusters are characterized by assignment of a particular set of the aforementioned computing nodes to access a shared storage facility that is also configured to communicate over the local area network or backplane … the LAN of a first rack having a quantity of 32 computing nodes can be interfaced with the LAN of a second rack having 16 nodes to form a two-rack cluster of 48 nodes. The former two LANs can be configured as subnets, or can be configured as one VLAN. Multiple clusters can communicate between one module to another over a WAN (e.g., when geographically distal) or a LAN (e.g., when geographically proximal”);
causing the assigned eligible nodes to execute the container image for the cloud service ¶0053, (¶0053, “operation of the system may commence upon receipt of a client instruction 202. In this embodiment, the client instructions 202 may comprise (1) a request for the initiating module to configure a computing cluster in the cloud computing infrastructure 103, and (2) a general description of the intended configuration of the to-be-configured cluster. Such a request and description might be of the form, “Configure a cluster that has three nodes.” Any known techniques can be used to determine the number of nodes. At step 260, a set of nodes are drawn from the cloud infrastructure. In some cases, the initiating module allocates bare-metal nodes of the cloud computing infrastructure. In some cases, the initiating module allocates pre-imaged nodes of the cloud computing infrastructure (e.g., pre-imaged with an operating system, pre-imaged with an operating system and a virtualization system, etc.). The nodes can be allocated using APIs as may be provided by the purveyor of the cloud computing infrastructure. When step 260 completes, an allocated nodes list 138 is provided to downstream processing….”), (¶0074, “…Once the leader-follower relationships have been established, performance of bring-up operations commence (step 214). In some embodiments, the leader directs each follower to perform one or more of the list of cluster management operations 207. In other embodiments, node-specific portions of the list of cluster management operations are apportioned to respective nodes, and each respective node performs its set of bring-up operations.”); and
operating the assigned eligible nodes as worker nodes that process cloud-service work while the leader node monitors performance statistics for the service-specific node group (¶0074, “Once the leader-follower relationships have been established, performance of bring-up operations commence (step 214). In some embodiments, the leader directs each follower to perform one or more of the list of cluster management operations 207. In other embodiments, node-specific portions of the list of cluster management operations are apportioned to respective nodes, and each respective node performs its set of bring-up operations.”).
However, MATURI in view of JAYASINGHE and Matican does not explicitly disclose the following limitation:
and a C3N reputation score;
operating the assigned eligible nodes as worker nodes that process cloud-service work items routed through a message queue, while the leader node monitors performance statistics for the service-specific node group.
Egner discloses trustworthiness score mobile edge computing system (“abstract”, ¶0066, “trustworthiness rating value may be weighted or modified by factors such as compute location proximity (as determined by wireless connectivity quality or number of hops), cost levels as applicable, or trust trend values relative to prior trustworthiness score…”);
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE and Matican to include trustworthiness score of the computing system as disclosed by Egner and be motivated in doing so in order to prevent provisioning of computing resources from untrustworthy computing system to the requestor-Egner abstract in parts.
However, the combination of MATURI, JAYASINGHE and Matican, and Egner does not disclose the following limitation:
a message queue, and monitoring performance statistics for the service-specific node group.
Chava discloses operating the assigned eligible nodes as worker nodes that process cloud-service work items routed through a message queue (¶0089, “…The message forwarded from MR.sub.3 of Gateway Unit A, flows through a queue "Queue 1 Input" which is extracted by a Message Router unit (MR.sub.4) in gateway unit B. MR4 then performs basic validation of the message before forwarding the message to Authentication unit AU.sub.2 of Gateway Unit, B. AU.sub.2 authenticates the message to make sure that the message is authorized to go to Carrier B connected to gateway Unit B…”, wherein the gateway unit A, MR4, Authentication unit AU, etc are serves as the eligible nodes), (¶0198, “… Message Queue Router Routes message to a specific message queue within the message exchange network…”), monitoring performance statistics for the service-specific node group (¶0187-¶0188, “…The data then can be used for a number of purposes including display of statistics on a website, for example, for monitoring purpose; transfer of records to inter-connect networks for their internal reconciliation into billing and other systems; transfer into another data warehouse system for performing analysis on the data etc.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of MATURI, JAYASINGHE, Matican, and Egner to include message queue as disclosed by Chava and be motivated in doing so in order to enable a reliable, asynchronous communication between distributed microservices during request processing.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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, Farid Homayounmehr can be reached at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Prosecution Insights