DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Amendment
Applicant’s response filed 23 December 2025 has been considered and entered. Accordingly, claims 1-21 are pending in this application. Claim 8 is currently amended; claims 1-7 and 9-21 are as previously presented.
Terminal Disclaimer
The terminal disclaimer filed on 23 December 2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of US Pat. No. 11,100,051 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 15-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a system having “a first computing device” and “a second user device” as its only components. Neither the claim nor the specification explicitly define or limit a computing device to include hardware elements, e.g. processors and memory. In contrast, Applicant’s specification readily recites that the systems disclosed can comprise “an entirely software embodiment” (see [0014]). Applicant’s specification, like the claim, describes the system as including generically described, non-limiting, devices. Likewise, the definition of a “device” (See IEEE 100: The Authoritative Dictionary of IEEE Standards Terms. Seventh edition. Standards Information Network IEEE Press. 2000. pp 297) includes “(10) (software) A mechanism or piece of equipment designed to serve a purpose or perform a function” [emphasis added]. Accordingly, the claim “system” comprising only generically recited “computing device[s]” is reasonably interpreted as covering embodiments including those implemented entirely in software, e.g. virtual devices or other software components, and thus is directed to software per se.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-21 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Johnson et al. (US 2010/0306180 A1), hereinafter Johnson, in view of Mahalingam et al. (cited in IDS filed 04/14/2025)(US 9,223,793 B1), hereinafter Mahalingam.
As to claim 1, Johnson discloses a method comprising:
receiving, from a first user device, a first request to record a first version of content (Fig. 9, #250, 252; [0174], Director device receives a request to store, i.e. record, an original file, i.e. a first version of content.);
receiving, from a second user device, a second request to record a second version of the content (Fig. 9, #256-260; [0175], [0176], The director device receives a second request to record an edited version of the file, i.e. a second version of the content.);
storing, at a master node, a a copy of the first version of the content and a copy of the second version of the content (Fig. 9; [0176], The director device stores both versions of the file at the director archive, i.e. a master node.);
based on a third request for the first version of the content from the first user device,
sending, to the first user device, the file comprising the first version of the content (Fig. 9, #262-266; [0178], The first user device requests the first version of the content (original file) and it is sent thereto from the director device.).
Johnson does not disclose determining, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content;
storing, at a master node, a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content;
generating, based on a third request for the first version of the content from the first user device, a reconstructed file that includes portions of the master file associated with the first version of the content; and
sending, to the first user device, the reconstructed file.
Although Johnson does disclose an ability to deduplicate content (Fig. 4, #112; [0125]-[0126]).
However, Mahalingam discloses determining, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content (Figs. 3A-3C and 6; Col. 6, Lines 6-30; Col. 9, Lines 30-48; A first version of a file (version X), i.e. a first version of the content, is compared to a second version of the file (version X+1), i.e. a second version of the content to identify unique and matching blocks of data between them.);
storing, at a master node, a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content (Figs. 4 and 6; Col. 4, Lines 54-62; Col. 5, Lines 6-15; Col. 8, Lines 19-29, A master file is stored in remote storage comprising only individual instances of the unique blocks from each version.);
generating, based on a third request for the first version of the content from the first user device, a reconstructed file that includes portions of the master file associated with the first version of the content (Fig. 5; Col. 8, Lines 30-53, The master file is read to obtain the corresponding blocks for a requested version of content.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Johnson with the teachings of Mahalingam by modifying Johnson such that instead of the director device receiving and then storing to archive storage each entire version of content, that the deduplication module of the director device is modified to deduplicate received content versions like is done by the CDP module using local storage in Mahalingam, and then store all unique blocks of content in a master file in the archive storage like is done with the remote storage of Mahalingam. It would have then been obvious to modify Johnson to use the director device to generate a reconstructed file from the master file, like is done in Mahalingam, and return the reconstructed file to the requesting user device of Johnson. Thus, as combined, rendering obvious the entirety of the claim. Said artisan would have been motivated to do so in order to reduce the amount of data usage and requirements for the archive storage of Johnson, like with the remote storage of Mahalingam (Mahalingam, Col. 5, Lines 12-18; Col. 6, Lines 10-14).
As to claim 8, Johnson discloses a non-transitory computer readable medium storing processor executable instructions that, when executed by at least one processor, cause the at least one processor to ([0018], [0188]):
receiving, from a first user device, a first request to record a first version of content (Fig. 9, #250, 252; [0174], Director device receives a request to store, i.e. record, an original file, i.e. a first version of content.);
receive, from a second user device, a second request to record a second version of the content (Fig. 9, #256-260; [0175], [0176], The director device receives a second request to record an edited version of the file, i.e. a second version of the content.);
store, at a master node, a a copy of the first version of the content and a copy of the second version of the content (Fig. 9; [0176], The director device stores both versions of the file at the director archive, i.e. a master node.);
based on a third request for the first version of the content from the first user device,
send, to the first user device, the file comprising the first version of the content (Fig. 9, #262-266; [0178], The first user device requests the first version of the content (original file) and it is sent thereto from the director device.).
Johnson does not disclose determine, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content;
store, at a master node, a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content;
generate, based on a third request for the first version of the content from the first user device, a reconstructed file that includes portions of the master file associated with the first version of the content; and
send, to the first user device, the reconstructed file.
Although Johnson does disclose an ability to deduplicate content (Fig. 4, #112; [0125]-[0126]).
However, Mahalingam discloses determine, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content (Figs. 3A-3C and 6; Col. 6, Lines 6-30; Col. 9, Lines 30-48; A first version of a file (version X), i.e. a first version of the content, is compared to a second version of the file (version X+1), i.e. a second version of the content to identify unique and matching blocks of data between them.);
storing, at a master node, a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content (Figs. 4 and 6; Col. 4, Lines 54-62; Col. 5, Lines 6-15; Col. 8, Lines 19-29, A master file is stored in remote storage comprising only individual instances of the unique blocks from each version.);
generating, based on a third request for the first version of the content from the first user device, a reconstructed file that includes portions of the master file associated with the first version of the content (Fig. 5; Col. 8, Lines 30-53, The master file is read to obtain the corresponding blocks for a requested version of content.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Johnson with the teachings of Mahalingam by modifying Johnson such that instead of the director device receiving and then storing to archive storage each entire version of content, that the deduplication module of the director device is modified to deduplicate received content versions like is done by the CDP module using local storage in Mahalingam, and then store all unique blocks of content in a master file in the archive storage like is done with the remote storage of Mahalingam. It would have then been obvious to modify Johnson to use the director device to generate a reconstructed file from the master file, like is done in Mahalingam, and return the reconstructed file to the requesting user device of Johnson. Thus, as combined, rendering obvious the entirety of the claim. Said artisan would have been motivated to do so in order to reduce the amount of data usage and requirements for the archive storage of Johnson, like with the remote storage of Mahalingam (Mahalingam, Col. 5, Lines 12-18; Col. 6, Lines 10-14).
As to claim 15, Johnson discloses a system comprising:
a computing device configured to (Fig. 1, #14; Fig. 4; [0020]):
receiving, from a first user device, a first request to record a first version of content (Fig. 9, #250, 252; [0174], Director device receives a request to store, i.e. record, an original file, i.e. a first version of content.);
receive, from a second user device, a second request to record a second version of the content (Fig. 9, #256-260; [0175], [0176], The director device receives a second request to record an edited version of the file, i.e. a second version of the content.);
store, at a master node, a a copy of the first version of the content and a copy of the second version of the content (Fig. 9; [0176], The director device stores both versions of the file at the director archive, i.e. a master node.);
based on a third request for the first version of the content from the first user device,
send, to the first user device, the file comprising the first version of the content (Fig. 9, #262-266; [0178], The first user device requests the first version of the content (original file) and it is sent thereto from the director device.) and
the first user device configured to send the first request to record the first version of content and the third request for the first version of the content (Fig. 9, #250 and 262; [0174], [0177]).
Johnson does not disclose determine, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content;
store, at a master node, a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content;
generate, based on a third request for the first version of the content from the first user device, a reconstructed file that includes portions of the master file associated with the first version of the content; and
send, to the first user device, the reconstructed file.
Although Johnson does disclose an ability to deduplicate content (Fig. 4, #112; [0125]-[0126]).
However, Mahalingam discloses determine, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content (Figs. 3A-3C and 6; Col. 6, Lines 6-30; Col. 9, Lines 30-48; A first version of a file (version X), i.e. a first version of the content, is compared to a second version of the file (version X+1), i.e. a second version of the content to identify unique and matching blocks of data between them.);
storing, at a master node, a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content (Figs. 4 and 6; Col. 4, Lines 54-62; Col. 5, Lines 6-15; Col. 8, Lines 19-29, A master file is stored in remote storage comprising only individual instances of the unique blocks from each version.);
generating, based on a third request for the first version of the content from the first user device, a reconstructed file that includes portions of the master file associated with the first version of the content (Fig. 5; Col. 8, Lines 30-53, The master file is read to obtain the corresponding blocks for a requested version of content.).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Johnson with the teachings of Mahalingam by modifying Johnson such that instead of the director device receiving and then storing to archive storage each entire version of content, that the deduplication module of the director device is modified to deduplicate received content versions like is done by the CDP module using local storage in Mahalingam, and then store all unique blocks of content in a master file in the archive storage like is done with the remote storage of Mahalingam. It would have then been obvious to modify Johnson to use the director device to generate a reconstructed file from the master file, like is done in Mahalingam, and return the reconstructed file to the requesting user device of Johnson. Thus, as combined, rendering obvious the entirety of the claim. Said artisan would have been motivated to do so in order to reduce the amount of data usage and requirements for the archive storage of Johnson, like with the remote storage of Mahalingam (Mahalingam, Col. 5, Lines 12-18; Col. 6, Lines 10-14).
As to claims 2, 9, and 16, the claims are rejected for the same reasons as claims 1, 8, and 15 above. In addition, Johnson, as previously modified with Mahalingam, discloses determining, based on an index file, the portions of the master file associated with the first version of the content (Mahalingam, Fig. 5; Col. 8, Lines 30-40; A version map file for the requested version of content, i.e. an index file, is used to determine the portions of the master file 220 needed to restore the requested version. This is used for any version.).
As to claims 3, 10, and 17, the claims are rejected for the same reasons as claims 2, 9, and 16 above. In addition, Johnson, as previously modified with Mahalingam, discloses generating the index file that identifies the portions of the master file associated with the first version of the content (Mahalingam, Figs. 3A-3C, #210B; Col. 7, Lines 35-38; Col. 8, Lines 1-23, E.g. Appending master block references to version map file 210B to generate it and store it at local storage 120, i.e. an edge node.).
As to claims 4, 11, and 18, the claims are rejected for the same reasons as claims 2, 9, and 16 above. In addition, Johnson, as previously modified with Mahalingam, discloses storing the index file at an edge node associated with the first user device (Mahalingam, Figs. 3A-3C, #210B; Col. 7, Lines 35-38; Col. 8, Lines 1-23, E.g. Appending master block references to version map file 210B to generate it and store it at local storage 120, i.e. an edge node. Since, as modified with Johnson, this would be connected with the director device like the CDP module of Mahalingam, and is thus associated with the first user device that can initiate requests thereto.).
As to claims 5, 12, and 19, the claims are rejected for the same reasons as claims 1, 8, and 15 above. In addition, Johnson, as previously modified with Mahalingam, discloses storing the reconstructed file at an edge node associated with the first user device (Mahalingam, Fig. 5, #110; Col. 8, Lines 30-47; E.g. Generating restored file at storage volume 110, i.e. an edge node. Since, as modified with Johnson, this would be connected with the director device like the CDP module of Mahalingam, and is thus associated with the first user device that can initiate requests thereto.).
As to claims 6, 13, and 20, the claims are rejected for the same reasons as claims 1, 8, and 15 above. In addition, Johnson, as previously modified with Mahalingam, discloses generating, based on a fourth request for the second version of the content from the second user device, a second reconstructed file that includes portions of the master file associated with the second version of the content (Johnson, Fig. 9, #262-266; [0178], As readily apparent, any user device can request a desired version of the content and it is sent thereto from the director device.; Mahalingam, Fig. 5; Col. 8, Lines 30-47, As previously combined, the requested version is reconstructed and sent to the requesting device of Johnson using the techniques of Mahalingam.); and
sending, to the second user device, the second reconstructed file (Johnson, Fig. 9, #262-266; [0178], As readily apparent, any user device can request a desired version of the content and it is sent thereto from the director device.).
As to claims 7, 14, and 21, the claims are rejected for the same reasons as claims 1, 8, and 15 above. In addition, Johnson, as previously modified with Mahalingam, discloses wherein each of the one or more unique portions of the content and the one or more and the one or more common portions of the content include a unique fragment of the content (Mahalingam, Figs. 3A-3E; Col. 6, Lines 56-67; Col. 7, Lines 1-5; As previously set forth, the master file contains a single instance of all unique and common blocks from each version. Thus each block in the master file is a unique, non-duplicate, block. Each block is deduplicated on a byte, i.e. fragment level. Thus the unique blocks each include unique fragments (bytes).).
Response to Arguments
Applicant's arguments filed 23 December 2025 have been fully considered but they are not fully persuasive. For Examiner’s response, see discussion below:
(a) Applicant’s arguments, see page 7, with respect to the objection to claim 8 have been fully considered and are persuasive. The objection to claim 8 has been withdrawn in view of Applicant’s amendments to the claim.
(b) Applicant’s arguments, see page 7, with respect to the double patenting rejections of claims 1-21 have been fully considered and are persuasive. The double patenting rejections of claims 1-21 have been withdrawn in view of Applicant’s filing of the accepted terminal disclaimer discussed above.
(c) At pages 7-8, with respect to the rejection of claim 15 under 35 USC §101, Applicant argues that the claim recites two components are part of the system, “a computing device” and a “first user device.” Applicant argus that the plain meaning of a device a physical component configured to perform the recited functions.
As to (c), Applicant’s arguments have been fully considered, but are not persuasive. Applicant has provided no evidence of any physical component in the claimed system. It is well known in the art that any physical computer element can be implemented virtually, i.e. in software. Thus the plain meaning of a “device” can include both physical computer components, as well as those implemented in software to emulate the physical components. Applicant’s specification also explicitly recites that the systems disclosed can comprise “an entirely software embodiment” (see [0014]). Applicant’s specification, like the claim, describes the system as including generically described, non-limiting, devices. Accordingly, the claim “system” comprising only generically recited “computing device[s]” is reasonably interpreted as covering embodiments including software, e.g. virtual devices or other software components, and thus is directed to software per se.
(d) At page 8, with respect to the rejection of claim 15 under 35 USC §101, Applicant argues that §101 does not require recitation of computer components, so long as if falls within one of the four statutory categories. Applicant then falls back on the argument that the claim recites physical components.
As to (d), Applicant’s arguments have been fully considered but are not persuasive. As set forth in (c) above, the claim is not directed necessarily to any physical embodiment, but includes an “entirely software embodiment” as per [0014] of Applicant’s specification. Software is not one of the four statutory categories. Thus, the claim does not fall with in any of the four statutory categories as required by 35 USC §101.
(e) At page 8, with respect to the rejection of claim 15 under 35 USC §101, Applicant argues that the specification does not need to explicitly define or limit a computing device to include hardware elements where a term has an established meaning to one ordinary skill in the art.
As to (f), Applicant’s arguments have been fully considered but are not persuasive. Again, the plain meaning of “device” does NOT limit a “device” to a physical, hardware, element. Rather, the plain meaning includes one or both of physical and software embodiments. Again, commensurate with Applicant’s own specification as set forth above which states the disclosed system can be hardware, software, or both. Applicant is further guided to the definition of a “device” in the IEEE dictionary cited in the rejection of the claim above. Definition (10) states that a device is “(software) A mechanism or piece of equipment designed to serve a purpose or perform a function.” Applicant is unable to articulate any supporting rationale from their specification that a device must be a physical component, nor does Applicant provide any evidence of the plain meaning they rely on. In contrast, Applicant’s specification contradicts Applicant’s improperly limited interpretation, and this is further compounded by the cited IEEE definition of the term “device” being defined as inclusive of software as set forth above. Thus, it is clear that the breadth of Applicant’s claimed devices include entirely software embodiments as set forth in the rejection.
(f) At page 8, with respect to the rejection of claim 15 under 35 USC §101, Applicant argues that the claim does not preempt any abstract idea, and is not performed mentally or with software alone.
As to (f), Applicant’s arguments have been fully considered but are not persuasive. First, the rejection under 35 USC §101 does not reject the claim as being directed to an abstract idea. As such, this argument is moot. Second, as set forth in the rejection under 35 USC §101 above, and also discussed in (c)-(e) above, the claim is in fact directed to embodiments implemented entirely in software. As such the rejection of claims 15-21 under 35 USC §101 are proper and maintained.
(g) At pages 9-11, with respect to the rejection of independent claims 1, 8, and 15 under 35 USC §103, Applicant argues that Mahalingam does not disclose or suggest “determining, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content.” Applicant argues that Mahalingam’s comparison is limited to determining, for each block of a single new version of a local data file, whether that block matches one of the master blocks in a previous version master file for the same local file. That Mahalingam does not determine the claimed features, and appears to then attempt to insert references to the first user device and second user device.
As to (g), Applicant’s arguments have been fully considered but are not persuasive. Applicant’s arguments appear to boil down to that Mahalingam performs file version comparisons at a block level, and that this is somehow not what is claimed. Applicant has not made any clear argument to what is actually different than the claimed language. As stated in the rejection, Mahalingam discloses determining, based on a comparison between the first version of the content and the second version of the content, one or more unique portions of the content and one or more common portions of the content among the first version of the content and the second version of the content (Figs. 3A-3C and 6; Col. 6, Lines 6-30; Col. 9, Lines 30-48; A first version of a file (version X), i.e. a first version of the content, is compared to a second version of the file (version X+1), i.e. a second version of the content to identify unique and matching blocks of data between them.). Here the blocks are clearly analogous to “portions” being claimed. First blocks/portions of a version to be backed up from a user device to remote storage are compared to those of the previous version, e.g. as explicitly stated in Col. 6, Lines 24-30. From this, Mahalingam determines unique blocks/portions of the new version of the file (e.g. Col. 6, Lines 20-21, “a full block of data 202F not matching any master blocks in the master file 220”) and common blocks portions (e.g. Col. 6, Lines 15-19) as part of the de-duplication of the data in the new version of the data file (e.g. Col. 6, Lines 6-36, Col. 9, Lines 30-48, Which also cites to Figs. 7A-7B with more details on de-duplication process.).
Thus, Mahalingam is performing every feature of the claimed determining step argued by Applicant. Mahalingam does not disclose a second user device being associated with the second version as Applicant appears to try and argue. However, this feature is not relied upon by Mahalingam. Rather, Johnson discloses the second version from the second user, and the combination with Johnson renders obvious two versions of content from two user devices as claimed using de-duplication from Mahalingam to render the claim obvious as a whole as discussed in the rejections above and also in (h) below. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
(h) At pages 11-13, with respect to the rejection of independent claims 1, 8, and 15 under 35 USC §103, Applicant argues that the combination of Johnson and Mahalingam is improper. The substance of Applicant’s argument begins at the end of page 12 in arguing that the references are technologically disjointed with Mahalingam being directed to continuous data protections where each new version of a file is deduplicated against a previous version master file on the same machine. Applicant argues that Johnson is directed to multi-user content management where different user devices upload whole file versions for storage and later retrieval. Applicant’s arguments follow then that the references do not disclose the same features as the other, and the combination goes beyond the predictable use of prior art under KSR.
As to (h), Applicant’s arguments have been fully considered but are not persuasive. Applicant’s arguments that the references do not disclose the same features as each other is a reason they are obvious to be combined, i.e. to modify and improve the other. This is the very basis of 35 USC §103. Both references are analogous with each other and the claims in that they are directed to managing multiple versions of a file for storage and retrieval. Johnson allows for multiple users to store different versions of a given file, the system stores entire copies of the versions of the given file to be returned upon request from a director device to a user device to retrieve a given version (Fig. 9, [0174]-[0176]). Mahalingam discloses storing multiple versions of a given file by utilizing a master file that includes one instance of each of the one or more unique portions of the content and one instance of each of the one or more common portions of the content between different versions of the file (Figs. 4 and 6; Col. 4, Lines 54-62; Col. 5, Lines 6-15; Col. 8, Lines 19-29, A master file is stored in remote storage comprising only individual instances of the unique blocks from each version.). Like the user storing the file on the director device of Johnson, Mahalingam stores the versions from the user computer to remote storage (Fig. 1; Col. 6 Lines 10-14). Also like Johnson, Mahalingam returns requested full versions of a file to a user, but by reconstructing the file using the master file (Fig. 5; Col. 8, Lines 30-53, The master file is read to obtain the corresponding blocks for a requested version of content.), again instead of maintaining separate complete versions of each file. Mahalingam does this for the purpose to “reduce the amount of data usage on the remote storage, and thus potentially reducing costs (Fig. 1; Col. 6 Lines 10-14). Thus, it would have been obvious to use the deduplication features in Mahalingam at the director device of Johnson to deduplicate the data at the director device while still enabling the users of Johnson to store and retrieve different versions of the same file. Said artisan being motivated to do so in order to reduce the amount of data usage and requirements for the archive storage of Johnson, like with the remote storage of Mahalingam (Mahalingam, Col. 5, Lines 12-18; Col. 6, Lines 10-14).
Thus, Johnson and Mahalingam are clearly not “technologically disjointed,” and the differences in their disclosures provide an obvious way to improve Johnson with teachings found in Mahalingam with a motivation provided explicitly from Mahalingam. Accordingly, the combination is proper and maintained.
(i) At page 13, with respect to the rejections of dependent claims 2-7, 9-14, and 16-21 under 35 USC §103, Applicant argues that the claims are non-obvious over the prior art for at least the same reasons previously argued with respective independent claims 1, 8, and 15 above.
As to (i), Applicant’s arguments have been fully considered but are not persuasive for at least the reasons set forth in (g) and (h) above with respect to claims 1, 8, and 15, and also for the respective reasons set forth in the rejections of claims 2-7, 9-14, and 16-21 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Anglin et al. (US 8,370,297 B2) discloses restoring deduplicated files from a server to a client, wherein the server maintains a chunk index of deduplicated chunks of files, and reconstructing a requested file from chunks on the server as well as chunks already present on the client (Abstract).
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 JAMES E RICHARDSON whose telephone number is (571)270-1917. The examiner can normally be reached Mon-Fri 9:00-5:30.
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, Sherief Badawi can be reached at (571) 272-9782. 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.
/James E Richardson/Primary Examiner, Art Unit 2167