VIRTUAL MULTICHANNEL STORAGE CONTROL

A computing system includes a computer executing an emulated operating system, the emulated operating system including a multichannel control unit; a plurality of virtual drives accessible to the emulated operating system; and a communication channel, the communication channel connecting the multichannel control unit and the virtual drives through one or more virtual channels. The multichannel control unit sends a first data access request to a virtual drive through the first virtual channel of the communication channel, the multichannel control unit sends a second data access request to a virtual drive through the second virtual channel of the communication channel.

FIELD OF THE DISCLOSURE

The present invention relates generally to computer architecture and internet infrastructure for storage access of virtual machines (emulated systems). More particularly, the present invention relates to increased speed in accessing virtual drives using virtual multichannel storage control, wherein the virtual multichannel is established over a single communication channel.

BACKGROUND

Virtual disk is an emulated hard drive, also known as logical hard drive. In most cases, a virtual disk is a file hosted on a physical hard drive, also known as disk-in-a-file. A virtual disk can be setup in a non-emulated operating system and/or an emulated operating system. For example, a virtual disk can be established under Linux, a non-emulated operating system, or a virtual disk can be established under Clear path OS 2200, an emulated operating system.

The data throughput of one or multiple virtual disks hosted on a physical hard drive is limited because the physical hard drive is accessed through a single communication channel. Only one data access request can be processed at a given time through a communication channel. After a data access request of a virtual drive is sent to the physical hard drive through the communication channel, there is a response latency before the data in interest is returned. Thus, the entire data throughput of the communication is limited because after one request is sent, the system idles and waits for at least the response latency to receive the desired data. The response latency causes a bandwidth limitation.

The embodiments of this disclosure aim to provide solutions to significantly increase the communication bandwidth using the same single communication channel.

SUMMARY

The present invention relates generally to computer architecture and internet infrastructure for storage access in virtual machines (emulated systems). More particularly, the present invention relates to increased speed in accessing virtual drives using virtual multichannel storage control, wherein the virtual multichannel is established over a single communication channel.

The data throughput of one or multiple virtual disks hosted on a physical hard drive is limited because the physical hard drive is accessed through a single communication channel. Traditionally, only one data access request can be processed at a given time through a communication channel. After a data access request of a virtual drive is sent to the physical hard drive through the communication channel, there is a response latency before the data in interest is returned. Thus, the entire data throughput of the communication is limited because after one request is sent, the system idles and waits for at least the response latency to receive the desired data. The response latency causes a bandwidth limitation.

The embodiments disclosed herein involves establishing multiple virtual communication channels over a single communication channel. In one embodiment, multiple virtual channels are established by sending multiple data access requests during the response latency.

In one embodiment, there is a first data request for a first virtual drive and a second data request for a second virtual drive. Between the first data request and the second data request there is a time gap (Tg). The Tg is shorter than the response latency (T). In one embodiment, Tg is 0.5T and the communication bandwidth can be doubled. In one embodiment, the Tg is 0.33T and the communication bandwidth can be tripled. In yet another embodiment, the Tg is 0.25T and the communication bandwidth can be quadrupled, so on and so forth.

According to one embodiment, a computing system includes a computer executing an emulated operating system, the emulated operating system including a multichannel control unit; a first virtual drive accessible to the emulated operating system; a second virtual drive accessible to the emulated operating system; and a communication channel, the communication channel connecting the multichannel control unit and the first virtual drive and the second virtual drive. The multichannel control unit sends a first data access request to the first virtual drive through the communication channel, the multichannel control unit sends a second data access request to the second virtual drive through the communication channel. The time interval between the first and second data requests being sent is shorter than a virtual drive's response latency.

According to another embodiment, a computing system includes a processor, a machine readable memory accessible by the processor, and a communication channel connecting the computing system with a plurality of virtual drives (VDs). The machine readable memory stores instructions when executed cause the processor to perform following actions: receiving a first request to access a first VD of an emulated machine; creating a file handle for the first request; putting the first request in a queue; sending the first request to the first VD through the communication channel; sending a second request to a second VD designated by the second request through the communication channel, wherein the second VD has a response latency; wherein an interval between sending the first request and the second request is shorter than the response latency.

DETAILED DESCRIPTION

FIG. 1Ais a schematic diagram of the virtual multichannel communication system (hereinafter “system” as referring to the embodiment ofFIG. 1)100according to one embodiment of the disclosure. The system100includes client devices102,104, and106. The client devices102,104,106can be any personal device, e.g., desktop computer, laptop computer, cell phone, etc., that can communicate with a virtual machine150through physical and/or wireless connection.

The virtual machine150can include an emulated operating system (OS). The virtual machine150includes a multichannel control unit108. In one embodiment, the multichannel control unit108can be a physical machine with processor and accessible machine readable memory. In another embodiment the multichannel control unit108can be software implemented logical functions. The multichannel control unit108includes a virtual drive creation control110and virtual drive access control112.

The client devices102,104,106can request creation of a virtual drive. The multichannel control unit108receives the request and use the virtual drive creation control110to create the virtual drive as well as the communication channel to the drive.

As shown inFIGS. 1A and 1B, the virtual drive creation control110can create virtual drive A114and its corresponding one or more virtual communication channels126; virtual drive B116and its corresponding one or more virtual communication channels128; virtual drive C118and its corresponding one or more virtual communication channels130; virtual drive Z124and its corresponding one or more virtual communication channels134; and/or any virtual drive120and its corresponding one or more virtual communication channels132. For each virtual drive (e.g., A114, B116, C118, . . .120, Z124), a plurality of virtual channels (e.g.,126,128,130,132,134) can be set up.

The virtual drives114,116,118,120,124and their respective one or more virtual communication channels126,128,130,132,134can be created together or separately all at once or on demand. In one embodiment, the virtual communication channels126,128,130,132,134are implemented over a single non-virtual communication channel. That says, in the embodiment, the virtual communication channels126,128,130,132,134are logical and are implemented over a single physical (the term “physical” is used in contrast with virtual) communication channel that can be wired or wireless.

In one embodiment, the virtual drive creation control110receives a request from a client device102,104,106to create a virtual drive on virtual machine150. In one embodiment, a user of a client device102,104,106may want to create a virtual drive with specific access controls. For example, a user may want to limit the access to the virtual drive to him/herself. In another example, a user may want to limit the access to the virtual drive to a community-of-interest, e.g., colleagues in the same office or departments, members of a team, etc. Thus, the request may include parameters for setting up the access control. These access control parameters may include the identities of the user/client devices that can access the virtual drives, the capacity of those user/client devices, e.g., read, write, delete, etc.

In one embodiment, according to the request, the virtual drive creation control110creates a partition on one or more physical hard drives accessible by the virtual machine150. This partition provides machine readable memory to support the functionalities of the virtual drive to be created. In one embodiment, this partition can be hosted on a single hard drive. In another embodiment, this partition can be hosted on a plurality of hard drives, e.g., cloud storage. In one embodiment, this partition has a fixed size. In another embodiment, this partition is scalable.

In one embodiment, the virtual drive creation control110creates an identifier, e.g., an access key, for the virtual drive. This identifier may include a name, a serial number, a logical identifier, an access key, etc. The access key can also be used for encryption/decryption functionalities to establish an encrypted communication between a client and a specific drive. This access key may be private to the client. In another embodiment, this access key can be public. Yet, in another embodiment, the access key can be shared among a community-of-interest.

In one embodiment, the virtual drive creation control110establishes one or more virtual communication channels for the virtual drive newly created. The virtual communication channels for the virtual drive are established, at least in part, using the identifier, e.g., the access key. In one embodiment, this means the information conveyed on the specific virtual channels is encrypted using the identifier, e.g., the access key. In another embodiment, this means when requesting information from the virtual drive, the request must include the access key.

As shown inFIG. 1A, the virtual drive access control112may send a plurality of requests156,158,160,162,164over the plurality of virtual channels130specific for virtual drive C118. The plurality of requests156,158,160,162,164are sent through different timings. The first request156is sent on T1. The second request158is sent on T2. The third request160is sent on T3. The fourth request is sent on T4. The fifth request is sent on T5. It is specifically noted that the virtual drive access control112can send a plurality of access requests to any of the virtual drives, not limited to virtual drive C.FIG. 1Ais merely an example of an embodiment, and shall not be construed as limiting the scope of the claims in any manner.

In one embodiment, the virtual drive C has a response time (T) which is a time period required for virtual drive C118to respond to an access request. As previously mentioned, the plurality of requests156,158,160,162,164are sent through different timings (The first request156is sent on T1. The second request158is sent on T2. The third request160is sent on T3. The fourth request is sent on T4. The fifth request is sent on T5. In one embodiment, the time gap between T2and T1is shorter than response time (T), which can be expressed as T2−T1≤T. Similarly, the time gap between T3and T2is shorter than response time (T): T3−T2≤T; the time gap between T4and T3is shorter than response time (T): T4−T3≤T; the time gap between T5and T4is shorter than response time (T): T5−T4≤T. In another embodiment, as T1is earlier in time than T2, T2earlier in time than T3, T3earlier in time than T4, T4earlier in time than T5, and the time gap between T5and T1is shorter than the response time, such that T5−T1≤T.

FIG. 1Bis an embodiment, showing virtual drive access control112can send a plurality of requests over channels126to virtual drive A, over channels128to virtual drive B, over channels130to virtual drive C, over channels132to any drive, and over channels134to drive Z.

In one embodiment, when the virtual channels126,128,130,132,134are established, each of them can have a plurality of access keys generated. For example, a master key if presented by the requestor, the requestor can have full capacity to the particular virtual drive114,116,118,120,124, e.g., read, write, delete, edit, etc. In another example, a read only key when presented by the requestor, the requestor can only read the files on the virtual drive. In another embodiment, a read-and-write key when presented by the requestor, the requestor can read and write the file on the virtual drive.

The virtual drive access control112assists the client devices102,104, and106to access data stored in the virtual drives114,116,118,120,124. The drive access control102receives the data access request and access the intended virtual drive and the intended data hosted on the drive. Various methods, such as method400shown inFIG. 4and method500shown inFIG. 5can be used to access the data hosted on the virtual drives114,116,118,120,124.

FIG. 2A(Prior Art) is an illustration of a traditional communication scheme200to one or more virtual drives hosted on a single hard drive known in the art. The communication scheme200is shown as an example of using a single physical communication channel. The term “physical communication channel” refers to non-virtual communication channel. The physical communication channel can be wired, wireless, or a combination thereof.

As shown inFIG. 2A, a data access request210to drive A is sent at the time point on the timeline205. There is a time latency T230between the time of the request210being sent and a response215being received. The time latency T230can be caused by various reasons, e.g., data connection quality, instruction processing speed, CPU frequency, hard drive data access speed (e.g., disk drive or solid state drive), etc.

FIG. 2Ashows an over simplified scenario where the second data access request220to drive A is placed at the same time as the response215from drive A to the first data access request210. In a realistic scenario, there should a small latency between the placement of the second data request220and the response215to the first request210. However, for the purpose of the embodiment shown inFIG. 2A, the small latency between215and220can be ignored.

After the second data access request220is placed, there is another latency T235before receiving the corresponding response225. Latency T230and latency T235can be the same or different. As shown inFIG. 2A, during the latency T230and latency T235, there is no data communication. During the latency T230and latency T235, the entire communication idles and waits for the virtual drive to respond. Thus, inFIG. 2A, the data throughput, also known as communication bandwidth, is limited by the response latency.

FIG. 2Bis an illustration of a virtual multichannel communication scheme240to one or more virtual drives hosted on a single hard drive according to one embodiment of the disclosure. In contrast toFIG. 2A(prior art),FIG. 2Bshows an embodiment of the disclosure that establishes a plurality of virtual channels that utilizes the response latency period to send multiple data access requests and receives multiple response through a single non-virtual communication channel.

In the embodiment ofFIG. 2B, there are four virtual channels: VC1, VC2, VC3, and VC4, each providing a communication path to a same virtual drive. This single virtual drive can be any virtual drive, e.g., virtual drive A114, virtual drive116, virtual drive118, . . .120, or virtual drive124.

In one embodiment, a multichannel control unit (MCU) may send a first data access (Req-1)352via the first virtual channel (VC1) to the single virtual drive. There is a latency T368before the virtual drive respond at358. During the latency T368, the MCU may send a second data access request (Reg-2)354to the virtual drive through the second virtual channel (VC2); and a third data access request (Reg-3)356to the virtual drive through the third virtual channel (VC3). Thus, during the latency368T, three requests (i.e., Req-1, Req-2, and Req-3) are sent, instead of only one as inFIG. 2A. The bandwidth ofFIG. 2Bis at least three times ofFIG. 2A, assuming the response latencies230and368are the same. In one embodiment, all the virtual channels are established over a single non-virtual channel.

A request through VC2may have a latency T370between the request354and the response362. A request through VC3may have a latency T372between the request356and the response364. The latency T368, latency T370, latency T372, and latency T374are independent from each other, e.g., they can be the same and/or they can be different.

There is a first time gap376between the first data request (Req-1)352and the second data request (Req-2)354. The first time gap376is shorter than the time latency T368. There is a second time gap378between the second data request (Req-2)354through VC2and the third data request (Req-3)356through VC3. The second time gap378is shorter than the time latency T368. There is a third time gap380between the third data request (Req-3) through VC3and a fourth data request (Req-4) through VC4. The time gap380is shorter than the time latency T368. Similarly shown inFIG. 2B, time gap378, time gap380, time gap382are shorter than time latency370. Time gap380, time gap382, time gap384are shorter than time latency372. Time gap382, time gap384, and time gap384are shorter than time latency374.

FIG. 2Cis an illustration of a virtual multichannel communication scheme250to different virtual drives hosted on a single hard drive according to one embodiment of the disclosure. In contrast toFIG. 2A(prior art),FIG. 2Cshows an embodiment of the disclosure that establishes a plurality of virtual channels that utilizes the response latency period to send multiple data access requests and receives multiple response through a single non-virtual communication channel.

In the embodiment ofFIG. 2C, there are three virtual channels, each providing a communication path to one or more virtual drives. In one embodiment, a multichannel control unit (MCU) may send a data access request252to drive A through the first virtual channel. There is a latency T268before Drive A responds at258. During the latency T268, the MCU may send a second data access request254to Drive A through the second virtual channel; and a third data access request256to Drive A through the third virtual channel. Thus, during the latency268T, three requests are sent, instead of only one as inFIG. 2A. The bandwidth ofFIG. 2Bis at least three times ofFIG. 2A. In one embodiment, all the virtual channels are established over a single non-virtual channel.

A request through channel B may have a latency T270between the request254and the response262. A request through channel C may have a latency T272between the request256and the response264. The latency T268, latency T270, latency T272, and latency T274are independent from each other, e.g., they can be the same and/or they can be different.

There is a first time gap276between the first data request252and the second data request254. The first time gap276is shorter than the time latency T268. There is a second time gap278between the second data request254through channel B and the third data request256through channel C. The second time gap278is shorter than the time latency T268. There is a third time gap280between the data request through channel C and a second data request through channel A. The time gap280is shorter than the time latency T268.

In one embodiment, the drive A, drive B, and drive C are all hosted on a single physical hard drive, with a single physical communication channel. The embodiment ofFIG. 2Bshows the implementation of, at least, three virtual channels implemented over the single physical channel and increased the communication bandwidth by three times. It is noted thatFIG. 2Bis illustrative only. With sufficiently short time gap between two data requests (e.g., time gap276,278,280), and/or sufficiently short time gap between two data responses (e.g., time gap282,284,286) compared to the response latency (e.g.,268,270,272,274), it is possible to infinitely increase the communication bandwidth by implementing infinite numbers of virtual channels over a single non-virtual channel.

FIG. 3is a method300of creating one or more virtual channels to one or more virtual drives according to one embodiment of the disclosure.

The method300includes305receiving, by a processor of the multichannel control unit (MCU), a request to create a virtual drive on an emulated machine, wherein the request includes an access control. Method300can be applied to the MCU108. In one embodiment, the MCU108receives a request from a client device102,104,106to create a virtual drive on virtual machine105. In one embodiment, a user of a client device102,104,106may want to create a virtual drive with specific access controls. For example, a user may want to limit the access to the virtual drive to him/herself. In another example, a user may want to limit the access to the virtual drive to a community-of-interest, e.g., colleagues in the same office or departments, members of a team, etc. Thus, the request at305may include parameters for setting up the access control. These access control parameters at305may include the identities of the user/client devices that can access the virtual drives, the capacity of those user/client devices, e.g., read, write, delete, etc.

The method300includes310creating, by the MCU, a partition on one or more physical hard drives accessible by the emulated machine, the partition providing machine readable memory to support functionalities of the virtual drive. In one embodiment, according to the request, the MCU108creates a partition on one or more physical hard drives accessible by the virtual machine150. This partition provides machine readable memory to support the functionalities of the virtual drive created. In one embodiment, this virtual drive is a file hosted on the physical hard drive. In one embodiment, this partition can be hosted on a single hard drive. In another embodiment, this partition can he hosted on a plurality of hard drives, e.g., cloud storage. In one embodiment, this partition has a fixed size. In another embodiment, this partition is scalable based on demands.

The method300includes315creating, by the MCU, an identifier, e.g., an access key, a serial number, etc., for the virtual drive. In one embodiment, the MCU108creates an identifier, e.g., an access key, for the virtual drive. This identifier may include a name, a serial number, a logical identifier, an access key, etc. The access key can also be used for encryption/decryption functionalities to establish an encrypted communication over the virtual communication channel between a client and a specific drive. This access key may be private to the client. In another embodiment, this access key can be public. In yet another embodiment, the access key can be shared among a community-of-interest.

At320, the MCU108establishes a virtual communication channel for the virtual drive newly created. The virtual communication channel for the virtual drive is established, at least in part, using the identifier, e.g., the access key. In one embodiment, this means the information conveyed on the specific virtual channel is encrypted using the identifier, e.g., the access key. In another embodiment, this means when requesting information from the virtual drive, the request may include the access key. In one embodiment, a system includes multiple virtual communication channels. Each virtual channel has a specific access key associated with the virtual channel. A request for data access must specify the access key for the intended virtual drive.

In one embodiment, when a virtual channel is established, there can be a plurality of access keys associated with the channel granting different level of accesses. For example, a master key if presented by the requestor, the requestor can have full capacity to the virtual drive, e.g., read, write, delete, edit, etc. In another example, a read only key when presented by the requestor, the requestor can only read the files on the virtual drive. In another embodiment, a read-and-write key when presented by the requestor, the requestor can read and write the file on the virtual drive, but cannot delete or edit existing files.

FIG. 4is a method400to access a plurality of virtual drives through a plurality of virtual channels with a first-in first-out queue according to one embodiment of the disclosure.

The method400includes405receiving, by a processor of a multichannel control unit (MCU), a first request to access a first virtual drive (VD) of an emulated machine, the first request includes a first identifier of the VD, a first file indicator, an action indicator. In one embodiment, the client devices102,104,106may initiate a data access request to the MCU. In one embodiment, the request is specific to a first drive. This request may include a first identifier of the VD, a file indicator referring to the file-in-interest, and an action identifier specifying whether the client want to read, write, delete, or edit the file-in-interest.

The method400includes410creating a file handle for the first request, by the MCU, the file handle including a physical partition reserved for receiving data, the first identifier of the VD, the first file indicator, and the action indicator. In one embodiment, the file handle is a temporary storage space to receive the data returned from the first virtual drive.

The file handle may include metadata portion and received data portion. The metadata portion may include the first identifier of the VD, the first file indicator, and the action indicator specified in the request at405. The received data portion can be a fixed partition or a scalable partition created to receive the data returned from the VD. The file handle can be created on any machine readable memory accessible by the MCU, e.g., RAM or hard drive. In one embodiment, after the data is received from the VD, the MCU sends the entire file handle back to the requester. In another embodiment, the MCU sends just the received data portion to the requester.

The method400includes415putting, by the MCU, the first request into a queue, wherein the first request takes a lower priority over a second request if the second request was put into the queue before the first request. At415, the queue is a first-in first-out queue. Thus, if the second request is already in the queue before the first request, the second request takes priority over the first request. This means the second request will be processed before the first request. It is possible for method400to include a different type of queue that prioritizes the requests based on different factors, not just the time of arriving the queue.

The method400includes420sending, by the MCU, the second request to a second VD designated by the second request, wherein the second VD has a response latency T, the response latency T is a time period between the time the second request is sent by the MCU and corresponding data is received by the MCU. Because the queue is first-in, first-out, the second request which arrived at the queue earlier will be processed before the first request. The second request is a request to access a drive via a second virtual channel. The virtual drive has a response latency T. The first response will be sent during the latency T of the second virtual drive. This means the time gap Tg between the second request and the first request is shorter than the latency T of the second virtual drive. In one embodiment, the first request and the second request are sent over a single non-virtual communication channel.

The method400includes425sending, by the MCU, the first request, wherein a time interval, e.g., time gap Tg, between sending the second request and the first request is shorter than the response latency T. At425, the concept is similar to the embodiment ofFIG. 2B. It is possible to send a plurality of requests to one or more virtual drives during the response latency T period.

FIG. 5is a method500to access a plurality of virtual drives through virtual communication channels with a prioritized queue according to one embodiment of the disclosure.

The method500includes505receiving, by a processor of a multichannel control unit (MCU), a first request to access a first virtual drive (VD) of an emulated machine, the first request includes a first identifier of the VD, an access priority, a first file indicator, an action indicator. In one embodiment, the client devices102,104,106may initiate a data access request to the MCU. In one embodiment, the request is specific to a first drive. This request may include a first identifier of the VD, a file indicator referring to the file-in-interest, and an action identifier specifying whether the client want to read, write, delete, or edit the file-in-interest.

At505, the request includes an access priority. This access priority allows a client or a system to prioritize the access, especially when there are multiple requests lining up in a queue. In one embodiment, the access priority may be set according to the importance of the task. In another embodiment, the access priority may be set according to the requestor's membership level, e.g., different level of subscription fees.

In one embodiment, the access priority are in three levels: low, medium, high. The data access request with high priority will be processed before medium and low priority. The data access request with medium priority will be processed before low priority.

The method500includes510creating a file handle for the first request, by the MCU, the file handle including a physical partition reserved for receiving data, the first identifier of the VD, the first file indicator, and the action indicator. In one embodiment, the file handle is a temporary storage space to receive the data returned from the first virtual drive.

The file handle may include metadata portion and a received data portion. The metadata may include the first identifier of the VD, the first file indicator, and the action indicator specified in the request at405. The received data portion can be a fixed partition or a scalable partition created to receive the data returned from the VD. The file handle can be created on any machine readable memory accessible by the MCU, e.g., RAM or hard drive. In one embodiment, after the data is received from the VD, the MCU send the entire file handle back to the requester. In another embodiment, the MCU send just the received data portion to the requester.

The method500includes515lining up, by the MCU, the first request into a queue according to the access priority, wherein a request with a higher access priority is processed before a request with a lower access priority, wherein among a group of requests with a same access priority, a request arrived earlier at the queue will be processed earlier than a request arrived later, wherein a second request either has a higher priority over the first request or the second request arrived earlier at the que than the first request.

At515, the queue is a prioritized queue. Requests are processed according to their designated access priority. Requests with the same priority is processed first-in first-out. Thus, if the second request has a same access priority level and is already in the queue before the first request, then the second request takes priority over the first request.

The method500includes520sending, by the MCU, the second request to a VD via a second virtual channel designated by the second request, wherein the VD has a response latency T, the response latency T is a time period between the time the second request is sent by the MCU and corresponding data is received by the MCU. As in515, because the second request either has a higher access priority or the second request arrived at the queue earlier than the first request. Thus, the second request will be processed before the first request. The second request is a request to access the virtual drive. The virtual drive has a response latency T. The first response will be sent during the latency T of the second virtual drive. This means the time gap Tg between the second request and the first request is shorter than the latency T of the second virtual drive. The two concurrent requests may be issued to the same VD or two different VDs via two different virtual channels.

The method500includes525sending, by the MCU, the first request, wherein a time interval, e.g., time gap Tg, between sending the second request and the first request is shorter than the response latency T. At425, the concept is similar to the embodiment ofFIG. 2B. It is possible to send a plurality of requests to one or more virtual drives during the response latency T period.

FIG. 6illustrates a computer network600for obtaining access to database files in a computing system according to one embodiment of the disclosure. The system600may include a server602, a data storage device606, a network608, and a user interface device610. The server602may also be a hypervisor-based system executing one or more guest partitions hosting operating systems with modules having server configuration information. In a further embodiment, the system600may include a storage controller604, or a storage server configured to manage data communications between the data storage device606and the server602or other components in communication with the network608. In an alternative embodiment, the storage controller604may be coupled to the network608.

In one embodiment, the user interface device610is referred to broadly and is intended to encompass a suitable processor-based device such as a desktop computer, a laptop computer, a personal digital assistant (PDA) or tablet computer, a smartphone or other mobile communication device having access to the network608. In a further embodiment, the user interface device610may access the Internet or other wide area or local area network to access a web application or web service hosted by the server602and may provide a user interface for enabling a user to enter or receive information.

The network608may facilitate communications of data between the server602and the user interface device610. The network608may include any type of communications network including, but not limited to, a direct PC-to-PC connection, a local area network (LAN), a wide area network (WAN), a modem-to-modem connection, the Internet, a combination of the above, or any other communications network now known or later developed within the networking arts which permits two or more computers to communicate.

FIG. 7illustrates a computer system700adapted according to certain embodiments of the server602and/or the user interface device710. The central processing unit (“CPU”)702is coupled to the system bus704. The CPU702may be a general purpose CPU or microprocessor, graphics processing unit (“GPU”), and/or microcontroller. The present embodiments are not restricted by the architecture of the CPU702so long as the CPU702, whether directly or indirectly, supports the operations as described herein. The CPU702may execute the various logical instructions according to the present embodiments.

The computer system700may also include random access memory (RAM)708, which may be synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), or the like. The computer system700may utilize RAM708to store the various data structures used by a software application. The computer system700may also include read only memory (ROM)706which may be PROM, EPROM, EEPROM, optical storage, or the like. The ROM may store configuration information for booting the computer system700. The RAM708and the ROM706hold user and system data, and both the RAM708and the ROM706may be randomly accessed.

The computer system700may also include an I/O adapter710, a communications adapter714, a user interface adapter716, and a display adapter722. The I/O adapter710and/or the user interface adapter716may, in certain embodiments, enable a user to interact with the computer system700. In a further embodiment, the display adapter722may display a graphical user interface (GUI) associated with a software or web-based application on a display device824, such as a monitor or touch screen.

The I/O adapter710may couple one or more storage devices712, such as one or more of a hard drive, a solid state storage device, a flash drive, a compact disc (CD) drive, a floppy disk drive, and a tape drive, to the computer system700. According to one embodiment, the data storage712may be a separate server coupled to the computer system700through a network connection to the I/O adapter710. The communications adapter714may be adapted to couple the computer system700to the network608, which may be one or more of a LAN, WAN, and/or the Internet. The user interface adapter716couples user input devices, such as a keyboard720, a pointing device718, and/or a touch screen (not shown) to the computer system700. The display adapter722may be driven by the CPU702to control the display on the display device724. Any of the devices702-722may be physical and/or logical.

The applications of the present disclosure are not limited to the architecture of computer system700. Rather the computer system700is provided as an example of one type of computing device that may be adapted to perform the functions of the server602and/or the user interface device710. For example, any suitable processor-based device may be utilized including, without limitation, personal data assistants (PDAs), tablet computers, smartphones, computer game consoles, and multi-processor servers. Moreover, the systems and methods of the present disclosure may be implemented on application specific integrated circuits (ASIC), very large scale integrated (VLSI) circuits, or other circuitry. In fact, persons of ordinary skill in the art may utilize any number of suitable structures capable of executing logical operations according to the described embodiments. For example, the computer system800may be virtualized for access by multiple users and/or applications.

FIG. 8Ais a block diagram illustrating a server hosting an emulated software environment for virtualization according to one embodiment of the disclosure. An operating system802executing on a server includes drivers for accessing hardware components, such as a networking layer804for accessing the communications adapter814. The operating system802may be, for example, Linux or Windows. An emulated environment808in the operating system802executes a program810, such as Communications Platform (CPComm) or Communications Platform for Open Systems (CPCommOS). The program810accesses the networking layer804of the operating system802through a non-emulated interface806, such as extended network input output processor (XNIOP). The non-emulated interface806translates requests from the program810executing in the emulated environment808for the networking layer804of the operating system802.

In another example, hardware in a computer system may be virtualized through a hypervisor.FIG. 8Bis a block diagram illustrating a server hosting an emulated hardware environment according to one embodiment of the disclosure. Users852,854,856may access the hardware860through a hypervisor858. The hypervisor858may be integrated with the hardware858to provide virtualization of the hardware858without an operating system, such as in the configuration illustrated inFIG. 8A. The hypervisor858may provide access to the hardware858, including the CPU802and the communications adaptor814.