Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 11-20, 22-29 are pending; claims 11, 22 and 26 are independent.
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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 11-20, 22-29 of the instant application are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims of U.S. Patent No. 11,144,510, (App. No. 15/179,459). Although the conflicting claims are not identical, they are not patentably distinct from each other because the claims of instant Application are the same subject matter as the claims in Patent No. 11,144,510, (App. No. 15/179,459). Claims 11-20, 22-29 of the instant application are also rejected under the judicially created doctrine of provisional obviousness-type double patenting as being unpatentable over claims of App. No.: 17/480,891 because, although the conflicting claims are not identical, the feature as recited in the claims of instant application are the same subject matter as the claims as recited in App. No.: 17/480,891 as shown in the previous office action and using the applied references for amended features.
Claim Rejections - 35 USC § 102
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 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 35 U.S.C. 102 that forms the basis for all the rejections under this section made in this Office Action:
A person shall be entitled to a patent unless—
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 11-20 and 22-29 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Guarraci, Pub. No.: US 2011/0066668 (Guarraci).
Claim 11. Guarraci teaches:
A remote file storage system comprising: a hardware processor configured to execute code; physical memory electrically coupled to said hardware processor for storing data and said code, said data including a remote file system (RFS) associated with a client, said RFS including a plurality of file system objects, each of said file system objects including metadata having a revision field and a global revision identifier associated with said RFS, said global revision identifier having a variable state; (figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 53-55, 90-94, 125-131, 147, multiple clients 101 access synchronized shared objects/files on their local devices; files on the local devices are synchronized with the copies of the same file on remote devices/clouds, a revision field is simply a field from which “the revision timestamps of every file and directory associated with the virtual file system and their associated content” can be identified: ¶ 53, “clients 101-A and 101-B are communicatively connected to a storage cloud 120, each client including a virtual file system 102…the virtual file system includes an application user interface (API) 103, a local file system 105, and a core engine 107…The core engine 107 refers to a set of application modules that are responsible for managing different aspects of the virtual file system 102, such as retrieving files from a remote storage device, synchronizing one copy of a file stored at the client 101 with another copy of the same file stored at a remote storage device, etc.”; a global revision identifier is a unique revision field identifier associated with a particular directory and files in the directory, e.g., “commit tree” having a variable state such as a timestamp, pointer to previous version, etc., for tracking different version of the same directory/files: ¶ 68, “the VFS cache module 174 also builds a hierarchical tree structure referencing the file using the metadata objects associated with the file and updates the tree structure to keep track of all subsequent operations to the file. Throughout this application, this tree structure is sometimes referred to as "commit tree" or "commit graph."”; ¶ 92, “The commit tree rendered at the system startup not only has the current status of the virtual file system ( e.g., the revision timestamps of every file and directory associated with the virtual file system and their associated content) but also provides a mechanism for a user to arbitrarily revert to a previous revision for the same file or directory”; ¶ 130, “the commit nodes corresponding to different revisions to the virtual file system…the first revision is made at the moment of T1 and represented by the commit node C1; and the second revision is made at the moment of T2 and represented by the commit node C2. Note that there is no conflict for the first two revisions because both revisions to the virtual file systems are synchronized with the storage cloud such that a file stored in the storage cloud (in the form of blocks) are the same as the file stored at the virtual file system's local file system cache”)
a user interface electrically coupled to said physical memory and to a network adapter and operative to establish a connection with a user of said client and to provide access to said RFS to said user; (fig. 1A, ¶¶ 53, 129, 147, clients are communicatively connected to cloud storage for file operations; ¶¶ 62, 134, wherein “the core engine 170 includes a virtual file system (VFS) management module 184 for interfacing with the client 194, e.g., receiving client requests for downloading or uploading certain files or instructions for modifying the virtual file system's configuration (e.g., its replication policy) and sending files to the requesting user. The VFS management module 184 is communicatively connected to the VFS configuration module 172 and the VFS retrieval module 186…a client or server computer 700 includes a user interface 706 comprising a display device 708 and one or more input devices 710” suggest that a user interface is involved in providing access to a user)
an RFS updater configured to update said metadata associated with one or more of said file system objects based on a state of said global revision identifier responsive to said RFS being modified by said user; and (figs. 2A-2C and 6A-6E , each file modification during time T is reflected in a portion of a hierarchical commit tree which is a metadata describing commit nodes, folder nodes and file nodes (figs. 2A-2C), for example, Commit node C1 shows the file system object E3 in File Node F2 associated with global revision identifier Directory Node D1 is updated to E6, File Node F3 and Directory Node D2 in Commit node C2, each updated metadata in the commit tree is structured as shown in fig. 2A for example)
a remote synchronizer configured to receive a prior revision identifier from a local file storage system, said prior revision identifier being indicative of a prior state of said global revision identifier, compare, for each file system object of said plurality of file system objects, a value stored in said revision field of said metadata to said prior revision identifier, identify, based on a relationship between said value stored in said revision field of said metadata and said prior revision identifier, a subset of said plurality of file system objects that require synchronization, and transmit, to said local file storage system, metadata corresponding only to said subset of said plurality of file system objects that require synchronization. (¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client, by default the request is for the latest version of a file, the modified file in the local storage is synchronized with other storage or cloud storage, the file is synchronized using version and time stamp associated with the file: ¶104, “the core engine turns a request for a file or even a data volume into requests for a set of metadata and content blocks and then fetches each block from a respective hosting storage device using an appropriate adapter. The process depicted in FIG. 4A provides more details of how the core engine processes each tree node in connection with retrieving a client-requested file”, ¶¶ 110-111, “the virtual file system synchronizes with the storage devices in the storage cloud either periodically or in an on-demand fashion”, ¶ 72, “the core engine 170 uses the commit tree structure to record the operations performed on the virtual file system so that it can easily locate a client-requested file or directory or a client-requested revision”, ¶ 78, “The reference to a predecessor directory node 203-3 is used for identifying a previous revision of the same directory. Using this parameter, the core engine can locate a client requested revision of a directory from its current revision by traversing across the commit tree”, ¶¶ 97-101, “In response to a request from an application or a person for a file managed by the virtual file system (311), the core engine performs a lookup of the commit tree for a file node associated with the requested file (313)…the request may specify a particular revision or multiple revisions to the file for retrieval, which may or may not include the latest revision of the file. By default, the request is for the latest revision of the file…After receiving the request, the core engine identifies the file node ID and then checks the state of the file node using the identified file node ID…If the file's state is one of the following two states: local [the file only exists at the local file system, not at the storage cloud” as in ¶ 74] or modified, [the file at the local file system has been modified, but not yet synchronized with the storage cloud” as in ¶ 75] and there is a valid, local copy of the requested file at the local file system cache. In some embodiments, the state "modified" may include the addition of a new file to the virtual file system…A commit tree may have multiple tree branches, each branch corresponding to a respective revision of a file in the virtual file system”; ¶¶ 102-103, “the virtual file system typically adds a new branch to the commit tree to log the transactions happening to the virtual file system between the last commit and the current commit the core engine generates the new tree branch in a bottom-up fashion. For example, the core engine first generates a new file node referencing one or more blocks associated with the new/updated file (331). Next, the core engine generates a new directory node referencing the new file node (333) and generates a new commit node referencing the new directory node (335). In some embodiments, the core engine may iterate the two steps multiple times if there are multiple directory layers separating the file node from the commit node. The generation of the new commit node implies the creation of the new commit tree branch. The core engine then adds the new commit tree branch to the commit tree (337). Finally, the core engine synchronizes the virtual file system with the storage devices by pushing the new blocks associated with the file node to the respective storage devices”; ¶¶ 130-132)
Claim 12. The system of Claim 11, wherein said RFS updater is configured to alter said metadata of said one or more of said file system objects to reflect said state of said global revision identifier. (Guarraci, figs. 6A-6E and ¶¶ 125-131, the value of commit node, folder node and file node are updated for each modified file during time T to a new state)
Claim 13. The system of Claim 12, wherein said RFS updater is configured to update said state of said global revision identifier to a new state prior to updating said metadata based on said state of said global revision identifier. (Guarraci, figs. 6A-6E and ¶¶ 125-131, the value of commit node, folder node and file node are updated for each modified file during time T, the value of commit node/folder node is assigned first to be associated with metadata of a modified file node)
Claim 14. The system of Claim 11, wherein said RFS updater is configured to update metadata associated with one or more folders of said RFS responsive to said RFS being modified by said user. (Guarraci, figs. 6A-6E and ¶¶ 125-131, the value of commit node, folder node and file node are updated for each modified file during time T)
Claim 15. The system of Claim 14, wherein said updated metadata is associated with a folder containing a file therein, said file comprising at least a portion of said modification to said RFS by said user. (Guarraci, figs. 6A-6E and ¶¶ 125-131, the value of commit node, folder node and file node are updated for each modified file during time T)
Claim 16. The system of Claim 11, wherein:
said metadata associated with said file system objects of said RFS are partitioned into a folders portion and a files portion; (Guarraci, figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 68, 72 and 92 a commit tree or commit graph (figs. 6A-6E) is a hierarchical structure of directory/files/blocks including folders portion and files portion each including information/metadata for tracking every update in the file system)
said folders portion includes a plurality of folder records each storing folder metadata associated with a folder of said RFS; (Guarraci, figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 68, 72 and 92 a commit tree or commit graph (figs. 6A-6E) is a hierarchical structure of directory/files/blocks including folders portion and files portion each including information/metadata for tracking every update in the file system)
said files portion includes a plurality of file records each storing file metadata associated with a file of said RFS;(Guarraci, figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 68, 72 and 92 a commit tree or commit graph (figs. 6A-6E) is a hierarchical structure of directory/files/blocks including folders portion and files portion each including information/metadata for tracking every update in the file system)
said folder metadata includes revision data indicative of said state of said global revision identifier at some point in time; and (Guarraci, figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 68, 72 and 92 a commit tree or commit graph (figs. 6A-6E) is a hierarchical structure of directory/files/blocks including folders portion and files portion each including information/metadata for tracking every update in the file system; version data is included in the hierarchical structure of directory/files/blocks for accessing pervious revision of the current updated file and directory)
said RFS updater is configured to update said revision data of said folder metadata responsive to said RFS being modified by said user. (Guarraci, figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 68, 72 and 92 a commit tree or commit graph (figs. 6A-6E) is a hierarchical structure of directory/files/blocks including folders portion and files portion each including information/metadata for tracking every update in the file system; version data is included in the hierarchical structure of directory/files/blocks for accessing pervious revision of the current updated file and directory)
Claim 17. The system of Claim 11, wherein said remote synchronizer is configured to:
establish a second connection with said local file storage system associated with a local file system (LFS); receive a synchronization request from said local file storage system; and provide, responsive to receiving said synchronization request, metadata associated with at least some of said file system objects of said RFS to said local file storage system. (Guarraci, ¶¶ 96-102 a request for a particular file returns the synchronized version of the file and associated metadata based on a particular revision of the commit tree/metadata (¶101); a request for a particular file initiates comparison for returning the synchronized version of the file based on a particular revision of the commit tree/metadata (¶ 101))
Claim 18. The system of Claim 17, wherein:
said synchronization request includes data indicative of at least one requested folder within said RFS; and (Guarraci, figs. 6A-6E, ¶¶ 96-102, a request includes data indicative of a requested folder/directory nodes in a commit tree (fig. 6, ¶¶ 96, 99)
said remote synchronizer is configured to provide, to said local file storage system, folder metadata associated with one or more identified folders of said RFS based on said at least one requested folder of said RFS, said folder metadata including revision data indicative of a state of said global revision identifier the last time one of said one or more identified folders of said RFS was modified. (Guarraci, figs. 6A-6E, ¶¶ 96-102, each commit tree is associated with a particular revision (¶ 101) and synchronizing to a latest revision is performed by identifying a particular reversion of a file/directory/commit nodes (¶ 101))
Claim 19. The system of Claim 18, wherein:
said client interface is operative to receive a file listing request from said local file storage system for at least some of said plurality of folders associated with said folder metadata provided to said local file storage system; and said remote synchronizer is further configured to provide file metadata for files stored in each folder identified in said file listing request to said local file storage system. (Guarraci, figs. 6A-6E, ¶¶ 96-102, a requested directory (¶ 96) includes a file listing (fig. 6, Directory Node D1 (folder), File Node F1, File Node F2 (file listing))
Claim 20. The system of Claim 17, wherein said remote synchronizer is configured to provide a current state of said global revision identifier to said local file storage system. (¶¶ 96-102, latest version is a default value (¶ 97); other revision/global revision identifiers are provided based on request (¶ 101))
Claim 22. Guarraci teaches:
A method for synchronizing remote file system (RFS) with an associated local file system (LFS), said LFS being located remotely from said RFS, said method comprising: (figs. 1A, 2A, 2B and 2C, and ¶¶ 53-55, 90-94, 125-131, 147, multiple clients 101 access synchronized shared objects/files on their local devices; files on the local devices are synchronized with the copies of the same file on remote devices/clouds: ¶ 53, “clients 101-A and 101-B are communicatively connected to a storage cloud 120, each client including a virtual file system 102…the virtual file system includes an application user interface (API) 103, a local file system 105, and a core engine 107…The core engine 107 refers to a set of application modules that are responsible for managing different aspects of the virtual file system 102, such as retrieving files from a remote storage device, synchronizing one copy of a file stored at the client 101 with another copy of the same file stored at a remote storage device, etc.”; ¶ 129, “the virtual file system is required to enable a user to access a set of files residing in the storage cloud ( especially those remote storage devices) from different geographical locations”)
maintaining said RFS in association with a client, said RFS including a plurality of file system objects, each of said file system objects including metadata having a revision field; maintaining a global revision identifier in association with said RFS, said global revision identifier having a variable state; (figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 53-55, 90-94, 125-131, 147, multiple clients 101 access synchronized shared objects/files on their local devices; files on the local devices are synchronized with the copies of the same file on remote devices/clouds, a revision field is simply a field from which “the revision timestamps of every file and directory associated with the virtual file system and their associated content” can be identified: ¶ 53, “clients 101-A and 101-B are communicatively connected to a storage cloud 120, each client including a virtual file system 102…the virtual file system includes an application user interface (API) 103, a local file system 105, and a core engine 107…The core engine 107 refers to a set of application modules that are responsible for managing different aspects of the virtual file system 102, such as retrieving files from a remote storage device, synchronizing one copy of a file stored at the client 101 with another copy of the same file stored at a remote storage device, etc.”; a global revision identifier is a unique revision field identifier associated with a particular directory and files in the directory, e.g., “commit tree” having a variable state such as a timestamp, pointer to previous version, etc., for tracking different version of the same directory/files: ¶ 68, “the VFS cache module 174 also builds a hierarchical tree structure referencing the file using the metadata objects associated with the file and updates the tree structure to keep track of all subsequent operations to the file. Throughout this application, this tree structure is sometimes referred to as "commit tree" or "commit graph."”; ¶ 92, “The commit tree rendered at the system startup not only has the current status of the virtual file system ( e.g., the revision timestamps of every file and directory associated with the virtual file system and their associated content) but also provides a mechanism for a user to arbitrarily revert to a previous revision for the same file or directory”; ¶ 130, “the commit nodes corresponding to different revisions to the virtual file system…the first revision is made at the moment of T1 and represented by the commit node C1; and the second revision is made at the moment of T2 and represented by the commit node C2. Note that there is no conflict for the first two revisions because both revisions to the virtual file systems are synchronized with the storage cloud such that a file stored in the storage cloud (in the form of blocks) are the same as the file stored at the virtual file system's local file system cache”)
establishing a network connection with a local file storage system associated with said LFS; (fig. 1A, ¶¶ 53 and 129, clients are communicatively connected to cloud storage for file operations)
receiving at least one prior revision identifier from said local file storage system, said prior revision identifier being indicative of a prior-state of said global revision identifier; said global revision identifier; (¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest version of a file or can be a specified version, the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file: ¶104, “the core engine turns a request for a file or even a data volume into requests for a set of metadata and content blocks and then fetches each block from a respective hosting storage device using an appropriate adapter. The process depicted in FIG. 4A provides more details of how the core engine processes each tree node in connection with retrieving a client-requested file”, ¶¶ 110-111, “the virtual file system synchronizes with the storage devices in the storage cloud either periodically or in an on-demand fashion”, ¶ 72, “the core engine 170 uses the commit tree structure to record the operations performed on the virtual file system so that it can easily locate a client-requested file or directory or a client-requested revision”, ¶ 78, “The reference to a predecessor directory node 203-3 is used for identifying a previous revision of the same directory. Using this parameter, the core engine can locate a client requested revision of a directory from its current revision by traversing across the commit tree”, ¶¶ 97-101, “In response to a request from an application or a person for a file managed by the virtual file system (311), the core engine performs a lookup of the commit tree for a file node associated with the requested file (313)…the request may specify a particular revision or multiple revisions to the file for retrieval, which may or may not include the latest revision of the file. By default, the request is for the latest revision of the file…After receiving the request, the core engine identifies the file node ID and then checks the state of the file node using the identified file node ID…If the file's state is one of the following two states: local [the file only exists at the local file system, not at the storage cloud” as in ¶ 74] or modified, [the file at the local file system has been modified, but not yet synchronized with the storage cloud” as in ¶ 75] and there is a valid, local copy of the requested file at the local file system cache. In some embodiments, the state "modified" may include the addition of a new file to the virtual file system…A commit tree may have multiple tree branches, each branch corresponding to a respective revision of a file in the virtual file system”; ¶¶ 102-103, “the virtual file system typically adds a new branch to the commit tree to log the transactions happening to the virtual file system between the last commit and the current commit the core engine generates the new tree branch in a bottom-up fashion. For example, the core engine first generates a new file node referencing one or more blocks associated with the new/updated file (331). Next, the core engine generates a new directory node referencing the new file node (333) and generates a new commit node referencing the new directory node (335). In some embodiments, the core engine may iterate the two steps multiple times if there are multiple directory layers separating the file node from the commit node. The generation of the new commit node implies the creation of the new commit tree branch. The core engine then adds the new commit tree branch to the commit tree (337). Finally, the core engine synchronizes the virtual file system with the storage devices by pushing the new blocks associated with the file node to the respective storage devices”; ¶¶ 130-132)
comparing, for each file system object of said plurality of file system objects, a value stored in said revision field of said metadata to said prior revision identifier; (see above)
identifying, based on a relationship between said value stored in said revision field of said metadata and said prior revision identifier, a subset of said plurality of file system objects that require synchronization; and (see above)
transmitting, to said local file storage system, metadata corresponding only to said subset of said plurality of file system objects that require synchronization. (see above)
Claim 23. The method of Claim 22, further comprising providing metadata associated with file system objects that have been modified since a prior synchronization that occurred when said global revision identifier was in said prior state. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest version of a file or can be a specified version, the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file)
Claim 24. The method of Claim 23, wherein:
said metadata comprises folder metadata associated with said one or more folders; and said method further comprises receiving a query from said local file storage system for file metadata associated with files stored in at least some of said one or more folders. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest version of a file or can be a specified version, the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file)
Claim 25. The method of Claim 22, further comprising:
providing a current revision identifier to said local file storage system, said current revision identifier defining a current state associated with said RFS; and thereby facilitating storage of said current revision identifier in LFS metadata associated with at least one folder of said LFS. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest/current version of a file or can be a specified version, the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file)
Claim 26. Guarraci teaches:
A local file storage system storing a local file system (LFS) that is synchronized with an associated remote file system (RFS) stored remotely from said LFS, said local file storage system comprising: a hardware processor configured to execute code; physical memory electrically coupled to said hardware processor for storing data and said code, said data including
said LFS including a plurality of file system objects, each of said file system objects including metadata having a revision field, and a plurality of prior revision identifiers, each prior revision identifier defining a state of said RFS at a time when an associated folder of a said LFS was last synchronized with said RFS; (Guarraci, figs. 1A, 2A, 2B and 2C, and ¶¶ 53-55, 90-94, 125-131, 147, multiple clients 101 access synchronized shared objects/files on their local devices; files on the local devices are synchronized with the copies of the same file on remote devices/clouds: ¶ 53, “clients 101-A and 101-B are communicatively connected to a storage cloud 120, each client including a virtual file system 102…the virtual file system includes an application user interface (API) 103, a local file system 105, and a core engine 107…The core engine 107 refers to a set of application modules that are responsible for managing different aspects of the virtual file system 102, such as retrieving files from a remote storage device, synchronizing one copy of a file stored at the client 101 with another copy of the same file stored at a remote storage device, etc.”; ¶ 129, “the virtual file system is required to enable a user to access a set of files residing in the storage cloud ( especially those remote storage devices) from different geographical locations”; ¶¶ 53-55, 69-70, 90-94, 125-131, 147, local and remote devices are physical locations for storing files/objects along with metadata indicative of version of the files/objects: ¶ 54, “the storage cloud 120 is a distributed, heterogeneous storage system including multiple types of storage devices such as local storage devices 109 ( e.g., thumb drive, hard drive, network attached storage (NAS ), etc.) and remote ( and often distributed) cloud storage devices. In other words, the term "cloud" in this application has a broader scope that may cover storage devices that are physically local to or remote from the virtual file system…the remote cloud storage devices is a cloud storage service provided by a third-party ( e.g., Amazon S3)…the cloud storage service includes a remote cloud platform 123, a set of cloud service modules 125, and a set of cloud storage devices 127”; ¶ 55, “a user of the virtual file system 102…submits a request for a file…the core engine 107 determines whether or not and how to retrieve information associated with the file ( e.g., metadata and data) from a storage device within the storage cloud 120. After receiving the information, the core engine 107 then rebuilds the requested file in the local file system 105 and makes it available for the user to access. Upon detection of the user's updates to the file, the core engine 107 then generates a new revision of the file and synchronizes the revised file including its metadata and data with one or more storage devices associated with the storage cloud 120”)
a remote cloud interface electrically coupled to said hardware processor and to said physical memory and configured to establish a connection with said remote file storage system; and (Guarraci, fig. 1A, ¶¶ 53 and 129, clients are communicatively connected to cloud storage for file operations)
a synchronizer configured to provide at least one prior revision identifier associated with said LFS to said remote file storage system and receive, from said remote file storage system, RFS metadata corresponding only to a subset of said plurality of file system objects that require synchronization. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client, by default the request is for latest version of a file, the file is modified in the local storage, it means the file has to be synchronized with other storage or cloud storage, the file is synchronized using version and timestamp associated with the file: ¶104, “the core engine turns a request for a file or even a data volume into requests for a set of metadata and content blocks and then fetches each block from a respective hosting storage device using an appropriate adapter. The process depicted in FIG. 4A provides more details of how the core engine processes each tree node in connection with retrieving a client-requested file”, ¶¶ 110-111, “the virtual file system synchronizes with the storage devices in the storage cloud either periodically or in an on-demand fashion”, ¶ 72, “the core engine 170 uses the commit tree structure to record the operations performed on the virtual file system so that it can easily locate a client-requested file or directory or a client-requested revision”, ¶ 78, “The reference to a predecessor directory node 203-3 is used for identifying a previous revision of the same directory. Using this parameter, the core engine can locate a client requested revision of a directory from its current revision by traversing across the commit tree”, ¶¶ 97-101, “In response to a request from an application or a person for a file managed by the virtual file system (311), the core engine performs a lookup of the commit tree for a file node associated with the requested file (313)…the request may specify a particular revision or multiple revisions to the file for retrieval, which may or may not include the latest revision of the file. By default, the request is for the latest revision of the file…After receiving the request, the core engine identifies the file node ID and then checks the state of the file node using the identified file node ID…If the file's state is one of the following two states: local [the file only exists at the local file system, not at the storage cloud” as in ¶ 74] or modified, [the file at the local file system has been modified, but not yet synchronized with the storage cloud” as in ¶ 75] and there is a valid, local copy of the requested file at the local file system cache. In some embodiments, the state "modified" may include the addition of a new file to the virtual file system…A commit tree may have multiple tree branches, each branch corresponding to a respective revision of a file in the virtual file system”; ¶¶ 102-103, “the virtual file system typically adds a new branch to the commit tree to log the transactions happening to the virtual file system between the last commit and the current commit the core engine generates the new tree branch in a bottom-up fashion. For example, the core engine first generates a new file node referencing one or more blocks associated with the new/updated file (331). Next, the core engine generates a new directory node referencing the new file node (333) and generates a new commit node referencing the new directory node (335). In some embodiments, the core engine may iterate the two steps multiple times if there are multiple directory layers separating the file node from the commit node. The generation of the new commit node implies the creation of the new commit tree branch. The core engine then adds the new commit tree branch to the commit tree (337). Finally, the core engine synchronizes the virtual file system with the storage devices by pushing the new blocks associated with the file node to the respective storage devices”; ¶¶ 130-132)
Claim 27. The system of Claim 26, wherein said RFS metadata is associated with file system objects that have been modified since a particular time when a particular folder of said LFS associated with said at least one prior revision identifier was last synchronized with said RFS. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest version of a file or can be a specified version, the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file)
Claim 28. The system of Claim 27, wherein:
said RFS metadata comprises folder metadata associated with said one or more folders of said RFS; and said synchronizer is configured to query said remote file storage system for file metadata associated with files stored in at least some of said one or more folders. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest version of a file or can be a specified version, the file is retrieved and provided to the client based on metadata and version associated with the requested file; the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file)
Claim 29. The system of Claim 26, wherein:
said remote cloud interface is configured to receive a current revision identifier from said remote file storage system, said current revision identifier defining a current state associated with said RFS; and said synchronizer is configured to store said current revision identifier in LFS metadata associated with at least one folder of said. (Guarraci, ¶¶ 55, 59, 68-69, 72-76, 90, 92-93, 97, 104, 110-111, 130-131, a file requested by a client; by default the request is for latest/current version of a file or can be a specified version, the file is modified in the local storage and therefore needs to be synchronized; the file is synchronized using version and time stamp associated with the file)
Response to Amendment and Arguments
In light of amendments, 101 rejections are withdrawn.
Double patenting rejections are maintained because Applicant did not file required TD.
Applicant arguments with respect to amended claims are considered but are not persuasive for at least the following reasons.
Applicant argues the applied references do not teach the amended claims because “The synchronization process does not include any comparison between commit trees or other metadata”. Remarks, 13-15.
In response, Guarraci discloses that each file that a client request is also a request for the file’s metadata such as a particular version of a file. The requested version is a latest version or a particular version of the file. In any case, the requested version/metadata has to be compared with versions/metadata in other storage or cloud storage for finding the requested version and providing the requested version to the client. See independent claims above for related paragraphs in Guarraci.
See also Parkison et al., Pub. No.: US 2015/0370827 A1:
[0007] The disclosed embodiments disclose techniques for synchronizing file updates between two cloud controllers of a distributed filesystem. Two or more cloud controllers collectively manage distributed filesystem data that is stored in the cloud storage systems; the cloud controllers ensure data consistency for the stored data, and each cloud controller caches portions of the distributed filesystem. During operation, a cloud controller receives a request from a client to access a file in the distributed filesystem. The cloud controller sends a synchronization update request for the file to a second cloud controller and in response receives a synchronization update for the file from the second cloud controller.
[0009] In some embodiments, cloud controllers send a version identifier for the most recent version of the file that they are currently aware of when sending a synchronization update request. The cloud controller receiving the request can use this version identifier to determine whether the file has been modified more recently locally and thus determine whether the version of the file that is currently available on the requesting cloud controller is out-of-date.
[0010] In some embodiments, a cloud controller receiving a synchronization update request for a file: (1) uses the version identifier for the file that was included in the request to determine the metadata deltas that are needed to update the out-of-date version of the file on the requesting cloud controller to the updated version of the file that is available locally; (2) compresses the metadata deltas; and (3) sends the compressed metadata deltas to the requesting cloud controller in a synchronization update. Using version identifiers to determine the metadata deltas facilitates determining the differences between an out-of-date file version and a current file version without needing to cache or download all of the data for the file on either cloud controller.
[0112] In some embodiments, a synchronization update comprises a “recipe” that can be used by a receiving cloud controller to update an existing version of a file to the most recent version of the file that was recently written to the cloud controller that sent the update. The cloud controller with the most recent version of a file can use version information from the target cloud controller to craft a set of specific changes to the file's metadata (“deltas”) that allow the target cloud controller to update the target file to the most recent version without requiring high-overhead checksum operations (for the actual file data) on both cloud controllers. Note that these metadata deltas that are sent are not the complete metadata for the file, but instead are a smaller set of changes that can be applied to the previous version of the metadata to bring it up to date with the most recent version of the metadata for the modified file. In general, the deltas of a synchronization update may have the same format as the more general incremental metadata snapshots, but may be limited in scope to a single file and directed to a single cloud controller (instead of all of the cloud controllers and the cloud storage system). However, in some situations where a cloud controller is requesting synchronization updates for multiple files from another cloud controller the metadata deltas for multiple files might be grouped together into a single transfer. In general (e.g., for most file changes) metadata deltas are typically much smaller than both the data and metadata for the file; for example, the metadata for a one Gbyte file might be on the order of one Mbyte, while a metadata delta that is sent to describe a small change to the file might be on the order of a few Kbytes using the disclosed techniques.
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 extension fee 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 Mohsen Almani whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9 AM-5 PM, ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ann J. Lo can be reached on 571-272-9767. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159
Prosecution Insights