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 .
Election/Restrictions
During a telephone conversation with Eric Schlevensky on 8/25/2026 a provisional election was made without traverse to prosecute the invention of elected group, claims 1-16. Affirmation of this election must be made by applicant in replying to this Office action. Claims 17-20 withdrawn from further consideration by the examiner, 37 CFR 1.142(b), as being drawn to a non-elected invention.
Claims 1-16 are drawn to a method and system using two processor modules in tandem to modify an application during execution
Claims 17-20 are drawn to a method using three processing devices to modify a safety function at periodic intervals
The inventions are independent or distinct from each other because:
Inventions group 1 and group 2 are independent as group 1 uses two processing modules in tandem executing an application, applying a lock to prevent execution, and modifying the application with both processing modules. Group 2 uses three processing devices to modify a safety function
Restriction for examination purposes as indicated is proper because all the inventions listed in this action are independent or distinct for the reasons given above and there would be a serious search and/or examination burden if restriction were not required because one or more of the following reasons apply:
Each of the identified groups recite subject matter that would require entirely different search strategies and additional search burden based on different classification and claim scope outlined above.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim3-4 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the limitation "the first and the second communication core". There is insufficient antecedent basis for this limitation in the claim.
Claim 4 recites the limitation “the first control core to the second control core”. There is insufficient antecedent basis for this limitation in the claim.
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.
Claim(s) 1-3 and 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240311141 A1 (hereinafter referred to as Hallett) and US 20200301699 A1 (hereinafter referred to as Raisch).
Regarding claim 1, Hallett teaches:
A method for modifying an application on a safety controller during execution, the method comprising the steps of:
receiving an edit request at a first processor module for an application executing in tandem on the first processor module and a second processor module (Fig. 6, [Abstract], Hallett shows "A system and related method, including a first processor core, a second processor core and a control circuitry to receive requests to update existing firmware of the first processor core to a new firmware." Examiner notes Fig. 6 shows the first and second core running an application in tandem as an update occurs.);
transmitting the change record from the first processor module to the second processor module (Fig. 5, Para. [58], Hallett shows "At step 508, the dynamic firmware update application loads new firmware to all processor cores except the second processor core. The dynamic firmware update application boots the new firmware on each of the processor cores except the second processor core, while the second processor core continues to receive and execute transactions. When the new firmware is completely booted onto the processor cores, each of the newly updated processor cores are available for processing, with an assertion check on the pause processing bit for the processor cores." Wherein the 1st and 2nd processor modules are the processor cores that updating with new firmware, except the second processor core);
acquiring a lock to prevent execution of the application in the first processor module after transmitting the change record to the second processor module (Fig. 5 (506); Para. [29], Hallett shows "FIG. 2 shows a flowchart illustrating a process 200 for updating the existing firmware of the first processor while continuing to execute transactions on the second processor core, in accordance with some embodiments of the present disclosure. In some embodiments, the referenced traffic manager, standalone traffic manager, first processor core, second processor core and the controller may be implemented as traffic manager 113, standalone traffic manager 115, first processor core 106, second processor core 108, and controller 110, respectively. In some embodiments, the process 200 can be modified by, for example, having steps rearranged, changed, added, and/or removed." Para. [33], Hallett shows "At step 208, the dynamic firmware update application causes the first processor core to stop executing transactions. The dynamic firmware update application has completed a hand-off from the first processor core to the second processor core, therefore the first processor core should stop executing transactions, so that the second processor core can continue the execution of outstanding transactions as the firmware update process resumes. Once the second processor core stops executing transactions, it is available and may remain available until after updating to the new firmware." Examiner notes that Fig. 5 shows pausing all cores to prevent execution of any application transaction except the second processor core.);
applying the change record to the application on the first processor module and on the second processor module during the lock of the application in the first processor between cycles of the application (Fig. 5 (508) and paragraph [0059], Hallet shows applying the firmware update to all cores except the currently running core.);
and releasing the lock preventing execution of the application in the first processor module when the change record has been applied to the first and second processor modules (Fig. 4-5 (410) and paragraph [0053], Hallet shows releasing the pausing of cores after the new firmware has been applied allowing the new cores with updated firmware to take over.).
Hallett does not disclose:
preparing a change record for the application in response to the edit request on the first processor module;
However, in the analogous art of embedded application upgrade, Raisch teaches:
preparing a change record for the application in response to the edit request on the first processor module (Abstract and Para. [0003] and [16], Raisch shows "Code Load O 140 is executed on First Core 149 located on Server Computer 120. In various embodiments, Code Load N 150 is executed on Second Core 159 located on Server Computer 120. In other embodiments, Code Load O 140 and Code Load N 150 can be located anywhere in distributed data processing environment 100. In various embodiments, First Core 149 can represent one or more old cores, wherein the one or more old cores are being updated by one or more new cores, and/or the one or more old cores are associated with one or more old code loads, one or more old applications, and/or one or more old kernels that are being updated by one or more new code loads, one or more new applications, and/or one or more new kernels. It should be noted that term “new” means a newer version of an older version of a code load (e.g., application and/or kernel) that is currently running. For example, an old code load is replaced by a newer version of the code load (e.g., a next code load). In various embodiments, Second Core 159 can represent one or more new cores, wherein the new core is updating and/or replacing one or more old cores, and/or the one or more new cores is associated with one or more new code loads, one or more new applications, and/or one or more new kernels that are updating and/or replacing the one or more old code loads, one or more old applications, and/or one or more old kernels." Wherein the code load as the change of record is loaded and executed based on upon the client request);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Hallett into the teachings of Raisch to implement “preparing a change record for the application in response to the edit request on the first processor module”. The modification would have been obvious as one of ordinary skill in the art would be motivated to minimize application blackout time by sending update data to a second core (Raisch, [Abstract]).
Regarding claim 2, Hallett as modified in claim 1 teaches:
wherein the first processor module includes a first communication core and a first control core and wherein the second processor module includes a second communication core and a second control core (Fig. 1(113, 115); Para. [25], Hallet shows "The controller 110 includes a control manager 111 that links with the traffic manager 113 and the standalone traffic manager 115 of the first processor core 106 and the second processor core 108, respectively. The control manager 111 is configured to send control signals from the controller to each of the processor cores 106, 108. The traffic manager 113 and the standalone traffic manager 115 provide command or instruction management as they are received by the first processor core 106 and the second processor core 108, respectively. The traffic manager 113 and standalone traffic manager 115 are set up to follow a transport protocol (e.g., PCIe, Ethernet, etc.) that is compatible with external devices, that are communicatively coupled to the system output 120." Examiner notes the traffic managers represent communication cores).
Regarding claim 3, Hallett as modified in claim 1 teaches:
further comprising the steps of: establishing a communication channel between the first communication core and the second communication core via a dedicated communication interface (Fig. 1; Para. [20], Hallet shows "FIG. 1 shows an illustrative diagram of a system 100 with a multi-core processor 104 and controller 110, in accordance with some embodiments of the present disclosure. In some embodiments, system 100 may include SSD device 102, which includes a multi-core processor 104, with a first processor core 106, a second processor core 108, and a data bus interface 116. It will be understood that the embodiments of the present disclosure are not limited to solid state drives (SSDs). For example, in some embodiments, the system 100 may include a hard disk drive (HDD) device in addition to or in place of the SSD.");
and transmitting the change record from the first communication core to the second communication core via the communication channel over the dedicated communication interface (Fig. 5, Para. [58], Hallett shows "At step 508, the dynamic firmware update application loads new firmware to all processor cores except the second processor core. The dynamic firmware update application boots the new firmware on each of the processor cores except the second processor core, while the second processor core continues to receive and execute transactions. When the new firmware is completely booted onto the processor cores, each of the newly updated processor cores are available for processing, with an assertion check on the pause processing bit for the processor cores." Fig. 1; Para. [20], Hallet shows "FIG. 1 shows an illustrative diagram of a system 100 with a multi-core processor 104 and controller 110, in accordance with some embodiments of the present disclosure. In some embodiments, system 100 may include SSD device 102, which includes a multi-core processor 104, with a first processor core 106, a second processor core 108, and a data bus interface 116. It will be understood that the embodiments of the present disclosure are not limited to solid state drives (SSDs). For example, in some embodiments, the system 100 may include a hard disk drive (HDD) device in addition to or in place of the SSD." Examiner notes the above citations don’t explicitly state using the Data Bus Interface, however it is implied through any communications through cores the data bus is used, for example, the data migration done in Fig. 6).
With regards to claim 9, it is a system claim having similar limitations as cited in claim 1 and 2 above. Thus, claim 9 is also rejected under the same rationale as cited in the rejection of claim 1 and 2 above.
With regards to claim 10, it is a system claim having similar limitations as cited in claim 3 above. Thus, claim 10 is also rejected under the same rationale as cited in the rejection of claim 3 above.
Claim(s) 4-7 and 11-12, and 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240311141 A1 (hereinafter referred to as Hallett) and US 20200301699 A1 (hereinafter referred to as Raisch) in further view of US 20260072695 A1 (hereinafter referred to as Munnan).
Regarding claim 4, Hallett as modified in claim 3 teaches:
and applying the change record in the first processor module with the first control core (Fig. 6 (602), Hallet shows loading new firmware. This shows the first processor has implemented the update).
Hallett does not disclose:
wherein the step of applying the change record to the application on the first processor module and on the second processor module further comprises the steps of: transmitting an apply edit command from the first control core to the second control core via the communication channel over the dedicated communication interface;
receiving an apply edit confirmation at the first control core from the second control core via the communication channel over the dedicated communication interface;
However, in the analogous art of split-lock architecture of multi-core processor, Munnan teaches:
wherein the step of applying the change record to the application on the first processor module and on the second processor module further comprises the steps of: transmitting an apply edit command from the first control core to the second control core via the communication channel over the dedicated communication interface (Para. [Abstract], Munnan shows "The first core is configured to send a request to the second core to enter into a lock mode to execute the safety-critical application in parallel with the first core. A comparator receives inputs from the first core and the second core and compares the inputs. The second core drives the comparator into a transition state; stops execution of a first application running on the second core; saves data from the second core to memory associated with the second core; and sends an acknowledgment back to the first core in response to the request. The first core, in response to receiving the acknowledgement signal, is further configured to enable the execution of the safety-critical application by both cores in lock mode by configuring the memory and the comparator." Examiner notes the above citation shows receiving a command from a first core to a second core to update its status and convert.);
receiving an apply edit confirmation at the first control core from the second control core via the communication channel over the dedicated communication interface (Para. [Abstract], Munnan shows "The first core is configured to send a request to the second core to enter into a lock mode to execute the safety-critical application in parallel with the first core. A comparator receives inputs from the first core and the second core and compares the inputs. The second core drives the comparator into a transition state; stops execution of a first application running on the second core; saves data from the second core to memory associated with the second core; and sends an acknowledgment back to the first core in response to the request. The first core, in response to receiving the acknowledgement signal, is further configured to enable the execution of the safety-critical application by both cores in lock mode by configuring the memory and the comparator." Para. [15], Munnan shows "Optionally, the request is one of a flag bit or a flush request." Para. [62], Munnan shows "The second core is also configured to stop the executing/processing the first application and to flush all data including dirty data from the second core and to save the context data and residual data in the memory of the second core." Examiner notes the above citation shows receiving a command from a first core to a second core to update its status and convert and further sending back an acknowledgement after implementing the command.);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Munnan into the teachings of Hallett as modified to implement “wherein the step of applying the change record to the application on the first processor module and on the second processor module further comprises the steps of: transmitting an apply edit command from the first control core to the second control core via the communication channel over the dedicated communication interface; receiving an apply edit confirmation at the first control core from the second control core via the communication channel over the dedicated communication interface”. The modification would have been obvious as one of ordinary skill in the art would be motivated to prevent having to reinitiali
Regarding claim 5, Hallett as modified in claim 5 teaches:
the first processor module includes a safety task period (Fig. 2(208, 210), Hallett shows in Fig. 2 pausing or stopping processors and migrating data. This can be considered a type of safety task period),
and at least one other task executes on the first processor module and the second process module during a second portion of the safety task period (Fig. 6 (608), Hallet shows the first processor after loading firmware receiving data and the second processor sending data. This can be considered another task executed at a second portion of the safety task period.).
Hallett does not disclose:
the first processor module and the second processor module execute the application in tandem once during a first portion of the safety task period,
However, in the analogous art of split-lock architecture of multi-core processor, Munnan teaches:
the first processor module and the second processor module execute the application in tandem once during a first portion of the safety task period (Para. [8], Munnan shows " wherein the first core is configured to, on initiating a safety-critical application, send a request to the second core to enter into a lock mode to execute the safety-critical application in parallel with the first core;" Examiner notes initiating the safety-critical application can be considered a safety task period.),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Munnan into the teachings of Hallett as modified to implement “the first processor module and the second processor module execute the application in tandem once during a first portion of the safety task period”. The modification would have been obvious as one of ordinary skill in the art would be motivated to prevent having to reinitiali
Regarding claim 6, Hallett as modified in claim 5 teaches:
wherein the steps of preparing the change record for the application in response to the edit request on the first processor module and transmitting the change record from the first processor module to the second processor module are performed during a plurality of the safety task periods (Fig. 2-4(208, 210), Hallett shows in these figures a plurality of pausing and while update related tasks happen concurrently. Fig. 5, Para. [58], Hallett shows "At step 508, the dynamic firmware update application loads new firmware to all processor cores except the second processor core. The dynamic firmware update application boots the new firmware on each of the processor cores except the second processor core, while the second processor core continues to receive and execute transactions. When the new firmware is completely booted onto the processor cores, each of the newly updated processor cores are available for processing, with an assertion check on the pause processing bit for the processor cores." Examiner notes this Fig. 5 can be seen with a plurality of pausing events happening in elements (300, 400).).
Regarding claim 7, Hallett as modified in claim 6 teaches:
wherein the steps of acquiring the lock to prevent execution of the application in the first processor module after transmitting the change record to the second processor module, applying the change record to the application on the first processor module and on the second processor module during the lock of the application in the first processor module, and releasing the lock preventing execution of the application in the first processor module when the change record has been applied to the first and second processor modules are performed during one second portion of the safety task period (Fig. 4-5, Hallet shows in these figures applying updates during a pause applied to the processor. Specifically after step 508 step 400 un-paused the processors in step 410.).
With regards to claim 11, it is a system claim having similar limitations as cited in claim 4 above. Thus, claim 11 is also rejected under the same rationale as cited in the rejection of claim 4 above.
With regards to claim 12, it is a system claim having similar limitations as cited in claim 4 above. Thus, claim 12 is also rejected under the same rationale as cited in the rejection of claim 4 above.
With regards to claim 14, it is a system claim having similar limitations as cited in claim 6 above. Thus, claim 14 is also rejected under the same rationale as cited in the rejection of claim 6 above.
With regards to claim 15, it is a system claim having similar limitations as cited in claim 7 above. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 7 above.
Claim(s) 8 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240311141 A1 (hereinafter referred to as Hallett) and US 20200301699 A1 (hereinafter referred to as Raisch) in further view of US 20220107798 A1 (hereinafter referred to as Takatsuna).
Regarding claim 8, Hallett as modified teaches claim 1 as cited above, but does not disclose:
further comprising the step of verifying a plurality of requested edits have no errors.
However, in the analogous art of software distribution, Takatsuna teaches:
further comprising the step of verifying a plurality of requested edits have no errors (Para. [38], Takatsuna shows "such as determining whether the installation can be executed, transferring the update data, and verifying an updated version of the program. Activation is a process of activating the installed updated version of the program. The activation control includes not only executing the activation, but also controlling a sequence of processes related to the activation, such as determining whether the activation can be executed and verifying the execution result.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Takatsuna into the teachings of Hallett to implement “further comprising the step of verifying a plurality of requested edits have no errors”. The modification would have been obvious as one of ordinary skill in the art would be motivated verifies the authenticity of the received data to ensure it works as intended (Takatsuna, Para. [38]).
With regards to claim 16, it is a system claim having similar limitations as cited in claim 8 above. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 8 above.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240311141 A1 (hereinafter referred to as Hallett) and US 20200301699 A1 (hereinafter referred to as Raisch) in further view of US 20260072695 A1 (hereinafter referred to as Munnan) and US 20240311158 A1 (hereinafter referred to as Koontz).
Regarding claim 13, Hallett as modified in claim 9 teaches:
and at least one other task executes on the second core of the first processor and the second core of the second processor during a second portion of each periodic interval (Fig. 6 (608), Hallet shows the first processor after loading firmware receiving data and the second processor sending data. This can be considered another task executed at a second portion of the interval between pauses).
Koontz does not disclose:
a first processor module including the first memory and the first processor, the first processor module further comprising a first clock circuit configured to start execution of the safety function at a periodic interval; and a second processor module including the second memory and the second processor, the second processor module further comprising a second clock circuit configured to start execution of the safety function at the periodic interval, wherein:
the second core of the first processor and the second core of the second processor execute the safety function in tandem once during a first portion of the periodic interval,
However, in the analogous art of s, Koontz teaches:
a first processor module including the first memory and the first processor, the first processor module further comprising a first clock circuit configured to start execution of the safety function at a periodic interval; and a second processor module including the second memory and the second processor, the second processor module further comprising a second clock circuit configured to start execution of the safety function at the periodic interval, wherein (Para. [22], Koontz shows "The plurality of processors 14 of an example embodiment are configured to operate synchronously and, as such, may be clocked by the same clock source. In other examples, however, the plurality of processors 14 are configured to operate asynchronously, such as by being clocked by different clock sources. The plurality of processors 14 may include a plurality of the same type of processors. Alternatively, the plurality of processors 14 may be embodied by a plurality of different types of processors, that is, the processors may be dissimilar processors (having different internal hardware architectures). In one example, the plurality of processors 14 include a plurality of multi-core processors. The processors 14 are each configured to execute one or more applications, at least some of which are to be synchronized. At least some of the applications may include multiple threads of operations, e.g., one or more processes. In an example, two or more threads of an application may execute concurrently, even though the threads may run at different periodic rates or even aperiodically. In an instance in which the system 10 includes a plurality of multi-core processors, each application may be executed in a partition on a particular core or set of cores of a respective processor. As a result, the same application and, in turn, the same thread may be executed by a respective core of two or more of the multi-core processors of this example".):
the second core of the first processor and the second core of the second processor execute the safety function in tandem once during a first portion of the periodic interval (Para. [22], Koontz shows "The plurality of processors 14 of an example embodiment are configured to operate synchronously and, as such, may be clocked by the same clock source. In other examples, however, the plurality of processors 14 are configured to operate asynchronously, such as by being clocked by different clock sources. The plurality of processors 14 may include a plurality of the same type of processors. Alternatively, the plurality of processors 14 may be embodied by a plurality of different types of processors, that is, the processors may be dissimilar processors (having different internal hardware architectures). In one example, the plurality of processors 14 include a plurality of multi-core processors. The processors 14 are each configured to execute one or more applications, at least some of which are to be synchronized. At least some of the applications may include multiple threads of operations, e.g., one or more processes. In an example, two or more threads of an application may execute concurrently, even though the threads may run at different periodic rates or even aperiodically. In an instance in which the system 10 includes a plurality of multi-core processors, each application may be executed in a partition on a particular core or set of cores of a respective processor. As a result, the same application and, in turn, the same thread may be executed by a respective core of two or more of the multi-core processors of this example".),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Koontz into the teachings of Hallet as modified to implement “a first processor module including the first memory and the first processor, the first processor module further comprising a first clock circuit configured to start execution of the safety function at a periodic interval; and a second processor module including the second memory and the second processor, the second processor module further comprising a second clock circuit configured to start execution of the safety function at the periodic interval, wherein: the second core of the first processor and the second core of the second processor execute the safety function in tandem once during a first portion of the periodic interval,”. The modification would have been obvious as one of ordinary skill in the art would be motivated to enhance fault tolerance, overall system safety, and computational lane coherency (Koontz, Para. [2-3]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20180173182 A1 – This prior art teaches updating a control system with multi-core processing without interruption
US 20200301691 A1 – This prior art teaches using a master controller to update a distributed amount of applications across a plurality of processors
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZEERICK A MALIK whose telephone number is (571)272-8110. The examiner can normally be reached Mon-Thurs, 7-5.
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.
/Z.A.M./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
