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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Drawings
The drawings are objected to because
In Fig. 1, reference character 100 is labeled “Eation” instead of “Creation”. Appropriate correction is required.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Interpretation
The term “module” is used four times in claim 1 and claim 10:
“generation module”
“authoring module”
“scheduling module”
“execution module”
Examiner must determine whether the BRI of “module” refers to a structural limitation or is merely a software limitation. If “module” is not a structural limitation, Examiner will consider whether the additional modifiers “generation”, “authoring”, “scheduling”, and “execution” impart structural limitations into the claim language. This is not a 35 U.S.C. 112(f) issue. The claims must be interpreted for purposes of patent eligibility under 35 U.S.C. 101 (see MPEP 2106.03 “software per se”), and further must be interpreted using BRI for purposes when considering prior art rejections (see MPEP 2111 for BRI).
The term “module” is interpreted in light of specification:
The term "module", as used herein, may include a unit implemented as hardware, software, or firmware, for example, the term "module" may be interchangeably used with the term a "logic", a "logical block", a "component", or a "circuit".
(Specification [page 12 paragraph 4 lines 1-3]).
Here, the definition is not limiting because of the verb “may include”, but under BRI, the term “module” at least includes “software”. Therefore, no hardware limitations are required by the term “module” under a broadest reasonable interpretation in light of the specification standard.
Examiner reviewed the modifiers in the context of the claims and how they are used in the specification. The modules are used and explained in the description with respect to FIG. 1 (Specification [page 6 paragraph 2]) through FIG. 6, (Specification [page 11 paragraph 7]), but no hardware limitations are described by the modifiers.
In claim 1 line 1, the term “first to Nth digital twin Docker images” is introduced. In claim 1 line 3, “first to Nth digital twin models, in which assets are virtualized” is introduced. In claim 1 line 10 line 7, the term “digital twin workflow” is introduced with the limitation “author a digital twin workflow by connecting the first to Nth digital twin Docker images”. The broadest reasonable interpretation in light of the specification of the terms is necessary to understand the scope of the claim.
Digital twin is defined in the specification:
A digital twin is an intelligent convergence technology of analyzing, in a virtual world, various pieces of information collected from a real world, deriving an optimization plan, and optimizing the real world on the basis of the optimization plan. That is, the digital twin is a technology of copying machines, equipment, objects, or the like in the real world with a computer to generate a digital virtual twin, and simulating situations that may occur in the real world, to predict the situations in advance, and may be referred to as an interface capable of understanding past and current operating states and predicting future operations by combining pieces of data and information representing structures, contexts, and operations of various physical systems.
(Specification [page 1 paragraph 3]).
The specification goes on to describe a digital twin model, in which assets are virtualized:
The creation module 100 creates a digital twin model in which assets are virtualized on the basis of asset information collected from the assets. In the present embodiment, the assets may correspond to manufacturing assets such as facilities, processes, lines, legacy manufacturing systems, artificial intelligence systems, simulation systems, or monitoring systems existing in a manufacturing site.
(Specification [page 6 paragraph 2 lines 1-5]).
The specification then defines a digital twin Docker image:
The present embodiment employs Docker images as the means of executing the digital twin model using the above-described scalability, execution flexibility, and consistency of Docker. As a digital twin Docker image (which may be referred to as a digital twin base Docker image) are generated by combining a digital twin model and a Docker image, the digital twin Docker image includes the digital twin model and all files necessary for the execution of the digital twin model.
(Specification [page 8 paragraph 2 lines 1-6]).
Finally, the specification provides examples of digital twin models within a digital twin workflow.
The authoring module 400 checks an output parameter of the Data submodel of the RollFormer digital twin model and an input parameter of the AI submodel of the FailureDetector digital twin model. Since the output parameter of the Data submodel of the RollFormer digital twin model and the input parameter of the AI submodel of the FailureDetector digital twin model are all load factors and equal, the authoring module 400 authors the digital twin workflow by mutually connecting the output parameter of the Data submodel of the RollFormer digital twin model and the input parameter of the AI submodel of the FailureDetector digital twin model. The authored digital twin workflow performs a function of predicting a failure based on the load factor of the RollFormer facility, and FIG. 4 illustrates an example of the generated digital twin workflow.
(Specification [page 9 paragraph 3]).
The definition of digital twin varies in scope based on how the term is used, (see “Digital Twin in manufacturing: A categorical literature review and classification” (2018-Kritzinger). A narrow definition focuses on the data flow between the digital and physical counterparts:
If further, the data flows between an existing physical object and a digital object are fully integrated in both directions, one might refer to it as Digital Twin. In such a combination, the digital object might also act as controlling instance of the physical object. There might also be other objects, physical or digital, which induce changes of state in the digital object. A change in state of the physical object directly leads to a change in state of the digital object and vice versa.
PNG
media_image1.png
164
374
media_image1.png
Greyscale
(2018-Krizinger [page 1017 col 2 paragraph 3]).
From an data analysis perspective, if data is flowing in only one direction, then a digital twin may be more akin to a scientific workflow:
From a database point of view, the scientific experiments which have to be carried out during such a development process are typically composed of a series of steps or tasks, which a.re intertwined according; to some control sequence (e.g., loops, conditional branches, and parallel execution). Each such step receives some input information and produces output information. This information is manyfold. It may appear in forms such as stored data. (e.g., files), data received from external devices (e.g., sensors), description of devices Lo be used on the execution of a step (e.g., equipment specification), conditions concerning step execution (e.g., preconditions, interrupt situations), consistency constraints, scheduling information, and others.
PNG
media_image2.png
154
384
media_image2.png
Greyscale
(“WASA: A workflow-based architecture to support scientific database applications” (1995-Medeiros) [page 3 paragraph 5]-[page 4 paragraph 1]).
Within the realm of workflows, “scientific workflows” are often contrasted with “business workflows”:
In business applications, the main motivation for introducing workflow management. is the desire to organize (actually "re-organize" or "re-engineer") work in, say, a company to enhance its efficiency. The motivation for workflow management in scientific applications, however, is less to enhance efficiency, but to control experiments, and to make available to scientific users the information on how experiments were conducted. What both domains have in common is the need to organize and control process executions.
(1995-Medeiros [page 6 paragraph 2 lines 5-11]).
In the claims, digital twin models must have “virtualized assets”, but these assets are broadly defined to include not just physical assets, but also “artificial intelligence systems, simulation systems, or monitoring systems”, (see Specification [page 6 paragraph 3]). There are no implied or functional limitations placed on the digital twin models because the models are transparent to the rest of the elements of the claim once the model has been packaged into a Docker image.
In the specification, two digital twin models are described including a “RollFormer” digital twin model and “FailureDetector” digital twin model (see Specification [page 9 paragraph 3]). The example seems to be closely aligned with a scientific workflow as defined by Medeiros, where data is coming from either a sensor or some form of equipment specification associated with RollFormer and analyzed with FailureDetector. These two models must be included in the scope of “digital twin model” for the claims to be interpreted consistently with specification. Applicant is given the power to be their own lexicographer, so the metes and bounds of “digital twin” as claimed can be further clarified through claim limitations if necessary.
In claim 1 line 1, and throughout the claims and specification, the term Docker is used. The term “Docker” is defined in the specification:
The term "Docker" refers to a software platform that supports application software to be rapidly built, tested, and deployed. Docker packages the application software into standardized modules called containers, and the containers include everything needed to execute the software, such as libraries, system tools, and code. In addition, Docker includes software as well as an independent execution environment, thereby ensuring flexible and consistent execution even in various different execution environments (operating systems, memory, application tool package versions, and the like). Docker is configured to be executed by Docker images that include all libraries and package files necessary for the execution of the application software.
(Specification [page 7 paragraph 6]-[page 8 paragraph 1]).
This language does not express clear intent to redefine the term, as it is used in the art, but instead reinforces the definition as it is used in the art. An important distinction in the art, that is not explicitly defined or mentioned in the specification is the difference between a Docker container and virtual machine (see FIG. 7 of “Evaluation of Containerized Simulation Software in Docker Swarm and Kubernetes” (2020-Lyu) [page 25]). For purposes of prosecution, Examiner intends to maintain this distinction when interpreting the claims. Applicant is welcome to disclaim claim scope in the arguments if such an interpretation is not intended.
The terminology “Docker image” is not explicitly defined in the specification. The art of reference makes a distinction between Docker containers and Docker images. The specification and claims, as currently drafted, use the terms interchangeably. For example in claim 1, the language:
...generate first to Nth digital twin Docker images by combining first to Nth digital twin models, in which assets are virtualized, and first to Nth Docker images, respectively,...
(see Claims filed 9/11/2023 [claim 1 lines 2-4]).
Generating “Docker image” by “combining” is consistent with how the terminology is used in the art of reference. However, claim 1 goes on to claim:
...execute the target digital twin Docker image according to the scheduling result of the scheduling module.
(see Claims filed 9/11/2023 [claim 1 lines 12-13]).
In light of the art of reference, the term “Docker image” here is more consistent with the terminology “Docker container” after being instantiated from a Docker image. Applicant is entitled to be their own lexicographer. The meaning of the limitation is clear, so this language is not indefinite. For purposes of prosecution, “Docker image” will be broadly interpreted based on implicit definitions made within the claim limitations.
In claim 1 lines 9-11, scheduling is referenced. The term “scheduling” is defined in the specification:
The term "scheduling" is defined as a concept of allocating resources required for the execution of the target digital twin Docker image.
(Specification [page 9 paragraph 5 lines 3-4]).
This definition is consistent with how the term is used in the art, and therefore no further interpretation is necessary.
Claim Interpretations 35 U.S.C. 112(f)
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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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) is/are:
The term “a generation module configured to generate...” in claim 1 line 2. Under (A), the term “module” is a generic placeholder; under (B), the phrase “configured to generate” is a functional limitation, and under (C), the generic placeholder is not modified by sufficient structure to perform the functional limitation. Having found that 35 U.S.C. 112(f) applies, the term “module” is further described in the specification (see Specification [page 12 paragraph 4 lines 1-3], but not with sufficient structure to perform the claimed limitation (i.e., a physical structure with a corresponding algorithm), (for more see MPEP 2181(II)(B), “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)”) . Therefore, this terminology is indefinite, and a 35 U.S.C. 112(b) rejection is necessary. See below for the rejection.
The term “authoring module configured to author...” in claim 1 line 7. Under (A), the term “module” is a generic placeholder; under (B), the phrase “configured to author...” is a functional limitation, and under (C), the generic placeholder is not modified by sufficient structure to perform the functional limitation. Having found that 35 U.S.C. 112(f) applies, the term “module” is further described in the specification (see Specification [page 12 paragraph 4 lines 1-3], but not with sufficient structure to perform the claimed limitation (i.e., a physical structure with a corresponding algorithm), (for more see MPEP 2181(II)(B), “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)”) . Therefore, this terminology is indefinite, and a 35 U.S.C. 112(b) rejection is necessary. See below for the rejection.
The term “scheduling module configured to schedule...” in claim 1 line 9. Under (A), the term “module” is a generic placeholder; under (B), the phrase “configured to select ... and schedule execution...” is a functional limitation, and under (C), the generic placeholder is not modified by sufficient structure to perform the functional limitation. Having found that 35 U.S.C. 112(f) applies, the term “module” is further described in the specification (see Specification [page 12 paragraph 4 lines 1-3], but not with sufficient structure to perform the claimed limitation (i.e., a physical structure with a corresponding algorithm), (for more see MPEP 2181(II)(B), “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)”) . Therefore, this terminology is indefinite, and a 35 U.S.C. 112(b) rejection is necessary. See below for the rejection.
The term “execution module configured to execute...” in claim 1 line 12. Under (A), the term “module” is a generic placeholder; under (B), the phrase “configured to execute...” is a functional limitation, and under (C), the generic placeholder is not modified by sufficient structure to perform the functional limitation. Having found that 35 U.S.C. 112(f) applies, the term “module” is further described in the specification (see Specification [page 12 paragraph 4 lines 1-3], but not with sufficient structure to perform the claimed limitation (i.e., a physical structure with a corresponding algorithm), (for more see MPEP 2181(II)(B), “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)”) . Therefore, this terminology is indefinite, and a 35 U.S.C. 112(b) rejection is necessary. See below for the rejection.
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.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112(b)
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.
With respect to claims 1-10, claims 1-10 contains the trademark/trade name “Docker”, used in the context of “Docker image” or “Docker images” throughout the claims. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a “container image” and, accordingly, the identification/description is indefinite.
For purposes of prosecution, the limitation will be interpreted as a “container image”.
Claims 1-9 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 limitations:
“generation module configured to generate...” of claim 1 line 2,
“authoring module configured to author...” in claim 1 line 7,
“scheduling module configured to select... and schedule execution...” in claim 1 line 9,
“execution module configured to execute...” in claim 1 line 12,
...invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. For each of these limitations, the disclosure is devoid of any structure that performs the function in the claim. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
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) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(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.
With respect to claims 2-9, the claims incorporate by reference the indefinite language of claim 1, and therefore are also rejected.
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-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the focus of the claim may be interpreted as software or a signal which is not a process, machine, manufacture, composition of matter, or improvement thereof.
With respect to claim 1, under step 1 of the Alice/Mayo test, claim 13 claims:
An apparatus for executing a digital twin, the apparatus comprising:
a generation module configured to generate first to Nth digital twin Docker images by combining first to Nth digital twin models, in which assets are virtualized, and first to Nth Docker images, respectively, wherein each of the digital twin Docker images includes the corresponding digital twin model and a file required for executing the corresponding digital twin model, where N is a natural number greater than or equal to 2;
an authoring module configured to author a digital twin workflow by connecting the first to Nth digital twin Docker images;
a scheduling module configured to select a target digital twin Docker image to be currently executed from the digital twin workflow, and schedule execution of the selected target digital twin Docker image; and
an execution module configured to execute the target digital twin Docker image according to the scheduling result of the scheduling module.
The specification further defines module permissively as :
The term "module", as used herein, may include a unit implemented as hardware, software, or firmware, for example, the term "module" may be interchangeably used with the term a "logic", a "logical block", a "component", or a "circuit".
(Specification [page 12 paragraph 4 lines 1-3]).
Under 35 U.S.C 101, software modules are software per se, which is patent ineligible because software is not a process, machine, manufacture, or composition of matter, or any new and useful improvement thereof. (See MPEP 2106.03).
With respect to claims 2-9, the claims incorporate by reference the limitations of claim 1, and do not add any structural limitations. Therefore, these claims are also rejected.
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) 1-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Designing a Semantic Digital Twin model for IoT” (2020-Muralidharan) in view of "KubeAdaptor: A Docking Framework for Workflow Containerization on Kubernetes" (2022-Shan) in further view of “Evaluation of Containerized Simulation Software in Docker Swarm and Kubernetes” (2020-Lyu)
With respect to claim 1, Muralidharan teaches An apparatus for executing a digital twin, the apparatus comprising (the hardware shown in FIG. 1, the cloud labeled “edge” is the primary computing device executing the digital twin represented by a hexagon with dotted line, but the full apparatus includes the IoT devices and client devices as well, [page 2]; FIG. 2, provides an expanded example with multiple Digital Twins enabled with Docker Images, [page 3]): a generation module (Docker, see [page 2 col 1 paragraph 2 line 14]-[page 2 col 2 paragraph 1 line 4]) configured to generate first to Nth digital twin Docker images by combining (bundle up applications with all its libraries and dependencies as one package, mimics IoT devices and applications similar in concept to DT, [page 2 col 1 line 16]-[page 2 col 2 line 1]; Fig. 2 shows 1-4 DT containers labeled with whales resulting from 1-4 images, [page 3]) first to Nth digital twin models, in which assets are virtualized (DT is the creation of virtual replicas of physical IoT devices, [page 2 col 1 paragraph 1 lines 10-11]; the DT models are the portion of the docker image that mimic IoT devices, [page 2 col 1 line 16]-[page 2 col 2 line 1]; in Fig. 2, authors created 4 digital twins corresponding the 4 IoT devices, which are running as containers enabled from the images, [page 3])..., wherein each of the digital twin Docker images includes the corresponding digital twin model (digital twin models are the "replicas", and the images mimic the IoT devices, [page 2 col 2 paragraph 3 lines 1-7]) and a file required for executing the corresponding digital twin model (libraries and dependencies, [page 2 col 2 paragraph 1 line 1]), where N is a natural number greater than or equal to 2 (see FIG. 2 shows 4 devices and 4 corresponding digital twins, [page 3]; these are containers enabled with corresponding images as noted in the figure; where images mimic the IoT device, [page 2 col 2 paragraph 3 lines 1-7]).
2020-Muralidharan does not teach workflows or the specifics about how Docker images are built. Therefore, 2020-Muralidharan does not teach ...and first to Nth Docker images, respectively, OR an authoring module configured to author a digital twin workflow by connecting the first to Nth digital twin Docker images; a scheduling module configured to select a target digital twin Docker image to be currently executed from the digital twin workflow, and schedule execution of the selected target digital twin Docker image; and an execution module configured to execute the target digital twin Docker image according to the scheduling result of the scheduling module.
However, 2022-Shan teaches an authoring module (command line interface shown in FIG. 2 to create yaml files such as WF.yaml, [page 5]) configured to author a digital twin workflow by connecting the first to Nth digital twin Docker images (see “Workflow Instantiation”, [page 8 col 2 paragraph 4]-[page 10 col 1 paragraph 1], after creating the digital twin docker images, already taught by Muralidharan, the image file is stored in a repository like local Harbor or Docker Hub, and then “initialize the task Image address in the ConfigMap file of the workflow injection module”, [page 10 col 1 paragraph 2 lines 3-4]; Listing 1 shows a ConfigMap file with the dependency.json key, [page 6], each with an "image" field to the Docker image, an "input" field for the input dependencies, and an "output" field for the output dependencies, [page 6]); a scheduling module (separated into three submodules: (1) the “workflow systems” with the “workflow scheduling algorithm”, (2) the “KubeAdaptor”, and the kube-scheduler (also called K8 scheduler) shown in FIG. 2, [page 5]) configured to select a target digital twin Docker image to be currently executed from the digital twin workflow, and schedule execution of the selected target digital twin Docker image (the image pull policy is set to “ifnotpresent” to pull task images from local Harbor, then workflow is sent to KubeAdaptor, which then starts the containerization process, [page 10 col 2 paragraph 2 lines 6-15]; within the KubeAdaptor and “Event Trigger Mechanism” ... “triggers generation of the subsequent task pod” for the “to be currently executed” limitation, [page 8 col 1 paragraph 3 line 12]; the KubeAdaptor restricts the K8 scheduler to only scheduling for execution tasks that are ready according to the workflow scheduling algorithm: “This mechanism enables a quick switch between the creation and destruction of workflow task pods and restricts the out-of-order pod scheduling of the K8s scheduler”, [page 8 col 1 paragraph 4 lines 1-3]); and an execution module (in FIG. 2, the execution module is Kubernetes labeled as “K8 cluster” executing the labeled “workflow task pods”, [page 5]; the actual execution is by one of six nodes, [page 8 col 2 paragraph 2 line 14]); configured to execute the target digital twin Docker image according to the scheduling result of the scheduling module (see FIG. 4, which shows the “execution sequence of the work flow task”, [page 9]; where pods are a “logical deployable unit” and combination multiple “containers”, [page 5 col 1 paragraph 2 bullet 1]; where workflow tasks are packaged into containers by Docker and built in the form of an image file, [page 4 col 2 paragraph 2 lines 2-6]).
2020-Muralidharan and 2022-Shan do not teach the specifics about how Docker images are built. Therefore, 2020-Muralidharan and 2022-Shan do not teach ...and first to Nth Docker images, respectively.
However, 2020-Lyu teaches and first to Nth Docker images, respectively (see explanation of Docker Images, [page 25 paragraph 3 bullet 1]-[page 26 paragraph 1 bullet 1]; and Dockerfile, [page 28 paragraph 1 bullet 2]; "create image using the customized Docker file", [page 25 paragraph 3 bullet 1 line 7]; "The order of executing the instructions in the Dockerfile must start from the instruction (’FROM’), which indicates the base image of this new image. Furthermore, the base image can also be an empty filesystem started by Docker if the base image is SCRATCH", [page 28 paragraph 1 bullet 2 lines 12-15]; the actual docker file is shown in Appendix A, with the FROM command being the first line, [page 60]; the first to Nth in this case means the Dockerfile for each of the 1 to N digital twin Docker images has its own Dockerfile; this understood by those having skill in the art reading Muralidharan, [page 2 col 2 paragraph 1 line 1] and [page 2 col 2 paragraph 3 line 8], but more explicitly explained as to the actual details in Lyu; see the example in Fig. 8 of Lyu showing that the application layers and dependencies are built on top of the base Ubuntu file system image, [page 26]).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan with Shan because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan discloses a system and method that teaches all of the claimed features except for the specific workflow scheduling algorithm. Muralidharan teaches Kubernetes (Muralidharan [page 3 col 1 paragraph 1 line 9]), which performs orchestration, and scheduling is part of orchestration. Shan has a specific section labeled “Motivation” that explains how the Kubernetes platform does not take workflows into account, (see Section 3.1 Motivation of Shan [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]). Specifically:
...the K8s scheduler is unaware of the interdependencies among the tasks inside scheduled pods [8]. Due to the inconsistency between the task submission order and the K8s scheduling order, the K8s scheduler becomes an unpredictable and unreliable task scheduling method.
(2022-Shan [page 4 col 1 paragraph 1 lines 1-6]).
To enable workflow systems to integrate the K8s platform smoothly and energize the two-level scheduling scheme, the KubeAdaptor is proposed to deal with these problems.
(2022-Shan [page 4 col 1 paragraph 1 lines 11-14]).
A person having skill in the art would have a reasonable expectation of successfully solving the workflow problem by using the native Kubernetes scheduler in the system and method of Muralidharan by modifying Muralidharan with the KubeAdaptor of Shan. Therefore, it would have been obvious to combine Muralidharan with Shan to a person having ordinary skill in the art.
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan in view of Shan with Lyu because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan in view of Shan discloses a system that teaches all of the claimed features except for how and why a digital twin docker image is built from a base Docker Image. Lyu provides an explanation:
Developers can either pull the images from the Docker Hub or create their images using the customized Dockerfile Since there is no image created for the simulator software, Apros used in the experiment of this thesis, there is a need to implement the Dockerfile for that simulator software and build the Apros image. To create a customized image, Developers can either pull the images developers should carefully write the instructions in the Dockerfile, and the necessary instructions will be introduced in a later section. Each instruction in the Dockerfile will create one layer in the image, and all necessary layers in the image are working together to support the container created from the image. The principle of filesystems in the image is that each layer, according to the instruction in the Dockerfile, will be added on top of existing layers. The layered architecture of Docker images is shown in figure 8.
(Lyu [page 25 paragraph 3 bullet 1 line 6]-[page 26 paragraph 1 bullet 1 line 7]).
In Docker, a custom application image is built on top of dependency layers. These layers can already be stored in an image called a “base image”, (see Lyu [page 28 paragraph 1 bullet 2 lines 13-15]). A person having skill in the art would have a reasonable expectation of successfully building a Docker image in the system and method of Muralidharan in view of Shan by modifying Muralidharan in view of Shan with the Docker images of Lyu. Therefore, it would have been obvious to combine Muralidharan in view of Shan with Lyu to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 2, Muralidharan in view of Shan and Lyu teaches all of the limitations of claim 1, as noted above. Muralidharan does not teach wherein the authoring module authors the digital twin workflow in a method that connects inputs and outputs of the first to Nth digital twin Docker images.
However, Shan teaches wherein the authoring module authors the digital twin workflow in a method that connects inputs and outputs of the first to Nth digital twin Docker images (see “Workflow Instantiation”, [page 8 col 2 paragraph 4]-[page 10 col 1 paragraph 1], after creating the digital twin docker images, already taught by Muralidharan, the image file is stored in a repository like local Harbor or Docker Hub, and then “initialize the task Image address in the ConfigMap file of the workflow injection module”, [page 10 col 1 paragraph 2 lines 3-4]; Listing 1 shows a ConfigMap file with the dependency.json key, [page 6], each with an "image" field to the Docker image, an "input" field for the input dependencies, and an "output" field for the output dependencies, [page 6]).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan with Shan because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan discloses a system and method that teaches all of the claimed features except for the specific workflow scheduling algorithm. Muralidharan teaches Kubernetes (Muralidharan [page 3 col 1 paragraph 1 line 9]), which performs orchestration, and scheduling is part of orchestration. Shan has a specific section labeled “Motivation” that explains how the Kubernetes platform does not take workflows into account, (see Section 3.1 Motivation of Shan [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]). Specifically:
...the K8s scheduler is unaware of the interdependencies among the tasks inside scheduled pods [8]. Due to the inconsistency between the task submission order and the K8s scheduling order, the K8s scheduler becomes an unpredictable and unreliable task scheduling method.
(2022-Shan [page 4 col 1 paragraph 1 lines 1-6]).
To enable workflow systems to integrate the K8s platform smoothly and energize the two-level scheduling scheme, the KubeAdaptor is proposed to deal with these problems.
(2022-Shan [page 4 col 1 paragraph 1 lines 11-14]).
A person having skill in the art would have a reasonable expectation of successfully solving the workflow problem by using the native Kubernetes scheduler in the system and method of Muralidharan by modifying Muralidharan with the KubeAdaptor of Shan. Therefore, it would have been obvious to combine Muralidharan with Shan to a person having ordinary skill in the art.
With respect to claim 3, Muralidharan in view of Shan and Lyu teaches all of the limitations of claim 1, as noted above. Muralidharan does not teach wherein Mth and Kth digital twin models respectively included in Mth and Kth digital twin Docker images, which are interconnected in the digital twin workflow, have the same parameter as configuration parameters thereof, where M and K are natural numbers greater than or equal to 1 and less than or equal to N, and M≠K.
However, Shan teaches wherein Mth and Kth digital twin models respectively included in Mth and Kth digital twin Docker images, which are interconnected in the digital twin workflow, have the same parameter as configuration parameters thereof, where M and K are natural numbers greater than or equal to 1 and less than or equal to N, and M≠K(See Listing 1, the dependency 0 has configuration parameters including cpuNum: [“1200”] and memNum:[“1200”], dependency 1 also has the same configuration parameters, [page 6]; these models are connected in the same digital twin workflow as noted by the output:[“1”, “2”] of dependency 0, and input:[“0”] field of dependency “1”, which indicates that the output of dependency 0 is fed as input to dependency 1, [page 6]).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan with Shan because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan discloses a system and method that teaches all of the claimed features except for the specific workflow scheduling algorithm. Muralidharan teaches Kubernetes (Muralidharan [page 3 col 1 paragraph 1 line 9]), which performs orchestration, and scheduling is part of orchestration. Shan has a specific section labeled “Motivation” that explains how the Kubernetes platform does not take workflows into account, (see Section 3.1 Motivation of Shan [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]). Specifically:
...the K8s scheduler is unaware of the interdependencies among the tasks inside scheduled pods [8]. Due to the inconsistency between the task submission order and the K8s scheduling order, the K8s scheduler becomes an unpredictable and unreliable task scheduling method.
(2022-Shan [page 4 col 1 paragraph 1 lines 1-6]).
To enable workflow systems to integrate the K8s platform smoothly and energize the two-level scheduling scheme, the KubeAdaptor is proposed to deal with these problems.
(2022-Shan [page 4 col 1 paragraph 1 lines 11-14]).
A person having skill in the art would have a reasonable expectation of successfully solving the workflow problem by using the native Kubernetes scheduler in the system and method of Muralidharan by modifying Muralidharan with the KubeAdaptor of Shan. Therefore, it would have been obvious to combine Muralidharan with Shan to a person having ordinary skill in the art.
With respect to claim 4, Muralidharan in view of Shan and Kyu teaches all of the limitations of claim 3 as noted above. Muralidharan does not teach wherein the Mth digital twin model has a specific parameter as an output parameter, the Kth digital twin model has the specific parameter as an input parameter, and the authoring module authors the digital twin workflow in a method that connects the output parameter of the Mth digital twin model and the input parameter of the Kth digital twin model.
However, Shan teaches wherein the Mth digital twin model has a specific parameter as an output parameter, the Kth digital twin model has the specific parameter as an input parameter, and the authoring module authors the digital twin workflow in a method that connects the output parameter of the Mth digital twin model and the input parameter of the Kth digital twin model (See Listing 1, dependency 0 and dependency 1 are models connected in the same digital twin workflow as noted by the output:[“1”, “2”] of dependency 0, and input:[“0”] field of dependency “1”, which indicates that the output of dependency 0 is fed as input to dependency 1, [page 6]).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan with Shan because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan discloses a system and method that teaches all of the claimed features except for the specific workflow scheduling algorithm. Muralidharan teaches Kubernetes (Muralidharan [page 3 col 1 paragraph 1 line 9]), which performs orchestration, and scheduling is part of orchestration. Shan has a specific section labeled “Motivation” that explains how the Kubernetes platform does not take workflows into account, (see Section 3.1 Motivation of Shan [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]). Specifically:
...the K8s scheduler is unaware of the interdependencies among the tasks inside scheduled pods [8]. Due to the inconsistency between the task submission order and the K8s scheduling order, the K8s scheduler becomes an unpredictable and unreliable task scheduling method.
(2022-Shan [page 4 col 1 paragraph 1 lines 1-6]).
To enable workflow systems to integrate the K8s platform smoothly and energize the two-level scheduling scheme, the KubeAdaptor is proposed to deal with these problems.
(2022-Shan [page 4 col 1 paragraph 1 lines 11-14]).
A person having skill in the art would have a reasonable expectation of successfully solving the workflow problem by using the native Kubernetes scheduler in the system and method of Muralidharan by modifying Muralidharan with the KubeAdaptor of Shan. Therefore, it would have been obvious to combine Muralidharan with Shan to a person having ordinary skill in the art.
With respect to claim 5, Muralidharan in view of Shan and Kyu teaches all of the limitations of claim 1, as noted above. Muralidharan does not teach when the target digital twin Docker images correspond to the Mth and Kth digital twin Docker images, the execution module sequentially executes the Mth and Kth digital twin Docker images.
However, Shan teaches when the target digital twin Docker images correspond to the Mth and Kth digital twin Docker images, the execution module sequentially executes the Mth and Kth digital twin Docker images (the image pull policy is set to “ifnotpresent” to pull task images from local Harbor, then workflow is sent to KubeAdaptor, which then starts the containerization process, [page 10 col 2 paragraph 2 lines 6-15]; within the KubeAdaptor and “Event Trigger Mechanism” ... “triggers generation of the subsequent task pod” for the “to be currently executed” limitation, [page 8 col 1 paragraph 3 line 12]; the KubeAdaptor restricts the K8 scheduler to only scheduling for execution tasks that are ready according to the workflow scheduling algorithm: “This mechanism enables a quick switch between the creation and destruction of workflow task pods and restricts the out-of-order pod scheduling of the K8s scheduler”, [page 8 col 1 paragraph 4 lines 1-3]; for examples see FIGS 4-6, [pages 9-10]; FIG. 4 shows the “execution sequence of the work flow task”, [page 9]; where pods are a “logical deployable unit” and combination multiple “containers”, [page 5 col 1 paragraph 2 bullet 1]; where workflow tasks are packaged into containers by Docker and built in the form of an image file, [page 4 col 2 paragraph 2 lines 2-6]; FIG. 5 shows the workflow themselves, [page 9]; and FIG. 6 shows how the workflows are executed in order, [page 10]).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan with Shan because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan discloses a system and method that teaches all of the claimed features except for the specific workflow scheduling algorithm. Muralidharan teaches Kubernetes (Muralidharan [page 3 col 1 paragraph 1 line 9]), which performs orchestration, and scheduling is part of orchestration. Shan has a specific section labeled “Motivation” that explains how the Kubernetes platform does not take workflows into account, (see Section 3.1 Motivation of Shan [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]). Specifically:
...the K8s scheduler is unaware of the interdependencies among the tasks inside scheduled pods [8]. Due to the inconsistency between the task submission order and the K8s scheduling order, the K8s scheduler becomes an unpredictable and unreliable task scheduling method.
(2022-Shan [page 4 col 1 paragraph 1 lines 1-6]).
To enable workflow systems to integrate the K8s platform smoothly and energize the two-level scheduling scheme, the KubeAdaptor is proposed to deal with these problems.
(2022-Shan [page 4 col 1 paragraph 1 lines 11-14]).
A person having skill in the art would have a reasonable expectation of successfully solving the workflow problem by using the native Kubernetes scheduler in the system and method of Muralidharan by modifying Muralidharan with the KubeAdaptor of Shan. Therefore, it would have been obvious to combine Muralidharan with Shan to a person having ordinary skill in the art.
With respect to claim 6, Muralidharan in view of Shan and Lyu teaches all of the limitations of claim 2, as noted above. Muralidharan does not teach wherein the authoring module authors the digital twin workflow in the form of a directed acyclic graph (DAG).
However, Shan teaches wherein the authoring module authors the digital twin workflow in the form of a directed acyclic graph (DAG) (The steps in a workflow are executed following the order defined as DAG. As shown in Listing 1, workflow definition in KubeAdaptor is human-readable and extremely simple to use with a negligible learning burden, [page 6 col 2 paragraph 1 lines 9-12]).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan with Shan because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan discloses a system and method that teaches all of the claimed features except for the specific workflow scheduling algorithm. Muralidharan teaches Kubernetes (Muralidharan [page 3 col 1 paragraph 1 line 9]), which performs orchestration, and scheduling is part of orchestration. Shan has a specific section labeled “Motivation” that explains how the Kubernetes platform does not take workflows into account, (see Section 3.1 Motivation of Shan [page 3 col 2 paragraph 3]-[page 4 col 1 paragraph 1]). Specifically:
...the K8s scheduler is unaware of the interdependencies among the tasks inside scheduled pods [8]. Due to the inconsistency between the task submission order and the K8s scheduling order, the K8s scheduler becomes an unpredictable and unreliable task scheduling method.
(2022-Shan [page 4 col 1 paragraph 1 lines 1-6]).
To enable workflow systems to integrate the K8s platform smoothly and energize the two-level scheduling scheme, the KubeAdaptor is proposed to deal with these problems.
(2022-Shan [page 4 col 1 paragraph 1 lines 11-14]).
A person having skill in the art would have a reasonable expectation of successfully solving the workflow problem by using the native Kubernetes scheduler in the system and method of Muralidharan by modifying Muralidharan with the KubeAdaptor of Shan. Therefore, it would have been obvious to combine Muralidharan with Shan to a person having ordinary skill in the art.
With respect to claim 7, Muralidharan in view of Shan and Lyu teaches all of the limitations of claim 1, as noted above. Muralidharan further teaches wherein each of the digital twin Docker images is configured to be distributed and executed over a plurality of computing nodes(see FIG. 2 showing the Docker images distributed and executed over multiple computing nodes, [page 3]; “Each change in a docker image is versioned similarly to Git, and it helps for learning purposes as well as maintaining the lifecycle of the IoT device with minimal overhead and maintenance. Most of the IoT devices have enough resources to have a digital twin in the device itself. In case if the devices are resource-constrained, then the docker images reside in the IoT gateway”, [page 3 col 1 paragraph 1 lines 1-7], describing how and why the images need to be distributed across nodes), and when the digital twin Docker images are distributed and executed over the computing nodes, the scheduling module (Kubernetes, [page 3 col 1 paragraph 1 line 9]) monitors an execution state of the digital twin Docker image at each computing node to determine a target computing node for executing the target digital twin Docker image (“The docker containers need orchestration to monitor these virtual DT images and orchestrate the containers dynamically. We have explored a platform called Kubernetes, which is a multi-host container management platform [11]. Kubernetes holds one or more containers together and reports the status when there is a failure or an update. Kubernetes enables easy tracking of the DT’s deployed in the form of docker images in multi-hosts”, [page 3 col 1 paragraph 1 lines 7-14]; The Kubernetes platform helps us in scaling a new DT image when one fails. Resource provisioning and scaling are inbuilt features of Kubernetes, [page 3 col 1 paragraph 3 lines 9-11]).
With respect to claim 8, Muralidharan in view of Shan and Lyu teaches all of the limitations of claim 1, as noted above. Muralidharan further teaches wherein the scheduling module (Kubernetes, [page 3 col 1 paragraph 1 line 9]) identifies available resources of each computing node based on a result of monitoring the execution state of the digital twin Docker image in each computing node (The Kubernetes platform helps us in scaling a new DT image when one fails. Resource provisioning and scaling are inbuilt features of Kubernetes, [page 3 col 1 paragraph 3 lines 9-11]), determines a required resource required (called resource constraints, [page 3 col 1 paragraph 1 line 6]) when the target digital twin Docker image is executed, and determines a computing node securing available resource above the determined required resource as the target computing node (“Most of the IoT devices have enough resources to have a digital twin in the device itself. In case if the devices are resource-constrained, then the docker images reside in the IoT gateway [10]. The docker containers need orchestration to monitor these virtual DT images and orchestrate the containers dynamically. We have explored a platform called Kubernetes, which is a multi-host container management platform [11]. Kubernetes holds one or more containers together and reports the status when there is a failure or an update. Kubernetes enables easy tracking of the DT’s deployed in the form of docker images in multi-hosts”, [page 3 col 1 paragraph 1 lines 1-14]; The Kubernetes platform helps us in scaling a new DT image when one fails. Resource provisioning and scaling are inbuilt features of Kubernetes, [page 3 col 1 paragraph 3 lines 9-11]).
With respect to claim 9, Muralidharan in view of Shan and Lyu teaches all of the limitations of claim 1, as noted above. Muralidharan and Shan do not teach wherein the asset indicates at least one of a facility, a process, a line, and a legacy manufacturing system in a manufacturing site.
However, Lyu teaches wherein the asset indicates at least one of a facility, a process, a line, and a legacy manufacturing system in a manufacturing site (digital twins are set up to test things like valves in manufacturing plants: “Now, many simulation software and platforms are used to train operators, optimize user interfaces, and secure the manufacturing processes. To utilize simulation in smart systems appropriately, structures and methods need to be designed and implemented carefully to ensure that multiple simulators run cooperatively and synchronously [6]. Collaborative Digital Twin is an excellent option to cooperate with those complicated and interactive smart systems. Collaborative digital twin refers to a digital twin that can operate multilaterally in the cloud. It enables different actors, such as equipment providers and system owners, to do the test in the cloud with their own equipment or customized options. For example, an equipment provider can test a specific valve for the existing system to check if this new valve is a better option than the existing, [page 9 paragraph 5 line 6-22]; the digital twin simulation software is called “Apros”, see a discussion how a plant is set up and simulated, [page 16]; the simulation is tested against the plant shown in FIG. 23, [page 51]; each symbol indicates a different asset in the plant).
It would have been obvious to one skilled in the art before the effective filing date to combine Muralidharan in view of Shan with Lyu because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Muralidharan in view of Shan discloses a system that teaches how to implement a digital twin for a class of technology called IoT devices. Lyu provides an explanation as to how this technology (IoT) can be applied to a specific business vertical called the manufacturing industry, now most referred to as industry 4.0:
Industry 4.0 enhances the reliability of the connection between the virtual and physical world. Because of that, smart systems now can be linked through advanced technologies like IoTs. Multiple intelligent systems can be combined and operated together. Thus cyber-physical systems can utilize them to achieve bigger goals and better performance.
(Lyu [page 9 paragraph 3]).
A person having skill in the art would have a reasonable expectation of improving performance of a manufacturing enterprise in the system and method of Muralidharan in view of Shan by modifying Muralidharan in view of Shan to apply to the plant facilities of Lyu. Therefore, it would have been obvious to combine Muralidharan in view of Shan with Lyu to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 10, Muralidharan teaches A method of executing a digital twin, the method comprising (see method shown in FIG. 2, [page 3], method explained in writing, [page 2 col 2 paragraph 4]-[page 3 col 1 paragraph 1]; essentially, DT models are bundled with platform dependencies in Docker images; the images are then instantiated in containers based on resources constraints, either on the IoT device itself or on the Edge/IoT gateway; monitoring and orchestration are performed by Kubernetes).
Regarding the rest of claim 10, incorporating the rejection of claim 1, claim 10 is rejected for a substantially similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230108560 A1 (Wang) – see FIG. 6A for graph programming and composition process, and FIG. 7 for graph execution; In a container embodiment in particular, processor drive 519 comprises a docker image that has different components as libraries such as Tensorflow, Pytorch driver functions that use the framework. Processor invocation would then involve deploying the image to the container and running commands on the container through a container platform such as Docker or container orchestration Kubernetes, [0114].
US 2021/0064433 A1 (Nakfour) - A workflow resource manager receives a request to execute a workflow in a cloud computing environment, where the workflow comprises a first set of operations and a second set of operations, and where the first set of operations precedes the second set of operations in the workflow. The workflow resource manager determines a set of cloud computing resource requirements associated with the second set of operations, determines whether the set of cloud computing resource requirements associated with the second set of operations is satisfied by available cloud computing resources, and responsive to determining that the set of cloud computing resource requirements associated with the second set of operations is not satisfied by the available cloud computing resources, rejects the request to execute the workflow, [Abstract].
US 2018/0137431 A1 (Goldfarb) - By storing the output (e.g., analytic results) to a data store that may be used as an input source to the second component, and coupling that with the ability to read input data from a cluster, the inventors note that processes/analytics/ models may be chained together easily in sequences. This allows the machine learning scientist to very easily execute pipelines or workflows of operations, such as a data cleaning step, a missing data imputation step, a feature extraction step, and an analytical model execution, all with a single command, [0024] lines 21-30; According to some embodiments described herein, the system 100 may be used to provide models in association with a machine learning framework, for example, a "digital twin" of a twinned physical system. A digital twin may be a high fidelity, digital replica or dynamic model of an asset or process, used to continuously gather data and increase insights, thereby helping to manage industrial assets at scale and optimize business operations, [0031] lines 1-8; Then in S218, a model is executed in an operations container 124. In one or more embodiments, the model container 124 may be a Docker container, or any other suitable program that may be executed, for example and exe file or a python file. As used herein, a "container" is a software packaging method consisting of an application's complete runtime environment, including its dependencies, libraries, and configuration files, allowing the application to run reliably when moved from one computing environment to another, [0046] lines 9-18.
CN112882765A - In this embodiment of the invention, after obtaining the digital twin model to be scheduled, the obtained digital twin model to be scheduled can be packaged into a Docker image, and then the startup parameters for starting the digital twin model to be scheduled can be determined. The startup parameters are then converted into the first startup parameters of the corresponding Docker image, so as to start the digital twin model to be scheduled packaged into a Docker image using the first startup parameters, [0095].
“Cost-Efficient and Latency-Aware Workflow Scheduling Policy for Container-based Systems” (2018-Zhang) –
PNG
media_image3.png
208
358
media_image3.png
Greyscale
[page 764].
“Custom Execution Environments with Containers in Pegasus-enabled Scientific Workflows” (2019-Vahi) - Science reproducibility is a cornerstone feature in scientific workflows. In most cases, this has been implemented as a way to exactly reproduce the computational steps taken to reach the final results. While these steps are often completely described, including the input parameters, datasets, and codes, the environment in which these steps are executed is only described at a higher level with endpoints and operating system name and versions. Though this may be sufficient for reproducibility in the short term, systems evolve and are replaced over time, breaking
the underlying workflow reproducibility. A natural solution to this problem is containers, as they are well defined, have a lifetime independent of the underlying system, and can be user-controlled so that they can provide custom environments if needed. This paper highlights some unique challenges that may arise when using containers in distributed scientific workflows. Further, this paper explores how the Pegasus Workflow Management System implements container support to address such challenges, [Abstract].
“A wholistic optimization of containerized workflow scheduling and deployment in the cloud–edge environment” (2022-Li) - Digital Twin in Industry 4.0 utilizes Internet of Things (IoT) to collect real-life data and combine it with simulation models for product design and development. The simulation process can be executed as a workflow, consisting of tasks with precedence constraints. In a container based workflow execution system, each task in the workflow is executed in a container within a virtual machine (VM). In this paper, a three-step scheduling model is proposed to combine scheduling of container-based workflows and the deployment of containers on a cloud–edge environment. In the first step, virtual CPU (vCPU) is allocated for each container to enable vCPU sharing among different containers. Next, two-step resource deployment is used to schedule the containers onto VM, and VM onto the physical machines in either edge or cloud environment. Multiple objectives are considered, including minimizing makespan, load imbalance, and energy consumption, from the perspective of cloud–edge resources as well as containerized workflows, [Abstract].
“Micro-Workflows: Kafka and Kepler fusion to support Digital Twins of Industrial Processes” (2018-Radchenko) - In recent years, we observe an exponential growth of "Smart Industry" concept that relies on the use of software and hardware systems to analyze data from several types of smart sensors by various types of models: mathematical, computational, data, etc. A set of such virtual models, representing processes, systems and equipment is called "Digital Twins" (DTs). DTs use data gathered from the sensory systems on production lines to predict failures of machinery, optimize the quality of the products, and reduce the ecological footprint from facilities. They can be described as a sequence of jobs that perform required functionality linked together by a set of edges that represent data dependencies. To organize a flexible cloud computing support for the Digital Twin execution, we propose a concept of Micro-Workflows that combines the power of scientific workflows, the flexibility of containers technology, and robustness of the distributed streaming approach, [Abstract].
“Digital Twin-driven online anomaly detection for an automation system based on edge intelligence” (2021-Huang) - Accurate anomaly detection is critical to the early detection of potential failures of industrial systems and proactive maintenance schedule management. There are some existing challenges to achieve efficient and reliable anomaly detection of an automation system: (1) transmitting large amounts of data collected from the system to data processing components; (2) applying both historical data and real-time data for anomaly detection. This paper proposes a novel Digital Twin-driven anomaly detection framework that enables real-time health monitoring of industrial systems and anomaly prediction. Our framework, adopting the visionary edge AI or edge intelligence (EI) philosophy, provides a feasible approach to ensuring high-performance anomaly detection via implementing Digital Twin technologies in a dynamic industrial edge/cloud network. Edge-based Digital Twin allows efficient data processing by providing computing and storage capabilities on edge devices. A proof-of-concept prototype is developed on a LiBr absorption chiller to demonstrate the framework and technologies’ feasibility. The case study shows that the proposed method can detect anomalies at an early stage, [Abstract].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL MILLER whose telephone number is (408) 918-7548. The examiner can normally be reached on Monday-Friday from 11am to 5pm (PT).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young, can be reached at telephone number (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/D.M./Examiner, Art Unit 2187
/KEVIN L YOUNG/ Supervisory Patent Examiner, Art Unit 2194