Detailed Action
Applicant amended claims 1 and 22 and presented claims 1-10, 22, 24-26, and 28-32 for reconsideration on 10/17/2025.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 is amended by adding the term “only” to the following potion of the claim:
responsive to receiving from said local file storage system said prior state of said global revision identifier providing to said local file storage system a proper subset of said RFS metadata corresponding only to said ones of said RFS objects that require synchronization, thereby facilitating a subsequent synchronization of said first instance of said set of objects stored in persistent storage at said first location with said second instance of said set of objects stored in persistent storage at said second location.
Applicant failed to provide support for the amended claim and the Examiner could not identify the amended portion in the Specification.
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 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. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-10, 22, 24-26 and 28-32 are rejected under 35 U.S.C. 103(a) as being unpatentable over Guarraci, Pub. No.: US 2011/0066668 (Guarraci), in view of Parkison et al., Pub. No.: US 2014/0006354 (Parkison).
Claim 1. Guarraci teaches:
In a remote file storage system, a method for facilitating synchronization of a remote file system (RFS) and a local file system (LFS), said RFS being located remotely from said LFS, 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.”)
providing said RFS including a plurality of RFS objects, said plurality of RFS objects including a first instance of a set of objects stored in persistent storage at a first physical location, each RFS object of said plurality of RFS objects being associated with RFS metadata indicative of a state of said each RFS object of said plurality of RFS objects; (¶¶ 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”)
synchronizing said RFS with said LFS as of a first time, said LFS including a plurality of LFS objects, said plurality of LFS objects including a second instance of said set of objects stored in persistent storage at a second physical location remote from said first physical location, each LFS object of said plurality of LFS objects being synchronized with a corresponding RFS object and being associated with LFS metadata indicative of a state of said each LFS object of said plurality of LFS objects; (¶¶ 53-55, 69-70, 90-94, 125-131, 147, as noted above, local and remote devices are physical locations for storing and synchronizing files/objects along with metadata indicative of version of the files/objects)
defining a storage space, said storage space identifying said set of objects as including every object of said plurality of RFS objects and every object of said plurality of LFS objects that is accessible by a particular user; (¶ 27, a storage space is defined for a user because “a user’s storage space” including local and remote storages are unified such that from “a user's perspective, the virtual file system acts like a hard drive, except the data is stored elsewhere”)
maintaining a global revision identifier associated with said RFS, said global revision identifier having a variable state; (figs. 1A, 2A, 2B, 2C, 6A-6E and ¶¶ 90-94, 125-131, 147, a global revision identifier is a unique 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 connection with said particular user; (fig. 1A, ¶¶ 53, 129, 147, clients are communicatively connected to cloud storage for file operations)
providing access to said RFS objects to said particular user by providing a proper subset of said set of objects to a client machine associated with said particular user responsive to a request by said particular user for said proper subset of said set of objects; (¶¶ 27, 55, 129, 147 particular users/clients have access to files/objects including a proper subset of files/objects in their unified storage spaces and each file node has an associated metadata (fig. 2A, ¶ 55))
receiving an instruction to modify a particular RFS object of said RFS from said particular user; (particular clients are communicatively connected to cloud storage for modifying a file stored in the cloud: fig. 1A, ¶¶ 53, 129, 147 “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. Note that the user may be the same person who accesses the set of files using different computing devices or different persons who access the set of files using different computing devices”)
modifying said particular RFS object in said remote physical location according to said instruction from said particular user; (particular clients are communicatively connected to cloud storage for modifying a file stored in the cloud: fig. 1A, ¶¶ 53 and 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. Note that the user may be the same person who accesses the set of files using different computing devices or different persons who access the set of files using different computing devices”)
responsive to said particular RFS object being modified, updating data in global revision field of said RFS metadata corresponding to said particular RFS object to reflect a current state of said global revision identifier. (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)
establishing a second connection with a local file storage system associated with said LFS and storing said LFS objects; (¶¶ 54, 59, accessing a local storage requires a second connection to the storage)
receiving from said local file storage system storing said LFS objects a prior state of said global revision identifier, said prior state of said global revision identifier representing a particular state of said global revision identifier at said first time, at least a portion of said LFS objects having been altered in said second physical location since said first time; (¶¶ 92, 130, a file stored in the local system comprising a current commit node shows a global revision identifier in T1, after modification of the file in the local system, the remote virtual file system will be synchronized to reflect the modification by versioning the commit node: ¶ 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”; figs. 6A-6E and ¶¶ 125-131 a modified local objects/files are synchronized with objects/files in remote virtual file systems based on the modified commit node/directory node/file node: ¶ 130, “at the moments of T 3 and T 3’, two users independently make changes to the same revision of the virtual file system from their respective computing devices by, e.g., adding new files to the virtual file system, deleting existing files from the virtual file system, or modifying existing files in the virtual file system. As a result, two different commit nodes C3 and C3' are generated at the two computing devices from which the changes to the virtual file system were made…Subsequently, when one of the two users (e.g., the user who generates the commit node C3) first synchronizes its virtual file system with the storage cloud, the new commit node C3 will be sent to the storage cloud to replace the commit node C2 as the virtual file system's current commit node”)
comparing data in each of a plurality of global revision fields of said RFS metadata corresponding to said plurality of RFS objects with said prior sate of said global revision identifier received from said local file storage system to identify ones of said RFS objects that require synchronization with corresponding ones of said LFS objects; and (see previous step where an identifier associated with a modified file in a local storage is used for identifying a copy of the same object in the cloud for synchronization)
responsive to receiving from said local file storage system said prior state of said global revision identifier providing to said local file storage system a proper subset of said RFS metadata corresponding only to said ones of said RFS objects that require synchronization, thereby facilitating a subsequent synchronization of said first instance of said set of objects stored in persistent storage at said first location with said second instance of said set of objects stored in persistent storage at said second location. (¶¶ 69-70, 95, 102, 111-112, 125-126, 130-131, a commit tree in virtual file system is associated with a global value and is used for tracking the changes to the virtual file system by adding new branches at different times; new branch is added by traversing a commit tree using a previous commit node, not all previous commit nodes are traversed for synchronizing the virtual file system and a local storage corresponding to the commit tree; ¶ 130, wherein “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…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” indicates there are same prior version of C in VFS and storage cloud and at time T1 only the prior version of C in the storge cloud is synchronized with a later version of C and further wherein “at the moments of T3 and T3′, two users independently make changes to the same revision of the virtual file system from their respective computing devices by, e.g., adding new files to the virtual file system, deleting existing files from the virtual file system, or modifying existing files in the virtual file system. As a result, two different commit nodes C3 and C3′ are generated at the two computing devices from which the changes to the virtual file system were made….when one of the two users (e.g., the user who generates the commit node C3) first synchronizes its virtual file system with the storage cloud, the new commit node C3 will be sent to the storage cloud to replace the commit node C2 as the virtual file system's current commit node” again, indicates that “commit node C2” is identified as a prior version in the storge cloud for synchronization and reflecting a current version of C)
Guarraci did not disclose the storage space as a namespace. However, Parkison discloses a storage space as a namespace by abstracting “a shared global namespace” (¶ 403), distributing the namespace mapping (¶ 402) and using the mapping for identifying a particular synchronized subscribed namespace for further synchronization: ¶ 397, “an exemplary distributed filesystem namespace 4000 that includes a number of user and project directories, each of which includes its own directory and/or file sub-hierarchy. Distributed filesystem namespace 4000 is segmented across three cloud controllers (4002-4006), each of which "owns" (e.g., is the primary manager of write access for) a specified subset of namespace 4000”; ¶¶ 418-422, “Consider the above-described namespace mapping capabilities for the distributed filesystem namespace 4000 illustrated in FIG. 40A. In this context, each cloud controller can provide a set of "shares" that represent locally owned sub-hierarchies, and track a set of mappings that link all of the shares for the distributed filesystem. For instance, these mappings may be tracked as a set of links to sub-hierarchies of files that are owned by other cloud controllers…All of the cloud controllers synchronize both changes to their locally owned file systems as well as changes to the namespace mappings with the other cloud controllers of the distributed filesystem, and thus all cloud controllers can continuously track all of the directories that are available across the set of cloud controllers and the directory mappings themselves”)
Guarraci synchronizes commit trees of virtual file systems associated with particular group of users (fig. 6E, ¶ 92, 129-130) among local and remote cloud storage (¶¶ 54, 147); it would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing a namespace and using the namespace for accessing local and remote files for achieving the same predictable result of synchronizing a particular modified portion/file of file system accessed by users from different locations.
Claim 2. The method of Claim 1, further comprising updating said current state of said global revision identifier to a new state. (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 3. The method of Claim 2, wherein said step of updating said data in said global revision field of said RFS metadata includes altering said RFS metadata associated with said particular RFS object to include a value corresponding to said current state of said global revision identifier prior to said step of updating said current state of said global revision identifier to said new state. (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 4. The method of Claim 1, wherein said step of updating said data in said global revision field of said RFS metadata corresponding to said particular RFS object includes updating RFS metadata associated with one or more folders of said RFS . (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 5. The method of Claim 4, wherein said instruction to modify said particular RFS object of said RFS comprises an instruction involving a file located within said one or more of said folders of said RFS having said RFS metadata associated therewith updated. (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 6. The method of Claim 1, wherein:
said RFS metadata associated with said RFS objects is 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 first 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 for each of said folder records includes data in said global revision field indicative of a former 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 step of updating said data in said global revision field of said RFS metadata to reflect said current state of said global revision identifier includes updating said data in said global revision field of said folder metadata. (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 7. The method of Claim 1, further comprising:
receiving a synchronization request from said local file storage system; and (Guarraci, ¶¶ 96-102 a request for a particular file returns the synchronized version of the file based on a particular revision of the commit tree/metadata (¶101))
initiating said comparing step in response to said receiving said synchronization request. (Guarraci, ¶¶ 96-102 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 8. The method of Claim 7, wherein:
said synchronization request includes data indicative of one or more requested folders within said first 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 step of providing said proper subset of said RFS metadata includes providing folder metadata associated with one or more identified folders of said RFS based on said one or more requested folders of said RFS. (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 9. The method of Claim 8, further comprising:
receiving a file listing request from said local file storage system for at least some of said one or more folders identified by said folder metadata provided to said local file storage system; and providing 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 10. The method of Claim 7, further comprising providing a said current value of said first 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))
Claims 11-21. (Canceled)
Claim 22. Guarraci teaches:
A method for synchronizing a local file system (LFS) with an associated remote file system (RFS), said LFS being stored on a local file storage system located geographically remotely from a remote file storage system storing 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”)
providing said LFS including a plurality of LFS objects, said plurality of LFS objects including a first instance of said set of objects stored in persistent storage at a first physical location, each LFS object of said plurality of LFS objects being associated with LFS metadata indicative of a state of said each LFS object of said plurality of LFS objects; (¶¶ 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”)
establishing a network connection with said remote file storage system associated with said RFS; (fig. 1A, ¶¶ 53 and 129, clients are communicatively connected to cloud storage for file operations)
synchronizing said LFS with said RFS as of a first time, said RFS including a plurality of RFS objects stored in persistent storage a second physical location, each RFS object of said plurality of RFS objects being synchronized with a corresponding LFS object and being associated with RFS metadata indicative of a state of said each RFS object of said plurality of RFS objects; (¶¶ 53-55, 69-70, 90-94, 125-131, 147, as noted above, local and remote devices are physical locations for storing and synchronizing files/objects along with metadata indicative of version of the files/objects)
defining a particular storage space, said particular storage space identifying said set of objects as including every object of said plurality of RFS objects and every object of said plurality of LFS objects that is accessible by a particular user; (¶ 27, a storage space is defined for a user because “a user’s storage space” including local and remote storages are unified such that from “a user's perspective, the virtual file system acts like a hard drive, except the data is stored elsewhere”)
initiating a second synchronization process with said remote file storage system; (figs. 6A-6E and ¶¶ 110-117 and ¶¶ 125-131, a VFS synchronizes with the storage devices in the storage cloud on-demand or periodically (¶ 110))
providing at least one storage space identifier to said remote file storage system via said network connection, said storage space identifier being indicative of the said particular storage space synchronized between said RFS and said LFS; (¶ 54, 79, 92, 101, a particular user defined storage identifier such as local or remote storage provided as service (fig. B, 831, 835, ¶ 63) is used for a particular revision of the root directory of the virtual file system (identifier) (¶ 101) for synchronization of a particular revision of a file (identifier) in the particular branch of the tree with the storage cloud; a VFS manages multiple data volumes each of which is associated with particular node in a particular commit tree (¶ 94))
providing at least one prior revision identifier to said remote file storage system, said prior revision identifier being indicative of a state of said second instance of a said set of objects at said first time; (figs. 6A-6E, ¶¶ 92-94, 130, each particular revision identifier of a file node, directory node or commit node in the commit tree has a reference to its predecessor tree node/prior version identifier that has been synchronized, ¶ 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. This mechanism is built into the commit tree because each tree node data structure (file node 201, directory node 203, or commit node 205) has a reference to its predecessor tree node”, ¶ 130)
receiving information from said remote file storage system, said information being indicative of differences between a current state of said second instance of said set of objects and a prior state of said second instance of said set of objects at said first time; (¶ 55, 92 and 125-131, wherein local storage system has access to information/metadata related to current and prior versions stored in the remote storage system/commit nodes as in ¶ 92, the information is used for synchronizing remote virtual versions according to modified version as in ¶ 55, “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”; ¶¶ 125-131)
generating file system operations based at least in part on said received information; (based on the information as noted in the previous steps, file system operation is generated for synchronization)
applying at least a first portion of said file system operations to said LFS objects; and providing at least a second portion of said file system operations to said remote file storage system to be applied to said RFS objects; and wherein first instance of said set of objects and said second instance of said set of objects are synchronized when said first portion of said file system operations is applied to said LFS objects and said second portion of said file system operations is applied to said RFS objects; and. (“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” as noted in the previous step is a database operation for applying changes/versions from remote system to local system and further “[u]pon 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” is a database operation for applying changes/versions from local file system to remote file system)
said step of receiving information from said remote file storage system includes receiving RFS metadata from said remote file storage system, said RFS metadata being representative of file system objects of said particular storage that have been modified since said first time. (¶¶ 95, 102, 111-112, 125-126, 131, a commit tree in virtual file system is associated with a global value and is used for tracking the changes to the virtual file system by adding new branches at different times; new branch is added by traversing a commit tree using a previous commit node, not all previous commit nodes are traversed for synchronizing the virtual file system and a local storage corresponding to the commit tree)
Guarraci did not specifically teach one storage space identifier as namespace identifier and a particular storage space as a subscribed namespace. However, Parkison teaches a namespace identifier of a subscribed namespace by abstracting “a shared global namespace” (¶ 403), distributing the namespace mapping (¶ 402) and using the mapping for identifying a particular synchronized subscribed namespace for further synchronization: ¶ 397, “an exemplary distributed filesystem namespace 4000 that includes a number of user and project directories, each of which includes its own directory and/or file sub-hierarchy. Distributed filesystem namespace 4000 is segmented across three cloud controllers (4002-4006), each of which "owns" (e.g., is the primary manager of write access for) a specified subset of namespace 4000”; ¶¶ 418-422, “Consider the above-described namespace mapping capabilities for the distributed filesystem namespace 4000 illustrated in FIG. 40A. In this context, each cloud controller can provide a set of "shares" that represent locally owned sub-hierarchies, and track a set of mappings that link all of the shares for the distributed filesystem. For instance, these mappings may be tracked as a set of links to sub-hierarchies of files that are owned by other cloud controllers…All of the cloud controllers synchronize both changes to their locally owned file systems as well as changes to the namespace mappings with the other cloud controllers of the distributed filesystem, and thus all cloud controllers can continuously track all of the directories that are available across the set of cloud controllers and the directory mappings themselves”)
Guarraci synchronizes commit trees of virtual file systems associated with particular group of users (fig. 6E, ¶ 92, 129-130) among local and remote cloud storage (¶¶ 54, 147); it would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied analogous references for disclosing a subscribed namespace identifier and using the identifier for synchronization because synchronizing data associated with a namespace is very well known in the art and doing so would increase usability of Guarraci by alternatively using “subscribed namespace identifier” to achieve the same predictable result of synchronizing a particular modified portion/file of file system accessed by users from different locations.
Claim 24. The method of Claim 22, wherein:
said RFS metadata comprises folder metadata associated with said one or more folders of said subscribed namespace; and said method further comprises querying said remote file storage system for file metadata associated with files stored in at least some of said one or more folders. (Guarraci, ¶¶ 10, 62-64, 68, 78-79, 110, 116, 119-120, query is performed by registering for notification (¶¶ 62-64, 68) and receiving changes/metadata for the files within the requested directory (¶ 110); Parkison, ¶¶ 397, 418-422, “each cloud controller can provide a set of "shares" that represent locally owned sub-hierarchies, and track a set of mappings that link all of the shares for the distributed filesystem. For instance, these mappings may be tracked as a set of links to sub-hierarchies of files that are owned by other cloud controllers…All of the cloud controllers synchronize both changes to their locally owned file systems as well as changes to the namespace mappings with the other cloud controllers of the distributed filesystem, and thus all cloud controllers can continuously track all of the directories that are available across the set of cloud controllers and the directory mappings themselves”)
Claim 25. The method of Claim 22, further comprising:
receiving a current revision identifier from said remote file storage system, said current revision identifier defining a current state of said second instance of said set of objects; and (Guarraci, ¶¶ 10, 62-64, 68, 78-79, 110, 116, last version identifier of the registered directory/folder (¶¶ 62-64, 68, 78) is compared with current version identifier for synchronization of the registered directory/folder in the multi-client file storage system (figs. 3, 6-7))
storing said current revision identifier in said LFS metadata associated with at least one folder of said subscribed namespace. (Guarraci, ¶¶ 10, 62-64, 68, 75, 78-79, 110, 116, last version identifier of the registered directory/folder (¶¶ 62-64, 68, 78) is compared with current version identifier for synchronization of the registered directory/folder in the multi-client file storage system (figs. 3, 6-7); a registered project/directory (¶ 75) in a local LFS is updated with respect to a registered name space (¶ 78); Parkison, ¶¶ 397, 418-422, “each cloud controller can provide a set of "shares" that represent locally owned sub-hierarchies, and track a set of mappings that link all of the shares for the distributed filesystem. For instance, these mappings may be tracked as a set of links to sub-hierarchies of files that are owned by other cloud controllers…All of the cloud controllers synchronize both changes to their locally owned file systems as well as changes to the namespace mappings with the other cloud controllers of the distributed filesystem, and thus all cloud controllers can continuously track all of the directories that are available across the set of cloud controllers and the directory mappings themselves”)
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: memory for storing data and code, said data and code including a set of native instructions for causing at least one hardware processor to perform a corresponding set of native operations when executed by said at least one hardware processor, (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”)
a particular storage space, said particular storage space identifying a set of objects accessible by a particular user, (¶ 27, a storage space is defined for a user because “a user’s storage space” including local and remote storages are unified such that from “a user's perspective, the virtual file system acts like a hard drive, except the data is stored elsewhere”)
said LFS including a plurality of LFS objects, said plurality of LFS objects including a first instance of said set of objects stored in persistent storage at a first physical location, each LFS object of said plurality of LFS objects being associated with LFS metadata indicative of a state of said each LFS object of said plurality of LFS objects; (¶¶ 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 prior revision identifier, said prior revision identifier defining a state of a second instance of said set of objects; (¶ 54, 79, 92, 101, a particular user defined storage identifier such as local or storage provided as service (fig. B, 831, 835, ¶ 63) is used for a particular revision of the root directory of the virtual file system (identifier) (¶ 101) for synchronization of a particular revision of a file (identifier) in the particular branch of the tree with the storage cloud; a VFS manages multiple data volumes each of which is associated with particular node in a particular commit tree as in ¶ 94))
a remote cloud interface configured to establish a connection with said remote file storage system; and (fig. 1A, ¶¶ 53 and 129, clients are communicatively connected to cloud storage for file operations)
a synchronizer including a subset of said set of native instructions configured to synchronize said LFS with said RFS as of a first time, said RFS including a plurality of RFS objects said plurality of RFS objects including said second instance of said set of objects stored in persistent storage at a second physical location, each RFS object of said plurality of RFS objects being synchronized with a corresponding LFS object and being associated with RFS metadata indicative of a state of said each RFS object of said plurality of RFS objects; (¶¶ 53-55, 69-70, 90-94, 125-131, 147, as noted above, local and remote devices are physical locations for storing and synchronizing files/objects along with metadata indicative of version of the files/objects)
initiate a second synchronization process with said remote file storage system, (figs. 6A-6E and ¶¶ 55, 110-117 and ¶¶ 125-131, a VFS synchronizes with the storage devices in the storage cloud on-demand or periodically)
provide at least one storage space identifier to said remote file storage system, said storage space identifier being indicative of said particular storage space, (¶ 54, 79, 92, 101, a particular user defined storage identifier such as local or storage provided as service (fig. B, 831, 835, ¶ 63) is used for a particular revision of the root directory of the virtual file system (identifier) (¶ 101) for synchronization of a particular revision of a file (identifier) in the particular branch of the tree with the storage cloud; a VFS manages multiple data volumes each of which is associated with particular node in a particular commit tree (¶ 94))
provide said prior revision identifier associated with said portion of the storage to said remote file storage system. (figs. 6A-6E, ¶¶ 92-94, 130, each particular revision identifier of a file node, directory node or commit node in the commit tree has a reference to its predecessor tree node/prior version identifier that has been synchronized, ¶ 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. This mechanism is built into the commit tree because each tree node data structure (file node 201, directory node 203, or commit node 205) has a reference to its predecessor tree node”, ¶ 130)
receive information from said remote file storage system, said information being indicative of differences between a current state of said second instance of said set of objects and a prior state of said second instance of said set of objects at said first time, (¶ 55, 92 and 125-131, wherein local storage system has access to information/metadata related to current and prior versions stored in the remote storage system/commit nodes as in ¶ 92, the information is used for synchronizing remote virtual versions according to modified version as in ¶ 55, “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”; ¶¶ 125-131)
generate file system operations based at least in part on said received information, (based on the information as noted in the previous steps, file system operation is generated for synchronization)
apply at least a first portion of said file system operations to said LFS objects; and provide at least a second portion of said file system operations to said remote file storage system to be applied to said RFS objects; and wherein said set of