Site News  |   Monitor Keywords  |   Monitor Archive  |   Organizer  |   Account Info  |

Computer system with tunneling

Computer system with tunneling description/claims

The present application claims priority to U.S. provisional patent application No. 60/973,923, filed on Sep. 20, 2007; all of the foregoing patent-related document(s) are hereby incorporated by reference herein in their respective entirety(ies).

1. Field of the Invention

The present invention relates to computer systems with a computer running multiple operating systems and more particularly to computer systems with a computer running multiple containerized (see DEFINITIONS section) operating systems to be respectively used by multiple terminals (see DEFINITIONS section).

2. Description of the Related Art

It is conventional to have a computer, such as a modified PC desktop type host computer, which controls and operates a plurality of terminals. In fact, mainframe computers dating back to at least the 1970s operated in this way. More recently, each terminal has been given its own operating system and/or instance of an operating system. These kind of systems are herein called multi-terminal systems.

It is conventional to use a hypervisor to run multiple operating systems on a single computer. A hypervisor (or virtual machine monitor) is a virtualization platform that allows multiple operating systems to run on a host computer at the same time. Some hypervisors take the form of software that runs directly on a given hardware platform as an operating system control program. With this kind of hypervisor, the guest operating system runs at the second level above the hardware. Other hypervisors take the form of software that runs within an operating system environment.

Hypervisors have conventionally been used in multi-terminal systems where each terminal has a dedicated guest operating system on a single host computer. In these conventional multi-terminal systems, I/O devices communicate I/O data through the hypervisor to perform basic I/O operations (see DEFINITIONS section). More specifically: (i) data from the I/O devices is communicated through the hypervisor to the computing hardware of the host computer; and (ii) from the computing hardware (if any) is communicated through the hypervisor to the I/O devices. Because the hypervisor is a virtualization platform, this means that the I/O devices must be virtualized in the software of the hypervisor and/or the guest operating system so that the communication of I/O data through the hypervisor can take place.

FIG. 1 shows prior art computer system 100 including: desktop PC 102 and four terminals 104a, 104b, 104c and 104d. Desktop PC 102 includes: video card 110; I/O ports 112; CPU 114; host operating system (“OS”) 116; virtualizing middleware 118, four guest OS's (see DEFINITIONS section) 120a, 120b, 120c, 120d; and four guest applications 122a, 122b, 122c and 122d. Each terminal 104 includes: display 130 and keyboard-mouse-audio (“KMA”) devices 132. Host OS may be any type of OS, such as Windows, Apple or POSIX (see DEFINITIONS section). As shown in FIG. 1, host OS 116 runs at security level (see DEFINITIONS section) L0, which may be, for example in an x86 CPU architecture, Ring Zero. This means that host OS 116 exchanges instructions directly with CPU 116 in native form (see DEFINITIONS section).

The guest OS's 120a, 120b, 120c, 120d are used to respectively control the four terminals 104a, 104b, 104c, 104d. This means that the four guest OS's: (i) control the visual displays respectively shown on displays 130a, 130b, 130c, 130d; (ii) receive input from the four keyboards 132a, 132b, 132c, 132d; (iii) receive input from the four mice 132a, 132b, 132c, 132d; and (iv) control audio for the four audio output devices (for example, speakers, headphones) 132a, 132b, 132c, 132d. The four guest OS's 120a, 120b, 120c, 120d are containerized virtual machines so that work by one user on one terminal does not affect or interfere with work by another user on another terminal. As shown in FIG. 1, they can respectively run their own application(s) 122a, 122b, 122c, 122d in an independent manner.

However, the four guest OS's are virtual machines, running at a security level 13, which is above the OS security level (see DEFINITIONS section) L0. For example, in an x86 architecture, the guest OS's 120a, 120b, 120c, 120d would be running at Ring Three. This is an indirect form of communication with the CPU 114. Furthermore, the instructions exchanged between the guest OS's and the CPU are virtualized by virtualizing middleware 118, which may take the form of a hypervisor or virtual machine manager (“VMM”). For example, some of the exchanged instructions relate to basic I/O operations. When the exchanged instructions are virtualized by virtualizing middleware 118, the instructions are taken out of their native form and put in a virtualized form. This virtualized form is generally a lot more code intensive than native form. This virtualization makes operations slower and more prone to error than similar exchanges between a host OS, running at the OS security level and the CPU.

It is conventional to run one type of operating system, buts still use application(s) written for an operating system of a different type. Some conventional systems for doing that will now be discussed.

FIG. 8 shows prior art computer system 140 including: CPU 142; POSIX operating system (OS) 144; and Berkeley Software Distribution (BSD) application 148. POSIX OS 144 includes a BSD socket (see DEFINITIONS section) 146 programmed to allow the BSD application 148 to run on the POSIX OS 144. However, systems according to the architecture of system 140 are not always easily achieved as will now be explained in connection with FIG. 9.

FIG. 9 shows a possible prior art computer system 150 including: CPU 152; Windows operating system (OS) 154; and LINUX application 148. Windows OS 154 includes a LINUX API 156 programmed to allow the LINUX application 158 to run on the Windows OS 154. This system 150 is denominated as “possible” prior art because it is a type of system that seems to be seldom, if ever, actually practiced. This may be due to difficulties in updating the LINUX API 156 to stay current with the underlying Windows OS 154 and/or overlying LINUX application 158, and/or difficulties involving proprietary code issues.

FIG. 10 shows prior art computer system 160 including: local computer 162; network 164 and POSIX application server computer 166. Local computer 162 includes: CPU 168; network interface card (NIC) 170; Windows operating system 172; and XMing module 174. POSIX application server computer 166 includes: CPU 178; network interface card (NIC) 186; POSIX operating system 180; and POSIX application 184. POSIX OS 184 includes a POSIX socket 182 programmed to allow the POSIX application 184 to run on the POSIX OS 180. System 160 overcomes the difficulties of running a POSIX (for example, LINUX) application by a user who is using a Windows operating system. The remote POSIX application server computer 186 can run the POSIX application(s) because it has the appropriate POSIX OS and socket(s). Inputs to this remote POSIX application(s) and outputs from this remote POSIX application are respectively sent and received through NIC's 170, 186 and network 164. The special Windows manager module XMing 174 at local computer 162 incorporates data received from the remote POSIX application server computer 166 as a window in the Windows display generated by Windows OS 172.

One disadvantage is that the inputs and outputs of the POSIX application(s) must be packetized and de-packetized by NIC's 170, 186 and sent through the switches of network 164. This makes the running of the POSIX application effectively slower and less reliable from the perspective of the user of local computer 162.

FIG. 11 shows system 188, which is a variation on system 160. Computer system 188 includes: local computer 189; video output 190; CPU 191; POSIX host OS 192; virtualizing middleware 193; Windows guest OS 194 and POSIX application 196. POSIX host OS 192 includes socket 197 for running POSIX application 196 right at the local computer 189. Instead of sending POSIX application output data back to XMing 195 through actual NIC's and the switches of an actual network, the output data of the POSIX application is instead sent through virtual network module 198 (including virtual switches) and virtual NIC 199 included in the virtualizing middleware 193. Once again, though this solution takes time both because of the de-packetizing/packetizing involved, and also because virtualization is a code-intensive process that causes relatively large instructions to be transmitted through the system to achieve the POSIX application effectively running on Windows operating system. It is also noted that other instructions (for example, I/O device related instructions) that must be exchanged between the Windows guest OS 194 and CPU 191 are also virtualized by the virtualizing middleware, which is a further disadvantage of prior art system 188.

Other publications potentially of interest include: (i) US published patent application 2008/0092145 (“Sun”); (ii) US published patent application 2006/0267857 (“Zhang”); (iii) US patent application 2007/0174414 (“Song”); (iv) Applica PC Sharing Zero Client Network Computing Remote Workstation powered by Applica Inc. (see www.applica.com website, cached versions 31 Jul. 2007 and earlier); (v) US patent application 2003/0018892 (“Tello”); (vi) US patent application 2007/0097130 (“Margulis”); (vii) US patent application 2008/0168479 (“Purtell”); (viii) U.S. Pat. No. 5,903,752 (“Dingwall”); (ix) US patent application 2007/0028082 (“Lien”); (x) US patent application 2008/0077917 (“Chen”); (xi) US published patent application 2007/0078891 (“Lescouet”); (xii) US published patent application 2007/0204265 (“Oshins”); (xiii) US published patent application 2007/0057953 (“Green”); (ix) US patent application 2004/0073912 (“Meza”); (x) US patent application 2007/0043928 (“Panesar”); and/or (xi) US patent application 2007/0174410 (“Croft”).

Description Of the Related Art Section Disclaimer: To the extent that specific publications are discussed above in this Description of the Related Art Section, these discussions should not be taken as an admission that the discussed publications (for example, published patents) are prior art for patent law purposes. For example, some or all of the discussed publications may not be sufficiently early in time, may not reflect subject matter developed early enough in time and/or may not be sufficiently enabling so as to amount to prior art for patent law purposes. To the extent that specific publications are discussed above in this Description of the Related Art Section, they are all hereby incorporated by reference into this document in their respective entirety(ies).

• Provisional Patent
• Utility Patent

• What Is a Patent?
• What Is a Trademark or Servicemark?
• What Is a Copyright?
• Patent Laws