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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9/11/2025 has been entered.
Response to Arguments
Applicant's arguments filed 7/11/2025 and 9/11/2025 have been fully considered.
The drawing and specification objections are withdrawn in view of the applicant’s amendments and corresponding remarks. The applicant’s amendments filed on 9/11/2025 have addressed the rejections based on 35 USC section 112(b) that were presented in the 3/11/2025 Office action. The applicant’s arguments regarding the scope of claims 1, 13, and 15 are persuasive in overcome the second written description issue presented in the 3/11/2025 Office action.
The applicant’s arguments regarding the remaining written description rejections have been considered but they are not persuasive. The applicant’s lecture regarding Kubernetes, on page 11 of the 7/11/2025 response, is irrelevant to the issues presented. Nowhere in the originally filed disclosure does the applicant incorporate any Kubernetes “official document” by reference (see section 608.01(p) of the MPEP and 37 CFR 1.57) nor did the applicant provide any statements in the originally filed disclosure that the orchestration loop is performed using a “well known and well documented” Kubernetes solution. The applicant has cited a URL but this is not evidence of what was known in the art at the time of the invention because the URL only represents what is currently published at a website when the URL is accessed. Further, the Examiner accessed the URL and did not find any information that supported the applicant’s arguments about what is “well known and well documented in Kubernetes solution”. If the applicant wants to formally submit evidence, they may use the procedure explained in section 609.05(c) of the MPEP to submit specific documents and it would be helpful if the applicant referred to specific teachings in such documents when making their argument about what is “well known and well documented”.
There is no reason to believe the original disclosure intended for the orchestration loop to be implemented in any other manner than it was explicitly disclosed. The originally filed disclosure does not refer to the orchestration loop as incorporating any teachings of a Kubernetes solution by reference or even implication. Paragraphs 81-86 attempt to describe the actions of the applicant’s orchestration loop with respect to Figure 4 so it is not clear how some other teachings of a loop that is “well known and well documented” would be applied to the loop process shown with respect to Figure 4.
The applicant fails to supply any explanation of how the invention creates a “configuration file”. The Examiner pointed to the paragraph 86 which states that once the orchestration loop is implemented, the master creates a configuration file and transmits it to the API 102M which transmits the configuration file to the first slave cluster. The applicant argues that there is no direct relationship between the transmission of request RQT and the creation of the configuration file FC, at the end of page 12 of the 7/11/2025 remarks, but this point only further shows how the applicant lacked any description of how the configuration file is actually created. The applicant is claiming that the configuration file comprises expected conditions but now they are arguing the creation of the configuration file has nothing to do with the final step of the orchestration loop (G5 in figure 4) which is supposed to be obtaining the expected conditions. The applicant’s explanation only creates more confusion about the origin of the configuration file and its mysteriously disclosed “takeover parameters”.
The applicant argues further on page 13 that because the term “takeover parameters” has been removed from the claim the issues regarding it are no longer relevant but this ignores the fact that the disclosure still states, in paragraph 87, that the configuration file still comprises “takeover parameters” and therefore the claims till covers this unexplained subject matter. The applicant is claiming that they invented a manner of creating a configuration file so it would be reasonable to expect some technical description of what exactly that means based on the guidance given in sections 2161.01(I) and 2162 of the MPEP.
Regarding the 5th written description issue presented in the last office action, the applicant’s arguments ignore the context in which the orchestration loop is applied by the slave. As shown in Figure 3, the orchestration loop is first applied by the applicant with respect to step E3. The applicant attempts to explain step E3 in paragraphs 76-86 with respect to Figure 4. Figure 4 is described as showing a process of obtaining information from a node and a database. Paragraphs 95 and 96 state that the same orchestration loop process is implemented “in order to configure all of the computing nodes of the slave cluster with execution conditions comprised in the configure file emitted by the master cluster”. There is no description of how the orchestration loop, described with respect to Figure 4, has any relationship to the configuration file received by the slave cluster. Paragraph 95 does not provide any explanation of how the reception of the configuration file and the implementation of the Figure 4 orchestration loop are related.
Further, the applicant does not present claim 14 as withdrawn, even though it covers a non-elected invention. As explained in the previous office actions, claim 14 was included in the wrong group do to a typographical error in the 4/29/2024 restriction. The applicant needs to list this claim as withdrawn or cancelled in response to this office action, even if the applicant plans to petition under 37 CFR 1.144, or the examiner will hold the next reply as non-compliant based on 37 CFR 1.121 for including an incorrect status identifier of the claim.
Regarding the 4th written description issue presented in the last office action, the applicant does not provide any explanation of what a “liberation parameter” is and how a configuration file is created using such parameters and therefore the applicant has not addressed the substance of the rejection.
Finally, because the applicant has broadened the claims, the Examiner has determined they are anticipated by the prior art. A new prior art rejection is presented based on the new breadth.
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.
Claims 1-6, 8, 13, and 15 are 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(s) contains 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 applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Written Description Issue #1
Claims 1, 13, and 15 feature the following amendment:
receiving a request for taking control of the slave cluster comprising an identifier of at least one task intended to be executed by at least one computing node of the slave cluster,
creating a configuration file of the slave cluster comprising the identifier and expected execution conditions of the at least one task intended to be executed by the at least one computing node of the slave cluster
The applicant did not disclose that that the same “identifier” that is received in the request in the first limitation is then used in configuration file that is created. The applicant alleges that paragraphs 73, 75, and 88 provide support for this amendment. The “identifier” referred to in paragraph 73 and 75 that is disclosed as a identifier of at least task to be executed by a node of the first slave cluster. Paragraph 88 describes how tasks executed by the master cluster may be distributed into a plurality of tasks groups and that “In such a situation, the Configuration file FC comprises an identifier of at least one group of tasks”. Paragraph 88 is using the concept of an identifier to identify a group of tasks and therefore it is not the same identifier referred to in paragraphs 73 and 75 which is “an identifier idT of at least one task to be executed”. The first sentence of paragraphs 88 refers to grouping the tasks that are executed at the master and paragraphs 89-91 explain the purpose of grouping the tasks. The context of grouping explained in paragraphs 88-91 has nothing to do with the identifier of tasks which are received in the request described in paragraph 73. The Examiner notes that original claims 1 and 2 showed this distinction between a “takeover parameter” and an “identifier” in a configuration file so the “identifier” received in the request cannot be substituted for the “takeover parameters” referred to in paragraph 87 because the original claims demonstrate that they were intended to cover to distinct concepts.
Written Description Issue #2
Claims 1, 13, and 15 feature the limitation:
creating a configuration file of the slave cluster comprising the identifier and expected execution conditions of the at least one task intended to be executed by the at least one computing node of the slave cluster, the expected execution conditions being identical to current execution conditions of at least one task by at least one computing node of the master cluster,
The first receiving step of claims 1, 13, and 15 is described in paragraphs 73-75 of the disclosure with respect to step E1 and E2 shown in Figure 3. Paragraph 73 states that an API 102M of management node 10M receives the takeover request from a slave cluster. The request identifies a task intended to be executed by the at least one slave cluster. Paragraph 74 provide an example of a takeover request message featuring many parameters, some of which have values assigned to them, but there is no description of what these parameters mean or what the values mean with respect to the parameters. Some of the parameters listed in paragraph 74 do not even show example values. Paragraph 75 states that the request is transmitted to database 103M and the database updates its registers with the identifier of the task from the request and information “relating to” the execution conditions of the task. This information referred to that is stored in the registers of the database is not otherwise described.
In paragraph 76, the disclosure proceeds to step E3 where an orchestration loop is implemented by the master cluster. The orchestration loop is described with reference to Figure 4. Paragraph 77 states that the orchestration loop is implemented in a cluster of nodes (presumably that shown in either of Figures 2 or 1) during which the execution conditions of tasks executed by the nodes 11i are updated according to information in database 103 and information on the current condition of the tasks by the computing nodes 11i.
Paragraph 82 describes a first step G1 where a request for information DI1 is sent from either controller 101 or synchronization module 104 to the API 102 of the management node. There is no description of how the invention goes from steps E1 and E2 where a takeover request is transmitted to API 102 and then database 103 to step G1 where either the controller 101 or synchronization module 104 is initiating a request DI1 to the API. There is no description of what triggers the controller 101 or synchronization module 104 to transmit a first request for information (DI1) to module API 102.
Paragraphs 83 and 84 describe the API 102 transmitting (step G2) the information request to the database 103 and the computing nodes 11i and receiving (step G3) information back from the database 103 and the computing nodes 11i. This appears to correspond to what is also described in paragraph 78. The applicant does not describe what information is received from database 103 or how such information is related to the information that was stored in the registers of the database, as described in paragraph 75.
Paragraph 84 further explains how the API module transmits, in step G4, the information received in step G3, to the controller 101 or sync module 104. Paragraph 85, then states that the controller 101 or sync module 104 transmits “a request RQT in application of a configuration determined by means of the information received during step G4”. However, there is no description of any determination made based on any of the information received in step G4. The applicant’s invention describes a function of determination without describing how the function is performed. The “request RQT in application of a configuration” is not defined by the applicant. It is not apparent what the relationship is between the information received from the database 103 and the nodes 11i, that comprises the information received in G4. Step G5 is clearly meaningless because RQT is not defined. There is no disclosure of why G5 is sent to API 102. The request RQT is not further referenced in the disclosure. There is no disclosure of how the information received from database 103 and nodes 11i would be integrated or what information is even provided in step G3 from database 103 and node 11i.
The disclosure then proceeds directly into the following description regarding the second and third limitations of claims 1 and 13:
[0086] Once the orchestration loop has been implemented, the master synchronization module 104M creates a configuration file FC and transmits the latter to the module API 102M in a step E4.
[0087] The module API 102M then transmits, in a step E5, the configuration file FC of the first slave cluster comprising takeover parameters and expected execution conditions of said task by the computing node 111E, the expected execution conditions of the task being identical to the current execution conditions of the same task by the computing node 111M. The execution conditions comprised in the configuration file may consist of constraints for the task to be correctly executed such as the hardware resources like the required CPU, GPU, radio antennas, but also the maximum resources authorized for a given task: maximum number of CPUs, required minimum read-access memory resources, etc.
There is no disclosure of how the configuration file is created. The applicant uses the term takeover parameter in paragraphs 42, 51, 52, 87, and 107 but fails to provide any description of what a takeover parameter is, where it comes from, or how it is used to create a configuration file.
The applicant does not provide a coherent description of what the “expected execution conditions” are. As explained, paragraph 75 references “information relating to executions conditions” received from the takeover request itself. Paragraphs 79, 80, and 84 indicate that such information would come from consulting a database at the management node and the compute node 11. Paragraph 85 implies that another message is sent that is determined by means of the information. It is not clear whether the claimed “expected execution conditions of the task” are supposed to be obtained from the request and stored in a database like in paragraph 75, or obtained from nodes and database like in paragraph 84 or are somehow related to the request G5 in paragraph 85 and the information shown as G6 in Figure 4 but not described at all by the applicant. Paragraph 87 describes examples of execution conditions as constraints but fails to articulate how these examples apply to any of the information received in step G4 or step E2. Because of the incoherent nature of the applicant’s disclosure is impossible to determine what the applicant is referring to by the “expected execution conditions” in paragraph 87 that are used to create the configuration file.
According to sections 2161.01(I) and 2163.03(V) of the MPEP:
original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved.
The applicant did not sufficiently describe how to create a configuration file comprising an identifier and expected execution conditions. First, the applicant does not coherently describe the orchestration loop because there is no description of what triggers 101/104 to send DI1 to API 102. Second, there is no description of how the determination is made by 101/104 that defines the request RQT in step G5. Paragraph 86 states that the configuration file is created after the orchestration loop but there is no description of what the relationship is between request RQT and the creation of the configuration file; in the applicant’s argues at the end of page 12 of their 7/11/2025 response that there is no direct relationship. The applicant did not provide any definition of what a takeover parameter is that defines the disclosed configuration file and did not clear and coherent technical description a current execution condition of the task by at least one computing node of the master cluster. The applicant’s description clearly fails to meet the requirements of sections 2163.03(V) and 2161.01(I) of the MPEP because it fails to coherently describe how the claimed function of creating of a configuration file is actually performed.
Written Description Issue #3
Claim 3 features the following limitation:
receiving a request for modifying a configuration of the master cluster comprising expected execution conditions of a task by the at least one computing node of the master cluster,
configuring the master cluster by means of the expected execution conditions of the task, the expected execution conditions of the task becoming, upon completion of the configuration, new current execution conditions of the task,
creating an update file of the configuration of the slave cluster comprising the expected execution conditions of the task by the at least one computing node of the slave cluster, the expected execution conditions of the task being identical to the new current execution conditions of the task by at least one computing node of the master cluster,
Paragraph 130-133 attempt to describe these limitations. There is no description of how the “master cluster” is configured by means of expected conditions. Paragraph 132 provides literal support for this limitation but does not provide any description of how the function of configuring a master cluster is performed.
Written Description Issue #4
Claim 8 features the following limitation:
creating a configuration file of the slave cluster comprising liberation parameters of the slave cluster
The applicant did not provide any description of how to create a configuration file comprising liberation parameters. Paragraphs 40 and 120 reference the term “liberation parameters” but the applicant provides not definition of this term or how it would be used to create a configuration file. The disclosure clearly does not comply with the guidance given in sections 2161.01(I) and 2163.03(V) of the MPEP which state that the applicant must disclose how a function is performed.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-5 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the limitation "the configuration of the slave cluster" in the “creating an update file” limitation. There is insufficient antecedent basis for this limitation in the claim. Claim 1 refers to “information relating to an implementation, by the slave cluster, of a configuration of the slave cluster” but not any specific configuration of the slave cluster. Even if the slave cluster were to considered to implement a configuration based on the configuration file, in claim 1, this is not covered by the claim because the claim only covers the perspective of the master. The master would have no knowledge of the ”the configuration of the slave cluster” and thus could not create an update file “of the configuration of the slave cluster”.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 2, 13 and 15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication Number 2020/0133718 by Koehler et al.
As to claim 1, Koehler teaches a method for controlling a first cluster of nodes, referred to as a slave cluster (paragraph 50 describes environment 112 as a cluster), by a second cluster of nodes, referred to as a master cluster, a cluster of nodes comprising at least one computing node (paragraph 50 describes environment 102 as a cluster), the control method being implemented by the master cluster (paragraph 53, the final sentence describes the functionality at environment 102 for managing migration) and comprising: receiving a request for taking control of the slave cluster identifying comprising an identifier of at least one task (VMs in ref. no. 104 are to be migrated from environment 102, which reads on the master to environment 112 which reads on the slave) intended to be executed by at least one computing node of the slave cluster (paragraph 36, operation 1 identifies virtualized entities to be migrated, paragraph 55, functionality of task manager 114 can be implemented at environment 102), creating a configuration file of the slave cluster comprising the identifier (paragraph 56, each virtualized entity selected) and expected execution conditions (paragraph 56, meta data for each virtualized entity) of the at least one task intended to be executed by the at least one computing node of the slave cluster, the expected execution conditions being identical to current execution conditions of the at least one task by at least one computing node of the master cluster (Figure 3 and paragraph 56), transmitting the configuration file to the slave cluster (Figure 3 and paragraph 56, the attributes are shared with the target), and receiving a message comprising information relating to an implementation, by the slave cluster, of a configuration of the slave cluster based on the configuration file (Paragraph 55, data structure 118 could be implemented at environment 102, thus status information from environment 112 would be received at environment 102).
As to claim 2, Koehler reads on the claimed scenario where the group comprises a single task.
As to claims 13 and 15, they are rejected according to the same mapping of claim 1.
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.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Application Publication Number 2020/0133718 by Koehler et al. in view of U.S. Patent Application Publication Number 2007/0244962 by Laadan et al.
As to claim 6, Koehler teaches the subject matter of claim 1; however Koehler does not explicitly teach a message emitted by an intermediate piece of equipment indicating the impossibility of transmitting a configuration file to the slave cluster
Laadan teaches receiving a message emitted by an intermediate piece of equipment indicating the impossibility of transmitting a configuration file to the slave cluster (paragraphs 61 and 87).
It would have been obvious to one of ordinary skill in the task distribution art at the time of the applicant’s filing to combine the teachings of Koehler regarding managing servers in a cluster with the teachings of Laadan regarding detecting impossibility of transmitting because such error checking would ensure correct operations.
Claim Not Rejected with Prior Art
Claims 3-5 and 8 are not rejected with prior art. Koehler was not found to teach the second and third steps of claim 3 in sequence in the context of claim 1. Koehler was not found to teach the creation of a configuration file comprising liberation parameters. Neither claim 3 nor 8 are found allowable because they are not described in a technical manner that meets the guidance for written description provided in section 2162 of the MPEP.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS B BLAIR whose telephone number is (571)272-3893. The examiner can normally be reached Monday-Friday 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached at 571-272-3949. 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.
/DOUGLAS B BLAIR/Primary Examiner, Art Unit 2454