Patent Grant
11681590
Some hypervisors may use virtual machine snapshots to improve the input/output (I/O) characteristics of a virtual machine (VM). A hypervisor may be configured to allow or cause a virtual machine to write a snapshot to a data store. A VM snapshot may be, for example, a file-based view of the state, disk data, memory, configuration, and other information associated with a VM at a specific point in time. A snapshot may be created for different reasons. It is possible to take multiple snapshots of a VM. A snapshot may be acquired even while a VM is running. A snapshot may be treated as a whole or may have its contents accessed individually. A snapshot may preserve the state and data of a VM at a specific point in time. The state may include, for example, the VM's power state (on, off, suspended). The data may include, for example, all the files touched by the VM and all the files that make up the VM. The data may also include, for example, information from disks, memory, and other devices touched by the VM.
The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various example systems, methods, and other example embodiments of various aspects of the invention. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that in some examples one element may be designed as multiple elements or that multiple elements may be designed as one element. In some examples, an element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.
Example apparatus and methods process virtual machine image level backups that may include files that are compressed and files that are not compressed. Example apparatus and methods may produce virtual machine image level backups by selectively compressing some files while leaving other files in their uncompressed state. Example apparatus and methods may then selectively recover a file or even an entire disk image from the image level backup that may include both compressed files and files that are not compressed.
Backing up a virtual machine at the image level and then being able to recover files from the backup image at the file level provides significant improvements over conventional systems that only provide image level recovery. For example, being able to recover at the file level allows management of backups to be simplified while providing users access to specific files in a backup image when needed. Image level backups followed by file level recovery workflows avoid recovering an entire backup image, which recovery would add significant overhead to the recovery process for a single file.
Example apparatus and methods selectively compress files during image level backup. Conventional systems do not perform this selective compression. Instead, conventional systems may compress all files to be placed into a disk image. Unfortunately, compressing an entire disk image during backup may add significant overhead to the backup process. In addition, much of the additional overhead may be unnecessary in cases where individual files are not suitable candidates for compression, such as with video files, or files that have already been compressed.
Compressing an entire disk image during backup also introduces significant overhead when the fully compressed image is used for file level recovery. In order to perform any recovery, even of just a single file, a conventional system must first decompress the entire disk image. Only after this lengthy process is performed can conventional systems recover individual files from the disk image.
Consider a virtual machine having a 100 GB disk. Assume that the 100 GB disk was backed up using a system that compressed the entire image. To recover an individual file from this backup, the entire 100 GB image needs to first be uncompressed before the file can be recovered. Example apparatus and methods improve on this approach by only selectively compressing files that are put into the backup and by allowing file level recovery with selective decompression from the backup.
In order to avoid the overhead of compressing the entire disk image during backup, only selective files are compressed by example apparatus and methods. Files are selected for compression based on pre-defined or user defined criteria, (e.g., file size, file type). For example, video files may be excluded from compression because they tend not to compress very well.
In one embodiment, creating an image level backup using selective compression may include take a snapshot of a virtual machine and then making a read/write copy of the snapshot. The read/write copy may then be mounted to a file system. While the read/write copy is mounted, files in the read/write copy may be selectively compressed while other files are left alone. Files may be selected for compression based on criteria including, for example, name, size, type, or user-designation. After the files have been selectively compressed in the mounted read/write copy, then file system buffers can be synchronized with the read/write copy. After the file system buffers are synchronized, then the read/write copy may be dismounted from the file system. An image level backup may then be created from the unmounted copy. Even though an image level backup is being created, file level recovery will be possible from the backup. The file level recovery may proceed without having to decompress the entire backup. If the file to be recovered is compressed, then it can be retrieved from the backup and just that file can be decompressed. If the file to be recovered isn't compressed, then the file can be retrieved and used without decompression.
In one embodiment, performing file recovery from a selectively compressed image level backup includes mounting the backup snapshot image that was created using selective compression, selecting a file to be recovered, and recovering the file at the file level, performing decompression if necessary. While a single file can be recovered, an entire image may also be recovered. In one embodiment, performing an image recovery from a selectively compressed image level backup includes making a copy of the backup snapshot image and then mounting the copy in read/write mode. A file system in the image may be walked to discover the files in the image. When a compressed file is encountered, the file may be decompressed in the read/write copy. After the file system has been walked, then file system buffers may be synchronized to the read/write copy and then the read/write copy may be unmounted. The full image may then be recovered from the unmounted copy.
Some portions of the detailed descriptions herein are presented in terms of algorithms and symbolic representations of operations on data bits within a memory. These algorithmic descriptions and representations are used by those skilled in the art to convey the substance of their work to others. An algorithm, here and generally, is conceived to be a sequence of operations that produce a result. The operations may include physical manipulations of physical quantities. Usually, though not necessarily, the physical quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. The physical manipulations create a concrete, tangible, useful, real-world result.
It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, or numbers. It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it is to be appreciated that throughout the description, terms including processing, computing, and determining refer to actions and processes of a computer system, logic, processor, or similar electronic device that manipulates and transforms data represented as physical (electronic) quantities.
Example methods may be better appreciated with reference to flow diagrams. For purposes of simplicity of explanation, the illustrated methodologies are shown and described as a series of blocks. However, it is to be appreciated that the methodologies are not limited by the order of the blocks, as some blocks can occur in different orders or concurrently with other blocks from that shown and described. Moreover, less than all the illustrated blocks may be required to implement an example methodology. Blocks may be combined or separated into multiple components. Furthermore, additional or alternative methodologies can employ additional, not illustrated blocks.
Method 600 also includes, at 660, determining whether a file is to be recovered or whether an entire image is to be recovered. The determination may be made based, for example, on information provided by a recovery operation, on information provided by a user, or on other information. Upon determining that a file is to be recovered from the image level backup of the virtual machine, method 600 proceeds to 670. Since files in the image level backup may either be compressed or not compressed, method 600 proceeds, at 670, to determine whether the file is compressed. The determination about whether the file is compressed may be based, for example, on information about the file that is carried by the file, on information about the file that is stored in an operating system or file system, on information provided by a user, on an examination of the file to see whether it is in a compressed state, or on other information. If the file is compressed in the image level backup, method 600 proceeds, at 672, by decompressing the file to be recovered into an uncompressed file. In one embodiment, where different files may have been compressed using different approaches, method 600 may include identifying an appropriate decompression approach and decompressing the file at 672 using the identified decompression approach.
Once the file has been decompressed, it may be provided as an uncompressed file at 674. If the file was not compressed in the image level backup, then method 600 proceeds to provide the file from the image level backup at 674 without performing decompression. Providing the file may include copying the contents of the file to another file, providing an inode that identifies the file, providing file system information that facilitates locating the file, or performing other computer based actions.
Upon determining at 660 that an entire disk image is to be recovered from the image level backup, method 600 proceeds to 680. Determining that an entire disk image is to be recovered may be based on information provided by a recovery operation, on information provided by a user, on information provided by a scheduled recovery process, or in other ways.
Method 600 continues, at 680, by instantiating a disk image file. Instantiating a disk image file may include sending a request to an operating system, sending a request to a file system, interacting with a hypervisor, or other computer based operation.
Method 600 may also include, at 682, identifying a set of files associated with the entire disk image. When an entire disk image is to be recovered, the set of files identified at 682 will be a set that is sufficient to recover the entire disk image. In one embodiment, identifying the set of files associated with the entire disk at 682 includes accessing file system metadata associated with files on the entire disk image. The file system metadata may facilitate walking a file system associated with the entire disk image. Walking the file system may in turn facilitate identifying a complete set of files that are needed to recover the entire disk image.
Method 600 also includes, at 690, determining whether members of the set of files are compressed and need to be decompressed or whether members of the set of files are not compressed and can simply be provided without being decompressed. When a file is identified as being compressed, method 600 may also include identifying a compression approach used to compress the file and a corresponding appropriate decompression approach.
If the determination at 690 for a member of the set of files is that the member of the set of files is compressed in the image level backup, method 600 proceeds, at 692, by decompressing the member of the set of files into an uncompressed file. In one embodiment, where different files may have been compressed using different approaches, method 600 may include identifying an appropriate decompression approach and decompressing the file at 692 using the identified decompression approach.
After the file is decompressed, the uncompressed file is added to the disk image file at 694. If the determination at 690 is that the member of the set of files is not compressed in the image level backup, method 600 proceeds, at 694, by adding the member of the set of files to the disk image file. Adding the member of the set of files to the disk image file may include copying a file, copying an inode, providing information to a file system that is managing the disk image, providing information to a disk manager, or other computer based operations. Actions 690, 692, and 694 may be performed for all members of the set of files identified at 682.
Method 600 also includes, at 620, accessing an existing disk image associated with the virtual machine. Accessing the existing disk image may include, for example, mounting the existing disk image to a file system associated with a hypervisor that supports the virtual machine.
Method 600 may include, at 630, identifying a plurality of files associated with the existing disk image. In one embodiment, the plurality of files may include all files that are associated with the virtual machine. In another embodiment, the plurality of files may include selected files that are associated with the virtual machine. In one embodiment, identifying files associated with the existing disk image at 630 includes accessing file system metadata associated with the existing disk image and walking a file system associated with the existing disk image based, at least in part, on the file system metadata. In another embodiment, a user may select the plurality of files. Walking the file system may involve, for example, a depth first search that visits all inodes in a file system tree.
Method 600 may decide, at 640, whether a member of the plurality of files associated with the existing disk image is to be compressed. In one embodiment, determining that the member of the set of files is to be compressed includes determining whether the member of the set of files has a size that satisfies a size criteria, determining whether the member of the set of files has a type that satisfies a type criteria, determining whether the member of the set of files has an age that satisfies an age criteria, determining whether the member of the set of files has a name that satisfies a name criteria, or determining other properties of the file. In one embodiment, determining whether the member of the set of files is to be compressed includes determining whether the member of the set of files has been designated by a user for compression.
Upon determining that the member of the plurality of files is to be compressed before being stored on the compressed disk image, method 600 proceeds, at 642, by compressing the member of the plurality of files into a compressed file. In one embodiment, where individual files may be compressed using different techniques, method 600 may include identifying an appropriate compression technique for the file. The technique may be identified based, at least in part, on file attributes, user inputs, or other criteria.
The compressed file is then added to the compressed disk image at 644. Upon determining that the member of the plurality of files is not to be compressed before being stored on the compressed disk image, method 600 proceeds, at 644, by adding the member of the plurality of files to the compressed disk image without compressing the file. The determination at 640 may be made for all files in the plurality of files.
Method 600 may also include, at 646, producing the image level backup from the compressed disk image. Producing the image level backup may include, for example, providing the compressed disk image to a backup process, making a copy of the compressed disk image, or other action. Since files may be selectively compressed, the image level backup may include files that are compressed and files that are not compressed. In one embodiment, the image level backup may be created at 646 after the compressed disk image includes a set of files from which the existing disk image can be recovered.
In one example, a method may be implemented as computer executable instructions. Thus, in one example, a computer-readable storage medium may store computer executable instructions that if executed by a machine (e.g., processor) cause the machine to perform method 600 or other methods described herein. While executable instructions associated with method 600 are described as being stored on a computer-readable medium, it is to be appreciated that executable instructions associated with other example methods described herein may also be stored on a computer-readable medium.
The following includes definitions of selected terms employed herein. The definitions include various examples and/or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Both singular and plural forms of terms may be within the definitions.
References to “one embodiment”, “an embodiment”, “one example”, “an example”, and other similar terms, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, though it may.
“Computer component”, as used herein, refers to a computer-related entity (e.g., hardware, firmware, software in execution, combinations thereof). Computer components may include, for example, a process running on a processor, a processor, an object, an executable, a thread of execution, and a computer. A computer component(s) may reside within a process and/or thread. A computer component may be localized on one computer and/or may be distributed between multiple computers.
“Computer-readable storage medium”, as used herein, refers to a non-transitory medium that stores instructions and/or data. A computer-readable medium may take forms, including, but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and other disks. Volatile media may include, for example, semiconductor memories, dynamic memory, and other memories. Common forms of a computer-readable medium may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, a CD, other optical medium, a RAM, a ROM, a memory chip or card, a memory stick, and other media from which a computer, a processor or other electronic device can read.
“Data store”, as used herein, refers to a physical and/or logical entity that can store data. A data store may be, for example, a database, a table, a file, a data structure (e.g. a list, a queue, a heap, a tree) a memory, a register, or other repository. In different examples, a data store may reside in one logical and/or physical entity and/or may be distributed between two or more logical and/or physical entities.
“Logic”, as used herein, includes but is not limited to hardware, firmware, software in execution on a machine, and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system. Logic may include, for example, a software controlled microprocessor, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, or a memory device containing instructions. Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics.
An “operable connection”, or a connection by which entities are “operably connected”, is one in which signals, physical communications, or logical communications may be sent or received. An operable connection may include a physical interface, an electrical interface, or a data interface. An operable connection may include differing combinations of interfaces or connections sufficient to allow operable control. For example, two entities can be operably connected to communicate signals to each other directly or through one or more intermediate entities (e.g., processor, operating system, logic, software). Logical or physical communication channels can be used to create an operable connection.
“Signal”, as used herein, includes but is not limited to, electrical signals, optical signals, analog signals, digital signals, data, computer instructions, processor instructions, messages, a bit, or a bit stream, that can be received, transmitted and/or detected.
“Software”, as used herein, includes but is not limited to, one or more executable instructions that cause a computer, processor, or other electronic device to perform functions, actions and/or behave in a desired manner. “Software” does not refer to stored instructions being claimed as stored instructions per se (e.g., a program listing). The instructions may be embodied in various forms including routines, algorithms, modules, methods, threads, or programs including separate applications or code from dynamically linked libraries.
“User”, as used herein, includes but is not limited to one or more persons, software, logics, applications, computers or other devices, or combinations of these.
Memory 820 may include volatile memory and/or non-volatile memory. Non-volatile memory may include, for example, read only memory (ROM), programmable ROM (PROM), and other memory. Volatile memory may include, for example, random access memory (RAM), and other memory. The memory 820 can store a process or data. Memory 820 may store electronic data associated with a virtual disk associated with the virtual machine.
Apparatus 800 may include a first logic 832 that creates an image level backup for the virtual machine. The image level backup may include a compressed file associated with the virtual machine and an uncompressed file associated with the virtual machine. The image level backup may depend, at least in part, on the electronic data associated with the virtual disk. In one embodiment, since files may be processed individually while creating the image level backup, different files may be compressed different ways. In conventional systems, where the entire image is compressed as an image, only a single compression approach may be employed. Being able to compress different files in different ways facilitates compressing files using an appropriate compression approach.
In one embodiment, the first logic 832 creates the image level backup by creating a snapshot of the virtual machine and then creating a read/write copy of the snapshot. The read/write copy is modified by selectively compressing files in the read/write copy. Some files may be compressed and some files may be left as-is, without being compressed. In one embodiment, different files may be compressed in different ways. The decision about whether or how to compress a file may be based on different factors. For example, a file may be selectively compressed based, at least in part, on a file type, a file size, a file age, or a user designation.
The first logic 832 may synchronize a file system associated with the virtual machine to the read/write copy. Synchronizing the file system and the read/write copy may include, for example, synchronizing file system buffers, operating system buffers, virtual machine data stores, hypervisor data stores, or other data stores. The first logic 832 may create the image level backup from the read/write copy.
This embodiment also includes a third logic 836 that recovers an entire image from the image level backup using file level recovery. The third logic 836 may recover the entire image from the image level backup by making a copy of the image level backup and establishing an association between the copy and a target file system associated with the hypervisor so that the associated copy can be read from and written to. Making the association may include, for example, mounting the copy to the target file system or otherwise making the copy visible to an operating system or file system.
To recover an entire image, the third logic 836 may identify a set of files in the mounted copy that are sufficient to recover the entire disk image. Identifying the set of files may include, for example, examining file system metadata, performing a file system operation (e.g., discover all), performing a database operation (e.g., find all), receiving user inputs, or performing another computer based operation.
The third logic 836 may, for members of the set of files, determine whether the files are compressed and need to be decompressed or whether the files are not compressed and can be processed without decompression. In one embodiment, where files may have been compressed individually using different compression approaches, the third logic 836 may identify an appropriate decompression approach on a per file basis.
The third logic 836 may, upon determining that the member is compressed, decompress the member file in the associated copy. For members that are not compressed, the third logic 836 may leave the file as-is in the associated copy. The third logic 836 may decompress files using different decompression approaches.
The third logic 836 may also synchronize the target file system and the associated copy. Synchronizing the target file system and the associated copy may include synchronizing buffers associated with an operating system or file system, or may include synchronizing data stores associated with an operating system, file system, virtual machine, or hypervisor. The third logic 836 may also break or otherwise end the association between the associated copy and the target file system to produce a free copy from which the entire disk image can be recovered.
Method 1000 includes, at 1050, mounting the image level backup to a target file system to produce a mounted image level backup. “Mounting” is used in its computer science term of art meaning. In one embodiment, mounting is the attaching of an additional file system to a currently accessible file system. The additional file system may be associated with the image level backup. The currently accessible file system may be associated with the running virtual machine or hypervisor. Recall that a file system may be, for example, a hierarchy of directories that may be used to organize files on a computer or computer readable storage medium. Mounting a file system may include providing information to an operating system about where in the hierarchy of directories to attach the file system being mounted. The attachment point may be referred to as the mount point. The mount point may become the root directory of the file system being mounted. Original contents of a directory that is used as a mount point may become invisible and inaccessible while the additional file system is still mounted.
Method 1000 includes, at 1060, determining whether a file will be recovered or whether an image will be recovered. Upon determining that a file is to be recovered, the file may be identified. Identifying the file may include, for example, receiving a file name from a recovery process, receiving a pointer to a file, receiving an inode, or other action. Method 1000 may proceed, at 1062, to determine whether the file to be recovered is compressed. Upon determining that the file is not compressed in the mounted image level backup, method 1000 may provide the file to the target file system at 1066 without decompressing the file. Information upon which the determination of whether the file is compressed can be made may be found in the file system that is mounted, in the operating system, in the image, in metadata associated with the file, in the file itself, or elsewhere.
Upon determining at 1062 that the file is compressed in the mounted image level backup, method 1000 may, at 1064, decompress the file to produce a decompressed file. The decompressed file may then be provided to the target file system at 1066. In one embodiment, where individual files may be compressed in different ways, method 1000 may include identifying a decompression approach for decompressing the file at 1064. Information upon which the identification of the appropriate decompression approach can be made may be found in the file system that is mounted, in the operating system, in the image, in metadata associated with the file, in the file itself, or elsewhere.
Upon determining that an entire disk image is to be recovered from the image level backup, method 1000 may proceed, at 1070, to make a copy of the image level backup. Method 1000 may, at 1072, mount the copy in a read/write mode to a target file system to produce a mounted copy. The target file system may be associated with a virtual machine, a hypervisor, a host machine, or other computer or process.
Method 1000 includes, at 1074, identifying a set of files in the mounted copy that are sufficient to recover the entire disk image. The identification may be based, for example, on file system metadata, on information available in the disk image, on information available in the target file system, on user inputs, or on other data. In one embodiment, identifying the set of files in the mounted copy includes accessing file system metadata associated with files on the entire disk image and walking a file system associated with the entire disk image based, at least in part, on the file system metadata.
At 1080, method 1000 may make determinations for members of the set of files. Upon determining that a member is compressed, method 1000 may, at 1082, decompress the member in the mounted copy. If the member is not compressed, method 1000 may proceed to the next file until all the files have been considered.
Method 1000 may also include, at 1084, synchronizing a buffer associated with the target file system to the mounted copy. Recall that the mounted image may have had its file system and that the target file system has its own file system. While mounted in the target system, file system metadata, operating system metadata, state, status, or other information may have become unsynchronized. Synchronizing the buffer at 1084 facilitates continuing error-free operations in the two file systems or other processes.
Method 1000 includes, at 1086, unmounting the mounted copy from the target file system to produce an unmounted copy, and, at 1090, recovering the entire disk image from the unmounted copy.
Method 1000 also includes, at 1012, creating a read/write copy of the snapshot image. In one embodiment, the read/write copy is made because the snapshot may be used for other purposes while the image is being created. At 1014, the copy is read/write mounted to a file system associated with a hypervisor that supports the virtual machine. With the copy mounted read/write, files in the copy may now be manipulated or modified in the copy. For example, method 1000 may, at 1016, modify the mounted read/write copy by selectively compressing one or more files in the mounted read/write copy.
A file in the mounted read/write copy may be selectively compressed upon determining that the file has a size that satisfies a size criteria, has a type that satisfies a type criteria, has an age that satisfies an age criteria, or has a name that satisfies a name criteria. For example, files that are more than a year old may be compressed while files that are smaller than 4k may not be compressed. A file in the mounted read/write copy may also be selectively compressed upon determining that the file has been designated by a user for compression. In one embodiment, different files may be compressed in different ways based, for example, on file type, size, age, owner, protections, security, or other attributes. For example, audio files may be compressed using one compression technique while text files may be compressed using a different compression technique. This is not performed in conventional systems because in conventional systems the entire image is compressed using a single compression technique.
Once the files have been modified, method 1000 may proceed, at 1020, to synchronize the mounted read/write copy and a data store or data structure (e.g., file system buffer) associated with the file system associated with the hypervisor. The read/write copy may then be unmounted at 1030 and the image level backup created from the unmounted read/write copy at 1040. Unmounting the read/write copy breaks down the relationship established by mounting the read/write copy.
While example systems, methods, and other embodiments have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and other embodiments described herein. Therefore, the invention is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims.
To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim.
To the extent that the term “or” is employed in the detailed description or claims (e.g., A or B) it is intended to mean “A or B or both”. When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995).
This application is a continuation of U.S. patent application Ser. No. 14/328,751, entitled “FILE LEVEL RECOVERY USING VIRTUAL MACHINE IMAGE LEVEL BACKUP WITH SELECTIVE COMPRESSION,” filed on Jul. 11, 2014, which is hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7103740 | Colgrove | Sep 2006 | B1 |
| 8060476 | Afonso | Nov 2011 | B1 |
| 8682862 | Rosikiewicz | Mar 2014 | B2 |
| 9632877 | Yin | Apr 2017 | B1 |
| 9785647 | Petri | Oct 2017 | B1 |
| 20100162039 | Goroff | Jun 2010 | A1 |
| 20110196842 | Timashev | Aug 2011 | A1 |
| 20160232060 | Nanivadekar | Aug 2016 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20170139786 A1 | May 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14328751 | Jul 2014 | US |
| Child | 15421583 | US |
