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 .
DETAILED ACTION
This office action is in response to amendment/reconsideration filed 7/22/2025, the amendment/reconsideration has been considered. Claims 1-11 are pending for examination.
Response to Arguments
Applicant's arguments are fully considered but are not convincing due to the following reasons:
Issue 1: Applicant argues with respect to the 112 rejections that the amended limitations overcome the current rejection.
sExaminer respectfully disagrees. See Examiner’s response in the rejection section below corresponding to the amended limitations.
Issue 2: Applicant’s arguments regarding the 102 rejection are moot in light of the new ground of rejections set forth below.
Claim Rejections - 35 USC § 112
3. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
4. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
5. Claims 1-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
a) Claim 1 recites “a first compute server including a client that is an application program container.”
First of all, it is unclear how a server itself includes a client that is an application program container. For example, what is the server that serves the client that is an application program container, and what is the client that the server serves, and/or how the client and server are the same entity. Applicant is required to clarify. For the sake of the examination, Examiner interprets any computing entity.
Secondly, claim 1 recites “a first compute server including a client that is an application program container, wherein the first computer server…configures a first volume by bundling together…and provides the first volume to the client.” The relationship between the server and the client that is an application program container cannot be definitely determined, because it is unclear how the server including the client that is an application program container provides the first volume to itself. Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship. Claims 2-11 are similarly rejected.
b) Claim 1 recites “a plurality of the lead local volumes provided” wherein “the lead local volumes provided” lacks sufficient antecedent basis. The preceding limitation merely recites “a lead local volume”. It is unclear what exactly “the lead local volumes provided” refer to. Applicant is required to clarify. For the sake of the examination, Examiner assumes any lead volume(s). Claims 2-11 are similarly rejected.
c) Claim 2 recites “wherein the first compute server is a server including an environment with a container execution base, wherein the client operates on the container execution base”. First of all, it is unclear what is considered a server including an environment. Secondly, it is unclear what is considered an environment with a container execution base. The relationship between the server and the container execution base cannot be definitely determined. The relationship between the client and the server is also unclear in light of the recitation wherein the client operates on the container execution base “with an environment included by the server”. It is also unclear how a server and a client operates and/or contain on the same execution base. Applicant is required to clarify. For the sake of the examination, Examiner assumes any relationship(s) and that the server and client can operate and/or contain on any execute base(s). Claim 3 is similarly rejected.
Claim Rejections - 35 USC § 103
6. 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 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.
7. 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.
8. 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.
9. Claims 1-11 are rejected under 35 U.S.C. 103 as being unpatentable over Degwekar et al (US 2023/0111859) in view of Mertes et al (US 2022/0334725).
As to claim 1, Degwekar discloses a storage system, comprising:
a plurality of storage servers that includes a storage device and a controller that processes data
inputted to and outputted from the storage device, the plurality of storage servers providing a lead local volume for inputting and outputting data to and from the storage device (see 112 rejection and Examiner’s interpretation therein. See figure 1, wherein one Storage Array Controller 18 (i.e., a controller) and its connected three Storage Disks (i.e., storage device) in combination the connected Storage Server can be considered a storage server, wherein two sets of Storage Array Controller 18 and the corresponding Storage Disks and Storage Server constitute two storage servers); and
a first compute server including a client that is an application program container, wherein the first compute server manages a free capacity of the plurality of storage servers (see 112 rejection and Examiner’s interpretation therein. See Figure 1, “Storage Management Application 12” together with Client HIS constitute a first compute server including a client. It is to be noted that any application program executable can be considered an application program container), individually provisions a storage capacity to each of the plurality of storage servers on a basis of the free capacity to provide the lead local volume, wherein the first compute server determines which storage server and which capacity are to be used to create the lead local volume from the free capacity of each storage server, and sends an instruction to each storage server to create the lead local volume having the capacity thus instructed, and configures a first volume on the basis of a plurality of the lead local volumes provided, and provides the first volume to the client (see 112 rejection and Examiner’s interpretation therein. See Figure 1; [0020], “A storage management application 12 executing on a client information handling system 10 provides a tool for storage resource organization, such definitions of storage pools 24 and storage groups 28… to provide automated placement of storage volumes 31 at storage drives 22 configured as disc arrays under the management of a storage controller 18 and storage server 16. For example, when an end user requests placement of an application storage volume, placement role modules 30 execute to seek to optimize storage capacity optimization of the storage resources while maintaining idempotency. Placement of the storage volume may seek to automatically meet constraints for a variety of criteria, such as class of service, available capacity, available load at a storage array and other factors. Storage management application defines an Ansible role, such as with a text editor, that distributes to storage asset processing resources for execution as a set of playbooks interfaced with other Ansible modules. By making storage volume placement primarily based on available storage capacity and percentage of storage utilization across multiple storage arrays, placement role module 30 balances load across multiple storage arrays and thereby improves storage utilization while reducing the risk that a provisioning request fails due to an improper storage array selection. The storage volume placement may be completely automated to place and provision the storage volume in response to a request at a storage drive or storage resource pool in response to the request, such as by provisioning the storage volume on the persistent storage of a drive and reporting completion in response to the request.”).
Degwekar, however, does not expressly disclose, or that the first volume is configured by bundling together the plurality of lead local volumes provided, wherein the first volume is a scale-out volume.
Mertes discloses that a first volume configured by bundling together a plurality of lead local volumes provided, wherein the first volume is a scale-out volume ([0450], “As depicted in FIG. 14, the storage system 1412 stores two volumes 1430, 1432. For example, those volumes 1430, 1432 may have been originally provisioned by the storage orchestration service on the storage system 1412. However, it will be appreciated that any storage system supporting the pool 1410 of storage resources can host the volumes 1430, 1432. In this example, volumes 1430, 1432 belong to a placement group 1434. In some examples, the placement group 1434 belong to a particular tenant space, which can span multiple storage systems. Volumes in a placement group may be aggregated based on specific policies assigned to those volumes”; [0150], “additional storage resources can be added through the use of a scale-out model, or through some combination…In a scale-out model, however, additional storage nodes may be added to a cluster of storage nodes, where such storage nodes can include additional processing resources, additional networking resources, and so on”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Degwekar with Mertes. The suggestion/motivation of the combination would have been to provide additional resources ([0150).
As to claim 5, see similar rejection to claim 1.
As to claim 2, Degwekar discloses the storage system according to claim 1, wherein the first compute server is a server including an environment with an execution base, wherein the client operates on the execution base, and a program operating on the execution base is used to perform management of the free capacity, storage capacity provisioning, and provision of the first volume (see citation in rejection to claim 1, e.g., figure 1 and [0020]), but does not expressly disclose that the execution base is a container execution base. Mertes discloses a concept for a server or a client to have an environment of or operate on a container execution base ([0157; [0197]]).
Before the effective fil8ing date of the inventio, it would have been obvious for an ordinary skilled in the art to combine Degwekar with Mertes. The suggestion/motivation would have been to utilize containerized environment (Mertes, [0157; [0197]).
As to claim 3, Degwekar-Mertes discloses the storage system according to claim 2, further comprising a second compute server which includes a client, wherein at least one of the plurality of storage servers provides the lead local volume to each of the first compute server and the second compute server (Mertes, Figure 3C; Figure 3E).
As to claim 4, Degwekar-Mertes discloses the storage system according to claim 1, wherein, in a case where the storage capacity of the first volume that is the scale-out volume is increased, the first compute server refers to the free capacity of the plurality of storage servers and determines a storage server to which an increased storage capacity is to be provisioned, wherein the storage server to which the increased storage capacity is provisioned increases the storage capacity provided as the storage capacity of the first volume (this limitation is conditioned on the condition “in a case where the storage capacity of the first volume is increased” which does not necessarily occur therefore is not given patentable weight. Alternatively, see citation in rejection to claim 1, e.g., Degwekar, [0020], wherein the volume is provision according to available storage capacity, implying an increased storage provisioned to a volume in a case of increased storage capacity [and decreased storage provisioned to a volume in a case of decreased storage capacity, and see Mertes, [0150]].
As to claim 6, Degwekar-Mertes discloses the storage system according to claim 1, wherein the first compute server includes a volume provisioning plugin container that:
communicates with a storage management server to acquire storage node capacity management information; references free capacity of each storage server from the storage node capacity management information to determine whether a scale-out volume can be created; and determines used capacity for each storage server when the scale-out volume can be created (Mertes, [0464], e.g., “the host 1422 sends a discovery request message 1640 to a network address (e.g., an IP address) configured on the host 1422 for discovering storage available to that host. For example, the storage available to the host 1422 can be associated with a tenant space mapped to a host account. The discovery request message 1640 is received by a discovery service of the storage orchestration service 1408….The discovery request message 1640 includes credentials for the host 1422 and a request for available storage system targets”; see [0431], “Container Orchestration Service”; [0516]; [0519]; [0536]-[0538]. See citation in rejection to claim 1 regarding scale-out volume determination).
As to claim 7, Degwekar-Mertes discloses the storage system according to claim 6, wherein:
the volume provisioning plugin container notifies each storage server of their determined used capacity and requests creation of a lead local volume having that capacity; each storage server creates their respective lead local volume in response to the request (Degwekar, see citation in rejection to claim 1. See also [0006], “automatically places application volumes in a selected resource out of available storage resources based on various criteria, such as class of service, available capacity and available load on the storage resource”, wherein notifying to create the requested amount of volume to be created is implied. See Mertes, [0431], “Container Orchestration Service”; [0516]; [0519]; [0536]-[0538]); and
a block storage driver container bundles together the plurality of created lead local volumes to form the first volume as a scale-out volume (Mertes, see citation in rejection to claim 1).
As to claim 8, Degwekar-Mertes discloses the storage system according to claim 1, wherein:
a volume provisioning plugin is prepared on a container execution base; the volume provisioning plugin acquires and holds free capacity and connection destination information of each storage server from a storage server management program; and the volume provisioning plugin references the free capacity of the storage servers to determine which storage server capacity to use (Mertes, [0464], e.g., “the host 1422 sends a discovery request message 1640 to a network address (e.g., an IP address) configured on the host 1422 for discovering storage available to that host. For example, the storage available to the host 1422 can be associated with a tenant space mapped to a host account. The discovery request message 1640 is received by a discovery service of the storage orchestration service 1408….The discovery request message 1640 includes credentials for the host 1422 and a request for available storage system targets”; [0431], “Container Orchestration Service such as Kubernetes”; [0516]; [0519]; [0536]-[0538]).
As to claim 9, Degwekar-Mertes discloses the storage system according to claim 1, wherein:
a volume provisioning plugin determines which storage server and which capacity are to be used to create lead local volumes from the free capacity of each storage server (Degwekar, see citation in rejection to claim 1 and citation in rejection to claim 7; Mertes, see citation in rejection to claims 7 and 8);
the volume provisioning plugin sends instructions to each storage server; each storage server creates a lead local volume having the instructed capacity (Degwekar, see citation in rejection to claim 1 and claim 7); and
the used capacity of each storage server is determined from a compute server side (Mertes, see citation in rejection to claims 7-8, the requested amount of storage).
As to claim 10, Degwekar-Mertes discloses the storage system according to claim 1, wherein:
a block storage driver container operating on a container execution base connects to the created lead local volumes of the plurality of storage servers (Mertes, see citation in rejection to claims 1 and 8);
the block storage driver container uses a logical volume management program to create a volume bundling together nodes (Mertes, see citation in rejection to claim 1); and
an application program container uses the bundled volume as a scale-out volume, enabling use of a large-capacity scale-out volume from the container execution base (Mertes, see citation in rejection to claim 1).
As to claim 11, Degwekar-Mertes discloses the storage system according to claim 1, wherein the first compute server includes a volume provisioning plugin container that:
communicates with a storage management server to acquire storage node capacity management information; references free capacity of each storage server from the storage node capacity management information to determine whether a scale-out volume can be created; and determines used capacity for each storage server when the scale-out volume can be created (see similar rejection to claim 8), wherein:
the volume provisioning plugin container notifies each storage server of their determined used capacity and requests creation of a lead local volume having that capacity; each storage server creates their respective lead local volume in response to the request; a block storage driver container bundles together the plurality of created lead local volumes to form the first volume as a scale-out volume (Mertes, see similar rejection to claim 7);
the volume provisioning plugin acquires and holds free capacity and connection destination information of each storage server from a storage server management program; and the volume provisioning plugin references the free capacity of the storage servers to determine which storage server capacity to use; the volume provisioning plugin determines which storage server and which capacity are to be used to create lead local volumes from the free capacity of each storage server (see similar rejection to claim 8);
the volume provisioning plugin sends instructions to each storage server; each storage server creates a lead local volume having the instructed capacity; the used capacity of each storage server is determined from a compute server side (see similar rejection to claim 9);
the block storage driver container operating on a container execution base connects to the created lead local volumes of the plurality of storage servers; the block storage driver container uses a logical volume management program to create a volume bundling together nodes; and an application program container uses the bundled volume as a scale-out volume, enabling use of a large-capacity scale-out volume from the container execution base (see similar rejection to claim 10).
Conclusion
10. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
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, Umar Cheema can be reached at 571-270-3037. 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.
/HUA FAN/ Primary Examiner, Art Unit 2458