Prosecution Insights
Last updated: October 23, 2026
Application No. 18/916,247

MINIMAL IMPACT SOFTWARE UPDATE DEPLOYMENT

Non-Final OA §101§103
Filed
Oct 15, 2024
Examiner
THOMSON, LUKE EDWARD
Art Unit
2193
Tech Center
2100 — Computer Architecture & Software
Assignee
Robert Bosch GmbH
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
6 currently pending
Career history
5
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§101 §103
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 This office action is in response to the application filed on Oct 15, 2024. Claims 1-27 are pending in this application. Claims 1, 14 and 27 are independent claims. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more. Regarding claim 1, the limitations: applying the placeholder code area update to the placeholder code area, the placeholder code area being a pre-allocated portion of a code segment of the software application outside of a code path that is reserved at compile time for future use and applying the placeholder instruction update to the placeholder instruction, the placeholder instruction being an instruction in the code path that is predefined in the software application as built, to be modified and/or replaced with another instructions to call a section of code that is outside of the code path encompass acts of observation, evaluation, judgment, and/or selection that can be practically performed in the human mind, including with the aid of pen and paper. Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas under Step 2A, Prong One. Under Prong 2, this judicial exception is not integrated into a practical application. The additional element of a method for deploying a software update to an electronic control unit (ECU) generally links the use of judicial exception to a particular technological environment or field of use. See MPEP 2106.05(h). The additional elements: receiving a software update to update existing portions of a software application, the software update indicating a placeholder instruction update to a placeholder instruction of the software application and a placeholder code area update to a placeholder code area of the software application and executing the software application as modified, to apply the software update constitute insignificant extra-solution activity, with receiving the software update being preliminary data-gathering activity and executing the modified application being post-solution activity. See MPEP2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a method for deploying a software update to an electronic control unit (ECU) generally links the use of judicial exception to a particular technological environment or field of use. As for the additional elements: receiving a software update to update existing portions of a software application, the software update indicating a placeholder instruction update to a placeholder instruction of the software application and a placeholder code area update to a placeholder code area of the software application and executing the software application as modified, to apply the software update are recited at a high-level of generality such that they amount to no more than adding insignificant extra solution activity to the judicial exception, thus, do they do not amount to significantly more, or provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding claims 2, 3 and 4, the limitations: (2) the placeholder instruction update indicates a location of the placeholder instruction to update and the instructions to replace the placeholder instruction with, (3) the placeholder code area update indicates which placeholder code area to update and the instructions to add to the placeholder code area and (4) the placeholder code area update indicates that the placeholder code area is preloaded with instructions and does not require an update recite additional mental process under Prong 1. Regarding claims 5, 6 and 7, the limitations: (5) the placeholder code area update includes a remote procedure call to a remote computing device that to be called as part of the code path as updated, (6) the placeholder instruction includes a delay loop that is replaced by the software update to preserve timing after addition of the placeholder code area update and (7) the timing of the delay loop is randomized across the ECU and other ECUs executing the software application recite mere instructions to implement an abstract idea or other exception on a computer. The “remote procedure call” and “delay loop” limitations merely specify computer functionality used to implement the recited software modification and therefore amount to using a computer or computer functionality as a tool to perform or apply the judicial exception. See MPEP §2106.05(f). The recitation in claim 7 of the ECU and other ECUs executing the software application additionally links implementation of the judicial exception to a particular technological environment. See MPEP §2106.05(h). These limitations, individually and in combination with the other additional elements, do not integrate the judicial exception into a practical application under Step 2A, Prong Two, or amount to significantly more under Step 2B. Regarding claims 8, 9 and 10, the limitations: (8) the software update implements a reduced alternative to update the existing portions of the software application, the reduced alternative eliminating a feature or returning with an error to remove a function of the software application, (9) the software update implements a stricter alternative to update the existing portions of the software application, the stricter alternative enhancing an existing security check or adding a new security check to increase security of a function of the software application and (10) the software update implements a diverse alternative to update the existing portions of the software application, the diverse alternative including an alternative version of a function of the software application that is functionally equivalent but constructed differently merely specifies the computer implementation of the judicial exception and amounts to using computer functionality as a tool to perform or apply the abstract idea. See MPEP §2106.05(f). The limitation, alone or in combination with the other additional elements, neither integrates the exception into a practical application under Step 2A, Prong Two, nor amounts to significantly more under Step 2B. Regarding claim 11, the limitation: wherein the placeholder instructions are located at the entry and/or exit points of basic blocks of instructions of the software application, wherein the basic blocks of instructions are connected by edges that are changes in control flow of the instructions. Does nothing more than add insignificant extra solution activity to the judicial exception of limiting the location the mental process can be performed. See MPEP2106.05(g). None of the additional elements taken alone or in combination either amount to a practical application under Step 2A, Prong Two, nor amount significantly more under Step 2B. Regarding claims 12 & 13, the limitations: (12) wherein the placeholder instructions are located to produce a pattern unique to the software application for identifying the software application and (13) wherein the placeholder instructions are chosen to include a power consumption pattern unique to the software application for identifying the software application. Selecting instructions according to a desired pattern and identifying the software based on that pattern are acts of evaluation, selection, and identification that can be practically performed in the human mind, including with the aid of pen and paper, and therefore fall within the Mental Processes grouping of abstract ideas. The remaining additional elements are analyzed as set forth above with respect to claim 1 and do not integrate the exception into a practical application or amount to significantly more. Regarding claim 14, the limitations: apply the placeholder code area update to the placeholder code area, the placeholder code area being a pre-allocated portion of a code segment of the software application outside of a code path that is reserved at compile time for future use; and apply the placeholder instruction update to the placeholder instruction, the placeholder instruction being an instruction in the code path that is predefined in the software application as built, to be modified and/or replaced with another instructions to call a section of code that is outside of the code path; encompass acts of observation, evaluation, judgment, and/or selection that can be practically performed in the human mind, including with the aid of pen and paper. Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas under Step 2A, Prong One. Under Prong 2, this judicial exception is not integrated into a practical application. The additional element of a system for deploying a software update to an electronic control unit (ECU), comprising: an ECU having a memory and a processor generally links the use of judicial exception to a particular technological environment or field of use. See MPEP 2106.05(h). The additional elements: receive a software update to update existing portions of a software application, the software update indicating a placeholder instruction update to a placeholder instruction of the software application and a placeholder code area update to a placeholder code area of the software application and execute the software application as modified using the processor, to apply the software update constitute insignificant extra-solution activity, with receiving the software update being preliminary data-gathering activity and executing the modified application being post-solution activity. See MPEP2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a system for deploying a software update to an electronic control unit (ECU), comprising: an ECU having a memory and a processor generally links the use of judicial exception to a particular technological environment or field of use. As for the additional elements: receive a software update to update existing portions of a software application, the software update indicating a placeholder instruction update to a placeholder instruction of the software application and a placeholder code area update to a placeholder code area of the software application and execute the software application as modified using the processor, to apply the software update are recited at a high-level of generality such that they amount to no more than adding insignificant extra solution activity to the judicial exception, thus, do they do not amount to significantly more, or provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101. Regarding claims 15-26, these claims recite limitations corresponding respectively to claims 2-13. For the corresponding limitations, see the analyses of claims 2-13 above. The recitation of the limitations in the context of an ECU having a processor and memory does not alter the eligibility analysis, as the processor, memory, and ECU merely provide computer implementation and a technological environment in which the recited judicial exceptions are performed. See MPEP §§ 2106.05(f) and 2106.05(h). Thus, claims 15-26 do not integrate the judicial exception into a practical application under Step 2A, Prong Two, and do not recite significantly more under Step 2B. Regarding claim 27, the limitations: apply the placeholder code area update to the placeholder code area, the placeholder code area being a pre-allocated portion of a code segment of the software application outside of a code path that is reserved at compile time for future use; and apply the placeholder instruction update to the placeholder instruction, the placeholder instruction being an instruction in the code path that is predefined in the software application as built, to be modified and/or replaced with another instructions to call a section of code that is outside of the code path; encompass acts of observation, evaluation, judgment, and/or selection that can be practically performed in the human mind, including with the aid of pen and paper. Thus, these limitations fall within the “Mental Processes” grouping of abstract ideas under Step 2A, Prong One. Under Prong 2, this judicial exception is not integrated into a practical application. The additional element of a non-transitory computer-readable medium comprising instructions that, when executed by an ECU having a processor and a memory, cause the ECU to perform operations generally links the use of judicial exception to a particular technological environment or field of use. See MPEP 2106.05(h). The additional elements: receive a software update to update existing portions of a software application, the software update indicating a placeholder instruction update to a placeholder instruction of the software application and a placeholder code area update to a placeholder code area of the software application and execute the software application as modified using the processor, to apply the software update constitute insignificant extra-solution activity, with receiving the software update being preliminary data-gathering activity and executing the modified application being post-solution activity. See MPEP2106.05(g). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a non-transitory computer-readable medium comprising instructions that, when executed by an ECU having a processor and a memory, cause the ECU to perform operations generally links the use of judicial exception to a particular technological environment or field of use. As for the additional elements: receive a software update to update existing portions of a software application, the software update indicating a placeholder instruction update to a placeholder instruction of the software application and a placeholder code area update to a placeholder code area of the software application and execute the software application as modified using the processor, to apply the software update are recited at a high-level of generality such that they amount to no more than adding insignificant extra solution activity to the judicial exception, thus, do they do not amount to significantly more, or provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101. Claim Rejections - 35 USC § 103 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. 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. Claims 1-3, 14-16 & 27 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1). Regarding claim 1, Ren teaches: (1) receiving a software update to update existing portions of a software application, (¶0002 "The present invention is related to digital electronics products with embedded software operating systems, and more particularly related to a system and method of updating, correcting, modifying or upgrading the embedded software in such digital products before or after the products have been released to market by use of software patches.") Modifying software after release corresponds to updating existing portions of a software application. (2) the software update indicating a placeholder instruction update to a placeholder instruction of the software application and (3) and a placeholder code area update to a placeholder code area of the software application; (Claim 41 “The method of claim 34, further comprising: e) generating a software patch, adapted to provide a predetermined function; f) transmitting said software patch to said digital product through a communications link; g) receiving said software patch by said digital product; h) writing said software patch into at least one of said patch operation areas.” Claim 42 “The method of claim 37, wherein said step of writing comprises the step of using said software patch to change at least one jump offset.”) Changing a jump offset in response to patching the software corresponds to the update indicating a placeholder instruction update. Applying the patch to a patch operation area corresponds to the software update indicating a placeholder code area. (4) applying the placeholder code area update to the placeholder code area, (¶0076 "In the following, an example is shown of allocating/reserving the Patch-Operation-Areas into assembler program. ... Based on this feature, we can declare certain data areas in software program and use the data area especially for software patch operation. When FLASH memory is used in digital products to contain software program, certain data areas can also be declared as being filled with “0XFF” hexadecimal numbers. As such, later on, patching process can easily change these “0xFF” hexadecimal numbers into patch program codes, such as the program codes of the Patch-Correction-Routines, the program codes of the Patch-Control-Routines, or the program codes for updating a software section or fixing an error.") Replacing the patch operation area that was previously filled with “0xFF” with the new patch code corresponds to applying the placeholder code area update. (5) the placeholder code area being a pre-allocated portion of a code segment of the software application outside of a code path that is reserved at compile time for future use; (¶0073 "A Patch-Operation-Area is allocated or reserved at some or most, if not every, location of L1, L2 … Ln. Some Patch-Operation-Areas can also be inserted or reserved at the end of the embedded software, or at a location of memory area outside of the embedded software code area." ¶0099 "In the Compilation-Method-2, after transforming the program code written in C/C++/Java language into assembler code using software compiler tools (may with optimization process), the Update-Processing-Routines, the Patch-Control-Routines, and the Patch-Operation-Area can be inserted into the assembler code.") Reserving memory areas for the software patch through compiler tools at a location outside of the code area corresponds to the pre-allocated portion of a code segment that is reserved at compile time outside of the code path. (6) applying the placeholder instruction update to the placeholder instruction, (7) the placeholder instruction being an instruction in the code path that is predefined in the software application as built, to be modified and/or replaced with another instructions to call a section of code that is outside of the code path; (¶0070 "After a patch for updating this section is received, the patch program is written into patch program area. The “B” instruction offset will be changed from “0xFFFFFF”, corresponding to jumping to Label_O, to an offset value corresponding to jumping to the start address of patch program") Updating a branch instruction to point to the new code section upon receiving the patch, the instruction having been previously defined to point to the original code section corresponds to applying the placeholder instruction update to a predefined instruction that is to be modified. (8) and executing the software application as modified, to apply the software update. (¶0090 "After a digital product successfully programs a received patch, it will start to use the instead of executing the corresponding original code in the software section.") The digital product using the new patch code corresponds with the modified software application applying the update. Ren fails to disclose: A method for deploying a software update to an electronic control unit (ECU), comprising: However, Fox teaches: A method for deploying a software update to an electronic control unit (ECU), comprising: (¶0027 "a method may be implemented for performing updates to ECU software while an ECU of a vehicle is operating. The method may comprise: receiving, at the vehicle while the ECU of the vehicle is operating, a software update file for the ECU software; writing, while the ECU is operating, the software update file into a first memory location in a memory of the ECU while simultaneously executing a code segment of existing code in a second memory location in the memory of the ECU; and updating a plurality of memory addresses associated with the memory of the ECU based on the software update file and without interrupting the execution of the code segment currently being executed in the second memory location in the memory of the ECU.") Writing a software update file into the memory of an ECU corresponds to deploying a software update to an electronic control unit. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “A method for deploying a software update to an electronic control unit (ECU), comprising”. By implementing the embedded software update technique of Ren in an electronic control unit as taught by Fox to permit portions of existing ECU software to be updated using patch code rather than replacement of the complete software application, thereby reducing memory and network resources required to deploy the update (Ren 0012-0013). Regarding claim 2, Ren further teaches: The method of claim 1, wherein the placeholder instruction update indicates a location of the placeholder instruction to update and the instructions to replace the placeholder instruction with. (¶0136-0153 “The patch data 940 may include some of the following items, such as: … Software Section Identifiers of the software sections that are updated by this patch;” ¶0070 “After a patch for updating this section is received, the patch program is written into patch program area. The “B” instruction offset will be changed from “0xFFFFFF”, corresponding to jumping to Label_O, to an offset value corresponding to jumping to the start address of patch program.”) The patch data including a software section identifier identifying the software section to be updated, wherein the section has a predefined “B” instruction that is modified upon receiving the patch corresponds to the placeholder instruction update indicating a location of the placeholder instruction to update and the instructions to replace the placeholder instruction with. Regarding claim 3, Ren further teaches: The method of claim 1, wherein the placeholder code area update indicates which placeholder code area to update and the instructions to add to the placeholder code area. (¶0136-0153 "The patch data 940 may include some of the following items, such as: ... Address information of patch data, which may be memory addresses, sector allocation information or other types of address information of FLASH/NVM/EEROM memory in digital product; Patch program codes that can be used for software updating; ... Software Section Identifiers of the software sections that are updated by this patch;") The patch data including the address information of the patch data and the patch program codes correspond to placeholder code area update indicating which placeholder code area to update and the instructions to add to the placeholder code area. Regarding claim 14, for the limitations corresponding to claim 1, see the rejection of claim 1 above. Fox further teaches an ECU comprising a processor and memory configured to perform the recited software-update operations (Fox 0010). Claim 15 is rejected for the same reasons as claim 2, as it merely recites the system steps corresponding to the method of claim 2. Claim 16 is rejected for the same reasons as claim 3, as it merely recites the system steps corresponding to the method of claim 3. Regarding claim 27, for the limitations corresponding to claim 1, see the rejection of claim 1 above. Fox further teaches a non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause performance of the recited ECU software-update operations (Fox claim 21). Claims 4 & 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Falcy et al. (US 2015/0317151 A1). Regarding claim 4, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the placeholder code area update indicates that the placeholder code area is preloaded with instructions and does not require an update. However, Falcy teaches: wherein the placeholder code area update indicates that the placeholder code area is preloaded with instructions and does not require an update. (Claim 1 "A method of facilitating enabling a software component on a device, said method being implemented by a computer system comprising one or more processors operable in executing program code stored on at least one non-transitory computer-readable medium to cause the computer system to perform the method comprising: the computer system receiving a download request for the software component and an identifier uniquely associated with the device for which the software component is requested; the computer system ascertaining based on a software inventory for the device whether the software component is pre-installed but not enabled on the device; and wherein, (i) in the event that the computer system ascertains that the software component is pre-installed but not enabled on the device, the computer system causes information for enabling the software component on the device to be communicated to the device, and (ii) in the event that the computer system ascertains that the software component is not pre-installed on the device, the computer system causes the software component to be downloaded for enablement on the device.") Determining that a computer system has a pre-installed component and does not require a further download corresponds to the placeholder code area update indicating a placeholder code area that is preloaded with instructions does not require an update Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the placeholder code area update indicates that the placeholder code area is preloaded with instructions and does not require an update.” By configuring the placeholder code area of Ren to optionally contain pre-installed software components as taught by Falcy. Such that if the components are already present the update only needs to enable the feature rather than downloading the code to implement the functionality to the ECU again, improving the user experience and lowering the bandwidth usage for the update (Falcy 0013). Claim 17 is rejected for the same reasons as claim 4, as it merely recites the system steps corresponding to the method of claim 4. Claims 5 & 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Satoh et al. (US 7783401 B2). Regarding claim 5, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the placeholder code area update includes a remote procedure call to a remote computing device that to be called as part of the code path as updated. However, Satoh teaches: wherein the placeholder code area update includes a remote procedure call to a remote computing device that to be called as part of the code path as updated. (Claim 11 "11. The device of claim 10, wherein the server and each of the clients are produced as electronic control units mounted in the vehicle, the task managing device is implemented in one of the electronic control units and the electronic control unit in which the server is implemented has a function of performing a message communication based on remote procedure call (RPC) and is configured to use the function of performing the message communication in order to perform communication with the other electronic control units mounted in the vehicle.") Using RPC to allow communication between electronic control units corresponds to a remote procedure call to a remote computing device that to be called as part of the code path. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the placeholder code area update includes a remote procedure call to a remote computing device that to be called as part of the code path as updated.” By modifying the patching method of Ren & Fox to allow the new program to use RPC as taught by Satoh. This would predictably allow the patch to add new features that need to communicate with other ECUs to perform the new functions. Claim 18 is rejected for the same reasons as claim 5, as it merely recites the system steps corresponding to the method of claim 5. Claims 6 & 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Mizutani et al. (US 5493674 A). Regarding claim 6, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the placeholder instruction includes a delay loop that is replaced by the software update to preserve timing after addition of the placeholder code area update. However, Mizutani teaches: wherein the placeholder instruction includes a delay loop that is replaced by the software update to preserve timing after addition of the placeholder code area update. (§ Second Embodiment "In this embodiment, as shown in FIG. 4, a program for executing a repeating loop for the time adjustment is put in the ROM beforehand. When the CPU for the electronic apparatus 8 receives a bug-correcting call X instruction which is inserted into the television control program while the CPU is executing the program, the wait loop repeat program is executed. The control program in the ROM is then returned to after the patch correction program in the RAM has been executed. Here, the number of times the wait loop is repeatedly executed is small if the patch correction is long. For example, as shown in FIG. 4, the sum of the period of time necessary to execute the process (2) and the period of time necessary to execute the process (patch correction) (3) is so set as to become always constant, whichever patch correction is executed.") The preexisting wait loop that consumes execution time prior to running the subsequently supplied patch code corresponds to a delay loop that preserves the timing after the placeholder code area update. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the placeholder instruction includes a delay loop that is replaced by the software update to preserve timing after addition of the placeholder code area update.” By modifying the placeholder of Ren to include a timing delay as taught by Mizutani as this would allow for the execution time of a code section to remain constant after a patch adds additional code thereby potentially preventing timing attacks. Claim 19 is rejected for the same reasons as claim 6, as it merely recites the system steps corresponding to the method of claim 6. Claims 7 & 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) and Mizutani et al. (U.S. Patent No. 5493674 A), and further in view of Vigilant et al. (US 2024/0211551 A1). Regarding claim 7, Ren, in view of Fox, in view of Mizutani, teaches the method of claim 6. Ren in view of Fox & Mizutani does not teach: wherein the timing of the delay loop is randomized across the ECU and other ECUs executing the software application. However, Vigilant teaches: wherein the timing of the delay loop is randomized across the ECU and other ECUs executing the software application. (¶0013-0015 "As a result, for one original (or real) opcode of the program, a replacing opcode block comprising this original opcode and one or more fictional (or fake) opcodes is generated and executed. The number of fictional opcodes for every opcode block is randomized by using the random number generator. And the position (or order) for executing the original opcode in every opcode block is also randomized. Thus, the invention allows to mask (or hide) the execution timings of the original opcodes of the program in order to prevent an attacker from analyzing a regular execution pattern of the program and finding a security breach. The invention also allows to dynamically change the execution pattern of the same program since the execution timings of the original opcodes are different each time the program is executed, thanks to the randomization of the number of fictional opcodes and the execution positions of the original opcodes.") Randomizing program execution timing by randomly varying the number of fictional instructions executed with an original instruction causing the execution timing of the program to vary corresponds to randomized timings of a delay function. As the amount of delay is different for each execution, multiple ECUs executing the software would thus also have the delay randomized between them. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the timing of the delay loop is randomized across the ECU and other ECUs executing the software application.” By randomizing the timing delay of Mizutani using the timing-randomization technique of Vigilant as this would allow the software to obscure the predictable execution timing and further hinder some timing-based attacks. Claim 20 is rejected for the same reasons as claim 7, as it merely recites the system steps corresponding to the method of claim 7. Claims 8-9 & 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Korotaev (US 2021/0026949 A1). Regarding claims 8 & 9, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the software update implements a reduced alternative to update the existing portions of the software application, the reduced alternative eliminating a feature or returning with an error to remove a function of the software application. However, Korotaev teaches: wherein the software update implements a reduced alternative to update the existing portions of the software application, the reduced alternative eliminating a feature or returning with an error to remove a function of the software application. (¶0033 "Software update generator 108 may determine that code A features a plurality of functions that are associated with the creation of the new tab and may generate a patch that removes code A from program code 103. As a result, an intruder may not be able to execute functionality 104 for initiating a new tab") An update that removes the code that implements a tab feature corresponds to implementing a reduced alternative to a portion of the software application by eliminating a feature and also removing a function of the software application. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the software update implements a reduced alternative to update the existing portions of the software application, the reduced alternative eliminating a feature or returning with an error to remove a function of the software application.” By using the software patching method of Ren to implement a version of the software with fewer features as taught by Korotaev. This system would allow removing unused or vulnerable functionality using a software patch to reduce the attack surface of the software and prevent exploitation of the removed functionality. (Korotaev 0004). Regarding claim 9, Ren in view of Foz does not teach: wherein the software update implements a stricter alternative to update the existing portions of the software application, the stricter alternative enhancing an existing security check or adding a new security check to increase security of a function of the software application. However, Korotaev further teaches: wherein the software update implements a stricter alternative to update the existing portions of the software application, the stricter alternative enhancing an existing security check or adding a new security check to increase security of a function of the software application. (¶0042 "According to an aspect, software update generator 108 may be configured to generate honeypot patches (e.g., honeypot patch 201) that are configured to convert a computing system with removed processes into a honeypot system. ... Honeypot patch 201 replaces and/or adds to program code 103 of applications 102. For example, honeypot patch 201 may replace code A, which is associated with the removed functionality 104, with honeypot (HP) code, which is associated with functionality 202. Functionality 202 may resemble functionality 104 (e.g., both processes may share the same PID). Accordingly, if an intruder attempts an unauthorized execution of functionality 104, functionality 202 is instead executed. Functionality 202 may generate a security event indicating an attempt to exploit a software vulnerability (e.g., an attempt to execute a removed process).") Replacing a piece of code with a new function that detects software exploitation corresponds to adding a new security check to increase security of a software application. Claim 21 is rejected for the same reasons as claim 8, as it merely recites the system steps corresponding to the method of claim 8. Claim 22 is rejected for the same reasons as claim 9, as it merely recites the system steps corresponding to the method of claim 9. Claims 10 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Islam et al. (US 2015/0379262 A1). Regarding claim 10, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the software update implements a diverse alternative to update the existing portions of the software application, the diverse alternative including an alternative version of a function of the software application that is functionally equivalent but constructed differently. However, Islam teaches: wherein the software update implements a diverse alternative to update the existing portions of the software application, the diverse alternative including an alternative version of a function of the software application that is functionally equivalent but constructed differently. (¶0027 "To address this, in some embodiments, the computing device may receive periodic patches or software updates from remote devices (e.g., OEM/developer servers, etc.) that include new software module variations for storage in memory that do not include known flaws/bugs." ¶0023 " Module variations of a particular module may be formatted or structured differently and/or include different information from one another. … Module variations of the same particular module may be used by software in the same manner and to achieve the same functionality or operational effect. ") Updating variations of a software module that is structured differently but achieves the same functionality corresponds to an update that implements a diverse alternative that is functionally equivalent but constructed differently. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the software update implements a diverse alternative to update the existing portions of the software application, the diverse alternative including an alternative version of a function of the software application that is functionally equivalent but constructed differently.” By modifying the patching method of Ren and Fox with the module variations as taught by Islam. This would allow for the software to be updated with new functionally equivalent modules between which the software could switch and therefore avoid using compromised or flawed variations while the software retains the same functionality (Islam 0031). Claim 23 is rejected for the same reasons as claim 10, as it merely recites the system steps corresponding to the method of claim 10. Claims 11 & 24 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Herdeg et al. (US 2011/0055805 A1). Regarding claim 11, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the placeholder instructions are located at the entry and/or exit points of basic blocks of instructions of the software application, wherein the basic blocks of instructions are connected by edges that are changes in control flow of the instructions. However, Herdeg teaches: wherein the placeholder instructions are located at the entry and/or exit points of basic blocks of instructions of the software application, wherein the basic blocks of instructions are connected by edges that are changes in control flow of the instructions. (¶0033-0034 " The nodes of the graph are basic blocks (BBs), and the edges are control flow edges (CFEs). Each SR contains a plurality of basic blocks. More specifically, each SR includes a start basic block, a tail basic block and zero or more body basic blocks. A start basic block is a pseudo basis block that provides a common entry point. Edges exiting the start block are termed entry edges and are pseudo edges that denote entering replacement code from the original client code. A tail basic block is a pseudo basic block that provides a common exit point. Edges entering the tail block are termed exit edges and are pseudo edges that denote leaving replacement code and continuing execution in the original client code. Body basic blocks represent real program code. Body basic blocks are transformed to generate the replacement code. ... In the final super-regions produced by the region selection operation 300, the body basic blocks form a single connected component in which the entry edges define the patch points (i.e., the addresses in the client program that are patched to enter the replacement code). The single entry and exit of a super-region makes it amenable to traditional compiler analysis and optimization.") The patch points at the entry to patchable basic blocks correspond to locations at entry points of basic blocks. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the placeholder instructions are located at the entry and/or exit points of basic blocks of instructions of the software application, wherein the basic blocks of instructions are connected by edges that are changes in control flow of the instructions.” By placing the placeholder instructions of Ren & Fox at basic block entry patch points as taught by Herdeg. This would predictably allow for the patch points to be allocated at points where they would not disrupt the execution of the basic blocks when replaced with the patch code. Claim 24 is rejected for the same reasons as claim 11, as it merely recites the system steps corresponding to the method of claim 11. Claims 12 & 25 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Rodriguez et al. (US 2010/0095376 A1). Regarding claim 12, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the placeholder instructions are located to produce a pattern unique to the software application for identifying the software application. However, Rodriguez teaches: wherein the placeholder instructions are located to produce a pattern unique to the software application for identifying the software application. (¶0031 "Consider a software company that wants to serialize particular copies of software, distributed to customers. Each copy may be marked, with a series of NOPS interspersed with other instructions in the assembly code, so as to encode the receiving customer's name or telephone number." ¶0033 “If a copy of the marked software is found posted on a public web site (e.g., a software piracy, or warez, site), the company can disassemble the executable code and examine the series of NOP/MOV instructions, beginning at the known location, and thereby identify the customer from whom the copy leaked. Yet casual examination of the code (e.g., searching for the customer's name as a text string) finds nothing.”) Inserting instructions according to a placement pattern that encodes identifying information corresponds to locating placeholder instructions to produce a pattern unique to the software application for identifying the software application. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the placeholder instructions are located to produce a pattern unique to the software application for identifying the software application.” By placing the placeholder instructions of Ren & Fox according to an identifying pattern as taught by Rodriguez. This would predictably provide an additional identification function while retaining their patching function and thus allow the software to be traceable back to a specific customer and/or user (Rodriguez 0033). Claim 25 is rejected for the same reasons as claim 12, as it merely recites the system steps corresponding to the method of claim 12. Claims 13 & 26 are rejected under 35 U.S.C. 103 as being unpatentable over Ren (US 2003/0084434 A1) in view of Fox (US 2022/0391197 A1) further in view of Reed et al. (US 2013/0318607 A1). Regarding claim 13, Ren, in view of Fox, teaches the method of claim 1. Ren in view of Fox does not teach: wherein the placeholder instructions are chosen to include a power consumption pattern unique to the software application for identifying the software application. However, Reed teaches: wherein the placeholder instructions are chosen to include a power consumption pattern unique to the software application for identifying the software application. (¶0074 “Markers can be of different nature and help with triggering and synchronization. Potential markers include physical signals (as changing the voltage level of a pin) or a specific sequence of instructions that yields a known power consumption sequence.” ¶0079-0080 “After inserting 710 markers into the code, the trusted software is executed and the resulting power traces are captured 720. Discriminatory features are extracted 750 and statistical analysis, averaging and clustering 760 is done to generate a set of authorized signatures 770. ... The signatures can be extracted from different signal domains and be multidimensional. Furthermore, multiple signatures can be used to identify a single piece of code.”) Selecting a sequence of instructions so that execution produces a distinctive power consumption signature identifying a software module corresponds to choosing the placeholder instructions to include a power-consumption pattern unique to the software application for identifying the software application. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to add “wherein the placeholder instructions are chosen to include a power consumption pattern unique to the software application for identifying the software application.” By choosing the placeholder instructions of Ren to produce a distinctive power-consumption signature as taught by Reed. This would allow for the detection of unauthorized modification and tampering of the software (Reed 0182). Claim 26 is rejected for the same reasons as claim 13, as it merely recites the system steps corresponding to the method of claim 13. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (US 9600672 B1) Dynamic function switching: Teaches the dynamic enabling/disabling of software module. Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUKE THOMSON whose telephone number is (571)272-0511. The examiner can normally be reached Monday Friday, 8 a.m. 5 p.m. ET.. 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. /LUKE THOMSON/ Examiner, Art Unit 2193 /Chat C Do/ Supervisory Patent Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Oct 15, 2024
Application Filed
Oct 02, 2026
Non-Final Rejection mailed — §101, §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month