DETAILED ACTION
Claims 1-20 were restricted. Claims 1-15 were elected. Claims 16-20 were withdrawn.
Claims 1, 9 are amended. Claim 4 is canceled. Claims 1-3, 5-15 are pending.
Priority: September 13, 2023(FP)
Assignee: Samsung
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/23/2026 has been entered.
Claim Rejections - 35 USC § 112
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.
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.
Claim(s) 1-15 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.
1.Amended Claim 1 is rejected for reciting a limitation with antecedent basis issues.
Claim 1 recites, ‘send the asynchronous event interrupt to the host device in response to the determination that the workload is greater than the workload threshold….’. Here ‘the workload’ lacks antecedent basis.
Note: In the Remarks, the Applicant does not mention the relevant specification paragraph(s) that recite the amendment(s).
1.Amended Claim 1 is rejected for reciting a limitation that is unclear, incorrect, vague and indefinite.
Amended Claim 1 recites, ‘a storage controller configured to
operate at least one virtual machine to control the non-volatile memory device’.
The limitation is merely copied from the spec, but the spec fails to provide any details as to its meaning, operation, or physical configuration.
It is well known that a storage controller is a piece of hardware. It is also well known that a VM is a software layer that requires a hypervisor or VMM to function. Accordingly, it is unclear whether the storage controller itself is running a hypervisor to operate the VM, or if the controller is simply acting as a passive node that receives commands from a VM running on a separate host.
Fig. 9 of the spec shows VM manager 2120, like a hypervisor, running in a separate host and coupled to the storage controller. But it is unclear how the storage controller instantiates/creates the VM in order to operate or execute it.
Since the claim and spec only state the result (operate a VM), without disclosing the specific algorithm, hardware bindings, or hypervisor configurations needed to interface with the VM, create the VM and achieve the ‘operation’, it is unclear how the storage controller operates the VM.
Since the claim is overly broad to cover configurations where either the host's VM manager or the storage controller ‘operates’ the VM, the metes and bounds of the limitation cannot be determined. Hence claim 1 is rejected for reciting a limitation that is unclear, vague and indefinite.
2.Amended claim 1 is rejected for reciting a limitation that is unclear, incorrect and indefinite.
Amended claim 1 recites, ‘store the workload threshold for the at least one virtual machine’, ‘monitor read commands or write commands received from the host device to count and update a workload of the storage device’.
The spec does not disclose these limitations. Para-0007 of the spec recites, ‘monitoring a workload of each of the plurality of virtual machines by counting read commands or write commands sent to the storage device’.
As shown, the spec limits the monitoring to the workload of individual VMs. But the claim expands the monitoring to the broader workload of the entire storage device.
In other words the claim recites that the ‘workload of the storage device’ is an aggregate of the VMs. But the spec does not teach how to update the aggregate device workload, only how to track individual VMs and determine a VM-level workload by isolating and counting commands for each VM.
Because the spec fails to provide the boundaries or a definition for what constitutes a 'workload of the storage device', the scope of the limitation is unclear.
Furthermore, claim 1 recites receiving a r/w command by the storage controller from the host and storing the host-provided workload threshold for the VM. But by updating aggregate ‘workload of the storage device’, for the VM, the claim recites an unclear scope. Since the language of the amended limitation combines features from different paragraphs (mix-n-match) of the spec, the claim fails to clearly describe how the controller tracks the workload of the VM and sends the ASE to the host. Hence claim 1 is rejected.
3.Amended claim 1 is rejected for reciting a limitation that is unclear, incorrect and indefinite.
Amended Claim 1 recites, ‘determine whether to send the asynchronous event interrupt based on the workload of the storage device being greater than the workload threshold’.
The spec does not disclose this limitation. As mentioned above, the spec does not teach determining ‘workload of the storage device’.
Because the spec only teaches how to quantify workloads by individual VM, reciting ‘workload of the storage device’ recites an unclear scope.
Furthermore since ‘workload of the storage device’ is the aggregate device workload, it will always exceed the workload of the VM. In other words, stating the condition is always true turns the conditional statement into a nullity, leading to uncertainty of the actual trigger for the ASE and an uncertain scope. Hence the limitation is rejected.
4.Amended claim 9 is rejected for reciting a limitation that is unclear, inconsistent and indefinite.
Amended claim 9 recites, ‘sending an asynchronous event interrupt….to the host device without receiving a request from the host device’. The spec does not recite this limitation.
Claim 9 is based on Para-0007 of the spec and Para-0007 recites, ‘sending an asynchronous event interrupt….regardless of whether a request is received from the host device’.
Because Para-0007 of the spec says the interrupt can be sent with or without a request, it is unclear if the storage device that sends an interrupt with a request from the host falls inside or outside the scope of the claim.
Given the contradiction in terminology, the boundaries of the claim are unclear. Hence claim 9 is rejected. For examination, the spec is followed.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
1.Amended Claims 1, 9 are rejected for reciting limitations that are unsupported by the spec.
Claim 9 recites, ‘a storage device running plurality of virtual machines to support multi-tenant services’.
Though the spec recites the same claim language, the spec does not provide any text or figures describing the details of how the storage controller in the storage device instantiates/creates the VMs in the storage device so that the VMs can ‘run’, aka execute.
A one-line recitation in the spec does not fulfill the written description requirement.
The spec fails to describe the operational steps or a flow chart where an instantiation module or hypervisor logic first configures the memory, disk, and resources (instantiation) before the storage controller starts running the VMs.
Though running VMs is well known in the art, the spec does not describe how the storage controller, independently, has the software and hardware capability to instantiate the VMs and run them.
The spec discloses that the storage controller monitors r/w commands for each of the plurality of VMs. But the spec fails to describe how the storage controller identifies each target VM for a received read or write command.
Though the spec casually recites the term ‘multi-tenant services’ on VMs, the spec fails to describe a cloud architecture where multiple users (‘tenants’) with shared VMs are configured so that the data and workloads of the tenants remain securely isolated from one another.
The spec discloses the end result (multi-tenant services on VMs running on the storage device/SSD) but fails to describe how these VMs are created, provisioned, or linked to the SSD (e.g., the specific hypervisor, mapping algorithms, or firmware/software interactions). In other words, the disclosure only claims a result rather than the operative details to achieve it.
The lack of disclosure describing how the VMs are created and run on the storage device, demonstrates that the applicant was not in possession of the specific technology that allows the storage controller to independently create the VMs and run them, at the time of filing. The lack of disclosure also demonstrates that the following limitations, ‘monitoring….’ and ‘sending….threshold’, fail to convey possession.
Hence the claim 9 limitation, ‘a storage device running plurality of virtual machines to support multi-tenant services’, recites a scope unsupported by the spec and is rejected for the same. Claim 1 recites, ‘a storage controller configured to operate at least one virtual machine….’, has the same issue and is also rejected.
2.Amended Claim 9 is rejected for reciting a limitation that is unsupported by the spec.
Claim 9 recites, ‘monitoring, by a storage controller of the storage device, a workload of each of the plurality of virtual machines on the storage device….’. The limitation aligns with the spec.
Now, Fig. 9, Para-0092 of the spec recites, ‘the virtual machine manager 2120 may monitor the workload of virtual machines (e.g., VM1, VM2, and VM3) allocated to each user (e.g., User1, User2, User3) on the SSD 2200’.
This shows that the spec discloses two distinct ‘controllers’, the VM manager and storage controller and two execution models. The spec discloses a host-based execution model, where the ‘VM manager’ (like a hypervisor) residing on a separate host monitors the workloads of VMs. The spec also recites a device-level execution model, where the ‘storage controller’ in the storage device monitors the workloads of VMs.
Though the spec discloses the host VM manager performing a monitoring function and the storage controller performing a monitoring function, it leaves a functional gap as to which ‘controller’ actually creates the VMs and runs them. Because the spec does not describe the origin or creation of the VMs and their execution, the spec fails to provide written description support for the full scope of the claims.
Though creating and running VMs is well known in the art, the lack of specific description, algorithm and hardware architecture showing that the storage controller itself creates, runs and controls the VMs, shows that the applicant was not in possession of a storage controller in a storage device to independently create and run VMs, at the time of filing.
Hence claim 9 is rejected for reciting a limitation that is unsupported by the spec.
3.Amended Claims 1, 9 are rejected for reciting a limitation that is unsupported by the spec.
Amended Claim 9 recites, ‘monitoring, by a storage controller of the storage device, a workload of each of the plurality of virtual machines on the storage device by counting read commands or write commands sent to the storage device’.
Claim 9 also recites that the VMs are running in the storage device.
The amended limitation functionally requires a specific mapping or association, .i.e. the controller must know which received read or write command is associated with which VM of the plurality of VMs running on the storage device. But the spec fails to describe how this association is achieved by the storage controller.
While the broad function of monitoring workloads by counting r/w commands is recited, the spec fails to provide any written description of how the controller associates each individual r/w command to one of the specific VMs. Because the spec lacks any disclosure of the structure, algorithm, or method by which the controller makes this association, the spec fails to convey that the inventor possessed the specific mechanism for associating each received r/w command with its respective VM.
Read and write commands and VMs are well-known in the art but how they are analyzed to determine their correspondence with running VMs created, executed and managed by the controller in the storage device, lacks written description support.
Since the controller cannot distinguish which r/w command is associated with which VM, workload determination of each VM and sending the ASE for any VM also fails possession. The claim is broader than the spec and recites a scope unsupported by the spec. Hence claim 9 is rejected. Claim 1 has the same issue.
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.
Claims 1-3, 5, 9-10, 13 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Kanno (20210200442) in view of Lee et al (20200151040) and Antony et al (20160378518).
As per Claim 1, Kanno discloses a storage device (Kanno, [Fig. 1: SSD 3]) configured to receive a read command or a write command from a host device (Kanno, [0061 – In Fig. 1, host interface 11 of SSD 3 receives various commands such as a write command, read command, etc., from host 2]), the storage device comprising:
a non-volatile memory device configured to store data (Kanno, [0038 – In Fig. 1, NAND flash memory 5 includes a memory cell array having a plurality of memory cells arranged in a matrix]; [0053 - Data is read from the physical storage location in NAND flash memory 5 designated by the physical address of interest]);
a storage controller (Kanno, [Fig. 1: controller 4]) configured to:
operate at least one virtual machine to control the non-volatile memory device (Kanno, [0042 – In Fig. 1, controller 4 in SSD 3 includes a virtualization support mechanism for supporting storage management by host 2. The virtualization support mechanism allows a plurality of virtual servers such as the virtual machines/VMs/VSSDs 41,42,43,….47 to share physical resources of SSD 3 and to directly access the physical resources of SSD 3]),
store a workload threshold of the at least one virtual machine (Kanno, [0026 – The controller maintains a threshold value for each of the virtual storage regions/VMs]; [0152 – In Fig. 8, ‘execution time of NAND processing’ field, stores an upper limit value of process execution time of a corresponding VSSD/VM]; [0095 - The execution time of NAND processing is an upper limit value of a write operation/command or a read operation/command of NAND flash memory 5 per unit time]; [0148 – In Fig. 8, VSSD management table 30 includes a plurality of entries corresponding to the VSSDs 51-57 created by the VSSD creation unit 21, thereby implying that VSSD 51 corresponds to a VM]) according to settings received from the host device (Kanno, [0061 – In Fig. 1, host interface 11 of SSD 3 receives the VSSD/VM management command from host 2]),
and send an asynchronous event interrupt to the host device based on the workload threshold (Kanno, [0089 - Controller 4 is able to report/send the measured total amount of written data for each VSSD/VM to host 2]; [0086 - Prevent data of which amount exceeds the total write amount for VSSD#1 designated by host 2 from being written into VSSD#1, thereby implying workload exceeds workload threshold. An end user of the VM which uses the VSSD#1 may request the data center operator to increase the total amount of writable data, thereby implying sending an asynchronous event interrupt to the host based on the workload threshold]),
wherein the storage controller is further configured to,
store the workload threshold (Kanno, [0152 – In Fig. 8, ‘execution time of NAND processing’ field, stores an upper limit value of process execution time of a corresponding VSSD/VM]; [0095 - The execution time of NAND processing is an upper limit value of a write operation/command or a read operation/command of NAND flash memory 5 per unit time]) for the at least one virtual machine (Kanno, [0026 – The controller maintains a threshold value for each of the virtual storage regions/VMs]; [0148 – In Fig. 8, VSSD management table 30 includes a plurality of entries corresponding to the VSSDs 51-57 created by the VSSD creation unit 21, thereby implying that VSSD 51 corresponds to a VM]);
monitor read commands or write commands received from the host device (Kanno, [0061 – In Fig. 1, host interface 11 in storage device/SSD receives various commands like write, read etc. from host 2]) to count (Kanno, [0039 - Because SSDs pack data in pages, the number of write commands sent by host = Total Data Written/Command Transfer Size, i.e. divide the total written data by the host's transfer block size]) and update a workload of the ([See 112(b)]) storage device (Kanno, [0196 – In Fig. 13, when controller 4 of SSD 3 receives a write command from host 2, the controller 4 determines a target VSSD to which write data are to be written based on a VSSD ID included in the write command. The controller 4 writes the write data into the target VSSD via steps S201,S203,S205 and counts an amount of written data via steps S202,S204,S206; Since Fig. 13 is a loop, it suggests that as monitoring continues the workload of the storage device for the VM will be updated]);
Lee discloses,
the storage controller (Lee, [Fig. 1: storage controller 1240]) to monitor read commands or write commands received from the host device (Lee, [0020 – In Fig. 1, storage device 1200 stores/writes or reads data in or from the NVM 1260 in response to an access request of the host 1100]) to count and update a workload ([See 112(b)]) of the storage device (Lee, [Fig. 4: HMB/Host Memory Buffer health table]; [0064 - In Fig. 7, step S310, HMB controller 1243 resident in storage controller 1240 monitors health state information of each the HMB areas according to data attributes of access requests of HMB 1120; Here, the HMB is mapped to the storage device and the monitoring is for write count/WC or read count/RC associated with VM(s) in the storage device. For e.g., when a host write command is received, the controller uses the HMB1 mapping information to determine the VM, updates corresponding HMB region, and updates the write count WC in the HMB health state table row for that identified VM in the storage device. The WC is stored in the HMB health state table 1246 in the controller. Since the spec does not disclose determining the command to VM association mechanism, the citation is a valid interpretation]);
determine whether to send the asynchronous event interrupt (Lee, [0068 - Before critical corruption occurs, the HMB controller 1243 may, in advance, transmit the corruption prediction notification/async event to the host 1100 according to health state monitoring for each area of HMB 1120]) based on the workload threshold of the storage device ([See 112(b)]) being greater than the workload threshold (Lee, [0070 – In Fig. 8, in operation S410, the storage device 1200 checks the write count WC of each HMB area of the HMB 1120. When an HMB area in which the write count WC is greater than the write threshold value TH_wc exists, go to step S430; Here the write count WC is the workload threshold of the storage device]);
send the asynchronous event interrupt to the host device (Lee, [Fig. 1: host 1100]) in response to the determination that the workload ([See 112(b)]) is greater than the workload threshold (Lee, [0070 -In Fig. 8, step S410, WC > TH_wc? Yes, storage controller 1240 transmits a corruption prediction notification to host 1100]) without a request from the host device (Lee, [Fig. 9: Notification Channel 1350, one-way communication from storage device to host, thereby implying no request from host]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the workload and workload threshold of Lee into the virtualization support of Kanno, for the benefit of using a storage controller configured to divide a buffer area allocated from the host memory through the interface into a plurality of buffer areas. The storage device monitors a deterioration state for each of the plurality of buffer areas, and transmits a corruption notification or a corruption prediction notification when a deterioration state exceeds a threshold (Lee, 0007).
Kanno,Lee disclose operating each VM with the controller in the storage device storing VSSD management data of each VM and tracking this data so it knows exactly where to route I/O operations in the NVM device for that VM.
Antony further discloses a storage controller configured to operate at least a VM as follows,
a storage controller (Antony, [Fig. 1: infrastructure platform 154]) configured to operate at least one virtual machine (Antony, [Fig. 1: a VM 172]) to control the non-volatile memory device (Antony, [Fig. 1]; [Fig. 3: SAN 164, storage device 302]; [0037 - Storage policies 308 dictate storage-related characteristics for physical storage device 302 and VM disk file 314/VMDK which is a file that stores information and acts as NVM storage for a VM 172 that container 127 is to use]; [0019 – In Fig. 1, cloud computing system 150 includes infrastructure platform 154 upon which a cloud computing environment 170 is executed. In Fig. 1, infrastructure platform 154 includes hardware resources 160 to provide a virtualization environment 156 that supports the execution/operation of a plurality of VMs 172 across hosts 162]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the infrastructure platform of Antony into the virtualization support of Kanno, Lee for the benefit of the cloud computing system being configured to dynamically provide users of an enterprise with one or more virtual data centers in which a user may provision VMs, deploy multi-tier applications on the VMs, and/or execute workloads (Antony, 0019).
As per Claim 2, the rejection of claim 1 is incorporated, and Kanno discloses,
wherein the workload includes at least one of count information of read/write commands (Kanno, [0173 - The execution-time-of-NAND-processing control unit 24 executes each command of a predetermined number/count of commands in a command group directed to VSSD#n/VM#n]), throughput of read/write operations per unit time (Kanno, [0168 – For VSSD#1, one erasure operation and 98 write operations per 1 cycle, e.g., 1 second, can be executed. Otherwise one erasure operation and 980 read operations per 1 cycle, e.g., 1 second, can be executed]), data usage rate (Kanno, [0175 - The token distribution and recovery processing is carried out to control, with respect to each individual VSSD, the rate of acquiring commands from a plurality of command queues in the memory of host 2]), number of write buffers in use of the storage controller (Kanno, [Fig. 12]), write rate (Kanno, [0102 - Controller 4 controls a rate of execution of commands in a command queue in which commands received from host 2 are stored, for each VSSD/VM]), queue depth, and a write amplification factor (WAF) of the non-volatile memory device (Kanno, [Fig. 12: write buffer#1-VSSD#1….write buffer#n-VSSD#n]).
As per Claim 3, the rejection of claim 1 is incorporated, and Kanno discloses,
wherein the storage controller (Kanno, [Fig. 1: controller 4]) is configured to decode a command received from the host device (Kanno, [0061 – In Fig. 1, host interface 11 receives various commands, such as write command, read command, VSSD/VM management command, UNMAP command etc., from host 2; Since the claim does not define ‘decode a command’, the citation is a valid interpretation]) and store the workload threshold of the at least one virtual machine (Kanno, [0178 – In Fig. 11, step S101, VSSD creation unit 21 creates VSSD 51, i.e., VSSD #1 based on the VSSD management command received first from host 2 and stores a setting parameter, which is designated by the VSSD management command for the VSSD 51, in the VSSD management table 30]; [0152 – In Figs.7-8, in ‘execution time of NAND processing’ field, an upper limit value of process execution time of a corresponding VSSD/VM is stored]; [0026 – The controller maintains a threshold value for each of the virtual storage regions/VMs]).
As per Claim 5, the rejection of claim 1 is incorporated, and Kanno discloses,
wherein the storage controller (Kanno, [Fig. 1: controller 4]) further includes processing circuitry (Kanno, [0060 - The controller 4 includes host interface 11, CPU 12, NAND interface 13, DRAM interface 14]) and at least one memory (Kanno, [Fig. 1: DRAM 6]; [0047 - Controller 4 can function as a flash translation layer/FTL; Since FTL uses DRAM to store the mapping table that translates logical block addresses to physical flash memory addresses, it thereby implies that DRAM 6 is included in controller 4]).
As per Claim 9, Kanno discloses an event reporting method for a storage device (Kanno, [Fig. 1: SSD 3]) running a plurality of virtual machines (Kanno, [0042 – In Fig. 1, controller 4 in SSD 3 includes a virtualization support mechanism for supporting storage management by host 2. The virtualization support mechanism allows a plurality of virtual servers such as the virtual machines 41,42,43,….47 to share physical resources of SSD 3 and to directly access physical resources/NVM of SSD 3]; [Fig. 3]) to support multi-tenant services (Kanno, [0033 - Each of the virtual machines 41,42,43,….47 is able to function as a virtual server configured to provide various services to the corresponding client/user; Since the claim does not define ‘multi-tenant services’, the citation is a valid interpretation]),
the event reporting method (Kanno, [0064 – VSSD management command, parameters allow functions for controlling QoS of each VSSD to be provided to host 2, thereby establishing a event reporting method]) comprising:
setting, by a host device (Kanno, [0061 – In Fig. 1, host interface 11 of SSD 3 receives the VSSD/VM management command from host 2]; [0147 - Fig. 8 shows a VSSD management table 30]), a workload threshold for each of the plurality of virtual machines on the storage device (Kanno, [0026 – The controller maintains a threshold value for each of the virtual storage regions/VMs]; [0152 – In Fig. 8, ‘execution time of NAND processing’ field, stores an upper limit value of process execution time of a corresponding VSSD/VM]; [0095 - The execution time of NAND processing is an upper limit value of a write operation/command or a read operation/command of NAND flash memory 5 per unit time]);
monitoring, by a storage controller of the storage device (Kanno, [Fig. 1: controller 4 of SSD 3]), a workload of each of the plurality of virtual machines ([See 112(a)]) on the storage device (Kanno, [Figs. 3-5]; [0008 – Fig. 3 shows a SSD which includes a virtualization support mechanism]; [0010 – Figs. 4-5 show VSSDs in the SSD for each VM]) by counting read commands or write commands (Kanno, [0039 - Because SSDs pack data in pages, the number of write commands sent by host = Total Data Written/Command Transfer Size, i.e. divide the total written data by the host's transfer block size]) sent to the storage device (Kanno, [0196 – In Fig. 13, when controller 4 of SSD 3 receives a write command from host 2, the controller 4 determines a target VSSD to which write data are to be written based on a VSSD ID included in the write command. The controller 4 writes the write data into the target VSSD via steps S201,S203,S205 and counts an amount of written data via steps S202,S204,S206]);
Lee discloses,
monitoring, by a storage controller of the storage device (Lee, [Fig. 1: storage controller 1240]; [Fig. 1: storage device 1200]), a workload of each of the plurality of virtual machines (Lee, [0035 – Mapping data of the storage device 1200 is stored in HMB1 area 1122 of HMB 1120, thereby implying that VMs are running in the storage device because the controller refers to the L2P mapping data for every r/w command to track its corresponding VM]) on the storage device (Lee, [0026 - The storage device 1200 accesses NVM device 1260 in response to a command CMD from the host 1100]; [0020 – In Fig. 1, storage device 1200 stores or reads data in or from NVM 1260 in response to an access request/read-or-write of host 1100]) by counting read commands or write commands sent to the storage device (Lee, [0064 - In Fig. 7, step S310, HMB controller 1243 resident in storage controller 1240 monitors health state information of each the HMB areas according to data attributes of access requests of HMB 1120; Here, the HMB is mapped to the storage device and the monitoring is for write count/WC or read count/RC associated with VM(s) in the storage device. For e.g., when a host write command is received, the controller uses the HMB1 mapping information to determine the VM, updates corresponding HMB region, and updates the write count WC in the HMB health state table row for that identified VM in the storage device. The WC is stored in the HMB health state table 1246 in the controller. Since the spec does not disclose determining the command to VM association mechanism, the citation is a valid interpretation]);
and sending an asynchronous event interrupt for at least one of the plurality of virtual machines to the host device (Lee, [0068 - Before critical corruption occurs, the HMB controller 1243 may, in advance, transmit the corruption prediction notification/async event to host 1100 according to health state monitoring for each area/VM of HMB 1120]) without receiving a request from the host device (Lee, [Fig. 9: Notification Channel 1350, one-way communication from storage device to host, thereby implying no request from host]) when the at least one of the plurality of virtual machines ([See 112(a)]) exceeds the workload threshold (Lee, [0065 - In Fig. 7, step S320, HMB controller 1243 checks whether at least one HMB area has a write count/WC that exceeds a write threshold value/TH_wc. Or if at least one HMB area has a read count/RC that exceeds a read threshold value/TH_rc. If an HMB area in the controller has RC or WC greater than TH_rc or TH_wc, the asynchronous event interrupt is sent to the host; This implies that since the controller knows how the VMs are mapped in the NVM, the HMB region health information is used to determine the VM whose workload exceeds TH_wc or TH_rc and the ASE is sent for that VM]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the workload and workload threshold of Lee into the virtualization support of Kanno, for the benefit of using a storage controller configured to divide a buffer area allocated from the host memory through the interface into a plurality of buffer areas. The storage device monitors a deterioration state for each of the plurality of buffer areas, and transmits a corruption notification or a corruption prediction notification when a deterioration state exceeds a threshold (Lee, 0007).
Kanno,Lee disclose running VMs with the controller in the storage device storing VSSD management data of each VM and tracking this data so it knows exactly where to route I/O operations in the NVM device for that VM.
Antony further discloses a storage device configured to run VMs as follows,
a storage device (Antony, [Fig. 1: infrastructure platform 154 represents the controller]; [0050 – In Fig. 3, storage policies 308 dictate user-specified characteristics of storage resources, e.g., physical storage device 302, that are to store data for the container in the VM]) running plurality of virtual machines (Antony, [Fig. 1: VMs 172]; [0019 – In Fig. 1, cloud computing system 150 includes infrastructure platform 154 upon which a cloud computing environment 170 is executed. In Fig. 1, infrastructure platform 154 includes hardware resources 160 to provide a virtualization environment 156 that supports the execution/operation of a plurality of VMs 172 across hosts 162]) to support multi-tenant services (Antony, [0020 – In Fig. 1, cloud computing environment 170 may be configured as part of a multi-tenant cloud service with logically isolated virtual computing resources on a shared physical infrastructure]),
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the infrastructure platform of Antony into the virtualization support of Kanno, Lee for the benefit of the cloud computing system being configured to dynamically provide users of an enterprise with one or more virtual data centers in which a user may provision VMs, deploy multi-tier applications on the VMs, and/or execute workloads (Antony, 0019).
As per Claim 10, it is similar to claim 2 and therefore the same rejections are incorporated.
As per Claim 13, the rejection of claim 9 is incorporated, and Kanno, Lee, Antony disclose,
wherein the monitoring of the workload of each of the plurality of virtual machines (Lee, [0023 - HMB 1120 is allocated to allow storage device 1200 to use the host memory 1130 as a buffer. Storage device 1200 divides HMB 1120 into areas/VMs]; [0064 - In Fig. 7, step S310, HMB controller 1243 monitors health state information of each of the HMB areas/VMs according to data attributes with reference to access requests/read or write commands of HMB 1120]), comprises:
storing and updating count values of the read command or the write command for each of the plurality of virtual machines (Lee, [Fig. 4]; [0047 - Health state for each area includes a write count and a read count of each area]; [0042 - The corruption prediction module 1244 continuously monitors an error rate of data read from HMB 1120 or a read count or a write count, and updates a monitoring result in the HMB health state table 1246]);
determining (Lee, [Fig. 7: step S320, RC > TH_rc or RC > TH_wc ?]) whether to send the asynchronous event interrupt (Lee, [0066 – In Fig. 7, if determination step S320 is Yes, then in step S330, HMB controller 1243 transmits a corruption prediction notification associated with the specific HMB area/VM to host 1100]) based on the count values per unit time and the workload thresholds of each of the plurality of virtual machines (Lee, [0065 – In Fig. 7, step S320, HMB controller 1243 checks whether if HMB area has a write count WC that exceeds a write threshold value TH_wc. Or, HMB controller 1243 checks whether at least one HMB area has a read count RC that exceeds a read threshold value TH_rc]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the workload and workload threshold of Lee into the virtualization support of Kanno, Antony for the benefit of using the storage controller of the storage device which monitors deterioration information of a first VM area of the host memory buffer and transmits a corruption prediction notification associated with the first VM area to the host based on a result of the monitoring (Lee, 0005).
Claims 6-7, 11-12 are rejected under AIA 35 U.S.C. 103(a) as being unpatentable over Kanno (20210200442) in view of Lee et al (20200151040), Antony et al (20160378518) and Yun et al (20180039578).
As per Claim 6, the rejection of claim 3 is incorporated, and Kanno, Lee, Antony disclose a read command, a write command and a VSSD management command.
However Yun further discloses,
wherein the command includes at least one of a read command, a write command (Yun, [0057 - In Fig. 3, step S121, host 410 transmits a command and an address to controller 431, thereby implying a read or write command]), and a set feature command for controlling the storage controller (Yun, [0109 – In Fig. 12, step S710, controller 331 receives a set feature command from host 310]; [0116 – In Fig. 15, if a feature identifier is OEh, set feature information includes information about a threshold value, thereby providing information to control the controller]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the set feature command of Yun into the virtualization support of Kanno, Lee, Antony for the benefit of providing monitoring information to the controller (Yun, Para-0116).
As per Claim 7, the rejection of claim 6 is incorporated, and Kanno discloses,
wherein the set feature command (Kanno, [0126 - Fig. 7 shows VSSD management command. Fig. 8 shows VSSD management table; Since the claim does not define ‘set feature command’ or its format, the citation is a valid interpretation]) includes a first field specifying the at least one virtual machine (Kanno, [0149 - In Fig. 8, the ‘VSSD ID’ field is an identifier of a corresponding stored VSSD]), a second field specifying a type of the workload (Kanno, [0076 – When host 2 requests creation of a VSSD for a VM which handles hot data, which is a type of data frequently updated, host 2 also designates a large volume of the total amount of writable data]; [0155 - In Fig. 8, in the ‘total amount of write-requested-data’ field, an upper limit value of a total amount of data capable of being written into a corresponding VSSD by host 2 is stored]), and a third field specifying a value of the workload threshold (Kanno, [0152 - In Fig. 8, in ‘execution time of NAND processing’ field, an upper limit value of process execution time of a corresponding VSSD is stored]).
As per Claim 11, the rejection of claim 9 is incorporated, and Kanno, Lee, Antony disclose that the controller is configured to divide a buffer area allocated from the host memory/HMB into a plurality of buffer areas/VMs.
Yun further discloses,
wherein the setting of the workload threshold (Yun, [Fig. 15]) comprises:
sending, by the host device, the workload threshold of each of the plurality of virtual machines (Yun, [Fig. 4]) to the storage device through a set feature command (Yun, [0109 - In Fig. 12, step S710, controller 331 receives a set feature command from host 310]);
and decoding the set feature command to store the workload threshold of each of the plurality of virtual machines (Yun, [0116 - In Fig. 15, when a feature identifier is OEh, set feature information includes information about a threshold value. This information is used in the operation of Fig. 4 and operation S710 of Fig. 12; In Fig. 4, controller divides the buffer allocated from the host memory/HMB into virtual areas/VMs]) in a non-volatile memory (Yun, [0025 – In Fig. 1, storage device 130 includes controller 131 and a plurality of NAND flash memories, 133a….133d]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the set feature command of Yun into the virtualization support of Kanno, Lee, Antony for the benefit of providing monitoring information to the controller (Yun, Para-0116).
As per Claim 12, it is similar to claim 7 and therefore the same rejections are incorporated.
Claims 8, 14-15 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Kanno (20210200442) in view of Lee et al (20200151040), Antony et al (20160378518) and Kern (20110258621).
As per Claim 8, the rejection of claim 1 is incorporated, and Kanno, Lee, Antony disclose multi-tenant services.
Kern further discloses,
wherein the at least one virtual machine (Kern, [0030 - In deploying the instance of VM 102, the cloud computing environment executes a data processing workload on the instance of the VM. The workload is executed through application 132 installed as a component of the instance of VM 102. The workload is a request/response service provided to cloud clients 119/host by accepting connections through network 100 in order to service requests from users by sending back responses; Here VM 102 is running on cloud computer 110/storage device]) corresponds to a user of a multi-tenant service (Kern, [0018 – A ‘cloud computer’ is a multi-user computer that provides a service, e.g. database access, file transfer, remote access or resources, e.g. file space, over a network]; [0012 - Examples of cloud computing services include SaaS and PaaS. In SaaS, a provider licenses an application to customers for use as a service on demand]),
the workload threshold (Kern, [0029 - Flagging an instance of a VM for autonomic scaling includes storing, in the cloud operating system in association with an identifier of the VM instance, predetermined threshold values of operating characteristics, including threshold values for processor utilization and for memory utilization; Higher utilization leads to higher throughput for a period of time because when a CPU is actively engaged in processing tasks, it's contributing to completing work and thus increasing the overall throughput of the system]) corresponds to an upper limit of throughput per unit time corresponding to a rate plan to which the user subscribes (Kern, [0014 - Utility computing is the practice of charging for cloud services like utilities, by units of time, work, or resources provided. A cloud utility provider can charge cloud clients for providing for a period of time certain quantities of memory, I/O support in units of bytes transferred/throughput, or CPU functions in units of CPU clock cycles utilized]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the autonomic scaling of VMs of Kern into the virtualization support of Kanno, Lee, Antony for the benefit of utilizing scaling as a desirable feature of a cloud computing environment in which the environment gracefully handles varying workloads, either increasing or decreasing (Kern, 0010).
As per Claim 14, it is similar to claim 8 and therefore the same rejections are incorporated.
As per Claim 15, the rejection of claim 14 is incorporated, and Kanno discloses,
proposing, by the host device, a rate plan change to the user (Kanno, [0076 - The data center operator may charge a more expensive VSSD utilization charge, e.g., in the form of an increased rental fee, to an end user who requests a VSSD having a large volume of the total amount of writable data, that is, a VSSD for which a large volume of the total write amount is permitted]) in response to the asynchronous event interrupt (Kanno, [0064 - The VSSD management command includes various parameters for providing a VSSD suitable for storage requirements of an individual user to a VM. These parameters allow functions for controlling QoS of each VSSD to be provided to host 2]).
Kern clarifies,
proposing, by the host device, a rate plan change to the user (Kern, [Fig. 4, step 332]) in response to the asynchronous event interrupt (Kern, [0049 - deploying, in step 332, by the cloud operating system, an additional instance 104 of the VM if a value of an operating characteristic exceeds a first predetermined threshold value]; [0014 - A cloud utility provider/host can charge cloud clients for providing for a period of time certain quantities of memory, I/O support in units of bytes transferred, or CPU functions in units of CPU clock cycles utilized]).
Therefore it would have been obvious to a person of ordinary skill at the time of filing to incorporate the autonomic scaling of VMs of Kern, Lee into the virtualization support of Kanno, Lee, Antony for the benefit of utilizing scaling as a desirable feature of a cloud computing environment in which the environment gracefully handles varying workloads, either increasing or decreasing (Kern, 0010).
Response to Arguments
The Applicant's arguments filed on March 26, 2026 have been fully considered, but they are not persuasive.
Amendments must be supported by the spec.
Applicant argues:‘Applicants have amended claim 1 to recite,…., ‘monitor read commands or write commands received from the host device to count and update a workload of the storage device’. (Rem, Pg. 9)
Response: This argument is incorrect.
The spec does not recite the limitation. It is a potential 112(a).
As mentioned in the 112(b), the spec limits the monitoring to the workload of individual VMs. But the claim expands the monitoring to the broader ‘workload of the entire storage device’.
Para-0048 of the spec recites, ‘the condition checker 1216 compares the workload threshold WL_TH of each virtual machine VM with the count information updated by the command count tracker 1218 from read/write commands’.
Furthermore, claim 1 recites, ‘the storage controller to store the workload threshold for….one virtual machine’, based on the workload threshold WL_TH value received from the host and Para-0006 of the spec recites, ‘monitor read commands or write commands received from the host device to count and update a workload’. Here ‘update a workload’ refers to the workload of the VM not the workload of the entire storage device.
Since the spec does not disclose the boundaries or a definition for ‘workload of the storage device’, all amended limitations that recite the same, in claim 1, being unsupported by the spec, are potential 112(a).
Furthermore since claim 1 recites ‘at least one VM’, or a single-VM storage device and the spec is reliant on a storage device with multiple VMs, claim 1 fails to enable the full scope of the invention. The narrowed scope of claim 1 is unsupported by the spec.
Applicant further argues,‘….Applicants note that,….in the relevant description…. [0028] In some example embodiments, the host 1100 may set monitoring conditions for the storage device 1200.... [0074] ….the storage device 1200 compares the workload threshold WL_TH for each virtual machine VM stored….….FIG. 3….[0075]…’. (Rem, Pg. 10)
Response: Picking and choosing features from different paragraphs without establishing how those features interrelate creates an incomplete, ambiguous or new limitation. The expectation that PHOSITA must conduct trial-and-error research to figure out how the features interact violates § 112.
Applicant further argues,‘Claim 9 is amended…., "monitoring, by a storage controller of the storage device, a workload of each of the plurality of virtual machines on the storage device by counting read commands or write commands sent to the storage device’. (Rem, Pg. 12)
Response: As mentioned in the 112(a), the spec does not disclose how the storage controller distinguishes which received r/w command is meant for which VM of the plurality of VMs running on the storage device.
Therefore the ‘monitoring’ is limited to counting the r/w commands sent to the storage device.
The spec does not disclose any meaningful detailed interaction between the host and the storage controller in relation to the ‘monitoring’ at the storage controller. Reciting a functional result like ‘monitoring….’ is not the same as describing how it is achieved. A 1-2 line casual mention of a result in the spec does not demonstrate that the inventor possessed the full scope of the limitation.
The spec is a high-level document and superficially recites many features and many technologies, which can be found in any textbook. But how these features and technologies are specifically ‘stitched’ together and utilized and the usage is described in detail for the disclosure, is missing.
Applicant further argues,‘….the Specification as originally filed is indicating that the storage controller monitors a workload of each of the plurality of virtual machines on the storage device’. (Rem, Pg. 12)
Response: The original disclosure makes a mere 2-line recitation that the storage device ‘runs’ aka executes a plurality of VMs and monitors a workload of each VM. No details are provided describing how the storage controller in the storage device creates and ‘runs’ these VMs or tracks each incoming r/w command to its corresponding VM, count the commands for that VM and determine each VM’s workload. Please see the 112(a) and 112(b).
Because the ‘running’ and monitoring’ are argued by the applicant to be important, the spec must teach exactly how this ‘running’ is achieved. Relying on the PHOSITA’s general knowledge cannot cure a failure to describe the actual invention in the spec itself.
The spec fails to disclose key operational components required to achieve ‘running’ and ‘monitoring’, such as how the controller handles I/O commands, performs memory virtualization, or isolates virtual resources from one another. An algorithm or flow chart detailing how I/O commands from the host are routed to virtual disks is missing. The specific type of virtualization software e.g., hypervisors, APIs, or firmware logic employed to instantiate the VMs, is missing.
The written description fails to convey that the applicant was in possession of ‘a storage device running a plurality of virtual machines’, and ‘monitoring a workload of each VM of the plurality of VMs on the storage device by counting r/w….’, at the time of filing. Without structural details (e.g., hypervisor configuration, processor-to-virtual core allocation mapping etc.), the disclosure does not demonstrate how the storage controller achieves the claimed importance.
Applicant further argues, ‘This is at the very least because Lee is not monitoring any workload with reference of the storage device to a workload threshold, but rather is monitoring error rates of data read from a host memory buffer (HMB) 1120 of the host’. (Rem, Pg. 14)
Response: This argument is incorrect.
According to the spec, ‘monitoring’ involves counting the r/w commands sent to the storage device. That’s all. How each received r/w command is associated with one of the VMs running in the storage device, is undisclosed. So the count for that VM is not reliably updated. Please see 112(a).
On the other hand, as shown in Lee, Fig. 1, the HMB controller is located in the storage controller of the storage device. As explained below, the HMB controller tracks and counts r/w commands received from the host to r/w to the storage device/NVM 1260. Furthermore, the HMB space in the host is mapped to the storage device. So HMB space is ‘included’ storage device. And Lee, Para-0048 recites, ‘….mapping data associated with address mapping of the non-volatile memory device 1260 may be stored in the first HMB area HMB1. User data to be programmed in the storage device 1200 may be temporarily stored in the second HMB area HMB2. Management data for managing or controlling the storage device 1200 may be stored in the third HMB area HMB3’. These regions are used by the HMB controller/storage controller to handle r/w requests from the host.
Lee, Para-0020 recites, ‘ The host 1100 may access the storage device 1200 for the purpose of storing or reading data in or from a non-volatile memory device (NVM) 1260’. For example, if a write command is received, the HMB controller uses HMB1 area to refer to the mapping information, determines that VM2 in storage device is associated with the write command, updates HMB2, and records the write count, WC in the HMB2 row of the HMB Health State Table in the controller. The WC applies towards the workload count of VM2.
If a read command is received, the controller uses HMB1, determines that the VM is VM3, reads HBM3, updates RC count for HBM3.
Lee discloses that counting r/w commands in HMB dictates the frequency of Error Checking and Correction/ECC sweeps, which are essential for determining when the data becomes corrupted. More write commands dictate physical wear, while read commands trigger mapping lookups. If the WC or RC exceed the threshold an ASE is sent to the host by the controller.
Hence Lee determines per-VM workload based on read and write counts in HMB. Accordingly Lee discloses ‘monitoring, …..by counting read commands or write commands sent to the storage’ and ‘sending an asynchronous event interrupt for at least one of the plurality of virtual machines….’.
More importantly, since the spec does not disclose determining the command to VM association mechanism, Lee’s disclosure fulfills the requirement.
Examiner Notes
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
1.’Storage device for supporting virtual machine, storage system including the storage device, and method of operating the same’, Samsung, US20170024132A1, Jun et al.
See Figs. 1-3. As per Para-0057, host memory 1140/host memory buffer/HMB may be used as a working memory associated with the physical function 1110-a or each of the virtual functions/VMs 1111 to 111n. And as per Para-0065, the host memory 1140 may provide a queue command storage area for supporting virtual functions/VMs. Fig. 3 shows how storage controller 2210 divides a buffer area allocated from the host memory/HMB through the host interface into a plurality of buffer areas/VMs.
2.’Computing systems including storage devices controlled by hosts’, Samsung, US20180088841A1, Ma et al.
Discusses event reporting between host and storage device in sufficient detail. As per Para-0006, the storage device may include a nonvolatile memory, and the host may control the storage device based on a physical address of the nonvolatile memory. The host may send an asynchronous event request command to the storage device. The storage device may monitor the nonvolatile memory and may send an asynchronous event request corresponding to the asynchronous event request command to the host based on the monitoring result. The asynchronous event request may include requesting another command from the host based on the monitoring result.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARVIND TALUKDAR whose telephone number is (303)297-4475. The examiner can normally be reached M-F, 10 am-6pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hosain Alam can be reached at 571-272-3978. 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.
Arvind Talukdar
Primary Examiner
Art Unit 2132
/ARVIND TALUKDAR/Primary Examiner, Art Unit 2132
Prosecution Insights