Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Continued Examination Under 37 CFR 1.114
1. 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 01/08/2026 has been entered.
Status of Claims
2. Applicants’ amendment dated 01/08/2026 responding to the Office Action 11/12/2025.
3. Claims 1-3, 6, 8-10, 13, 15-17 and 19 have been amended.
4. Claims 1-20 are pending in the application, of which claims 1, 8 and 15 are in independent form and which have been fully considered by the examiner.
Response to Amendments
5. (A) Regarding art rejection: Applicants’ amendment necessitated new grounds of rejections presented in the following art rejection. Please see Muehlenstaedt et al. (US Patent No. 12430236 B2).
Examiner Notes
6. Examiner cites particular columns 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 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.
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.
7. Claims 1-2, 6-7, 8-9, 13-14 and 15-16 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-2, 6-7, 8-9, 13-14 and 15-16 recite “at least part of the software” in lines 14-15 of claim 1; line 4 of claim 2; lines 1-3 of claim 6; line 2 of claim 7; lines 18-19 of claim 8; line 4 of claim 9; lines 2-3 of claim 13; line 2 of claim 14; lines 15-16 of claim 15; line 4 of claim 16; lines 2-3 of claim 19 and line 2 of claim 20 appear to mis-descriptive/unclear; and as such, it renders the claim indefinite.
Claims 4-5, 10-12 and 17-20 depend on claims 1, 8 and 16 are also rejected under 112(b).
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.
8. Claim(s) 1-2, 4-9, 11-16 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mueh et al. (US Patent No. 12430236 B2 – herein after Mueh) in view of Tadkase et al. (Us Pub. No. 2024/0272943 A1 – art of record -- herein after Tadkase).
Regarding claim 1.
Muel discloses
A method for providing timing-independence for software (automatic progression monitoring and review of software testing outputs in order to detect anomalies such as outliers, unusual patterns, unusual trends, or the like – See col. 2, lines 42-45. Trending continuously upwards may be considered indicative of an anomalous behavior of the testing characteristic of the software program overtime or versions – See col. 8, lines 31-34), comprising:
adding variance to software (there is more reliance placed on testing using simulated environments… Increasing attention is being placed on the creation of simulation environments which can provide such testing in a manner that gives confidence that the test outcomes represent potential real behavior of an autonomous vehicle – See col. 3, lines 4-16. Simultaneous monitoring of two or more testing characteristics of a software program. The term “multivariate” as used herein, refers to a data element with more than one variable. For example, a data element representing pass/fail ratios over different test case groups (e.g., functionality based test case groups discussed above) for software program versions may be plotted as a multidimensional vector using a multivariate control chart – See col. 7, lines 63-67 and col. 8, lines 1-4) to cause unspecified modalities associated with changes in operation of the software and hardware that deviates from an operational design model (anomalies may be identified based on patterns in a univariate control chart such as, without limitation, one or more testing characteristic values lie outside of the LCL and/or the UCL, there exists a trend (upward and/or downward) in the testing characteristic values, a threshold number of testing characteristic values being more than a threshold distance from the mean value (i.e., large shifts from the mean), stratification, or the like. For example, for the control chart 500 including a plot 510 of failure percentages over various software versions, the points 511 and 515 lie outside of the UCL and may be considered anomalous compared to historical failure percentages – See col. 8, lines 19-30. A standard deviation may be calculated corresponding to the historical data for the testing characteristic being monitored, and used to determine the LCL and the UCL. For example, the UCL may be a sum of the mean (i.e., the arithmetic mean) and a multiple (e.g., three) of the standard deviation times a multiplier of the sample size, while the LCL may be the mean minus a multiple of the standard deviation times a multiplier of the sample size – See col. 7, lines 51-59);
executing the software with the added variance (generating a plurality of test reports for the software program by executing one or more test cases on a plurality of versions of the software program, generating a control chart based on the plurality of test reports, generating an alert when at least one testing characteristic includes an anomaly over the plurality of versions of the software program as determined based on the control chart. The control chart may include a plot associated with at least one testing characteristic of the software program, and a historical context associated with execution of the one or more test cases on the plurality of versions of the software program – See col. 12, lines 16-27);
presenting the unspecified modalities in a user interface on a display (anomalies may be identified based on patterns in a univariate control chart such as, without limitation, one or more testing characteristic values lie outside of the LCL and/or the UCL – See col. 8, lines 19-22), wherein the presenting the unspecified modalities include presenting the changes in the operation of the software and the hardware that deviates from the operational design model (identification of a large impact of changes in a new version or release on the software program quality, determination whether changes in pass/fail behavior are reasonable, determination whether changes in pass/fail behavior are anomalous, identification of occurrence of undesirable changes in a new software program version that lead to anomalous test results, management of various testing parameters and results with a changing set of test cases – see col. 3, lines 66-67 and col. 4, lines 1-8);
based on the unspecified modalities presented in the user interface on the display, identifying the unspecified modalities during runtime execution of the software (a formal specification (e.g., a simulation scenario configuration), for example conforming to a schema interpretable by a testing system 140. A test case 106 may contain test information for a test of a corresponding software program 102. For example, such information might identify a target software program 102 and/or a version level thereof, input data to be processed by the target software program 102, runtime flags of the testing system 140 or the target software program, simulated hardware or software conditions, functions or features to be tested, metadata identifying related tests – See col. 4, lines 45-55);
identifying, in the user interface on the display, distribution of the unspecified modalities associated with execution of the software in response to the adding the variance resulting in changes in operation of the software or the hardware (automatic progression monitoring and review of software testing outputs in order to detect anomalies such as outliers, unusual patterns, unusual trends, or the like. The software program or device under test may be a computer program, an integrated circuit with embedded software, computer platform, or any other system that is defined during its development phase as a computer program – See col. 2, lines 42-49);
modifying at least part of the software to eliminate the unspecified modalities (automatically diagnosing which files, revisions and configurations of such computer programs that causes specific test results for anomaly detection– See col. 2, lines 53-55); and
Mueh does not disclose
executing the modified software to determine whether the unspecified modalities have been eliminated.
Tadkase discloses
executing the modified software to determine whether the unspecified modalities have been eliminated (the dependency constraint may include eliminating scheduling branches that may violate dependency restrictions (in which the dependencies may be indicated in the scheduling parameters 417). For example, the dependency constraint may be such that descendent nodes may not be scheduled before corresponding ancestor nodes due to the dependency of the descendent nodes on the ancestor nodes – See paragraph [0217]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Tadkase’s teaching into Mueh’s invention because incorporating Tadkase’s teaching would enhance Mueh to enable eliminating one or more of the identified scheduling branches from consideration according to one or more bounding constraints as suggested by Tadkase (paragraph [0209]).
Regarding claim 2, the method of claim 1,
Tadkase discloses
wherein the identifying the distribution of the unspecified modalities associated with the software includes identifying the distribution of modalities outside of design timing constraints associated with the execution of the modified at least part of the software (the task management may include monitoring the execution of the tasks to verify that the generated schedule is being followed. For example, the monitoring may include monitoring compliance with execution timing constraints associated with tasks, compliance with execution sequence constraints associated with the tasks and/or health of at least a portion of the runtime system. In these or other embodiments, the task management may include performing one or more remedial operations based on the monitoring – See paragraph [0009]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Tadkase’s teaching into Mueh’s invention because incorporating Tadkase’s teaching would enhance Mueh to enable to include monitoring the execution of the tasks to verify that the generated schedule is being followed as suggested by Tadkase (paragraph [0009]).
Regarding claim 4, the method of claim 1,
Tadkase discloses
wherein the identifying the distribution of the unspecified modalities includes quantifying the unspecified modalities (the application data analysis 402 may include one or more of a runnable dependency analysis, critical path identification, a runnable categorization analysis, a runnable hierarchy analysis, and/or a compute engine analysis such as described at least with respect to FIGS. 3A and 3B – See paragraph [0208]), determining a timing envelope for execution of tasks of the software (monitoring compliance with execution timing constraints associated with tasks – See paragraphs [0007-0010]), and identifying the unspecified modalities at an edge of the timing envelope (validated for timing guarantees and such that the schedule may be followed (e.g., the order and the timing may be followed) on a consistent basis in multiple runs of the schedule – See paragraphs [0050-0053]).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Tadkase’s teaching into Mueh’s invention because incorporating Tadkase’s teaching would enhance Mueh to enable to monitor compliance with execution timing constraints associated with tasks as suggested by Tadkase (paragraphs [0007-0010]).
.
Regarding claim 5, the method of claim 1,
Mueh discloses
wherein the identifying the distribution of the unspecified modalities includes identifying events in a critical path and rearranging an order of execution of non-dependent tasks not in the critical path (identification of the anomaly, value of the anomaly, degree of the detected anomaly, likely cause of the detected anomaly, suggested corrective or preventative actions, or the like. The system may assign a unique identifier to the data object. The unique identifier may be random or pseudo-randomly generated. Alternatively, the unique identifier may be sequentially or otherwise assigned by the system– See col. 9, lines 44-52).
Regarding claim 6, the method of claim 1,
Muehl discloses
wherein the modifying the at least part of the software to eliminate the unspecified modalities includes modifying the at least part of the software to prevent over-designing of implemented hardware and overfitting of the software into the implemented hardware (A test case run might end with a failure code from the target software program 102 when a supporting hardware or software component fails (perhaps due to a latent bug triggered by the test case). The types of things that can cause a test run to fail are well known and extensive – See col. 5, line 7-12. Given a specific simulation scenario, the scenario can be parametrized in many different ways, e.g., by the actor attributes like speed, size, heading and potentially more complex parameters, AV parameters like the AV speed, and scene parameters like street properties and locations of different actors in the scene. Each instantiation of such a simulation scenario can be unique and defined – See col. 3, lines 48-54).
Regarding claim 7, the method of claim 1,
Mueh discloses
wherein the modifying the at least part of the software to eliminate the unspecified modalities includes optimizing execution of tasks of the software (adaptation to other systems, such as self-optimization between the different modalities of a software program – See col. 6, lines 37-38).
Regarding claim 8.
A device for providing timing-independence for software, comprising:
a memory storing computer-readable instructions; and
a processor connected to the memory, wherein the processor is configured to execute the computer-readable instructions to perform operations to:
Regarding claim 8, recites the limitations as rejected claim 1 above.
Regarding claim 9, recites the limitations as rejected claim 2 above.
Regarding claim 11, recites the limitations as rejected claim 4 above.
Regarding claim 12, recites the limitations as rejected claim 5 above.
Regarding claim 13, recites the limitations as rejected claim 6 above.
Regarding claim 14, recites the limitations as rejected claim 7 above.
Regarding claim 15.
A non-transitory computer-readable media having computer-readable instructions stored thereon, which when executed by a processor causes the processor to perform operations comprising:
Regarding claim 15, recites the limitations as rejected claim 1 above.
Regarding claim 16, recites the limitations as rejected claim 2 above.
Regarding claim 18, recites the limitations as rejected claims 4 and 5 above.
Regarding claim 19, recites the limitations as rejected claim 6 above.
Regarding claim 20, recites the limitations as rejected claim 7 above.
9. Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mueh and Tadkase as applied to claims 1, 8 and 15 respectively above, and further in view of Champagne et al. (US Pub. No. 2021/0019121 A1 – art of record --herein after Champagne).
Regarding claim 3, the method of claim 1,
Mueh discloses
wherein the adding the variance to the software includes at least one of (a runtime UI component that adds dynamic runtime behavior to the web page – See paragraph [0002):
[[adding non-determinism to the software to cause timing of execution of tasks by the software to change]]; or
adding randomization to the software, wherein the adding the randomization to the software includes at least one of adding randomization of memory allocation, oversizing allocation of memory, or replacing instructions of the software with different equivalent instructions (assign a unique identifier to the data object. The unique identifier may be random or pseudo-randomly generated – see col. 9, lines 47-50).
Mueh and Tadkase does not disclose
adding non-determinism to the software to cause timing of execution of tasks by the software to change.
Champagne discloses
adding non-determinism to the software to cause timing of execution of tasks by the software to change (the systems and methods described herein may be configured to provide a hybrid-deterministic embedded software architecture. For example, a non-deterministic software architecture may include software runs without any predictable timing (e.g., typically used in simpler electronics with simpler code, such as a computer keyboard). That is, the code simply runs, and any timing-related functionality depends on the microcontroller or processor hardware – See paragraph [0033]);
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to use Champagne’s teaching into Mueh’s and Tadkase’s invention because incorporating Champagne’s teaching would enhance Mueh and Tadkase to enable to provide a hybrid-deterministic embedded software architecture as suggested by Champagne (paragraphs [0033-0034]).
Regarding claim 10, recites the limitations as rejected claim 3 above.
Regarding claim 17, recites the limitations as rejected claim 3 above.
Conclusion
10. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Goyal et al. (US Pub. No.2024/0036835 A1 – herein after Goyal).
Goyal discloses
A method for providing timing-independence for software (providing multiple computational instances to one customer is that the customer may wish to independently develop, test, and deploy its applications and services – See paragraph [0072]. A configuration item may be a list of attributes that characterize the hardware or software that the configuration item represents. These attributes may include manufacturer, vendor, location, owner, unique identifier, description, network address, operational status, serial number, time of last update, and so on. The class of a configuration item may determine which subset of attributes are present for the configuration item (e.g., software and hardware configuration items may have different lists of attributes) – See paragraph [0091]), comprising:
adding variance to software (a runtime UI component that adds dynamic runtime behavior to the web page – See paragraph [0002]) to cause unspecified modalities associated with changes in operation of the software and hardware that deviates from an operational design model (a plurality of different UI component templates may be added to the runtime UI component, and each of these UI component templates may be associated with corresponding modifiable and non-modifiable metadata portions – See paragraphs [0005-0006]. A software module that removes discovery information from task list 502 and formulates this discovery information into configuration items (e.g., representing devices, components, applications, and/or services discovered on managed network 300) as well as relationships therebetween – See paragraph [0100]. It negatively impacts an enterprise's ability to run and grow its operations, innovate, and meet regulatory requirements – See paragraph [0026-0027]. The positioning, visual appearance, and/or behavior of static UI components 602-612 may be changed using the template-based web page editor at design time – See paragraph [0143]);
executing the software with the added variance (asks may result in proxy servers 312 reading additional information from the particular device, such as processor information, memory information, lists of running processes (software applications), and so on. Once more, the discovered information may be stored as one or more configuration items in CMDB 500 – See paragraphs [0112-0113]. Runtime UI component 614 may instead be defined at design time and executed at runtime to generate context-dependent versions of web page 600 (e.g., web page 620)… once runtime UI component metadata 616 has been defined, the same or similar behavior may be added to other instances of runtime UI component 614 in other web pages by adding runtime UI component metadata 616 to the other instances of runtime UI component 614 – See paragraph [0148]);
presenting the unspecified modalities in a user interface on a display (Determining the spatial arrangement of the context-specific UI component may involve adjusting a size of each context-specific UI component to fit the data to be displayed – See paragraph [0203]), wherein the presenting the unspecified modalities include presenting the changes in the operation of the software and the hardware that deviates from the operational design model (determine further details about the operational state of a classified device. The probes used during this phase may be based on information gathered about the particular devices during the classification phase and/or the identification phase – See paragraphs [0112-0113]. Collected information may be presented to a user in various ways to allow the user to view the hardware composition and operational status of devices – See paragraph [0116]. Adjusting a size of each parent component to fit therein the child components thereof. Depending on the area occupied by the context-specific UI components, scrolling and/or pagination may be added to the runtime UI component in order to fit the context-specific UI components within the empty portion of the web page reserved/designated by the runtime UI component – see paragraphs [0203-0205]);
based on the unspecified modalities presented in the user interface on the display, identifying the unspecified modalities during runtime execution of the software (low-code/no-code developers may be allowed to build web pages with dynamic behavior without needing to learn and/or master any programming languages and/or without running a significant risk of developing error-prone web pages – See paragraph [0167]);
identifying, in the user interface on the display, distribution of the unspecified modalities associated with execution of the software in response to the adding the variance resulting in changes in operation of the software or the hardware (discover certain types of services, as these patterns can be programmed to look for specific arrangements of hardware and software that fit a description of how the service is deployed – See paragraph [0122]. Quickly determine where certain software applications are deployed, and what configuration items make up a service. This allows for rapid pinpointing of root causes of service outages or degradation. For example, if two different services are suffering from slow response times, the CMDB can be queried (perhaps among other activities) to determine that the root cause is a database application that is used by both services having high processor utilization – See paragraph [0126]. Visual appearance, and/or behavior of static UI components 602-612 may be changed using the template-based web page editor at design time, but such properties of static UI components 602-612 might not be modifiable at runtime. Static UI components 602-612 may, for example, define a menu structure of web page 600, provide links to other web pages, display corresponding data, and/or otherwise provide at least some of the functionality of web page 600 – See paragraph [0143]);
modifying at least part of the software to eliminate the unspecified modalities (displays and allows for editing of the modifiable portions of the metadata and (ii) hides and prevents editing of non-modifiable portions of the metadata – See paragraph [0004]. The runtime UI component editor may allow the mapping to be implemented by modifying editable parts of the metadata associated with each UI component template. The runtime UI component editor may hide and/or protect non-editable parts of the metadata associated with each UI component, thus reducing and/or eliminating the possibility of generating mappings that result in runtime errors – See paragraph [0183])
Wang et al. (US Pub. No. 2024/0340302 A1) discloses involving natural language processing (NLP) based auto formal modeling of protocols and specifications with large language models (NLP) are provided. Methods for formal and fuzzing amplification for fuzz testing to detect vulnerabilities are also disclosed. Furthermore, solutions are provided to identified vulnerabilities in existing 5G infrastructures. Also disclosed is a digital twin fuzzing framework – See Abstract.
Lysecky et al. (US Patent No. 11,868479 B2) discloses safety-critical devices, specifically medical devices, using: a) runtime, adaptive methods that dynamically assess the risk of newly discovered vulnerabilities and threats, and b) automatic mitigation methods that reduce system risk by seamlessly reconfiguring the device to operate within different execution modes – See Abstract.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONGBAO NGUYEN whose telephone number is (571)270-7180. The examiner can normally be reached Monday-Friday 8am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, 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.
/MONGBAO NGUYEN/ Examiner, Art Unit 2192