CTFR 17/893,053 CTFR 88488 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 1. This Office Action is in response to the amendment filed on 02/13/2026. Claims 1-20 are pending in this application. Claims 1, 16 and 20 are independent claims. This Office Action is made Final. Allowable Subject Matter 12-151-08 AIA 07-43 12-51-08 2. Claim s 9-10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA 4. 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. 07-21-aia AIA 5. Claim s 1, 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), and further in view of Wolf (US PGPub 20190265955) . As per Claim 1, Suominen teaches of a computer-implemented method, comprising: generating multiple versions of software from a single source code; and (Par 15, “In order to provide improved detection of malware and threats, a system is proposed which makes use of behaviour profiles generated for multiple different versions of the same application in a computer system .” Par 24, “In 201 , the security application analyses evolutionary changes between the behaviours of the different versions of the same application .”) installing unique ones of the versions onto corresponding, unique hardware systems, (Par 23, “In 200 , the security application analyses the computer system 1 to monitor installation and operation of multiple different versions of the same application in a computer system .” It’s obvious to install and execute the different versions of the same application in a multiple computer systems as in Par 2 and 5 in order to isolate the issues only arising from the software versions, not different physical hardware devices as in par 15, “in order to provide improved detection of malware and threats …”) wherein when the versions are run on the [respective] hardware systems. the resulting respective executions of the versions are different. (Par 33, “In an embodiment, the behavioural data for the analysis may be generated by executing multiple different versions of the same application on physical machines during normal usage, on separate test machines or by any virtualization system.” Par 2, “ Many computer devices and computer systems [hardware systems] , such as desktop personal computers (PCs), laptops, personal data assistants (PDAs) and mobile phones can be at risk from malware.” Par 5, “There is a need for methods and systems that alleviate the foregoing problems and enable detecting malicious modifications in software applications before these applications cause harm to computer systems.”) Suominen does not specifically teach, however Uy teaches of installing … on the hardware systems being redundant relative to one another , and when the versions are run on the respective hardware systems (Par 4, “In addition, the device manufacturers must provide each of the different cellular carriers with different versions of the same device to meet the requirements of each cellular carrier.” Par 5, “Hence, although to the public, the devices may appear or be marketed as the same model, from the perspectives of the manufacturer and the carriers, the devices actually may be several models or versions that are similar but differ as to the software loads . Thus, the sets of features and/or applications installed or activated on the different carrier's version(s) of the mobile device require the manufacture of different versions of the same mobile device model. Accordingly, there is a need to minimize the number of different mobile device versions of the same mobile device model that need to be generated to meet the requirements of the different carriers.”) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the hardware systems being redundant relative to one another, as conceptually seen from the teaching of Uy, into that of Suominen because this modification can help test the different versions of the same software on the identical devices in order to measure and analyze the effects of different versions of the software on the particular hardware device. Neither Suominen nor Uy specifically teaches, however Wolf teaches binary and/or execution profiles of the respective versions are made different by implementing random processes and/ or different compilation parameters … the resulting respective executions of the versions are different (Par 62, In some embodiments of the present invention, two of the sets of sequences are object codes . Preferably, the two object codes are generated by different compilation processes applied to the same programming language source code . The different compilation processes may be executed by different compiler software or by the same compiler software but using different compilation parameters , and/or using different target architectures. These embodiments are particularly useful when the method is executed to assess the accuracy of one compilation process in comparison to another compilation process.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add binary and/or execution profiles of the respective versions are made different by implementing random processes and/or different compilation parameters … the resulting respective executions of the versions are different, as conceptually seen from the teaching of Wolf, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to measure and analyze the effects of different versions of the software on the particular hardware device. As per Claim 8, Suominen does not specifically teach, however Uy teaches of the computer-implemented method of claim 1, wherein the hardware systems have identical hardware configurations. (Par 4-5, Thus, the sets of features and/or applications installed or activated on the different carrier's version(s) of the mobile device require the manufacture of different versions of the same mobile device model. Accordingly, there is a need to minimize the number of different mobile device versions of the same mobile device model that need to be generated to meet the requirements of the different carriers.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the hardware systems have identical hardware configurations, as conceptually seen from the teaching of Uy, into that of Suominen because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device. Re Claim 20, it is the system claim, having similar limitations of claim 1. Thus, claim 20 is also rejected under the similar rationale as cited in the rejection of claim 1. 6 . Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), and further in view of Costa (US PGPub 20180211067). As per Claim 2, neither Suominen nor Uy specifically teaches, however Costa teaches of the computer-implemented method of claim 1, wherein the versions have different executable binary images relative to one another. (Abstract, An abstract identity value may be used to determine equivalence of two enclave instantiations that are not identical, such as two similar enclaves hosted on different computers, two enclaves hosted on different native enclave platforms, and two enclaves instantiated from different versions of the same enclave binary images. Par 31, For example, different versions of the same enclave, such as the versions of enclave binaries before and after a bug is fixed, may be given the same name, independent of version.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the versions have different executable binary images relative to one another, as conceptually seen from the teaching of Costa, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device. Re Claim 17, it is the product claim, having similar limitations of claim 2. Thus, claim 17 is also rejected under the similar rationale as cited in the rejection of claim 2 . 07-21-aia AIA 7. Claim s 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), in view of Costa (US PGPub 20180211067), and further in view of Dewitt (US PGPub 20190079855) . As per Claim 3, none of Suominen, Uy and Costa specifically teaches, however Dewitt teaches of the computer-implemented method of claim 2, wherein generating the multiple versions of software from the same source code includes using differing compiler settings for compiling respective versions of software. (Par 57, In response to detecting an update, an adjustment module 206 may automatically and/or dynamically generate one or more builds for hardware devices 102 using the updated computer executable code such that various features of the updated computer executable code are executable on a hardware device 102. For example, an adjustment module 206 may compile or otherwise build different versions of the updated computer executable code (e.g., using different compilers, different compiler flags or settings, different compiler targets, or the like) for different devices 102 (e.g., different makes and/or models), devices 102 with different operating systems and/or operating system versions, or the like.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add using differing compiler settings for compiling respective versions of software, as conceptually seen from the teaching of Dewitt, into that of Suominen, Uy and Costa because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device. As per Claim 4, none of Suominen, Uy and Costa specifically teaches, however Dewitt teaches of the computer-implemented method of claim 2, wherein generating the multiple versions of software from the same source code includes using different compilers for compiling different versions of software. (Par 57, In response to detecting an update, an adjustment module 206 may automatically and/or dynamically generate one or more builds for hardware devices 102 using the updated computer executable code such that various features of the updated computer executable code are executable on a hardware device 102. For example, an adjustment module 206 may compile or otherwise build different versions of the updated computer executable code (e.g., using different compilers, different compiler flags or settings, different compiler targets, or the like) for different devices 102 (e.g., different makes and/or models), devices 102 with different operating systems and/or operating system versions, or the like.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add generating the multiple versions of software from the same source code includes using different compilers for compiling different versions of software, as conceptually seen from the teaching of Dewitt, into that of Suominen, Uy and Costa because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 8. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), and further in view of Suryanarayana (US PGPub 20230146526) . As per Claim 5, neither Suominen nor Uy specifically teaches, however Suryanarayana teaches of the computer-implemented method of claim 1, wherein the versions are identical, wherein the running is performed such that the versions have different execution profiles relative to one another. (Par 11, Use of container-specific firmware settings may allow for different versions of a firmware to be executed by different concurrently executed containers. In some embodiments, a firmware version may be rolled back for a first container while maintaining execution of a current firmware version for a second container.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add that the running is performed such that the versions have different execution profiles relative to one another, as conceptually seen from the teaching of Suryanarayana, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 9. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), in view of Suryanarayana (US PGPub 20230146526), and further in view of Dewitt (US PGPub 20190079855) . As per Claim 6, none of Suominen, Uy and Suryanarayana specifically teaches, however Dewitt teaches of the computer-implemented method of claim 5, wherein at least two of the hardware systems use different types of operating systems relative to one another to run the version associated therewith. (Par 57, In response to detecting an update, an adjustment module 206 may automatically and/or dynamically generate one or more builds for hardware devices 102 using the updated computer executable code such that various features of the updated computer executable code are executable on a hardware device 102. For example, an adjustment module 206 may compile or otherwise build different versions of the updated computer executable code (e.g., using different compilers, different compiler flags or settings, different compiler targets, or the like) for different devices 102 (e.g., different makes and/or models), devices 102 with different operating systems and/or operating system versions, or the like.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add at least two of the hardware systems use different types of operating systems relative to one another to run the version associated therewith r, as conceptually seen from the teaching of Dewitt, into that of Suominen, Uy and Suryanarayana because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 10. Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), and further in view of Dewitt (US 20190079855) . As per Claim 7, neither Suominen nor Uy specifically teaches, however Dewitt teaches of the computer-implemented method of claim 1, wherein at least two of the hardware systems use different types of operating systems relative to one another to run the version associated therewith. (Par 57, In response to detecting an update, an adjustment module 206 may automatically and/or dynamically generate one or more builds for hardware devices 102 using the updated computer executable code such that various features of the updated computer executable code are executable on a hardware device 102. For example, an adjustment module 206 may compile or otherwise build different versions of the updated computer executable code (e.g., using different compilers, different compiler flags or settings, different compiler targets, or the like) for different devices 102 (e.g., different makes and/or models), devices 102 with different operating systems and/or operating system versions , or the like.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add at least two of the hardware systems use different types of operating systems relative to one another to run the version associated therewith., as conceptually seen from the teaching of Dewitt, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 11. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), and further in view of Fukuoka (US Patent 4802164) . As per Claim 11, none of Suominen, Uy and Wolf specifically teaches, however Fukuoka teaches of the computer-implemented method of claim 1, comprising input/output scheduler randomization whereby orders of I/O tasks in I/O queues of the hardware systems are randomly changed in the respective hardware systems. (Col 1, lines 52-68, In order to achieve this object, according to one feature of the present invention, an input/output control table provided for each of the input/output devices to store status control information for the input/output devices, has lock control flags indicating whether the input/output control table is locked by the processor accessing the relevant input/output device or not and lock addresses indicating the address of the locked processor and a scheduler controlling the order of starting the input/output devices has a priority processing function of selecting and determining a processor accessing an input/output device at random for every start of an input/output device based on the lock control flags and/or the lock addresses, the flags indicating the status of the respective input/output device, as set in the control table. Col 7, lines 39-50, it is possible to construct a scheduler which makes it possible to determine one of a plurality of input/output devices connected to a multi-processor system at random each time an input/output starting instruction is executed, depending on the processor accessing them. Further, in the embodiments described above of the present invention a plurality of input/output devices can be put in their operation state at the same time so that they can execute different jobs at the same time. In this way, an input/output device multi-operation test such as) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add input/output scheduler randomization whereby orders of I/O tasks in I/O queues of the hardware systems are randomly changed in the respective hardware systems, as conceptually seen from the teaching of Fukuoka, into that of Suominen, Uy and Wolf because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 12. Claim s 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), and further in view of Cush (US PGPub 20030145083) . As per Claim 12, neither Suominen nor Uy specifically teaches, however Cush teaches of the computer-implemented method of claim 1. comprising detecting a software failure in a first of the hardware systems during runtime, and causing a second of the hardware systems to behave differently for reducing an impact of a same software error on the second hardware system. (Par 18, Referring now to the drawings, FIG. 1 shows a system 10 for Collecting, Diagnosing and Reporting (CDR) information about an information technology network or environment according to a preferred embodiment of the present invention. The CDR or diagnosing system 10 assists in identifying and mitigating problems related to software, hardware, application, or device configuration issues that cause downtime. The illustrated CDR system 10 includes components at a user or customer site and components at a solution provider site 14 which is remote from the customer site 12. While the illustrated CDR system 10 includes a single customer site 12, it is noted that a plurality of customer sites 12 can be utilized within the scope of the present invention. Par 167, By doing a server compare, for example, a customer is able to quickly identify that the permissions of the backup services were changed to a user with the incorrect credentials causing the application to fail. In automated diagnosis mode, information is automatically sent to the customer (no human intervention) to help mitigate issues before they arise. The automated diagnosis can be proactive by highlighting best practices on the system such as application and device configuration and event settings.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add detecting a software failure in a first of the hardware systems during runtime, and causing a second of the hardware systems to behave differently for reducing an impact of a same software error on the second hardware system, as conceptually seen from the teaching of Cush, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device. As per Claim 13, neither Suominen nor Uy specifically teaches, however Cush teaches of the computer-implemented method of claim 12, wherein the different behavior includes reacting to the software failure in a different manner. (Par 166, The view/compare view of the portal interface preferably lists all servers 30 that are currently being monitored by the CDR collection system 10. In a single screen, the user preferably has the capability to do the following: click on a snapshot time and see the detailed configurations and logs; view the most current snapshot in one click; compare two distinct snapshots for a particular server to see how things have changed on that server 30; one-click compare the last two snapshots or the last snapshot to the "gold image" or "master" snapshot; and compare to different systems by selecting two distinct systems. Par 167, The diagnosing step can take at least for different forms: identify mode; on-demand diagnosis mode; automated diagnosis mode; and learning mode. In the identify mode, the user can identify, from the portal interface, system, hardware, software, application and/or device changes that affect availability, performance and usability.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add reacting to the software failure in a different manner, as conceptually seen from the teaching of Cush, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 13. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), in view of Cush (US PGPub 20030145083), and further in view of Shiraishi (US PGPub 20170142156) . As per Claim 14, none of Suominen, Uy and Cush specifically teaches, however Shiraishi teaches of the computer-implemented method of claim 12. wherein the different behavior includes modifying execution of the version running in the second hardware system in an attempt to avoid the software failure in the second hardware system. (Par 57, (1) using one or more runtime hooks in a virtual machine of the open platform in-vehicle infotainment system 184 to prevent malicious code included in the untrusted application 191 from executing; (2) using one or more runtime hooks in the virtual machine of the open platform in-vehicle infotainment system 184 to modify the execution of the malicious code included in the untrusted application 191 so that the execution is determined to be safe by the application assurance system 199; (3) identifying and disabling the execution of one or more specific software components or permissions included in the malicious code of the untrusted application 191 which are determined to be undesirable; (4) determining the presence of a security issue related to data access and provide random false data to the untrusted application 191 so that the security issue is reduced, minimized or eliminated; (5)) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add modifying execution of the version running in the second hardware system in an attempt to avoid the software failure in the second hardware system, as conceptually seen from the teaching of Shiraishi, into that of Suominen, Uy and Cush because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 14. Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), in view of Wolf (US PGPub 20190265955), and further in view of Jacob (US Patent 8756461) . As per Claim 15, neither Suominen nor Uy specifically teaches, however Jacob teaches of the computer-implemented method of claim 1, comprising detecting a repeated software failure in a primary one of the hardware systems when the primary hardware system performs a particular task; determining that a secondary one of the hardware systems does not experience the same failure when performing the task: and using the secondary hardware system as the primary provider of the task. (Col 5, lines 48-Col 6, line 2, As further shown in the example of FIG. 1, routing component 12 includes a primary control unit 20 and a standby control unit 22, where standby control unit 22 is typically utilized to provide routing or control plane functionality only when primary control unit 20 fails. In this configuration, standby control unit 22 may represent a redundant control unit for use in instances of primary control unit 20 failure. Typically, routing component 12, upon detecting a failure of primary control unit 20 that would prevent primary control unit 20 from properly performing its control plane functionality, seamlessly (from the perspective of forwarding component 14 and other routers in the network) transfers control from primary control unit 20 to standby control unit 22, whereupon transferring control standby control unit 22 becomes the primary control unit and primary control unit 20 becomes the standby control unit . Routers that feature redundant control units capable of assuming control in the event of failure of the primary control unit are referred to as "high-availability routers" as these routers may be more resilient to error and, as a result, may provide more availability than other routers that do not feature redundant control units . Router 10 may therefore be referred to as a high-availability router 10.) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add detecting a repeated software failure in a primary one of the hardware systems when the primary hardware system performs a particular task; determining that a secondary one of the hardware systems does not experience the same failure when performing the task: and using the secondary hardware system as the primary provider of the task, as conceptually seen from the teaching of Jacob, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device . 07-21-aia AIA 15. Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975) . As per Claim 16, Suominen teaches of a computer program product, the computer program product comprising: one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media, the program instructions comprising: program instructions to generate multiple versions of software from a single source code; (Par 15, “In order to provide improved detection of malware and threats, a system is proposed which makes use of behaviour profiles generated for multiple different versions of the same application in a computer system .” Par 24, “In 201 , the security application analyses evolutionary changes between the behaviours of the different versions of the same application .”) program instructions to install unique ones of the versions onto corresponding, unique hardware systems, (Par 23, “In 200 , the security application analyses the computer system 1 to monitor installation and operation of multiple different versions of the same application in a computer system .” It’s obvious to install and execute the different versions of the same application in a multiple computer systems as in Par 2 and 5 in order to isolate the issues only arising from the software versions, not different physical hardware devices as in par 15, “in order to provide improved detection of malware and threats …”) wherein when the versions are run on the [respective] hardware systems. the resulting respective executions of the versions are different. (Par 33, “In an embodiment, the behavioural data for the analysis may be generated by executing multiple different versions of the same application on physical machines during normal usage, on separate test machines or by any virtualization system.” Par 2, “ Many computer devices and computer systems [hardware systems] , such as desktop personal computers (PCs), laptops, personal data assistants (PDAs) and mobile phones can be at risk from malware.” Par 5, “There is a need for methods and systems that alleviate the foregoing problems and enable detecting malicious modifications in software applications before these applications cause harm to computer systems.”) Suominen does not specifically teach, however Uy teaches of installing … on the hardware systems being redundant relative to one another , and when the versions are run on the respective hardware systems (Par 4, “In addition, the device manufacturers must provide each of the different cellular carriers with different versions of the same device to meet the requirements of each cellular carrier.” Par 5, “Hence, although to the public, the devices may appear or be marketed as the same model, from the perspectives of the manufacturer and the carriers, the devices actually may be several models or versions that are similar but differ as to the software loads . Thus, the sets of features and/or applications installed or activated on the different carrier's version(s) of the mobile device require the manufacture of different versions of the same mobile device model. Accordingly, there is a need to minimize the number of different mobile device versions of the same mobile device model that need to be generated to meet the requirements of the different carriers.”) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the hardware systems being redundant relative to one another, as conceptually seen from the teaching of Uy, into that of Suominen because this modification can help test the different versions of the same software on the identical devices in order to measure and analyze the effects of different versions of the software on the particular hardware device . 07-21-aia AIA 16. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975) and further in view of Costa (US PGPub 20180211067) . Re Claim 17, it is the product claim, having similar limitations of claim 2. Thus, claim 17 is also rejected under the similar rationale as cited in the rejection of claim 2 . 07-21-aia AIA 17. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), and further in view of Suryanarayana (US PGPub 20230146526) . Re Claim 18, it is the product claim, having similar limitations of claim 5. Thus, claim 18 is also rejected under the similar rationale as cited in the rejection of claim 5 . 07-21-aia AIA 18. Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Suominen (US PGPub 20190294795), in view of Uy (US PGPub 20160049975), and further in view of Fukuoka (US Patent 4802164) . As per Claim 19, neither Suominen nor Uy specifically teaches, however Fukuoka teaches of the computer program product of claim 18, comprising implementing a procedure selected from the group consisting of : address space layout randomization, operating system scheduler randomization, and input/output scheduler randomization . (Col 1, lines 52-68, In order to achieve this object, according to one feature of the present invention, an input/output control table provided for each of the input/output devices to store status control information for the input/output devices, has lock control flags indicating whether the input/output control table is locked by the processor accessing the relevant input/output device or not and lock addresses indicating the address of the locked processor and a scheduler controlling the order of starting the input/output devices has a priority processing function of selecting and determining a processor accessing an input/output device at random for every start of an input/output device based on the lock control flags and/or the lock addresses, the flags indicating the status of the respective input/output device, as set in the control table. Col 7, lines 39-50, it is possible to construct a scheduler which makes it possible to determine one of a plurality of input/output devices connected to a multi-processor system at random each time an input/output starting instruction is executed, depending on the processor accessing them . Further, in the embodiments described above of the present invention a plurality of input/output devices can be put in their operation state at the same time so that they can execute different jobs at the same time. In this way, an input/output device multi-operation test such as) Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add implementing a procedure selected from the group consisting of: address space layout randomization, operating system scheduler randomization, and input/output scheduler randomization, as conceptually seen from the teaching of Fukuoka, into that of Suominen and Uy because this modification can help test the different versions of the same software on the identical devices in order to ensure the consistency of the different versions, detecting any bugs in those versions and validating the improvement of the different versions of the software on the particular hardware device. Response to Arguments 19. Applicant's arguments with respect to the claims 1, 16 and 20 and their dependent claims have been fully considered but they are not persuasive. Regarding the first argument that Suominen does not teach the different versions of software created from a single source code, the examiner would like to point out that Suominen teaches in par 15, In order to provide improved detection of malware and threats, a system is proposed which makes use of behaviour profiles generated for multiple different versions of the same application in a computer system. For example malicious modifications done to software before its release (i.e. any time during the development and build process) may be detected by comparing behavioural data of multiple different versions of the same software to deduce what changes in the behaviour are likely to be part of normal evolutionary progress and which changes have been caused by abnormal, malicious or suspicious modifications. Par 23, In 200 , the security application analyses the computer system 1 to monitor installation and operation of multiple different versions of the same application in a computer system. Par 24, In 201 , the security application analyses evolutionary changes between the behaviours of the different versions of the same application. Thus, the examiner maintains that Suominen teach the different versions of software created from a single source code. Regarding another argument that modification of Suominen would render Suominen unsatisfactory for its intended purpose, the examiner would like to point out that Suominen is inherent or obvious (or silent) about the target device for installing the different software for testing being redundant or similar in terms of their hardware configurations where Uy specifically teaches of installing … on the hardware systems being redundant relative to one another. Thus, the examiner maintains that the Uy’s teaching of installing on the hardware systems being redundant relative to one another would provide the advantage/benefit of testing different versions of the single source code application on the same hardware devices in order to minimize any other hardware differences. 20. Applicant’s arguments with respect to claims 1, 16 and 20 and their dependent claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Conclusion 07-40 AIA 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 JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 9am-6pm. 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, Chat Do can be reached at 571-272-3721. 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. /JAE U JEON/Primary Examiner, Art Unit 2193 Application/Control Number: 17/893,053 Page 2 Art Unit: 2193 Application/Control Number: 17/893,053 Page 3 Art Unit: 2193 Application/Control Number: 17/893,053 Page 4 Art Unit: 2193 Application/Control Number: 17/893,053 Page 5 Art Unit: 2193 Application/Control Number: 17/893,053 Page 6 Art Unit: 2193 Application/Control Number: 17/893,053 Page 7 Art Unit: 2193 Application/Control Number: 17/893,053 Page 8 Art Unit: 2193 Application/Control Number: 17/893,053 Page 9 Art Unit: 2193 Application/Control Number: 17/893,053 Page 10 Art Unit: 2193 Application/Control Number: 17/893,053 Page 11 Art Unit: 2193 Application/Control Number: 17/893,053 Page 12 Art Unit: 2193 Application/Control Number: 17/893,053 Page 13 Art Unit: 2193 Application/Control Number: 17/893,053 Page 14 Art Unit: 2193 Application/Control Number: 17/893,053 Page 15 Art Unit: 2193 Application/Control Number: 17/893,053 Page 16 Art Unit: 2193 Application/Control Number: 17/893,053 Page 17 Art Unit: 2193 Application/Control Number: 17/893,053 Page 18 Art Unit: 2193
Prosecution Insights