Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
DETAILED ACTION
Arguments and amendment filed 7/29/2025 have been examined.
Claims 1 and 4 have been amended.
In this Office Action, claims 1-9 are currently pending.
This Office Action is Final.
Response to Arguments
Applicant’s arguments with respect to claim(s) and the previous rejection under 35 USC 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s arguments, with respect to the rejection under 35 USC 101 have been fully considered and are persuasive. The rejection under 35 USC 101 has been withdrawn.
As to arguments concerning the double-patenting rejection, as no terminal disclaimer has been filed the double patenting rejection remains.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1‐9 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1‐10 of U.S. Patent No. 11,748,201. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 is generic to all that is recited in claim 1 of U.S. Patent No. 11,748,201. That is, claim 1 of U.S. Patent No. 11,748,201 falls entirely within the scope of claim 1 or, in other words, claim 1 is anticipated by claim 1 of U.S. Patent No. 11,748,201.
Specifically, because instant claim 1 recites: “the structured data representation associated with the at least one file system interface comprises a set of Uniform Resource Identifier (URI)-addressable cloud nodes that contain information passed by that file system interface about its associated local file system;" this limitation is/are a species of the generic category defined by “the structured data representation associated with the at least one file system interface comprises a Uniform Resource Identifier (URI)-addressable cloud node that contains information passed by that file system interface about its associated local file system, together with an access control,” (see claim 1, U.S. Patent No. 11,748,201) the process of
claim 1 reciting “the structured data representation associated with the at least one file system interface comprises a set of Uniform Resource Identifier (URI)-addressable cloud nodes that contain information passed by that file system interface about its associated local file system;” is anticipated by claim 1 of U.S. Patent No. 11,748,201 reciting “the structured data representation associated with the at least one file system interface comprises a Uniform Resource Identifier (URI)-addressable cloud node that contains information passed by that file system interface about its associated local file system, together with an access control;”.
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, 4-9 is/are rejected under pre-AIA 35 U.S.C.103(a) as being unpatentable over Nickolov et al., US Pub. No. 2011/0153697 A1, in view of Miller et al., US Pub. No. 2005/0004993 A1, in view of Antosz et al., US Pub. No. 2009/0249284 A1.
As to claim 1, Nickolov discloses:
a method to provide storage for an enterprise in association with one or more cloud-based storage service providers,
(Nickolov abstract: According to different embodiments, various aspects may be directed to
different embodiments of virtualized filer appliances and/or filer applications which may be used
for facilitating manipulation of virtualized storage volumes and/or file systems of one or
more different types of operating systems (OSs) implemented on distributed computer systems.;
see also [0101] In at least one embodiment, one or more aspects and/or features
described herein may be implemented in a manner which utilizes 3Tera's Applogic™ grid
operating system for providing a true distributed utility computing services.)
comprising:
providing the enterprise one or more file system interfaces,
(Nickolov abstract: In one embodiment, the filer appliance may include one or more virtual
interfaces for interfacing with one or more virtual volumes and/or one or more other virtual
appliances, virtual applications, etc.; see also [0140]),
wherein at least one file system interface executes either as a virtual machine or on physical hardware and is configured to represent, to the enterprise, a local file system whose data is stored in the one or more cloud-based storage service providers
(Nickolov [0141] Secondly, the underlying 9P protocol was used to remove the difference
between local and remote files ( except for a possible difference in latency or in throughput).
This has the advantage that a device or devices, represented by files, on a remote computer
could be used as though it were the local computer's own device(s). This means that under Plan
9, multiple file servers provide access to devices, classing them as file systems.; see also
abstract: In one embodiment, a filer appliance may be implemented as a virtual machine which
is configured or designed to handle managing of one or more volumes. In one embodiment, the
filer appliance may include one or more virtual interfaces for interfacing with one or more virtual
volumes and/or one or more other virtual appliances, virtual applications, etc.);
While Nickolov discloses:
represent, to the enterprise, a local file system whose data is stored in the one or more cloud-based storage service providers;
Nickolov does not disclose:
represent, to the enterprise, a local file system whose data is stored in the one or more cloud-based storage service providers as a write-once, object-based file system;
wherein the one or more file system interfaces export versions of their local file system data in an encrypted manner and as a structured data representation
to the write once, object-based file system in the one or more cloud-based storage service providers,
wherein a given version of the structured data representation associated with the at least
one file system interface comprises a set of Uniform Resource Identifier (URl)-addressable
cloud nodes that contain information passed by that file system interface about its
associated local file system;
However, Miller discloses:
a local file system whose data is stored in the one or more cloud-based storage service providers as a write-once, object-based file system;
(Miller teaches a distributed write-once object storage/retrieval system
See [0021] Exemplary methods, systems, and devices are disclosed for managing objects in an instant messaging system. Generally, an object store provides a write-once, read-many
object storage and retrieval system, wherein the objects are immutable. The object store provides an interface through which a feature application can store or retrieve an object
using an object name;
see also [0065] FIG. 7 illustrates another exemplary object retrieval scenario 700 in which requested object data is located at a peer computer. A feature 702 running on a client,
client 1, requests object data from an object store 704 by passing in an object name having a hash value and location data. The object store 704 determines that the requested object data is not in a local cache 706. By parsing the object name, the object store 704 determines that the requested object data is at a client computer, client 2.;
see also [0017] Various exemplary methods may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules
may be located in both local and remote memory storage devices.)
wherein the one or more file system interfaces export versions of their local file
system data in an encrypted manner and as a structured data representation
(Miller teaches an interface for providing encrypted and condensed representations/message digests/hashed objects with fingerprints for object storage/retrieval, i.e. “wherein the one or more file system interfaces export versions of their local file system data in an encrypted manner and as a structured data representation”
see [0027] the object store 116 can provide degrees of data security by encrypting data, such as by hashing identifier data associated with an object.; see also [0021] The object store provides an interface through which a feature application can store or retrieve an object using an object name;
See also [0040] SHA1 is an algorithm for computing a 'condensed representation' of the object data. The 'condensed representation' is of fixed length and is known as a 'message digest' or 'fingerprint'. A common fixed length of the Hash1 field is 160 bits, which virtually guarantees that the Hash1 value will be unique for every object. The uniqueness of the Hash1 value enables the Hash1 value to act as a 'fingerprint' of the object data, to ensure data integrity and allow for data
comparison checking. For instance, when object data is downloaded, the Hash1 value can be calculated and compared to a previous Hash1 value to guarantee that the object data is unaltered. The Hash1 value can also be used as an index into a cache to locate the previously stored object data.)
to the write once, object-based file system in the one or more cloud-based storage service providers,
(Miller teaches a distributed write-once object storage/retrieval system see [0055] FIG. 4 is a retrieve object operation flow 400 having exemplary operations for retrieving an object that may be stored at any of various locations on a computer network. As discussed with regard to FIG. 1, objects and object data may be stored in a local cache, in a local file system, in network storage (e.g., on a disk on network server), and/or on a remote client, or peer computer.;
See also [0021] Exemplary methods, systems, and devices are disclosed for managing objects in an instant messaging system. Generally, an object store provides a write-once, read-many
object storage and retrieval system, wherein the objects are immutable. The object store provides an interface through which a feature application can store or retrieve an object
using an object name;
see also [0017] Various exemplary methods may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules
may be located in both local and remote memory storage devices)
wherein a given version of the structured data representation associated with the at least
one file system interface comprises a set of Uniform Resource Identifier (URl)-addressable
cloud nodes that contain information passed by that file system interface about its
associated local file system;
(Miller teaches using URI addressed objects to retrieve objects stored at remote locations on a network, i.e. “a given version of the structured data representation associated with the at least
one file system interface comprises a set of Uniform Resource Identifier (URl)-addressable
cloud nodes that contain information passed by that file system interface about its
associated local file system”
See [0051-0056] [0051] The Creator field and the Location field will enable the ObjectStore to
later retrieve the object data from a location other than the local cache if necessary.
[0052] The name returned in the returning operation 312 may be in a specified format, such as Uniform Resource Identifier (URI) and Uniform Resource Name (URN). A URI is a character string that can identify any kind of resource on the Internet, including images, text, video, audio
and programs. A common version of a URI is a Uniform Resource Locator (URL). A URN is defined to be a permanent, globally unique name for an object. An exemplary URI
and URN are shown below: [0053] URI: //[Creator]/[Type]/[Hashl]/[Hash2]?fn= [FriendlyName ]&URL=[Location ]; [0054] URN: [Type]: [Creator]: [FriendlyName]: [Location]: [Hash1]: [Hash2]
[0055] FIG. 4 is a retrieve object operation flow 400 having exemplary operations for retrieving an object that may be stored at any of various locations on a computer network. As discussed with regard to FIG. 1, objects and object data may be stored in a local cache, in a local file
system, in network storage (e.g., on a disk on network server), and/or on a remote client, or peer computer. The operation flow 400 responds to a request for an object by determining where the object is located, and then retrieving the object from that location. [0056] A requesting operation 402 requests object data using an object name, such as the object name returned in the returning operation 310 (FIG. 3). The requesting operation 402 may pass in an object name obtained from a remote client computer, or a network server.)
It would have been obvious to one having ordinary skill in the art at the time the time of the
effective filing date to apply distributed write-once object storage/retrieval system as taught by Miller to the teachings to Nikolov, since it was known in the art that distributed systems provide a object store provides a write-once, read-many object storage and retrieval system, wherein the objects are immutable where the object store provides an interface through which a feature application can store or retrieve an object using an object name and the object store encodes the object data to create a unique identifier, through which the object store can access the object from a local cache, or from one of a plurality of locations where the object may be stored locally or remotely where the object store can decode the object's name to obtain location and/or creator information to retrieve the object from the local or remote storage (Miller [0021]).
Nickolov/Miller do not disclose:
and wherein the given version of the structured data representation associated with the
at least one file system interface includes or points to all data structures and data needed to
reconstruct the associated local file system at a point-in-time;
however, Antosz discloses:
wherein the given version of the structured data representation associated with the
at least one file system interface includes or points to all data structures and data needed to
reconstruct the associated local file system at a point-in-time
(Antosz teaches exporting point-in-time copies of local file systems using snapshots/delta versions, i.e. a structured data representation that “includes or points to all data structures and data needed to reconstruct the associated local file system at a point-in-time”, see [0245] One or more embodiments may be configured to automatically capture, transmit and store point-in-time copies, shadow copies, alternate configurations, etc. of the executing infrastructure for archives backup, recovery, failover or other operational readiness concerns;
See also [0293] Local backup storage 360-any form of storage, e.g., external disk or array of disks or a file system exported by a server, which is used by the embodiment for storing local
copies of images, snapshots, and other data used by the embodiment's disaster recovery system.; see also [0014] Automated Image Modification. Allows any file or folder in an image to be changed as if it were a mounted file system; see also [0304] A physical machine may be
converted to a virtual machine through a P2V (physical to virtual) conversion and placed on a
source machine 310.;
see also [0268-0269] [0268] Additionally, at the step 250, image management in the form of backups, restores, deltas, differences, upgrades, mobility, failovers, failbacks, etc. may be performed. [0269] At a step 260, other support operations required in the ongoing operation of the virtual appliances may be provided. For example, when new versions of the operating
system, applications, or virtual machines that comprise a virtual appliance are available, the system can assist in migration of both the software and the customer's data to the
newer version.;
see also [0354] Deltas can be sent among any parts of the embodiment to be integrated into and restored and used as new versions of a virtual machine.).
It would have been obvious to one having ordinary skill in the art at the time the time of the
effective filing date to apply exporting constructed point in time backups as taught by Antosz to the system of Nickolov/Miller since it was known in the art that backup systems provide exporting constructed point in time backups to allow configured to provide command and control capability to start, stop, pause, customize, re-configure, optimize, resize, scale, migrate, consolidate, replicate, backup, recover, load balance or otherwise remotely manage the execution and operation of the infrastructure. (Antosz [0214]).
As to claim 4, Antosz as modified discloses the method as described in claim 1, wherein the local file system, a directory and its contents, a given file, or a piece of a file, are restorable
(Antosz teaches capture, transmit and store point-in-time copies, i.e. a file system is restorable
from the scalable file system with respect to a given time period [0245] One or more
embodiments may be configured to automatically capture, transmit and store point-in-time
copies, shadow copies, alternate configurations, etc. of the executing infrastructure for archives
backup, recovery, failover or other operational readiness concerns. Image differencing may be
used to determine the changes made to a virtual machine image for the purpose of reducing the
amount of data needing to be archived. Change management techniques, described above,
may also be used to reduce the amount of data needing to be archived.;
See also [0268] Additionally, at the step 250, image management in the form of backups,
restores, deltas, differences, upgrades, mobility, failovers, failbacks, etc. may be performed.;
see also [0014] Automated Image Modification. Allows any file or folder in an image to be changed as if it were a mounted file system without causing the virtual machine to be executed or with the virtual machine being mounted or executing. The process may involve a script-based solution for file, folder, registry and/or other changes to the image)
and Miller as modified discloses:
from the write-once, object-based file system
(Miller teaches a distributed write-once object storage/retrieval system see [0055] FIG. 4 is a retrieve object operation flow 400 having exemplary operations for retrieving an object that may be stored at any of various locations on a computer network. As discussed with regard to FIG. 1, objects and object data may be stored in a local cache, in a local file system, in network storage (e.g., on a disk on network server), and/or on a remote client, or peer computer.;
See also [0021] Exemplary methods, systems, and devices are disclosed for managing objects in an instant messaging system. Generally, an object store provides a write-once, read-many
object storage and retrieval system, wherein the objects are immutable. The object store provides an interface through which a feature application can store or retrieve an object
using an object name.)
And Antosz as modified discloses:
with respect to a given time period
(Antosz teaches capture, transmit and store point-in-time copies, i.e. a file system is restorable with respect to a given time period [0245] One or more embodiments may be configured to automatically capture, transmit and store point-in-time copies, shadow copies, alternate configurations, etc. of the executing infrastructure for archives backup, recovery, failover or other operational readiness concerns. Image differencing may be used to determine the changes made to a virtual machine image for the purpose of reducing the amount of data needing to be archived. Change management techniques, described above, may also be used to reduce the amount of data needing to be archived.;
See also [0268] Additionally, at the step 250, image management in the form of backups, restores, deltas, differences, upgrades, mobility, failovers, failbacks, etc. may be performed.).
As to claim 5, Nickolov as modified discloses the method as described in claim 1 wherein at least one file system interface is located on the physical hardware on-premises in the enterprise
(Nickolov teaches various "locally attached volume", i.e. file system interface is located on the
physical hardware on-premises see [0204] In at least one embodiment, data transfer between
the appliances can be arranged in many ways; including, for example, one or more of the
following ( or combinations thereof); [0205] having the appliance 121 read its locally attached
volume and write over a network file system to the appliance 125,; see also [0094] Such
caching is easily accomplished, for example, by layering on top of the NBD client a block device
driver that uses a file on a local physical disk to store copies of blocks recently accessed by the
virtual machine.).
As to claim 6, Antosz as modified discloses the method described in claim 1, wherein the structured data representation associated with the at least one file system interface is a logical representation of a combination of a current version of the local file system and one or more prior versions of the local file system.
(Antosz teaches storing/restoring data in the additional storage which may be replicas of the data in the remote backup or failover systems, additional versions of the data, e.g., older or intermediate versions, i.e. “a combination of a current version of the local file system and one or more prior versions” see [0297] Additional storage system 400-the part of the embodiment, which stores additional copies of images, snapshots, and other data, for the purposes of backup, restore, failover, or failback. The data in the additional storage 400 may be replicas of the data in the remote backup or failover systems, additional versions of the data, e.g., older or intermediate versions, as well as versions of the virtual machines that do not exist in the other ones.
See also [0147] Automatic or manual detection or creation of different versions of a component, sets of components or environments. And [0208] Version Migration. When new versions of the operating system, applications, or virtual machines that comprise a virtual appliance are available, the system 5 can assist in migration of both the software and the customer's data to the newer version. The same configuration and validation techniques as described above may be used to validate that the software continues to function correctly after version migration.)
As to claim 7, Nickolov as modified discloses the method as described in claim 1 wherein the file system interface is a generic virtual file system interface that supports a set of access protocols
(Nickolov teaches using various standard file protocols, i.e. "a generic virtual file system
interface that supports a set of access protocols" [0122] Unix-like operating systems create a
virtual file system, which makes all the files on all the devices appear to exist in a single
hierarchy.; see also Nickolov [0206];
See also Nickolov [0586] It also allows for file upload/download to/from the appliance, using
standard file protocols, such as ftp, scp, cits, etc. (the same way as if the filer appliance was a
physical server).; and [0206] using a protocol like nfs, ftp, or cits,).).
As to claim 8, Nickolov as modified discloses the method as described in claim 7 wherein the set of access protocols are one of: NFS and CIFS
(Nickolov teaches using various standard file protocols, i.e. "NFS and CIBS" [0122] Unix-like
operating systems create a virtual file system, which makes all the files on all the devices
appear to exist in a single hierarchy.; see also Nickolov [0206];
See also Nickolov [0586] It also allows for file upload/download to/from the appliance, using
standard file protocols, such as ftp, scp, cits, etc. (the same way as if the filer appliance was a
physical server).; and [0206] using a protocol like nfs, ftp, or cits,).).
As to claim 9, Nickolov as modified discloses the method as described in claim | wherein one or more of the file system interfaces are implemented as instances within a cloud computing layer
(Nickolov teaches utilizing Cloudware- based systems, i.e. "implemented as instances within a
cloud computing layer" see [0586] One immediate benefit may be that it may allow the user to
download things from the 'net. In at least some embodiments utilizing Cloudware- based
systems and/or including automatic IP allocation ( e.g., inApplogic™), this may become the
default/easy; see also [ 0259] In another embodiment, one or more filer appliances may be
implemented as virtual machines created from preconfigured volume templates ( e.g., as
implemented by virtual machine managers such as VMware VB, Citrix XenServer, Microsoft
Virtual Server, or cloud computing services such as Amazon EC2, etc.).
Claims 2-3 is/are rejected under pre-AIA 35 U.S.C.103(a) as being unpatentable over Nickolov et al., US Pub. No. 2011/0153697 A1, in view of Miller et al., US Pub. No. 2005/0004993 A1, in view of Antosz et al., US Pub. No. 2009/0249284 A1, in view of Anderson et al., US Pub. No. 2008/0046476 A1.
As to claim 2, Nickolov/Miller/Antosz do not disclose:
wherein the structured data representation associated with the at least one file system interface comprises one or more tree-based data structures, wherein at least one tree-based data structure starts with a root that represents a current version of the local file system, and that further includes one or more change events that have been generated as a result of modification to the local file system;
However, Anderson discloses:
The method as described in claim 1, wherein the structured data representation associated with the at least one file system interface comprises one or more tree-based data structures, wherein at least one tree-based data structure starts with a root that represents a current version of the local file system, and that further includes one or more change events that have been generated as a result of modification to the local file system
(Anderson teaches a root and tree structured snapshot data structures with snapshot identifiers wherein the snapshot directory version identifies children of the directory that are different, i.e. “tree-based data structure starts with a root that represents a current version of the local file system, and that further includes one or more change events” See Fig. 2A [0121] & V. Snapshot Creation [0121] FIG. 6 illustrates one embodiment of a flowchart of operations 400 for creating a snapshot. In the depicted embodiment, the process 400 executes when a snapshot is created. The process 400 begins 401 by getting the path of the root of the snapshot to be created 402. In one embodiment, the root of the snapshot is the top-most level in the file system hierarchy governed by the snapshot. Accordingly, the snapshot governs the root of the snapshot and the descendants of the root of the snapshot. In one embodiment, the root of the snapshot is either a file or directory. In other embodiments, the root of the snapshot is only a file or only a directory.;
See also [0075-0077] [0075] FIG. 2A illustrates one embodiment of a file system
hierarchy indicating one embodiment of snapshots taken on the file system hierarchy…. [0077] The dashed lines 221, 222, 223 in FIG. 2A correspond to snapshots of the file system 200. In one embodiment, each of the snapshots has a snapshot identifier (“snapshot ID”). In one embodiment, the snapshot ID provides an indication as to the relative time the snapshot was created. For example, if the snapshot ID of snapshot A is greater than the snapshot ID of snapshot B, it is understood that snapshot A was created after snapshot B. In one embodiment, the snapshot ID is assigned to snapshots based on a monotonically increasing global snapshot counter (“global count”).
See also [0025-0027] [0025] An additional embodiment of the invention may include a data storage system capable of preserving data snapshots of portions of the stored data as of selected points in time. The system may include a data storage tree structure to store current data in directories and files; a snapshot module configured to create snapshots in time of directories and files; and snapshot data structures of snapshot versions of a directory, wherein the snapshot directory version identifies children of the directory that are different from the next more recent version of the directory.. [0027] An additional embodiment of the present invention includes a method of traversing a portion of data stored hierarchically in a data storage system in which the portion of the data represents a snapshot of the data stored in said system as of a point in time. The method may include identifying the desired snapshot point in time and the desired file or files within the storage system; and traversing the nodes of the storage system that are identified at the nodes as associated with the desired snapshot to find the desired file or files.;).
It would have been obvious to one having ordinary skill in the art at the time the time of the
effective filing date to apply tree structured snapshot identifiers wherein the snapshot directory version identifies children as taught by Anderson to the system of Nickolov/Miller/ Antosz since it was known in the art that distributed file systems provide a storage system that track of a plurality of versions of selected data portions as of selected points in time where the storage system may include a snapshot module configured to track multiple snapshots of the same and/or different portions of the data stored in said storage system at substantially the same and/or different points in time; a data structure configured to store the current data of the storage system and to store the snapshot versions of the data generally only to the extent the snapshot versions of the data differ from the storage system's current data; snapshot data structures related to the snapshot versions configured to store information about nodes within the snapshot versions that have been modified. (Anderson [0028]).
As to claim 3, Anderson as modified discloses the method as described in claim 1, wherein, from a tree-walk perspective, a tree-based data structure is a complete version of the local file system at a given point-in-time
(Anderson [0027] An additional embodiment of the present invention includes a method of traversing a portion of data stored hierarchically in a data storage system in which the portion
of the data represents a snapshot of the data stored in said system as of a point in time. The method may include identifying the desired snapshot point in time and the desired file or files within the storage system; and traversing the nodes of the storage system that are identified at the nodes as associated with the desired snapshot to find the desired file or files.;
see also [0123] After the snapshot tracking file has been created 403 and the global count added 404, decision block 405 determines whether the root of the snapshot is also the root of the file system. If it is the root of the file system, the operations in blocks 406, 407, and 408 can be skipped. However, if it is not the root of the file system, a for loop for all ancestors of the root of the snapshot to the root of the file system 406 is initiated.).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Sinha et al., US Pub. No.: US 2005/0055385 A1, teaches past versions of data in a distributed database system comprising multiple databases and associated database servers are queried using temporal database access mechanisms, where a request for data in a past state from a "remote" database can be received at a "local" database server and relevant portions of the request are passed to the remote server for processing. The processing performed by the remote server includes returning the requested data in the specified past state to the local server, or at least with enough information to reconstruct the data into the past state;
Vermeulen et al., US Pub. No.: 2007 /0156842 A1, teaches distributed, web-services based storage system. A system may include a web services interface configured to receive, according to a web services protocol, a given client request for access to a given data object, the request including a key value corresponding to the object. The system may also include storage nodes configured to store replicas of the objects, where each replica is accessible via a respective unique locator value, and a keymap instance configured to store a respective keymap entry for each object. For the given object, the respective keymap entry includes the key value and each locator value corresponding to replicas of the object. A coordinator may receive the given client request from the web services interface, responsively access the keymap instance to identify locator values corresponding to the key value and, for a particular locator value, retrieve a corresponding replica from a corresponding storage node;
Owara et al., US Patent No.: US 7,966,293 B1, teaches a system and method for managing backup and restore operations on a storage system, typically between source storage system and destination storage system using a backup management client that employs a version of the Network Data Management Protocol to interface with the destination file server and generate an "index" of data structures (such as directories and files) from directly from scanning the trees of PCPis stored on the destination. The management client includes a command line interface for entry of instructions by a user or application and a web-based user interface and allows the index to be displayed as a series of web pages on a graphical user interface. The index can be browsed and selected data structures can be restored to a source filer/file server as desired. All back-ups/PCPis can be contemporaneously browsed, allowing greater flexibility in selecting a best backup image to restore.
CONTACT INFORMATION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EVAN S ASPINWALL whose telephone number is (571)270-7723. The examiner can normally be reached Monday-Friday 8am-5pm.
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, Neveen Abel-Jalil can be reached at 571-270-0474. 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.
/Evan Aspinwall/Primary Examiner, Art Unit 2152
Prosecution Insights