DETAILED ACTION
Claims 19-25 were previously restricted, and are now canceled. Applicant elected claims 1-18 (without traverse). Claims 30-33, 35 are canceled.
Claims 1, 3-5, 7, 9-11, 13, 15-17, 26-29, 34 are amended.
Claims 1-18, 26-29, 34 are pending.
Priority: 1/21/2022
Assignee: International Business Machines
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after allowance or after an Office action under Ex Parte Quayle, 25 USPQ 74, 453 O.G. 213 (Comm'r Pat. 1935). Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, prosecution in this application has been reopened pursuant to 37 CFR 1.114. Applicant's submission filed on 1/23/2026 has been entered.
Election/Restrictions
Newly submitted claim(s) 36-37 are directed to an invention that is independent or distinct from the invention originally claimed for the following reasons:
Claim 36 (and 37) recites, ‘broadcasting, from a backup data storage site to at least one other backup data storage site, metadata…’.
Fig. 2 belongs to the elected group (claims 1-18). And Fig. 2, Para-0047 of the spec recites, ‘Processing proceeds to operation S270, where point in time copy information broadcasting mod 308 broadcasts point in time copy information among the data backup sites’. As recited, the broadcasting method in the elected group is from broadcasting mod 308 to the backup sites.
Furthermore, Para-0047 recites that ‘information’ is broadcasted, not metadata. The broadcasting mod 308 is not a backup site. Fig. 3 shows Program 300 which includes broadcasting mod 308. According to Fig. 1, Program 300 is included in data protection distribution subsystem 102 which is communicatively coupled via network 114 to the backup sites.
On the other hand, in claim 36, the broadcasting method is from one backup site to another backup site. And ‘metadata’ is broadcasted. This method of broadcast is different from the method recited in the elected group. The method of broadcast recited in claims 36-37 is similar to claim 21 (non-elected group, claims 19-25).
Since applicant has received an action on the merits for the originally presented invention, this invention has been constructively elected by original presentation for prosecution on the merits. Accordingly, claim(s) 36-37 are withdrawn from consideration as being directed to a non-elected invention. See 37 CFR 1.142(b) and MPEP § 821.03.
To preserve a right to petition, the reply to this action must distinctly and specifically point out supposed errors in the restriction requirement. Otherwise, the election shall be treated as a final election without traverse. Traversal must be timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are subsequently added, applicant must indicate which of the subsequently added claims are readable upon the elected invention.
Should applicant traverse on the ground that the inventions are not patentably distinct, applicant should submit evidence or identify such evidence now of record showing the inventions to be obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
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.
Claim(s) 1-18, 26-29, 34 are 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.
1.Claim 1 is rejected for reciting a limitation with antecedent basis issues.
Amended Claim 1 recites, ‘….within data storage repositories of a backup data storage site’, and further recites, ‘….record the complete copy of the volume at a backup data storage site at least once…’. Here, ‘… a backup data storage site…’ has been already introduced.
1.Amended Claim 1 is rejected for being unclear, inconsistent and indefinite.
Amended Claim 1 recites, ‘….a complete copy of the volume within data storage repositories of a backup data storage site’. The spec does not recite this limitation. The spec does not define ‘data storage repositories of a backup data storage site’.
Spec, Para-0053 recites, ‘….having PiT consistent back-up copies saved in different storage systems repositories distributed in two or more sites and or regions….’. The claimed limitation being unclear, is indefinite.
Hence claim 1 is rejected. For examination, the spec is used.
2.Amended Claim 1 is rejected for reciting a limitation that is unclear, ambiguous and indefinite.
Amended Claim 1 recites, ‘the set of backup data storage sites comprises at least two backup data storage sites’, ‘wherein a first backup storage site stores a first complete copy of the volume at a first specified time and a second backup storage site stores a second complete copy of the volume at a second specified time’.
The spec does not recite this limitation.
In addition to being unmoored from the spec, the limitation recites an ambiguous scope.
The limitation is ambiguous and the ambiguity arises from the interaction between sequential rotation and the timing of the first backup.
If sequential rotation means the sites switch roles (e.g., Site A is ‘first’ in week 1, Site B is ‘first’ in week 2, it is unclear if ‘first’ refers to a specific physical location or the chronological order of the backup in the sequence.
If the sites swap roles, it is ambiguous whether a ‘first (physical) backup storage site’ always refers to the same physical hardware, or if it refers to the primary site in the current rotation.
If the rotation is sequential (e.g., A, then B, then A), a ‘first specified time’ might correspond to Site A in one scenario and Site B in another, creating a circular or conflicting definition.
Since the limitation is unclear regarding the temporal state and location of the most current backup, the limitation leads to uncertainty in the claim scope. Hence claim 1 is rejected. Claims 7,13 have the same issue.
3.Amended Claim 1 is rejected for being unclear, repetitive and indefinite.
Amended Claim 1 recites, ‘(iii)the backup data storage site selected at each specified time is determined based on a sequential rotation among the set of backup data storage sites to record the complete copy of the volume at a backup data storage site at least once per the specified time’.
This recitation is unclear.
Since the claim already recites, ‘periodically storing, at each of the specified times, a complete copy….within ….a backup data storage site selected from a set of backup data storage sites, and (i)…., (ii)…’, the last, limitation, namely (iii), is not clear and concise.
The limitation (iii) does not distinctly claim the subject matter. The repetitive, circular verbiage adds unnecessary bulk, without enhancing clarity, value or impact. Hence claim 1 is rejected for reciting a limitation with unnecessary verbosity thereby making the scope of claim 1 uncertain with respect to the spec. Claims 7,13 have the same issue.
4.Amended Claims 26,27,28 are rejected for reciting a limitation that is unclear, ambiguous and indefinite.
Amended Claim 26 recites, ‘….wherein…. rotating….between the first backup storage site….at a first specified time of the specified times, the second backup storage site at a second specified time of the specified times….’.
The spec does not recite this limitation.
The phrase ‘at a first specified time of the specified times’ is unclear because it does not clearly define which ‘specified time’ is being used, nor does it distinguish ‘a first’ from the other ‘specified times’ mentioned in independent claim 1.
The phrase ‘a first specified time of the specified times’ creates an ambiguity regarding whether it refers to the first in time (e.g., the earliest snapshot), or a single arbitrary snapshot selected from the set of snapshot times, leading to uncertainty about the claim scope.
The phrases, 'at a second specified time of the specified times' and ‘at a third specified time of the specified times' have the same issues.
If the ‘sequential rotation’ between sites (1, 2, 3) must happen at specific times (T1, T2, T3) that do not logically match the actual times the snapshots are taken, the claim is indefinite. The ‘sequential rotation’ implies a specific order (1-to-2-to-3), but if the ‘specified times’ do not correspond directly to the snapshot intervals, it is unclear when or how the rotation occurs relative to the data backup.
The phrases, 'at a second specified time of the specified times' and ‘at a third specified time of the specified times' have the same issues.
Hence claim 26 being unclear is indefinite and is rejected. Claims 27,28 have the same issue.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-18, 26-29, 34 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
1.Amended Claims 1,7,13 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘monitoring a volume at a first data storage site for periodic point in time copying, where the periodic point in time copying comprises recording snapshots of the volume at specified times
separated by a specified period of time’.
The limitation discloses dynamic activity(active task of snapshotting/recording the data state), as it occurs repeatedly over time as the data in the volume changes due to application writes.
The limitation recites, however, the functional result of ‘recording’ without describing the necessary structure or steps to achieve that result. The spec only describes the function at a high level of generality, failing to teach how to implement the specific function. A one-line recitation in the spec does not fulfill the written description requirement.
The limitation suggests a snapshot scheduling algorithm. But the spec does not disclose the steps of the algorithm as it applies to the disclosure.
There is no definition of the ‘monitor’ (H/W or S/W components responsible for monitoring). Though the spec makes a passing reference to ‘mod 302’ as the monitoring module, adequate description of the monitoring module identifying and tracking the specific volume/LUN to be monitored for I/O operation(s), is missing. How the monitoring module initiates the snapshot at the exact moment required by the specified period, is missing.
A diagram detailing how the snapshots are recorded and how they are stored is missing. There is no flowchart showing how the ‘periodic’ aspect is managed (e.g., triggering a snapshot based on a timer, a scheduler, or a policy engine). There is no disclosure of how the ‘specified times’ (e.g. start recording at 2:00 AM) and ‘separated by….specified period of time’ (the interval between recordings, such as every day) are defined, stored, and updated. More importantly, a table structure showing how the system records PiT information (e.g., snapshot IDs, timestamps, and pointers to changed data blocks), is undisclosed. Snapshot schedule status and snapshot transfer status are undisclosed.
Accordingly, the claim recites a scope unsupported by the spec, making the limitation overly broad and encompassing subject matter not described. This shows that the applicant's possession of the limitation, at the time of filing was incomplete. Hence claim 1 is rejected. Claims 7,13 have the same issue. See MPEP 2161.01
2.Amended Claims 1,7,13 is rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 1 recites, ‘periodically storing, at each of the specified times, a complete copy of the volume within….a backup…site….’. The spec does not recite this limitation.
Para-0004 of the spec recites, ‘periodically storing ….a ….copy’. And Para-0015 recites, ‘For a monitored volume,….periodic point in time copies are recorded upon data storage capabilities of rotating backup data storage sites as each period elapses’.
‘Periodically storing at each of the specified times’ implies a rigid, predetermined schedule where exact, known intervals are documented and followed (e.g., store every day at 03:00 AM). ‘Periodically storing’ refers to a more general, regular, or even irregular, repeated action without necessarily detailing the precise timing of each interval (e.g., store every 4 hours).
The spec does not recite that recording the snapshot at the first data storage site and the storing the backup at the backup site are strictly linked in time. In fact, Fig. 1 and Para-0033 of the spec disclose synchronous and asynchronous backups. Therefore, reciting ‘….each of the specified times’ is an unverified extrapolation.
It is well-known in the art that a snapshot is a point-in-time copy of a volume. It is not a full backup, and only stores changes.
The claim recites, ‘recording snapshots of the volume….’, and then recites ‘periodically ….storing a complete copy at a backup site’. The spec does not describe in detail how snapshots recorded at the primary site become ‘a complete copy’ at the backup site. The contents transferred to the backup site are undisclosed. No steps to reconstruct ‘a complete copy’ of the volume at the backup site, are disclosed. This lack of disclosure suggests lack of possession of the limitation.
The limitation recites a scope unsupported by the spec. Hence Claim 1 is rejected because the spec does not convey possession of the claimed scope. Claims 7,13 have the same issue.
3.Claims 5,11,17 are rejected for reciting limitations that are unsupported by the spec.
Claim 5 recites, ‘the set of backup data storage sites includes at least three backup storage sites; there are at least three subsets of backup data storage site(s), with each subset including a unique combination of at least two of the backup data storage sites of the set of backup data storage sites but fewer than the entire set of backup data storage sites, where each backup data storage site records a complete…copy….for a given period’.
The claim recites a combination generation algorithm. The spec recites the desired result (combining sites for recovery) without describing the structure (the algorithm) necessary to achieve that result.
Spec, Para-0044 recites ‘In the event of one of the three data backup sites experiencing a failure, there is only a one in three chance that it is at the data backup site with the most recent point in time copy….’. These few lines recite a high level conceptual goal for disaster recovery rather than a detailed description showing the applicant possessed a specific way to generate these unique combinations.
According to the spec, disaster recovery is crucial. So the algorithm is an important feature of the invention. There are many 3-element combination algorithms. But for computer-implemented functions, as recited in Claim 5, the spec does not recite a flowchart, diagram or pseudo-code, in enough detail to show the inventor was in possession of a specific way of combining backup sites, at the time of filing.
In addition, the limitation, ‘where each backup data storage site records a complete copy of the monitored volume for a given period’, refers to a rotation algorithm. Furthermore, as mentioned above, there is no written description regarding the re-construction of the complete copy stored at each selected backup site.
In summary, the claim uses a combination algorithm, a rotation algorithm and complete copy reconstruction algorithm. But the spec fails to disclose the specific steps, formulas, or logic of these algorithms, providing only a functional description of the desired results. Consequently, the spec does not demonstrate that the applicant was in possession of the limitations at the time of filing.
Hence claim 5 is rejected for reciting limitations that are unsupported by the spec. Claims 11,17 have the same issue.
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.
Claims 1-2,4,7-8,10,13-14,16,29 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Dain et al (20150286542) in view of Kitamura (20060218364), and Tsaur et al (9880776).
As per Claim 1, Dain discloses a computer-implemented method (CIM) (Dain, [0005 - A method is provided for efficient FlashCopy backup target volume allocation with reuse and a shared resource pool/set using a processor device in a computing environment]) comprising:
monitoring a volume (Dain, [0079 - Fig. 4: production volume P in a SAN volume controller/SVC]) at a first data storage site for periodic point in time copying (Dain, [0081 - Production volume P can be changing due to writes from the host]), where the periodic point in time copying comprises recording snapshots of the volume (Dain, [0034 - A snapshot is a PiT copy where the target only holds the changed data necessary to present the PiT copy of the source/volume]) at specified times separated by a specified period of time (Dain, [0030 - The FlashCopy function enables an administrator to make point-in-time, full/complete volume copies of data]; [0031- FlashCopy is used for creating recovery points that are application consistent point in time copies of the production data, thereby implying recording snapshots by monitoring production data/volume]);
periodically storing (Dain, [0079 - Flashcopy backups of the production volume P, e.g., a source 402, are scheduled periodically]), at each of the specified times (Dain, [0081 - IBM Tivoli FlashCopy manager schedules application consistent snapshot backups]; [0035 - With a data source S and PiT copies of S taken at times t1, t2, then at time t1, a PiT copy/complete is taken using data target T1 resulting in a cascade: S→T1. Then at time t2 there is taken a second PiT copy using data target T2 and resulting in the cascade: S→T2→T1]), a complete copy of the volume (Dain, [0030 - A FlashCopy function creates a copy of a source volume on a target volume. This copy is called a point-in-time copy or complete copy. When a FlashCopy operation is initiated, a relationship is created between a source volume and target volume. This relationship is a mapping of the source volume and the target volume. This mapping allows a point-in-time copy/complete of that source volume to be copied to the associated target volume, thereby implying that ‘complete copy’ is a full backup or initial backup corresponding to the first snapshot]; [0082 - The storage controller creates an initial data reduced full copy of the production volume in a repository using data reduction techniques such as data deduplication and IBM RTC. The deltas/incrementals between subsequent snapshots are deduplicated and compressed using RTC to minimize capacity and extend the amount of FlashCopy restore points retained in the repository, thereby implying combining the initial full copy/backup and incremental backups due to the snapshots, as a complete copy. Since the claim does not recite how a ‘complete copy’ is reconstructed at the backup site, the citation is a valid interpretation]) within data storage repositories of a backup data storage site (Dain, [0079 - When a Flashcopy backup of P, e.g., the source 402, is initiated at time T0 within the SVC, a space efficient FlashCopy target volume T0 is created. This is signified by the notation P→T0/mapping, implying an instantaneous backup at the selected backup site at the specified time]) selected from a set of backup data storage sites (Dain, [0098 – In Fig. 13, step 1302 begins by maintaining a global pool/set of FlashCopy backup target volumes]; [0079 - As long as the space-efficient source and target volumes have been created and are available, they can be selected when the Flashcopy relationship is created]; [0073 – In Fig. 3, storage 330a,330b….330n are shown as ranks in data storage system 300. Ranks may be local to data storage system 300, or may be located at a physically remote location]),
Neither the claim nor the spec disclose the monitoring process to record snapshots.
Kitamura discloses,
monitoring a volume (Kitamura, [0064 - In Fig. 8, step 1001, the write observing process begins monitoring I/O in host 1. When the host issues a write operation, the processing proceeds to Step 1002]; [0065 - In Step 1002, the target logical volume associated with the write operation is identified]) at a first data storage site (Kitamura, [0027 - In Fig. 1, I/O requests are r/w requests from the host. A volume manager process 232 performs the operations to create and manage a logical volume. A snapshot process 233 performs the operations to create and manage snapshot volumes; It is well known that a snapshot volume is a PiT image of a storage volume that records the state of data at a specific moment or a complete copy]) for periodic point in time copying (Kitamura, [0029 - The snapshot function creates a virtual snapshot volume/S-VOL of a PiT snapshot of a selected logical volume/P-VOL/primary volume]),
where the periodic point in time copying comprises recording snapshots of the volume at specified times (Kitamura, [0054 – In Fig. 5, each row in the table represents information for a snapshot generation. BLOCKS field 553 indicates a number of snapshot blocks that were copied during a period of time. Time1 field 551 indicates the beginning time of the period, and Time2 field 552 indicates the end time of the period]) separated by a specified period of time (Kitamura, [0048 – In Fig. 6, INTERVAL field 605 indicates how often a snapshot is to be taken]);
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the volume monitoring of Kitamura into the the efficient FlashCopy backup of Dain, Kitamura for the benefit of creating a snapshot volume which is a the volume where the data image at a certain point-in-time is preserved is frequently used in many storage systems, since the snapshot enables users to backup data on a live system concurrently when host I/O is online (Kitamura, 0002).
Tsaur discloses,
where,
(i) the set of backup data storage sites comprises at least two backup data storage sites (Tsaur, [Fig. 1: 160A, 160B]),
(ii) one backup data storage site from the set of backup data storage sites is selected at each specified time (Tsaur, [Col. 8, lines 55-58 – In Fig. 3, step 501, backup software 50 determines which of the plurality of backup storage devices 160 is the target backup storage device for the current backup operation]),
(iii) the backup data storage site selected at each specified time is determined based on a sequential rotation among the set of backup data storage sites (Tsaur, [Col. 9, lines 2-5 - The backup software assigns a circular order/sequence to the backup storage devices, and each time a new backup operation is performed, the next backup storage device in the order is selected as the backup storage device]) to record the complete copy of the volume (Tsaur, [Col. 9, lines 19-23 – In Fig. 3, step 502, the backup software determines what type of backup operation the current backup operation is specified by the backup schedule for the current time]; [Col. 9, lines 23-26 – In Fig. 3, step 503, if the current backup operation is a full backup operation then the backup software creates a new full backup/complete copy data set and store it on the target backup storage device; This is the initial full backup of first snapshot which is stored as the complete copy]; [Col. 9, lines 28-32 - If the current backup operation is an incremental backup operation then the backup software determines whether the target backup storage device already has a full backup data set stored on it. If not then the backup software create a new full backup data set and store it on the target backup storage device in step 505]; [Col. 9, lines 36-56 - If the target backup storage device already has a full backup data set stored on it then the backup software performs steps 507, 509; At step 509, the new incremental backup data set is stored. So the complete copy is the combination of the initial full backup and the incremental backup of the second snapshot]) at a backup data storage site at least once per the specified time (Tsaur, [Col. 3, lines 27-32 - If there are two backup storage devices, then a first backup operation creates a first backup data set on the first backup storage device, and the next backup operation creates a second backup data set on the second backup storage device. This cycle then repeats because of the round-robin algorithm, thereby implying that the complete copy is recorded at a backup site at least once per the specified time; Here, ‘at least once’ means that with two backup sites, the backup software simply alternates between Site A and Site B for each sequential rotation, guaranteeing that a complete copy lands at each site during every other cycle]),
wherein a first backup storage site stores a first complete copy of the volume at a first specified time (Tsaur, [Claim 1 - Create a first backup of a data set to form a first backup data set on a first storage device at a first point in time]; [Fig. 3]) and a second backup storage site stores a second complete copy of the volume at a second specified time (Tsaur, [Claim 1 - Create a second backup of the data set to form a second backup data set on a second storage device at a second point in time after the first point in time]; [Fig. 3]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the sequential rotation of Tsaur into the efficient FlashCopy backup of Dain, Kitamura for the benefit of having each of the backup data sets on any given backup storage device be independent from the backup data sets on the other backup storage device. Thus, if one of the backup storage devices fails, then any of the backup data sets on the other backup storage device can still be used to perform a complete recovery of the data objects (Tsaur, Col. 3, lines 43-49).
As per Claim 2, the rejection of claim 1 is incorporated and Dain, Kitamura, Tsaur disclose,
outputting, to at least the set of backup data storage sites, a point in time copy information dataset corresponding to point in time copy events (Tsaur, [Col. 8, lines 38-41 – Backup software 50 stores metadata 306 on each backup storage device which describes the backup data sets stored on that backup storage device]; [Col. 9, lines 45-52 - The backup software uses the ID of the target backup storage device as an index value to the backup catalog 113 to lookup the most recent backup data set that was stored on the target backup storage device. The backup software 50 examines metadata 306 which is stored on the target backup storage device and which describes the backup data sets stored on the target backup storage device in order to find the most recent one]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the sequential rotation of Tsaur into the point in time copy of Dain, Kitamura for the benefit of having each of the backup data sets on any given backup storage device be independent from the backup data sets on the other backup storage device. Thus, if one of the backup storage devices fails, then any of the backup data sets on the other backup storage device can still be used to perform a complete recovery of the data objects (Tsaur, Col. 3, lines 43-49).
As per Claim 4, the rejection of claim 2 is incorporated, and Dain, Kitamura, Tsaur disclose,
wherein the point in time copy information dataset is outputted among the set of backup data storage sites through Transmission Control Protocol/Internet Protocol (TCP/IP) connections (Tsaur, [Col. 7, lines 41-47 - The backup server computer 150 implements a cloud-computing backup service for the clients. For example, the backup storage system 100 may be located remotely from the client systems and communicates with them via the Internet/TCP-IP to provide cloud-based backup storage services to the client computer systems, thereby implying that the PiT information dataset is outputted among the backup sites through TCP/IP connections]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the sequential rotation of Tsaur into the point in time copy of Dain, Kitamura for the benefit of having each of the backup data sets on any given backup storage device be independent from the backup data sets on the other backup storage device. Thus, if one of the backup storage devices fails, then any of the backup data sets on the other backup storage device can still be used to perform a complete recovery of the data objects (Tsaur, Col. 3, lines 43-49).
As per Claim 7, it is similar to claims 1, 13 and therefore the same limitations are incorporated.
As per Claim 8, it is similar to claim 2 and therefore the same mappings are incorporated.
As per Claim 10, it is similar to claim 4 and therefore the same mappings are incorporated.
As per Claim 13, Dain discloses a computer system (CS) (Dain, [0068 - Fig. 3 shows a hardware structure of a data storage system in a computer system]) comprising:
a processor(s) set (Dain, [Fig. 3: processor 342]);
a machine readable storage device (Dain, [0070 - In Fig. 3, system memory 343 include or be in communication with a cache 345 for storage 330]); and
computer code stored on the machine readable storage device (Dain, [0007 - The computer-readable storage medium has computer-readable program code portions stored thereon]), with the computer code including instructions for causing the processor(s) set to perform operations (Dain, [0070 - The system memory 343 of storage controller 340 stores the operation software 350, program instructions and data, which the processor 342 may access for executing functions and method steps associated with managing storage 330]) including the following:
The remaining limitations are similar to claims 1, 7 and therefore the same limitations are incorporated.
As per Claim 14, it is similar to claim 2 and therefore the same mappings are incorporated.
As per Claim 16, it is similar to claim 4 and therefore the same mappings are incorporated.
As per Claim 29, the rejection of claim 1 is incorporated, and Dain, Kitamura, Tsaur disclose,
wherein the first specified time, the second specified time, and a future specified time occur at predetermined intervals (Kitamura, [0045 – In Fig. 6, each row in the table corresponds to a logical volume for which snapshot processing is to be performed. The table is populated by an user/admin]; [0048 – In Fig. 6, a NUMBER field 604 represents the number of snapshots to be taken for a logical volume. An INTERVAL field 605 indicates the how often a snapshot is to be taken. For example, in the second row 606 the logical volume is scheduled for 36 snapshots, where one snapshot is taken every hour]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate predetermined interval of Kitamura into the efficient FlashCopy backup of Dain,Tsaur for the benefit of administering the creation and management of the snapshots from the user interface at the console (Kitamura, 0042).
Claims 3, 9, 15 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Dain et al (20150286542) in view of Kitamura (20060218364), Tsaur et al (9880776), and Prahlad et al (20120179886).
As per Claim 3, the rejection of claim 2 is incorporated and Dain,Kitamura, Tsaur disclose point in time copy, snapshots and local and remote backup sites.
Prahlad discloses,
wherein the point in time copy information dataset (Prahlad, [0074 - A user interface screen so that a user may browse and recover data, such as from snapshot images, quick recovery volumes, primary copies, storage copies, etc., as of a point in time. Browsing and recovery may be by client, sub-client, volume, and application specific, and may be at the volume level or at the sub-volume level]) includes a table with entries for point in time copies recorded on the set of backup data storage sites (Prahlad, [0069 – As per Fig. 5, snapshot information that has been indexed or associated with snapshot images by the snapshot manager 503, is tracked in snapshot table 510]; [Fig. 7]),
where each entry in the table (Prahlad, [Figs. 5, 7]) includes information indicative of:
(i) a timestamp indicating a date and time when a snapshot of the monitored volume was recorded as a given complete copy (Prahlad, [0069 - The snapshot information includes a timestamp that indicates when a snapshot was created and a time interval that indicates how long the snapshot should persist]; [Fig. 7: Creation Time: Date, Time]; [0095 – In Fig. 11, first storage operation 900 is a full snapshot/complete copy of a raw partition primary volume 114, thereby implying its entry in table 510 will have a timestamp]),
and (ii) what backup data storage site(s) recorded the given complete copy (Prahlad, [Fig. 7: squid.commvault.com/…./First Storage Group, squid.commvault.com/File System, squid…..com/SQL Server 2000; Here the URL suggests backup sites which might be local or remote]; [0070 - The snapshot manager 503 makes entries into snapshot table 510 for the given client. When a storage is being performed, the manager 503 identifies the content, identifies the volumes and performs or directs the copying to quick recovery volume 118]; [0101 - Snapshot data and incremental block level changes to snapshot data are copied to remote secondary storage 120. System 100a uses additional information communicated with the snapshot data, to unpack the data at remote secondary storage 120 location and to create a remote quick recovery volume 118, thereby implying what backup data storage site(s) recorded the given point in time copy/complete copy]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the snapshot table of Prahlad into the efficient FlashCopy backup of Dain,Kitamura,Tsaur for the benefit of using the snapshot table which is accessed by any one of the program modules like the snapshot manager for managing and controlling the quick recovery volumes (Prahlad, 0069).
As per Claim 9, it is similar to claim 3 and therefore the same mappings are incorporated.
As per Claim 15, it is similar to claim 3 and therefore the same mappings are incorporated.
Claims 5-6, 11-12, 17-18 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Dain et al (20150286542) in view of Kitamura (20060218364), Tsaur et al (9880776), and Coombs et al (20070094533).
As per Claim 5, the rejection of claim 1 is incorporated, and Dain discloses,
the set of backup data storage sites includes at least three backup storage sites (Dain, [Fig. 9: T1, T2, T3]);
where each backup data storage site records a complete copy (Dain, [0030 - A FlashCopy function creates a copy of a source volume on a target volume. This copy is called a point-in-time/PIT copy or complete copy. When a FlashCopy operation is initiated, a relationship is created between a source volume and target volume. This relationship is a mapping of the source volume and the target volume. This mapping allows a point-in-time copy of that source volume to be copied to the associated target volume; complete copy at backup site is full backup or initial backup of first snapshot]; [0082 – initial data reduced full copy of the production volume and deltas/incrementals between snapshots are replicated in a backup site, thereby combining the initial backup/full copy and incremental backups, as complete copy of the backup site]) of the monitored volume for a given period (Dain, [0079 - Flashcopy backups of the production volume P, e.g., a source 402, are scheduled periodically]).
The spec does not disclose the combination scheme recited in the claim. Coombs discloses a tree structure which can determine the number of unique subsets, namely, A-B, B-C, A-C as follows,
there are at least three subsets of backup data storage site(s) (Coombs, [0042 - Tree 40 includes monthly root node 42 representing a full backup/complete copy]; [0040 - Table 1 shows chronologically how backup dependencies are formed including how initial daily backups are based on the first monthly backup]),
with each subset including a unique combination of at least two of the backup data storage sites of the set of backup data storage sites but fewer than the entire set of backup data storage sites (Coombs, [0041 - The backup dependency structure for a 28-day notional month of backups is depicted as a tree 40 having a plurality of nodes each representing an individual full backup. A node is connected to another mode by an edge denoting a parent/child dependency between the joined nodes whereby a child node depends from a parent node if the parent node represents a base/full backup for the backup represented by the child node]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the complete backup dependency structure of Coombs into the efficient FlashCopy backup of Dain,Kitamura,Tsaur for the benefit of structuring the backup dependencies in a tree-like structure facilitates convenient backup, restore and paring, i.e. deletion of the backup and its removal from the tree structure, when the backups are deemed unnecessary or once the backup storage device is full, without sacrificing a comprehensive set of backups (Coombs, 0043).
Tsaur clarifies the rotation scheme as follows,
where each backup data storage site records a complete copy (Tsaur, [Fig. 5]) of the monitored volume (Tsaur, [Col. 3, lines 25-27 - The backup operations may be alternated across the plurality of backup storage devices/sites in a round-robin fashion]; [Col. 9, lines 19-26 – In Fig. 3, step 502, the backup software determines what type of backup operation is specified by the backup schedule for the current time. In step 503, if the current backup operation is a full backup operation then the backup software creates a new full/complete backup data set and stores it on the target backup storage device. But if the current backup operation is incremental, then the alternate path which includes steps 507,509 are followed, thereby combining the full backup and newly created incremental backup for 2nd snapshot, as complete copy at the backup site]) for a given period (Tsaur, [Col. 1, lines 55-57 – Each of the backup operations may be performed at a respective time specified by the backup schedule]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the sequential rotation of Tsaur into the efficient FlashCopy backup of Dain,Kitamura,Coombs for the benefit of having each of the backup data sets on any given backup storage device be independent from the backup data sets on the other backup storage device. Thus, if one of the backup storage devices fails, then any of the backup data sets on the other backup storage device can still be used to perform a complete recovery of the data objects (Tsaur, Col. 3, lines 43-49).
As per Claim 6, the rejection of claim 1 is incorporated, and Dain, Kitamura, Tsaur disclose backup data storage sites.
Coombs further discloses,
wherein at least one backup data storage site is isolated from the first data storage site (Coombs, [Fig. 1B: primary storage device 22]) and located in a different geographic region than the first data storage site separated by at least ten kilometers (Coombs, [0029 – In Fig. 1B, backup storage device 24 may comprise a larger capacity storage device, such as a RAID device, coupled to a remote backup system 26, such as a server resident at a remote computer facility]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the remote backup sites of Coombs into the efficient FlashCopy backup of Dain,Kitamura,Tsaur for the benefit of data being transmitted to remote backup device via a network or selectively backing up data to a remote device or locally to remote device or to both devices (Coombs, 0068).
As per Claim 11, it is similar to claim 5 and therefore the same mappings are incorporated.
As per Claim 12, it is similar to claim 6 and therefore the same mappings are incorporated.
As per Claim 17, it is similar to claim 5 and therefore the same mappings are incorporated.
As per Claim 18, it is similar to claim 6 and therefore the same mappings are incorporated.
Claims 26-27 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Dain et al (20150286542) in view of Kitamura (20060218364), Tsaur et al (9880776), Coombs et al (20070094533) and Okada et al (20060047726).
As per Claim 26, the rejection of claim 5 is incorporated, and Dain, Kitamura, Tsaur, Coombs disclose sequential rotation.
Okada further discloses,
wherein the sequential rotation comprises rotating in a sequential order (Okada, [0012 - A backup management device that carries out simulated backup management in advance, outputs the number of backup media/sites needed for backup]; [0073 - Since the order of rotation of secondary volumes 230 has a pattern whereby six backups make up one set, once the location at which the flag is ‘ON’ reaches ‘Number 6’, it then returns to ‘Number 1’, thereby implying that the rotation is applicable between the first, second, third backup sites at their respective backup times]) between the first backup storage site of the set of backup data storage sites (Okada, [0047 – In Fig. 1, secondary volumes 230a, 230b, 230c, 230d, 230e….collectively as secondary volumes 230]) at a first specified time of the specified times (Okada, [0009 - Backup cycle refers to a periodic time interval at which backups are performed]; [Fig. 17: step S300, Backup time arrived? Yes, thereby implying a first time]; [Fig. 18: step S400]), the second backup storage site of the set of the backup storage sites at a second specified time of the specified times (Okada, [Fig. 17: step S300, Backup time arrived? Yes]; [Fig. 18: step S400]), and a third backup storage site of the set of backup data storage sites at a third specified time of the specified times (Okada, [Fig. 17: step S300, Backup time arrived? Yes, thereby implying a second time because backup is periodic and Fig. 18 is a loop]; [Fig. 18: step S400]; [0052 - Schedule mode in Fig. 17 is a backup mode in which a backup schedule that includes the order of rotation of secondary volumes 230 to which backups are to be made is created in advance, and backups are executed according to this backup schedule. Serial mode in Fig. 18 is a backup mode in which a secondary volume 230 to which backup is to be made is selected serially at each backup cycle, and backup executed accordingly]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate administering multiple generations of backup data of Okada into the efficient FlashCopy backup of Dain, Kitamura, Tsaur, Coombs for the benefit of having the backup management device that manages multiple generations of backup data to rotate a plurality of rewriteable backup media while recording backup data onto the backup media according to a predetermined backup cycle (Okada, 0008).
As per Claim 27, it is similar to claim 26 and therefore the same mappings are incorporated.
Claims 28,34 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Dain et al (20150286542) in view of Kitamura (20060218364), Tsaur et al (9880776), and Okada et al (20060047726).
As per Claim 28, the rejection of claim 13 is incorporated, and Dain, Kitamura, Tsaur disclose sequential rotation.
Okada further discloses,
wherein the sequential rotation comprises rotating in a sequential order (Okada, [0012 - A backup management device that carries out simulated backup management in advance, outputs the number of backup media/sites needed for backup]; [0073 - Since the order of rotation of secondary volumes 230 has a pattern whereby six backups make up one set, once the location at which the flag is ‘ON’ reaches ‘Number 6’, it then returns to ‘Number 1’, thereby implying that the rotation is applicable between the first, second, third backup sites at their respective backup times]) between the first backup storage site of the set of backup data storage sites (Okada, [0047 – In Fig. 1, secondary volumes 230a, 230b, 230c, 230d, 230e….collectively as secondary volumes 230]) at a first specified time of the specified times (Okada, [0009 - Backup cycle refers to a periodic time interval at which backups are performed]; [Fig. 17: step S300, Backup time arrived? Yes, thereby implying a first time]; [Fig. 18: step S400]), the second backup storage site of the set of the backup storage sites at a second specified time of the specified times (Okada, [Fig. 17: step S300, Backup time arrived? Yes]; [Fig. 18: step S400]), and a third backup storage site of the set of backup data storage sites at a third specified time of the specified times (Okada, [Fig. 17: step S300, Backup time arrived? Yes, thereby implying a second time because backup is periodic and Fig. 18 is a loop]; [Fig. 18: step S400]; [0052 - Schedule mode in Fig. 17 is a backup mode in which a backup schedule that includes the order of rotation of secondary volumes 230 to which backups are to be made is created in advance, and backups are executed according to this backup schedule. Serial mode in Fig. 18 is a backup mode in which a secondary volume 230 to which backup is to be made is selected serially at each backup cycle, and backup executed accordingly]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate administering multiple generations of backup data of Okada into the efficient FlashCopy backup of Dain, Kitamura, Tsaur, Coombs for the benefit of having the backup management device that manages multiple generations of backup data to rotate a plurality of rewriteable backup media while recording backup data onto the backup media according to a predetermined backup cycle (Okada, 0008).
As Per Claim 34, the rejection of claim 2 is incorporated, and Dain,Kitamura, Tsaur disclose outputting PiT/complete copy information.
Okada discloses,
wherein the outputted point in time copy information (Okada, [0074 - Fig. 10 shows a backup hold status display screen which displays a time axis going back in time from the current point in time]; [Fig. 3]) is a table listing a history of point in time copies recorded for the volume being monitored (Okada, [0008 - The backup management device manages multiple generations of backup data by rotating a plurality of rewriteable backup media while recording backup data onto the backup media according to a predetermined backup cycle]; [0005 - Various algorithms may be employed to create a backup schedule that involves backing up while rotating a number of volumes, e.g. round robin]), including which backup data storage site recorded each complete copy and when each complete copy was recorded (Okada, [0066 – Fig. 5 shows a volume table, which records the volume IDs, LUNs set in the volumes, backup data acquisition time/history, etc.]; [0069 - Fig. 8 shows a tape backup catalog which records a data backup history, namely, backup ID, tape ID, offset, size, and backup acquisition time; Since the claim does not recite how the table is represented, the citations are valid interpretation]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate administering multiple generations of backup data of Okada into the efficient FlashCopy backup of Dain,Kitamura,Tsaur for the benefit of having the backup management device that manages multiple generations of backup data to rotate a plurality of rewriteable backup media while recording backup data onto the backup media according to a predetermined backup cycle (Okada, 0008).
Response to Arguments
The Applicant's arguments filed on January 23, 2026 have been fully considered, but moot in view of the new ground of rejection.
Applicant argues, ‘Amended claim I recites "monitoring a volume at a first data storage site for periodic point in time copying, where the periodic point in time copying comprises recording snapshots of the volume at specified times ….’. (Rem, Pg. 11)
Response: The amendments do not align with the spec.
Though monitoring a volume and storing data are well-known in the art, the ‘monitoring’ step is not merely a preamble, but a critical, active step required to ‘periodically record’ the state of the system, without which the ‘complete copy’ cannot be accurately created at the selected backup site. For example, snapshot transfer status is a monitoring function, which is undisclosed.
By definition, a snapshot is a PiT copy of a volume. It is not a full backup, and only stores changes.
If storing a ‘complete copy’ at each selected backup site is essential to the disclosure, then the spec must recite in detail how a ‘complete copy’ is reconstructed at the backup site. The spec’s failure to do so demonstrates lack of possession of the limitation, ‘….storing a complete copy….’, at the time of filing.
Spec, Para-0041 recites, ‘The primary volume….has been flagged for frequent point in time snapshots ….to be recorded, with one point in time copy being recorded for data protection at least every hour. This stipulation requires that a complete copy of the primary volume must be recorded at a data backup site at least once per hour’.
This solo recitation lacks adequate description because the spec does not disclose in detail how frequent PiT snapshots constitute a ‘complete copy’ at the selected backup site. It is well known that a snapshot is just a metadata map of data blocks, but backup systems use this map to create an independent complete copy at a backup site. The first snapshot is a full backup/complete copy of the volume. Subsequent snapshots only capture changed data blocks/deltas since the last snapshot, which are then copied to the backup site, ensuring the backup site holds a full/complete copy of the data. For example, the first snapshot at T1 is merged with the incremental changes snapshot at T2. The merging happens at the backup site to create the complete copy.
The spec does not disclose any form of merging or a different method or a new method, to reconstruct the complete copy at the backup site. Therefore the recitation,‘….storing a complete copy….’ is a functional result rather than a structural description.
The spec uses a common, indistinct word in backup technology, ‘complete copy’, rather than providing concrete examples, structural details, or specific data types that define ‘complete copy’ at the backup site. Specifically, 'complete copy' lacks clear definition, and the spec provides no guidance on whether it includes, e.g., metadata, hidden files, or temporal consistency, thus requiring undue experimentation to determine the contents of a 'complete copy’.
By not defining ‘complete copy’, by not disclosing what is transferred to the backup site, but instead broadly claiming ‘storing a complete copy of a volume on a backup site….’ without describing a specific method for the storage, the applicant is attempting to lock in every possible method of creating and storing a snapshot-based backup, regardless of whether they invented it. Please see the 112(a)’s.
Applicant further argues, ‘….and further specifies that "the complete copy of the volume is recorded at a backup data storage site at least once per the specified time."’ (Rem, Pg. 13)
Response: Amended Claim 1 recites that the set of backup sites includes at least two backup sites using sequential rotation to record a complete copy on each backup site, at least once. This scenario uses a round-robin rotation scheme disclosed by the combination of the prior art where Tsaur discloses that the algorithm sequentially selects the next backup site in the set, ensuring all backup sites are used in a repeating cycle. ‘At least once’ means that with two backup sites, the backup software simply alternates between Site A and Site B for each sequential rotation, guaranteeing that a complete copy lands at each site during every other cycle.
As mentioned above, the spec does not disclose the steps that reconstruct the complete copy at the selected backup site. The spec relies on a result, ‘…storing a complete copy….’, without reciting the steps to achieve the result, i.e. ‘storing’.
However, Tsaur, Fig. 3 discloses that when the backup operation type is: full, the full backup/initial backup is stored as ‘complete copy’. This is equivalent to the full backup of the first snapshot. And when the backup operation type is: incremental, the newly created incremental backup(second snapshot) is combined with the initial full backup and stored as ‘complete copy’ on the selected backup site. Please see O/A.
Applicant further argues, ‘However, none of the portions of Yagawa describe storing "a complete copy of the volume" at a backup….site’. (Rem, Pg. 15)
Response: This argument is incorrect.
The combination of the prior art discloses storing ‘a complete copy of the volume’ at a backup site. For example, Yagawa, Fig. 3, Para-0022 recites, ‘FIG. 3 illustrates a process for performing a PiT shadow copy from the A-Vol/source to the B-Vol/target to form a volume pair’.
It is well-known in the art that a shadow copy is a snapshot providing an exact image of the volume at a specific time. By moving the shadow copy to a separate/target site and forming a volume pair, an independent, complete copy of the original data is created, at that specific moment, thereby serving as a backup. Therefore, Yagawa, Fig. 3, discloses storing a complete copy of the volume at a backup site.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm EST.
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, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132
