DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-14 are pending for examination.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1, Statutory Category: Yes, the claim 1 is a method for resource sharing in an orchestrated environment that recites a series of steps and therefore falls in the statutory category of a process.
Step 2A- Prong 1: Judicial Exception Recited: Yes, the claim recites: “determining a first utilization status of first nodes of the first cluster for the purpose of providing the container instance by the first orchestration unit of the first cluster; determining a second utilization status of second nodes of the at least one second cluster by an exchange of load information between the first orchestration unit and a second orchestration unit of the at least one second cluster; selecting a target node from one of the first and second nodes according to the provisioning policy and according to the first utilization status and the second utilization status by the first orchestration unit”. As drafted, the claim as a whole recites a method including steps that could be performed in the human mind, but for the recitation of generic computing components. The human mind can easily judging/evaluating/determining/identifying a first utilization status of first nodes of the first cluster for the purpose of providing the container instance by the first orchestration unit of the first cluster, judging/evaluating/determining/identifying a second utilization status of second nodes of the at least one second cluster by an exchange of load information between the first orchestration unit and a second orchestration unit of the at least one second cluster, and selecting/choosing a target node from one of the first and second nodes according to the provisioning policy and according to the first utilization status and the second utilization status by the first orchestration unit. Therefore, but for the recitation of generic computing components, these steps may be a Mental Processes that can be performed in the human mind (including an observation, evaluation, judgment, opinion).
Therefore, yes, the claims do recite judicial exceptions.
Step 2A- Prong 2: Integrated into a practical Application: No, this judicial exception is not integrated into a practical application. In particular, the claim recites an additional limitations that “receiving a request to start the container instance including a provisioning policy in a first orchestration unit of the first cluster” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g)). In addition, “an orchestrated environment having a first cluster and at least one second cluster, in which each cluster has an orchestration unit for automatically managing a container instance on at least one node of the respective cluster” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). Moreover, the limitation of “wherein the load information is exchanged via an orchestration interface between the first orchestration unit and the second orchestration unit” which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Further, the limitation of “starting the container instance on the target node by the second orchestration unit, if the selected target node is a second node” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)). The claim has no details what so ever on how the claimed function will occur, and this limitation is Contingent limitations, it does not required to be performed, see MPEP 2111.04 II. Contingent limitations (i.e., Examiner did not need to present evidence of the obviousness of the method steps of claim 1 that are not required to be performed under a broadest reasonable interpretation of the claim). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they not impose any meaningful limits on practicing the abstract idea. Therefore, the claim is directed to the abstract idea.
Step 2B: Claim provides an Inventive Concept: No. The additional element “an orchestrated environment having a first cluster and at least one second cluster, in which each cluster has an orchestration unit for automatically managing a container instance on at least one node of the respective cluster” is an attempt to generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h))). In addition, the limitation of “wherein the load information is exchanged via an orchestration interface between the first orchestration unit and the second orchestration unit” which is directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a generic computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). Moreover, the limitation of “starting the container instance on the target node by the second orchestration unit, if the selected target node is a second node” which is merely applying the judicial exception or abstract idea (See MPEP 2106.05(f)). Further, the limitation of “receiving a request to start the container instance including a provisioning policy in a first orchestration unit of the first cluster” (insignificant pre-solution data gathering (see MPEP § 2106.05(g))) which are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f))). These additional elements and combination of the elements does not amount to significant more than the exception itself or provide an inventive concept in Step 2B.
Under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B. Here, the “receiving” step was considered to be extra-solution activity in Step 2A as insignificant data gathering and communication and are well understood, routine, conventional activity in the field. The “receiving” step was for the purpose of “communication” and “transmitting the data” and these can be reached on one of court case (Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) see MPEP § 2106.05(d) II). Accordingly, a conclusion that “receiving” step is well understood, routine, conventional activity is supported under Berkheimer options 2.
For these reasons, there is no inventive concept in the claim, and thus the claim is ineligible.
Independent claims 13 and 14 are rejected for the same reason as claim 1 above. Claim 13 further recites “an assembly for resource sharing”. Claim 14 further recites “a computer program product comprising a computer readable hardware storage device have computer readable program code stored therein”. These additional elements are directed to generic computing components/functions merely applying the abstract idea (MPEP § 2106.05(f)).
With respect to the dependent claim 2, the claim elaborates that wherein a specific node or a node type and/or properties of the node, on which the container instance may be started, are specified in the provisioning policy (this limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 3, the claim elaborates that wherein in the provisioning policy it is specified whether the container instance may be started only on one of the first nodes or also on one of the second nodes (this limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 4, the claim elaborates that wherein a container instance, the execution of which is not limited to a particular node, is started either on one of the first or on one of the second nodes depending on the first and second utilization status (this limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 5, the claim elaborates that wherein within the first or second cluster a residual capacity of resources for starting container instances is reserved by the orchestration unit of its own cluster, which is not approved for starting a container instance from the other cluster (this limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 6, the claim elaborates that wherein if the container instance is executed by the second node, the first orchestration unit is notified by the second orchestration unit when the second utilization status increases above a specified maximum value, and the execution of the container instance on the second node is terminated(“notified by the second orchestration unit when the second utilization status increases above a specified maximum value” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g))) and are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)). In addition, “the execution of the container instance on the second node is terminated” are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 7, the claim elaborates that wherein load information is exchanged via the orchestration interface only after a successful mutual authentication of the first orchestration unit and the second orchestration unit (These limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 8, the claim elaborates that wherein the load information is exchanged at fixed time intervals or based on a resource allocation event between the first and the second orchestration unit (These limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 9, the claim elaborates that wherein the first orchestration unit: receives different authorizations with regard to the configuration of container instances or the resource allocation on the second node depending on the second orchestration unit. (“receives different authorizations” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g))) and are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 10, the claim elaborates that wherein the load information is transmitted from the second orchestration unit to a central utilization unit and the load information is queried from the central utilization unit by the first orchestration unit (These limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 11, the claim elaborates that wherein the first orchestration unit is registered with a publish subscribe service as a subscriber and the at least one second orchestration unit is registered as a publisher and the first orchestration unit receives the load information of the second nodes automatically by the publish subscribe service (These limitations are directed to Adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
With respect to the dependent claim 12, the claim elaborates that wherein the first orchestration unit transmits the request to start the container instance to the orchestration unit of the selected target node (“transmits the request to start the container instance” which is insignificant pre-solution data gathering (see MPEP § 2106.05(g))) and are well understood, routine, conventional activity (see MPEP § 2106.05(d)). Courts have identified “receiving and transmitting data, storing and retrieving information”, et cetera as well understood, routine, conventional and mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (see MPEP 2106.05(f)).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “first/second cluster” and “first/second orchestration unit” in claim 13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
Claim limitations “first/second cluster” and “first/second orchestration unit” in claim 13 invokes 35 U.S.C. 112(f). The specification paragraph [0038] that discloses “The assembly and, in particular, the physical as well as the virtual realization of nodes, orchestration units and the like therein, can comprise one or more processors.” as performing corresponding structure. However, said “first/second cluster” and “first/second orchestration unit” in claim 13 without the detail about the means to accomplish the functions are not an adequate disclosure of corresponding structure (i.e., they are general purpose computer and they are not sufficient structure to be corresponding structure under 112(f). That is, the general purpose computer must be transformed into a specially programmed computer by way of an algorithm). MPEP § 2181(II)(B) specifically indicated that “For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b). See Net MoneyIN, Inc. v. Verisign. Inc., 545 F.3d 1359, 1367, 88 USPQ2d 1751, 1757 (Fed. Cir. 2008). See also In re Aoyama, 656 F.3d 1293, 1297, 99 USPQ2d 1936, 1939 (Fed. Cir. 2011) ("[W]hen the disclosed structure is a computer programmed to carry out an algorithm, ‘the disclosed structure is not the general purpose computer, but rather that special purpose computer programmed to perform the disclosed algorithm.’") (quoting WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339, 1349, 51 USPQ2d 1385, 1391 (Fed. Cir. 1999))” and “The corresponding structure is not simply a general purpose computer by itself but the special purpose computer as programmed to perform the disclosed algorithm. Aristocrat, 521 F.3d at 1333, 86 USPQ2d at 1239. Thus, the specification must sufficiently disclose an algorithm to transform a general purpose microprocessor to the special purpose computer” Therefore, the claim (i.e., 13) is indefinite and is rejected under 35 U.S.C. 112(b).
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 13 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The claim 13 contain subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above in 112(f) (i.e., “first/second cluster” and “first/second orchestration unit” in claim 13), the disclosure does not provide adequate structure to perform the claimed functions. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention. See MPEP § 2181(II)(B) “When a claim containing a computer-implemented 35 U.S.C. 112(f) claim limitation is found to be indefinite under 35 U.S.C. 112(b) for failure to disclose sufficient corresponding structure (e.g., the computer and the algorithm) in the specification that performs the entire claimed function, it will also lack written description under 35 U.S.C. 112(a)”.
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.
Claims 1-14 are rejected under 35 U.S.C. 112(b), 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 pre-AIA the applicant regards as the invention.
As per claim 13:
As described above in 112(f) (i.e., “first/second cluster” and “first/second orchestration unit” in claim 13) without the detail about the means to accomplish the functions are not an adequate disclosure of corresponding structure. The MPEP § 2181(II)(B) specifically indicated that “For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b). See Net MoneyIN, Inc. v. Verisign. Inc., 545 F.3d 1359, 1367, 88 USPQ2d 1751, 1757 (Fed. Cir. 2008). See also In re Aoyama, 656 F.3d 1293, 1297, 99 USPQ2d 1936, 1939 (Fed. Cir. 2011) ("[W]hen the disclosed structure is a computer programmed to carry out an algorithm, ‘the disclosed structure is not the general purpose computer, but rather that special purpose computer programmed to perform the disclosed algorithm.’") (quoting WMS Gaming, Inc. v. Int’l Game Tech., 184 F.3d 1339, 1349, 51 USPQ2d 1385, 1391 (Fed. Cir. 1999))”. Therefore, the claim 13 is indefinite and is rejected under 35 U.S.C. 112(b).
As per claims 1 and 13-14 (line# refers to claim 1):
In line 18, it recites the phrase “a second node”. However, prior to this phrase at line 10, it recites “second nodes”. Thus, it is unclear whether the second recitation of “a second node” is the same or different from the first recitation of “second nodes” (i.e., is that second node is one of the second nodes? or just any node? For examining purpose, examiner will interpret as any node.
As per claim 12:
Lines 2-3, “the orchestration unit” lacks antecedence basis. It is uncertain if this term intent to refer to “the second orchestration unit” as cited in claim 1, lines 17-18.
As per claims 2-12:
They are method claims that depend from rejected claims and do not resolve the deficiencies thereof and are therefore rejected for the same reasons as above.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 9 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Bahl et al. (US Pub. 2021/0019194 A1) in view of DOUDALI et al. (US Pub. 2020/0019426 A1) and further in view of ALNAS et al. (US Pub. 2020/0304422 A1).
Bahl was cited in the IDS filed on 02/27/2024.
As per claim 1, Bahl teaches the invention substantially as claimed including A method for resource sharing in an orchestrated environment having a first cluster and at least one second cluster, in which each cluster has an orchestration unit for automatically managing a container instance on at least one node of the respective cluster comprising (Bahl, Fig. 2, 202 master (as orchestration unit), 220A to 220B workers (as node); POD 226, microservice containers 228A; [0040] lines 3-8, Each cluster can comprise one or more hosts. In this example, the cluster includes a master 202 and workers 220A and 220B (collectively, 220); [0041] lines 1-8, The master 202 can operate as a control plane for the cluster. For example, the master 202 can be responsible for the global, cluster-level scheduling of pods (e.g., sets of one or more containers) and the handling of events):
receiving a request to start the container instance including a provisioning policy in a first orchestration unit of the first cluster (Bahl, [0041] lines 1-13, The master 202 can operate as a control plane for the cluster. For example, the master 202 can be responsible for the global, cluster-level scheduling of pods (e.g., sets of one or more containers) and the handling of events (e.g., starting up a new pod when additional computing resources are needed). The master 202 can include an Application Programming Interface (API) server 204, a controller manager 206, a scheduler 208, and a distributed Key Value (KV) store 210. These components of the master 202 can run on any host in the cluster but usually run on the same (physical or virtual) machine without the workers 220; [0090] receive a request to deploy an application as a service mesh application. The service mesh application can be associated with governance information including user-defined criteria that response times for the application not exceed a maximum response time and to minimize TCO. Each microservice container of the application can represent a learning agent of a fully cooperative SG having the common goal of minimizing TCO while constrained by the SLA requirement. The decision module 424 can define the state space for each microservice container as the set of possible deployment configurations for that microservice container (e.g., deployment in a first CSP network using a reserved compute instance, deployment in a second CSP network using a reserved compute instance, deployment in an unreserved compute instance in the first CSP network, deployment in an unreserved compute instance in the second CSP network, etc.). The decision module 424 can define the action space for each microservice container as the transitions from one (valid) state to another (e.g., doing nothing and remaining deployed in its current compute instance; provisioning a reserved compute instance in the second CSP network, migrating the microservice container to the newly provisioned compute instance, terminating or hibernating the provisioned compute instance in the first CSP network, etc).
Bahl fails to specifically teach determining a first utilization status of first nodes of the first cluster for the purpose of providing the container instance by the first orchestration unit of the first cluster; determining a second utilization status of second nodes of the at least one second cluster by an exchange of load information between the first orchestration unit and a second orchestration unit of the at least one second cluster; selecting a target node from one of the first and second nodes according to the provisioning policy and according to the first utilization status and the second utilization status by the first orchestration unit and starting the container instance on the target node by the second orchestration unit, if the selected target node is a second node, wherein the load information is exchanged via an orchestration interface between the first orchestration unit and the second orchestration unit.
However, DOUDALI teaches determining a first utilization status of first nodes of the first cluster for the purpose of providing the container instance by the first orchestration unit of the first cluster (DOUDALI, Fig. 3A, first physical host 350 (as first cluster), First VM 310, second VM 320, fourth VM 340 (as first nodes); [0003] The container scheduler can receive a request to deploy a container. In response to the request, the container scheduler can (1) apply user-defined constrains and policies to identify an initial candidate list of virtual machines for where to deploy the container and (2) send information (e.g., container information) to a virtual machine scheduler (sometimes referred to as an infrastructure scheduler, which can be responsible for scheduling virtual machines based on a cluster's resources). In some embodiments, the information includes a list of one or more virtual machines on which the container can be deployed; [0007] determining resource utilization data for each physical host of the plurality of physical hosts. The method also includes identifying, based on the resource utilization data and the first information, a virtual machine of the plurality of virtual machines; [0033] Virtual machine scheduler 120 can execute at the container, virtual machine, or host level. Further, in some examples, virtual machine scheduler 120 can execute on a physical host (e.g., physical host 110, physical host 112; [0042] the virtual machine scheduler (as first orchestration unit of first cluster (i.e., physical host 110) can determine resource utilization data for physical hosts);
determining a second utilization status of second nodes of the at least one second cluster (DOUDALI, Fig. 1, 112 second physical host, 134 and 136; [0007] determining resource utilization data for each physical host of the plurality of physical hosts. The method also includes identifying, based on the resource utilization data and the first information, a virtual machine of the plurality of virtual machines; 120 virtual machine scheduler, 140 container scheduler; [0003] The container scheduler can receive a request to deploy a container. In response to the request, the container scheduler can (1) apply user-defined constrains and policies to identify an initial candidate list of virtual machines for where to deploy the container and (2) send information (e.g., container information) to a virtual machine scheduler; [0042] the virtual machine scheduler (as first orchestration unit) can determine resource utilization data for physical hosts);
selecting a target node from one of the first and second nodes according to the provisioning policy and according to the first utilization status and the second utilization status by the first orchestration unit (DOUDALI, Fig. 3A; Fig. 3B; [0003] The container scheduler can receive a request to deploy a container. In response to the request, the container scheduler can (1) apply user-defined constrains and policies to identify an initial candidate list of virtual machines for where to deploy the container and (2) send information (e.g., container information) to a virtual machine scheduler (sometimes referred to as an infrastructure scheduler, which can be responsible for scheduling virtual machines based on a cluster's resources). In some embodiments, the information includes a list of one or more virtual machines on which the container can be deployed; [0051] When determining a virtual machine for deployment of a container, the scheduling process can determine resource utilization data for each of the three virtual machines 310-330, but not virtual machine 340 (recall that a container scheduler cannot determine resource utilization data for a VM not executing containers). The resource utilization data can indicate (1) the amount of resources consumed by each virtual machine 310-330 (e.g., as illustrated by load 312), (2) whether a virtual machine includes a replica of a container to be deployed, or (3) any combination thereof; [0055] the second scheduling process can determine resource utilization data for each of the identified one or more physical hosts. Based on the resource utilization data, the second scheduling process can identify a physical host. For example, the second scheduling process can determine that second physical host 360 has a higher percentage of unused resources (or higher amount of unused resources) as compared to first physical host 350 and as a result is better suited for deployment of the requested container despite that the virtual machine executing on second physical host 360 has the greatest resource usage of the virtual machines visible to the first scheduling process. After identifying second physical host 360, the second scheduling process can either (1) identify a subset of the virtual machines executing on second physical host 360 or (2) identify each virtual machine running on second physical host 360. Identified virtual machines can be referred to as candidate virtual machines); and
starting the container instance on the target node by the second orchestration unit, if the selected target node is a second node (DOUDALI, [0013] Each of the plurality of virtual machines can be configured to execute one or more containers; [0036] container scheduler 140 can, in some instances, schedule containers on highly loaded physical hosts; [0047] once the container scheduler (as second orchestration unit) has identified a virtual machine (as target node), the container scheduler can deploy the container on the identified virtual machine (270). For example, the container scheduler can cause the container to begin executing (as starting) on the identified virtual machine; also see [0037] container scheduler 140 can execute at the container, virtual machine, or host level. Further, in some examples, container scheduler 140 executes on a physical host [Examiner noted: this limitation is Contingent limitations, it does not require that step actually happening see MPEP 2111.04 II. Contingent limitations (i.e., Examiner did not need to present evidence of the obviousness of the method steps of claim 1 that are not required to be performed under a broadest reasonable interpretation of the claim)]).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl with DOUDALI because DOUDALI’s teaching of starting executing the container on a selected node based on the resource utilizations of different clusters (hosts) would have provided Bahl’s system with the advantage and capability to allow the system to easily identifying a node for executing the container based on the resource utilization in order to improving the system resource management and efficiency (see DOUDALI, [0002]).
Bahl and DOUDALI fail to specifically teach when determining a second utilization status of second nodes, it is by an exchange of load information between the first orchestration unit and a second orchestration unit of the at least one second cluster, and wherein the load information is exchanged via an orchestration interface between the first orchestration unit and the second orchestration unit.
However, ALNAS teaches when determining a second utilization status of second nodes, it is by an exchange of load information between the first orchestration unit and a second orchestration unit of the at least one second cluster, and wherein the load information is exchanged via an orchestration interface between the first orchestration unit and the second orchestration unit (ALNAS, Fig. 4; [0095] lines 1-17, an interface 33 is configured between the management entities 300, x300 in different EC systems 31, 32, e.g. orchestrators of MEC systems 31, 32, which interface 33 is used for exchanging EC service availability information between EC systems. The interface 33 may be employed by the management entities 300, x300 of different EC systems 31, 32 to set up respective CSRs 310, x310 for exchange of availability information related to services. In FIGS. 3 and 4, the interface 33 is logically illustrated between the respective CSRs 310, 310x, but the proposed solutions, in which the first EC system has a CSR 310 does not require that the second EC system 32 has a corresponding CSR x310. In alternative embodiments, the management entity x300 of the second EC system 32 may be configured to obtain service availability information from the CSR 310 and use that information for instantiating applications in a host x220, and potentially updating a local service registry in that EC host x220; please note: load information/utilization is taught by DOUDALI).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl and DOUDALI with ALNAS because ALNAS’s teaching of exchange the information between different systems by utilizing respective orchestrators via an interface would have provided Bahl and DOUDALI’s system with the advantage and capability to allow the system to easily identifying and managing the resource utilization among the different cluster/systems in order to improving the system performance and efficiency.
As per claim 2, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. DOUDALI further teaches wherein a specific node or a node type and/or properties of the node, on which the container instance may be started, are specified in the provisioning policy (DOUDALI, [0003] The container scheduler can receive a request to deploy a container. In response to the request, the container scheduler can (1) apply user-defined constrains and policies to identify an initial candidate list of virtual machines for where to deploy the container and (2) send information (e.g., container information) to a virtual machine scheduler (sometimes referred to as an infrastructure scheduler, which can be responsible for scheduling virtual machines based on a cluster's resources). In some embodiments, the information includes a list of one or more virtual machines on which the container can be deployed. In such embodiments, the information can further include (1) resource requirements of the container to be scheduled and (2) policies configured for the container to be scheduled (e.g., a policy indicating that a particular container should be (1) run on a physical host with a particular label or (2) not run on a physical host that already has another container of the same type or another container with a particular label).
As per claim 3, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. DOUDALI further teaches wherein in the provisioning policy it is specified whether the container instance may be started only on one of the first nodes or also on one of the second nodes (DOUDALI, [0010] The first information can include a resource requirement of a container to be deployed, a policy associated with the first scheduling process, a ranking of the plurality of virtual machines, or any combination thereof. The policy associated with the first scheduling process can relate to identifying a virtual machine to be used to deploy a container. The ranking can be determined by the first scheduling process; [0013] identifying, based on the resource utilization data, a physical host of the plurality of physical hosts, where identifying the virtual machine is further based on the identified physical host. Each of the plurality of virtual machines can be configured to execute one or more containers).
As per claim 4, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. DOUDALI further teaches wherein a container instance, the execution of which is not limited to a particular node, is started either on one of the first or on one of the second nodes depending on the first and second utilization status (DOUDALI, Fig. 3A, utilization; [0052] Based on the resource utilization data, the scheduling process can determine to deploy a new container on second VM 320, because second VM 320 is using less of its allocated resources than other virtual machines viewable by the scheduling process (e.g., VMs 310, 330). Such a decision may not be optimal as the load 332 of first physical host 350 is relatively high compared to the load 336 of second physical host 360; [0055] the second scheduling process can determine resource utilization data for each of the identified one or more physical hosts. Based on the resource utilization data, the second scheduling process can identify a physical host. For example, the second scheduling process can determine that second physical host 360 has a higher percentage of unused resources (or higher amount of unused resources) as compared to first physical host 350 and as a result is better suited for deployment of the requested container despite that the virtual machine executing on second physical host 360 has the greatest resource usage of the virtual machines visible to the first scheduling process).
As per claim 9, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. Bahl further teaches wherein the first orchestration unit: receives different authorizations with regard to the configuration of container instances or the resource allocation on the second node depending on the second orchestration unit (Bahl, [0057] The security module 308 (e.g., Istio® Citadel) can manage service authentication, authentication policy, role-based access control, Transport Layer Security (TLS) authentication, and keys/certificates. In some embodiments, the security module 308 can issue x509 certificates to the microservice containers 228, allowing for mutual TLS (mTLS) between the microservices and transparent encryption of their traffic. In some embodiments, the security module 308 may use microservice identity built into the underlying container orchestrator to generate certificates. This identity can allow for policy enforcement; [0053] applications can depend on various network functions from their infrastructure, such as load balancing, traffic management, routing, health monitoring, security policies, service and user authentication, protection against intrusion and DDoS attacks, and so forth).
As per claim 13, it is an assembly of resource haring in an orchestrated environment claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 14, it is a computer program product claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of KOSMISKAS (US Pub. 2017/0031680 A1).
As per claim 5, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. Bahl further teaches wherein within the first or second cluster a residual capacity of resources for starting container instances is reserved by the orchestration unit of its own cluster (Bahl, Fig. 2; [0083] The decision module 424 can determine whether to scale up, scale down, or maintain the same amounts of computing resources for deploying the service mesh application, intermediate components, and the microservice containers 228 based on the volume of client requests to the application, intermediate components, and the microservice containers (e.g., obtained via the request metering module 416), computing resources utilized by and reserved for the application, intermediate components, and the microservice containers (e.g., obtained via the resource metering module 418), and governance metrics relative to governance requirements for the application, intermediate components, and the microservice containers (e.g., obtained via the unreserved metering module 422). In addition, the decision module 424 can determine how and where to provision the computing resources for the application, intermediate components, and the microservice containers 228 based on the availability of unreserved computing resources and monetary cost constraints, SLA requirements, and other governance information applicable at various levels of the application hierarchy; [0107] multi-cloud service mesh orchestration platform can select the CSP-specific resources for deploying the microservice containers and the sidecar proxies for interconnecting the microservices. This can include determining whether to deploy the microservice containers and sidecar proxies using unreserved computing resources or reserved computing resources. This can also include determining the characteristics of the virtual machines and/or containers to provision, such as the type of CPU, number of CPU cores, CPU processing rate, type of GPU, number of GPU cores, GPU processing rate, amount of memory, type of storage, amount of storage, storage bandwidth, type of hypervisor or other virtualization management software, and so forth).
Bahl, DOUDALI and ALNAS fail to specifically teach which is not approved for starting a container instance from the other cluster.
However, KOSMISKAS teaches which is not approved for starting a container instance from the other cluster (KOSMISKAS, [0007] lines 1-8, an entire VM is required even if the user requires access to a single Android app. The VM needs to be started with all necessary components to support the Android runtime. The amount of resources used by the environment may greatly exceed the resources needed by the Android app itself. The high resource requirement prevents VMs from being deployed to devices other than servers and desktops, such as mobile phones and tablets).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with KOSMISKAS because KOSMISKAS’s teaching of prevents VMs from being deployed to devices other than servers and desktops would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to ensuring all necessary component/resources are needed in order to improving the system performance and efficiency.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of Miyazaki (US Pub. 2015/0234673 A1).
As per claim 6, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. Bahl, DOUDALI and ALNAS fail to specifically teach wherein if the container instance is executed by the second node, the first orchestration unit is notified by the second orchestration unit when the second utilization status increases above a specified maximum value, and the execution of the container instance on the second node is terminated.
However, Miyazaki teaches wherein if the container instance is executed by the second node, the first orchestration unit is notified by the second orchestration unit when the second utilization status increases above a specified maximum value, and the execution of the container instance on the second node is terminated (Miyazaki, Fig. 3; Claim 1, a first information processing device; and a second information processing device connected to the first information processing device via a switch device, wherein the first information processing device includes a first processor configured, for performing migration of a virtual machine running on the first information processing device to the second information processing device, to start memory transfer for transferring memory data related to the virtual machine to the second information processing device, stop, when an accumulated amount of transferred memory data exceeds a first threshold, packet transmission performed by the virtual machine and transmit a prior shut-down notice to the second information processing device, the prior shut-down notice notifying that the virtual machine is to be shut-down, receive a first control message including address information of the virtual machine, and shut down the virtual machine when the accumulated amount exceeds a second threshold, and the second information processing device includes a second processor configured to transmit, upon receiving the prior shut-down notice from the first information processing device, the first control message to the switch device and the first information processing device, cause a virtual network interface to start reception of packets destined for the virtual machine, start up, when the memory transfer is completed, the virtual machine to start the packet transmission, and output packets held in the virtual network interface to the virtual machine).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with Miyazaki because Miyazaki’s teaching of providing the notice when the VM exceeds a second threshold and need to be shutdown would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to easily determining the status of the VMs which improving the system performance and efficiency.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of Wane (US Pub. 2016/0007190 A1).
As per claim 7, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. ALNAS further teaches wherein load information is exchanged via the orchestration interface of the first orchestration unit and the second orchestration unit (ALNAS, Fig. 4; [0095] lines 1-17, an interface 33 is configured between the management entities 300, x300 in different EC systems 31, 32, e.g. orchestrators of MEC systems 31, 32, which interface 33 is used for exchanging EC service availability information between EC systems. The interface 33 may be employed by the management entities 300, x300 of different EC systems 31, 32 to set up respective CSRs 310, x310 for exchange of availability information related to services. In FIGS. 3 and 4, the interface 33 is logically illustrated between the respective CSRs 310, 310x, but the proposed solutions, in which the first EC system has a CSR 310 does not require that the second EC system 32 has a corresponding CSR x310. In alternative embodiments, the management entity x300 of the second EC system 32 may be configured to obtain service availability information from the CSR 310 and use that information for instantiating applications in a host x220, and potentially updating a local service registry in that EC host x220).
Bahl, DOUDALI and ALNAS fail to specifically teach wherein load information is exchanged only after a successful mutual authentication.
However, Wane teaches wherein load information is exchanged only after a successful mutual authentication (Wane, [0069] Once each profile manager is post-personalized into the eUICC, the MNOHUB server 102 is the only entity with the capacity of exchanging data with them, as a mutual-authentication procedure is always required before provisioning (e.g., CREATE PROFILE, INSTALL PROFILE, DELETE PROFILE, etc.) can be performed).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with Wane because Wane’s teaching of mutual-authentication procedure would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to verify the identity of the entities in order to improving the system security and performance.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of Mantri et al. (US Pub. 2022/0269571 A1).
As per claim 8, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. Bahl, DOUDALI and ALNAS fail to specifically teach wherein the load information is exchanged at fixed time intervals or based on a resource allocation event between the first and the second orchestration unit.
However, Mantri teaches wherein the load information is exchanged at fixed time intervals or based on a resource allocation event between the first and the second orchestration unit (Mantri, [0011] such site-to-site (i.e., peer-to-peer) resource availability monitoring may be extended to additional consideration associated with resource deployment in the event of DR failover such as (i) the type and criticality of the deployable resources at a site, (ii) rendering of decisions to deploy those resources, (iii) the dynamic nature of actual deployment of those resources; and/or (iv) a messaging protocol employed to convey resource utilization and availability at the sites so as to ascertain one or more sites suitable for failover. Notably the messaging protocol to convey (i.e., exchange) resource utilization and availability may occur on-demand (i.e., in response to a proposed VM configuration change) or at periodic intervals and may manifest as push or pull communications (i.e., sent without specific request or in response to a request)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with Mantri because Mantri’s teaching of exchanging resource utilization and availability may occur on-demand (i.e., in response to a proposed VM configuration change) or at periodic intervals would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to easily determining the resource utilization without specific request which improving the system efficiency and performance (see Mantri, [0011]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of Hampton (US Patent. 11,163,606 B1).
As per claim 10, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. ALNAS teaches wherein the load information is transmitted from the second orchestration unit (ALNAS, Fig. 4; [0095] lines 1-17, an interface 33 is configured between the management entities 300, x300 in different EC systems 31, 32, e.g. orchestrators of MEC systems 31, 32, which interface 33 is used for exchanging EC service availability information between EC systems. The interface 33 may be employed by the management entities 300, x300 of different EC systems 31, 32 to set up respective CSRs 310, x310 for exchange of availability information related to services. In FIGS. 3 and 4, the interface 33 is logically illustrated between the respective CSRs 310, 310x, but the proposed solutions, in which the first EC system has a CSR 310 does not require that the second EC system 32 has a corresponding CSR x310. In alternative embodiments, the management entity x300 of the second EC system 32 may be configured to obtain service availability information from the CSR 310 and use that information for instantiating applications in a host x220, and potentially updating a local service registry in that EC host x220).
Bahl, DOUDALI and ALNAS fail to specifically teach wherein the load information is to a central utilization unit and the load information is queried from the central utilization unit by the first orchestration unit.
However, Hampton teaches wherein the load information is to a central utilization unit and the load information is queried from the central utilization unit by the first orchestration unit (Hampton, Col 5, lines 56-62, thread manager updater adapted to access the shared resource, obtain the resource utilization metric, and store the resource utilization metric at a storage location, wherein each thread pool manager accesses the resource utilization metric at the storage location).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with Hampton because Hampton’s teaching of storing the resource utilization within a shared storage location and allowing all other managers to access and queries would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to easily sharing the resource utilization among different systems which improving the resource utilization and system performance.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of Zucknovich et al. (US Pub. 2013/0246498 A1).
As per claim 11, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. ALNAS teaches the first orchestration unit receives the load information of the second nodes (ALNAS, Fig. 4; [0095] lines 1-17, an interface 33 is configured between the management entities 300, x300 in different EC systems 31, 32, e.g. orchestrators of MEC systems 31, 32, which interface 33 is used for exchanging EC service availability information between EC systems. The interface 33 may be employed by the management entities 300, x300 of different EC systems 31, 32 to set up respective CSRs 310, x310 for exchange of availability information related to services. In FIGS. 3 and 4, the interface 33 is logically illustrated between the respective CSRs 310, 310x, but the proposed solutions, in which the first EC system has a CSR 310 does not require that the second EC system 32 has a corresponding CSR x310. In alternative embodiments, the management entity x300 of the second EC system 32 may be configured to obtain service availability information from the CSR 310 and use that information for instantiating applications in a host x220, and potentially updating a local service registry in that EC host x220).
Bahl, DOUDALI and ALNAS fail to specifically teach wherein the first orchestration unit is registered with a publish subscribe service as a subscriber and the at least one second orchestration unit is registered as a publisher and the first orchestration unit receives the load information of the second nodes automatically by the publish subscribe service.
However, Zucknovich teaches wherein the first orchestration unit is registered with a publish subscribe service as a subscriber and the at least one second orchestration unit is registered as a publisher and the first orchestration unit receives the load information of the second nodes automatically by the publish subscribe service (Zucknovich, [0051] Some of this data is associated with a publication registration which may be published as initialization files, change files, or incremental summary update files as well as other types of data sets and files. FIG. 5 illustrates example data included in a publication registration. In operation, the content management servers 202, 203, 204 may receive publication registrations and store the same in non-cache memory so that consumption application servers 208 can interrogate and thereafter, subscribe to receive the publisher data sets. As shown in the FIG. 3 example, the publication application server 206 may be located in different geographies and connect to different content management servers 202, 203, and 204. All content management servers 202, 203, 204 are aware of each other and communicate updates of information to each other; [0057] FIG. 7 shows an example consumption data set registration provided by a consumption entity, such as consumption application server 206. The consumption data set registration includes a set of registrations of interest identifying one or more publisher data sets. In one embodiment, for example, the consumption application server 206 registers each publisher data set it will use, along with attributes including required permissions that are needed to receive the publisher data set, the frequency of consumption, and the nature of how the publisher data set will be processed. The consumption data set registration can be consumed as initialization files, change files, or incremental summary update files, as well as other types of files. The content management servers 202, 203, 204 receive this registration and store it for use in executing a routing algorithm to route the publisher data set from the publication application server 206 to the consumption application server 208. The consumption application server 208 may interrogate and subscribe to receive the publisher data sets based on a set of permissions that the consumption application server has available to it. The consumption application server 208 may be located in different geographical locations and connect to different content management servers 202, 203, and 204. The content management servers 202, 203, 204 communicate with one another. In one embodiment, each instance of the content management servers in different geographical locations maintains a single list that indicates one or more consumption application server 208 registered to receive the publisher data set, along with each of the published data sets required to be delivered to the consumption application server 208, and details concerning what publisher data set the consumption application server is to consume by communicating among the content management servers 202, 204, 204).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with Zucknovich because Zucknovich’s teaching of exchanging the information based on registered publisher and registered subscriber would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to easily communicating the data by publisher and subscriber relationship in order to improving the data communication efficiency and system performance.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Bahl, DOUDALI and ALNAS, as applied to claim 1 above, and further in view of HOLZMAN et al. (US Pub. 2023/0035600 A1).
As per claim 12, Bahl, DOUDALI and ALNAS teach the invention according to claim 1 above. Bahl, DOUDALI and ALNAS fail to specifically teach wherein the first orchestration unit transmits the request to start the container instance to the orchestration unit of the selected target node.
However, HOLZMAN teaches wherein the first orchestration unit transmits the request to start the container instance to the orchestration unit of the selected target node (HOLZMAN, Fig. 1, 122, 128; Fig. 2, 122, 128; Abstract, This disclosure relates generally to creating and managing cloud infrastructure, and more specifically, integrating one or more cloud infrastructure tools for building cloud infrastructures. An example method includes, receiving a request to deploy a cloud infrastructure on a cloud service provider based on a cloud template of the cloud management platform; transmitting configuration instructions associated with a cloud infrastructure tool to a container orchestration platform for execution on one or more containers running on the container orchestration platform to deploy the cloud infrastructure; receiving a deployment state of the cloud infrastructure on the cloud service provider from the container orchestration platform following execution of the configuration instructions; and reporting a status of the cloud infrastructure based on the deployment state; please note: selected node was taught by DOUDALI).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Bahl, DOUDALI and ALNAS with HOLZMAN because HOLZMAN’s teaching of transmitting configuration instructions associated with a cloud infrastructure tool to a container orchestration platform for execution would have provided Bahl, DOUDALI and ALNAS’s system with the advantage and capability to allow the system to easily managing the container execution and deployment in order to improving the system performance and efficiency.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee J Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ZUJIA XU/Examiner, Art Unit 2195
Prosecution Insights