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 the amendment filed 12/04/2025.
Claims 1-20 are pending in this application.
Claims 1, 6, 8 and 13 are independent claims.
Claims 1-4, 6-11, and 13-16 are currently amended.
This Office Action is made final.
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.
Claims 1-17 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
In claim 1, ones see “second VIFA layer being a hardware”. It is not clear what that means. As it stands, there is no support for it in the specification. Fig 10 shows two distinct blocks “Second VIFA layer” (Block 10025) and “Second Hardware Layer” (Block 10026). To say that second VIFA layer is hardware contradicts that. It would mean those blocks have to be merged into one.
In claim 1, ones sees “and a fourth virtual interface different from the fourth virtual interface”. How can an interface be different than itself?
Claim 1, also recites establishing a second virtual interface transfer relationship between the second virtual interface and the fourth virtual interface, the second virtual interface being configured as a second data output party”. This is confusing and what would make sense if relationship was between first and fourth interfaces. Earlier the claim says “second VIF A layer including a third virtual interface and a fourth virtual interface different from the fourth virtual interface”. So the fourth layer is already part of the second layer so why that relationship matter.
Claims 6, 8 and 13 have the same problem and are rejected for the same reasons.
The remaining claims, not specifically mentioned, are rejected for being dependent upon one of the claims above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lee (US 2023/0251799 A1) in view of Tsirkin (US 2021/0263761 A1) and in further view of Earl (US 9,965,357 B1).
As per claim 1, Lee teaches A data processing method applied to a source virtual machine, the source virtual machine including a first virtual interface function abstract (VIFA) layer, the first VIFA layer being a hardware, the method comprising:
obtaining target information of the source virtual machine based on the first VIFA layer, the target information including control plane information and data plane information; (Lee [0011] The one or more data structures might also include a bitmap of dirty pages, which is a bitmap identifying dirty pages in a namespace assigned to a VM [data plane information]. Dirty pages are pages that have been modified due to write or write zeroes commands, such as those defined by the NVMe Specification. The size of the page mapping to single bits in the bitmap of mapped pages and the bitmap of dirty pages can be reported by the MFND to a host computing device. [0015] In order to perform live migration of VM data stored in a namespace on a non-volatile memory device, which might be referred to herein as a "source" non-volatile memory device, a host computing device first requests that the source non-volatile memory device track changes to the namespace by the associated VM using the command described above. In response thereto, the source non-volatile memory device tracks changes made by the VM to the namespace and stores one or more data structures such as those described above that identify the changed portions of the namespace [0073] As shown in FIG. 2F, the MFND 102A can also be configured to implement a command ll0F for enabling a host computing device l00A to retrieve a device internal state 214 of the child physical function 112B on the MFND 102B that is assigned to the VM 104A. The device internal state 214 of the child physical function 112B defines the current hardware state of the child physical function 112B. For example, and without limitation, the device internal state [control plane information] 214 can include various data structures containing the contents of an administration queue, the contents of one or more I/O submission queue pairs, the contents of one or more I/O completion queue pairs, and any asynchronous event request commands parked on the child physical function 112B. The device internal state 214 can include different or additional state information in other configurations);
establishing a virtual interface transfer relationship between the first VIFA layer and the second VIFA layer, including: establishing a first virtual interface transfer relationship between the first virtual interface and the third virtual interface, the first virtual interface being configured as a first data output party, and the third virtual interface being configured as a first data receiver corresponding to the first virtual interface; (Lee [0011] The one or more data structures might also include a bitmap of dirty pages, which is a bitmap identifying dirty pages in a namespace assigned to a VM. Dirty pages are pages that have been modified due to write or write zeroes commands, such as those defined by the NVMe Specification. The size of the page mapping to single bits in the bitmap of mapped pages and the bitmap of dirty pages can be reported by the MFND to a host computing device. [0015] In order to perform live migration of VM data stored in a namespace on a non-volatile memory device, which might be referred to herein as a "source" non-volatile memory device, a host computing device first requests that the source non-volatile memory device track changes to the namespace by the associated VM using the command described above. In response thereto, the source non-volatile memory device tracks changes made by the VM to the namespace and stores one or more data structures such as those described above that identify the changed portions of the namespace);
transmitting the target information to the target virtual machine based on second virtual interface transfer relationship (Lee [0060] The one or more data structures might also include a bitmap of dirty pages (“BDP”) 206, which is a bitmap identifying dirty pages in a namespace 202A assigned to a VM 104A. Dirty pages [data plane] are pages that have been modified due to write or write zeroes commands, such as those defined by the NVMe Specification. The size of the page mapping to single bits in the BMP 204 and the BDP 206 can be reported by the MFND 102A to the source host computing device 100A. For example, and without limitation, each individual bit in the BMP 204 and the BDP 206 might map to respective 4 kilobytes (“kB”), 8 kB, 16 kB, 32 kB, or 64 kB of the namespace 202A).
Lee does not teach determining that a target virtual machine includes a second VIFA layer, the second VIFA layer being a hardware, the first VIFA layer including a first virtual interface and a second virtual interface different from the first virtual interface, and the second VIFA layer including a third virtual interface and a fourth virtual interface different from the fourth virtual interface.
However, Tsirkin teaches determining that a target virtual machine includes a second VIFA layer, the second VIFA layer being a hardware, the first VIFA layer including a first virtual interface and a second virtual interface different from the first virtual interface, and the second VIFA layer including a third virtual interface and a fourth virtual interface different from the fourth virtual interface; (Tsirkin [0049] At block 435, the processing device of the destination host computer system starts the virtual machine on the destination host computer system. At block 440, the processing device of the destination host computer system compares the source host configuration data structure and the destination host configuration data structure. The processing device can determine whether the two data structure match. For example, in case of the configuration data structure being an ACPI table, the processing device can determine whether data structures and/or or individual data entries in the two ACPI tables are the same. In some implementations, the destination host computer system can compare the two data structures in response to determining that the virtual machine has been migrated to the destination host computer system as determined from the received part of the state of the virtual machine. [0058] At block 530, the processing device of the source host computer system compares source host configuration data structure and the destination host configuration data structure. In some implementations, the processing device can access the source hardware configuration data structure that has been generated when the virtual machine was initiated on the source host computer system before the migration. For example, the source hardware configuration data structure can describe a hardware configuration of the source host computer system for a virtual machine. In one implementation, the source host computer system can generate hardware configuration tables (hereinafter, “ACPI tables”) in accordance with the Advanced Configuration and Power Interface (ACPI) Specification. Such ACPI tables can include an extended system description table (XSDT), a differentiated system description table (DSDT), and/or a secondary system description table (SSDT). Some ACPI tables (e.g., XSDT) can include pointers to a table that contains hardware configuration definitions such as the power state and the CPU allocation. Other ACPI tables (e.g., DSDT and SSDT) can correspond to such a hardware configuration table).
The whole concept of “transfer relationship” is not clear to the examiner. If Table 1 of the specification is an example of this relationship, the examiner still does not see how this facilitates the transfer process.
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Tsirkin with the system of Lee to establish a second layer. One having ordinary skill in the art would have been motivated to use Tsirkin into the system of Lee for the purpose of managing host hardware configuration for virtual machine migration. (Tsirkin paragraph 01)
Lee and Tsirkin do not teach establishing a second virtual interface transfer relationship between the second virtual interface and the fourth virtual interface, the second virtual interface being configured as a second data output party, and the third virtual interface being configured as a second data receiver corresponding to the second virtual interface and transmitting the target information to the target virtual machine based on the first virtual interface transfer relationship.
However, Earl teaches establishing a second virtual interface transfer relationship between the second virtual interface and the fourth virtual interface, the second virtual interface being configured as a second data output party, and the third virtual interface being configured as a second data receiver corresponding to the second virtual interface; (Earl Fig 2 Block 216 and Fig 3)
transmitting the target information to the target virtual machine based on the first virtual interface transfer relationship (Earl [col 7, lines 63-65 and col 8, lines 1-5] In block 312, the save set is then restored. This can be achieved using an import command with an existing guide file (e.g., an export file) or a newly generated guide or export file. For example, if there is a change in the directory structure, the comparison enables the VHDs and the aVHDs to be transferred from the location identified in the configuration information included in the save set to the appropriate destination based on the configuration information of the destination)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Earl with the system of Lee and Tsirkin to establish a transfer relationship. One having ordinary skill in the art would have been motivated to use Earl into the system of Lee and Tsirkin for the purpose of backing up and/restoring virtual machines in cluster environments (col 1, lines 10-12)
As per claim 3, Lee teaches The data processing method of claim 1, wherein obtaining the target information of the source virtual machine based on the first VIFA layer includes:
searching for a first address corresponding to the data plane information in a first address record file of the first VIFA layer; obtaining the data plane information based on the first address; determining a first resource abstraction structure corresponding to the control plane information in the first VIFA layer, the first resource abstraction structure being a data structure; and obtaining the control plane information in the first resource abstraction structure. (Lee [0015] In order to perform live migration of VM data stored in a namespace on a non-volatile memory device, which might be referred to herein as a “source” non-volatile memory device, a host computing device first requests that the source non-volatile memory device track changes to the namespace by the associated VM using the command described above. In response thereto, the source non-volatile memory device tracks changes made by the VM to the namespace and stores one or more data structures such as those described above that identify the changed portions of the namespace. [0016] In turn, the host computing device requests the one or more data structures from the source non-volatile memory device. The host computing device then utilizes the one or more data structures to identify the modified portions of the namespace and requests the contents of those changed portions from the source MFND. The source non-volatile memory device, in turn, provides the changed data to the host computing device. The host computing device then causes the data changed by the VM in the namespace to be written to a namespace on a target non-volatile memory device. This process may be repeated until all of the changed data has been migrated from the namespace on the source non-volatile memory device to the namespace on the target non-volatile memory device. [0060] The one or more data structures might also include a bitmap of dirty pages (“BDP”) 206, which is a bitmap identifying dirty pages in a namespace 202A assigned to a VM 104A. Dirty pages are pages that have been modified due to write or write zeroes commands, such as those defined by the NVMe Specification. The size of the page mapping to single bits in the BMP 204 and the BDP 206 can be reported by the MFND 102A to the source host computing device 100A. For example, and without limitation, each individual bit in the BMP 204 and the BDP 206 might map to respective 4 kilobytes (“kB”), 8 kB, 16 kB, 32 kB, or 64 kB of the namespace 202A. [0073] As shown in FIG. 2F, the MFND 102A can also be configured to implement a command 110F for enabling a host computing device 100A to retrieve a device internal state 214 of the child physical function 112B on the MFND 102B that is assigned to the VM 104A. The device internal state 214 of the child physical function 112B defines the current hardware state of the child physical function 112B. For example, and without limitation, the device internal state 214 can include various data structures containing the contents of an administration queue, the contents of one or more I/O submission queue pairs, the contents of one or more I/O completion queue pairs, and any asynchronous event request commands parked on the child physical function 112B. The device internal state 214 can include different or additional state information in other configurations.)
As per claim 4, Lee teaches separating the target information of the source virtual machine into the control plane information and the data plane information; obtaining a first address for storing the data plane information; recording the first address in the first address record file; establishing a first resource abstraction structure in the first VIFA layer, the first resource structure being a data structure; and storing the control plane information in the first resource abstraction structure. (Lee [0010] In various embodiments, the one or more data structures might be implemented as a bitmap of mapped pages. The bitmap of mapped pages is a bitmap that identifies mapped pages from a namespace assigned to a VM. Mapped pages are pages that have been allocated due to write or write zeroes commands, such as those defined by the Non-Volatile Memory Express (“NVMe”) Specification. [0125] Clause 4. The computer-implemented method of any of clauses 1-3, wherein the one or more data structures comprise one or more data structures selected from the group consisting of a bitmap of mapped pages, a bitmap of dirty pages, an ordered list of mapped page ranges, and an ordered list of dirty page range [0127] Clause 6. The computer-implemented method of any of clauses 1-5, wherein the device internal state comprises one or more data structures selected from the group consisting of an administration queue, one or more input/output (I/O) submission queue pairs, one or more I/O completion queue pairs, and any asynchronous event request commands parked on the child physical function assigned to the VM. [0144] Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be executed in any order, combined in any order, subdivided into multiple sub-operations, and/or executed in parallel to implement the described processes. The described processes can be performed by resources associated with one or more device(s) such as one or more internal or external CPUs or GPUs, and/or one or more instances of hardware logic such as FPGAs, DSPs, or other types of accelerators).
As per claim 5, Lee teaches wherein when the data plane information includes a to-be-migrated dirty page memory, obtaining the target information of the source virtual machine based on the first VIFA layer includes:
determining a dirty bitmap in a first address record file of the first VIFA layer, the dirty bitmap including at least one dirty page address and the dirty page memory corresponding to each of the dirty page addresses in the at least one dirty page address; (Lee [0044] Having developed a set of one or more migration-direction-specific correlation models, the guest OS tool correlations and hypervisor implementation-related settings for specific directional migrations may be output/stored (225). In one or more embodiments, the correlations may be stored locally (e.g., local repository 130 of FIG. 1), globally/centrally (e.g., central repository 140 of FIG. 1), or both. [0046] FIG. 3 depicts a methodology for analytics-based migrating of guest OS optimization tool settings in a multi-hypervisor data center environment, according to embodiments of the present disclosure. [0047] In one or more embodiments, a virtual machine operating on a first hypervisor environment from a first vendor is selected (305) to be migrated to a second hypervisor environment from a second vendor. In one or more embodiments, the analytics-based migration system gathers (310) data regarding the source guest OS tool settings and hypervisor environment settings-related data for the source hypervisor environment, the destination hypervisor environment, or both).
for each of the dirty page addresses in the at least one dirty page address, determining the dirty page memory corresponding to each of the dirty page addresses to obtain at least one dirty page memory; and determining that the to-be-migrated dirty page memory is the at least one dirty page memory. (Lee [0070] The live migration agent 208A executing on the source host computing device 100A can utilize the BDP 206 to identify data that the VM 104A changed in the namespace 202A and to retrieve that data from the MFND 102A. For example, and as illustrated in FIG. 2E, the live migration agent 208A executing on the source host computing device 100A can utilize the BDP 206 to identify dirty LBA pages 212 in the namespace 202A. In turn, the live migration agent 208A can cause the management API 118 to issue one or more commands 110E to read the dirty LBA pages 212 from the namespace 202A. The parent physical function 112A receives the command 110E and, in response thereto, reads the dirty LBA pages 212 from the namespace 202A and returns the dirty LBA pages 212 in response to the command 110E. [0072] The live migration agent 208B on the target host computing device 100B can then call the management API 118 in order to write the dirty LBA pages 212 to the target namespace 202B. The parent physical function 112D writes the dirty LBA pages 212 to the target namespace 202B on the non-volatile memory device 103B on the target MFND 102B. As will be discussed in greater detail below, this process might be repeated multiple times in order to migrate all of the dirty LBA pages 212 from the namespace 202A on the source MFND 102A to the namespace 202B on the target MFND 102B. [0085] The routine then proceeds to operation 318, where the source host computing device 100A transmits the dirty LBA pages 212 to the live migration agent 208B executing on the target host computing device 100B. The live migration agent 208B executing on the target host computing device 100B then causes the dirty LBA pages 212 to be written to the namespace 202B on the MFND 102B. The operations 314 and 316 may be repeated as necessary to migrate all of the dirty LBA pages 212 from the MFND 102A to the MFND 102B.)
As per claim 7, Lee teaches the second VIFA layer includes a second address record file and a second resource abstraction structure, and the method further comprising: determining a second address for storing the data plane information; and recording the second address in the second address record file for obtaining the data plane information through the second address; and establishing an association relationship between the second resource abstraction structure and the control plane information for obtaining the control plane information through the association relationship. (Lee [0015] In order to perform live migration of VM data stored in a namespace on a non-volatile memory device, which might be referred to herein as a “source” non-volatile memory device, a host computing device first requests that the source non-volatile memory device track changes to the namespace by the associated VM using the command described above. In response thereto, the source non-volatile memory device tracks changes made by the VM to the namespace and stores one or more data structures such as those described above that identify the changed portions of the namespace. [0016] In turn, the host computing device requests the one or more data structures from the source non-volatile memory device. The host computing device then utilizes the one or more data structures to identify the modified portions of the namespace and requests the contents of those changed portions from the source MFND. The source non-volatile memory device, in turn, provides the changed data to the host computing device. The host computing device then causes the data changed by the VM in the namespace to be written to a namespace on a target non-volatile memory device. This process may be repeated until all of the changed data has been migrated from the namespace on the source non-volatile memory device to the namespace on the target non-volatile memory device. [0060] The one or more data structures might also include a bitmap of dirty pages (“BDP”) 206, which is a bitmap identifying dirty pages in a namespace 202A assigned to a VM 104A. Dirty pages are pages that have been modified due to write or write zeroes commands, such as those defined by the NVMe Specification. The size of the page mapping to single bits in the BMP 204 and the BDP 206 can be reported by the MFND 102A to the source host computing device 100A. For example, and without limitation, each individual bit in the BMP 204 and the BDP 206 might map to respective 4 kilobytes (“kB”), 8 kB, 16 kB, 32 kB, or 64 kB of the namespace 202A. [0073] As shown in FIG. 2F, the MFND 102A can also be configured to implement a command 110F for enabling a host computing device 100A to retrieve a device internal state 214 of the child physical function 112B on the MFND 102B that is assigned to the VM 104A. The device internal state 214 of the child physical function 112B defines the current hardware state of the child physical function 112B. For example, and without limitation, the device internal state 214 can include various data structures containing the contents of an administration queue, the contents of one or more I/O submission queue pairs, the contents of one or more I/O completion queue pairs, and any asynchronous event request commands parked on the child physical function 112B. The device internal state 214 can include different or additional state information in other configurations.)
Claim 2 is already covered by claim 1 because claim 1 teaches both data plane and control plane transmission of data.
As to claims 6, 8 and 13, they are rejected based on the same reason as claim 1.
As to claims 9 and 14, they are rejected based on the same reason as claim 2.
As to claims 10 and 15, they are rejected based on the same reason as claim 3.
As to claims 11 and 16, they are rejected based on the same reason as claim 4.
As to claims 12 and 17, they are rejected based on the same reason as claim 5.
As to the new claim 18, it is rejected based on the same reason as claim 1. (Mapping has shown state/configuration info and dirty pages explicitly)
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Lee (US 2023/0251799 A1) in view of Tsirkin (US 2021/0263761 A1) in and in further view of Earl (US 9,965,357 B1) and Lu (US 2023/0244380 A1).
As per claim 19, Lee and Tsirkin and Earl do not each wherein each of the first virtual interface, the second virtual interface, the third virtual interface, and the fourth virtual interface is a high-speed serial computer expansion bus (e.g., a peripheral component interconnect express, PCie) type of virtual interface.
However, Lu teaches the data wherein each of the first virtual interface, the second virtual interface, the third virtual interface, and the fourth virtual interface is a high-speed serial computer expansion bus (e.g., a peripheral component interconnect express, PCie) type of virtual interface. (Lu [0076] During the operation of the virtual machine, the PCIe 138 may be virtualized to four virtual interfaces 140. The virtual functions 128 may have a one to one correspondence with the virtual interfaces 140; in other words, a first virtual function corresponds to a first virtual interface, and a second virtual function corresponds to a second virtual interface, and the like. [0125] The PCIe identifier 523 is configured to record configuration of the virtual interface (such as the virtual interface 140 in FIG. 1) of the source server. The virtual interface refers to a PCIe virtual interface designated to the specific virtual function 407).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Lu with the system of Lee and Tsirkin and Earl to use a high-speed serial computer expansion bus. One having ordinary skill in the art would have been motivated to use Lu into the system of Lee and Tsirkin and Earl for the purpose of implementing live migration (Lu paragraph 05)
Allowable Subject Matter
Claim 20 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed on 12/04/2025 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claims 1, 6, 8 and 13 have been considered but are moot because the arguments do not apply because of the introduction of new art by Earl.
The examine thinks the claim language is confusing and the amendments have simply put even more layers into the independent claims. It is crucial at a minimum to designate each layer as being a target or a source layer. This would be somewhere along the lines of Fig 10. It is also important to add what the layer is for (i.e. transferring data or control plane information). Otherwise it is truly confusing and makes the job of finding prior art difficult. The idea of transferring data and control plane information during live migration of virtual machines is well known.
The layers are not defined in any degree of specificity within the specification. In short “There are a lot of abstraction layers” but very little detail about the inner workings and advantages over existing technology. The specification also shows examples of relationships among layers (Tables 1 and 2) but very little about these layers and what they do and how they do things differently than what is known.
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 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 MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor April Blair, can be reached on (571)270-1014. 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.
/MEHRAN KAMRAN/Primary Examiner, Art Unit 2196
Prosecution Insights