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 .
Response to Amendment
Applicant’s Remarks/Arguments filed on January 29th, 2026, have been carefully considered.
Claims 1, 9, and 17 have been amended.
Claims 7 and 8 have been canceled.
Claims 1-6 and 9-22 are currently pending in the instant application.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6 and 9-22 are rejected under 35 U.S.C. 103 as being unpatentable over Lev-Ran et al. [US2007/0124415] hereinafter Lev, in view of Prakash et al. [US7,996,636] further in view of El-Beltagy et al [US2014/0280563]. Lev teaches method and apparatus for reducing network traffic over low bandwidth links. Prakash teaches uniquely identifying block context signatures in a storage volume hierarchy. El-Beltagy teaches method and device for peer arrangement in multiple substream upload P2P overlay networks.
Regarding claims 1, 9, and 17, Lev teaches a method [Lev abstract “…a method is disclosed for reducing network traffic..”] comprising:
identifying [Lev paragraph 0046, lines 5-6 “… A signature is computed for each of the one or more data chunks…”] portions of a dataset that are missing from a cloud-based target storage system [Lev paragraph 0046, lines 6-10 “…Then, for each of the one or more data chunks, the sender determines whether that data chunk has previously been transmitted by looking up the signature of that data chunk in a sender index table that associates signatures with unique index values. If the that data chunk has not been previously transmitted, the second creates a new index value…”].
Lev fails to explicitly teach a set of ancestors corresponding to the portions of the dataset.
However, Prakash does teach identifying a set of ancestors corresponding to the portions of the dataset [Prakash column 21, lines 37-65 “…assigns unique IDs (e.g., bufftree IDs) to volumes of the storage volume hierarchy, yet allows clone volumes to determine that data blocks belong to an appropriate ancestor volume (e.g., and were written by the ancestor volume prior to creation of the clone). In this manner, the novel technique may uniquely identify and accurately deter-mine whether an accessed data block is a correct data block (e.g., alleviating occurrences of data ID aliasing). Operationally, when volumes 750 are created within an aggregate 700 in a manner described above, each volume is assigned a unique bufftree ID 773 in accordance with the present invention. In particular, clone volumes 950 that are created from parent volumes 805 are assigned a bufftree ID 973 that is unique from the parent volume's buff-tree ID 813. In other words, the bufftree ID for the container file of each particular volume of the aggregate 700 is assigned a unique value. Also, upon creation, a clone volume 950 may be configured to store the bufftree ID 813 of the parent volume, for example, within an ancestor (parent) bufftree ID field 997 of the clone volume's storage label file 990. Notably, when the parent volume 805 is a clone volume of another parent volume, the bufftree IDs of the parent volume's parent may also be stored (i.e., storing the bufftree IDs for all ancestors of the clone volume). In other words, a chain of relation-ship is established between a clone volume and its ancestor volumes in a storage volume hierarchy…”].
Lev and Prakash are analogous arts in that they both deal with improving memory performance.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lev’s identifying missing data with Prakash’s teachings of identifying a set of ancestors for the benefit of alleviating the occurrences of data ID aliasing particularly for related siblings and ancestors by more finely grained context checking [Prakash column 26, lines 63-66 “…the present invention advantageously allows for more finely grained context checking, thus alleviating occurrences of data ID aliasing, particularly for clone volumes and their related siblings and ancestors (parents)…”].
wherein the dataset is to be replicated from a source storage system [Lev paragraph 0046, first lines “…At a sender, a data block is received for transmission to a receiver, where the sender and the receiver are connected over a communication link…”] to the cloud-based target storage system [Lev paragraph 0221, first lines “…one or more edge servers connect to the same core server, where the edge servers may be established in the LANs of the branch offices of a business organization and the core server may be established at the LAN of the main office…”(The examiner has determined the prior art to be older than the term “cloud” yet the edge servers would read on a “cloud-based target”.)]; and
Lev and Parkash fail to explicitly teach sending, identifiers for one or more of the portions of the dataset to an additional storage system other than the source storage system; and directing copying of the one or more portions of the dataset to the cloud-based target storage system from the additional storage system.
However, El-Beltagy does teach sending, [El-Beltagy paragraph 0012, middle lines “…sending, from a network peer requesting to download data content…”], identifiers for one or more of the portions of the dataset [El-Beltagy paragraph 0012, middle lines “…a request to download a single content sub-stream…” and paragraph 0045, middle lines “…a content stream is divided into a number of sub-streams sometimes referred to as stripes. For instance, if the content stream rate is 1 Mbps, and 4 stripes are used to distribute the content, each stripe would constitute a sub-stream of 256 kbps. Given a peer with an upload capacity of 1.5 Mbps which distributes data to six other peers with a maximum upload capacity of 256 kbps, this peer is said to have six "seats" since it can upload six stripes simultaneously to other peers with a predetermined upload bandwidth…”(Where the stripes are identifiers for one or more portions of the streaming dataset.)] to an additional storage system other than the source storage system [El-Beltagy paragraph 0012, last lines “…from a respective one of selected network peers being arranged at a distribution level closer to the streaming source than the requesting network peer…”(In a P2P network the peers become sources which reads on retrieve data from an additional source.)].
Lev, Prakash and El-Beltagy are analogous arts in that they both deal with data replication of data.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to the teachings of Lev and Prakash with El-Beltagy peer-to-peer source replication for the benefit of reducing latency in a data transmission network by using an additional source closer to the peer and thus improving performance [El-Beltagy paragraph 0016, first lines “…advantageously facilitates connecting peers to one another in a P2P network in a manner that efficiently exploits all available peer bandwidth while at the same time arranging the peers in an overlay that is resilient to failure…”].
Prakash teaches and the set of ancestors corresponding to the one or more of the portions of the dataset [Prakash column 21, lines 37-65 “…assigns unique IDs (e.g., bufftree IDs) to volumes of the storage volume hierarchy, yet allows clone volumes to determine that data blocks belong to an appropriate ancestor volume (e.g., and were written by the ancestor volume prior to creation of the clone). In this manner, the novel technique may uniquely identify and accurately deter-mine whether an accessed data block is a correct data block (e.g., alleviating occurrences of data ID aliasing). Operationally, when volumes 750 are created within an aggregate 700 in a manner described above, each volume is assigned a unique bufftree ID 773 in accordance with the present invention. In particular, clone volumes 950 that are created from parent volumes 805 are assigned a bufftree ID 973 that is unique from the parent volume's buff-tree ID 813. In other words, the bufftree ID for the container file of each particular volume of the aggregate 700 is assigned a unique value. Also, upon creation, a clone volume 950 may be configured to store the bufftree ID 813 of the parent volume, for example, within an ancestor (parent) bufftree ID field 997 of the clone volume's storage label file 990. Notably, when the parent volume 805 is a clone volume of another parent volume, the bufftree IDs of the parent volume's parent may also be stored (i.e., storing the bufftree IDs for all ancestors of the clone volume). In other words, a chain of relation-ship is established between a clone volume and its ancestor volumes in a storage volume hierarchy…”]
El-Beltagy teaches directing copying of the one or more portions of the dataset to the cloud-based target storage system from the additional storage system [El-Beltagy paragraph 0055, middle lines “…the entering peer with a list of k randomly selected peers from which the data content can be downloaded as well as the assigned level of the entering peer. Thus, the entering peer requests in step S103 one of the peers on the list to supply it with the latest subset of data given the determined network level for the entering peer. If there exists at least one peer out the k selected peers which is arranged at a level closer to the streaming source than that determined for the entering peer, the requested data content will be uploaded in step S104 to the entering peer with some…].
Regarding claims 2 and 10, as per claim 1, Lev teaches further comprising receiving, by the cloud-based target storage system, a metadata identifier associated with the dataset [Lev paragraph 0084, middle lines “…The message may include one or more parameters associated with the existing data transmission context, such as, for example, a context identifier, an index range, and an allocated context size…”].
Regarding claims 3, 11, and 18, as per claim 1, Lev teaches further comprising sending, from the cloud-based target storage system to the source storage system, information describing portions of the dataset that are stored on the cloud-based target storage system [Lev paragraph 0079, last half “…At the receiver, the data transmission context comprises a receiver index table, which maps index values to the locations of previously transmitted data chunks in a receiver cache. The mapping of index values to data chunks is also referred to herein as a "receiver dictionary."…”].
Regarding claims 4, 12, and 19, as per claim 1, Lev teaches further comprising receiving, from the source storage system and based on the information describing portions of the dataset that are stored on the cloud-based target storage system, information describing portions of the dataset that are not stored on the cloud-based target storage system [Lev paragraph 0073, all lines “…both the sender and the receiver keep a record of previously transmitted data chunks--the sender keeps a sender index table that associates the signatures of these data chunks with unique index values, and the receiver keeps a cache of these previously transmitted data chunks and a receiver index table that associates the unique index values with locations in the cache of these data chunks…”].
Regarding claims 5, 13, and 20, as per claim 1, El-Beltagy teaches comprising sending, from the cloud-based target storage system to an additional source storage system [El-Beltagy paragraph 0012, middle lines “…sending, from a network peer requesting to download data content…” and paragraph 0012, last lines “…from a respective one of selected network peers being arranged at a distribution level closer to the streaming source than the requesting network peer…”(In a P2P network the peers become sources which reads on retrieve data from an additional source.)], a request for one or more portions of the dataset [El-Beltagy paragraph 0012, middle lines “…a request to download a single content sub-stream…”], wherein the request in generated based on the information describing portions of the dataset that are not stored on the cloud-based target storage [El-Beltagy paragraph 0012, middle lines “…a request to download a single content sub-stream…” and paragraph 0045, middle lines “…a content stream is divided into a number of sub-streams sometimes referred to as stripes. For instance, if the content stream rate is 1 Mbps, and 4 stripes are used to distribute the content, each stripe would constitute a sub-stream of 256 kbps. Given a peer with an upload capacity of 1.5 Mbps which distributes data to six other peers with a maximum upload capacity of 256 kbps, this peer is said to have six "seats" since it can upload six stripes simultaneously to other peers with a predetermined upload bandwidth…”(Where the stripes are identifiers for one or more portions of the streaming dataset.)] .
Regarding claims 6, and 14, as per claim 1, Lev teaches comprising receiving, by the cloud-based target storage system from the additional source storage systems, the one or more portions of the dataset [Lev paragraph 0112, all lines “…Once inter-block compression module 288 has processed every entry in the received read vector in this manner, the module assembles, or reconstructs, the original data block by putting together the one or more data chunks in the order they are represented by the entries of the read vector. The assembled block is passed back to CIFS read flow module 286, which in turn passes it to CIFS client 282. CIFS client 282 sends the data block to the network client through which the user requested the data block…”].
Regrading claim 21, as per claim 1, El-Beltagy teaches replicating one or more portions of the dataset to the cloud-based target storage system from a second additional storage system other than the additional storage system [El-Beltagy paragraph 0012, last lines “…which P2P network the streaming source is arranged to divide data content to be streamed into a plurality of content sub-streams together forming the data content and to distribute the plurality of content sub-streams to the network peers. The method comprises sending, from a network peer requesting to download data content, a request to download a single content sub-stream from a respective one of selected network peers being arranged at a distribution level closer to the streaming source than the requesting network peer until a number of content sub-streams have been downloaded by the requesting network peer from which the requested data content can be formed…”].
Regarding claim 22, as per claim 1, El-Beltagy teaches replicating one or more portions of the dataset to the cloud-based target storage system from the source storage system [El-Beltagy paragraph 0051, last lines “…If the requesting peer cannot find an uploading peer which can supply the requesting peer with a requested stripe, the requesting peer will have to turn to the streaming source (unless the requesting peer have enough stripes to form the requested data content)…”].
Response to Arguments
Applicant’s arguments with respect to claims 1, 9, and 17, have been considered but are moot in view of new grounds of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC CARDWELL whose telephone number is (571)270-1379. The examiner can normally be reached on Monday - Friday 10-6pm 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, Reginald Bragdon can be reached on (571) 272-4204. 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 http://pair-direct.uspto.gov. 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.
/ERIC CARDWELL/Primary Examiner, Art Unit 2139
Prosecution Insights