DETAILED ACTION
Claims 1-4, 6-14, and 16-20 are pending. Claims 1 and 11 are in independent form. This Office action is FINAL.
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 § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1, 3-4, 6-11, 13-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2018/0150501 to Hattori (“Hattori”) in view of U.S. Publication No. 2017/0315882 to Yammine et al. (“Yammine”) in view of U.S. Publication No. 2016/0357464 to Suzuki et al. (“Suzuki”).
Regarding Claim 1, Hattori teaches:
A data recovery method, comprising:
determining first data, containing application data generated when an application program runs normally (Hattori: Paragraph [0071], “For example, during normal operation, the recovery unit 77 periodically acquires an image of the database stored in the data storage 61 and stores the image in a nonvolatile storage device, for example”);
storing the first data in a handle record, that is managed using a reference count mechanism, wherein the reference count mechanism stores a quantity of times that a resource is referenced, and wherein the storing the first data in the handle record comprises storing the first data in at least one layer comprising at least one bucket (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”; wherein the quantity of times for the reference count is the operations with timestamps being stored prior to the failover time); and
when the application program is unexpectedly restarted, obtaining the handle record and restoring the application program, based on the handle record, to a status before the application program is unexpectedly restarted (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
However, Hattori does not appear to teach:
storing, by an activity manager service (AMS), the first data in a handle record,
wherein the AMS is a system process, the first data is carried by Intent of the AMS.
However, in the same field of endeavor, Yammine teaches:
storing, by an activity manager service (AMS), the first data in a handle record (Yammine: Paragraph [0041], “A transaction group describes a set of one or more operations that are to be processed as a single transaction work unit (i.e., processed atomically) when executed with respect to backend object storage. The records generated by intent log writer 318 are self-describing, including the operations and data to be written, thus enabling recovery of the data as well as the object storage state via replay of the operations. Intent log writer 318 uses catalog 316 to reference file data that may be stored in extent storage 309 that is managed by the local file system. For example, if an update operation includes user data (i.e., object data content), then the data may be committed (if not already committed) to extent storage 309”),
wherein the AMS is a system process, the first data is carried by Intent of the AMS (Yammine: Paragraph [0041], “A transaction group describes a set of one or more operations that are to be processed as a single transaction work unit (i.e., processed atomically) when executed with respect to backend object storage. The records generated by intent log writer 318 are self-describing, including the operations and data to be written, thus enabling recovery of the data as well as the object storage state via replay of the operations. Intent log writer 318 uses catalog 316 to reference file data that may be stored in extent storage 309 that is managed by the local file system. For example, if an update operation includes user data (i.e., object data content), then the data may be committed (if not already committed) to extent storage 309”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Hattori by storing data using intents by a system process, as taught by Yammine. One of ordinary skill in the art would have been motivated to make this modification because the system can benefit from the methods of Yammine by improving performance and reducing latency. (Yammine: Paragraph [0020]).
However, the Hattori/Yammine combination does not appear to teach:
process configured to perform at least one of starting, switching, or scheduling at least one of an activity, a service, a broadcast receiver, or a content provider, and also manage and schedule an application process.
However, in the same field of endeavor, Suzuki teaches:
process configured to perform at least one of starting, switching, or scheduling at least one of an activity, a service, a broadcast receiver, or a content provider, and also manage and schedule an application process (Suzuki: Paragraph [0059], “The server configuration information acquisition processing unit 214 acquires internal configuration information of the application servers 300. The integrated configuration information acquisition processing unit 215 generates information associating an application, an LU, and a scheduled application execution period with each other based on information acquired by the respective processing units 211 to 215 described above”; wherein scheduling an application process is also interpreted as scheduling an activity or service and Suzuki teaches generating scheduling information for scheduling an application).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Hattori/Yammine combination by scheduling application processes, as taught by Suzuki. One of ordinary skill in the art would have been motivated to make this modification because the system can benefit from the methods of Suzuki by improving efficiency of scheduling. (Suzuki: Paragraph [0146]).
Regarding claim 3, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 1 and further teaches:
wherein managing the handle record using a reference count mechanism comprises:
referencing the handle record by using a first system interface (Hattori: Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 4, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 3 and further teaches:
wherein the referencing the handle record by using the first system interface comprises:
setting a scheduled job for the handle record, wherein the scheduled job comprises a one-time job or a periodic job (Hattori: Paragraph [0093], “When the image of the database stored in the data storage 61 is periodically acquired and stored in, for example, a nonvolatile storage device, the recovery unit 77 also reads the image of the latest database. In this case, the recovery unit 77 only needs to read the later log from the time of capturing the latest database image”); or
setting a trigger condition for the handle record; or
setting a notification job for the handle record, wherein the notification job comprises a persistent notification or a non-persistent notification.
Regarding claim 6, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 1 and further teaches:
wherein the method further comprises:
establishing a bucket-based mapping tabl(Hattori: Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 7, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 6 and further teaches:
wherein the bucket addressing comprises:
a bucket number identifying a bucket allocated to the first data, or
a combination of the bucket number and a bucket key value that identifies a location of the first data in the bucket (Hattori: Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 8, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 3 and further teaches:
wherein the referencing the handle record by using the first system interface comprises:
referencing, by using the first system interface, a topmost layer of the first data stored in the at least one layer comprising the at least one bucket (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 9, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 6 and further teaches:
wherein the method further comprises:
when the application program runs normally, updating or deleting the first data based on the bucket-based mapping table, to keep the first data consistent with application data in the application program running in a latest status (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 10, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 1 and further teaches:
wherein when the application program is unexpectedly restarted, the obtaining the handle record and restoring the application program comprises:
obtaining the handle record of the application program by using a second system interface based on an application identifier, that is used to identify the application program (Hattori: Paragraph [0065], “when changing the database according to the operation information received from the client device 50, the operation unit 72 causes the identifier memory unit 62 to store the identifier of the operation information. Further, when receiving the operation information from the client device 50, the operation unit 72 checks whether or not the identifier of the operation information received from the client device 50 is stored in the identifier memory unit 62. When the identifier of the operation information received from the client device 50 is stored in the identifier memory unit 62, the operation unit 72 does not change the database according to the received operation information. In addition, the operation unit 72 deletes from the identifier memory unit 62 the identifier of the operation information received before the time point a predetermined time before the present time. Here, the fixed time is the failover time”; Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”); and
parsing the handle record, and recovering data in the handle record to the application program (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 11, Hattori teaches:
A terminal, comprising;
a memory configured to store a computer program (Hattori: Paragraph [0129], “The program executed by the server device 30 has a module configuration including an operation reception module, an operation module, a log processing module, a first replication module, a result transmission module, a second replication module, and a recovery module. This program is developed and executed on the RAM 202 by the CPU 201 (processor), thereby causing the information processing device 200 to function as the operation receiver 71, the operation unit 72, the log processor 73, the first replication unit 74, the result transmitter 75, the second replication unit 76, and the recovery unit 77. Note that the server device 30 is not limited to such a configuration, and may be a configuration in which at least a part of the operation receiver 71, the operation unit 72, the log processor 73, the first replication unit 74, the result transmitter 75, the second replication unit 76, and the recovery unit 77 is implemented by a hardware circuit (for example, a semiconductor integrated circuit)”); and
a processor configured to invoke the computer program from the memory and run the computer program to perform a method (Hattori: Paragraph [0129], “The program executed by the server device 30 has a module configuration including an operation reception module, an operation module, a log processing module, a first replication module, a result transmission module, a second replication module, and a recovery module. This program is developed and executed on the RAM 202 by the CPU 201 (processor), thereby causing the information processing device 200 to function as the operation receiver 71, the operation unit 72, the log processor 73, the first replication unit 74, the result transmitter 75, the second replication unit 76, and the recovery unit 77. Note that the server device 30 is not limited to such a configuration, and may be a configuration in which at least a part of the operation receiver 71, the operation unit 72, the log processor 73, the first replication unit 74, the result transmitter 75, the second replication unit 76, and the recovery unit 77 is implemented by a hardware circuit (for example, a semiconductor integrated circuit)”), the method comprising:
determining first data containing application data generated when an application program runs normally (Hattori: Paragraph [0071], “For example, during normal operation, the recovery unit 77 periodically acquires an image of the database stored in the data storage 61 and stores the image in a nonvolatile storage device, for example”);
storing the first data in a handle record that is managed by using a reference count mechanism, wherein the reference count mechanism stores a quantity of times that resource is referenced, and wherein the storing the first data in the handle record comprises storing the first data in at least one layer comprising at least one bucket (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”; wherein the quantity of times for the reference count is the operations with timestamps being stored prior to the failover time); and
when the application program is unexpectedly restarted, obtaining the handle record and restoring the application program, based on the handle record, to a status before the application program is unexpectedly restarted (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
However, Hattori does not appear to teach:
wherein the first data is carried by Intent of activity manager service (AMS), the AMS is a system program.
However, in the same field of endeavor, Yammine teaches:
wherein the first data is carried by Intent of activity manager service (AMS), the AMS is a system program (Yammine: Paragraph [0041], “A transaction group describes a set of one or more operations that are to be processed as a single transaction work unit (i.e., processed atomically) when executed with respect to backend object storage. The records generated by intent log writer 318 are self-describing, including the operations and data to be written, thus enabling recovery of the data as well as the object storage state via replay of the operations. Intent log writer 318 uses catalog 316 to reference file data that may be stored in extent storage 309 that is managed by the local file system. For example, if an update operation includes user data (i.e., object data content), then the data may be committed (if not already committed) to extent storage 309”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by Hattori by using intents to store data by a system process, as taught by Yammine. One of ordinary skill in the art would have been motivated to make this modification because the system can benefit from the methods of Yammine by improving performance and reducing latency. (Yammine: Paragraph [0020]).
However, the Hattori/Yammine combination does not appear to teach:
process configured to perform at least one of starting, switching, or scheduling at least one of an activity, a service, a broadcast receiver, or a content provider, and also manage and schedule an application process.
However, in the same field of endeavor, Suzuki teaches:
process configured to perform at least one of starting, switching, or scheduling at least one of an activity, a service, a broadcast receiver, or a content provider, and also manage and schedule an application process (Suzuki: Paragraph [0059], “The server configuration information acquisition processing unit 214 acquires internal configuration information of the application servers 300. The integrated configuration information acquisition processing unit 215 generates information associating an application, an LU, and a scheduled application execution period with each other based on information acquired by the respective processing units 211 to 215 described above”; wherein scheduling an application process is also interpreted as scheduling an activity or service and Suzuki teaches generating scheduling information for scheduling an application).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Hattori/Yammine combination by scheduling application processes, as taught by Suzuki. One of ordinary skill in the art would have been motivated to make this modification because the system can benefit from the methods of Suzuki by improving efficiency of scheduling. (Suzuki: Paragraph [0146]).
Regarding claim 13, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 11 and further teaches:
wherein managing the handle record
referencing the handle record by using a first system interface (Hattori: Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 14, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 13 and further teaches:
wherein the referencing the handle record by using the first system interface comprises:
setting a scheduled job for the handle record, wherein the scheduled job comprises a one- time job or a periodic job (Hattori: Paragraph [0093], “When the image of the database stored in the data storage 61 is periodically acquired and stored in, for example, a nonvolatile storage device, the recovery unit 77 also reads the image of the latest database. In this case, the recovery unit 77 only needs to read the later log from the time of capturing the latest database image”); or
setting a trigger condition for the handle record; or
setting a notification job for the handle record, wherein the notification job comprises a persistent notification or a non-persistent notification.
Regarding claim 16, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 11 and further teaches:
wherein the storing further comprises:
establishing a bucket-based mapping table comprising a correspondence between a keyword uniquely identifying the first data and bucket addressing pointing to a storage location of the first data, wherein the bucket-based mapping table is used to find a storage location of the first data in a bucket based on the keyword when data is updated or deleted (Hattori: Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 17, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 16 and further teaches:
wherein the bucket addressing comprises:
a bucket number, or
a combination of the bucket number identifying a bucket allocated to the first data and a bucket key value identifying a location of the first data in the bucket (Hattori: Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 18, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 13 and further teaches:
wherein the referencing the handle record by using a first system interface comprises:
referencing, by using the first system interface, a topmost layer of the first data stored in the at least one layer comprising the at least one bucket (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 19, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 16 and further teaches:
wherein the method further comprises:
when the application program runs normally, updating or deleting the first data based on the bucket-based mapping table, to keep the first data consistent with application data in the application program running in a latest status (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Regarding claim 20, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 11 and further teaches:
wherein when the application program is unexpectedly restarted, the obtaining the handle record and restoring the application program comprises:
obtaining the handle record of the application program by using a second system interface based on an application identifier that is used to identify the application program (Hattori: Paragraph [0065], “when changing the database according to the operation information received from the client device 50, the operation unit 72 causes the identifier memory unit 62 to store the identifier of the operation information. Further, when receiving the operation information from the client device 50, the operation unit 72 checks whether or not the identifier of the operation information received from the client device 50 is stored in the identifier memory unit 62. When the identifier of the operation information received from the client device 50 is stored in the identifier memory unit 62, the operation unit 72 does not change the database according to the received operation information. In addition, the operation unit 72 deletes from the identifier memory unit 62 the identifier of the operation information received before the time point a predetermined time before the present time. Here, the fixed time is the failover time”; Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”); and
parsing the handle record, and recovering data in the handle record to the application program (Hattori: Paragraph [0071], “When restart is performed, the recovery unit 77 reads the image of the database at the time point closest to the failure occurrence point and stores the image in the data storage 61. Subsequently, the recovery unit 77 reads from the log storage 63 the log after the image is acquired, and restores the database to the point immediately before the failure occurrence based on the read log”; Paragraph [0082], “If the identifier of the received operation information is not stored in the identifier memory unit 62 (No in S52), the operation unit 72 causes the identifier memory unit 62 to store the identifier of the received operation information (step S53). In this case, the operation unit 72 attaches the time information to the identifier. The time is, for example, the time when operation information is received. As a result, the operation unit 72 can delete from the identifier memory unit 62 the identifier received at the time point before the start of the failover time”; and Paragraph [0084], “the log processor 73 generates a log of the change of the database caused by the operation of the database (step S55). In this case, the log processor 73 adds the identifier of the operation information to the log of the change of the database. Then, the log processor 73 causes the log storage 63 to store the log to which the identifier is added”).
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Hattori in view of Yammine in view of Suzuki and further in view of U.S. Patent No. 7,640,454 to Botes (“Botes”).
Regarding claim 2, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 1. However, the combination does not appear to explicitly teach:
wherein the first data is volatile data that is not stored in a memory of an external storage device in a serialization manner.
However, in the same field of endeavor, Botes teaches:
wherein the first data is volatile data that is not stored in a memory of an external storage device in a serialization manner (Botes: Col. 2, lines 27-31, “A subset of this configuration information is dynamically maintained in volatile storage. Recovery software is configured to retain a previous state of the dynamically maintained configuration information by storing the previous state in persistent storage”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Hattori/Yammine/Suzuki combination by having the first data as volatile data and not storing it externally in a serialization manner, as taught by Botes. One of ordinary skill in the art would have been motivated to make this modification because the system can benefit from the methods of Botes by increasing reliability and improving the ability to restore from an undesirable state or suboptimal state. (Botes: Col. 1, lines 50-67 and Col. 2, lines 1-11).
Regarding claim 12, the Hattori/Yammine/Suzuki combination teaches all of the elements of claim 11. However, the Hattori/Yammine/Suzuki combination does not appear to explicitly teach:
wherein the first data is volatile data that is not stored in a memory of an external storage device in a serialization manner.
However, in the same field of endeavor, Botes teaches:
wherein the first data is volatile data that is not stored in a memory of an external storage device in a serialization manner (Botes: Col. 2, lines 27-31, “A subset of this configuration information is dynamically maintained in volatile storage. Recovery software is configured to retain a previous state of the dynamically maintained configuration information by storing the previous state in persistent storage”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method taught by the Hattori/Yammine/Suzuki combination by having the first data as volatile data and not storing it externally in a serialization manner, as taught by Botes. One of ordinary skill in the art would have been motivated to make this modification because the system can benefit from the methods of Botes by increasing reliability and improving the ability to restore from an undesirable state or suboptimal state. (Botes: Col. 1, lines 50-67 and Col. 2, lines 1-11).
Response to Arguments
Applicant’s arguments, see pages 7-11, filed 03/18/2025, with respect to the 103 rejections have been fully considered and are persuasive in light of new amendments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly found prior art that is pertinent to the new amendments made. As for the layer and bucket argument the Examiner was not persuaded and the rejection seen in claim 5 regarding the amendments are applied. Specifically, the Applicant broadens the element of claim to store data in at least one layer and at least one bucket. Broadly speaking that can be interpreted as any storage device that is striped. A bucket can broadly be a single data cell. A layer can be broadly interpreted as an array of memory. It is very broadly interpreted as written. Therefore, the rejection towards this element is still taught by Hattori.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (US 7103740 B1 and US 20250173450 A1).
US 7103740 B1: System and method for performing backups of a multi-class file system are described. In one embodiment, more recently modified data may be assigned and/or migrated to higher storage classes and less recently modified data may be migrated at time intervals to lower storage classes in the multi-class file system. Backups of each of the storage classes may be performed at time intervals. In one embodiment, the backups may be image-based backups of the storage devices in the storage classes. In one embodiment, the lower storage classes may include one or more read-only storage classes including less-recently modified data that are backed up less frequently than higher storage classes including more-recently modified data. In one embodiment, files migrated to lower storage class(es) may be compressed.
US 20250173450 A1: In some embodiments a running instance of a multi-tenant SaaS application may send different requests associated with different tenants. For example, a first tenant may request train scheduling application to plan a first trip leaving from a first location at a first time, and a second tenant may request the train scheduling application to plan a second trip leaving from a second location at a second time. To allow distinguishing between multiple differing requests, a request from a running instance of a multi-tenant SaaS application for data access may use a token, e.g., to identify the tenant associated with the request.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Matthew N Putaraksa whose telephone number is (303)297-4365. The examiner can normally be reached on Monday-Thursday 7:00am-5:00pm MT.
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, Matt Kim can be reached on 571-272-4182. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/MATTHEW N PUTARAKSA/Examiner, Art Unit 2114 /BRYCE P BONZO/Supervisory Patent Examiner, Art Unit 2113
Prosecution Insights