DETAILED ACTION (motivation)
This action is responsive to Remarks and Claim amendments filed on February 17, 2026.
Claims 1, 11 and 17-18 have been amended. Claims 2, 12 and 16 have been canceled.
Claims 1, 3-11, 13-15 and 17-18 are pending and are presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 amendments
The objection of claim 12 is withdrawn in view of applicant’s cancellation.
The objection of the disclosure (Abstract) is withdrawn in view of applicant’s clarification.
Response to Arguments
Applicant has argued that Sethi does not teach the newly added limitation of independent claims 1, 11 and 17-18 (Remarks, pages 8-9). Applicant's arguments have been fully considered and are persuasive. Therefore, the rejection is withdrawn. However, upon further consideration, a new ground of rejection is made as set forth in details below. See Goud et al. (US Pub. No. 2022/0283836, art being made of record as applied herein.
Claim Objections
Claims 6-8 are objected to because of the following informalities: Claim 6 recites “further comprising: updating the plurality of digital twins for the system, wherein, during the updating, the plurality of digital twins are: changed by adjusting at least one existing digital twin.”. Please amend the claim language as indicated in bold. Appropriate correction is required. Dependent claims 7-8 do not overcome the deficiency of the base claim and, therefore, are objected for the same reasons as the base claim.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 13 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 13 recites “further comprising: updating the predetermined negative list, wherein the predetermined negative list again results.”. It is unclear what “wherein the predetermined negative list again results.” means. It seems the claim language is incomplete. For examination purposes, the Examiner will interpret it as updating the predetermined negative list.
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-9 and 17 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 Goud et al. (US Pub. No. 2022/0283836 – hereinafter Goud).
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: 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 (See figures 2-6 (and related text) and paragraph [0052], “At 502, the process may receive configuration data from individual client devices. At 504, the process may receive a request to subscribe to updates (e.g., software updates or firmware updates) from the individual client devices. For example, in FIG. 1, one or more of the client devices 102 may send the configuration data 140, the subscription request 142, or both to a server, such as the broker server 108, of the manufacturer 112.”. See paragraph [0059], “At 604, the process may determine configuration data associated with the client device. At 606, the process may create a container based on the configuration data to create a replica container that replicates the client device. At 608, the process may install the update in the replica container. For example, in FIG. 1, the verification server 106 may determine the configuration data 140 associated with the client device 102(N) by accessing the configuration data 140 stored in the configuration database 136. The verification server 106 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 verification server 106 may install the vendor update 144 in the container 134(N) that replicates the client device 102(N).”. Examiner notes: configuration data provided in a container, each time the container (i.e., digital twin) is created it would have a different configuration). 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 (See figures 2-6 (and related text) and paragraph [0060], “At 610, the process may perform multiple tests on the replica container with the update installed. At 612, the process may collect logs generated from performing the multiple tests. At 614, the process may analyze the logs to determine if the update causes issues to the replica container with the update installed. For example, in FIG. 2, the verification module 130 may perform the tests 128 (e.g., in the order 146) to the container 134(N) with the vendor update 144 installed. The verification server 106 may collect the logs 202 generated by performing the tests 128 to the container 134(N). The verification module 130 may analyze the logs 202 generated by performing the tests 128 to the container 134(N) with the vendor update 144 installed. For example, the machine learning 126 may be used to analyze the logs 202 and previously gathered logs stored in the log collection 132.”. Examiner notes: monitoring the container). 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 (See figure 6 (and related text) and paragraphs [0060]-[0062], “At 610, the process may perform multiple tests on the replica container with the update installed. At 612, the process may collect logs generated from performing the multiple tests. At 614, the process may analyze the logs to determine if the update causes issues to the replica container with the update installed. For example, in FIG. 2, the verification module 130 may perform the tests 128 (e.g., in the order 146) to the container 134(N) with the vendor update 144 installed. The verification server 106 may collect the logs 202 generated by performing the tests 128 to the container 134(N). The verification module 130 may analyze the logs 202 generated by performing the tests 128 to the container 134(N) with the vendor update 144 installed. For example, the machine learning 126 may be used to analyze the logs 202 and previously gathered logs stored in the log collection 132.”. Examiner notes: evaluating the container). 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 (See figures 5-6 (and related text) and paragraph [0061], “If the process determines at 614, that the update causes issues to the replica container with the update installed, then the process may, at 616, send the logs generated by the multiple tests to the vendor. At 618, the process may receive a modified update from the vendor and the process map may proceed to 608, to install the modified update in the replica container. In this way, 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. For example, in FIG. 2, if the verification module 130 determines that the logs 202 indicate at least one issue, then the verification server 106 may send the logs 202 to a particular vendor (e.g., one of the vendors 114). The particular vendor may modify the update to create the modified update 206 to address the issue(s) and send the modified update 206 to the verification server 106. The verification server 106 may uninstall the vendor update 144, install the modified update 206 in the container 134(N), and perform the tests 128 to the container 134(N) with the modified update 206 installed. If the logs 202 generated as a result of performing the tests 128 indicate that the modified update 206 caused at least one issue, then the logs 202 may be sent to the particular vendor for further modification.”. Examiner notes: causes of issues captured in a log reported to vendors, i.e., negative list)). Sethi is silent to disclose, however in an analogous art, Goud teaches: 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 (See paragraph [0027], “virtualization manager 140 is a computer program that executes in a central server in data center 120 (e.g., the same or a different server than the server on which network manager 138 executes) or runs in one of VMs 105. Virtualization manager 140 is configured to carry out administrative tasks for data center 120, including managing hosts 102, managing VMs 105 running within each of host 102, provisioning VMs 105, transferring VMs 105 from between hosts 102, transferring VMs 105 between data centers, transferring application instances between VMs 105 or between hosts 102, and load balancing among hosts 102 within data center 120. Virtualization manager 140 takes commands from components as to creation, migration, and deletion decisions of VMs 105 and application instances on data center 120. Virtualization manager 140 also makes independent decisions on management of local VMs 105 and application instances, such as placement of VMs 105 and application instances between hosts 102.”. See paragraph [0056], “At 430, DRS 142 determines whether to configure the VM 105 for the host 102, whether a VM 105 is capable of being configured, and the configuration. At 432, DRS evaluates a minimum resource demand of the VM 105 and a desired state of the VM 105. DRS 142 may evaluate the minimum resource demand based on the VM 105's current resource usage and predicted future resource usage. DRS 142 may evaluate the desired state of the VM 105 based on its initial configuration. The minimum resource demand and desired state of the VM 105 helps DRS 142 determine whether a host 102 is capable of supporting performance of the VM 105 in its desired state or, at a minimum, meets the resource demand.”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Sethi’s teaching which relates generally to verifying a vendor software update and more particularly to verifying the vendor software update by executing tests on a container that replicates a configuration of a client server and using machine learning to analyze the test results, with Goud’s teaching, as Goud would provide steps for dynamic configuration of virtual objects. 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 (See figures 2-6 (and related text) and paragraph [0052], “At 502, the process may receive configuration data from individual client devices. At 504, the process may receive a request to subscribe to updates (e.g., software updates or firmware updates) from the individual client devices. For example, in FIG. 1, one or more of the client devices 102 may send the configuration data 140, the subscription request 142, or both to a server, such as the broker server 108, of the manufacturer 112.”. See paragraph [0059], “At 604, the process may determine configuration data associated with the client device. At 606, the process may create a container based on the configuration data to create a replica container that replicates the client device. At 608, the process may install the update in the replica container. For example, in FIG. 1, the verification server 106 may determine the configuration data 140 associated with the client device 102(N) by accessing the configuration data 140 stored in the configuration database 136. The verification server 106 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 verification server 106 may install the vendor update 144 in the container 134(N) that replicates the client device 102(N).”).
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 (See figures 5-6 (and related text) paragraph [0041], “If the verification module 130 determines that an issue is encountered, based on the logs 202, the verification module 130 may use the monitor 2082 retrieve various data and store the data in the log collection 132. For example, the log collection 132 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, parameters that the vendors 114 have requested be collected, and the like.”). With respect to claim 6 (original), Sethi teaches further comprising: updating the plurality of digital twins for the system, wherein, during the updating, the plurality of digital twins are: (iii) changed by adjusting at least one existing digital twin (See figures 5-6 (and related text) and paragraphs [0055], [0061], received modified update). With respect to claim 7 (original), Sethi teaches wherein the updating is based on at least one integration state of the software (See abstract and figures 1-7 (and related text), testing/verifying software/update/firmware before deploying to clients).
With respect to claim 8 (original), Sethi teaches wherein the updating of the plurality of digital twins for the system is triggered according to a predetermined criterion (See paragraph [0055], “if the process determines, at 512, that the update caused an issue to the container during the verification process, then the process may send data (e.g., logs, memory dumps, and the like) generated during the verification process to the vendor, at 516. At 518, the process may receive a modified update from the vendor. For example, the modified update may address the issues that were caused during the verification process. The process may proceed to 510 to verify the modified update using the container. The process may repeat 510, 512, 516, and 518 until the update does not cause any issues during the verification process. For example, in FIG. 2, if the verification server 106 determines that installing the vendor update 144 to the container 134(N) (e.g., that replicates the client device 102(N)) causes at least one issue, then the manufacturer 112 may send the vendor update 144 to a particular vendor of the vendors 114 that created the vendor update 144 along with the logs 202 that were generated when testing the vendor update 144. The particular vendor may send the modified update 206 to the manufacturer 112. The particular vendor may modify the vendor update 144 to create the modified update 2062 address the issues (e.g., indicated by the logs 202). The 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. The process (e.g., 510, 512, 516, 518) of receiving an update from one of the vendors 114 and testing the update in a container replicating a client device may be repeated until the testing reveals that no issues were caused by the update. After the verification server 106 determines that the modified update 206 does not cause any issues, the verification server 106 may send the modified update 206 to the client device 102(N).”. Examiner notes: update my manufacturer/vendor using collected log criteria). With respect to claim 9 (original), Sethi teaches further comprising: receiving at least one integration state for the software (See figure 6, verified update (step 620)).
With respect to claim 17 (currently amended), the claim is directed to a system that corresponds to the method recited in claim 1, respectively (see the rejection of claim 1 above, wherein Sethi also teaches such system in figures 1 and 8).
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 Goud et al. (US Pub. No. 2022/0283836 – hereinafter Goud) and further in view of Vazquez-Canteli et al. (US Pub. No 2022/0058497 – hereinafter Vazquez – previously presented).
With respect to claim 4 (original), Sethi in view of Goud is silent to disclose, however in an analogous art, Vazquez teaches wherein the provided input data depend on at least one random variable and/or are based on fuzzing (See paragraphs [0007], [0082], [0096], [0100] and figures 6, 8-9 (and related text), “in some embodiments, each digital twin includes a respective Bayesian network. In some embodiments, the fault diagnostics inference engine maintains links between Bayesian networks of digital twins corresponding to different devices. In some embodiments, each digital twin includes a respective conditional probability table. In some embodiments, each digital twin includes a respective voting network. In some embodiments, the predictive maintenance engine produces initial and ongoing probabilities of faults as a function of time. In some embodiments, the predictive maintenance engine calculates a probability of failure at any time interval for a device from an annual failure rate of the device. “. See paragraph [0105], “the system executes a fault diagnostics inference engine to determine faults corresponding to the device event data (1004). The faults can include control-logic configuration faults, software and human-induced faults, and/or hardware faults 614. The inference engine can include and base decisions on a Bayesian network that associates device events with device faults and can include a conditional probability table associated with the Bayesian network. The Bayesian network(s) can be dynamic Bayesian networks that are updated from a predictive maintenance engine. The fault diagnostics inference engine can include a plurality of digital twins each corresponding to a different device. Each digital twin can include a respective Bayesian network. The fault diagnostics inference engine can maintain links between Bayesian networks of digital twins corresponding to different devices (i.e., random variable)”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Sethi and Goud, by utilizing at least one random variable and/or are based on fuzzing as suggested by Vazquez, as Vazquez would calculates a probability of failure at any time interval for a device.
Claims 10-11, 13-15 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 Goud et al. (US Pub. No. 2022/0283836 – hereinafter Goud) and further in view of Marisetty et al. (US Pub. No. 2007/0061634 – hereinafter Marisetty – previously presented). With respect to claim 10 (previously presented), Sethi in view of Goud is silent to disclose, however in an analogous art, Marisetty teaches wherein the predetermined negative list and/or portions of the predetermined negative list are retrievable via an application programming interface (API) (See paragraph [0059], “This protocol (API) is produced (via EFI) by the platform firmware during platform initialization and gives higher-level software access to a non-volatile error log managed by the platform firmware.”). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Sethi and Goud, wherein the predetermined negative list and/or portions of the predetermined negative list are retrievable via an application programming interface (API) as suggested by Marisetty, as Marisetty would give higher-level software access to a non-volatile error log managed by the platform firmware.
With respect to claim 11 (currently amended), the claim is directed to a method that corresponds to the method recited in claims 1 and 10, respectively (see the rejection of claims 1 and 10 above, wherein non-provisioning the software in the configuration based on a result of the check being positive has been interpreted as a cycle/repeat/continuous process to evaluate and fix issues on the software until fully verified (see Sethi’s figure 5-6)). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify the combination of Sethi and Goud, wherein non-provisioning the software in the configuration based on a result of the check being positive as suggested by Marisetty, as Marisetty would provide a mechanism to evaluate and fix issues until the software/update is fully verified.
With respect to claim 13 (original), Sethi teaches further comprising: updating the predetermined negative list, wherein the predetermined negative list again results (see figure 4 (and related text) and paragraphs [0029], [0042], [0047]-[0048], different test and failure categories). With respect to claim 14 (original), Sethi 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 (see figure 4 (and related text) and paragraphs [0029], [0042], [0047]-[0048], checking the log). With respect to claim 15 (original), Sethi teaches further comprising: provisioning the software in the configuration based on the result of the check being negative (see figures 5-6 (and related text). Examiner notes: claim requirement has been interpreted as a cycle/repeat/continuous process to evaluate and fix issues on the software until fully verified).
With respect to claim 18, the claim is directed to a system that corresponds to the method recited in claim 11, respectively (see the rejection of claim 11 above, wherein Sethi also teaches such system in figures 1 and 8).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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 5712726799. 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