DETAILED ACTION
This action is responsive to RCE filed on September 14, 2026.
Claims 1, 8, 11, 13 and 17-18 have been amended. Claims 6-7 have been canceled. Claims 2, 12 and 16 have been previously canceled. Claims 19-22 have been newly added
Claims 1, 3-5, 8-11, 13-15 and 17-22 are pending and presented for examination.
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 September 14, 2026 has been entered.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The objection to claims 6-8 set forth in the Final Office Action mailed March 13, 2026 is withdrawn as to claims 6 and 7 in view of applicant’s cancellation of those claims, and is withdrawn as to claim 8 in view of applicant’s amendment.
The rejection of claim 13 under 35 U.S.C. 112(b) set forth in the Final Office Action mailed March 13, 2026 is withdrawn. The amendment to claim 13 deletes the phrases “, wherein the” and “again” and inserts the phrase “so that a further”, so that the limitation now reads “updating the predetermined negative list so that a further predetermined negative list results”. The examiner has verified this amendment against the claim listing of record. As amended, the limitation is grammatically complete and its metes and bounds are ascertainable. The rejection is accordingly withdrawn.
The rejections of claims 1, 3, 5-9 and 17 under 35 U.S.C. 103 over Sethi in view of Goud, of claim 4 over Sethi in view of Goud and further in view of Vazquez-Canteli, and of claims 10-11, 13-15 and 18 over Sethi in view of Goud and further in view of Marisetty, each as set forth in the Final Office Action mailed March 13, 2026, are withdrawn.
Goud, Marisetty and Vazquez-Canteli are no longer applied in the combinations set forth in the prior action. New grounds of rejection over Sethi in view of Moyal and further in view of Morley; over Sethi in view of Moyal and Morley and further in view of Davis; and over Sethi in view of Moyal and Morley and further in view of Vazquez-Canteli, are set forth below.
Response to Arguments
Applicant’s argument that the analysis of the “integration state” limitation does not comply with 37 C.F.R. 1.104(c)(2) (Remarks, pages 9-10) has been fully considered and is persuasive as to the prior action. The limitation, formerly recited in claim 7, now appears in each of independent claims 1, 11 and 17-18. It is addressed on the merits below with pinpoint citations and an articulated rationale.
For purposes of the rejections set forth below, the phrase “at least one integration state of the software” is construed in light of the specification. Paragraph [0004] of the published application describes subunits of the software that are “respectively developed substantially independently of one another” and are “integrated into the software”. Paragraph [0005] states that provisioning may take place “at any time and/or respectively after changing an integration state”. Paragraph [0026] states that a repetition may be triggered “in an event-oriented manner, for example as a result of a new integration state of the software (during software development)”. Paragraph [0049] states that basing the updating on integration states ensures that the plurality of digital twins “corresponds to a current software development level”. Paragraph [0032] identifies the subunits as, for example, an operating system, a library, a runtime component or an application, and states that “any development level of a subunit of the software may be uniquely identified by a (sub)version”. Paragraph [0050] states that the predetermined criterion that triggers the updating may take into account “if new (sub)versions of the software and/or its subunits are issued/integrated”, and paragraph [0051] states that an integration state may be received “after an integration step has been completed”. An integration state of the software is therefore the state of integration of the software’s subunits, that is, which subunit versions are presently built into the software; and the arrival of a new or modified version for integration constitutes a new integration state.
Applicant’s argument that a virtual machine is not a digital twin, and that the virtual machines 105 of Goud are therefore not the claimed digital twins (Remarks, pages 10-11), has been fully considered and is persuasive. Goud is no longer applied.
The rejections set forth below do not rely on a virtual machine. The digital twins are mapped to the replica containers 134(1) to 134(N) of Sethi, as combined with Moyal, each of which is created and configured from the configuration data 140 that a specific client device 102(N) itself transmitted and that is stored in the configuration database 136 (Sethi, paragraphs [0026], [0028] and [0034]). Sethi’s replica container is therefore linked to a specific real-world counterpart, which is the very characteristic applicant identifies as distinguishing a digital twin from a virtual machine. The rejections further apply Moyal, which uses the term itself and defines a digital twin as “a virtual representation that serves as the real-time digital counterpart of a real customer environment” (Moyal, paragraph [0018]). In the combination, each of Sethi’s replica containers is such a digital twin of the specific client device it replicates. Applicant’s own disclosure is not to the contrary: paragraph [0002] of the published application states that digital twins “can be used to digitally map “real” (tangible and/or intangible) systems or partial aspects thereof” and that “[s]uch mappings may be based on models and/or simulations”. Neither the claims nor the specification requires a live or bidirectional communicative link.
Applicant’s incorporation of former claims 6 and 7 into the independent claims has been fully considered. The incorporation has introduced a duplicate limitation into each of claims 1, 11, 17 and 18, which is addressed under 35 U.S.C. 112(b) below.
Drawings
The drawings are objected to under 37 C.F.R. 1.83(a) and 37 C.F.R. 1.84(p)(5).
FIG. 4 bears the descriptive legend “continuous integration and/or deployment delivery system”. The specification and the claims consistently recite “continuous integration and/or deployment/delivery system”, with a solidus between “deployment” and “delivery”, at paragraphs [0005], [0010], [0011], [0026], [0030], [0062] and [0063] of the published application and in each of claims 17 and 18. The legend in FIG. 4 omits the solidus and is therefore inconsistent with the specification and the claims.
Corrected drawing sheets in compliance with 37 C.F.R. 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 C.F.R. 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.
Specification
The disclosure is objected to because of the following informalities, each appearing at paragraph [0066] of the published application.
Paragraph [0066] recites “The computer system comprise a server on a network (e.g., the internet, ...)”. The verb does not agree with the subject and an auxiliary appears to have been omitted. Appropriate correction is required, for example “The computer system may comprise a server on a network”, consistent with the two immediately preceding sentences of the same paragraph.
Paragraph [0066] recites “Furthermore, the computer system may comprise a memory (e.g., HDD, SDD, ...)”. The acronym “SDD” appears to be a typographical error for “SSD”, the conventional abbreviation for a solid state drive. Appropriate correction is required.
Appropriate correction is required.
Claim Objections
Claims 9, 17-18 and 21 are objected to because of the following informalities.
Claim 9 recites “receiving at least one integration state for the software”. Claim 1, from which claim 9 depends, already introduces “at least one integration state of the software”. Claim 9 should refer back to that element with the definite article and with the same preposition, for example “receiving the at least one integration state of the software”.
Claim 17 recites a processor configured to “provide”, “monitor”, “evaluate”, “add” and “update”, each in the infinitive form, and then recites “and updating the plurality of digital twins for the system” in the gerund form. The last recited step should be in the same grammatical form as the steps that precede it, for example “and update the plurality of digital twins for the system”.
Claim 18 recites the conjunction “and” before each of its last two recited steps, namely “ineligible for provisioning; and updating the plurality of digital twins for the system” and “at least one existing digital twin; and updating the plurality of digital twins for the system”. The conjunction should appear only before the last recited step.
Claim 21 depends from claim 17 and is objected to as incorporating the informality of claim 17.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 3-5, 8-11, 13-15 and 17-22 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.
Claims 1, 11 and 17-18 each recite the step of updating the plurality of digital twins twice. In claim 1, the fifth recited step is “updating the plurality of digital twins for the system, wherein, during the updating, the plurality of digital twins are: (i) extended by generating at least one new digital twin, and/or (ii) reduced by deconstructing or deactivating at least one existing digital twin”, and the sixth recited step is “updating the plurality of digital twins for the system, wherein, during the updating, the plurality of digital twins are: (i) extended by generating at least one new digital twin, and/or (ii) reduced by deconstructing or deactivating at least one existing digital twin and/or (iii) changed by adjusting at least one existing digital twin, wherein the updating is based on at least one integration state of the software”. The two steps are identical through alternative (ii). It is therefore unclear whether the claim requires two separate updating operations or one, and the phrase “wherein the updating is based on at least one integration state of the software” has two possible antecedents, so that it cannot be determined which updating step is required to be based on an integration state. Claims 11, 17 and 18 recite the same duplicated step and are indefinite for the same reason. For purposes of examination, the examiner interprets claims 1, 11 and 17-18 as requiring a single updating of the plurality of digital twins in which the plurality of digital twins are extended by generating at least one new digital twin, and/or reduced by deconstructing or deactivating at least one existing digital twin, and/or changed by adjusting at least one existing digital twin, that updating being based on at least one integration state of the software.
Claims 1, 11 and 17-18 each recite “evaluating the configuration of the software of the at least one digital twin”. The only earlier recitation of a configuration in these claims is “wherein the digital twins have different configurations of the software for the system”, which is plural and is recited collectively of the plurality of digital twins. There is therefore insufficient antecedent basis for the singular “the configuration of the software of the at least one digital twin”. For purposes of examination, the examiner interprets this limitation as referring to that one of the different configurations of the software which is carried by the at least one digital twin being monitored.
Claims 1, 11 and 17-18 each recite “when at least one abnormal state was recognized during the monitoring of the at least one digital twin”. The antecedent recitation in each of these claims is “an abnormal state of the at least one digital twin”, in the singular. It is unclear whether “at least one abnormal state” refers to that same abnormal state or introduces a further and broader recitation. For purposes of examination, the examiner interprets “at least one abnormal state” as referring to the abnormal state recited in the monitoring step.
Claim 8 recites “wherein the updating of the plurality of digital twins for the system is triggered according to a predetermined criterion”. Claim 8 has been amended to depend from claim 1, and claim 1 recites two updating steps as set forth above. It cannot be determined which of the two updating steps of claim 1 is required to be triggered according to a predetermined criterion. For purposes of examination, the examiner interprets claim 8 as requiring that the single updating of the plurality of digital twins, as interpreted above with respect to claim 1, be triggered according to a predetermined criterion.
Claim 22 recites “The continuous integration and/or deployment/delivery system as recited in claim 22”. A claim cannot depend from itself. The claim therefore fails to define the subject matter it encompasses, because the recited limitations cannot be added to any set of limitations from a preceding claim. It appears from the pattern of claims 19-21, which depend respectively from claims 1, 11 and 17, that claim 22 was intended to depend from claim 18. For purposes of examination, the examiner interprets claim 22 as depending from claim 18.
Claims 3-5, 8-10 and 19 are rejected as depending from claim 1; claims 13-15 and 20 are rejected as depending from claim 11; and claim 21 is rejected as depending from claim 17. Each of these dependent claims incorporates by reference all of the limitations of its base claim and does not cure the indefiniteness of that base claim. For purposes of examination, each of these dependent claims is interpreted in accordance with the interpretations of its base claim set forth above.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 22 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 22 recites “The continuous integration and/or deployment/delivery system as recited in claim 22”. Claim 22 does not contain a reference to a claim previously set forth, because the only claim referenced is claim 22 itself. As set forth in MPEP 608.01(n), subsection III, the test for a proper dependent claim is whether the dependent claim would be infringed by anything that would also infringe the claim from which it depends; a claim that refers only to itself cannot satisfy that test, because there is no previously set forth claim whose limitations it incorporates. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements. As set forth above with respect to the rejection under 35 U.S.C. 112(b), for purposes of examination claim 22 is interpreted as depending from claim 18.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3, 5, 8-11, 13-15, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sethi et al. (US Pub. No. 2021/0334195, hereinafter “Sethi” – previously presented) in view of Moyal et al. (US Pub. No. 2023/0036410, hereinafter “Moyal”) and further in view of in view of Morley et al. (US Pub. No. 2016/0162275, hereinafter “Morley”).
With respect to claim 1 (Currently Amended), Sethi teaches a computer-implemented method for continuously monitoring configurations of software for a system, the method comprising the following steps: (Sethi, paragraphs [0017], [0031] and [0043]. Here, Sethi discloses a computer-implemented method carried out by a verification server for repeatedly verifying vendor updates to software installed on client devices before those updates are released, stating that the system may “receive an update (e.g., software or firmware) from a vendor, determine that a client device has subscribed to the update, create a container, configure the container based on the client device’s configuration to replicate the client device, install the update in the container, perform tests on the container with the update installed, analyze the logs generated by performing the tests, and release the update to the client device”, and that this verification is carried out each time an update is received, thereby continuously monitoring the configurations of the software for the client device).
providing input data to a plurality of digital twins for the system, wherein the digital twins have different configurations of the software for the system (Sethi, paragraphs [0024], [0026], [0028], [0034] and [0059]. Here, Sethi discloses a plurality of replica containers, stating that the verification server “may include machine learning 126, multiple tests 128, a verification module 130, log collection 132, and containers 134(1) to 134(N)”, and that each container is built from configuration data that a specific client device itself transmitted, stating that the verification module “may create a container, such as the container 134(N), retrieve the configuration data 140 sent by the client device 102(N) and stored in the configuration database 136, and configure the container 134(N) based on the configuration data 140” and that it thereby “may replicate a configuration of one of the client devices 102 using one of the containers 134”. Each such container replicates a specific client device and, in the combination with Moyal set forth below, is a digital twin of that client device. Sethi further discloses that the several containers carry different configurations, stating that “the configuration database 136 may include multiple configurations, with each configuration of the multiple configurations corresponding to a particular client device 102”, and that the configuration data “may include information identifying the software 116, the drivers 118, and the firmware 122 associated with each of the client devices 102”, so that the containers built from those configurations have different configurations of the software. Sethi further discloses providing input data to the containers, stating that the verification module “may configure the container 134(N) to replicate the client device 102(N) by installing, in the container 134(N), the software 116, the drivers 188, and virtual versions of the components 120 with the firmware 122” and that it “may install the vendor update 144 in the container 134(N)” and then perform the tests on that container).
monitoring at least one digital twin of the plurality of digital twins, which is executed at least based on the input data, wherein the monitoring is configured to recognize an abnormal state of the at least one digital twin (Sethi, paragraphs [0028], [0035], [0038], [0041] and [0060]. Here, Sethi discloses executing the container with the installed software and watching it for abnormal behavior, stating that “the process may perform multiple tests on the replica container with the update installed”, that “the process may collect logs generated from performing the multiple tests”, and that “the process may analyze the logs to determine if the update causes issues to the replica container with the update installed”. Sethi further discloses that the monitoring recognizes abnormal states of the executing container, stating that the verification module “may determine if an issue occurred by determining if an unrequested restart or reboot occurred, whether a system memory dump was created, whether a blue screen of death (BSOD) occurred, or whether another type of error response was initiated by the operating system”, and that where an issue is encountered the collected data identifies “which particular test of the tests 128 cause the issue, a type of the particular test, test parameters used by the particular test, data provided in the logs 202, parameters associated with the error”. An unrequested reboot, a memory dump, a blue screen of death or another operating-system error response is an abnormal state of the executing container. Sethi does not use the term “digital twin” for its replica containers; that difference is supplied by Moyal, as set forth below).
evaluating the configuration of the software of the at least one digital twin as ineligible for provisioning when at least one abnormal state was recognized during the monitoring of the at least one digital twin (Sethi, paragraphs [0030], [0043], [0046] and [0055]. Here, Sethi discloses that the outcome of the monitoring determines whether the tested configuration is released, stating that “[i]f the logs generated by performing the tests 128 to the container 134(N) … indicate that the vendor update 144 did not cause any issues, then the vendor update 144 may be sent to the client device 102(N) for installation”, and conversely that “[i]f the vendor update causes issues in the replica, then the vendor update is sent to the vendor, along with logs generated by performing the tests, to enable the vendor to modify the update to address the issues”. Sethi therefore evaluates the tested configuration as ineligible for release, and withholds it from the client device, whenever an issue is recognized during the testing of the replica container. Sethi does not use the term “digital twin” for its replica containers; that difference is supplied by Moyal, as set forth below).
updating the plurality of digital twins for the system, wherein, during the updating, the plurality of digital twins are: (i) extended by generating at least one new digital twin, and/or (ii) reduced by deconstructing or deactivating at least one existing digital twin (Sethi, paragraphs [0024], [0028], [0034] and [0059]. Here, Sethi discloses extending the plurality of replica containers by generating a new container whenever a further client-device configuration is to be verified, stating that “the process may create a container based on the configuration data to create a replica container that replicates the client device” and that the verification server “may create the container 134(N) and configure the container 134(N) based on the configuration data 140 to create a replica container that replicates the client device 102(N)”, the containers running from 134(1) to 134(N). Generating a further container is extending the plurality by generating at least one new digital twin. Sethi does not use the term “digital twin” for its replica containers; that difference is supplied by Moyal, as set forth below. The claim recites the element in the alternative and the prior art need teach only one alternative.).
updating the plurality of digital twins for the system, wherein, during the updating, the plurality of digital twins are: (i) extended by generating at least one new digital twin, and/or (ii) reduced by deconstructing or deactivating at least one existing digital twin and/or (iii) changed by adjusting at least one existing digital twin, wherein the updating is based on at least one integration state of the software (Sethi, paragraphs [0020], [0027], [0028], [0053] and [0055]. Here, Sethi discloses changing an existing replica container by adjusting it, and doing so as a direct function of which software version is presently to be integrated into the client’s software. Sethi discloses that the verification cycle is commenced upon receipt of a new vendor update, stating that “[t]he broker server 108 may periodically check with the backend server 104 to determine if a vendor update (e.g., the vendor update 144) has been received from one of the vendors 114” and that upon determining that the update was received it “may instruct the verification server 106 to verify that the vendor update 144 may not cause issues when installed in a particular client device”. Sethi then discloses adjusting the existing container when a further, modified version arrives for integration, stating that “[t]he verification server 106 may uninstall the vendor update 144 from the container 134(N) and install the modified update 206 in the container 134(N) and perform the tests 128 to the container 134 to determine if the modified update 206 causes issues”, and that this cycle “may be repeated until the testing reveals that no issues were caused by the update”. Sethi further discloses the same operation for a successive version, stating that the operations may include “receiving a second vendor update from the vendor, uninstalling the vendor update from the replica container, installing the second vendor update in the replica container, and performing the plurality of tests … to the replica container with the second vendor update installed”. Here, the existing container is not discarded and rebuilt; the software it carries is uninstalled and the newly integrated version is installed in its place, which is changing an existing digital twin by adjusting it. That adjustment is performed because a new or modified version of the software has arrived to be integrated, which is a new integration state of the software under the construction set forth above with respect to applicant’s arguments. Applicant’s specification confirms this reading. It identifies an operating system, a library, a runtime component and an application as subunits of the software, states that “any development level of a subunit of the software may be uniquely identified by a (sub)version” (published application, paragraph [0032]), and gives as the event on which the updating may depend the case in which “new (sub)versions of the software and/or its subunits are issued/integrated” (published application, paragraph [0050]). Sethi’s vendor update is “an update to (i) a BIOS, (ii) an operating system, (iii) a software application, (iv) a device driver, or (v) a firmware of a hardware component that is installed on the client device 102(N)” (Sethi, paragraph [0053]), that is, a new (sub)version of a subunit of the client’s software issued for integration. Sethi does not use the term “digital twin” for its replica containers; that difference is supplied by Moyal, as set forth below. The claim recites the element in the alternative and the prior art need teach only one alternative.).
Sethi is silent to disclose that its replica containers are digital twins; however, in an analogous art, Moyal teaches digital twins (Moyal, paragraphs [0018], [0027], [0028], [0029], [0030], [0056] and [0074]. Here, Moyal discloses testing software against a digital twin of the real environment in which that software is to run, and defines the term, stating that “A digital twin may be described as a virtual representation that serves as the real-time digital counterpart of a real customer environment”. Moyal discloses that the digital twin is executed with the software and is monitored for abnormal behavior, stating that the digital twin testing system “executes the code that has been developed so far with simulated data” and that “any deviation from the expected behavior based on the functional and non-functional requirements may be identified as defects”. Moyal further discloses that the testing is carried out across differing configurations, stating that “the digital twin functional and non-functional simulation testing may use different scenarios of different combinations of upstream applications and downstream applications interacting with the application being developed”, and that it is performed “[b]efore the application is moved to production”. In the combination, each of Sethi’s replica containers 134(1) to 134(N), which is configured from the configuration data transmitted by a specific client device and replicates that client device, is such a digital twin, being a virtual counterpart of that specific real client environment. The plurality of replica containers is therefore a plurality of digital twins, and each recitation of a digital twin in the limitations mapped to Sethi above reads on those replica containers, as set forth in each of those mappings.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have implemented each of Sethi’s replica containers as a digital twin of the client device it replicates, as taught by Moyal, because Moyal teaches that testing software against a digital twin before release allows issues to be corrected “to avoid further design, development, and validation cycles for the application being developed” (Moyal, paragraph [0074]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
Sethi in view of Moyal is silent to disclose; however, in an analogous art, Morley teaches adding an entry, including the configuration of the software of the at least one digital twin, to a predetermined negative list, based on the configuration of the software being evaluated as ineligible for provisioning; (Morley, paragraphs [0015], [0050], [0051], [0053] and [0058]. Here, Morley discloses a predetermined negative list by name, stating that “[i]f an application is found to be incompatible with a platform, and identified as such, then that application is said to be blacklisted for the platform to indicate such incompatibility”. Morley discloses that entries are added to that blacklist as the consequence of an evaluation, stating that “[e]ach time a malfunction report is received, the Update Server 35 updates the malfunction report database with a new entry to reflect the report and adjusts the malfunction tally and compatibility (e.g., whitelist or blacklist) status entries for the given application on the given platform version in the empirically derived app whitelist and blacklist table”, and that the evaluation itself is a determination of ineligibility, stating that the Update Server “compares the number of reported malfunctions with a threshold value of malfunction reports … and a threshold value of total number of installations of the application on the platform version” and that “[i]f both numbers exceed the threshold value, the application is deemed incompatible”. Morley further discloses that the entry added to the blacklist identifies the configuration of the software and not merely the fact of a failure, stating that the tables “contain the number of incompatibility reports or malfunction reports of an application by app ID, version number, and build number and are linked to a specific target platform number”. An application identifier together with a version number and a build number, linked to a platform version, is a configuration of the software).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal to add an entry identifying the failing software configuration to a predetermined negative list when that configuration is evaluated as ineligible for provisioning, as taught by Morley, because Morley teaches that the recorded incompatibility data are used “to ascertain whether applications should be quarantined or removed during platform upgrades” (Morley, paragraph [0032]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 3 (Original), Sethi teaches wherein the provided input data includes input data of the system and/or data derived from the input data of the system (Sethi, paragraphs [0026], [0034], [0052] and [0059]. Here, Sethi discloses that the data provided to the replica container originates from the client device that the container replicates, stating that “the process may receive configuration data from individual client devices” and that “the client device 102 (N) may send the configuration data 140 to the manufacturer 112”, and that the container is then populated with that data, the verification module configuring “the container 134(N) to replicate the client device 102(N) by installing, in the container 134(N), the software 116, the drivers 188, and virtual versions of the components 120 with the firmware 122”. The configuration data transmitted by the client device is input data of the system, and the software, drivers and virtual component versions installed into the container on the basis of that data are data derived from the input data of the system. The claim recites the element in the alternative and the prior art need teach only one alternative.).
With respect to claim 5 (Original), Sethi teaches wherein the at least one abnormal state of the at least one digital twin includes: an error in an execution of the at least one digital twin; and/or a deviation from states of the remaining digital twins of the plurality of digital twins; and/or an intrusion as a result of an intrusion detection system in the at least one digital twin (Sethi, paragraphs [0038] and [0041]. Here, Sethi discloses an error in the execution of the replica container, stating that the verification module “may determine if an issue occurred by determining if an unrequested restart or reboot occurred, whether a system memory dump was created, whether a blue screen of death (BSOD) occurred, or whether another type of error response was initiated by the operating system” and that it “may determine if an issue occurred by determining if a software application crashed or created a log indicating a problem”. Sethi further discloses recording the particulars of that error, stating that the log collection “may include which particular test of the tests 128 cause the issue, a type of the particular test, test parameters used by the particular test, data provided in the logs 202, parameters associated with the error”. An application crash, a blue screen of death, an unrequested reboot or an operating-system error response occurring while the container is executing is an error in an execution of the digital twin. Each replica container is a digital twin in the combination of Sethi in view of Moyal, as set forth with respect to claim 1. The claim recites the element in the alternative and the prior art need teach only one alternative.).
With respect to claim 8 (Currently Amended), Sethi teaches wherein the updating of the plurality of digital twins for the system is triggered according to a predetermined criterion (Sethi, paragraphs [0027], [0055] and [0061]. Here, Sethi discloses that the adjustment of the replica container is triggered by a defined condition rather than arbitrarily, stating that the broker server “may periodically check with the backend server 104 to determine if a vendor update … has been received from one of the vendors 114” and, on that condition being met, instructs the verification server to verify the update. Sethi further discloses that the repetition of the adjustment is governed by a stated criterion, namely the persistence of issues, stating that “[t]he process may repeat 510, 512, 516, and 518 until the update does not cause any issues during the verification process” and that “608, 610, 612, 614, 616, and 618 may be repeated until the process determines that the update received from the vendor does not cause any issues when installed in the replica container that includes the update”. The receipt of a vendor update, and the determination that the update still causes issues, are each a predetermined criterion according to which the updating of the containers is triggered. This accords with applicant’s specification, which states that the predetermined criterion may take into account “if new (sub)versions of the software and/or its subunits are issued/integrated” (published application, paragraph [0050]). Each replica container is a digital twin in the combination of Sethi in view of Moyal, as set forth with respect to claim 1).
With respect to claim 9 (Original), Sethi teaches further comprising: receiving at least one integration state for the software (Sethi, paragraphs [0023], [0027] and [0053]. Here, Sethi discloses receiving the version of the software that is to be integrated, stating that “one of the vendors 114 may provide a vendor update 144 to the manufacturer 112” and that “[a]fter receiving the vendor update 144, the manufacturer 112 may store the vendor update 144 in the vendor update database 124 on the backend server 104”. Sethi further discloses that the received update is identified by what it changes in the client’s software, stating that the broker server “may determine that the vendor update 144 is an update to (i) a BIOS, (ii) an operating system, (iii) a software application, (iv) a device driver, or (v) a firmware of a hardware component that is installed on the client device 102(N)”. The receipt of a vendor update identifying the subunit and version to be integrated into the client’s software is the receipt of an integration state for the software under the construction set forth above with respect to applicant’s arguments. Applicant’s specification likewise describes receiving an integration state as “retrieving the at least one integration state” or as being triggered “after an integration step has been completed” (published application, paragraph [0051])).
With respect to claim 10 (Previously Presented), Sethi in view of Moyal is silent to disclose; however, in an analogous art, Morley teaches wherein the predetermined negative list and/or portions of the predetermined negative list are retrievable via an application programming interface (API) (Morley, paragraphs [0032], [0034], [0040], [0041] and [0043]. Here, Morley discloses that the blacklist is exposed through an application programming interface, stating that “App Store Server 40 responds to service requests from the App Checker module 17, such as via an application programming interface (“API”) that is specified by the App Store Server 40” and that “the API is a series of Hypertext Transfer Protocol (“HTTP”) request and response messages, usually in an Extensible Markup Language (“XML”) format”. Morley discloses that the requesting module retrieves the list by means of that interface, stating that the App Checker module “makes an API call that sends a message to the App Store Server 40 to query whether each of the specific applications installed on the mobile device 15 are compatible with a target platform version and build”, and that the server “queries accessible databases which contain whitelist and blacklist information for applications on particular platforms” and returns the result. Morley further discloses that a portion consisting of the negative list alone may be returned, stating that “the generated catalog can include just the whitelisted applications, just the greylisted applcations, or just the blacklisted applications” and that “when the generated catalog includes just the blacklisted applications on the mobile device 15, immediate action may be take on those applications without any comparisons”. The claim recites the element in the alternative and the prior art need teach only one alternative.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal so that the predetermined negative list, or the portion of it consisting of the blacklisted entries, is retrievable via an application programming interface, as taught by Morley, because Morley teaches that querying the list through such an interface “can reduce network overhead by reducing the amount of data transmitted between the App Checker module 17 and App Store Server 40” (Morley, paragraph [0034]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 11 (Currently Amended), the claim recites limitations similar to claim 1 and is rejected for the same reasons set forth for claim 1, and differs only in that it further recites A computer-implemented method for continuously provisioning software for a system, comprising: receiving a configuration of the software; checking at least based on a predetermined negative list, whether the configuration of the software is ineligible for provisioning; and non-provisioning the software in the configuration based on a result of the check being positive, wherein the predetermined negative list and/or portions of the predetermined negative list are retrievable via an application programming interface (API), wherein the predetermined negative list is adjusted by:, which limitations are mapped below.
Sethi in view of Moyal is silent to disclose; however, in an analogous art, Morley teaches A computer-implemented method for continuously provisioning software for a system, comprising: (Morley, paragraphs [0024], [0027] and [0038]. Here, Morley discloses a computer-implemented method for repeatedly determining whether software is to be released to a device, stating that the App Checker module “pings or queries the Update Server 35 and requests whether a platform update is available” and that “[w]hen a platform update is available, App Checker module 17 determines whether each of the applications 16A-N installed on mobile device 15 … are compatible with the target platform version that is available in the update”, and that this determination is made repeatedly, stating that the App Checker module 17 “automatically checks the compatibility status of quarantined or removed applications after a predetermined time period, such as once a day, once a week, or once a month”).
receiving a configuration of the software; (Morley, paragraphs [0034] and [0040]. Here, Morley discloses receiving the configuration of the software whose eligibility is to be determined, stating that “an application registry of the mobile device 15 is pulled and a list is created that includes the unique application identifier (“app ID”) … as well as version and build numbers of the installed applications (collectively, “application credentials”)” and that “the generated application list of installed applications on the current platform version with app ID, version number, and build number are transmitted to the App Store Server 40 via the API call along with the target platform version”. An application identifier together with a version number and a build number is a configuration of the software, and that configuration is received by the server that performs the check).
checking at least based on a predetermined negative list, whether the configuration of the software is ineligible for provisioning; (Morley, paragraphs [0041] and [0043]. Here, Morley discloses checking the received configuration against the blacklist, stating that the App Store Server “queries accessible databases which contain whitelist and blacklist information for applications on particular platforms, specifically the target platform at issue” and “searches the whitelist and blacklist databases for each of the applications that reside in the generated application list received from App Checker module 17 and matches each application on the generated application list with a whitelist or blacklist entry on the target platform”. The outcome of that search is a determination of ineligibility, the returned catalog indicating “whether each application is compatible (i.e., is whitelisted, greylisted, or blacklisted for the target platform version)”).
non-provisioning the software in the configuration based on a result of the check being positive, (Morley, paragraphs [0025], [0043], [0044] and [0046]. Here, Morley discloses withholding the software in the configuration found on the blacklist, stating that “if a compatibility match is not found in the target version catalog … the App Checker module 17 populates an application quarantine or removal database with the application identifying information, including the app ID, version number, build number, and a status of whether the application is affirmatively quarantined or removed”, and that quarantine means “to isolate an application such that the application is no longer capable of execution on the mobile device 15”. Morley further discloses withholding the update itself, stating that “the App Checker module 17 allows the subscriber to cancel the platform upgrade altogether if compatibility of particular application(s) are important enough to justify the maintenance of the current platform version”).
wherein the predetermined negative list and/or portions of the predetermined negative list are retrievable via an application programming interface (API), (Morley, paragraphs [0032], [0034] and [0041]. Here, Morley discloses that the list is retrieved through an application programming interface, stating that “App Store Server 40 responds to service requests from the App Checker module 17, such as via an application programming interface (“API”) that is specified by the App Store Server 40”, that the App Checker module “makes an API call that sends a message to the App Store Server 40”, and that the returned catalog “can include just the whitelisted applications, just the greylisted applcations, or just the blacklisted applications”, which is a portion of the negative list. The claim recites the element in the alternative and the prior art need teach only one alternative.).
wherein the predetermined negative list is adjusted by: (Morley, paragraphs [0050], [0051] and [0054]. Here, Morley discloses that the blacklist is adjusted on the basis of the outcomes observed for the software, stating that “[t]he empirically derived compatibility (i.e., whitelist or blacklist) status is continuously monitored and updated by the Update Server 35”, that the server “updates the malfunction report database with a new entry to reflect the report and adjusts the malfunction tally and compatibility (e.g., whitelist or blacklist) status entries for the given application on the given platform version”, and that “the compatibility status (i.e., whitelist or blacklist status) … is updated or adjusted based on this threshold analysis”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal so that a received software configuration is checked against the predetermined negative list, is not provisioned when that check is positive, and is checked against a list that is retrievable via an application programming interface and adjusted on the basis of observed failures, as taught by Morley, because Morley teaches that this arrangement serves for “identifying and isolating applications on a customized mobile device that are incompatible with a platform update” (Morley, paragraph [0015]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 13 (Currently Amended), Sethi in view of Moyal is silent to disclose; however, in an analogous art, Morley teaches further comprising: updating the predetermined negative list so that a further predetermined negative list results (Morley, paragraphs [0050], [0051], [0054] and [0055]. Here, Morley discloses that the blacklist is repeatedly updated so that a further, revised blacklist results, stating that the Update Server “updates the number of malfunction reports as the reports are received in real time or in near real time, and then adjusts the empirically derived compatibility status based on a threshold value of malfunction reports”, that “[e]ach time a malfunction report is received, the Update Server 35 updates the malfunction report database with a new entry to reflect the report and adjusts the malfunction tally and compatibility (e.g., whitelist or blacklist) status entries for the given application on the given platform version”, and that as a result of that threshold analysis “a table like that shown in FIG. 4A can be generated or updated accordingly”. The generation of the revised table is the further predetermined negative list that results from the updating).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal so that the predetermined negative list is updated so that a further predetermined negative list results, as taught by Morley, because Morley teaches updating the list “in order to provide the App Checker module 17 with up to date interoperability information relative to a target platform version” (Morley, paragraph [0031]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 14 (Original), Sethi in view of Moyal is silent to disclose; however, in an analogous art, Morley teaches wherein the checking of whether the configuration of the software is ineligible for provisioning comprises checking whether the configuration of the software corresponds to at least one entry of the predetermined negative list (Morley, paragraphs [0041] and [0043]. Here, Morley discloses that the check is performed by matching the received configuration against the entries of the blacklist, stating that the App Store Server “searches the whitelist and blacklist databases for each of the applications that reside in the generated application list received from App Checker module 17 and matches each application on the generated application list with a whitelist or blacklist entry on the target platform”, and that the comparison is carried out entry by entry, “[t]he generated application list of installed applications on the current platform version with app ID, version number, and build number is compared to the application catalog of the target platform version on an iterative basis to find out whether each of the currently installed applications is or is not compatible with the target platform version”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal so that the check of whether the configuration of the software is ineligible for provisioning is performed by determining whether that configuration corresponds to an entry of the predetermined negative list, as taught by Morley, because Morley teaches that matching each configuration against the list entries means that “the catalog provides specific compatibility information for applications of interest to the mobile device 15” (Morley, paragraph [0041]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 15 (Original), Sethi in view of Moyal is silent to disclose; however, in an analogous art, Morley teaches further comprising: provisioning the software in the configuration based on the result of the check being negative (Morley, paragraphs [0043] and [0046]. Here, Morley discloses releasing the software when the check against the blacklist does not return a match, stating that “[w]hen a match (or yes/whitelist hit) is found in the target version catalog indicating the application is deemed compatible with the target platform version, no further action is taken with regard to the compatible application”, so that the application is neither quarantined nor removed, and that “[a]fter populating the quarantine or removal database, App Checker module 17 upgrades the mobile device 15 to the target platform version”, so that the software found not to be blacklisted is put into use on the device).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal so that the software is provisioned in the configuration when the result of the check is negative, as taught by Morley, because Morley teaches that where the configuration is found compatible “no further action is taken with regard to the compatible application” and the update proceeds (Morley, paragraph [0043]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 17 (Currently Amended), the claim is directed to a continuous integration and/or deployment/delivery system that recites limitations similar to claim 1 and is rejected for the same reasons set forth for claim 1, wherein Sethi teaches a continuous integration and/or deployment/delivery system configured to continuously monitor configurations of software for a system, the continuous integration and/or deployment/delivery system including a processor configured to: (Sethi, paragraphs [0016], [0020]-[0021], [0024] and [0070]-[0072]. Here, Sethi discloses a server-based system that carries out the verification and release of software updates, stating that “[m]ultiple servers, such as, a backend server 104, a verification server 106, and a broker server 108, associated with a manufacturer 112, may be connected to the network 110”, and that such a server includes a processor, stating that an information handling system “may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory”).
With respect to claim 18 (Currently Amended), the claim is directed to a continuous integration and/or deployment/delivery system that recites limitations similar to claim 11 and is rejected for the same reasons set forth for claim 11, wherein Sethi teaches a continuous integration and/or deployment/delivery system configured to continuously provision software for a system, the continuous integration and/or deployment/delivery system including a processor configured to: (Sethi, paragraphs [0016], [0020]-[0021], [0024] and [0070]-[0072]. Here, Sethi discloses a server-based system that carries out the release of software updates to client devices, stating that “[m]ultiple servers, such as, a backend server 104, a verification server 106, and a broker server 108, associated with a manufacturer 112, may be connected to the network 110”, and that such a server includes a processor, stating that an information handling system “may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory”).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Sethi et al. (US Pub. No. 2021/0334195, hereinafter “Sethi” – previously presented) in view of Moyal et al. (US Pub. No. 2023/0036410, hereinafter “Moyal”) in view of Morley et al. (US Pub. No. 2016/0162275, hereinafter “Morley”) and further in view of Davis (US Pub. No. 2021/0026758, hereinafter “Davis”).
With respect to claim 4 (Original), Sethi in view of Moyal and Morley is silent to disclose; however, in an analogous art, Davis teaches wherein the provided input data depend on at least one random variable and/or are based on fuzzing (Davis, paragraphs [0003], [0004], [0010], [0030], [0031] and [0045]. Here, Davis discloses supplying input data to an executing virtualized instance of a system under test, and discloses that those input data are generated by fuzzing and depend on a random variable. Davis defines the technique, stating that “fuzz testing or fuzzing is an automated software testing technique that involves providing invalid, unexpected, random, or pseudorandom data as inputs to virtual devices”, and that “[t]he fuzz tester is configured to iteratively construct operations with random or pseudorandom contents or inputs and transmit them to one or more virtual devices of the virtual machine”. Davis further discloses the random variable on which the provided input data depend, stating that “[t]he fuzzer control 130 can also include a pseudorandom number generator 134”, that “[a] pseudorandom number generator is an algorithm for generating a sequence of numbers whose properties approximate the properties of sequences of random numbers”, and that “the pseudorandom number generator can be used to generate pseudorandom input data for populating operation parameters to be included in fuzzing operations that are then sent to the fuzzer firmware”. Davis further discloses that the fuzzing is directed at an executing virtualized instance and that abnormal states of that instance are what the fuzzing is intended to surface, stating that “[i]n the event the virtual machine 160 crashes or hangs as a result of the fuzz testing” the process is handled accordingly. The input data provided to the virtual machine are therefore both based on fuzzing and dependent on at least one random variable. The claim recites the element in the alternative and the prior art need teach only one alternative.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal and Morley so that the input data provided to the digital twins depend on at least one random variable and are based on fuzzing, as taught by Davis, because Davis teaches that “[i]dentifying all possible unexpected inputs to a virtual device is not feasible. So, the primary way in which these defects are identified is through fuzz testing” (Davis, paragraph [0003]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
Claims 19-22 are rejected under 35 U.S.C. 103 as being unpatentable over Sethi et al. (US Pub. No. 2021/0334195, hereinafter “Sethi” – previously presented) in view of Moyal et al. (US Pub. No. 2023/0036410, hereinafter “Moyal”) in view of Morley et al. (US Pub. No. 2016/0162275, hereinafter “Morley”) and further in view of Vazquez-Canteli et al. (US Pub. No. 2022/0058497, hereinafter “Vazquez-Canteli” – previously presented).
With respect to claim 19 (New), Sethi in view of Moyal and Morley is silent to disclose; however, in an analogous art, Vazquez-Canteli teaches wherein the system is a real-world system, wherein the input data is temporally variable input data from the real-world system, and wherein each of the digital twins represents a respective dynamic model of the real-world system that is dependent on the temporally variable input data from the real-world system (Vazquez-Canteli, paragraphs [0006]-[0007], [0033], [0104] and [0105]-[0106]. Here, Vazquez-Canteli discloses that the modeled system is a real-world system, namely the physical equipment of a building automation system, stating that the method includes “receiving device event data for a plurality of devices” and that the digital twins correspond to such equipment “as illustrated above with respect to such elements as AHUs, VAVs, chillers, etc.”. Vazquez-Canteli further discloses that the input data are temporally variable data drawn from that real-world system, stating that the predictive maintenance engine “produces initial and ongoing probabilities of faults as a function of time” and “calculates a probability of failure at any time interval for a device from an annual failure rate of the device”. Vazquez-Canteli further discloses that each digital twin is a respective dynamic model that depends on those temporally variable data, stating that “[t]he fault diagnostics inference engine can include a plurality of digital twins each corresponding to a different device”, that “[e]ach digital twin can include a respective Bayesian network”, and that “[t]he Bayesian network(s) can be dynamic Bayesian networks that are updated from a predictive maintenance engine”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal and Morley so that the system is a real-world system, the input data are temporally variable input data from that real-world system, and each digital twin represents a respective dynamic model of that real-world system dependent on those data, as taught by Vazquez-Canteli, because Vazquez-Canteli teaches that with such dynamically updated models “[t]he inference engine can thereafter provide a better estimation on the root cause fault based on these updated failure rates” (Vazquez-Canteli, paragraph [0111]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 20 (New), Sethi in view of Moyal and Morley is silent to disclose; however, in an analogous art, Vazquez-Canteli teaches wherein the system is a real-world system, wherein the input data is temporally variable input data from the real-world system, and wherein each of the digital twins represents a respective dynamic model of the real-world system that is dependent on the temporally variable input data from the real-world system (Vazquez-Canteli, paragraphs [0006]-[0007], [0033], [0104] and [0105]-[0106]. Here, Vazquez-Canteli discloses that the modeled system is a real-world system, namely the physical equipment of a building automation system, stating that the method includes “receiving device event data for a plurality of devices” and that the digital twins correspond to such equipment “as illustrated above with respect to such elements as AHUs, VAVs, chillers, etc.”. Vazquez-Canteli further discloses that the input data are temporally variable data drawn from that real-world system, stating that the predictive maintenance engine “produces initial and ongoing probabilities of faults as a function of time” and “calculates a probability of failure at any time interval for a device from an annual failure rate of the device”. Vazquez-Canteli further discloses that each digital twin is a respective dynamic model that depends on those temporally variable data, stating that “[t]he fault diagnostics inference engine can include a plurality of digital twins each corresponding to a different device”, that “[e]ach digital twin can include a respective Bayesian network”, and that “[t]he Bayesian network(s) can be dynamic Bayesian networks that are updated from a predictive maintenance engine”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Sethi in view of Moyal and Morley so that the system is a real-world system, the input data are temporally variable input data from that real-world system, and each digital twin represents a respective dynamic model of that real-world system dependent on those data, as taught by Vazquez-Canteli, because Vazquez-Canteli teaches that with such dynamically updated models “[t]he inference engine can thereafter provide a better estimation on the root cause fault based on these updated failure rates” (Vazquez-Canteli, paragraph [0111]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 21 (New), Sethi in view of Moyal and Morley is silent to disclose; however, in an analogous art, Vazquez-Canteli teaches wherein the system is a real-world system, wherein the input data is temporally variable input data from the real-world system, and wherein each of the digital twins represents a respective dynamic model of the real-world system that is dependent on the temporally variable input data from the real-world system (Vazquez-Canteli, paragraphs [0006]-[0007], [0033], [0104] and [0105]-[0106]. Here, Vazquez-Canteli discloses that the modeled system is a real-world system, namely the physical equipment of a building automation system, stating that the method includes “receiving device event data for a plurality of devices” and that the digital twins correspond to such equipment “as illustrated above with respect to such elements as AHUs, VAVs, chillers, etc.”. Vazquez-Canteli further discloses that the input data are temporally variable data drawn from that real-world system, stating that the predictive maintenance engine “produces initial and ongoing probabilities of faults as a function of time” and “calculates a probability of failure at any time interval for a device from an annual failure rate of the device”. Vazquez-Canteli further discloses that each digital twin is a respective dynamic model that depends on those temporally variable data, stating that “[t]he fault diagnostics inference engine can include a plurality of digital twins each corresponding to a different device”, that “[e]ach digital twin can include a respective Bayesian network”, and that “[t]he Bayesian network(s) can be dynamic Bayesian networks that are updated from a predictive maintenance engine”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Sethi in view of Moyal and Morley so that the system is a real-world system, the input data are temporally variable input data from that real-world system, and each digital twin represents a respective dynamic model of that real-world system dependent on those data, as taught by Vazquez-Canteli, because Vazquez-Canteli teaches that with such dynamically updated models “[t]he inference engine can thereafter provide a better estimation on the root cause fault based on these updated failure rates” (Vazquez-Canteli, paragraph [0111]). See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); MPEP § 2143(I)(G).
With respect to claim 22 (New), and as set forth above under 35 U.S.C. 112(b) and 35 U.S.C. 112(d), claim 22 is interpreted for purposes of examination as depending from claim 18. So interpreted, the claim recites limitations similar to claim 21 and is rejected for the same reasons set forth for claim 21 (Vazquez-Canteli, paragraphs [0006], [0007], [0033], [0104], [0105] and [0106]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Dattatri et al. (US Pat. No. 11,003,433) discloses a software distribution blacklist that is populated when execution failures at target systems exceed a threshold and that thereafter prevents the software packet from being distributed to the blacklisted systems.
Madrid et al. (US Pub. No. 2018/0232223) discloses an updateable compatibility list at a vehicle telematics control unit and the cessation of an update where the resulting combination of module software versions would be incompatible.
Rockwell et al. (US Pub. No. 2016/0170775) discloses a module compatibility matrix used to determine whether a vehicle software configuration is compatible before a software update is switched into active use.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-6:00 PM.
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, Hyung S Sough can be reached at 571-272-6799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights