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 .
PROSECUTION REOPENED After Appeal Brief
In view of the Appeal Brief filed on 8/10/2023, PROSECUTION IS HEREBY REOPENED. A new ground of rejection is set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/BORIS GORNEY/Supervisory Patent Examiner, Art Unit 2154
Response to Arguments
Applicant's arguments filed 11/12/2025 have been fully considered but they are not persuasive.
Claims 1, 10 and 16
Applicant states (pp. 9) that Cohen combined with Joshi does not teach “adding a plurality of request records associating metadata in the repository with request types of the I/O requests for which the metadata in the repository was previously returned, wherein a request type identifies a specific command request for the metadata, and wherein the request type and the metadata are indicated in separate fields of the request records;” Examiner respectfully disagrees.
Joshi teaches a multi-level non-volatile cache (i.e., repository) for I/O requests (Joshi: [0002]), capturing (i.e., adding) request information from storage clients (Joshi: [0164]). Each cache entry (i.e., request record) identifies (i.e., associates) context of a prior request (i.e., previously returned) cached (i.e., stored) for potential later use, including (i.e., indicating) both identifier of the requested file (i.e., metadata) and the operation (i.e., command) performed (i.e., request type). File operations include open, read, copy, delete, create, truncate, modify, write etc. (Joshi: [0235]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s requested metadata together with Joshi’s operation performed as separate fields in the same cache entry, such that cache hit can be further conditioned on match of the operation performed.
Applicant further states that the intended use of cache entries in Joshi is to determine whether a I/O request is cacheable, which is different from the claimed use of request records to determine metadata in the repository for a request type. Examiner respectfully disagrees, since Joshi teaches the claimed request records at least for the special case when an I/O request is determined to be cacheable.
Applicant states (pp. 10) that Chaudhry does not teach “in response to determining that the accessing the requested metadata from the catalog has failed, determining a request record of the plurality of request records indicating a request type of the received I/O request; and returning, to the received I/O request, the metadata in the repository that is indicated in the determined request record for the request type of the received I/O request, wherein the requested metadata is returned from the repository if not accessible through the catalog.” Examiner respectfully disagrees.
Chaudhry teaches distributed catalog processing, data caching, and indexing. A local cache (i.e., repository) stores a local catalog containing portions of file blocks copied from a storage server (i.e., catalog), together with properties such as copy creation timestamps. The local cache is kept in two-way sync with the storage server, by propagating changes between local and remote catalogs (Chaudhry: [0009]). Chaudhry provides (i.e., returns) offline access to the local cache even when it loses connection (i.e., not accessible) to the remote server, or when the remote server goes down (i.e., fails) temporarily (Chaudhry: [0120]-[0121]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Chaudhry to Cohen and Joshi. One having ordinary skill in the art would have found motivation to utilize the local cache of Joshi as the local catalog of Chaudhry to provide cached access for improved performance in Cohen, in addition to backup access when the remote catalog fails in Chaudhry.
In summary, the cited prior art of record combined teaches the following workflow:
Receive I/O request for metadata in catalog;
Retrieve the requested metadata from repository;
If found, return retrieved metadata from repository;
If not found, retrieve requested metadata from catalog;
If successful:
Cache retrieved metadata in repository, together with request properties;
Return retrieved metadata from catalog;
If failed, retrieve requested metadata from backup.
Steps (i) followed by (iv)-(vi) forms a special case representing the claimed workflow, where the repository serves as both cache and backup.
Claims 3, 12 and 18
Applicant states (pp. 11) that the intended use of indicator in Joshi is to determine whether an I/O request is cacheable, which is different from claim element “indication field” used to determine when to return metadata from the repository after failure of the same I/O request from the catalog. Examiner respectfully disagrees.
Cohen and Chaudhry do not disclose claim element “indication field”; however, Joshi teaches cache (i.e., repository) policy with an indicator (i.e., indication field) (Joshi: [0252]) to identify cacheable I/O requests using selection criteria configured for a user, storage client, cache level or the like (Joshi: [0171]). In other words, cacheable I/O requests that are failed by the catalog are redirected to the repository for service.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen and Chaudhry. One having ordinary skill in the art would have found motivation to incorporate Joshi’s selective caching in the local catalog of Chaudhry serving as the cache of Cohen, to improve failure tolerance at least for cacheable I/O requests.
Claims 4, 13 and 19
Applicant states (pp. 12) that the cited prior art of record combined does not teach claim 4. Examiner respectfully disagrees.
Cohen and Joshi teach claim 1. Upon receiving an I/O request for metadata, Cohen accesses the cache (i.e., repository) first to determine if there is a cache hit – a cache entry (i.e., request record) matching both Cohen’s requested metadata and Joshi’s performed operation (i.e., request type) (Joshi: [0235]). If so, the cache is accessed to retrieve the metadata (3:24-45). In other words, two cache entries can be for the same performed operation but on requested metadata of different datasets, leading to potentially different caching decisions for the two corresponding I/O requests.
Claims 6 and 14
Applicant states (pp. 14) that Cohen combined with Joshi does not teach claim 6. Examiner respectfully disagrees.
Joshi teaches a multi-level non-volatile cache (i.e., repository) for I/O requests (Joshi: [0002]), capturing metadata of various types and/or granularity from storage clients (Joshi: [0164]). The multi-level cache may comprise an object-level cache for object data within a storage client, OS, or other storage system or subsystem; and/or an application-level cache for a particular application or storage client (Joshi: [0169]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s requested metadata together with Joshi’s operation performed and cache granularity (i.e., object-level vs. application-level) as separate fields in the same cache entry, such that cache hit can be further conditioned on match of the operation and cache granularity performed.
Claim 7
Applicant states (pp. 16) that Cohen combined with Joshi does not teach claim 7. Examiner respectfully disagrees.
Each cache entry in Joshi captures metadata of a prior I/O request, including (i.e., associating) identifier of the file requested, the file operation performed (i.e., request type) (Joshi: [0235]), the storage client (i.e., application) sending (i.e., submitting) the request, and so on (Joshi: [0236]). In other words, two cache entries can be by different applications for different copies (i.e., instances) of the same metadata, leading to potentially different caching decisions for the two corresponding requests.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s requested metadata together with Joshi’s operation performed and the requesting application as separate fields in the same cache entry, such that cache hit can be further conditioned on match of the operation performed and the requesting application.
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, 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.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Cohen et al. US patent 9,286,303 [herein “Cohen”], and further in view of Joshi et al. US patent application 2012/0210068 [herein “Joshi”].
Claim 16 recites “A method for processing Input/Output (I/O) requests for metadata on data sets in storage, comprising: in response to returning metadata, in a catalog storing metadata, to I/O requests, performing: storing the returned metadata in a repository; and”.
Cohen teaches metadata as data about data describing the state of system storing the contents of user data (i.e., data sets), such as properties, characteristics and attributes (1:10-16). Cohen provides cache (i.e., repository) on user nodes to locally store temporal copies of metadata returned from a catalog (2:33-37).
Cohen does not disclose limitation “adding a plurality of request records associating metadata in the repository with request types of the I/O requests for which the metadata in the repository was previously returned, wherein a request type identifies a specific command request for the metadata, and wherein the request type and the metadata are indicated in separate fields of the request records;”
According to the instant specification (fig. 3; [0025]-[0026]), the repository maintains a collection of request records, each of which stores properties associated with an I/O request including request type, dataset, subsystem, and application. I/O requests for the same metadata having different request type, dataset, application or subsystem are maintained in separate request records.
However, Joshi teaches a multi-level non-volatile cache (i.e., repository) for I/O requests (Joshi: [0002]), capturing (i.e., adding) request information from storage clients (Joshi: [0164]). Each cache entry (i.e., request record) identifies (i.e., associates) metadata of a prior request (i.e., previously returned) cached (i.e., stored) for potential later use, including (i.e., indicating) both identifier of the requested file (i.e., metadata) and the operation (i.e., command) performed (i.e., request type). File operations include open, read, copy, delete, create, truncate, modify, write etc. (Joshi: [0235]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s metadata together with operation performed as separate fields in the same cache entry in Joshi, so that cache hit can be further conditioned on match of the operation performed.
Claim 16 further recites “accessing the catalog to retrieve requested metadata for a received I/O request; returning the requested metadata for the received I/O request from the catalog in response to accessing the requested metadata from the catalog;”
Upon receiving an I/O request for metadata, Cohen accesses cache first to determine if there is a cache hit matching the I/O request to a cache entry containing the same metadata requested and operation performed. If not, the catalog is accessed to retrieve and return the requested metadata (3:24-45).
Claim 16 further recites “in response to determining that the accessing the requested metadata from the catalog has failed, determining a request record of the plurality of request records indicating a request type of the received I/O request; and returning, to the received I/O request, the metadata in the repository that is indicated in the determined request record for the request type of the received I/O request, wherein the requested metadata is returned from the repository if not accessible through the catalog.”
This is a contingent limitation that is not limiting according to the BRI of method claims, per MPEP §2111.04(II).
Claims 1-15 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen as applied to claim 16 above, in view of Joshi, and further in view of Chaudhry et al. US patent application 2011/0225141 [herein “Chaudhry”].
Claim 1 recites “A computer program product for processing Input/Output (I/O) requests for metadata on data sets in storage, wherein the computer program product comprises a computer readable storage medium having computer readable program instructions executed by a processor to perform operations, the operations comprising: in response to returning metadata, in a catalog storing metadata, to I/O requests, performing: storing the returned metadata in a repository; and”.
Cohen teaches metadata as data about data describing the state of system storing the contents of user data (i.e., data sets), such as properties, characteristics and attributes (1:10-16). Cohen provides cache (i.e., repository) on user nodes to locally store temporal copies of metadata returned from a catalog (2:33-37).
Cohen does not disclose limitation “adding a plurality of request records associating metadata in the repository with request types of the I/O requests for which the metadata in the repository was previously returned, wherein a request type identifies a specific command request for the metadata, and wherein the request type and the metadata are indicated in separate fields of the request records;”
According to the instant specification (fig. 3; [0025]-[0026]), the repository maintains a collection of request records, each of which stores properties associated with an I/O request including request type, dataset, subsystem, and application. I/O requests for the same metadata having different request type, dataset, application or subsystem are maintained in separate request records.
However, Joshi teaches a multi-level non-volatile cache (i.e., repository) for I/O requests (Joshi: [0002]), capturing (i.e., adding) request information from storage clients (Joshi: [0164]). Each cache entry (i.e., request record) identifies (i.e., associates) metadata of a prior request (i.e., previously returned) cached (i.e., stored) for potential later use, including (i.e., indicating) both identifier of the requested file (i.e., metadata) and the operation (i.e., command) performed (i.e., request type). File operations include open, read, copy, delete, create, truncate, modify, write etc. (Joshi: [0235]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s metadata together with operation performed as separate fields in the same cache entry in Joshi, so that cache hit can be further conditioned on match of the operation performed.
Claim 1 further recites “accessing the catalog to retrieve requested metadata for a received I/O request; returning the requested metadata for the received I/O request from the catalog in response to accessing the requested metadata from the catalog;”
Upon receiving an I/O request for metadata, Cohen accesses cache first to determine if there is a cache hit matching the I/O request to a cache entry containing the same metadata requested and operation performed. If not, the catalog is accessed to retrieve and return the requested metadata (3:24-45).
Cohen does not disclose limitation “in response to determining that the accessing the requested metadata from the catalog has failed, determining a request record of the plurality of request records indicating a request type of the received I/O request; and returning, to the received I/O request, the metadata in the repository that is indicated in the determined request record for the request type of the received I/O request, wherein the requested metadata is returned from the repository if not accessible through the catalog.”
However, Chaudhry teaches distributed catalog processing, data caching, and indexing. A local cache (i.e., repository) stores a local catalog containing portions of file blocks copied from a storage server (i.e., catalog), together with properties such as copy creation timestamps. The local cache is kept in two-way sync with the storage server, by propagating changes between local and remote catalogs (Chaudhry: [0009]). Chaudhry provides (i.e., returns) offline access to the local cache even if it loses connection (i.e., not accessible) to the remote server, or if the remote server goes down (i.e., fails) temporarily (Chaudhry: [0120]-[0121]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Chaudhry to Cohen and Joshi. One having ordinary skill in the art would have found motivation to utilize the local cache of Chaudhry to provide cached access for improved performance in Cohen, in addition to backup access when the catalog fails.
Claims 10 is analogous to claim 1, and are similarly rejected.
Claim 2 recites “The computer program product of claim 1, wherein the operations further comprise: forwarding an intercepted request to the catalog of metadata; and receiving failure for the intercepted request forwarded to the catalog.”
Upon receiving (i.e., intercepting) an I/O request for metadata, Cohen accesses cache first to determine if there is a cache hit. If not, the catalog is accessed (i.e., forwarded) to retrieve and return the requested metadata (3:24-45).
Cohen and Chaudhry teach claim 1, where a local cache stores a local catalog containing portions of file blocks copied from a storage server (i.e., catalog), together with properties such as copy creation timestamps. The local cache is kept in two-way sync with the storage server, by propagating changes between local and remote catalogs (Chaudhry: [0009]). Chaudhry provides offline access to the local cache even if it loses connection to the remote server, or if the remote server goes down (i.e., fails) temporarily (Chaudhry: [0120]-[0121]).
Claims 11 and 17 are analogous to claim 2, and are similarly rejected.
Claim 3 recites “The computer program product of claim 1, wherein the operations further comprise: indicating to retrieve metadata from the repository in an indication field; and submitting the received I/O request to retrieve the requested metadata from a catalog of metadata, wherein the returning the requested metadata for the received I/O request from the repository is performed in response to a failure of the submitting the received I/O request to the catalog and in response to the indication field indicating to retrieve metadata from the repository.”
Upon receiving an I/O request for metadata, Cohen accesses cache first to determine if there is a cache hit matching the I/O request to a cache entry containing the same metadata requested and operation performed. If not, the catalog is accessed (i.e., submitted) to retrieve and return the requested metadata (3:24-45).
Cohen and Chaudhry teach claim 1, where a local cache (i.e., repository) stores a local catalog containing portions of file blocks copied from a storage server (i.e., catalog), together with properties such as copy creation timestamps. The local cache is kept in two-way sync with the storage server, by propagating changes between local and remote catalogs (Chaudhry: [0009]). Chaudhry provides (i.e., returns) offline access to the local cache even if it loses connection to the remote server, or if the remote server goes down (i.e., fails) temporarily (Chaudhry: [0120]-[0121]).
Cohen and Chaudhry do not disclose claim element “indication field”; however, Joshi teaches cache (i.e., repository) policy with an indicator (i.e., indication field) (Joshi: [0252]) to identify cacheable I/O requests using selection criteria configured for a user, storage client, cache level or the like (Joshi: [0171]). In other words, cacheable I/O requests that are failed by the catalog are redirected to the repository for service.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen and Chaudhry. One having ordinary skill in the art would have found motivation to incorporate Joshi’s selective caching in the local catalog of Chaudhry serving as the cache of Cohen, to improve failure tolerance at least for cacheable I/O requests.
Claims 12 and 18 are analogous to claim 3, and are similarly rejected.
Claim 4 recites “The computer program product of claim 1, wherein the request records further associate metadata in the repository with data sets indicated in the I/O requests, wherein the request records associate different metadata with a same request type and with different data sets for submitted request types.”
Cohen and Joshi teach claim 1. Upon receiving an I/O request for metadata, Cohen accesses the cache (i.e., repository) first to determine if there is a cache hit – a cache entry (i.e., request record) matching both Cohen’s requested metadata and Joshi’s performed operation (i.e., request type) (Joshi: [0235]). If so, the cache is accessed to retrieve the metadata (3:24-45). In other words, two cache entries can be for the same performed operation but on requested metadata of different datasets, leading to potentially different caching decisions for the two corresponding I/O requests.
Claims 13 and 19 are analogous to claim 4, and are similarly rejected.
Claim 6 recites “The computer program product of claim 1, wherein the request records associate metadata returned for a request type with a data set and a subsystem having the data set, wherein the data set exists in multiple subsystems, and wherein the repository includes metadata for the request type and for the subsystems including the data set, wherein the operations further comprise: intercepting an update to metadata in a catalog of metadata for the data set in multiple subsystems; determining request records in the repository that include the metadata for the request type associated with the data set and the subsystems including the data set; and updating the metadata for the data set in the subsystems in the determined request records in the repository.”
Cohen and Joshi teach claim 1. Upon receiving (i.e., intercepting) an I/O request to update metadata, Cohen accesses the cache (i.e., repository) first to determine if there is a cache hit – a cache entry (i.e., request record) matching both Cohen’s requested metadata and Joshi’s performed operation (i.e., update) (Joshi: [0235]). If so, the cache is accessed to update the metadata (3:24-45). In other words, two cache entries can be for different copies (i.e., in different subsystems) of the same metadata, leading to potentially different caching decisions for the two corresponding requests.
Cohen does not teach claim element “subsystem”; however, Joshi teaches a multi-level non-volatile cache (i.e., repository) for I/O requests (Joshi: [0002]), capturing metadata of various types and/or granularity from storage clients (Joshi: [0164]). The multi-level cache may comprise an object-level cache for object data within a storage client, OS, or other storage system or subsystem; and/or an application-level cache for a particular application or storage client (Joshi: [0169]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s requested metadata together with Joshi’s operation performed and cache granularity (i.e., object-level vs. application-level) as separate fields in the same cache entry, such that cache hit can be further conditioned on match of the operation and cache granularity performed.
Claim 14 is analogous to claim 6, and is similarly rejected.
Claim 7 recites “The computer program product of claim 1, wherein the repository includes multiple request records associating instances of metadata with request types of requests for which the metadata was returned from a catalog of metadata and applications that submitted the requests, wherein the request records associate different instances of metadata with a same request type and different applications that submitted the same request type.”
Cohen and Joshi teach claim 1. Upon receiving an I/O request for metadata, Cohen accesses the cache (i.e., repository) first to determine if there is a cache hit – a cache entry (i.e., request record) matching both Cohen’s requested metadata and Joshi’s performed operation (i.e., request type) (Joshi: [0235]). If so, the cache is accessed to retrieve the metadata (3:24-45).
Cohen does not disclose claim element “applications that submitted the requests”; however, each cache entry in Joshi captures metadata of a prior I/O request, including (i.e., associating) identifier of the file requested, the file operation performed (i.e., request type) (Joshi: [0235]), the storage client (i.e., application) sending (i.e., submitting) the I/O request, and so on (Joshi: [0236]). In other words, two cache entries can be by different applications for different copies (i.e., instances) of the same metadata, leading to potentially different caching decisions for the two corresponding requests.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to cache Cohen’s requested metadata together with Joshi’s operation performed and the requesting application as separate fields in the same cache entry, such that cache hit can be further conditioned on match of the operation performed and the requesting application.
Claim 8 recites “The computer program product of claim 1, wherein request records indicate for a plurality of applications whether requests for metadata are to be intercepted to determine whether to retrieve the metadata from the repository, further comprising: intercepting, from an application, a request to access metadata from the catalog in response to determining that at least one application indicated in the intercepted request is indicated in a request record.”
Cohen and Joshi teach claim 1. Upon receiving an I/O request for metadata, Cohen accesses the cache (i.e., repository) first to determine if there is a cache hit – a cache entry (i.e., request record) matching both Cohen’s requested metadata and Joshi’s performed operation (Joshi: [0235]). If so, the cache is accessed to retrieve the metadata (3:24-45).
Cohen does not disclose this claim; however, Joshi teaches a cache (i.e., repository) policy to identify (i.e., intercept) cacheable I/O requests using selection criteria configured for a user, storage client, cache level or the like (Joshi: [0171]). Each cache entry captures metadata of a prior I/O request, including identifier of the file requested, the file operation performed, and the request context (Joshi: [0235]), such as the storage client (i.e., application) sending the I/O request (Joshi: [0236]).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Joshi to Cohen. One having ordinary skill in the art would have found motivation to incorporate Joshi’s cache policy to enable selective caching in Cohen.
Claim 9 recites “The computer program product of claim 1, wherein the operations further comprise: intercepting a change to a catalog of metadata that would change metadata in the catalog; determining whether the intercepted change to the catalog is for metadata stored in the repository for a request; writing the changed metadata to the repository to update the metadata stored for the request in the repository in response to determining that the intercepted change is for metadata stored in the repository; and writing the changed metadata to the catalog.”
Cohen and Joshi teach claim 1. Upon receiving (i.e., intercepting) an I/O request to change metadata, Cohen accesses the cache (i.e., repository) first to determine if there is a cache hit – a cache entry matching both Cohen’s requested metadata and Joshi’s performed operation (i.e., change) (Joshi: [0235]). If so, the cache is accessed to change the metadata (3:24-45).
Cohen uses a variety of cache management techniques. A cache can be a write-through cache, where changes to metadata are automatically synchronized (i.e., written) between the one or more cache entries and the catalog (3:24-45).
Claims 15 and 20 are analogous to claim 9, and are similarly rejected.
Allowable Subject Matter
Claim 5 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The closest prior art found is Cohen, which uses a variety of cache management techniques. A cache can be a write-through cache, where updates to metadata are automatically synchronized between the one or more cache entries and the catalog (3:24-45). An example of metadata update is spawning (i.e., extending to) a new user node (i.e., second volume) from an existing one (i.e., first volume) (3:44-59). However, Cohen does not teach extending datasets from the existing node to the new node.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. For example, Choubey et al. US patent application 2017/0185619 teaches request caching based on requestor identity.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHELLY X. QIAN whose telephone number is (408)918-7599. The examiner can normally be reached Monday - Friday 8-5 PT.
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, Boris Gorney can be reached at (571)270-5626. 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.
/BORIS GORNEY/Supervisory Patent Examiner, Art Unit 2154
/SHELLY X QIAN/Examiner, Art Unit 2154