DETAILED ACTION
Priority: 4/5/2024
Assignee: Hitachi
Election/Restrictions
Newly submitted claim(s) 12, 13-14 are directed to an invention/species that is independent or distinct from the invention originally claimed for the following reasons:
There are two groups/species of claims:
Claims 1, 5-11 (Species-1 or S1)
Claims 1, 9, 12, 13-14 (Species-2 or S2)
At least Figs. 2,6-8,10,13,15-16,19,22-24,26,28 pertain to S1.
At least Figs. 3,9,17-18,20-21,27 pertain to S2.
The first species, S1, recites data processing involving a replication source logical volume/LV (henceforth source LV), a data sharing LV and a replication destination/LV (henceforth destination LV). S1 recites that each logical volume includes a first cache area that stores data and a second cache area that compresses and stores data in the first cache area. In Fig. 2, the ‘second cache area’ is located in the ‘data sharing cache area’ of each volume. No other storage location is identified in the ‘data sharing cache area’ of each logical volume. S1 recites data movement between the second cache area of the source LV and the second cache area of the data sharing LV. S1 further recites that when the source LV is deleted the controller moves data stored in the second cache area of the data sharing LV to the destination LV and deletes the data sharing LV. Thus S1 recites a configuration, scope and function where the source LV, the data sharing LV, and the destination LV, participate in replication.
The second species, S2, recites data processing involving a source LV, a data sharing LV, a destination LV and ‘a replication destination LV in a copy state’.
Claims 13-14 of S2 recite, ‘when a replication destination logical volume in a copy state exists during a postscript processing of dirty data’.
With regards to the existence of ‘a replication destination LV in a copy state’, Fig. 18 shows ‘postscript processing of dirty data’. And Fig. 3 shows that a logical volume used in ‘postscript processing’ has a different configuration. Each logical volume includes a first cache area that stores data and a second cache area that compresses and stores data in the first cache area. Fig. 3 also shows that the ‘second cache area’ is located in the ‘data sharing cache area’ of each volume. And the ‘data sharing cache area’ has an additional area called, ‘postscript area’. The meta information (directory table, mapping table) is also stored in the data sharing cache area.
Spec, Fig. 17 shows that if dirty data is identified, Fig. 18, ‘postscript processing’ is invoked. Claim 12 recites identifying dirty data in the first cache area of the source LV. And claim 13 recites when ‘a replication destination LV in a copy state’ exists during a postscript processing of dirty data, the controller determines whether directory information corresponding to a logical address of the dirty data has been copied. And claim 14 recites that when ‘a replication destination LV in a copy state’ exists during a ‘postscript processing’ of dirty data and is not copied, the controller copies the directory information corresponding to a logical address before storing the compressed dirty data in the ‘postscript area’. As recited, S2 recites data movement between the second cache area of the source LV and the second cache area of the data sharing LV, and also transfers the postscript data and meta information stored in the data sharing cache area of the source LV to the data sharing cache area of the data sharing LV. Therefore S2 recites a configuration and data movement that is different from S1.
In short, each species recites a configuration, function and scope that results in a distinct method of data transfer between its logical volumes.
It is interesting to note that Fig. 2 discloses a configuration (X) of a logical volume (utilized by LV’s of S1) and Fig. 3 recites another configuration (Y) of a logical volume, but the figures do not recite a ‘hybrid’ configuration (X+Y) involving Fig. 2 and Fig. 3 (as utilized by LV’s of S2).
CPC classification:
S1 search at least includes :: G06F3/0647, G06F16/27, G06F2201/84, G06F16/184, G06F3/065, G06F16/1744, G06F3/0608
S2 search at least includes :: G06F3/0685, G06F16/128, G06F2201/84, G06F3/0611, G06F3/065, G06F3/0665, G06F11/1456, G06F12/0806
The distinct configuration, data movement, function and scope of each species requires two different sets of prior art and NPL. The claims require different fields of search (e.g., searching different classes/subclasses or electronic resources, or employing different search strategies or search queries), examining which would be a significant burden on the examiner.
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) 9, 12, 13-14 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, 5-11 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.Amended Claims 1, 9 are rejected for reciting a limitation with antecedent basis issues.
Amended Claim 1 recites, ‘A storage system providing a plurality of logical volumes….each of the logical volumes includes….’.
Amended Claim 1 further recites, ‘when the controller replicates the logical volume’.
As recited, ‘the logical volume’ has not been introduced. To establish antecedent basis, the limitation must recite, ‘when the controller replicates a logical volume of the plurality of logical volumes’. Claim 9 has the same issue.
Note: This issue was mentioned in the previous O/A. But it is unresolved. Based on the amendments and arguments, it is clarified and maintained.
2.Amended Claim 5 is rejected for reciting a limitation with antecedent basis issues.
Amended Claim 5 recites, ‘when a logical volume that accesses the data sharing logical volume….’.
Claim 1 introduces a source LV, a destination LV and a data sharing LV. Therefore it is unclear what ‘a logical volume’ represents. It is unclear if it is a new volume. To maintain consistency and clarity, the claim can recite, ‘if the replication destination LV becomes the only volume accessing the data sharing LV by deleting….’.
Note: Claim 5 submitted as part of the original disclosure correctly recites, ‘when the logical volume….’.
3.Amended Claim 7 is rejected for reciting a limitation with antecedent basis issues.
Amended Claim 7 recites, ‘wherein the controller performs data movement between the second cache area of the logical volume….’.
Claim 1 introduces ‘data movement’. So to establish antecedent basis, claim 7 must recite, ‘performs the data movement’.
1.Amended Claim 1 is rejected for reciting a limitation that is unclear, Vague and indefinite.
Amended claim 1 recites, ‘wherein the at least one controller performs data movement …..by replacing the second cache area of the replication source logical volume with the second cache area of the data sharing logical volume’.
As recited, it is unclear how the source ‘second cache area’, represented by an address, is replaced with the data sharing ‘second cache area’, another address.
It is well known, replacing ‘A with B’ means, ‘Take A out, put B in’. So the result is: A is no longer there, B is now there. The ‘replacement’ suggests data loss.
If the source ‘second cache area’ represents the data stored in it, the limitation, ‘replacing the second cache area of the replication source….’, also suggests data loss.
Hence claim 1 is rejected for reciting a limitation that is unclear, vague and indefinite. Claims 9, 10-11 have the same issue and are rejected for the same reason.
2.Amended Claim 1 is rejected for reciting a limitation that is unclear, ambiguous, inconsistent and indefinite.
Amended claim 1 recites, ‘wherein, when data is written in the first cache area of….source logical volume,…… wherein when the data write in the first cache area ….is write that updates data, data after update is stored while data before update is left’.
If ‘when the data write in the first cache area….is write that updates data’, then was the ‘first write data’ stored, compressed and moved? If not, then is ‘write that updates data’ stored, compressed and moved?
That said, how is ‘write that updates data’ determined? Any ‘write’ data size in the first cache area of source LV is not tracked by the controller. Hence it is unclear how ‘write that updates data’ is calculated.
Data and data size in the source first cache area is dynamic. It is also unclear how ‘data after update’ is calculated and stored. It is also unclear how ‘data before update’ is calculated. It is also unclear how ‘left data’ in ‘data before update is left’ calculated.
Given the lack of details in data size tracking in the source first cache area, ‘which’ data is compressed and moved is indeterminate.
Data is written by the host (via write requests) to the first cache area of the source LV. How this dynamic data is tracked and compressed to the second cache area of the source LV and then moved to the second cache area of the data sharing LV lacks written description support in the spec.
In short, the dynamic data size calculation and movement lacks written description support in the spec and hints at new matter. Hence amended claim 1 is rejected for reciting a limitation that is unclear, ambiguous, inconsistent and indefinite.
3.Amended Claim 1 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Amended Claim 1 recites, ‘when data is written in the first cache area of the replication source logical volume….., the data is compressed and stored in the second cache area of the data sharing logical volume…..’.
Since ‘data movement’ is unrecited, it is unclear how compressed data of the source LV is stored in the second cache area of the data sharing LV.
Hence amended claim 1 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
4.Amended Claim 5 is rejected for reciting a limitation that is unclear, vague and indefinite.
Amended claim 5 recites, ‘when logical volume that accesses the data sharing logical volume becomes only one replication destination logical volume by deleting the replication source logical volume’.
However, spec, Para-0004 recites, ‘because the data referred to by the replication destination volume is also stored in the area managed by the replication source volume, there is a problem that the replication source volume cannot be deleted’. And Para-0089 recites, ‘an operation for deleting the replication source volume 200 cannot be performed, and a problem that an unnecessary data set cannot be released from the storage system 100 is generated’.
If the source LV is deleted, as recited in claim 5, it is unclear what happens to the ‘association’ between data in the first cache area of the source LV and the data moved to the second cache area of the data sharing LV, as recited in amended claim 1.
Due to source LV deletion, spec, Para-0129 recitation, ‘Consequently, the data of the data sharing volume 202 referred to by the replication source volume 200 can be accessed from the replication destination volume 201’, is no longer true. So due to the ‘broken association’, it is unclear how the controller can ‘move’ data in the second cache area of data sharing LV to the destination LV, as further recited in amended claim 5.
Claim 5 recites source LV deletion without adequate detail.
Since it is unclear if the source LV deletion can maintain the data integrity between the data sharing LV and destination LV, claim 5 is rejected for reciting a limitation that is unclear, vague and indefinite.
5.Amended Claim 6 is rejected for reciting a limitation that is unclear, logically inconsistent and indefinite.
Amended Claim 6 recites, ‘wherein data of the second cache area of the data sharing logical volume is deleted’.
Parent of claim 6, amended claim 5, recites that the data sharing LV is deleted. Hence it is unclear how claim 6 recites ‘data….of the data sharing logical volume is deleted’.
Note: This issue was mentioned in the previous O/A. But it is unresolved. Based on the amendments and arguments, it is clarified and maintained.
6.Amended Claim 7 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Amended Claim 7 recites, ‘performs data movement between….by: ….replacing….second cache area of the logical volume….and replacing directory information indicating….with the first cache area of the logical volume….’.
As recited, it is unclear which logical volume the limitations are referring to, source or destination ?
More importantly, the claim also recites, ‘replacing….the logical volume and the second….data sharing logical volume’. This recitation conflicts with amended claim 1, which recites, ‘replacing the second cache area of….source…. with the second cache area of the data sharing….’.
Replacing ‘X and Y’ is not the same as replacing ‘X with Y’. That said, neither ‘replacement’ steps are recited in the spec.
The claim also recites, ‘replacing directory….indicating a relationship with the first cache area of the logical volume…’, without identifying source or destination logical volume.
Accordingly, claim 7 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
7.Amended Claim 8 is rejected for reciting a limitation that is unclear, ambiguous and indefinite.
Claim 8 recites, ‘wherein data input to the second cache area (of ????) and data output from the second cache area (of ??) are stopped when the second cache area (of ??) and the directory information (of ??) are replaced’.
This recitation has many issues. The issues marked with ‘??’ are ambiguous. Hence the rejection.
Note: This issue was mentioned in the previous O/A. But it is unresolved. Based on the amendments and arguments, it is clarified and maintained.
8.Claim 11 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Claim 11 recites, ‘before replacing….wherein the directory information indicates a relationship between the first cache area and the second cache area’.
Spec, Fig. 16, Para-0125 recites, ‘In step S1603-1, the volume replication program 511-1 copies the directory table 301 of the replication source volume to the directory table 301 secured for the data sharing volume’. That’s all. No other information is provided. Therefore reciting, ‘wherein the directory information indicates a relationship between the first cache area and the second cache area’, is an extrapolation.
Furthermore, it is unclear which logical volumes are associated with ‘first cache area’ and ‘second cache area’, the source LV and/or data sharing LV.
Hence claim 11 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
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, 5-11 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Matsushita et al (20220035833) in view of Matsushita et al (20130305003, hereinafter Matsushita-2).
As per Claim 1, Matsushita discloses a storage system (Matsushita, [0043 - Fig. 1 shows storage system 201]) providing a plurality of logical volumes (Matsushita, [0076 – Fig. 6 shows volume management table 311 used for managing logical volumes such as the PVOL 100, the Snapshot 101, and DSVOL 102]) comprising at least one controller (Matsushita, [0058 – Fig. 2, storage controller 210]; [0009 - The storage system includes a plurality of controllers and capable of creating a snapshot, which is a replication of a logical volume]; [0057 - Storage system 201 comprises a plurality of storage controllers 210, and a plurality of PDEVs 220. PDEV 220 is connected to storage controller 210. One or more DSVOLs 102-i(i=0,1,….n-1) are assigned to one storage controller 210]),
wherein each of the logical volumes (Matsushita, [0045 - All DSVOLs 102-i are of the same capacity]) includes a first cache area that stores data (Matsushita, [0068 - The cache memory 301 temporarily stores a data set to be written to PDEV 220]; [0072 – In Fig. 4, the PVOL/Snapshot internal address 400 is a logical address of the target data in the PVOL 100 in directory table 103-i, and is a logical address of the target data in the Snapshot 101 in directory table 104-i]) and a second cache area (Matsushita, [0009 - A log structured area which stores data of the logical volume]) that compresses and stores (Matsushita, [0107 – In Fig. 14, step S1404, Snapshot creation program 304 compresses the dirty data identified in step S1400. In step S1405, program 304 copies the compressed data set, which was compressed in step S1404, to the log structured area]) the data stored in the first cache area (Matsushita, [0075 – In Fig. 5, post-compression capacity 502 is the data volume after compression when the target data of the PVOL 100 or the Snapshot 101 is stored in the log structured area 106-i]; [0123 – In Fig. 17, step S1700, back-end write program 307 determines whether there is dirty data in cache memory 301/first cache area, step S1700:Yes. In step S1701:Append Processing, which compresses the data. See Fig. 14]),
and when the controller replicates the logical volume (Matsushita, [0009 - Creating a snapshot, which is a replication of a logical volume]),
data stored ([See 112(b)]) in the second cache area of a replication source logical volume (Matsushita, [0053 - The mapping table 105 is a table which converts a PVOL internal address of data 111-j(j=0, 1, 2, 3) into an internal address of a log structured area 106, thereby implying the data association between source LV’s first cache area 111 and second cache area/log 106, because first cache area data is compressed and stored in second cache area/log 106]) is moved to the second cache area of a data sharing logical volume (Matsushita, [0043 – Fig. 1 uses the RoW/Redirect on Write method when creating a Snapshot; Since the claim does not recite which data is moved, the citation is a valid interpretation. The spec also recites RoW]; [0045 – In Fig. 1, DSVOL 102 is a logical storage area that is selected and extracted from Pool 107 and is a logical storage area of DSVOLs 102-i]; [0050 -SS directory table 104 is a group of the directory tables 104-i(i=0,1,n-1), for each Snapshot 101; A snapshot/SVOL is a point in time copy of the PVOL data, so data stored in the second cache area of the source LV is moved to the second cache area of the first snapshot/SVOL-1/data sharing volume]),
and data in the first cache area of the replication source logical volume (Matsushita, [Figs. 1,3]) is associated with the data moved to the second cache area of the data sharing logical volume (Matsushita, [Fig. 13: step S1308-Update directory area assignment table 314, stepS1309-Update directory area management table 312]; [0102 - In S1311, upon receiving the instruction for copying the directory of S1310, Snapshot creation program 304 copies the directory table 103-i of the PVOL/source, which is a replication source VOL, to the relevant directory area of DSVOL 102-i allocated in steps S1308 and S1309]),
a storage area of the first cache area of a replication destination logical volume (Matsushita, [Figs. 1,3]) that is a replication of the replication source logical volume is associated with a storage area that is the second cache area of the data sharing logical volume and stores the data (Matsushita, [Fig. 13 refers to Fig. 14]; [Fig. 14: step 1406, Update Mapping table]; [Fig. 14: step 1407, update Directory table]; [0108 – In Fig. 14, step S1406, the Snapshot creation program 304 sets the copy destination address of the compressed data as the reference destination address/log structured area internal address 501]; [0109 - In step S1407, the Snapshot creation program 304 sets the mapping area internal address 500 of the mapping information created in S1406 as the reference destination address 401 in the entry corresponding to the logical address of the data among the respective entries of the directory table 103; These two steps imply the association between the first cache area of dest LV and second cache area of data sharing LV; Since spec, Fig. 16,Para-0129 does not explicitly recite the ‘association’, the citation is a valid interpretation]),
wherein the at least one controller produces the data sharing logical volume (Matsushita, [Fig. 12: Volume creation]; [0089 – In Fig. 12, step S1200, the volume creation program 303 confirms whether the directory area and the mapping area of the PVOL which satisfy the designated condition/volume capacity can be allocated in each DSVOL 102-i based on the storage controller 201 which controls each DSVOL 102-i. The volume creation program 303 proceeds to step S1202 when it is determined that the foregoing areas can be allocated/produced in S1200, step S1201: Yes; Since controller-1 controls DSVOL 102-1, the citation is a valid interpretation]; [Fig. 12: After steps S1203-S1205, in step S1206, volume management table is updated to show the new allocation and assignment]) when the data sharing logical volume does not exist for the replication source logical volume (Matsushita, [0045 - DSVOL 102 is a logical storage area that is selected and extracted from Pool 107 as data is written to the first cache area as shown in Fig. 16]; [0076 – In Fig. 6, volume management table 311 is a table for managing volumes such as the PVOL 100, the Snapshot 101, and DSVOL 102, thereby implying that if the entry is missing in the table, then the data sharing volume does not exist and will be created by Fig. 12 as explained above. Furthermore, since the PVOL already exists, SVOL-1 is produced next]),
when data is written in the first cache area of the replication source logical volume (Matsushita, [0115 – In Fig. 16, front-end write processing is executed by the front-end write program 306 upon receiving, from host a write request for writing data in PVOL 100; Since snapshot creation is after Fig. 12: VOL creation, it implies that data is written to first cache area after destination LV is created]) after production of the replication destination logical volume (Matsushita, [0088 - Fig. 12 shows SVOL-2/destination creation processing. The VOL creation processing is executed by the volume creation program 303 according to an instruction from management system 203]; [Fig. 12: step S1201, Can area be allocated? Yes]),
the data is compressed and stored ([See 112(b)]) in the second cache area of the data sharing logical volume (Matsushita, [Fig. 17]; [0096 – In Fig. 13, step S1300, Snapshot creation program 304 receives the VOL# of the replication source VOL, which is the PVOL to undergo the Snapshot creation; Since the snapshot/SVOL-1 is a PiT copy of the PVOL, it implies that the PVOL written data is compressed and stored in second cache area of the data sharing volume/SVOL]) without being associated with the replication destination logical volume (Matsushita, [0097 – In Fig. 13, step S1304, the Snapshot creation program 304 confirms whether the directory area of the Snapshot, which is a replication of the replication source VOL, can be allocated in the DSVOL 102, thereby implying associating and storing data in the second cache area of the data sharing logical volume/first SVOL and not the replication destination volume]),
when the data write in the first cache area of the replication source logical volume (Matsushita, [0072 – In Fig. 4, the PVOL internal address 400 is a storage logical address of the target data in PVOL 100 in the case of the directory table 103-i]; [0068 – In Fig. 3, cache memory 301 temporarily stores a data set to be written to PDEV 220]; [Fig. 13: in S1300, the Snapshot creation program 304 receives the VOL# of the replication source VOL, which is the PVOL to undergo the Snapshot creation; Since snapshot creation is after Fig. 12: VOL creation, it implies that data written to first cache area is after destination PVOL/Snapshot is created]) after production of the replication destination logical volume (Matsushita, [0088 - Fig. 12 shows VOL/destination creation processing. The VOL creation processing is executed by the volume creation program 303 according to an instruction from management system 203]; [Fig. 12: step S1201, Can area be allocated? Yes]) is write ([See 112(b)]) that updates data (Matsushita, [Fig. 13: step S1301: Yes, Append Processing, perform all steps, goto step S1311]), data after update is stored while data before update is left (Matsushita, [0043 – RoW/Redirect on Write]; [Fig. 13: proceed until step S1305; Since the claim does not recite how ‘data before and after update’ is identified, the citation is a valid interpretation]),
Matshshita-2 clarifies the data movement as follows,
data stored in the second cache area of a replication source logical volume (Matsushita-2, [Fig. 13: compressed P-VOL/source]) is moved to the second cache area of a data sharing (Matsushita-2, [Fig. 13: compressed S-VOL/data sharing]) logical volume (Matsushita-2, [0124 – In Fig. 14, LU copy program 134 then copies the compressed data which is read in step S404 as is to the compressed S-VOL cache area in step S405. The LU copy program 134 then stores compressed data, which has been copied to the compressed S-VOL cache area, in the compressed S-VOL chunk 1304 in step S406; Here the use of copy program 134 suggests that S-VOL represents the data sharing LV. The copy program 134 performs copy, not replication]), and data in the first cache area of the replication source logical volume (Matsushita-2, [Fig. 4: uncompressed LU 401/PVOL implies that the uncompressed data is stored in a first cache area]) is associated with the data moved to the second cache area of the data sharing logical volume (Matsushita-2, [Fig. 14: S408, update chunk management table]; [0071 – In Fig. 7, in the case of the Fig. 4, uncompressed LU chunk 410, information indicating 64 kB is stored in the page size field 1382]; [0073 – In Fig. 7, chunk management table, compressed LU mapping table address field 1384 stores addresses where the compressed LU mapping table corresponding to the chunk is stored]),
wherein when data is written in the first cache area of the replication source logical volume (Matsushita-2, [0075 - Fig. 8 shows an initial compression procedure in a case where compression of an uncompressed LU 401 is instructed by the management terminal 102; Here uncompressed LU comprises of data written to first cache area]), the data is compressed and stored in the second cache area of the data sharing logical volume without being associated with the replication destination logical volume (Matsushita-2, [0009 - Control unit compresses data which is written to the logical volume/source LV by the host and assigns one of the plurality of chunks to a compressed data logical volume/data sharing LV which stores the compressed data]),
wherein the at least one controller performs data movement (Matsushita-2, [0124 – In Fig. 14, LU copy program 134 then copies the compressed data which is read in step S404 as is to the compressed S-VOL cache area in step S405. The LU copy program 134 then stores compressed data, which has been copied to the compressed S-VOL cache area, in the compressed S-VOL chunk 1304 in step S406; Here the use of copy program 134 suggests that S-VOL represents the data sharing LV. The copy program 134 performs copy, not replication]) between the second cache area of the replication source logical volume (Matsushita-2, [Fig. 4: uncompressed LU 401, implies that PVOL stores uncompressed data in a first cache area]; [Fig. 13: compressed P-VOL/source]; [0111 – In Fig. 13, a compressed P-VOL 1301 represents a copy source LU which stores compressed data, thereby implying that the compressed data is stored in the second cache area]) and the second cache area of the data sharing logical volume (Matsushita-2, [Fig. 13: compressed S-VOL/data sharing]; [0111 – In Fig. 13, compressed S-VOL 1302 represents a copy destination LU]) by replacing ([112(b)]) the second cache area of the replication source logical volume with the second cache area of the data sharing logical volume (Matsushita-2, [0124 – In Fig. 14, the storage address of the compressed S-VOL chunk 1304 is configured with exactly the same offset as the compressed P-VOL chunk 1303, the offset address in the chunk]; [0125 – If copying of all the data in the compressed P-VOL chunk 1303 is complete, the LU copy program 134 updates the information of the compressed S-VOL chunk 1304 of the chunk management table 138 in step S408]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the high-speed copying of Matsushita-2 into the data replication of Matsushita, for the benefit managing a storage area which is provided by the storage unit as a pool, and assigns a storage area of the pool to the logical volume on the basis of the data I/O requests from the host, wherein the control unit divides the pool into a plurality of chunks, wherein the control unit compresses data which is written to the logical volume by the host and assigns one of the plurality of chunks to a compressed data logical volume which stores the compressed data (Matsushita-2, 0008-0009).
As per Claim 5, the rejection of claim 1 is incorporated and Matsushita discloses,
when the logical volume that accesses the data sharing logical volume becomes only one replication destination logical volume (Matsushita, [0152 - Fig. 23 shows restoration processing. In step S2100, restoration program 308 receives the PVOL# of the restoration destination and the Snapshot# of the restoration source from management system 203 thereby implying that first snapshot/SVOL-1 becomes the new source LV after the restoration]) by deleting ([See 112(b)]) the replication source logical volume (Matsushita, [Fig. 20: PVOL deletion, all steps]; [0134 – In Fig. 20, the deletion process starts with step S2000. Here the PVOL deletion program 310 receives the PVOL#/source to be deleted]),
the controller moves data ([See 112(b)]) stored in the second cache area of the data sharing logical volume (Matsushita, [0009 - A log structured area/second cache which stores data of the logical volume/data sharing volume]) to the replication destination logical and delete the data sharing logical volume (Matsushita, [0135 – In Fig. 20, step S2000, the Snapshot deletion program 310 receives the Snapshot#/SVOL-1 to be deleted. At step S2005: Can mapping area be deleted? No, because the claim does not recite if the association with the first cache area of source LV and second cache area of data sharing LV is non-existent. Then goto step S2009, step S2010: Yes, step S2011, End process, implying that SVOl-1/data sharing volume is deleted])
As per Claim 6, the rejection of claim 5 is incorporated and Matsushita discloses,
wherein data of the second cache area of the data sharing logical volume (Matsushita, [0137 – In Fig. 20, step S2003, the PVOL/Snapshot deletion program 310 deletes, from the directory area management table 312, the record corresponding to the directory table deleted in S2002. Next, in S2004, program 310 deletes, from the directory area assignment table 314, the record of the directory area offset address 900 corresponding to the record that was deleted from the directory area management table 312 in S2003]) is deleted (Matsushita, [0134 - Fig. 20 shows the PVOL/Snapshot deletion processing]; [0135 – In Fig. 20, step S2000, the PVOL/Snapshot deletion program 310 receives the PVOL# or the Snapshot# to be deleted and proceeds to the last step of the flow diagram]).
As per Claim 7, the rejection of claim 1 is incorporated and Matsushita discloses,
wherein the controller performs data movement ([See 112(b)]) between the second cache area of the logical volume and the second cache area of the data sharing logical volume (Matsushita, [0009 – Each volume has a log structured area/second cache which stores data of the logical volume or the snapshot]) by replacing the second cache area of the logical volume and the ([See 112(b)]) second cache area of the data sharing logical volume (Matsushita, [Fig. 13, Fig. 14: step 1406-Update Mapping Table, step 1407-Update Directory Table]),
and replacing directory information (Matsushita, [0100 – In Fig. 13, step S1308, the directory area assignment table 314 is updated]; [0101 - In step S1309, the directory area management table 312 is updated]) indicating a relationship with the first cache area of the logical volume associated with the second cache area (Matsushita, [0081 - The directory area management table 312 includes a directory# 700 and a directory area offset address 701. For example, an area in which the address 50 in the same DSVOL 102 is the offset address has been allocated in a directory having a directory# of 0]; [0082 - A serial number of the directory# in the corresponding VOL/Snapshot can be obtained from the quotient obtained by dividing the PVOL/Snapshot internal address of the target data by the capacity that can be managed by one directory table. The directory# 700 can be obtained from the serial number of the directory# by referring to the directory# 602 of Fig. 6, thereby implying how the relationship is maintained in the table(s) and which can be updated as needed]).
Matsushita-2 clarifies,
wherein the controller performs data movement between the second cache area of the logical volume and the second cache area of the data sharing logical volume by replacing the second cache area of the logical volume and the ([See 112(b)]) second cache area of the data sharing logical volume (Matsushita-2, [0124 – In Fig. 14, LU copy program 134 then copies the compressed data which is read in step S404 as is to the compressed S-VOL cache area in step S405. The LU copy program 134 then stores compressed data, which has been copied to the compressed S-VOL cache area, in the compressed S-VOL chunk 1304 in step S406; Here the use of copy program 134 suggests that S-VOL represents the data sharing LV. The copy program 134 performs copy, not replication]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the high-speed copying of Matsushita-2 into the data replication of Matsushita, for the benefit managing a storage area which is provided by the storage unit as a pool, and assigns a storage area of the pool to the logical volume on the basis of the data I/O requests from the host, wherein the control unit divides the pool into a plurality of chunks, wherein the control unit compresses data which is written to the logical volume by the host and assigns one of the plurality of chunks to a compressed data logical volume which stores the compressed data (Matsushita-2, 0008-0009).
As per Claim 8, the rejection of claim 7 is incorporated and Matsushita discloses,
wherein data input to the second cache area ([See 112(b)]) and data output from the second cache area (Matsushita, [0009 - A log structured area/second cache which stores data of the logical volume or the snapshot]) are stopped (Matsushita, [0099 – In Fig. 13, step S1307, the Snapshot creation program 304 increments the latest generation# 1101 of the created Snapshot, and updates the Snapshot generation management table 316 by setting the Snapshot creation time 1103, the Snapshot# 1104 which corresponds to the VOL# of the volume management table 311, and the status 1105=SUSPEND]; [0087 – As per Fig. 11, which shows the Snapshot generation management table 316, the status 1105 includes ‘SUSPEND’ which disables the synchronization of the data of the PVOL and the Snapshot]) when the second cache area and the directory information are replaced (Matsushita, [0105 - In Fig. 14, step S1401, the Snapshot creation program 304 refers to the Snapshot generation management table 316, and determines whether the PVOL includes a Snapshot in a SUSPEND status. If determination step S1402 is Yes, then go to step S1404, S1405, S1406-Update Mapping Table, S1407-Update Directory Table, S1408-destage; Here the Suspend status, updating the Mapping Table and Directory Table and destaging of data suggests changing the association and stopping the I/O]).
As per Claim 9, it is similar to claim 1 and therefore the same mappings are incorporated.
As per Claim 10, the rejection of claim 1 is incorporated and Matsushita, Matsushita-2 disclose,
wherein the at least one controller (Matsushita-2, [Fig. 1: controller 120]) stops data input to and data output from the second cache area (Matsushita-2, [0135 – In Fig. 16B, compression processing is started where the CPU load is low, there are few I/O requests from the host, thereby implying that I/O is low or suspended]) when replacing ([See 112(b)]) the second cache area of the replication source logical volume with the second cache area of the data sharing logical volume (Matsushita-2, [Fig. 14 does not recite host input, thereby implying suspended I/O]; [0124 – In Fig. 14, LU copy program 134 then copies the compressed data which is read in step S404 as is to the compressed S-VOL cache area in step S405. The LU copy program 134 then stores compressed data, which has been copied to the compressed S-VOL cache area, in the compressed S-VOL chunk 1304 in step S406, thereby implying data movement; Since data movement involves replacing, the recitation is a valid interpretation]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the high-speed copying of Matsushita-2 into the data replication of Matsushita, for the benefit managing a storage area which is provided by the storage unit as a pool, and assigns a storage area of the pool to the logical volume on the basis of the data I/O requests from the host, wherein the control unit divides the pool into a plurality of chunks, wherein the control unit compresses data which is written to the logical volume by the host and assigns one of the plurality of chunks to a compressed data logical volume which stores the compressed data (Matsushita-2, 0008-0009).
As per Claim 11, the rejection of claim 1 is incorporated and Matsushita, Matsushita-2 disclose,
wherein, before replacing the second cache area of the replication source logical volume with the second cache area of the data sharing logical volume ([See 112(b)]), the at least one controller copies directory information from the replication source logical volume to the data sharing logical volume (Matsushita-2, [Fig. 14]), wherein the directory information indicates a relationship between the first cache area and the second cache area (Matsushita-2, [Fig. 14: S408, update chunk management table]; [0071 – In Fig. 7, in the case of the Fig. 4, uncompressed LU chunk 410, information indicating 64 kB is stored in the page size field 1382]; [0073 – In Fig. 7, chunk management table, compressed LU mapping table address field 1384 stores addresses where the compressed LU mapping table corresponding to the chunk is stored]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the high-speed copying of Matsushita-2 into the data replication of Matsushita, for the benefit managing a storage area which is provided by the storage unit as a pool, and assigns a storage area of the pool to the logical volume on the basis of the data I/O requests from the host, wherein the control unit divides the pool into a plurality of chunks, wherein the control unit compresses data which is written to the logical volume by the host and assigns one of the plurality of chunks to a compressed data logical volume which stores the compressed data (Matsushita-2, 0008-0009).
Response to Arguments
The Applicant's arguments filed on December 23, 2025 have been fully considered, but they are not persuasive.
Applicant Argues: ‘Applicant has also canceled claims 2-4 without prejudice ….Support for this amendment…. [0123]-[0129] and [0131]-[0132] of the specification, as well as in FIGS. 16-20 of the drawings’. (Rem, Pg. 6)
Response: Claim 1 has been amended by reciting a system with at least one controller, inserting canceled claims 2-4 and adding a new limitation, thereby changing the scope of the claims. However the insertions are out-of-sequence/chronological order. The timeline of events is compromised. The insertions have introduced inconsistencies without adding clarity. Amended claim 1, as recited, is inconsistent with at least Figs. 15-16 of the spec. Also see the maintained and new 112(b)’s.
Applicant further argues: Additionally….Matsushita fails to disclose …."a storage area of the first cache area of a replication destination logical volume ….is associated with a storage area that is the second cache area of the data sharing logical volume and stores the data," as recited in claim 1’. (Rem, Pg. 7)
Response: This argument is incorrect.
The spec lacks written description support for the ‘association’ between the first cache area of the destination LV and the second cache area of the data-sharing LV.
Spec, Fig. 16, Para-0129 recites, ‘In step S1607, because step S1605 and step S1606 that are processing related to cache area replacement are completed, ….Finally, in step S1603-2, the volume replication program 511-1 copies the directory table 301 from the replication source volume 200 to the replication destination volume 201. Consequently, the data of the data sharing volume 202 referred to by the replication source volume 200 can be accessed from the replication destination volume 201’. There is no explicit disclosure of the cache areas. There is no explicit disclosure of the claimed ‘association’. Hence the recited ‘association’ is an extrapolation.
Matsushita discloses RoW. Matsushita, Fig. 1 shows how RoW works and the association mentioned above. Matsushita, Figs. 13-14 disclose the requirement, Fig. 14: step 1406- Update Mapping table, step 1407-Update Directory table, thereby implying the ‘association’. This is similar to the recitation in the spec.
Applicant further argues: ‘The DSVOL 102 of Matsushita is fundamentally different from the claim features…….., but does not disclose a separate data sharing logical volume with its own dedicated second cache area for storing compressed data shared between replication source and destination volumes….architecture’. (Rem, Pg. 7)
Response: This argument is incorrect.
Spec, Fig. 2, Para-0067 recites, ‘The storage system 100 includes a replication source volume 200, a replication destination volume 201, a data sharing volume 202, and a pool 205 as logical configurations’. Each volume is ‘cut-out’ from the pool, as recited in Para-0096.
Matsushita and the spec disclose Logical Volume Management. Though Matsushita, Fig. 1 and spec, Fig. 2 have different visual representations, they are similar in configuration and function. Both, the spec and Matsushita disclose snapshot creation and management.
DSVOL is a storage area. The controller maps and stores data (uncompressed and compressed) for each PVOL/SVOL and manages them via the tables.
The PVOL is a copy source LV, where data is received in the first cache area, and compressed data of the first cache area is stored in the second cache area. The SVOL is a point-in-time/PiT copy or snapshot of the PVOL data. Matsushita, Para-0050 recites, ‘The SS directory table 104 is a group of the directory tables 104-i (i=0,1,….n-1), and is provided for each Snapshot 101’.
With reference to the claims, the first snapshot is the data sharing volume/SVOL-1 and the second snapshot is the destination volume/SVOL-2.
Distributed memory is not shared memory. Matsushita, Para-0071 recites, ‘One entry of each directory table 103-i, 104-i corresponds to data in units of granularity (for instance, 256 KB) of the logical data of the PVOL 100’. Para-0054 recites, ‘in the DSVOL 102, the log structured area 106 storing the data of the PVOL 100 and the Snapshot 101 is distributed and arranged as a log structured area 106-i (i=0, 1,….n-1) in each DSVOL 102-i’. And Fig. 14, Para-0107 recites, ‘in S1405, the Snapshot creation program 304 copies the compressed data set, which was compressed in S1404, to the log structured area of the replication source VOL’.
These are some citations which suggest that the PVOL and the SVOL, each have a first storage/cache area which stores uncompressed data and a second storage/cache area which stores the compressed data of the first cache area.
Data movement between logical volumes is achieved by RoW and updating at least the directory table and the mapping table.
Applicant further argues:‘Matsushita is…..unrelated to "data stored in the second cache area of a …..source logical volume is moved to the second cache area of a data sharing logical volume’. (Rem, Pg. 8)
Response: This argument is incorrect. Please see the 112(b).
The claims do not recite dynamic data size calculation and corresponding data movement. As mentioned in the 112(b), the claims do not recite ‘which’ data is moved. Matsushita discloses Redirect-On-Write/Row, a method that moves data. Spec also recites RoW.
Matsushita, at least Figs. 13-14 recite that when the snapshot, which is a point in time copy of the PVOL data, is created, the data from the PVOL first cache area which is compressed and stored in the second cache area of the PVOL is ‘moved’ to the second cache area of the SVOL/data sharing volume and the directory table and the mapping table are updated.
Applicant further argues:‘Matsushita's snapshot creation does not swap actual compressed data from a….source's second cache area to a separate data sharing volume's second cache area as claimed’. (Rem, Pg. 8)
Response: This argument is incorrect.
The spec does not disclose a ‘swap’ operation and the steps in the swap. Merely reciting the word ‘swap’, without disclosing how the ‘swap’ is achieved results in a 112(a) for lack of written description support.
As an aside, a typical ‘swap’ involves exchanging the values of two variables, and also requires a temporary storage location to prevent data loss. There are 3 steps, namely, store the first value in the temporary variable, move the second value to the first variable, and move the temporary value to the second variable. There is no disclosure in the spec of ‘data movement’ involving a ‘swap’.
Swapping addresses also requires a temporary location. There is no disclosure of the steps disclosing how addresses/cache areas are ‘swapped’.
Applicant further argues:‘This copying of directory tables is fundamentally different from the claimed movement of compressed data between cache areas. More particularly, claim 1 is different….because the data is moved virtually through swapping or replacing the cache area itself’. (Rem, Pg. 8)
Response: Please see the 112(b).
Claim 1 recites, ‘wherein the at least one controller performs data movement….by replacing the second cache area (address-1) of the replication source logical volume with the second cache area (address-2) of the data sharing logical volume’. As explained in the 112(b), the ‘replacing’ results in data loss.
The spec supports the data loss because Para-0127 recites, ‘in step S1605, the volume replication program 511-1 replaces a data sharing cache area 204-0 in which the data of the replication source volume 200 is stored with a data sharing cache area 204-2 of the data sharing volume’.
Matsushita discloses creating the first snapshot/SVOL-1/data sharing volume, updates the mapping tables, and directory tables, thereby disclosing the claimed ‘data movement’.
Applicant further argues:‘Furthermore,…. Matsushita's append processing does not teach "when data is written in the first cache area of the replication source logical volume…., the data is compressed and stored in the second cache area of the data sharing logical volume….," as recited in claim 1’. (Rem, Pg. 8)
Response: This argument is incorrect. Please see the 112(b).
The claim recites that when data is written in the first cache area of the source LV, the data is compressed and stored in the second cache area of the data sharing LV, without reciting any ‘data movement’ for the transfer. There is also no written description support in the spec for the recited ‘transfer’.
Matsushita, Fig. 16, shows data received from the host is written to the first cache area of the PVOL, and is compressed and stored in the second cache area/log structured area of the PVOL. When the snapshot, which is a point in time copy of the PVOL, is created, the compressed data in the PVOL is ‘copied’ to the second cache area of the data sharing cache/SVOL and tables updated. Since the spec does not recite how the ‘transfer’ is achieved, Matsushita recites a valid method of ‘transfer’.
Matsushita, Fig. 13, Para-0096 recites that the Snapshot creation program 304 performs the append processing of dirty data. As explained in the 112(b), sizes of ‘data written to the first cache area’ or ‘write that updates data’, ‘update data’, ‘data before update, ‘data after update’ etc., are not tracked. Therefore it is valid to use Fig. 14, append processing to process ‘dirty data’ as a valid interpretation for the undisclosed data types and data tracking.
Applicant further argues: ‘Matsushita's append processing compresses data and stores it in a log structured area,….not the same as storing data in a second cache area of a data sharing logical volume that is separate from both the replication source and destination volumes’. (Rem, Pg. 8)
Response: This argument is incorrect.
As mentioned above, Matsushita and the spec disclose snapshot creation and management. So the data sharing volume is the first snapshot and the destination volume is the second snapshot.
That said, Matsushita, Para-0054 recites, ‘in the DSVOL 102, the log structured area 106 storing the data of the PVOL 100 and the Snapshot 101 is distributed and arranged as a log structured area 106-i (i=0, 1,….n-1) in each DSVOL 102-i’. This clearly recites that the PVOL and the snapshot/SVOL/data sharing LV, each have their own log structured area 106/second cache area. The controller manages each area as needed.
Applicant further argues: Specifically, regarding claim 7, for example, ….recite "wherein the controller performs data movement…. by: replacing the second cache area of the logical volume and the second cache area of the data sharing logical volume…. (Rem, Pg. 9)
Response: Amended claim 7 has issues. Please see the 112(b).
Whether it is ‘replacing … with ….’, as recited in amended claim 1 or ‘replacing … and ….’, as recited in amended claim 7, both methods recite data loss.
Applicant further argues:‘By way of example, Hosogi describes a different replication system with primary and secondary storage systems using different compression algorithms’. (Rem, Pg. 10)
Response: This argument is incorrect.
Claim 1 submitted as part of the original disclosure recited ‘a storage system with a plurality of volumes and a plurality of controllers’. It is well known in the prior art that a single storage system can be comprised of multiple, smaller storage systems. In addition, claim 1 did/does not recite how the ‘plurality of logical volumes’ are associated with the physical storage. Spec, Para-0070 recites, ‘The pool 205 is a logical storage area based on at least one RAID group’. It is well-known that a RAID group is a group of physical drives that work together under a specific RAID level, e.g., RAID 5, 6, 10. Since spec, Para-0049 recites that the computer system can be a distributed system, it suggests that the physical drives can be spread across different systems in a distributed manner. Therefore Hosogi is valid prior art.
Applicant further argues: ‘Specifically….claim 5…. by deleting the replication source logical volume,….through swapping between the source volume and the data sharing volume (….volume delete)’.(Rem, Pg. 10)
Response: Please see the 112(b).
Applicant further argues:‘Each new claim submitted herein in patentable for its incorporation of any parent claims, as well as for the patentable subject matter recited therein’. (Rem, Pg. 10)
Response: Please see the 112(b)’s for claims 11.
Examiner Notes:
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
1.’Method for exchanging data between volumes of storage system’, Hitachi, US20070088929A1- A temporary storage area for data exchange is provided, then the position of the data to be exchange is located, data is read out from the located position in first or second volume to store in the temporary area, and data in the temporary area is written to the located position of the volume different from the volume from which the data is read out. During migration, if there is stored active data on the second destination volume, then the data is exchanged between volumes using the temporary area.
2.’Volume management apparatus, volume management method, and volume management program’, Hitachi, US20200150866A1- A storage system stores volumes. The volume includes a first volume and a second volume which is a volume copied from the first volume by snapshot. When a write request is received, processor determines whether a volume of a copy source related to a target volume of the write request is a volume of which a storage region is a valid region where a data amount reduction process is applied, the processor switches and performs a process of creating the second volume related to the snapshot.
Conclusion
THIS ACTION IS MADE FINAL. 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 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
Prosecution Insights