WO2007032875A2 - Modular computer system and related methods - Google Patents

Abstract

A modular computer system is described. The computer system includes a plurality of Application Modules, an active module interconnection system, and shared system resources. Each module is a single unit that contains application programs and a processor and memory adequate to contain and execute the application. Shared system resources such as display, keyboard, mouse, storage and interfaces are available to the Application Modules via the module interconnection system. The Application Modules communicate with each other and the shared system resources via the module interconnection system. The module interconnection system includes an Administration Module and a switch. All Application Modules are connected to the Administration Module by a communication link and connected to the switch by zero or more data channels. The computer system functions without a centralized operating system.

Description

MODULAR COMPUTER SYSTEM AND RELATED METHODS

This application claims priority from U.S. Provisional Application No. 60/715,512, filed September 9, 2005. BACKGROUND OF THE INVENTION Field of the Invention

This invention relates to computer architectures, and in particular, it relates to a modular computer architecture and related devices and methods. Description of the Related Art Conventional computer architecture is centered around a CPU (with one or more processors) and an operating system that controls the computer's shared resources including input and display, file storage, etc.

Various computer systems have been described before where a processor is provided in a modular unit. For example, U.S. Patent No. 5,581,763, entitled "Secure architecture and apparatus using an independent computer cartridge", describes a "specialized computer architecture and apparatus having a specially selected portion contained within a special sealed cartridge, together called an Independent Computer Module (ICM). The ICM contains a fully functioning computer including: a CPU, RAM, ROM, a specialized memory switching means, and a communications port for providing a two-way communications link with a host computer, through a specialized interface. The host computer is fitted with a receptacle for holding the ICM, called an Interface Unit, which contains a matching interface, and a means for direct electrical connection to a communications port on the host computer. The ICM is inserted into the Interface Unit. The host computer contains a program for communicating with the ICM that provides ICM-based programs with host-software-controlled access to the host's various hardware resources such as mass data storage, keyboard input, and video display. The applications program within the ICM requests the services of a host function by sending a function command, and any needed data, over the communications link. The host computer responds by accomplishing the requested function, in a manner similar to the way a conventional operating system (such as MS-DOS) provides such services to an applications program running in the host memory. However in this case, the operating system program returns any required response to the ICM through the communications link." (Col. 5, line 62 - col. 6, line 20.) It can be seen that this system is still centered on a host computer with an operating system. U.S. Patent No. 5,608,608, entitled "Cartridge-based design for portable and fixed computers", describes a "computer system [which] includes a chassis and a cartridge having separate functional components that interface with one another over a common bus. The chassis includes a plurality of user interface modules, which are generally designed and packaged according to a particular application/work mode, each coupled to a first bus. The cartridge, on the other hand, includes components that can be shared among the various applications/work modes. Specifically, the cartridge has a core processor and memory coupled to a second bus, and at least one slot for housing a communication module that is coupled to the second bus." (Abstract.) The cartridge contains the processor, operating system and application programs of a conventional computer. In essence, this patent describes a way of sharing the same core processor among various docking station-like chassis.

U.S. Patent No. 6,029,183, entitled "Transferable core computer", describes a computer system having two structures, "a mobile core unit and an enclosure capable of enclosing and cooperating with the core unit. The core unit has all of the components of a general purpose computer except for a display and source of power. This core unit by itself is non-functional as a computer unless it is in electrical contact with the enclosure. The enclosure has several connector ports for attachment of peripherals to the system." (Abstract.) This system is similar to U.S. Patent No. 5,608,608 in concept. U.S. Patent No. 6,154,680, entitled "Control systems and methods utilizing object oriented hardware elements", describes "Computer-based industrial control systems and methods employing object oriented hardware elements. An object oriented hardware element may comprise a processor core coupled one side to a universal real-world interface circuit, and on the other side to an open bus interface. In a preferred embodiment, the open bus interface provides downloading software programming objects to the microprocessor core. A computer-based control system in accordance with the present invention may comprise a personal computer or central processing unit coupled to a communications network, at least one zone interface module coupled to the communications network and to an open bus, at least one zone device module coupled to the open bus and, if required, one or more zone processor modules coupled to the open bus. Software object may be downloaded from the personal computer or central processing unit to the various modules to achieve modular, exception-based, distributively intelligent (MEDI) I/O control within the system." (Abstract.) This is a distributed processing environment in which a central computer-based control system downloads software to the modules, which are used for industrial control. U.S. Patent No. 6,795,318, entitled "Portable modular electronic system", describes a "portable modular electronic system [which] comprises a controller module, at least one memory module; and at least one application module that are mechanically-connectable and disconnectable with respect to each other and include mating electrical connectors for communicating electrical signals between modules when the modules are mechanically connected." (Abstract.) In this system, the central controller module controls the system resources including the display and the user interface pad.

UK patent application No. GB 2381336A, entitled "Object-oriented heterogeneous multiprocessor platform", describes a system that includes "a plurality of executing units amongst which object methods are distributed, a run-time support, a shared memory for storing object data and which is accessible by the execution units and by the run time support, and an invocation network for carrying method invocation messages via interfaces between execution units and/or between the run-time support." (Abstract.) In this system, the execution units are slave processors to the overall controlling system processor. The system is designed to increase the processing power of the CPU.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a new computer architecture. Unlike the conventional CPU-centric architecture including the modular devices summarized above, a computer system according to embodiments of the present invention is "Application-centric", and is comprised of individual Application Modules connected by a high-speed message-passing system. Shared system resources of power, display, keyboard, mouse, storage, and interfaces such as network connections, USB connections, serial connections, parallel connections, etc. may also be implemented. A computer based on this architecture can be thought of as having two main parts: a collection of Application Modules, and the "box" (the system case) that contains the shared resources of the system. The system case provides power to all of the modules, as well as a means of communication between the modules.

Additional features and advantages of the invention will be set forth in the descriptions that follow and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims thereof as well as the appended drawings. To achieve these and other advantages and in accordance with the purpose of the present invention, as embodied and broadly described, the present invention provides a modular computer system including a module interconnection and one or more application modules connected to the module interconnection system. Each application module includes, within a single physical unit, interface hardware for interfacing with the module interconnection, application programs, and a processor and memory for executing the application programs. The plurality of application modules include zero or more system resource modules. The application modules execute their respective application programs autonomously and asynchronously, and communicate with each other via the module interconnection.

In another aspect, the present invention provides a method for carrying out modular computing, including the steps of connecting one or more application modules to a module interconnection, each application module including, within a single physical unit, interface hardware for interfacing with the module interconnection, application programs, and a processor and memory for executing the application programs; the application modules executing their respective application programs autonomously and asynchronously; and the application modules communicating with each other via the module interconnection.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 schematically illustrates a modular computer system according to an embodiment of the present invention. Figure 2 illustrates an Application Module of the computer system of Fig. 1.

Figure 3(a) illustrates a module interconnection of the computer system of Fig. 1. Figure 3(b) illustrates another module interconnection of the computer system of Fig. 1.

Figures 4(a)-4(d) illustrate various Application Modules for providing compatibility with existing applications.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In this disclosure, a computer system according to embodiments of the present invention is referred to as "TEA", which stands for "The Embedded Application". The term TEA should be understood to be merely a convenient name used to refer to the computer architecture and the related devices, systems and methods.

The TEA architecture can be thought of as a re-arrangement of the hardware and software components present in the traditional personal computer (PC). This rearrangement allows for a better implementation of the functions necessary for the operation of the various applications that comprise a PC system. Instead of the traditional CPU-centric system in which a single CPU and operating system controls every application and device in the system, a computer based on TEA is "Application-centric" and is comprised of individual CPUs and devices connected by a high-speed message-passing system. A computer based on the TEA architecture can be thought of as having two main parts: a collection of Application Modules, and the "box" (the system case) that contains the shared resources of the system. The Application Modules, which run the programs, are inserted into the box in various ways, which may include being mounted inside like conventional peripheral cards, or plugged into slots like PCMCIA cards, or as USB-like devices. The system case provides power to all of the modules, as well as a means of communication between them and the shared system resources including display, keyboard, mouse, storage, and interfaces such as network connections, USB connections, serial connections, parallel connections, etc.

In a TEA computer, all application programs run on their own dedicated Application Modules, and a high-speed message passing system is used to connect them together and to the system resources. Through this system, common interface functions such as display, keyboard, and interfaces can be shared among the Application Modules within a system. (In the present disclosure, shared functionalities such as display, keyboard, mouse, and interfaces are referred to as "system resources" or "shared resources". The terms "application(s)" and "application module(s)" are often used to refer to modules other than those for the system resources, but are also used sometimes in a more general sense to refer to all modules including the system resources modules. The meaning should be clear from the context.) Each application module runs autonomously and asynchronously (i.e. their execution can proceed independently, and a process may be started before another process has finished). The underlying TEA interconnection system provides a flexible, high-speed communications medium between Application Modules and the shared system resources. The physical layout of a TEA computer system depends on the requirements of the end user and on the desired form factor of the system itself. The core concept of the TEA architecture is to provide a simple means for communications between Application Modules, which have their own dedicated processing hardware. Referring to Fig. 1, a TEA computer system 10 includes a TEA module interconnection 11 and a plurality of Application Modules 12a-d. Four Application Modules are shown as examples: an "office" Application Module 12a (which may be, for example, a word processing application, a spreadsheet application, etc.), a storage module 12b (which may include one or more hard drives or other forms of non- volatile storage), a user interface 12c (which may be composed of separate desktop module, video module, and mouse/keyboard module, or one combined module that performs these functions as illustrated in Fig. 1), and a network interface 12d (which may be composed of separate network module and browser and/or email module, or one combined module that performs these functions as illustrated in Fig. 1). Each Application Module contains its own processing hardware and software. The module interconnection 11 and the Application Modules 12a-d may be housed in a system case 13, which also contains a power supply 14. A display device 15, a keyboard 16a and mouse 16b are shown in this example as being connected to a single module 12c; alternatively, separate display and input modules may be used and the display and input devices may be connected to these separate modules or combined with other modules.

There are typically several system-level functions that are preferably shared among all Application Modules, such as the user interface (desktop), keyboard and mouse, mass storage, and network interfaces. In these instances, dedicated TEA module(s) (e.g. 12c, 12d in Fig. 1) handles the functionality, and shares resources as needed among the Application Modules. For instance, the Desktop Module controls the size and position of an Application's window on the screen but depends on that Application Module to provide the actual data to be displayed. The keyboard and mouse module sends messages to the appropriate Application Modules whenever keys are pressed or the mouse is moved.

Connecting all of the modules together is the TEA interconnection system 11, which provides high-speed, secure communications between all of the Application Modules in a TEA system. In this disclosure, the TEA interconnection system is sometimes also referred to as the TEA interconnection bus or the TEA bus. It should be understood, however, that the TEA interconnection is not a "bus" in the true engineering sense of the word, and the word "bus" is used in this context merely for convenience. The "slot" for removable modules can be thought of as a physical bridge implementing the aforementioned connection scheme to the fixed connector of the removable module. Some modules can use wireless connections to the system and thus do not even require physical wires and connectors.

Just as the TEA Computer Architecture distributes hardware among the Application Modules, the architecture separates the software functionality traditionally performed by an operating system. System resources are shared via the TEA bus. The traditional operating system functions are distributed in separate hardware modules.

The Application Module's interface to the rest of the system is handled completely through the TEA interconnect system. An application can send and receive messages to other modules when necessary, for such functions as keyboard input, network communication, mass storage, etc. This bus is merely a means of sharing system resources; an Application Module vendor may choose to use any hardware architecture within the module that best fits the application's requirements.

As shown in Fig. 2, the hardware of an Application Module 12 includes two sections: the hardware necessary to run the application (the application hardware) 121, and the hardware interface to the TEA system 122 (which includes interface hardware 126 and optionally hot-swap hardware 127, described in more detail below.) Additionally (not shown), Application Modules that control external devices such as display, keyboard and mouse have interface hardware for connecting to the external devices. The application hardware typically includes one or more CPU 123 along with RAM and/or ROM 124. Some modules may also include non-volatile storage 125 (hard disk, FLASH, etc.). Application Modules utilize their own dedicated CPU and support hardware to perform the processing necessary for the applications. The processing power of the CPU and the type and amount of memory will depend on the needs of the application. For example, a browser application will not need as fast a CPU or as much memory as a CAD Application Module. Display-oriented applications may have graphics accelerators; databases may have embedded disk drives; spreadsheets may have math co-processors. The application hardware is dedicated and specific to the application itself. In this manner, the application defines the capability of the hardware, instead of the hardware defining what applications can be run. CPU. Application vendors may choose whatever processor technology best suits the application. A wide range of processors are available and more will be developed. The vendor may choose a CPU to best match the requirements of an application.

Memory. Since the memory of an Application Module is utilized only in the module itself, the vendor may choose the exact memory technology and capabilities that fit the needs of the application. Memory prices are low enough and storage sizes large enough that it is cost effective to put dedicated DRAM directly on the module. High-performance modules can also implement cache memories, choosing the best size and refresh algorithms based on application requirements. ROM. Application modules may utilize FLASH memory to provide the Read Only Memory functionality required by the module. In a manner similar to conventional BIOS, this ROM can provide the "boot" code for the module upon power up. However, unlike conventional systems, the module is in complete control of the ROM and thus it can be optimized for the application. For example, the ROM could contain the actual application code if desired, or just contain "loader" code to load the application from some system resource. The use of FLASH memory also provides for the capability of a TEA module to upgrade the application code via remote accesses or by downloaded "files." If desired, the Application Module vendor can provide the ability to change the module's FLASH memory in much the same manner that some PC vendors allow a user to upgrade the system BIOS memory. For high-security modules this feature may not be desirable - the increase in security of pure ROM code could outweigh the convenience of updatable Flash memory.

Persistent Memory. Many applications will require some form of persistent memory. Traditionally this is available by using some form of disk drive, such as hard drive and floppy drive, or FLASH memory. TEA module designers are free to choose devices that best fit the application. Given the small size and low cost of current disk drive technology, it is easy enough to provide a hard disk directly on a module (as seen by the Apple iPod™ technology). Lower cost options such as FLASH or battery-backed CMOS are also available depending on the storage requirements. An alternative is off-module storage. Storage Modules (described in more detail below) can be used in a system to provide larger storage capabilities than are available on individual modules. Another alternative is network storage servers. The TEA architecture can accommodate the use of traditional bulk storage methods, including tape drive libraries, CDROMS, etc. TEA Interface. The interface hardware (TEA interface) 126 is the actual connection of the module to the rest of the system. On the module, this connection may take the form of any physical connection scheme desired by the Module/Application vendor, such as connector, cable, or wireless. Much like the Ethernet stack, this may be considered a Layer 1 Physical connection. The TEA Interface is described in more detail later. Module Physical Formats. The Application Module is not dependent upon any particular physical format or "footprint". The following is a non-exclusive list of possible module physical forms, along with representative applications and/or features that may be conveniently associated with that form. 1. Thumb format (similar to USB sticks) Email

"Customized" browser- only the features needed

IM (Instant Messenger)/Chat

5 2. iPod(TM)-style - All of above, plus Music/video Simple display

3. Cell phone

0 Full cell phone functionality

Better display Contact list, etc.

4. PDA (Personal Digital Assistant) or large PDA 5 Better display

Stylus input Keyboard input

5. Small Tablet

>0 Road warrior functionality

Better Display Handwriting

6. PCMCIA

>5 Targeted at individual desktop applications where flexibility but not portability is needed

7. Peripheral Card - PCI card style

More power, installed within case 50

8. High-power

For scientific or engineering tasks Full computer with lots of CPU, memory, disk Linux clustering within single case )5

9. Legacy Modules

Fully compatible with legacy systems since it is actual hardware/bios/OS Windows, Linux, DOS, Apple, TRS-80

tO The TEA Computer Architecture also lends itself to implementation in various scenarios beyond the traditional desktop PC configuration. For example, a thin client application on a dedicated module could communicate with a traditional centralized application server. Furthermore, the centralized server could itself be based on the TEA architecture, with multiple Application Modules providing computational resources to

15 distributed users. In this case, the distributed network would simply become an extension of the internal message-passing Module Interconnection bus, offering flexible configuration and efficient operation.

Some components of the TEA system are described in further detail below. TEA Module Interconnection. All Application Modules and shared system resources of a TEA system communicate via the TEA module interconnection, a high-speed communications scheme. The actual physical medium can vary depending on the requirements of the system and Application Modules. The TEA interconnect scheme may include static or dynamic routing or both. Data and messages are sent using data packets that are directed to specific modules based on the configuration and security settings of the system.

Within a desktop or server case, Application Modules can be connected to each other with a fixed back plane or with cables similar to the SATA disk cables in use today. Those modules that are removable can utilize a PCMCIA-type format for insertion into slots in the case. And for small modules a USB-like connection can be used. Portable modules can use wireless connections such as Bluetooth. Other communication schemes may be used, including those that may be developed in the future.

As illustrated in Fig. 3 (a), the TEA module interconnection 11 includes a TEA Switch 111 and an Administration Module 112. The Administration Module 112 is necessary for the system to function, and all other modules in the system have a guaranteed communications link to the Administration Module (known as the Administration Channel 113.) In practice the Administration Channel may be implemented as either a dedicated communications link or as part of a shared communications link. In addition, modules may have zero or more Data Channels 114 connected through the Switch 111 to be used for high-speed inter-module messages. The Switch, being a dedicated piece of hardware, may be incorporated onto the Administration Module, but may also be implemented separately on another part of the system such as a dedicated module or embedded circuit board.

Data Channels. For maximum design and performance flexibility, the communications pathway of the TEA architecture is based on high-speed communications channels. In a typical system the Data Channels 114a-d are implemented via cables or a backplane that connect the Application Modules 12a-d and the Switch 111. The actual physical implementation of the channel can depend on the requirements of the modules, as long as the Switch 111 is able to support the necessary format.

The Switch 111 connects the various Data Channels 113a-d between Modules 12a-d under the control of the Administration Module 112 (and in fact can be implemented on the Administration module if desired.) The Administration Module 112 tells the switch 111 which channels to connect, based on system configuration and/or on dynamic requests from Application Modules 12a-d. Only the Administration Module 112 is able to define routing connections. Administration Channel. The Administration Channels 113a-d provide communications between the Application Modules 12a-d and the Administration Module 112. Application Modules use the Administration Channels to request connections to other modules in the system. Because this is an important function, each module connection point has a guaranteed connection to the Administration Module. Thus every Application Module can always be assured of having a constant and secure means of communications to the Administration Module, regardless of the state of the rest of the system.

In addition, the Administration Channel 113a-d can also be used as a means of configuring an Application Module 12a-d. Applications typically require various parameters and settings to be provided by the end user; for example the allocation of disk space to different applications, or setting the security level on the network interface module. These types of settings are not part of the normal operation of the application, and indeed should be separate for security reasons. Since the Administration Channel is typically separated from the Data Channel, it is an ideal mechanism for providing a secure means of interfacing to the end user. An Application Module 12a-d can provide a special configuration screen or window, similar to the Control Panel of Windows™ operating systems, via the

Administration Channel. Being physically isolated from all other Application Modules, it would be difficult if not impossible for a different, malicious application to change the application's settings.

In addition, the Administration Channel can also be used as the sole Data Channel for Application Modules that do not require high-speed data transfers. For example, simple "tool" applications that only require a single simple window interface can use the Administration Channel and its associated control panel window as the sole interface to the user.

Resource Allocation. In the event that the Data Channels 114a-d are implemented as a dynamic resource, some means of allocation must be provided. The Administration

Module 112 provides this means. Whenever an Application Module needs to share data with another module, it sends a request to the Administration Module. The Administration Module then configures the Switch 111 for the best possible data transfer rate given the current conditions of the system, and replies to the Application Module with the Data Channel channels it can use. The Application Module then performs the data transfer.

The bandwidth of the TEA interconnect system is unlikely to be a bottleneck because all of the high-bandwidth hardware requirements are located on the Application Modules themselves. Thus the bus bandwidth is only needed when an Application Module needs to communicate with another entity, either a system resource module or another module.

Desktop Module and Video Module

The main interface for the user, the Graphical User Interface (GUI) or Desktop, is preferably defined and implemented by a single Desktop Module. The Desktop Module will define what the user sees on the screen in terms of background colors or patterns, mouse shapes, icon types, menu bars, etc. Application Modules will query the Desktop Module to get the common interface parameters, similar to how conventional Windows™ applications query the operating system. Note that while the Desktop Module is considered one of the shared system resources, it can still be a removable device, allowing the user to transfer to other computers while retaining the same desktop configuration.

The Desktop Module may be tightly coupled to, or even implemented on, a Video Module. The Video Module provides the interface to the physical display hardware such as an external monitor or laptop screen. This module is much simpler than conventional graphics cards, because it only needs to be a simple display buffer. The Application Modules themselves do all complicated graphics calculations; the Video Module simply accepts the resulting bitmaps and displays them on the screen in a location and manner as determined by the Desktop Module.

Operation and Implementation. Acting as the desktop interface, the Desktop Module sends requests for display segments to the various applications in the system, based on the current requirements of the display (desktop) layout, clipping regions, etc. So when a window is moved, sized, created, etc. the Desktop Module knows what windows are where and which ones need to be redrawn. It sends redraw requests to the appropriate Application Modules as necessary.

The Application Modules receive requests and send back the appropriate bitmaps. The Application Module is free to provide as much optimization as desired. The simplest case may be for the Application Module to redraw the entire application screen and send it at each request, ignoring the clipping area. Optimizations may include only drawing the specified rectangle; buffering the bitmap and sending the entire screen or the clip rectangle; or using a separate display processor to handle display requests through dual-port memory. The Video Module receives the resultant bitmap messages and displays them on the screen, performing the necessary clipping. Provisions in the protocol are preferably provided for special cases such as aborting a transfer, deleting a previous unfulfilled request, etc. so that the Video Module can work most efficiently. The hardware on the Video Module only needs to buffer one message at a time, but can buffer more if desired to increase performance.

A dedicated Display Channel may be provided for each Application Module to transmit video data to the Video Module. Further optimization, shown in Fig 3(b) which illustrates an alternative module interconnection of the computer system, may include an additional TEA switch 115 as a part of the module interconnection 11 which accepts input from each of the Application Modules 12a-d via the dedicated Display Channels 117a-b, and provides two output channels 118a and 118b to the Video Module 12e. One output channel 118a would provide video data for the current or "in-focus" application, and the second channel 118b would provide video data for the remainder of the modules using the display. In this manner, the module in focus gets the full bandwidth of a display channel and priority processing by the Video Module, insuring the highest degree of quality. The shared secondary or non-focus channel allows the remainder of the modules to still be able to update their display segments, but at a (possibly) reduced bandwidth or frequency.

The TEA system may provide different types of low-level messages between applications and the Video Module. For instance, there may be a simple text mode, similar to a console display. The application then just sends ASCII text. There may also be more advanced graphics modes, etc. Data Storage Data Management. A central tenet of the TEA architecture is that an Application Module is in total control of its own data. This approach, referred to as "Hardware

Encapsulation", is a significant change from the traditional PC implementation. Instead of relying on a single monolithic filesystem implemented by a centralized operating system and residing on a separate hard disk, Application Modules are able to implement data storage in the manner that is best suited for their particular applications. Modules can have any type of persistent memory: disks, flash memory, battery-backed CMOS, etc. In addition to this module-specific data storage, a system-level Storage Module may also be used to provide even more data storage capabilities. This Storage Module may be RAID arrays, tape drives, network storage, etc. Since it is an independent Application Module, it is running its own control program and is thus able to allocate storage space totally under its own control. Application Modules can request space on the Storage Module as needed.

A TEA system may include a file manager module that performs functions similar to the "Explorer" program in a conventional operating system. Message protocols support the query of metadata from each module, so the file manager module can poll all other modules for metadata and then display it as desired. TEA may also provide functions such as "file" copies, etc. by using additional messages. However, the modules involved in the operation have full control over whether or not they want to perform the operation. For example, if data is requested to be transferred from a word processor to a storage module, but the data has been marked "private" by the user, then the word processor application will refuse to send the data.

Data Locality. The data handling mechanism of TEA allows for a different concept of data locality. In today's world where the OS is responsible for handling the storage of an application's data, the location of the data is the prime consideration. The concepts of disk directories, backup tapes, and file servers are necessary in order to use an application.

However, the data caching mechanism inherent in TEA changes this paradigm. Under TEA, an application simply tells the data storage medium to which it is connected to save or get a data object. The application provides enough information to uniquely identify this data object within its own data space. An application's data space is defined as the data known by (and most likely created by) that application. For example, every file created by an application has a unique filename defined by the application. However, a different application can use the same filename to represent different data, since the actual data is in a separate application-unique data space. The storage module can expand this data space to include central fileservers, network-based servers, or a VPN-like connection back to the users desktop computer. The data space uses its own data naming and locating protocols to move data around, much like today's Internet-based file servers and TCP/IP services.

All of this is transparent to the application and user, and thus is similar to the concept of data caching. As with some conventional advanced processing units, the application does not care if the data has been cached within the processor, in L2 cache, in memory, or swapped to disk; it just requests data and waits for it to be available. Caching is a means of efficiency, not necessity. The TEA data space is similar. An Application Module can request a data object and the low-level, user-invisible data handling mechanism provides it. It doesn't matter where it actually resides, except for the speed of operation. So applications that want high-speed operation provide more local storage space. This entire operating paradigm is apart of the TEA architecture.

This also makes portable computing almost seamless. For devices such as cell phones, where the main use would be viewing small amounts of data, the inherent wireless connectivity provides the link to the user's entire dataset, without needing to download or synchronize, and also without user intervention.

TEA also provides a solution to many problems in managing conventional computer systems. Consider that all data on a computer must be created or imported by an application. For instance, word processors allow users to write documents; browsers allow users to download data from the network. In conventional systems, it is the responsibility of the user to decide where to put this data and how to organize it, with the further burden of doing it with a hierarchical file system structure. In a TEA system, the data is automatically managed by the application that creates it. The user is no longer required to locate and manage the data; the application automatically does it for her. Thus to see what data is available, the user opens the application, and the application provides the ability for the user to view, select, and access data. In conventional systems this is typically done via a window showing the file system structure; in TEA it can be done by any method appropriate for the application and the data (lists, icons, the traditional file system, etc.)

TEA also provides an inherent method of archiving old or rarely used data. Released from a file system based on physical disk structures, TEA treats all data as simple objects. Thus the data can reside in memory, on disk, the network, or wherever. It doesn't matter to the application- it simply maintains a directory of its own data, and leaves the local management to the hardware. The user can manually select which data to archive, and/or a routine can automatically archive old or rarely used data based on time or access frequency. An application can "archive" data by moving it up the cache chain. At the application level, the data is simply marked "archived" (and optionally kept in a different directory listing.) The same memory management code used to allocate the data in the first place then sends the data to the next level of the cache. Note that there is no need for the application to know exactly where the data is; it just queries the next level whenever it needs the data, just like memory caching.

Inter-Module Data Transfer. An Application Module stores its data "internally" similar to the private data of a C++ object. And also in a similar manner, the data is only accessible through application-provided interfaces. To transfer data to another Application Module, messages are sent along the TEA Interconnection bus, protocols are negotiated, and data is transferred. If desired, the application can export data into common formats such as text files, etc., but only if the receiving application wants that service and the sending application has that capability. For transfers to applications or other devices not physically residing in the TEA system, a communications gateway (such as a network module) encapsulates the data for upstream transmission so that the transfer looks like an in-system transfer to the sending application.

Therefore, the traditional concepts of binary or text files no longer apply. Applications are free to store data any way they desire, and the storage device treats it like an atomic data object. Access to the data is controlled by the application, similar to the way a C++ object encapsulates its data, rather than being controlled by a centralized operating system.

Data Cloning and Security. Since a module may contain data, there must be a way for the user to easily and securely upgrade modules without loss of data. There are several ways of doing this depending on the security level desired by the user. One method is to utilize off-module storage. The user may copy all of the desired data onto a Storage Module, network server, CD, etc. The user then copies this data onto the new module. A variation of this method is to copy the data directly from the old module to the new module, assuming both are available in the system at the same time.

Archiving and Backup. One major ongoing problem with persistent data is how to manage the archiving and backup. The traditional directory structure does not lend itself well to keeping track of archived and backup files, history, locations, etc. The TEA storage paradigm provides for painless backup and archiving of data objects, due to the inherent caching structure. Data objects can be automatically "cached" at each level, similar to how conventional CPU caches work. The data controller (memory, disk, etc.) at each level keeps track of data storage time (or other parameters) and decides when to send the data to the next level. It keeps track of the new location, so when the application wants the data, the request is passed down the levels until the data is located and retrieved.

The concepts of "archiving" and "backup" are different in that archiving is typically done with data that does not need to be accessed quickly. Backup is a means of insuring that data is not lost due to equipment failure. The TEA storage paradigm blends these two concepts together and as such makes them obsolete. Archiving is inherent in the very nature of the caching structure. As a data object ages (i.e. is not modified or accessed) it will descend the cache structure. If desired, the user can incorporate traditional "archiving" methods such as magnetic tape or optical disks at the lower levels of the cache. But there is no need for special software to run these systems and keep track of the data on each tape; it is part of the regular TEA storage system. The nature of the "backup" process depends on the cache level. CPU/Memory cache coherency mechanisms already do "backup" of the data by keeping the RAM current. Disk backup can occur in various ways depending on the desires of the user and the system setup. However, it will all be invisible to the end user. Methods include those of the RAID system, and cache copying (i.e. sending data down the cache even though it isn't old.)

Implementation. Unlike the conventional PC architecture where a centralized OS provides directory services, the Application Module in a TEA system is responsible for maintaining its own "directory" of objects it creates and manages. Since this is a normal function of an application (it has to keep track of its data already) this is not a performance hit. The unique names/IDs of an object are used to identify the objects within the Application Module data space. This local directory is in fact also a persistent data object, albeit (preferably) a single, unique object to simplify object searches. Optionally, when a module is installed into the system, it sends out an "I'm here" message, and also if desired, a "Who's there" message to detect other applications that it may want to talk to. Usually an application will always try to find storage devices, but it may also look for communications devices, etc. The application will also always look for the User Interface applications of keyboard/mouse, and video output. For each other application that the module is interested in, it negotiates a unique, in-system identifier. If need be, the user is queried via the administration interface, to provide customization or to resolve conflicts, but usually the applications can handle inter-module identification themselves, since this is mostly to maintain low-level communications. The user may be queried for storage-type identifiers, such as "Name this app." When the data is "stored", the application sends it to the storage system (previously identified when the application was placed in a TEA system.) The application provides its object name/ID to the storage system, which appends its own id which identifies the application locally. This id can be derived from combinations of the physical ID of the module itself, the virtual ID assigned to the application, the currently "logged in" user, and/or other identification methods such as those involving biometrics. The storage system maintains its own directory as well, using any appropriate method.

Note that the application has no awareness of this storage method and is thus insulated from device-specific requirements such as filename lengths, partition sizes, etc. Since the application maintains its own "directory" of data objects, the storage system does not need to maintain or impose its own directory structure on the application. The storage system simply accepts requests to store and retrieve objects based on the name the application gives. The storage system may apply its own directories for the sake of efficient searches, but the application is oblivious to this.

The first-level storage is conceptually similar to the existing PC world of using memory for application-level storage, and the hard disk/file system for system-level storage. In the PC paradigm, the application uses such things as directory names and file extensions to identify a particular file (by perhaps providing a list of possibilities to the user.) A similar operation is possible in a TEA system, but with inherent security, since the frame storage device will only let an application see its own data. Upper-level storage devices, corresponding to conventional file servers, are implemented in the same way. They service requests for storage or retrieval, and are able to use their own directory, storage, and security models.

Security can be obtained by having each level perform its own encryption if desired. Since the only "in the clear" data passed between levels need be identifiers, the actual data can be treated as a totally encapsulated object. And since each level can also use a different encryption algorithm, security can actually increase at each level of storage.

Portability can also be accomplished in this model. Each level will have some sort of administration, which may be the intranet administrator of a business, the network administration of an ISP, an on-line archival service, etc. Since an "account" must be previously established for each level, that level can maintain a mapping of object/user/application identifiers to its own storage paradigm. If a user wants to be able to store data using one application and retrieve it using another, it assigns the data object a certain attribute that informs the upper levels to keep the user identifier visible and in a way that allows retrieval by different apps. This causes each level to pass the application ID up the chain instead of totally encapsulating it within its own level.

Data storage within an Application Module itself is application-specific. For example, a basic DRAM array can be used for simple applications, multiple levels of caching can be implemented for high-end applications, size-dependent applications can incorporate hard disks in the module itself, etc. When the data needs to be stored in medium or long-term storage, it is moved off of the module. At this point, the data is treated as an object, and the concept of encapsulation is used.

The raw data from the module is encapsulated in a "packet" in a way somewhat similar to existing network protocols. The format of this data object is based on protocols supported by the source and destination modules, and is not architecture-dependent. The new data packet will include "addressing" information in the header, identifying the owner module/application, security and encryption, protocol-specific information, etc.

The traditional hierarchical directory tree is no longer used (except for within the module itself, optionally). Since data is treated as an atomic unit with its own inherent identifying information, the file system no longer needs to be based on physical locations. Any of a variety of addressing schemes can be used, as defined by the destination system. For example, if a network storage system accepts data, it defines a protocol that allows it to uniquely identify the originator of the data object. The originating module (such as the network interface module of a user's system) encapsulates the data object, creates the header based on the network storage protocol, and sends it on its way. Thus, the addressing or directory system is defined at each "interface" and need not be all-encompassing. A hierarchical directory structure can be used between the Application Module and the disk module if desired, while a URL-type addressing scheme can be used for network storage. "File" manager. Each application provides its own interface to its own data. Applications may use commonly accepted concepts such as menus, list boxes, etc. similar to how it works now. The TEA system may also provide a "File Manager" application to request information from other applications in the system. This gives the user a single interface to all "data" on the system, like conventional file managers. The File Manager uses a high-level interface to get data from applications, instead of the other way around. Applications have full control over what they give, and how they respond to requests for "Open data" and such.

Network Interface Module

Overview. The network interface module takes the place of the traditional NIC or Network Interface Card. While performing the standard tasks of physically connecting to a network, such as the Ethernet, a TEA network interface module (NIM) has the ability to implement much more functionality and security.

The NIM may be the location of network-related applications such as browsers and email, as well as the location for implementing firewall-like protections. In such a case the NIM may be the only direct connection to the outside world. This provides much more security since the software does only one thing- interface to the network, and is thus easier to debug and maintain. Also, should malware or viruses make it to the module, only the data stored on that module would be directly affected. Since the NIM is a TEA module, security is inherent in the design. The use of the Administration Channel prevents malware from changing any of the security settings. Data encapsulation prevents malware from immediate and global access to all data (and code) on the computer. Dedicated hardware allows the module vendor not only a choice of CPU's (thus making it harder for a single virus to propagate) but also allows the vendor to implement custom and proprietary hardware for added security. Virus protection. A virus scanner module may be provided. When installed in the system, all other modules in the system will use it as a "filter" for data transfers, which is preferably transparently to the user. Thus when a data transfer is negotiated between two modules, the data is actually first passed through the virus module. This module can be highly optimized for scanning functions to minimize its impact on performance. The use of the virus scanner may be decided by the sender and/or the receiver. Thus a malware application cannot bypass the virus scanner. For example, the receiver may insist on the use of the virus scanner, thus insuring all incoming data has been scanned.

Remote Terminals. The TEA architecture makes it easy to access the modules remotely. The Network Interface Module may be set up to act as a gateway, similar to VPN. A user can work on another computer (the remote terminal) that simply passes the key/mouse messages through its NIM (or a NIC in a conventional computer), the network, and the NIM on the user's computer to the modules. The video messages are then passed back to the remote terminal. Similarly, a user may "run" a module via a PDA or cell phone, using wireless connections, and have the full power of the module. The NIM also allows the modules to be flexibly located physically. For example, individuals within an organization may have their own office module, but the modules may be physically located in a rack in a computer room and accessed via a network such as an intranet. This allows sensitive or expensive modules to be centralized while other modules remain in the desktop case. Keyboard and Mouse

The Keyboard/Mouse Module generates TEA messages based on those input devices. These messages are usually routed to the "in-focus" application by the Desktop Module or the Desktop Module and switch combination, since only the Application Module that has display focus typically needs to receive user input. Case and Mechanical Design

Power. Conversion from A/C power to D/C power may be accomplished either inside or outside the case. The system power will be distributed within the case to individual modules. In addition, each module has the ability to incorporate its own power source if needed. Module power can be implemented in a variety of ways depending on the desired effect.

Modules designed to be easily removed from the system will use hot-swap hardware 127 (see Fig. 2) to provide enough short-term power for the module to perform a shut-down 5 or save when main power is removed or when the module is removed from the system. A simple version of this would be a large amount of capacitance in the power path within the module. More advanced modules can incorporate batteries to give even more power after removal from the system. Non-removable modules with system state information will also use some level of hot-swap techniques to allow state data to be saved.

0 The hot-swap techniques give an additional feature providing built-in protection from power surge, brown-out, and power failure.

The system power supply can be thought of as a charger for removable modules in addition to a permanent power supply for both removable and non-removable modules.

Modules designed to operate as stand-alone modules will have battery power or an L 5 external power source.

Case Designs. The case of a TEA computer may have a variety of designs.

1. Desktop Case: Variety of shapes and sizes are available for every need, ranging from traditional boxes such as mini-towers, desktop boxes, etc. to more esoteric designs.

2. Laptop "Shell": The shell contains the display, keyboard, and power, as well as various 10 connections for different types of TEA modules.

3. "Server" case: They may be used for clustering TEA modules within a single big case. They can also include traditional 19" racks, with slide-out trays or built-in slots.

4. Advanced cases: The flexibility of the TEA architecture allows for a large variety of new and unusual case designs. For instance, the entire computer may be built into the LCD

>5 display case, with module slots behind the display. Or the box may look like an Ionic Breeze tower.

Upgrading

The TEA architecture provides more methods of upgrading software than do conventional operating-system-centric systems. Modules can be upgraded via the traditional

30 methods of CDROM or network downloads (in much the same way one can upgrade PC BIOS memory.) TEA also allows for other methods such as physical replacement of the module. In this method the user can install the new upgraded module, clone settings and data if desired, and make sure the module runs as desired, all without loosing the original module's functionality and without resorting to risky software-only uninstall methods. TEA also provides for greater security during the upgrade process, both for the user and the module vendor. Because the vendor is in complete control of the upgrade process, methods can be put in place to insure complete data and operational integrity during the upgrade. And vendors can be assured that no piracy is taking place. Compatibility

The TEA architecture is best utilized when the applications are written specifically for TEA modules. However, due to the need to utilize existing applications, it is preferable for TEA to be compatible with existing operating systems and code base. Three examples of providing compatibility for existing applications are Application on Module, OS on Module, and TEA Bridge.

Application On Module (see Fig. 4(a)). In this method, a single application (or tightly coupled suite of applications) 41 is installed on a single TEA module 40. Software 42 is provided that acts as an interface between the application and the TEA bus. This layer 42 provides all of the operating system API functionality needed by the application, and in essence is the "operating system" from the application's point of view. Fig. 4(d) shows a TEA system that is otherwise similar to the system in Fig. 1, but has a legacy OS Application Module 40 connected to the module interconnection 11.

This method has several advantages. Because there is only a single application, the TEA Interface Layer need only supply the exact API functions needed by the application. Not only does this simplify development but it also assists in debugging and testing.

OS on Module (see Fig. 4(b)). This method implements what is basically a PC, on a module 40, with hardware-level compatibility as needed. TEA is used as the means for I/O to such devices as keyboard, display, etc. Custom device drivers 45 are written for the OS 44 on the module, to interface the OS to the rest of the TEA system. With this method, the OS is expecting to be in complete charge of the system, including the display. So while the module will still have windows on the GUI desktop, these windows will appear like the desktops of the operating system. In addition, the cost is much greater since the module must now provide a commercial operating system as well as applications. TEA Bridge (see Fig. 4(c)). This method is a variation of the OS on Module method in that an entire operating system is present in the system. However, instead of being embedded on a TEA module, the OS 47 is running on a regular PC motherboard 46. A hardware device (TEA Bridge) 48 is used as a "bridge" between this system and a TEA system. This method provides for the easiest transition to a TEA system in that the user can retain the entire existing PC, along with operating system and applications. TEA modules can be added as desired, until there is no longer a need for the original PC.

It will be apparent to those skilled in the art that various modification and variations can be made in the modular computing device and methods of the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover modifications and variations that come within the scope of the appended claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A modular computer system comprising: a module interconnection; and one or more application modules adapted to be connected to the module interconnection, each application module including, within a single physical unit, interface hardware for interfacing with the module interconnection, application programs, and a processor and memory for executing the application programs, wherein the one or more application modules include zero or more system resource modules, wherein the application modules execute their respective application programs autonomously and asynchronously, and wherein the application modules communicate with each other via the module interconnection.

2. The modular computer system of claim 1, wherein none of the application modules acts as a centralized operating system.

3. The modular computer system of claim 1, wherein the one or more application modules include one or more user interface modules as system resource modules for controlling a display device, a keyboard, and/or a mouse, wherein the user interface modules communicate data with other application modules.

4. The modular computer system of claim 1 , wherein the one or more system resource modules include a storage module having a mass storage device.

5. The modular computer system of claim 1, wherein the one or more system resource modules include an interface module for interfacing with an external network or device.

6. The modular computer system of claim 1, further comprising a power supply for supplying power to all application modules and the module interconnection.

7 The modular computer system of claim 6, wherein at least some of the application modules further include hot-swap hardware for providing sufficient power for the module to perform a shut-down or save when power is removed or when the module is removed from the system.

8. The modular computer system of claim 1 , wherein the application modules communicate with each other via the module interconnection using message passing.

9. The modular computer system of claim 1 , wherein each application module maintains a directory of data objects within its own data space, regardless of the physical location of the data objects.

10. The modular computer system of claim 1 , wherein when an application module is installed into the system, it sends a message to announce its presence and sends a message to detect other application modules present in the system.

11. The modular computer system of claim 1 , wherein the module interconnection comprises an administration module and a switch, wherein each application module is adapted to be connected to the administration module via an administration channel, wherein each application module is adapted to be connected to the switch via zero or more data channels for module to module communication, and wherein the administration module controls module to module communications.

12. The modular computer system of claim 11 , wherein the administration channels are guaranteed communication channels and provide communications between the application modules and the administration module.

13. The modular computer system of claim 11 , wherein the application modules request connections to other application modules in the system by using the administration channels.

14. The modular computer system of claim 1 , wherein the application modules include a video module for displaying video data to a video display, and wherein the module interconnection further comprises dedicated display channels for transferring video data from at least some of the application modules to the video module.

15. The modular computer system of claim 14, wherein the application modules further include keyboard/mouse interfaces, and a desktop module which implements a graphical user interface, wherein the desktop module controls routing of display, keyboard, and mouse data between other application modules and the video module and keyboard/mouse interfaces.

16. A method for carrying out modular computing, comprising: connecting one or more application modules to a module interconnection, each application module including, within a single physical unit, interface hardware for interfacing with the module interconnection, application programs, and a processor and memory for executing the application programs; the application modules executing their respective application programs autonomously and asynchronously; and the application modules communicating with each other via the module interconnection.

17. A module interconnection for a modular computer system, comprising: one or more interface ports for connecting to application modules, each interface port having an administration channel and zero or more data channels; an administration module connected to the administration channel of each interface port; and a switch connected to the data channels of each interface port, if any, wherein the administration module is adapted to control module to module communications.