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 .
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 5, 11, 14, 16, and 17 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hillberg et al. (Pub. No. US 2004/0230576).
Claim 1:
Hillberg et al. disclose a storage system comprising:
a memory storing instructions [fig. 1; pars. 0014-0015 – System Memory]; and
a processor communicatively coupled to the memory and configured to execute the instructions to [fig. 1; pars. 0014-0015 – Processing Unit]:
receive a request from a client of the storage system to read or write data in the storage system, the request defined in accordance with a storage access protocol and indicating a data transformation function to be applied to the data as part of fulfilling the request [figs. 3-5; pars. 0031-0038 – An access request is received. Transform information is associated with the data. (“FIG. 5 is a logical flow diagram generally illustrating a process for accessing transformed data within a compound file, in accordance with the invention. The process 500 begins at a starting block 501 where an application has requested an access to data within in stream of a multi-part file. The transform information 210 has already been specified for the stream.”)];
initiate, based on the request, execution of the data transformation function to transform the data into transformed data [figs. 3-5; pars. 0031-0038 – The transform is performed. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)]; and
use the transformed data to fulfill the request [figs. 3-5; pars. 0031-0038 – The data access is performed. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)].
Claim 5 (as applied to claim 1 above):
Hillberg et al. disclose,
wherein the request comprises a read request or a write request to a file system [figs. 3-5; pars. 0031-0038 – The data access is a read or write operation. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)].
Claim 11 (as applied to claim 1 above):
Hillberg et al. disclose,
wherein the execution of the data transformation function to transform the data into the transformed data comprises sending a compute task and the data to a compute environment configured to transform the data into the transformed data and return the transformed data [figs. 3-5; pars. 0031-0038 – An access request is received. The request and associated transformation is performed. (“FIG. 5 is a logical flow diagram generally illustrating a process for accessing transformed data within a compound file, in accordance with the invention. The process 500 begins at a starting block 501 where an application has requested an access to data within in stream of a multi-part file. The transform information 210 has already been specified for the stream.”)].
Claim 14:
Hillberg et al. disclose a computer-implemented method comprising:
receiving, by a component of a storage system, a request from a client of the storage system to read or write data in the storage system, the request defined in accordance with a storage access protocol and indicating a data transformation function to be applied to the data as part of fulfilling the request [figs. 3-5; pars. 0031-0038 – An access request is received. Transform information is associated with the data. (“FIG. 5 is a logical flow diagram generally illustrating a process for accessing transformed data within a compound file, in accordance with the invention. The process 500 begins at a starting block 501 where an application has requested an access to data within in stream of a multi-part file. The transform information 210 has already been specified for the stream.”)];
initiating, by the component of the storage system and based on the request, execution of the data transformation function to transform the data into transformed data [figs. 3-5; pars. 0031-0038 – The transform is performed. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)]; and
using, by the component of the storage system, the transformed data to fulfill the request [figs. 3-5; pars. 0031-0038 – The data access is performed. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)].
Claim 16 (as applied to claim 14 above):
Hillberg et al. disclose, wherein:
the request comprises a read request [figs. 3-5; pars. 0031-0038 – The data access is a read or write operation. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)]; and
using the transformed data to fulfill the request comprises providing the transformed data to the client [figs. 3-5; pars. 0031-0038 – The data access is a read or write operation. For a read, read data is returned. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)].
Claim 17 (as applied to claim 14 above):
Hillberg et al. disclose, wherein:
the request comprises a write request [figs. 3-5; pars. 0031-0038 – The data access is a read or write operation. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)]; and
using the transformed data to fulfill the request comprises writing the transformed data to storage [figs. 3-5; pars. 0031-0038 – The data access is a read or write operation. For a write, data is written. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)].
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.
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.
Claim(s) 2 and 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 1 above, and further in view of Mahesh (Pub. No. US 2022/0172325).
Claim 2 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the request includes an extension to the storage access protocol, the extension indicating the data transformation function to be applied to the data as part of fulfilling the request.
In the same field of endeavor, Mahesh discloses,
wherein the request includes an extension to the storage access protocol, the extension indicating the data transformation function to be applied to the data as part of fulfilling the request [par. 0056 – “In one example, plugin 258 includes an API read command (e.g., a GET call) with extensions to indicate one or more preprocessing functions to be applied on retrieved data prior to returning it to the processor node.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include using extensions to indicate one or more preprocessing (transformation) functions, as taught by Mahesh, in order to improve performance by including the functions in the command rather than having to perform a lookup of the functions.
Claim 4 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the request comprises a GET request, a PUT request, or a POST request for an object data store.
In the same field of endeavor, Mahesh discloses,
wherein the request comprises a GET request, a PUT request, or a POST request for an object data store [par. 0056 – “In one example, operators 256 can add metadata to a store command to cause external storage to store one or more data objects to support subsequent preprocessing and offload with a data access request. In one example, operators 256 represent data pipeline operations exposed as a service that plugin 258 understands. In one example, plugin 258 includes an API store command (e.g., a PUT call) with extensions to indicate that a data object should be stored in a way to support preprocessing functions later during retrieval. In one example, plugin 258 includes an API read command (e.g., a GET call) with extensions to indicate one or more preprocessing functions to be applied on retrieved data prior to returning it to the processor node.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include object storage, as taught by Mahesh, in order to provide cost-effectiveness.
Claim(s) 3 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claims 1 and 14 above, respectively, and further in view of Barthe et al. (Pub. No. US 2014/0351494).
Claim 3 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the request carries a header indicating the data transformation function to be applied to the data as part of fulfilling the request.
In the same field of endeavor, Barthe et al. disclose,
wherein the request carries a header indicating the data transformation function to be applied to the data as part of fulfilling the request [par. 0032 – “This received write command may thus include a header containing different parameters such as the type of command (its instruction code INS in the case of a command according to the ISO 7816-4 standard), and the data to be written.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include using a header to indicate one or more parameters (transformation functions), as taught by Mahesh, in order to improve performance by including the functions in the command rather than having to perform a lookup of the functions.
Claim 15 (as applied to claim 14 above):
Claim 15, directed to a computer-implement ed method, is rejected for the same reasons set forth in the rejection of claim 3 above.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 1 above, and further in view of Buniatyan (Pub. No. US 2022/0121880).
Claim 6 (as applied to claim 1 above):
Hillberg et al. disclose,
wherein the data transformation function comprises a Lambda function.
In the same field of endeavor, Buniatyan discloses,
wherein the data transformation function comprises a Lambda function [pars. 0028, 0071 – “The data transformation module 110 receives a plurality of transformation functions concatenated together as a dependency directed acyclic graph to transform the plurality of large-scale datasets from one form into another. The plurality of transformation functions are user-defined, serverless lambda functions which apply arbitrary computation to a single sample or a subsection of a sample of a tensor of the set of tensors or a large-scale dataset.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include a lambda function, as taught by Buniatyan, in order to provide flexibility by providing functions that run without needing to provision servers.
Claim(s) 7, 8, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 1 and 14 above, respectively, and further in view of Patil et al. (Pub. No. US 2021/0005330).
Claim 7 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the data transformation function is provided by a containerized application.
In the same field of endeavor, Patil et al. disclose,
wherein the data transformation function is provided by a containerized application [pars. 0017, 0035, 0048 – “The data pipelines can be constructed using computing primitives and building blocks, such as VMs, containers, processes, or any combination thereof. In some examples, the data pipelines may be constructed using a group of containers (e.g., a pod) that each perform various functions within the data pipeline (e.g., subscriber, data processor, publisher, connectors that transform data for consumption by another container within the application or pod, etc.) to consume, transform, and produce messages or data. In some examples, the definition of stages of a constructed data pipeline application may be described using a user interface or REST API, with data ingestion and movement handled by connector components built into the data pipeline. Thus, data may be passed between containers of a data pipeline using API calls.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include containerized applications, as taught by Patil et al., in order to provide portability, efficiency, and agility.
Claim 8 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose, wherein:
the storage system comprises a plurality of storage nodes; and
the data transformation function is implemented as a containerized application configured to run in a container runtime environment deployed on the plurality of storage nodes.
In the same field of endeavor, Patil et al. disclose,
the storage system comprises a plurality of storage nodes [pars. 0017, 0035-0039, 0048 – “The storage 280 may be configured to store edge stack data 281, such as software images, binaries and libraries, metadata, etc., to be used by the edge system 210 to load and execute the edge stack. In some examples, the edge stack data 281 includes instructions that when executed by a process or the edge system 210, causes the edge system to perform functions described herein. The storage may include local storage (solid state drives (SSDs), hard disk drives (HDDs), flash or other non-volatile memory, volatile memory, or any combination thereof), cloud storage, networked storage, or any combination thereof.”]; and
the data transformation function is implemented as a containerized application configured to run in a container runtime environment deployed on the plurality of storage nodes [pars. 0017, 0035-0039, 0048 – “The data pipelines can be constructed using computing primitives and building blocks, such as VMs, containers, processes, or any combination thereof. In some examples, the data pipelines may be constructed using a group of containers (e.g., a pod) that each perform various functions within the data pipeline (e.g., subscriber, data processor, publisher, connectors that transform data for consumption by another container within the application or pod, etc.) to consume, transform, and produce messages or data. In some examples, the definition of stages of a constructed data pipeline application may be described using a user interface or REST API, with data ingestion and movement handled by connector components built into the data pipeline. Thus, data may be passed between containers of a data pipeline using API calls.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include containerized applications, as taught by Patil et al., in order to provide portability, efficiency, and agility.
Claim 18 (as applied to claim 14 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the data transformation function comprises a containerized application configured to run in a container runtime environment implemented on a plurality of storage devices in the storage system.
In the same field of endeavor, Patil et al., disclose,
wherein the data transformation function comprises a containerized application configured to run in a container runtime environment implemented on a plurality of storage devices in the storage system [pars. 0017, 0035, 0048 – “The data pipelines can be constructed using computing primitives and building blocks, such as VMs, containers, processes, or any combination thereof. In some examples, the data pipelines may be constructed using a group of containers (e.g., a pod) that each perform various functions within the data pipeline (e.g., subscriber, data processor, publisher, connectors that transform data for consumption by another container within the application or pod, etc.) to consume, transform, and produce messages or data. In some examples, the definition of stages of a constructed data pipeline application may be described using a user interface or REST API, with data ingestion and movement handled by connector components built into the data pipeline. Thus, data may be passed between containers of a data pipeline using API calls.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include containerized applications, as taught by Patil et al., in order to provide portability, efficiency, and agility.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) in view of Patil et al. (Pub. No. US 2021/0005330) as applied to claim 8 above, and further in view of Gupta et al. (Pub. No. US 2020/0319798).
Claim 9 (as applied to claim 8 above):
Hillberg et al. and Patil et al. disclose all the limitations above but do not specifically disclose,
wherein the plurality of storage nodes are implemented on a plurality of blades of a storage array.
In the same field of endeavor, Gupta et al. disclose,
wherein the plurality of storage nodes are implemented on a plurality of blades of a storage array [fig. 2E].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Hillberg et al. and Patil et al. to include blades, as taught by Gupta et al., in order to allow for easy replacement and hot-swapability.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 1 above, and further in view of Esmaeilzadeh et al. (Pub. No. US 2023/0020163).
Claim 10 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the processor is within a storage device containing a physical storage resource to be used to fulfill the request.
In the same field of endeavor, Esmaeilzadeh discloses,
wherein the processor is within a storage device containing a physical storage resource to be used to fulfill the request [pars. 0004, 0049 – “Some aspects include a system, comprising: a computing device, comprising: computational storage or computational memory, the computational storage or computational memory having a processor; a downstream data processor that is different from the processor of the computational storage or computational memory;”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include computational storage, as taught by Esmaeilzadeh, in order to reduce latency and bandwidth usage.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 11 above, and further in view of Wilson et al. (Pub. No. US 2018/0144269).
Claim 12 (as applied to claim 11 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the compute environment executes an artificial intelligence classifier model applied to the data to determine and return a classification label for the data.
In the same field of endeavor, Wilson et al. disclose,
wherein the compute environment executes an artificial intelligence classifier model applied to the data to determine and return a classification label for the data [par. 0039 – “Some embodiments of the present invention use machine-learning algorithms to train classifiers, in particular supervised learning. Supervised learning is a branch of machine learning involving the task of inferring a function from labeled training data. The training data comprises a set of training examples. In supervised learning, each training example may comprise an object (e.g. a content item) and a label (which, for example, may classify the content item into one or more categories). A supervised learning algorithm can analyze the training data and produce an inferred function (e.g. a classifier model), which can then be used to predict a label for (or otherwise classify) an unlabeled content item.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include labeling unlabeled data, as taught by Wilson et al., in order to add context for data in supervised learning and allow the algorithm to learn the relationship between inputs and outputs.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 1 above, and further in view of Miller et al. (Pub. No. US 2013/0232190).
Claim 13 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the data transformation function comprises a filter applied to filter the data.
In the same field of endeavor, Miller et al. disclose,
wherein the data transformation function comprises a filter applied to filter the data [claim 1 – “responsive to the received read request, execute a transformation function defined by the determined blob type based on the criteria to create transformed data, wherein executing the transformation function comprises one or more of the following: reducing one or more dimensions of graphical data in the target blob, applying a data reduction algorithm to data in the target blob, applying a format conversion to data in the target blob, and filtering data in the target blob; and provide the transformed data to the client”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include filtering data, as taught by Miller et al., in order to allow unwanted data to be removed.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) in view of Mahesh (Pub. No. US 2022/0172325) and Kulkarni et al. (Pub. No. US 2007/0136396).
Claim 20:
Hillberg et al. disclose a non-transitory computer readable storage medium comprising computer instructions for:
receiving, at a storage system, a request from a client of the storage system to read or write data in the storage system, the request defined in accordance with a storage access protocol and including a data identifier for the data [figs. 3-5; pars. 0031-0038 – An access request is received. The request identifies data within a stream of a multi-part file. Transform information is associated with the data. (“FIG. 5 is a logical flow diagram generally illustrating a process for accessing transformed data within a compound file, in accordance with the invention. The process 500 begins at a starting block 501 where an application has requested an access to data within in stream of a multi-part file. The transform information 210 has already been specified for the stream.”)];
initiating, based on the indication, execution of the data transformation function to transform the data into transformed data [figs. 3-5; pars. 0031-0038 – The transform is performed. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)]; and
using the transformed data to fulfill the request [figs. 3-5; pars. 0031-0038 – The data access is performed. (“At block 510, the identified transform is applied. When applying the transform, the transform instance data is used to properly transform the data. If the access is a write, the transform (encode) is applied. If the access is a read, the inverse transform (decode) is applied.”)].
However, Hillberg et al. do not specifically disclose,
detecting, in the request, an indication of a data transformation function to be applied to the data as part of fulfilling the request;
In the same field of endeavor, Mahesh discloses,
detecting, in the request, an indication of a data transformation function to be applied to the data as part of fulfilling the request [par. 0056 – “In one example, plugin 258 includes an API read command (e.g., a GET call) with extensions to indicate one or more preprocessing functions to be applied on retrieved data prior to returning it to the processor node.”];
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Hillberg et al. to include using extensions to indicate one or more preprocessing (transformation) functions, as taught by Mahesh, in order to improve performance by including the functions in the command rather than having to perform a lookup of the functions.
Hillberg et al. and Mahesh disclose all the limitations above but do not specifically disclose,
the data identifier uses a naming convention indicating a data transformation function
In the same field of endeavor, Kulkarni et al. disclose,
the data identifier uses a naming convention indicating a data transformation function [fig. 6; par. 0068 – “The transformation module 132 may identify the transformation definition based on a naming convention or name match between the source data graph 104 and the transformation definition 134.”]
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Hillberg et al. and Mahesh to include a naming convention, as taught by Kulkarni et al., in order to improve performance by allowing the transformation function to be identified by the naming convention rather than having to perform a lookup.
Claim(s) 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hillberg et al. (Pub. No. US 2004/0230576) as applied to claim 1 and 14 above, respectively, and further in view of Pawlowski et al. (Pub. No. US 2004/0030668).
Claim 21 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the storage access protocol comprises a file storage access protocol.
In the same field of endeavor, Pawlowski et al. disclose,
wherein the storage access protocol comprises a file storage access protocol [par. 0020 – “The present invention is directed to a multi-protocol storage appliance that serves both file and block protocol access to information stored on storage devices in an integrated manner.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Hillberg et al. to include multi-protocols, as taught by Pawlowski et al., in order to increase flexibility.
Claim 22 (as applied to claim 1 above):
Hillberg et al. disclose all the limitations above but do not specifically disclose,
wherein the storage access protocol comprises a block storage access protocol.
In the same field of endeavor, Pawlowski et al. disclose,
wherein the storage access protocol comprises a block storage access protocol [par. 0020 – “The present invention is directed to a multi-protocol storage appliance that serves both file and block protocol access to information stored on storage devices in an integrated manner.”].
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Hillberg et al. to include multi-protocols, as taught by Pawlowski et al., in order to increase flexibility.
Allowable Subject Matter
Claim 19 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.
Response to Arguments
Applicant's arguments filed November 13, 2025 have been fully considered but they are not persuasive.
35 U.S.C. 101
The rejection has been removed in light of the amendments to the claim.
35 U.S.C. 102
Applicant argues that Hillberg fails to disclose “receive a request from a client of the storage system to read or write data in the storage system, the request defined in accordance with a storage access protocol and indicating a data transformation function to be applied to the data as part of fulfilling the request”
Examiner submits that in Hillberg, the request for data indicates the associated transformation to be performed according to whether the stream is a member of a data space. The transformation to be applied is identified based on the request. The claim does not require that the transformation function be listed within the request.
Applicant’s arguments with respect to amended subject matter have been addressed in the new grounds of rejection presented above.
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 LARRY T MACKALL whose telephone number is (571)270-1172. The examiner can normally be reached Monday - Friday, 9am-5pm.
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 G Bragdon can be reached at (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 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.
LARRY T. MACKALL
Primary Examiner
Art Unit 2131
6 February 2026
/LARRY T MACKALL/Primary Examiner, Art Unit 2139