DETAILED ACTION
Applicant’s Amendment filed on September 24, 2026 has been reviewed.
Claims 1, 8 and 16 are amended in the amendment.
Claims 1-16 have been examined.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on September 24, 2026 has been entered.
Claim Rejections - 35 USC § 103
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-5, 7-9, 12 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Beard et al. (WO 2015/031540 A1), hereinafter referred to as Beard, in view of Kramer et al. (US 2017/0046199 A1), hereinafter referred to as Kramer.
With respect to claim 1, Beard teaches A method of data processing using a proxy (providing a transparent virtualization of the source filer 102, so that the client terminals continue to issue requests for use of the source filer 102 for purpose of intercepting and proxying client/source filer exchanges, para. 0047; fig. 1B), the method comprising:
receiving, from a client device (the data migration system 100 can provide a transparent virtualization of the source filer 102, so that the client terminals continue to issue requests for use of the source filer 102 for purpose of intercepting and proxying client/source filer exchanges, para. 0047; fig. 1B), a first data object request requesting a first data object, wherein the first data object request is directed by the client device to a first networked data storage server (the file system server 110 fields file system requests 111 from clients 101 while the replication engine 124 implements replication processes that populate and update the destination filer 104; requests communicated from the clients 101 that utilize the source filer 102 [first networked data storage server] are inspected in order to identify file system objects that need to be migrated or updated on the destination filer 104, para. 0050; fig. 1B);
determining, using the proxy, whether the requested first data object is available from a second networked data storage server (a determination is made as to whether the file system object has previously been migrated to the destination filer (512); an OID key can be determined for the file system object and then used to determine whether the object was previously migrated to the destination filer 104, para. 0111; fig. 5; see para. 0036; if the file handle is associated with a file system object that has not previously been replicated, then the file system server 110 initiates steps (732) to replicate the file system object on the destination filer., para. 0117; fig. 7; the file/object lookup 120 uses the OID store 122 to map the file handle 129 of a requested file system object to an object identifier (OID) node 131, para. 0055; when a request is received that specifies a file system object 113, file system server 110 uses the file handle 129 of the requested file system object to check whether an object identifier (OID) exists for the specified file handle; the file system server 110 communicates the file handle 129 to the file/object lookup 120; the file/object lookup 120 references the file handle 129 to determine if a corresponding OID node 131 exists; if an OID node 131 exists for the file handle 129, then the assumption is made that the corresponding file system objects 113 in the source filer 102 has previously been processed for data migration to the destination filer 104, para. 0060), wherein the second networked data storage server is separate from the proxy and is accessible by the proxy over a network (a data migration system 100 operates to migrate data from a source filer 102 to a destination filer 104; each of the source and destination filers 102, 104 can correspond to a network- based file system, para. 0044; fig. 1B; the data migration system 100 is implemented through use of one or more in-line appliances and/or software and operates independently, is self-contained, and installs in the network path between the clients and file servers, para. 0046 [destination filer 104 is a network-based file system distinct from the in-line data migration system 100]);
if the requested first data object is available from the second networked data storage server, retrieving the requested first data object from the second networked data storage server using the proxy (the server 20 can include comparison logic 22 retrieving a metadata set from the source filer 102 using the file handle of the incoming client request 11, para. 0036; fig. 1A; when a particular file system object is deemed valid, the target memory 30 can be used to provide a response to a corresponding client request 11, para. 0038; when the migration has progressed to the point that the destination filer 104 provides the responses to the client requests 111, the mapper 160 can translate the attributes of a file system object retrieved from the destination filer 104, para. 0072; also see para. 0094; fig. 2D);
if the requested first data object is not available from the second networked data storage server, retrieving the requested first data object from the first networked data storage server using the proxy (the server 20 include comparison logic 22 retrieving a metadata set from the source filer 102 using the file handle of the incoming client request 11, para. 0036; fig. 1A; the asynchronous replication of the file system object enables the client requests to readily be forwarded to the source filer for response (530); if the forwarded request is a read-type request (532), a response is received from the source filer for the read request and forwarded to the client (540), para. 0112; fig. 5; also see para. 0108);
providing the requested first data object to the client device (if the forwarded request is a read-type request (532), a response is received from the source filer for the read request and forwarded to the client (540), para. 0112; fig. 5; also see, para. 0038); and
if the requested first data object is not available from the second networked data storage server, providing the requested first data object, using the proxy, to the second networked data storage server (when the file/object lookup 120 determines that no OID node 131 exists in the OID store 122 for a given file handle 129, then the replication engine 124 is triggered to replicate the corresponding file system object to the destination filer 104, para. 0063, also see para. 0117; fig. 7A), thereby opportunistically migrating the first data object from the first networked data storage server, on a per-request basis, to the second networked data storage server (the determination is that the object has not previous been migrated, a sequence of operations may be queued and asynchronously implemented in which the file system object is replicated on the destination file system 104 (520), para. 0112; fig. 5; the replication engine 124 can replicate the corresponding file system object by performing a read operation on the source filer 102 for the newly discovered file system object, then triggering a create operation to the destination filer 104 (or the destination caching engine 118) in order to create the discovered file system object on the destination filer, para. 0068; the replay logic 133 issue a create operation 159 to replicate the file system object 135 at the destination filer 104, para. 0069; fig. 1B), wherein the migrating reduces subsequent usage of the first networked data storage server (the server 20 can associate a state with each replicated file system object 17 of the target memory 30; a particular file system object is deemed valid, the target memory 30 used to provide a response to a corresponding client request 11 to enhance performance when compared to the source filer 12, para. 0038; in a cut-over stage, when the destination filer 204 is used to handle client requests while the clients remain mounted to the source filer 202; the data migration system 203 operates to transparently forward the requests to the destination filer 204 for response, and also forwards the response from the destination filer to the clients 201; thus, the data migration system 203 forwards the requests 241 to the destination filer 204, and not to the source filer 202para. 0094; fig. 2D; the request can made to the source cache engine 132, rather than to the source filer 102; this offloads some of the load required from the source filer 102 during the migration process, para. 0066; also see para. 0112).
Bread does not explicitly teach wherein the first networked data storage server is a server operated by a provider that imposes constraints on usage of the first networked data storage server, wherein the constraints comprise a limit, imposed by the provider, on at least one of a bandwidth capacity limit, a latency constraint, or a throughput limit;
However, Kramer teaches wherein the first networked data storage server is a server operated by a provider that imposes constraints on usage of the first networked data storage server (the system (100) includes a source service (102), the source service (102) is a storage provider that is currently storing a customer's objects need to migrate to, para. 0022-0024; al see para. 0012; fig. 1; a storage provider limit the customer's bandwidth making it difficult to quickly transfer the entire volume of data, a bandwidth limit result in throttling simultaneous connections by the customer as well as produce high error rates for the customer's data, para. 0012), wherein the constraints comprise a limit, imposed by the provider, on at least one of a bandwidth capacity limit, a latency constraint, or a throughput limit (a storage provider limit the customer's bandwidth making it difficult to quickly transfer the entire volume of data, a bandwidth limit result in throttling simultaneous connections by the customer as well as produce high error rates for the customer's data, para. 0012) in order to ensure that each of the customers have access to their data when desire as taught by Kramer (para. 0001);
Therefore, based on Bread in view of Kramer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Kramer to the method of Beard in order to ensure that each of the customers have access to their data when desire as taught by Kramer (para. 0001).
With respect to claim 2, Bread teaches The method of claim 1, wherein determining whether the requested first data object is available from the second networked data storage server comprises executing an asynchronous query (the data migration system 100 can implement processes that initially populate the destination filer 104 asynchronously, while the clients actively use the source filer 102; moreover, file system operations communicated from the clients 101 can be implemented asynchronously at the destination filer 104, para. 0049; also see para. 0061 and 0067).
With respect to claim 3, Bread teaches The method of claim 1, wherein determining whether the requested first data object is available from the second networked data storage server comprises reading from a record of data object availability created by the proxy in response to prior requests (when a request is received that specifies a file system object 113, file system server 110 uses the file handle 129 of the requested file system object to check whether an object identifier (OID) exists for the specified file handle; the file system server 110 communicates the file handle 129 to the file/object lookup 120; the file/object lookup 120 references the file handle 129 to determine if a corresponding OID node 131 exists; if an OID node 131 exists for the file handle 129, then the assumption is made that the corresponding file system objects 113 in the source filer 102 has previously been processed for data migration to the destination filer 104, para. 0060; also see para. 0055-0057; fig. 5).
With respect to claim 4, Bread teaches The method of claim 1, wherein determining whether the requested first data object is available from the second networked data storage server comprises:
performing a multi-stage check using a cache (the source cache engine 132 can procure and cache the attributes of the source filer 102. When the attributes are acquired for a given OID node 131 such as replication engine 124 issues GetAttr request, the request can made to the source cache engine, para. 0065-0066); and
executing a query (the source cache engine 132 can procure and cache the attributes of the source filer 102. When the attributes are acquired for a given OID node 131 such as replication engine 124 issues GetAttr request, the request can made to the source cache engine, para. 0065-0066; also see para. 0116-0117).
With respect to claim 5, Bread teaches The method of claim 1, wherein the first data object request is received according to a first protocol (the file system server 110 receives and processes NFS (version 3) packets issued from clients 101; other file system protocols can also be accommodated; the file system server 110 can include logical components that summarize the protocol-specific request (e.g. , NFS request) before processing the request in a protocol-agnostic manner, para. 0050), retrieving the first data object from the second networked data storage server is performed according to a second protocol (a data migration system 100 operates to migrate data from a source filer 102 to a destination filer 104; each of the source and destination filers 102, 104 can correspond to a network- based file system, para. 0044; fig. 1B; when a particular file system object is deemed valid, the target memory 30 can be used to provide a response to a corresponding client request 11, para. 0038; when the migration has progressed to the point that the destination filer 104 provides the responses to the client requests 111, the mapper 160 can translate the attributes of a file system object retrieved from the destination filer 104, para. 0072), and retrieving the requested first data object from the first networked data storage server is performed according to a third protocol (a data migration system 100 operates to migrate data from a source filer 102 to a destination filer 104; each of the source and destination filers 102, 104 can correspond to a network- based file system, para. 0044; fig. 1B; when a request is received that specifies a file system object 113, file system server 110 uses the file handle 129 of the requested file system object to check whether an object identifier (OID) exists for the specified file handle; the file system server 110 communicates the file handle 129 to the file/object lookup 120; the file/object lookup 120 references the file handle 129 to determine if a corresponding OID node 131 exists; if an OID node 131 exists for the file handle 129, then the assumption is made that the corresponding file system objects 113 in the source filer 102 has previously been processed for data migration to the destination filer 104, para. 0060; also see para. 0055-0057; fig. 5).
With respect to claim 7, Beard teaches The method of claim 1, further comprising:
caching the requested first data object at the proxy as a cached copy (the source cache engine 132 can cache file system objects on discovery, and subsequently identify those file system objects that are more frequently requested, para. 0051); and
providing the cached copy to the second networked data storage server as the requested first data object (the source cache engine 132 can procure and cache the attributes of the source filer 102; this offloads some of the load required from the source filer 102 during the migration process, para. 0066; the replication engine 124 can implement processes to replicate a file system object with the destination filer 104, para. 0067-0068).
With respect to claim 8, Beard teaches A method of data migration from a source networked data storage server to a target networked data storage server (providing a transparent virtualization of the source filer 102, so that the client terminals continue to issue requests for use of the source filer 102 for purpose of intercepting and proxying client/source filer exchanges, para. 0047; fig. 1B), the method comprising:
determining, using a proxy, a first protocol for interacting with the source networked data storage server (the file system server 110 receives and processes NFS (version 3) packets issued from clients 101; other file system protocols can also be accommodated; the file system server 110 can include logical components that summarize the protocol-specific request (e.g. , NFS request) before processing the request in a protocol-agnostic manner, para. 0050),
determining, using the proxy, a second protocol for interacting with the target networked data storage server (each of the source and destination filers 102, 104 can correspond to a network- based file system, such as those that utilize a protocol such as NFS Version 3 or Version 4, para. 0044), wherein the target networked data storage server is separate from the proxy and is accessible by the proxy over a network (a data migration system 100 operates to migrate data from a source filer 102 to a destination filer 104; each of the source and destination filers 102, 104 can correspond to a network- based file system, para. 0044; fig. 1B; the data migration system 100 is implemented through use of one or more in-line appliances and/or software and operates independently, is self-contained, and installs in the network path between the clients and file servers, para. 0046 [destination filer 104 is a network-based file system distinct from the in-line data migration system 100]);
receiving, from a client device using the first protocol, a first data object request requesting a first data object (the data migration system 100 can provide a transparent virtualization of the source filer 102, so that the client terminals continue to issue requests for use of the source filer 102 for purpose of intercepting and proxying client/source filer exchanges, para. 0047; fig. 1B), wherein the first data object request is directed by the client device to the source networked data storage server (the file system server 110 fields file system requests 111 from clients 101 while the replication engine 124 implements replication processes that populate and update the destination filer 104; requests communicated from the clients 101 that utilize the source filer 102 [first networked data storage server] are inspected in order to identify file system objects that need to be migrated or updated on the destination filer 104, para. 0050; fig. 1B);
obtaining the first data object from the source networked data storage server, using the first protocol (the asynchronous replication of the file system object enables the client requests to readily be forwarded to the source filer for response (530); if the forwarded request is a read-type request (532), a response is received from the source filer for the read request and forwarded to the client (540), para. 0112; fig. 5);
providing the first data object to the client device, using the first protocol (when a particular file system object is deemed valid, the target memory 30 can be used to provide a response to a corresponding client request 11, para. 0038); and
providing the first data object to the target networked data storage server, using the second protocol (when the file/object lookup 120 determines that no OID node 131 exists in the OID store 122 for a given file handle 129, then the replication engine 124 is triggered to replicate the corresponding file system object to the destination filer 104, para. 0063, also see para. 0117; fig. 7A), thereby opportunistically migrating the first data object such that subsequent requests for the first data object are serviceable from the target networked data storage server (the determination is that the object has not previous been migrated, a sequence of operations may be queued and asynchronously implemented in which the file system object is replicated on the destination file system 104 (520), para. 0112; fig. 5; the replication engine 124 can replicate the corresponding file system object by performing a read operation on the source filer 102 for the newly discovered file system object, then triggering a create operation to the destination filer 104 (or the destination caching engine 118) in order to create the discovered file system object on the destination filer, para. 0068; the replay logic 133 issue a create operation 159 to replicate the file system object 135 at the destination filer 104, para. 0069; fig. 1B), reducing subsequent usage of the source networked data storage server (the server 20 can associate a state with each replicated file system object 17 of the target memory 30; a particular file system object is deemed valid, the target memory 30 used to provide a response to a corresponding client request 11 to enhance performance when compared to the source filer 12, para. 0038; in a cut-over stage, when the destination filer 204 is used to handle client requests while the clients remain mounted to the source filer 202; the data migration system 203 operates to transparently forward the requests to the destination filer 204 for response, and also forwards the response from the destination filer to the clients 201; thus, the data migration system 203 forwards the requests 241 to the destination filer 204, and not to the source filer 202para. 0094; fig. 2D; the request can made to the source cache engine 132, rather than to the source filer 102; this offloads some of the load required from the source filer 102 during the migration process, para. 0066; also see para. 0112).
Beard does not explicitly teach wherein the source networked data storage server is a server operated by a provider that imposes constraints on usage of the source networked data storage server, wherein the constraints comprise a limit, imposed by the provider, on at least one of a bandwidth capacity limit, a latency constraint, or a throughput limit;
However, Kramer teaches wherein the source networked data storage server is a server operated by a provider that imposes constraints on usage of the source networked data storage server (the system (100) includes a source service (102), the source service (102) is a storage provider that is currently storing a customer's objects need to migrate to, para. 0022-0024; al see para. 0012; fig. 1; a storage provider limit the customer's bandwidth making it difficult to quickly transfer the entire volume of data, a bandwidth limit result in throttling simultaneous connections by the customer as well as produce high error rates for the customer's data, para. 0012), wherein the constraints comprise a limit, imposed by the provider, on at least one of a bandwidth capacity limit, a latency constraint, or a throughput limit (a storage provider limit the customer's bandwidth making it difficult to quickly transfer the entire volume of data, a bandwidth limit result in throttling simultaneous connections by the customer as well as produce high error rates for the customer's data, para. 0012) in order to ensure that each of the customers have access to their data when desire as taught by Kramer (para. 0001);
Therefore, based on Bread in view of Kramer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Kramer to the method of Beard in order to ensure that each of the customers have access to their data when desire as taught by Kramer (para. 0001).
With respect to claim 9, Beard teaches The method of claim 8, further comprising caching the first data object at the proxy after obtaining the first data object from the source networked data storage server and before providing the first data object to the target networked data storage server (the source cache engine 132 can cache file system objects on discovery, and subsequently identify those file system objects that are more frequently requested, para. 0051; the source cache engine 132 can procure and cache the attributes of the source filer 102; this offloads some of the load required from the source filer 102 during the migration process, para. 0066; the replication engine 124 can implement processes to replicate a file system object with the destination filer 104, para. 0067).
With respect to claim 12, Beard teaches The method of claim 8, wherein the first protocol and the second protocol are the same protocol (each of the source and destination filers 102, 104 can correspond to a network- based file system, such as those that utilize a protocol such as NFS Version 3 or Version 4, para. 0044).
With respect to claim 16, Beard teaches A non-transitory computer-readable storage medium storing instructions (machine-readable medium, para. 0159), which when executed by at least one processor of a computer system (processor 1104 executing one or more sequences of one or more instructions contained in main memory 1106; such instructions read into main memory 1106 from another machine-readable medium, such as storage device 1110, para. 0159), causes the computer system to:
receive, from a client device (the data migration system 100 can provide a transparent virtualization of the source filer 102, so that the client terminals continue to issue requests for use of the source filer 102 for purpose of intercepting and proxying client/source filer exchanges, para. 0047; fig. 1B), a first data object request requesting a first data object, wherein the first data object request is directed by the client device to a first networked data storage server (the file system server 110 fields file system requests 111 from clients 101 while the replication engine 124 implements replication processes that populate and update the destination filer 104; requests communicated from the clients 101 that utilize the source filer 102 [first networked data storage server] are inspected in order to identify file system objects that need to be migrated or updated on the destination filer 104, para. 0050; fig. 1B),
determine whether the requested first data object is available from a second networked data storage server (a determination is made as to whether the file system object has previously been migrated to the destination filer (512); an OID key can be determined for the file system object and then used to determine whether the object was previously migrated to the destination filer 104, para. 0111; fig. 5; see para. 0036; if the file handle is associated with a file system object that has not previously been replicated, then the file system server 110 initiates steps (732) to replicate the file system object on the destination filer., para. 0117; fig. 7; the file/object lookup 120 uses the OID store 122 to map the file handle 129 of a requested file system object to an object identifier (OID) node 131, para. 0055; when a request is received that specifies a file system object 113, file system server 110 uses the file handle 129 of the requested file system object to check whether an object identifier (OID) exists for the specified file handle; the file system server 110 communicates the file handle 129 to the file/object lookup 120; the file/object lookup 120 references the file handle 129 to determine if a corresponding OID node 131 exists; if an OID node 131 exists for the file handle 129, then the assumption is made that the corresponding file system objects 113 in the source filer 102 has previously been processed for data migration to the destination filer 104, para. 0060), wherein the second networked data storage server is separate from the computer system and is accessible over a network (a data migration system 100 operates to migrate data from a source filer 102 to a destination filer 104; each of the source and destination filers 102, 104 can correspond to a network- based file system, para. 0044; fig. 1B; the data migration system 100 is implemented through use of one or more in-line appliances and/or software and operates independently, is self-contained, and installs in the network path between the clients and file servers, para. 0046 [destination filer 104 is a network-based file system distinct from the in-line data migration system 100]);
if the requested first data object is available from the second networked data storage server, retrieve the requested first data object from the second networked data storage server (the server 20 can include comparison logic 22 retrieving a metadata set from the source filer 102 using the file handle of the incoming client request 11, para. 0036; fig. 1A; when a particular file system object is deemed valid, the target memory 30 can be used to provide a response to a corresponding client request 11, para. 0038; when the migration has progressed to the point that the destination filer 104 provides the responses to the client requests 111, the mapper 160 can translate the attributes of a file system object retrieved from the destination filer 104, para. 0072; also see para. 0094; fig. 2D);
if the requested first data object is not available from the second networked data storage server, retrieve the requested first data object from the first networked data storage server (the server 20 can include comparison logic 22 retrieving a metadata set from the source filer 102 using the file handle of the incoming client request 11, para. 0036; fig. 1A; the asynchronous replication of the file system object enables the client requests to readily be forwarded to the source filer for response (530); if the forwarded request is a read-type request (532), a response is received from the source filer for the read request and forwarded to the client (540), para. 0112; fig. 5; also see para. 0108);
provide the requested first data object to the client device(if the forwarded request is a read-type request (532), a response is received from the source filer for the read request and forwarded to the client (540), para. 0112; fig. 5; also see, para. 0038); and
if the requested first data object is not available from the second networked data storage server, provide the requested first data object to the second networked data storage server (when the file/object lookup 120 determines that no OID node 131 exists in the OID store 122 for a given file handle 129, then the replication engine 124 is triggered to replicate the corresponding file system object to the destination filer 104, para. 0063, also see para. 0117; fig. 7A), thereby opportunistically migrating the first data object from the first networked data storage server, on a per-request basic, to the second networked data storage server (the determination is that the object has not previous been migrated, a sequence of operations may be queued and asynchronously implemented in which the file system object is replicated on the destination file system 104 (520), para. 0112; fig. 5; the replication engine 124 can replicate the corresponding file system object by performing a read operation on the source filer 102 for the newly discovered file system object, then triggering a create operation to the destination filer 104 (or the destination caching engine 118) in order to create the discovered file system object on the destination filer, para. 0068; the replay logic 133 issue a create operation 159 to replicate the file system object 135 at the destination filer 104, para. 0069; fig. 1B), wherein the migrating reduces subsequent usage of the first networked data storage server subject to the constraints (the server 20 can associate a state with each replicated file system object 17 of the target memory 30; a particular file system object is deemed valid, the target memory 30 used to provide a response to a corresponding client request 11 to enhance performance when compared to the source filer 12, para. 0038; in a cut-over stage, when the destination filer 204 is used to handle client requests while the clients remain mounted to the source filer 202; the data migration system 203 operates to transparently forward the requests to the destination filer 204 for response, and also forwards the response from the destination filer to the clients 201; thus, the data migration system 203 forwards the requests 241 to the destination filer 204, and not to the source filer 202para. 0094; fig. 2D; the request can made to the source cache engine 132, rather than to the source filer 102; this offloads some of the load required from the source filer 102 during the migration process, para. 0066; also see para. 0112).
Bread does not explicitly teach wherein the first networked data storage server is a server operated by a provider that imposes constraints on usage of the first networked data storage server, wherein the constraints comprise a limit, imposed by the provider, on at least one of a bandwidth capacity limit, a latency constraint, or a throughput limit;
However, Kramer teaches wherein the first networked data storage server is a server operated by a provider that imposes constraints on usage of the first networked data storage server (the system (100) includes a source service (102), the source service (102) is a storage provider that is currently storing a customer's objects need to migrate to, para. 0022-0024; al see para. 0012; fig. 1; a storage provider limit the customer's bandwidth making it difficult to quickly transfer the entire volume of data, a bandwidth limit result in throttling simultaneous connections by the customer as well as produce high error rates for the customer's data, para. 0012), wherein the constraints comprise a limit, imposed by the provider, on at least one of a bandwidth capacity limit, a latency constraint, or a throughput limit (a storage provider limit the customer's bandwidth making it difficult to quickly transfer the entire volume of data, a bandwidth limit result in throttling simultaneous connections by the customer as well as produce high error rates for the customer's data, para. 0012) in order to ensure that each of the customers have access to their data when desire as taught by Kramer (para. 0001);
Therefore, based on Bread in view of Kramer, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Kramer to the medium of Beard in order to ensure that each of the customers have access to their data when desire as taught by Kramer (para. 0001).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Beard et al. (WO 2015/031540 A1), hereinafter referred to as Beard, in view of Kramer et al. (US 2017/0046199 A1), hereinafter referred to as Kramer, further in view of Prahlad et al. (US 2019/0179805 A1), hereinafter referred to as Prahlad, and furthermore in view of Polak et al. (US 2021/0374072 A1), hereinafter referred to as Polak.
With respect to claim 6, Beard teaches The method of claim 5, further comprising:
providing the combined request to the second networked data storage server and/or the first networked data storage server (handling requests from individual clients for file system objects of the source file system; in handling requests, the one or more processors identify a file handle specified in a given request from one of the plurality of clients, and retrieve, from the source file system, a set of metadata associated with the specified file handle, para. 0019).
Beard in view of Kramer does not explicitly teach
caching a multipart request from the client device;
However, Prahlad teaches
caching a multipart request from the client device (the callback layer 1750 traps commands to the cache 1644, where that command identifies certain blocks on a disk for access or modifications, and writes to the data structure the changed blocks, para. 0264) in order to improve data transfers as taught by Prahlad (para. 0065);
Therefore, based on Bread in view of Kramer, and further in view of Prahlad, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Prahlad to the method of Beard in view of Kramer in order to improve data transfers as taught by Prahlad (para. 0065).
Bread in view of Kramer, and further in view of Prahlad does not explicitly teach
caching if the first protocol provides for multipart request and the second protocol and/or the third protocol does not; and
assembling a plurality of data parts from the multipart request into a single request to form a combined request; and
providing the combined request.
However, Polak teaches
caching if the first protocol provides for multipart request and the second protocol and/or the third protocol does not (the access request formatted according to a protocol associated with a first data store; in the access request, an operation name accompanied by one or more attributes of the requested operation, para. 0028; the access request translated into a different format by the compatibility layer, thereby producing a translated access request; the different format represent a format expected by a second data store that stores the one or more records identified in the access request; the second data store associated with a different protocol that dictates how access requests are formatted, para. 0029); and
assembling a plurality of data parts from the multipart request into a single request to form a combined request (the access request formatted according to a protocol associated with a first data store; in the access request, an operation name accompanied by one or more attributes of the requested operation, para. 0028; the access request translated into a different format by the compatibility layer, thereby producing a translated access request; the different format represent a format expected by a second data store that stores the one or more records identified in the access request; the second data store associated with a different protocol that dictates how access requests are formatted, para. 0029); and
providing the combined request (the access request formatted according to a protocol associated with a first data store; in the access request, an operation name accompanied by one or more attributes of the requested operation, para. 0028; the access request translated into a different format by the compatibility layer, thereby producing a translated access request; the different format represent a format expected by a second data store that stores the one or more records identified in the access request; the second data store associated with a different protocol that dictates how access requests are formatted, para. 0029) in order to facilitate migration from a first data store to a second data store without the need to change the program code of client applications or client libraries that use the protocol of the first data store as taught by Polak (para. 0013).
Therefore, based on Bread in view of Kramer, further in view of Prahlad, and furthermore in view of Polak, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Polak to the method of Beard in view of Bread in view of Kramer, and further in view of Prahlad in order to facilitate migration from a first data store to a second data store without the need to change the program code of client applications or client libraries that use the protocol of the first data store as taught by Polak (para. 0013).
Claims 10-11 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Beard et al. (WO 2015/031540 A1), hereinafter referred to as Beard, in view of Kramer et al. (US 2017/0046199 A1), hereinafter referred to as Kramer, and further in view of Prahlad et al. (US 2019/0179805 A1), hereinafter referred to as Prahlad.
With respect to claim 10, Beard in view of Kramer teaches The method of claim 8 as described above,
Beard in view of Prahlad does not explicitly teach further comprising interacting with a plurality of source networked data storage servers to obtain client data.
However, Prahlad teaches further comprising interacting with a plurality of source networked data storage servers to obtain client data (presents clients 130 and other system components with a unified name space, even if the system is storing data on multiple cloud storage sites 115, para. 0112) in order to improve data transfers as taught by Prahlad (para. 0065).
Therefore, based on Bread in view of Kramer, and further in view of Prahlad, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Prahlad to the method of Beard in view of Kramer in order to improve data transfers as taught by Prahlad (para. 0065).
With respect to claim 11, Beard in view of Kramer teaches The method of claim 8 as described above,
Beard in view of Kramer does not explicitly teach further comprising interacting with a plurality of target networked data storage servers to migrate client data.
However, Prahlad teaches further comprising interacting with a plurality of target networked data storage servers to migrate client data (a cloud storage submodule may obviate the need for complex scripting or the addition of disparate cloud gateway appliances to write data to multiple cloud storage site targets, para. 0112) in order to improve data transfers as taught by Prahlad (para. 0065).
Therefore, based on Bread in view of Kramer, and further in view of Prahlad, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Prahlad to the method of Beard in view of Kramer in order to improve data transfers as taught by Prahlad (para. 0065).
With respect to claim 13, Beard in view of Kramer teaches The method of claim 8 as described above,
Beard in view of Kramer does not explicitly teach wherein the first protocol comprises first encryption steps, the second protocol comprises second encryption steps, and the first encryption steps are distinct from the second encryption steps, the method further comprising:
using the first encryption steps to decrypt the first data object as received from the source networked data storage server; and
using the second encryption steps to encrypt the first data object prior to sending to the target networked data storage server.
However, Prahlad teaches wherein the first protocol comprises first encryption steps, the second protocol comprises second encryption steps (when a system migrates or copies data to secondary storage, including secondary cloud storage, the system encrypt the data before or after a secondary copy or archival copy is created, para. 0373; user protect data starting from the source with in-stream encryption, and then extend encryption to data “at-rest”, para. 0393), and the first encryption steps are distinct from the second encryption steps (when a system migrates or copies data to secondary storage, including secondary cloud storage, the system encrypt the data before or after a secondary copy or archival copy is created, para. 0373; user protect data starting from the source with in-stream encryption, and then extend encryption to data “at-rest”, para. 0393), the method further comprising:
using the first encryption steps to decrypt the first data object as received from the source networked data storage server (a cloud storage site API permit storing encrypted data belonging to a client on a cloud storage site, together with an encrypted version of the encryption key that was used to encrypt the encrypted data; a password would be required from the client in order to decrypt the encrypted version, para. 0114); and
using the second encryption steps to encrypt the first data object prior to sending to the target networked data storage server (when a system migrates or copies data to secondary storage, including secondary cloud storage, the system encrypt the data before or after a secondary copy or archival copy is created, para. 0373;) in order to enhance the “at-rest” security of files stored within a cloud storage site 115A-N, by reducing the risk of unauthorized access to the files' content as taught by Prahlad (para. 0373).
Therefore, based on Bread in view of Kramer, and further in view of Prahlad, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Prahlad to the method of Beard in view of Kramer in order to enhance the “at-rest” security of files stored within a cloud storage site 115A-N, by reducing the risk of unauthorized access to the files' content as taught by Prahlad (para. 0373).
With respect to claim 14, Beard in view of Kramer teaches The method of claim 8 as described above,
Beard in view of Kramer does not explicitly teach further comprising:
selecting the source networked data storage server from among a plurality of source networked data storage servers; and
selecting the target networked data storage server from among a plurality of target networked data storage servers, wherein a selected target networked data storage server is selected based on data security requirements.
However, Prahlad teaches further comprising:
selecting the source networked data storage server from among a plurality of source networked data storage servers (the selection of cloud storage sites on the basis of actual performance, a storage manager 105, secondary storage computing devices 165 and/or other system components may track, log and/or analyze the performance achieved by cloud storage sites, para. 0068); and
selecting the target networked data storage server from among a plurality of target networked data storage servers, wherein a selected target networked data storage server is selected based on data security requirements (the deduplication module 299 restrict the lookup to those cloud storage sites 115 that would satisfy storage policy parameters applicable to each block, such as class of storage used for the object such as data security associated with a particular cloud storage site, para. 0180) in order to improve data transfers as taught by Prahlad (para. 0065).
Therefore, based on Bread in view of Kramer, and further in view of Prahlad, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Prahlad to the method of Beard in view of Kramer in order to improve data transfers as taught by Prahlad (para. 0065).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Beard et al. (WO 2015/031540 A1), hereinafter referred to as Beard, in view of Kramer et al. (US 2017/0046199 A1), hereinafter referred to as Kramer, further in view of Prahlad et al. (US 2019/0179805 A1), hereinafter referred to as Prahlad, and furthermore in view of Balasubramanian et al. (US 2018/0191599 A1), hereinafter referred to as Balasubramanian.
With respect to claim 15, Beard in view of Kramer, and further in view of Prahlad teaches The method of claim 14 as described above,
Beard in view of Kramer, and further in view of Prahlad does not explicitly teach wherein the data security requirements include jurisdictional data handling requirements.
However, Balasubramanian teaches wherein the data security requirements include jurisdictional data handling requirements (capturing domain-related requirements, such as security requirements, compliance requirements, and jurisdictional requirements, para. 0055) in order to determine the effectiveness of enterprise cloud migration as taught by Balasubramanian (para. 0108).
Therefore, based on Beard in view of Kramer, further in view of Prahlad, and furthermore in view of Balasubramanian, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Balasubramanian to the method of Beard in view of Kramer, and further in view of Prahlad in order to determine the effectiveness of enterprise cloud migration as taught by Balasubramanian (para. 0108).
Response to Arguments
Applicant’s arguments with respect to claims 1-16 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO HONG NGUYEN whose telephone number is (571)272-2666. The examiner can normally be reached on Monday-Friday 8AM-4:30PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joon H. Hwang can be reached on (571)272-40364036. 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.
/H.H.N/Examiner, Art Unit 2447
October 8, 2026
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
