DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-15 of this US application are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/13/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for 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 1, 4-5, 7-12 and 14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Braginsky et al. (US 2009/0216815, hereinafter “Braginsky”).
Regarding claim 1, Braginsky teaches A system comprising:
a first computing device of a first computing system able to communicate over a network with a second computing device of a second computing system, wherein data is replicated between the first computing system and the second computing system ([0021] and Fig. 1: A server 106 is also electrically coupled to the network, such that the client computers 102(1)-(n) can communicate with the server 106 via the network 104.), the first computing device configured to perform operations comprising:
receiving, by the first computing device, a first metadata change made to metadata of a first instance of an object stored at a storage location associated with the first computing device ([0032]: In a first phase (operations 602-608), sometimes called the commit phase, the client system sends to the server all client metadata entries (also sometimes called client meta-directory entries) that have been modified by the client (602).);
associating, by the first computing device, with the first metadata change, a time of the first metadata change ([0033]: In some embodiments, the server assigns a version number to each new server metadata entry and assigns a new version number to each updated server metadata entry. Alternately, or in addition, it may store a timestamp in the server metadata entry to indicate the date and time of the last update made to the server metadata entry.);
based on receiving replication of a second instance of the object from the second computing device of the second computing system, determining that a second metadata change was made to metadata of the second instance of the object at the second computing system, wherein the second instance of the object includes a time of the second metadata change ([0034]: As noted above, each metadata entry includes a timestamp (synch_ts) indicating the last time the entry was changed on the server. The server identifies and sends to the client the requested server metadata entries (612).); and at least one of:
resolving, by the first computing device, a conflict between the first metadata change and the second metadata change based at least in part on comparing the time of the first metadata change with the time of the second metadata change ([0034]: As noted above, each metadata entry includes a timestamp (synch_ts) indicating the last time the entry was changed on the server. The server identifies and sends to the client the requested server metadata entries (612). [0036]: When a received server metadata entry conflicts with one or more corresponding client metadata entries (i.e., entries having the same filed ID and/or the same filename), the process requires a user to resolve the conflict (616). As noted above, the user may resolve the conflict by selecting a client or server version of a file (and its metadata) as the "winner," in which case the losing file and/or its metadata will be overwritten by the winning file and/or its metadata, or the user may rename or move the conflicting client file so as to eliminate the conflict. Changes are applied to the client meta-directory in accordance with the user specified resolution of the conflict (616). This may include deleting or revising one or more client metadata entries. In addition, the client schedules any file content uploads or downloads needed to implement the user specified resolution of the conflict (616).), or
merging, by the first computing device, the first metadata change with the second metadata change into the metadata for the object ([0035]: When a received server metadata entry does not conflict with any corresponding client metadata entries (i.e., entries having the same filed ID and/or the same filename), the metadata changes in the server metadata entry are applied to the corresponding client metadata entry (614). Alternately, the received server metadata entry is used to overwrite the corresponding client metadata entry, if any.).
Regarding claim 4, Braginsky teaches the operations further comprising replicating, by the first computing device, the first instance of the object to the second computing device at the second computing system, wherein the second computing device at the second computing system is configured to resolve the conflict between the first metadata change and the second metadata change based at least in part on comparing the time of the first metadata change with the time of the second metadata change ([0034]: As noted above, each metadata entry includes a timestamp (synch_ts) indicating the last time the entry was changed on the server. The server identifies and sends to the client the requested server metadata entries (612). [0041]: If newer metadata is present on the server (408--Yes), then the server rejects the metadata entry received from the client (410). In addition to checking for newer metadata, the server determines, at 414, if another data object exists on the server with the same path.).
Regarding claim 5, Braginsky teaches replicating, by the first computing device, the first instance of the object to a third computing device at a third computing system; replicating, by the second computing device, the second instance of the object to the third computing device at the third computing system; and wherein the third computing device at the third computing system is configured to resolve the conflict between the first metadata change and the second metadata change based at least in part on comparing the time of the first metadata change with the time of the second metadata change ([0022]: [0022] In use, the server acts as a virtual file repository or disk drive for the client computers 102(1)-(n), i.e., the local client computers and the server store synchronized copies of various data objects. Data objects as used herein are any collection of related data or program records stored as a unit, such as folders, data files, email messages, instant messages, text documents, word processing documents, figures, databases or the like. Where possible, e.g., where the client and server are connected via the network, local data objects on the client computers and server data objects on the server are synchronized, subject to the conflict resolution procedures described below in relation to FIGS. 4A, 4B, 5A and 5B.).
Regarding claim 7, Braginsky teaches wherein the time of the first metadata change is stored with the metadata of the first instance of the object and replicated with the metadata of the first instance of the object during replication of data to the second computing device at the second computing system ([0033]: Alternately, or in addition, it may store a timestamp in the server metadata entry to indicate the date and time of the last update made to the server metadata entry. [0034]: As noted above, each metadata entry includes a timestamp (synch_ts) indicating the last time the entry was changed on the server. The server identifies and sends to the client the requested server metadata entries (612).).
Regarding claim 8, Braginsky teaches wherein the operation of merging the first metadata change with the second metadata change into the metadata for the object further comprises: storing, by the first computing device, both the first metadata change and the second metadata change in the metadata of the first instance of the object stored by the first computing device ([0007]: According to some embodiments there is provided a computer implemented method for managing shared data conflicts. In one aspect of the method, a client stores client metadata entries corresponding to a plurality of data objects. During a first phase of a synchronization process, the client sends one or more client metadata entries to a server. [0008]: In some embodiments, another aspect of the method includes a server that stores server metadata entries corresponding to a plurality of data objects.).
Regarding claim 9, Braginsky teaches receiving, by the first computing device, in replication of data received from the second computing device, a third instance of the object in which the first metadata change has been merged with the second metadata change ([0046]: The client transmits a request to the server requesting any changes to the metadata on the server, at 432. The request includes an indication of when the last synchronization occurred between the server and the client. In some embodiments, this indication may be the synchronization time stamp (synch TS) 230 (FIG. 2A). The request is then received by the server (434). [0047]: The servers then determine whether any changes to any of the data objects or metadata have been made since the last time that the server synchronized with the client.).
Regarding claim 10, Braginsky teaches based at least on determining that the metadata of the third instance of the object includes the first metadata change and the second metadata change, deleting, from the metadata associated with the first instance of the object, the time associated with the first metadata change and user information associated with the first metadata change ([0033]: In some embodiments, the server assigns a version number to each new server metadata entry and assigns a new version number to each updated server metadata entry. Alternately, or in addition, it may store a timestamp in the server metadata entry to indicate the date and time of the last update made to the server metadata entry. [0034]: As noted above, each metadata entry includes a timestamp (synch_ts) indicating the last time the entry was changed on the server.).
Regarding claim 11, Braginsky teaches wherein a third metadata change is received with the replication of the second instance of the object from the second computing device of the second computing system, the operations further comprising: resolving a conflict between the first metadata change and the second metadata change based at least in part on comparing the time of the first metadata change with the time of the second metadata change to select a metadata change from the first metadata change and the second metadata change based on resolving the conflict ([0034]: As noted above, each metadata entry includes a timestamp (synch_ts) indicating the last time the entry was changed on the server. The server identifies and sends to the client the requested server metadata entries (612). [0036]: When a received server metadata entry conflicts with one or more corresponding client metadata entries (i.e., entries having the same filed ID and/or the same filename), the process requires a user to resolve the conflict (616).);
determining that the third metadata change does not conflict with the selected metadata change; and merging the third metadata change and the selected metadata change into a single instance of the object at the first computing system ([0035]: When a received server metadata entry does not conflict with any corresponding client metadata entries (i.e., entries having the same filed ID and/or the same filename), the metadata changes in the server metadata entry are applied to the corresponding client metadata entry (614). Alternately, the received server metadata entry is used to overwrite the corresponding client metadata entry, if any.).
Claim 12 is rejected under the same rationale as claim 1.
Claim 14 is rejected under the same rationale as claim 1. Braginsky also teaches One or more non-transitory computer-readable media storing one or more programs executable by a first computing device of a first computing system to configure the first computing device to perform operations ([0024]: The memory 206 (which may comprise or include a computer readable storage medium) preferably includes an operating system 220, such as LINUX, having instructions for processing, accessing, storing, or searching data, etc.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2-3, 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Braginsky in view of Papernik et al. (US 11,593,351, hereinafter “Papernik”).
Regarding claim 2, Braginsky teaches the system of claim 1 as discussed above. Braginsky does not explicitly teach the operations further comprising resolving, by the first computing device, the conflict based in part on a comparison of user information related to a first user indicated to be a source of the first metadata change with user information related to a second user indicated to be a source of the second metadata change.
Papernik teaches the operations further comprising resolving, by the first computing device, the conflict based in part on a comparison of user information related to a first user indicated to be a source of the first metadata change with user information related to a second user indicated to be a source of the second metadata change (column 27 lines 19-28: discussing about to compare the first current status for the user account from the provisioning service device to the second current status of the user account in the status log; determine the first current status for the user account from the provisioning service device does not match the second current status of the user account in the status log based on the comparison to detect conflicting information of the user account between the current status information in the status log and the account status information in the provisioning service device; determine whether to update the second current status of the status log based on the detected conflicting information and update the second current status of the status log by using modification instructions to correct the conflicting information of the user account in the status log, wherein correcting the conflicting information of the user account in the status log results in the current status information of the status log matching the account status information of the user account in the provisioning service device).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the synchronization process of Braginsky with the teaching about the comparison of user information of Papernik because it allows for individual changes to be made without affecting other groups which improves the efficiency of the system (Papernik column 21 lines 39-41).
Regarding claim 3, Braginsky in view of Papernik teaches wherein the user information related to the first user indicates at least one of: a role of the first user with respect to the object (Papernik, column 20 line 61 – column 21 line 1: For example, continuing with the previous example, the first data control device 104A may send service instructions 128 to the second data control device 104B based on changes that were made to a user's role or title. In this example, the second data control device 104B may use a look-up table to determine the settings or permissions that are associated with the new role or title for the user.), or privileges of the first user with respect to the object (Papernik, column 10 lines 42-45: As an example, a validation rule 122 may indicate that a service request 300 is valid when the service request 300 identifies a user account 126 that is associated with at least a minimum number of account owners.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the synchronization process of Braginsky with the teaching about the comparison of user information of Papernik because it allows for individual changes to be made without affecting other groups which improves the efficiency of the system (Papernik column 21 lines 39-41).
Claim 13 is rejected under the same rationale as claim 2.
Claim 15 is rejected under the same rationale as claim 2.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Braginsky in view of Sedan et al. (US 2020/0409975, hereinafter “Sedan”).
Regarding claim 6, Braginsky teaches the system of claim 5 as discussed above. Braginsky does not explicitly teach wherein the first computing system, the second computing system and the third computing system are arranged in an active-active ring replication configuration.
Sedan teaches wherein the first computing system, the second computing system and the third computing system are arranged in an active-active ring replication configuration ([0051] and Fig. 1: Referring to FIG. 1, one embodiment of a ring replication system is shown in accordance with one embodiment of the present invention. Ring replication system 100 includes a central ring of four electronic storage devices R1 (node 102), R2 (node 104), R3 (node 106), and R4 (node 108).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the synchronization process of Braginsky with the teaching about the ring replication of Sedan because the disclosed ring replication system also guarantees against data loss of stored data in the event of network or machine failure (Sedan, [0106]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Towle (US 2017/0005883) discloses that a ring replication strategy may guarantee a fixed number of replication channels independent of the number of distributed compute grid systems. In one embodiment, a ring replication strategy is only used for important state data, or state data that, in the event of a planned maintenance activity, needs to exist in whatever distributed compute grid system an active session is routed to. Whether a ring replication strategy is suitable may be based on the acceptability of end-user impact of important state data not existing ([0050]).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHONG H NGUYEN whose telephone number is (571)270-1766. The examiner can normally be reached Monday-Friday, 8:30am-5pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ajay Bhatia can be reached at (571) 272-3906. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PHONG H NGUYEN/ Primary Examiner, Art Unit 2156
December 2, 2025