DETAILED ACTION
This Action is a response to the reply filed 20 October 2023. Claims 1-20 are presented for examination.
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 .
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2, 4-14, 16 and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by G. Deconinck and R. Lauwereins, "User-triggered checkpointing: system-independent and scalable application recovery," Proceedings Second IEEE Symposium on Computer and Communications, Alexandria, Egypt, 1997, pp. 418-423 (“Deconinck”).
Regarding claim 1, Deconinck teaches: A method comprising: implementing a library into a process, wherein the library facilitates checkpoint-and-resume functionality to enable the process to checkpoint itself via the implemented library (Deconinck, e.g., § 2, ¶2, “library provides the programmer with define-calls, indicating from which elements the process the state must be saved – this defines the checkpoint contents --; and trigger-calls indicating the position of the RL in the program code …”);
using a set of tags to annotate code of the process, the set of tags defining which data of the process is to be saved in an event in which the process terminates in an unexpected manner, wherein the set of tags includes a first set of tags defining a block within the code, and wherein the set of tags includes a second set of tags defining the data that is to be saved (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays … programmer indicates these data-items by specifying the start addresses and the size of their memory regions … process continues until a trigger-call is encountered (positions C4 in Fig. 1). This trigger-call must be positioned in each process …” See also, e.g., § 2.1, ¶7, “Each process may have multiple instances of trigger-calls … For each of them, the different checkpoint contents may be different …”);
after the data has been saved, detecting that the process has terminated in the unexpected manner; restarting the process from a beginning state (Deconinck, e.g., § 2.2, ¶1, “Upon recovery … all processes are restarted from the beginning …”);
from the beginning state of the process, causing the process to progress through the code, wherein said progression includes skipping execution of code for which data was previously saved; continue progressing and skipping through the code until said progression reaches the defined block; and causing the process to resume at the defined block (Deconinck, e.g., § 2.2, ¶¶2-6, “each process re-establishes the connection to the checkpoint control layer … processes set up their application-specific topology … allocate necessary space … execution jumps to the define-calls to re-define which elements belong to the checkpoint contents … each process continues with the corresponding trigger-call, where the checkpoint data is restored (This again allows to skip application-specific instructions … restores this checkpoint data in the memory regions corresponding to the re-initialized checkpoint contents. As such, the application is again in the same state as when this checkpoint data was saved before the failure. From here on, it continues as in the fault-free case from section 2.1, further saving checkpoint data …”).
Regarding claim 2, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein detecting that the process has terminated in the unexpected manner includes detecting that the process has crashed (Deconinck, e.g., § 2.2, ¶1, “Upon recovery … all processes are restarted from the beginning …” See also, e.g., § 1, describing a failure necessitating restarting applications from the beginning without the use of checkpoint saving, consistent with a crash).
Regarding claim 4, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein the data that is defined to be saved includes variable data (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays …”).
Regarding claim 5, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein the set of tags is further configured to enable a declaration as to when the data that is defined is to be saved (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays … programmer indicates these data-items by specifying the start addresses and the size of their memory regions … process continues until a trigger-call is encountered (positions C4 in Fig. 1). This trigger-call must be positioned in each process … initiates the checkpointing for this process …”).
Regarding claim 6, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein the data that is saved is different than an entire program’s state (Deconinck, e.g., § 2.3, “Checkpointing approaches that are transparent to the user have the checkpoint contents equal to the entire process state … For the user-triggered checkpointing approach the checkpoint contents consists only of data items from within the application … reduction in checkpoint contents …”).
Regarding claim 7, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein the data that is saved includes one or more of variable data, metadata, or a sub-portion of program state (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays …”).
Regarding claim 8, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein the data that is saved includes metadata about a last completed block of code that was executed prior to the process terminating in the unexpected manner (Deconinck, e.g., § 2.1, “trigger-call … initiates the checkpointing for this process … saves the state of each of the elements belonging to the checkpoint contents as checkpoint data: it scans its local data structure, and sends the state of corresponding memory regions to stable storage. Then, a short control message (with process identification and a sequence number) … When all processes saved the checkpoint data at the trigger-call, this data forms a RL for the application … consists of checkpoint data representing the state of the process …”).
Regarding claim 9, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein code portions whose data is not included in the data that is defined and saved is executed during said progression, such that the data for those code portions is reset during said progression (Deconinck, e.g., § 2.2, “checkpoint contents consists only of elements from the application ... No other information from the process’s workspace … has to be saved, as it is restored to the correct state by re-executing a portion of the application …”).
Regarding claim 10, the rejection of claim 1 is incorporated, and Deconinck further teaches: wherein, at a top section of the block, the set of tags identify one or more variables whose values are to be saved (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays …”).
Regarding claim 11, Deconinck teaches: A method comprising: accessing a library that has been implemented in a process, wherein the library facilitates checkpoint-and-resume functionality to enable the process to checkpoint itself via the implemented library (Deconinck, e.g., § 2, ¶2, “library provides the programmer with define-calls, indicating from which elements the process the state must be saved – this defines the checkpoint contents --; and trigger-calls indicating the position of the RL in the program code …”);
using a set of tags to annotate code of the process, the set of tags defining which data of the process is to be saved in an event in which the process terminates in an unexpected manner, wherein the set of tags includes a first set of tags defining a block within the code, and wherein the set of tags includes a second set of tags defining the data that is to be saved (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays … programmer indicates these data-items by specifying the start addresses and the size of their memory regions … process continues until a trigger-call is encountered (positions C4 in Fig. 1). This trigger-call must be positioned in each process …” See also, e.g., § 2.1, ¶7, “Each process may have multiple instances of trigger-calls … For each of them, the different checkpoint contents may be different …”);
after the data has been saved, detecting that the process has terminated in the unexpected manner; restarting the process from a beginning state (Deconinck, e.g., § 2.2, ¶1, “Upon recovery … all processes are restarted from the beginning …”);
from the beginning state of the process, causing the process to progress through the code, wherein said progression includes skipping execution of code for which data was previously saved; continue progressing and skipping through the code until said progression reaches the defined block; and causing the process to resume at the defined block, which is user defined such that the process resumes at a location in the code defined by the user (Deconinck, e.g., § 2.2, ¶¶2-6, “each process re-establishes the connection to the checkpoint control layer … processes set up their application-specific topology … allocate necessary space … execution jumps to the define-calls to re-define which elements belong to the checkpoint contents … each process continues with the corresponding trigger-call, where the checkpoint data is restored (This again allows to skip application-specific instructions … restores this checkpoint data in the memory regions corresponding to the re-initialized checkpoint contents. As such, the application is again in the same state as when this checkpoint data was saved before the failure. From here on, it continues as in the fault-free case from section 2.1, further saving checkpoint data …” Examiner’s note: the resumption point is at a trigger-call, which is a user-defined implementation of the checkpointing location).
Regarding claim 12, the rejection of claim 11 is incorporated, and Deconinck further teaches: wherein, prior to the process terminating in the unexpected manner, a log describing an initial progress of the process is maintained, said log detailing the process’s initial progress through the set of tags, the initial progress occurring prior to the process terminating in the unexpected manner (Deconinck, e.g., § 2.1, ¶¶2-4, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays … checkpoint library saves the state of each of the elements belonging to the checkpoint contents as checkpoint data: it scans its local data structure, and sends the state of corresponding memory regions to stable storage. Then a short control message (with process identification and a sequence number) is asynchronously sent to the checkpoint control layer indicating that this checkpoint data was saved …” See also, e.g., § 2.4, “control process … keeps track of the progress of checkpointing for those processes that are closer to that I/O node … control process establishes a connection to each of the processes of its controlled set … receive control messages at every trigger-call, indicating that a process saved its checkpoint data for a particular RL …” Note: RL is a recovery line).
Regarding claim 13, the rejection of claim 12 is incorporated, and Deconinck further teaches: wherein the log includes a current stack frame describing which block the process is in as well as a most recently passed checkpoint within that block (Deoninck, e.g., § 2.4, “Each control process (including the master) keeps a local database on stable storage with information on the status of the RLs of the application, representing the checkpointing progress as seen by the lower layer. The status of a RL evolves from INVALID over LOCALLY_COMPLETE (if a control process knows that its entire controlled set saved the checkpoint data for a RL) to GLOBALLY_COMPLETE (if all processes saved the checkpoint data for that RL). Some time later, this RL is marked VALID. (Fail-time-bounded behavior is assumed, allowing a non-zero error detection latency [17] and more realistic than fail-silent.) If it is obsolete, e.g. because a more recent RL is VALID, its status changes to OBSOI.ETE and the corresponding checkpoint data is deleted.” Examiner’s note: a locally or globally complete RL is an indication that a particular RL (checkpoint) has been most recently passed locally or globally; an obsolete RL is one for which a next checkpoint is now valid. Each RL is associated with a function or loop, thus further indicating a block the process is in).
Regarding claim 14, the rejection of claim 13 is incorporated, and Deconinck further teaches: wherein the log further includes values of each variable in each block that has been marked for checkpointing by the set of tags (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays …”).
Regarding claim 16, the rejection of claim 11 is incorporated, and Deconinck further teaches: wherein the block includes a sub-part of a function (Deconinck, e.g., Fig. 1, showing define and trigger calls in loops, which are a sub-part of the main function).
Regarding claim 18, Deconinck teaches: A computer system comprising: one or more processors; and one or more hardware storage devices that store instructions that are executable by the one or more processors to cause the computer system (Deconinck, e.g., § 1, describing the execution of the disclosed methods in a high performance computing environment including parallel computers; see also § 4, describing an example computing environment on which an experimental use of the methods was performed) to: access a library that has been implemented in a process, wherein the library facilitates checkpoint-and-resume functionality to enable the process to checkpoint itself via the implemented library (Deconinck, e.g., § 2, ¶2, “library provides the programmer with define-calls, indicating from which elements the process the state must be saved – this defines the checkpoint contents --; and trigger-calls indicating the position of the RL in the program code …”);
use a set of tags to annotate code of the process, the set of tags defining which data of the process is to be saved in an event in which the process terminates in an unexpected manner, wherein the set of tags includes a first set of tags defining a block within the code, and wherein the set of tags includes a second set of tags defining the data that is to be saved (Deconinck, e.g., § 2.1, ¶¶2-3, “each process continues its execution and initializes the checkpoint contents at the define-calls (positions C3 in Fig. 1). These calls define the elements for which the status must be saved … variables, arrays … programmer indicates these data-items by specifying the start addresses and the size of their memory regions … process continues until a trigger-call is encountered (positions C4 in Fig. 1). This trigger-call must be positioned in each process …” See also, e.g., § 2.1, ¶7, “Each process may have multiple instances of trigger-calls … For each of them, the different checkpoint contents may be different …”);
after the data has been saved, detect that the process has terminated in the unexpected manner; restart the process from a beginning state (Deconinck, e.g., § 2.2, ¶1, “Upon recovery … all processes are restarted from the beginning …”);
from the beginning state of the process, cause the process to progress through the code, wherein said progression includes skipping execution of code for which data was previously saved; continue to progress and to skip through the code until said progression reaches the defined block; and cause the process to resume at the defined block (Deconinck, e.g., § 2.2, ¶¶2-6, “each process re-establishes the connection to the checkpoint control layer … processes set up their application-specific topology … allocate necessary space … execution jumps to the define-calls to re-define which elements belong to the checkpoint contents … each process continues with the corresponding trigger-call, where the checkpoint data is restored (This again allows to skip application-specific instructions … restores this checkpoint data in the memory regions corresponding to the re-initialized checkpoint contents. As such, the application is again in the same state as when this checkpoint data was saved before the failure. From here on, it continues as in the fault-free case from section 2.1, further saving checkpoint data …” Examiner’s note: the resumption point is at a trigger-call, which is a user-defined implementation of the checkpointing location).
Claims 19-20 are rejected for the additional reasons given in the rejections of claims 12-13 above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Deconinck in view of Bluvband, Max, U.S. 6,993,487 B2 (“Bluvband”).
Regarding claim 3, the rejection of claim 1 is incorporated, but Deconinck does not more particularly teach that at least some of the tags are added to the code in a form of a comment. However, Bluvband does teach: wherein at least some of the tags in the set of tags are added to the code in a form of a comment (Bluvband, e.g., 2:3-22, “organizing and managing program code comments … enables editing of comments in code segments … Comments on code segments … can be classified into … Watch variables comments …” See also, e.g., 6:11-25, “A comment that is classified as watch comment contains one or more watch expressions or variables, which are related to the referred comment code segment … produces monitoring for the given watch expressions or variables, while debugging the code segment … displaying the expressions and their values …”) for the purpose of permitting a user to enter comments via text or voice to facilitate testing, debugging and/or monitoring of the values of user-defined values or elements in code (Bluvband, e.g., 2:27-3:20).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for user-defined checkpointing of code as taught by Deconinck to provide that at least some of the tags are added to the code in a form of a comment because the disclosure of Bluvband shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for code commenting for at least enabling monitoring to provide that at least some of the tags are added to the code in a form of a comment for the purpose of permitting a user to enter comments via text or voice to facilitate testing, debugging and/or monitoring of the values of user-defined values or elements in code (Bluvband, Id.).
Claims 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Deconinck in view of Randimbivololona, Famantanantsoa, U.S. 2010/0299559 A1 (“Randimbivololona”).
Regarding claim 15, the rejection of claim 11 is incorporated, but Deconinck does not more particularly teach that the block includes an entire function. However, Randimbivololona does teach: wherein the block includes an entire function (Randimbivololona, e.g., ¶71, “Tags are placed, for example, at each entry point and each exit point within a function in the program …” See also, e.g., ¶72, “Each tag has a progression point and a checkpoint”) for the purpose of facilitating the identification of a point of failure in source code by including checkpointing and replay capabilities for code debugging (Randimbivololona, e.g., ¶¶71-82).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for user-defined checkpointing of code as taught by Deconinck to provide that the block includes an entire function because the disclosure of Randimbivololona shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for checkpointing and debugging aircraft program code to provide that the block includes an entire function for the purpose of facilitating the identification of a point of failure in source code by including checkpointing and replay capabilities for code debugging (Randimbivololona, Id.).
Regarding claim 17, the rejection of claim 11 is incorporated, but Deconinck does not more particularly teach that the block includes multiple functions. However, Randimbivololona does teach: wherein the block includes multiple functions (Randimbivololona, e.g., ¶71, “Tags are placed, for example, at each entry point and each exit point within a function in the program …” See also, e.g., ¶72, “Each tag has a progression point and a checkpoint.” Examiner’s note: functions can include calls to other functions, and therefore at least some tag groupings will include multiple function calls) for the purpose of facilitating the identification of a point of failure in source code by including checkpointing and replay capabilities for code debugging (Randimbivololona, e.g., ¶¶71-82).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method for user-defined checkpointing of code as taught by Deconinck to provide that the block includes multiple functions because the disclosure of Randimbivololona shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for checkpointing and debugging aircraft program code to provide that the block includes multiple functions for the purpose of facilitating the identification of a point of failure in source code by including checkpointing and replay capabilities for code debugging (Randimbivololona, Id.).
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Examiner, Art Unit 2191