Personal Digital Assistant Module Having a Broadcast Pointer Device

This invention is in the area of portable computers and pertains more specifically to small portable computing devices known in the art as personal digital assistants.

Personal Digital Assistant (PDA) units, as of the date of this disclosure, enjoy a position of hope in the computer marketplace. Some believe this approach, a small, relatively inexpensive, and eminently portable computer unit, having software specifically written for tasks a user might expect to perform while travelling, will provide eminently useful and therefore salable computer products. Apple Computer, Hewlett Packard, and several other well-known computer manufacturers have made a considerable investment at no small risk in such systems.

Given the new systems now introduced, and those coming, for what is now known about them, there are still a number of drawbacks and problems. For example:

1. The PDA systems introduced are relatively costly, with starting prices ranging from several hundred dollars to two thousand dollars and more. At such prices, rivalling current pricing for desktop systems, the buying public may react negatively. It is true that prices will fall with increased manufacturing volume and competition, but the high end start may well be rejected by potential users.

2. The systems being offered are still relatively bulky, considering the limited range of tasks that may be accomplished. Most are certainly too big to be conveniently carried in a breast pocket. The Newton, manufactured by Apple Corporation, weighs about a pound and is approximately the size of a VHS video cassette.

3. A big drawback of the PDA systems being offered is the way they transfer data between a user's desktop unit, or other host, and the PDA. Known communication is by modem, by infrared communication, and by serial connection. These all require manipulation by a user, modulation on one or both ends of the communication path, and the like, which can be time-consuming, error-prone, and hardware extensive (expensive). Presently the Newton offers a modem and/or LED communication as an option, adding to the overall cost.

4. In known PDAs, software is typically recorded in ROM, so updating applications can be difficult, and sometimes impossible. This will be a problem because PDA users will not want the PDA to have the same capabilities at all times. Typical users will be people who travel and work while they travel. These users require different functions for a trip to Taiwan than for a trip to France, for example. What is needed is a quick and convenient means to update and substitute software.

5. Another difficulty is in the fact that the data files a user manipulates while travelling are typically data files also resident in a home unit, herein called a host unit, such as the user's office desktop machine or notebook or other portable computer. It is very troublesome to have two or more sets of critical data, with differences that one must remember to correct at an appropriate time. This can cause unending grief if files are not correctly updated. At best, current PDAs must use a relatively slow compressed bus to download and upgrade files. Typically this is done through a serial port, using a linking application like Laplink.TM..

What is needed is a small and inexpensive PDA that has a range of features that eliminate the above-described risks and problems. This new unit needs to be smaller than those presently being introduced, such as about credit-card size, or perhaps modeled on the PCMCIA type II or type III standard form factors. It should be inexpensive enough to produce that at least a minimum version could be sold in the roughly $100-$200 range, so it will be a unit seen to be a relatively inexpensive necessity. A PDA unit of this sort is the subject of the present invention, and is termed by the inventors a micro-PDA, or .mu.PDA.

A very important feature of the .mu.PDA in an aspect of the present invention is a direct parallel bus interface with a connector allowing the unit to be docked by plugging it into a docking bay in a host unit. Moreover, when the .mu.PDA is docked in the host, there needs to be a means to effectively disable the CPU in the .mu.PDA and to provide direct access to both the .mu.PDA software and data storage by the host CPU. This direct access would provide immediate ability to communicate in the fastest available fashion between the .mu.PDA and the host, and would also facilitate additional important features to be described below.

The .mu.PDA also needs to have an optional compressed bus interface, including a connector separate from the host interface, so add-on devices may be utilized, such as a FAX modem, cellular communication, printer, and so on.

An additional feature that could be optionally provided in another aspect of the invention is an interface at the host to allow a user to select pre-arranged software mixes for loading to the .mu.PDA. This feature comprises a set of control routines operating in conjunction with the host's display and input means, to allow the user to quickly select applications and perhaps data as well to be loaded to the .mu.PDA satellite, to configure the smaller, more portable unit for specific itineraries and purposes.

Another desirable feature is an ability to automatically update data files. In this aspect of the invention, with the .mu.PDA docked, data on the host, if carrying a later date and/or time stamp than the data on the .mu.PDA, would be automatically updated on the .mu.PDA and vice-versa. When one returns from an excursion using the .mu.PDA and docks the satellite at the host, the host gains access, determines the location of the latest files, and accomplishes the update. This feature needs to have some built-in user prompting to be most effective. It makes the .mu.PDA a true satellite system.

In a preferred embodiment of the invention a personal digital assistant module is provided comprising an enclosure for enclosing and supporting internal elements, a microcontroller within the enclosure for performing digital operations to manage functions of the personal digital assistant module, and a memory means connected to the microcontroller by a memory bus structure for storing data and executable routines. There is a power supply means within the enclosure for supplying power to functional elements of the personal digital assistant module, a display means operable by the microcontroller and implemented on a surface of the enclosure, and input means connected to the microcontroller for providing commands and data to the personal digital assistant module. A host interface means comprising a host interface bus structure, which may be configured as a PCMCIA bus interface, is connected to the microcontroller and to a first portion of a host interface connector at a surface of the enclosure, and the host interface means is configured to directly connect the microcontroller to a compatible bus structure of a host computer.

In one embodiment the personal digital assistant module has an expansion bus interface comprising an expansion bus structure connected to the microcontroller and to a first portion of an expansion bus connector for connecting the microcontroller to a peripheral device. A wide variety of peripheral devices are provided for use with the personal digital assistant of the invention.

In another aspect, the personal digital assistant module also has a nonvolatile storage device, such as an EEPROM connected to the microcontroller and containing one or more codes unique to the personal digital assistant, for uniquely identifying the personal digital assistant to digital devices connected on the host interface.

In a preferred embodiment, the display and input means for the personal digital assistant are configured as an overlaid touch screen and LCD display on a surface of the outer case of the personal digital assistant. A pointer device implemented as a thumbwheel in one embodiment and as a pressure sensitive pad in another is provided as part of the input capability.

In other embodiments the personal digital assistant module has attachable pointer devices and other input devices. In some of these alternative embodiments pointer devices may be stored in a compartment in the personal digital assistant and deployed for use.

The personal digital assistant module forms a unique combination with a general-purpose computer host having the personal digital assistant as a satellite unit. The host in this instance has a docking bay especially configured to dock the personal digital assistant, making a direct bus connection between the local CPU of the personal digital assistant and the CPU of the host. The host may be a desktop unit, a notebook computer, or a smaller portable like a palmtop computer. This combination provides power and convenience not before available.

Many other digital devices are also provided according to various aspects of the invention, such as modems, scanners, data acquisition peripherals, cellular phones, and a software vending machine, and all of these devices may be appended to the personal digital assistant by the expansion bus interface or, in many cases, by the host interface.

The personal digital assistant provided according to embodiments of the present invention is a unit more compact than conventional PDAs. It represents a new dimension in computer application and applicability, in a form promising to be eminently usable by and useful to almost everyone; and at a price easily affordable. It solves the communication problem intrinsic to personal digital assistants relative to larger and more powerful computers, with a unit that fits into a user's breast pocket, and at a very low price.

FIG. 1A is an isometric view of a .mu.PDA according to an embodiment of the present invention.

FIG. 1B is a plan view of the .mu.PDA of FIG. 1A.

FIG. 2 is a cross-sectional view of the .mu.PDA of FIGS. 1A and 1B.

FIG. 3 is a block diagram of the .mu.PDA of FIG. 1A and some peripheral elements.

FIG. 4 is a more detailed plan view of the .mu.PDA of FIG. 1A showing in particular an LCD display and touch screen user interface in an aspect of the present invention. FIG. 5 is an isometric view of a .mu.PDA and a host notebook computer in an aspect of the present invention, with the .mu.PDA about to be docked in a docking bay of the notebook computer.

FIG. 6 is a block diagram of a .mu.PDA docked in a docking bay of a host computer according to an embodiment of the present invention.

FIG.7 is a logic flow diagram of the steps in docking a .mu.PDA in a host computer according to an embodiment of the present invention.

FIG. 8 is an isometric illustration of a .mu.PDA software vending machine in an aspect of the present invention.

FIG. 9 is a top plan view of a .mu.PDA enhanced user interface according to an embodiment of the present invention.

FIG. 10 is a top plan view of a .mu.PDA with a microphone in an embodiment of the present invention.

FIG. 11 is an isometric drawing of a .mu.PDA docked in a dedicated cellular or cordless telephone according to an embodiment of the present invention.

FIG. 12 is a plan view of a .mu.PDA with a speaker and pager interface according to an embodiment of the present invention.

FIG. 13 is a plan view of a .mu.PDA with an infrared communication interface according to an embodiment of the present invention.

FIG. 14 is a plan view of a .mu.PDA with a scanner attachment according to an embodiment of the present invention.

FIG. 15 is a plan view of a .mu.PDA with a fax-modem attached according to an embodiment of the present invention.

FIG. 16 is a plan view of a .mu.PDA with a printer adapter interface according to an embodiment of the present invention.

FIG. 17 is an isometric drawing of a .mu.PDA docked in a barcode reader providing a data acquisition peripheral according to an embodiment of the present invention.

FIG. 18 is an isometric view of a .mu.PDA with a solar charger according to an embodiment of the present invention.

FIG. 19 is a plan view of four .mu.PDAs interfaced to a dedicated network console providing inter-PDA communication according to an embodiment of the present invention.

FIG. 20 is an isometric view of a .mu.PDA according to the invention connected by the expansion port to a standard-sized keyboard.

FIG. 21A is an isometric view of a notebook-type computer with a removable pointer device stored in an on-board compartment according to an embodiment of the present invention.

FIG. 21B is an isometric view of the notebook-type computer of FIG. 21a with a mouse pointer device deployed for use, having a connecting cable.

FIG. 21C is an isometric view of a notebook-type computer with A cordless mouse device deployed for use.

FIG. 21D is an isometric view of a notebook-type computer with a cord-connected trackball device deployed for use.

FIG. 21E is an isometric view of a notebook-type computer with a cordless trackball device deployed for use.

FIG. 21F is an isometric view of a notebook-type computer with a cord-connected combination mouse/trackball device deployed for use.

FIG. 21G is an isometric view of a notebook-type computer with a cordless combination mouse/trackball device deployed for use.

FIG. 21H is an isometric view of a notebook-type computer with a trackball pointer mounted in a well according to an embodiment of the present invention.

FIG. 21I is an isometric view similar to FIG. 21H, showing the trackball pointer deployed for use away from the well.

FIG. 22 is a plan view of the removable pointer device of FIG. 21H and 21I, and surrounding areas of the host.

FIG. 23 is a mostly diagrammatic representation of internal components of the removable pointer device of FIGS. 21H, 21I and 22.

FIG. 24 is a mostly diagrammatic representation of internal components of a removable pointer device according to an alternative embodiment of the present invention.

FIG. 25A is a plan view of a combined removable pointer device according to an alternative embodiment of the present invention.

FIG. 25B is a plan view of the pointer device of FIG. 25A, showing the opposite side.

FIG. 25C is an elevation view of a combined removable pointer device according to an alternative embodiment of the present invention.

FIG. 25D is a mostly diagrammatic representation of the internal components of the combined removable pointer device of FIG. 25C.

FIG. 26A is a plan view of a polar-coordinate pointer device stored in a compartment in a host computer according to an alternative embodiment of the present invention.

FIG. 26B is a plan view of the polar-coordinate pointer device of FIG. 26A, with the pointer device extended for use.

FIG. 26C is a graphic illustration of the geometry involved in the calculation of the Cartesian of the polar-coordinate pointer device in FIG. 26B.

FIG. 27A is a plan view of a broadcast pointer system with a deployable element and a storage compartment according to an alternative embodiment of the present invention.

FIG. 27B is a plan view of the broadcast pointer device of FIG. 27A with the deployable element deployed.

FIG. 27C is a plan view of another broadcast pointer system with a stylus-type deployable element.

FIG. 27D is an illustration of a waveform as received by antenna 1319 from pointer 1321.

FIG. 28 is an isometric view of a keyboard having a removable pointer device according to a preferred embodiment of the present invention.

FIG. 1A is an isometric view of a .mu.PDA 10 according to an embodiment of the present invention. In this embodiment the unit is modeled on the PCMCIA standard Type II form factor, having a height D1 of about 5 mm. Body 12 is described in further detail below, and has a female portion 14 of a connector recessed at one end for engaging a mating male portion of the connector in a host computer, connecting the .mu.PDA internal circuitry directly with a host internal bus. The host unit may be a notebook computer having a docking bay for the .mu.PDA. Docking bays may be provided in desktop and other types of computers, and even in other kinds of digital equipment, several examples of which are described below.

Still referring to FIG. 1A, in this embodiment there is a combination I/O interface 16 implemented on one side of the .mu.PDA, comprising a display overlaid with a touch-sensitive planar structure providing softkey operation in conjunction with interactive control routines operable on the .mu.PDA in a stand-alone mode.

Although not shown in FIG. 1A, there may also be guides implemented along the sides of the case of the device for guiding the module in and out of a docking bay in a host computer unit. There may also be one or more mechanical features facilitating engagement and disengagement of the module in a docking bay.

FIG. 1B is a top plan view of the .mu.PDA of FIG. 1A showing a thumbwheel 18 implemented in one corner of the .mu.PDA. The thumbwheel in this embodiment is an input device capable of providing input with both amplitude and directional characteristics, and in some cases rate characteristics as well. The thumbwheel has many uses in combination with the .mu.PDA and I/O interface 16. One such use is controlled scrolling of icons, characters, menus, and the like on the display of the device. The thumbwheel provides many of the functions of a pointer device.

In this embodiment of the .mu.PDA a second external connector portion 20 is provided. This connector portion is for engaging peripheral devices as part of an expansion bus interface.

FIG. 2 is a simplified cross-sectional view of a means for constructing a .mu.PDA according to the present invention in a Type II PCMCIA, or other relatively small package. ICs 34 are encapsulated in a conformal material 36, and interconnection is accomplished by traces on a flexible polymer film 32 shown as overlaying the encapsulated structure. In this structure the ICs are not packaged in the conventional manner having solder leads for assembly to a printed circuit board. Rather, connections are made directly between the solder pads on the chip and the traces on the Kapton film. Also there is no intention to relate ICs indicated by element No. 34 with specific functional lCs in a .mu.PDA. This cross-section is illustrative of a method of construction only.

In this compact construction there may also be traces on the side of film 32 away from the interconnections for the CPU and memory for connection to other elements, such as display 25 and touch-sensitive screen 27.

LCD display 25 is implemented on one side of the .mu.PDA, and touch-sensitive interface 27 is provided overlaying at least a portion of the LCD display. A metal casing 38, or other suitable material or combinations of material, surrounds the internal components and conforms to Type II PCMCIA form factors. This simplified cross-section illustrates some of the principles of construction that can allow the needed components to be inexpensively fitted into the small form factor needed. In another embodiment the .mu.PDA is implemented in the form factor of a type III (10 mm thick) PCMCIA unit, using relatively conventional technology, such as PCB technology, rather than the encapsulated construction described immediately above. Various other constructions, form factors, and combinations are possible, as well.

FIG. 3 is a simplified electrical block diagram of the .mu.PDA of FIGS. 1A, 1B and 2. A unique microcontroller 11 acts as the CPU of the .mu.PDA in the stand-alone mode, that is, when the .mu.PDA is not docked in a host unit. When the .mu.PDA is docked in a host computer, microcontroller 11 acts as a slave unit, granting bus control to the CPU of the host. In docked mode, the CPU of the host thus gains control of the memory contents of the .mu.PDA, subject in most cases to security procedures which are described below. Thus the host computer can transfer data and software into and out of a docked .mu.PDA memory. In other embodiments many other cooperative operating modes may be accomplished between the two CPUs and accessible memory devices.

Memory 13 is preferably a nonvolatile device from 1 to 2 megabytes in this embodiment, and both control routines for applications and data files are stored in this memory. Memory 13 may be flash memory, CMOS ROM, CMOS RAM with battery, or a combination, with the software stored in ROM and the data in the flash memory. The memory device is interfaced to microcontroller 11 via a dedicated bus structure 17, and microprocessor 11 is configured to drive memory bus 17.

A battery 15 is the power source in the stand-alone mode, and may be recharged in one or more of several ways. The power traces are not shown in FIG. 3, but extend to all of the powered devices in the .mu.PDA module. When the unit is docked in the host, the host power source may be connected to pins through the host interface to recharge the battery. Alternatively, an attached means such as a solar panel may be configured to charge the battery and/or provide power to the .mu.PDA. A solar panel for power is described elsewhere in this disclosure. Also the battery may be easily removed for periodic replacement.

Host bus connector 14 is a part of a host interface which comprises a bus structure 26 for providing connection to the host in docked mode, as described above. In a preferred embodiment, the host interface is according to PCMCIA Type II, Rev. 3 standard, which is capable of communication either in PCMCIA mode or in a mode similar to PCI mode. PCI mode refers to a high-speed intermediate bus protocol being developed by Intel corporation, expected to become a standard bus architecture and protocol in the industry. The physical interface at the host in this embodiment is a slot-like docking bay, as is typical of know docking bays for PCMCIA devices. This docking bay may be implemented as a docking box, a built-in unit like a floppy-drive unit, or it may take some other form.

Connector portion 20 is a part of the expansion bus interface described above, comprising a dedicated bus structure 40 connected to microcontroller 11. This interface can be implemented in a number of different ways. The purpose of the optional expansion bus interface is to connect to optional peripheral devices, such as a printer, a FAX modem, a host cellular phone, and others. The expansion bus interface is not an essential feature in a minimum embodiment of the present invention, but provides vastly enhanced functionality in many embodiments.

The expansion interface can take any one of several forms. A preferred form is an extended enhanced parallel port and protocol based on an invention by the present inventors disclosed in a copending patent application. Another form is an indexed I/O port having 8-bit address and 8-bit data capability. The requirement of the expansion port is that the connection and communication protocol be compatible with expansion devices, such as telephone modems, fax modems, scanners, and the like. Many other configurations are possible.

Optional equipment such as devices listed in box 19 may be connected for use with the .mu.PDA through the expansion bus. Selected ones of such devices may also be built in to the .mu.PDA in various embodiments, providing variations of applicability. In the former case, connection is through path 21 and the expansion bus interface via connector portion 20. In the built-in case, connection is in the interconnection traces of the .mu.PDA as indicated by path 23.

I/0 interface 16 (also FIG. 1B) is for viewing .mu.PDA application-related data and for touch-sensitive input via softkeys. By softkeys is meant assignment by software of various functions to specific touch sensitive screen areas, which act as input keys. Labels in I/O interface 16 identify functionality of the touch-sensitive areas in various operating modes according to installed machine control routines. LCD display 25 and the touch-sensitive area 27 together form the combination I/O interface 16 described also above.

In some embodiments of the present invention, data and program security is provided comprising an Electrically Erasable Programmable Read Only Memory (EEPROM) 31, which is connected by dedicated communication lines to microcontroller 11. EEPROM 31 holds one or more codes installed at the point of manufacturing to provide security for information transfer between a host and a .mu.PDA. The purpose is to control access by a host to the memory contents of a .mu.PDA, so each .mu.PDA may be configured to an individual. To accomplish this, docking and bus mastering machine control routines are initiated at the point of clocking, and this security process is described in more detail below. In other embodiments, security codes may be provided by a Read Only Memory (ROM) chip or other permanent or semi-permanent memory source.

FIG. 4 is a plan view similar to FIG. 1B, of a .mu.PDA, showing in particular I/O interface 16. The size and location of I/O interface 16 may vary, but in general occupies a major portion of one of the sides of the module. In one embodiment I/O interface 16 comprises an LCD display with a resolution of 256 by 144 pixels in a screen size that displays 32 by 12 characters. Each character in this embodiment is displayed in an area eight pixels wide and twelve pixels high. In another embodiment, the pixel resolution is 320 by 200, which corresponds to 40 by 16 characters.

The touch-sensitive areas of the touch-sensitive screen correspond to the character areas of the display. By touching an area with a finger or stylus, data can be entered quite quickly and with minimal CPU demand.

At one corner, thumbwheel 18 provides a two-directional means of controlling the configuration of the display according to installed control routines. A menu 70 is configured at one side to represent the current status of any application in progress and to provide appropriate user menu selections. In a preferred embodiment input from thumbwheel 18 is used for scrolling through menu 70, and active areas may be indicated by a cursor. A user makes a menu selection by pressing the appropriate touch-sensitive area. A specific input may be provided to cause the menu area to be displayed on either side of the display according to a user's preference.

Specific characters are displayed in this embodiment in a region 74, with each character area associated with a touch-sensitive input area. As region 70 dedicated to selectable characters is much too small to display all characters of a standard keyboard, input from thumbwheel 18 allows a user to pan region 74 displaying an entire virtual standard keyboard. Movement of thumbwheel 18 in one direction pans the character region horizontally, and movement in the other direction pans the character region vertically. When an end is reached the window pans onto the virtual keyboard from the other end. In this manner, a user may quickly pan the character window to display an entire standard keyboard, and make selections with a finger or a stylus. Of course, it is not required that a virtual keyboard be laid out for access in the format of a standard keyboard. Characters and punctuation, etc., could just as simply be displayed in a single strip along a region of the display, and scrolled by input from the thumbwheel or other pointer-type input device.

In this embodiment, to avoid delays caused by panning, if the thumbwheel is rotated quickly the character window jumps rather than scrolling to speed up the interface. In addition, menu 70 may optionally provide for a character display in different fonts and sizes, although a single font is preferred to minimize memory demand. It will be apparent to those with skill in the art that there are many alternatives for character selection and display, and many ways thumbwheel 18 may be configured to allow for scrolling and panning.

A document window 72 is provided in this embodiment at the top or bottom of I/O interface 16. A cursor locates the active position within the document for editing purposes. Menu 70 provides selection of available fonts, and input by thumbwheel 18 controls cursor movement over the document. As a document will in almost all cases be much larger than the display capability of region 72, it is necessary to pan the document window in essentially the same manner as the keyboard window is panned. For example, rotating thumbwheel 18 in one direction may display horizontal strips of a document, while rotating the thumbwheel in the opposite direction moves the window vertically strips of the same document.

A soft key or optional hard key may be configured to switch between the document and keyboard window, and the same or another key may be configured to switch between scrolling left or right, up or down, document or keyboard. A switch key may be used to change the thumbwheel mode of operation. A switch key may also be used in combination with a floating pointer to select characters and menu items. In this embodiment, the user can keep his or her hands relatively stationary on just the thumbwheel and the switch key, making all possible selections. Use of a switch key in combination with a floating pointer facilitates the use of small fonts. A switch key may also be incorporated as an additional hard key in a convenient location on the case 12.

It will be obvious to a person skilled in the art than there are numerous ways to combine menu selections, switching keys and I/O configurations to provide a user-friendly user interface. A further embodiment of the present invention provides an I/O set-up application wherein a user may completely customize features of I/O area displays.

There are other sorts of mechanical interfaces which may be used to provide pointer-style input in different embodiments of the invention as alternatives to the thumbwheel disclosed. One is a four-way force-sensitive mouse button and a selector button, which may be located at opposite ends of case 12 below I/O interface 16. Each button is designed to be operated by one finger. The four-way force-sensitive mouse button can provide menu scrolling of a cursor and panning and/or indexing of keyboard and document windows, while the selector button is used to select and edit according to position of a cursor. This configuration minimizes hand movement and keeps the I/O area clear for viewing.

Implementation of thumbwheels, pressure-sensitive switches and buttons, and the like, are known in the art, including the translation of mechanical motion and pressure to electrical signals and provision of such signals to a microcontroller. For this reason, details of such interfaces are not provided in this disclosure. Combinations of such inputs with displays and input areas may, however, be considered as inventive.

FIG. 5 is an isometric drawing of a .mu.PDA 10 in position to be docked in a notebook computer 172 via a Type II PCMCIA docking port 105 according to an embodiment of the present invention. As further described below, once the .mu.PDA is docked, it is activated and a procedure is initiated with the host computer to manage communication and verify memory access rights (security).

Access rights are considered important by the inventors for a number of reasons. Firstly, through the expedient of one or more specific codes, unique to each .mu.PDA, a user may protect files stored in his module from access by unauthorized persons. The code can be used both to control access to data and files via I/O interface 16, and also through the host bus interface, so data and files may be secure from access by an unauthorized host system.

In the former case, when a .mu.PDA is powered up, an application routine can query the user for an access code to be entered at I/O interface 16 FIG. 4). If the code is not entered properly, access is denied, and power goes off. Codes for the purpose are stored in EEPROM 31 (FIG. 3), or in whatever ROM device may be devoted to the purpose. In some embodiments, the code may by mask-programmed at manufacture, so it is not alterable. In others, the code may be accessible and changeable by special procedures in the field.

In the case of host communication, it is possible that a portable or desktop computer, or some other device, may have a docking port physically configured to receive a .mu.PDA, yet not be configured to communicate with the .mu.PDA. This certainly might be the case where the .mu.PDA is in the PCMCIA form. For purposes of disclosure and description, this specification terms such a unit a generic host. If the unit is configured to communicate with a .mu.PDA it is an enabled host. If a host is configured for full access to a particular .mu.PDA, it is a dedicated host.

If a docking unit is a generic host, there will be no communication unless the person presenting the .mu.PDA provides the control routines to the host. This may be done for a generic host such as by transfer from a floppy disk, from a separate memory card through the docking port, or, in some embodiments, the communication software may be resident in memory 13 (FIG. 3) of a docked .mu.PDA, transferrable to the host to facilitate further communication.

If the docking unit is in fact an enabled host, or is configured after docking to be an enabled host, the stored code or codes in EEPROM 31 (or other storage unit) may be used to verify authorization for data and program transfer between the host and a .mu.PDA. In one embodiment this procedure is in the following order: First, when one docks a .mu.PDA in a compatible docking port, certain pin connections convey to both the .mu.PDA microcontroller and to the host CPU that the module is docked. Assuming an enabled host, the fact of docking commences an initialization protocol on both systems.

In most embodiments, if the docking unit is a non-host, that is, it is not capable of communication with the docked module, nothing happens, and the user may simply eject the docked module. If the computer is an enabled host, an application is started to configure host access to the .mu.PDA's data files through the .mu.PDA microcontroller. A user interface, described more fully below for a particular embodiment, is displayed on the host monitor 104 (FIG. 5). The host interface menu, as well as other application menus, may be formatted in part as a display of the .mu.PDA I/O interface 16 as seen in FIG. 4 and described in accompanying text. In some embodiments, the docked .mu.PDA can be operated in situ by manipulating the input areas of the .mu.PDA displayed on the host's screen.

If the host is not a home unit for the docked module, that is, the host does not have matching embedded ID codes to those stored in the docked module, a visitor protocol is initiated. In this event, a visitor menu is displayed on host display 104 for further input, such as password queries for selections of limited data access areas in the docked module. In this case, too, a user may gain full access to the docked module's memory registers by entering the proper password(s).

If the host is a fully compatible host home unit, full access may be immediately granted to the host to access memory contents of the docked module, including program areas; and both data and programs may be exchanged.

In any case, when the .mu.PDA is ejected or otherwise removed from the docking port, the on-board module microcontroller again gains full control of the internal .mu.PDA bus structures.

FIG. 6 is a simplified block diagram of a .mu.PDA docked in a host computer, and FIG. 7 is a basic logic flow diagram of the steps involved in docking a .mu.PDA in a host computer 66 according to an embodiment of the present invention. Host computer 66 is represented in a mostly generic form, having a host CPU 24, and input device 60, such as a keyboard, a mass storage device 28, such as a hard disk drive, and system RAM 62. It will be apparent to those with skill in the art that many hosts may have a much more sophisticated architecture, and the architecture shown is meant to be illustrative.

When a .mu.PDA unit is docked, connector 14' in FIG. 6 comprises portion 14 shown in FIGS. 1B and 3 and a mating connector portion for engaging portion 14 in port 105 (FIG. 5). The engagement of the separate portions of the connector cause bus 26 in the .mu.PDA and bus 26' in the host to become directly connected. There is then a direct bus path between microcontroller 11 and host CPU 24 (FIG. 6).

As previously described there is a pin configuration (not shown) in connector 14 dedicated to signalling that a module is docked. In FIG. 7, step 42 represents insertion of a .mu.PDA module into the docking port. At step 44 the signalling pin configuration signifies physical docking is accomplished. At step 46 host interface bus 26 is activated, including the mated host bus 26' in the host.

At step 48 (FIG. 7) microcontroller 11 in the .mu.PDA starts a preprogrammed POST procedure. Microcontroller 11 in this embodiment has a page of RAM 68 implemented on the microcontroller chip. In other embodiments RAM may be used at other locations. At step 50, the POST routine loads a bootstrap program to RAM 68, which includes a code or codes for security matching. This code or codes comprise, for example, a serial number.

At step 54 the bootstrap program begins to execute in microcontroller 11, and at step 56 the microcontroller looks for a password from the host on host interface bus 26 (FIG. 6).

The fact of docking, assuming an enabled or dedicated host, also causes a communication routine, which may be accessed from, for example, mass storage device 28 at the host, to display a user interface on monitor screen 104 of the host unit, as partly described above. It is this communication program that makes a generic host an enabled host.

Assuming an enabled, but not dedicated, host, the user interface will query a user for input of one or more passwords, after successful entry of which the host will pass the input to microcontroller 11 for comparison with the serial number and perhaps other codes accessed from EEPROM 31 in the bootstrap of the .mu.PDA.

According to the codes passed from the host to the docked module, microcontroller 11 will allow full access to memory 31 at function 52, FIG. 7, for the host CPU, or limited access at some level at function 58, defined by received codes (or no matching code at all).

The access protocols and procedures allowing partial or direct access to .mu.PDA memory 13 are relatively well known procedures in the art, such as bus mastering techniques, and need not be reproduced in detail here. In addition to simple comparison of codes, there are other techniques that may be incorporated to improve the integrity of security in the communication between a .mu.PDA and a host. For example, within the limitation of storage capacity of the EEPROM or other nonvolatile source, executable code might also be uploaded to onboard RAM 68, or code keys to be used with executable code from other sources, or relatively simple maps re-allocating memory positions and the like, so each .mu.PDA may be a truly unique device.

There are additional unique features provided in one aspect of the invention as part of the communication routines introduced above. One such feature is automatic updating and cross-referencing of existing files and new files in both computers, under control of the host system, with the host having direct bus access to all memory systems. Auto-updating has various options, such as auto-updating by clock signature only, flagging new files before transfer, and an editing means that allows the user to review both older and newer versions of files before discarding the older in favor of the newer. This automatic or semiautomatic updating of files between the satellite and the host addresses a long-standing problem. The updating routines may also incorporate a backup option to save older files.

Another useful feature in host/.mu.PDA communication is a means for a user to select and compose a mix of executable program files for downloading to a .mu.PDA, either replacing or supplementing those executable routines already resident. A user can have several different program lists for downloading as a batch, conveniently configuring the applicability of a .mu.PDA among a wide variety of expected work environments.

Such applications as databases, spreadsheets, documents, travel files such as currency converters, faxing and other communications programs, time clocks, address and telephone records, and the like, may comprise customized lists of user-preferred applications.

In another embodiment, an undocked .mu.PDA can transfer data via the optional expansion bus 40 (FIG. 3) directly to a host. In the special case of a .mu.PDA user without access to a PCMCIA interface on his host (notebook or desk-top) computer, he or she can connect to a host via an auxiliary port on the host, such as a serial port, via the expansion bus interface. In this case, the .mu.PDA still requests password(s) from the host, and controls access to its on-board memory according to the password(s) received.

The optional expansion interface may also be used in some embodiments while a .mu.PDA is mastered by a host, wherein the host may effectively send data through the bus structures of the .mu.PDA.

Software Vending Machine

In a further aspect of the invention, a Software Vending Machine with a very large electronic storage capacity is provided, wherein a .mu.PDA user may dock a module and purchase and download software routines compatible with the .mu.PDA environment.

FIG. 8 is an isometric view of such a vending machine 61 having a docking bay 63 for a .mu.PDA, a credit card slot 65, and a paper money slot 67. A display 69 provides a user interface for reviewing and purchasing software from the vending machine, along with selector buttons such as button 71 along the sides of the display. In an alternative embodiment the display may also have a touch screen, and may, in some embodiments, emulate the .mu.PDA I/O area on a larger scale.

In operation, a user may, in this embodiment, review software for sale simply by docking his .mu.PDA unit in the vending machine and selecting from a menu on display 69. The menu may allow the user to browse all available applications, or list new applications since entered dates. The user can select certain applications, try them out, at least in simulation, and then select applications to purchase.

The vending machine, once all the requirements are met, such as proper identification and payment, copies the selected application(s) to the memory of the .mu.PDA, or, alternatively, to a floppy disk provided by either the user or the vending machine. In this case there is also a floppy disk drive 73 in the vending machine and a port 75 for dispensing formatted floppies for a customer to use in the disk drive. This mode is useful for the instances where a user's .mu.PDA is loaded beyond capacity to receive the desired software, or the user simply wishes to configure the software mix himself from his or her own host computer.

There may also be provided a backup option so a user may instruct the vending machine to read and copy all or a selection of his files to one or more floppy disks before installing new files or data.

As described above, each user's .mu.PDA includes an EEPROM or other storage uniquely identifying the .mu.PDA by a serial number or other code(s), so the vending machine may be configured in this embodiment to provide the software in one of several modes.

A user may buy for a very nominal price a demo copy of an application, which does not provide full capability of the application, but will give the user an opportunity to test and become familiar with an application before purchase. Also, the user may buy a version of the same application, configured to the ID key of the .mu.PDA to which it is loaded, and operable only on that .mu.PDA. In another embodiment, the software is transferable between a family of keyed .mu.PDAs, or has the ability to "unlock" only a limited number of times. In these cases, the applications would be sold at a lesser price than an unlocked version. The unlocked version works on any .mu.PDA and/or host/.mu.PDA system. The higher price for the unlocked version compensates for the likelihood of unauthorized sharing of the vended applications.

The vending machine could also offer a keyed version, customized to operate only on the .mu.PDA docked in the software vending machine, or upon a family of .mu.PDAs. This keyed version is possible because of the individual and unique nature of each .mu.PDA, which has, at a minimum, a unique serial number, and may also have other security programming, as described above, which allows a vending machine to prepare and download a customized copy of an application that will operate only on the particular module for which it is purchased.

There are a number of different means by which unique correspondence might be accomplished, as will be apparent to those with skill in the art. A standard version stored in the memory facility of a vending machine might be recompiled, for example, on downloading, using a unique code from the docked or identified .mu.PDA as a key in the compilation, so only the specific .mu.PDA may run the program by using the same unique key to sequence the instructions while running. The key for scrambling or otherwise customizing an application might also comprise other codes and/or executable code sequences stored uniquely in a .mu.PDA.

In yet another aspect related to the vending machine, there is a printer outlet 77 which prints a hardcopy manual for the user. It is, of course, not necessary that the software vended be specific to the M-PDA. Applications may also be vended for other kinds of machines, and transported in the memory of the .mu.PDA, or by floppy disk, etc. In this embodiment a non-.mu.PDA user can acquire a wide assortment of software.

The software vending machine may also serve as an optional informational display center in such locations as airports, train stations, convention centers, and hotels. Upon inserting a .mu.PDA a user may interface directly and upload current information including, but not limited to, local, national, and world news; stock quotes and financial reports; weather; transportation schedules; road maps; language translators; currency exchange applications; E-mail and other direct on-line services.

A customized vending machine could be tailored to business travelers and allow fast access to pertinent information, allowing the user to download files to send via E-mail. In another aspect of the invention, the vending machines are linked to each other allowing users to send messages to associates travelling through locations of associated vending machines. Such dedicated .mu.PDA E-mail is immediately downloaded to a specific .mu.PDA as it is docked. The sender may have the associate's .mu.PDA unique encoded key as identification, or some other dedicated identifying means for E-mail.

In another embodiment, as each business associate arrives at an airport, he or she may prompt the custom vending machine in that location via an optional installed infrared interface (not shown) in their .mu.PDA. The custom vending machine, also equipped for infrared communication, receives the signal and sends/or receives any messages that are waiting.

Enhanced Display

FIG. 9 is a plan view of an enhanced I/O interface unit 79 according to an aspect of the present invention. Interface unit 79, with about a 5-inch diagonal measurement, comprises a combination LCD display at least partially overlaid by a touch-sensitive input screen, providing an I/O area 80 in much the same manner as in a .mu.PDA. Four docking bays 81, 83, 85, and 87 are provided in the left and right edges of interface unit 79 in this embodiment, and are configured for PCMCIA type II modules. One of these bays may be used for docking a .mu.PDA according to the present invention, and the other three to provide a larger CPU, additional memory, battery power, peripheral devices such as modems, and the like by docking functional PCMCIA modules.

Interface unit 79 is a framework for assembling a specialty computer through docking PCMCIA units, including a .mu.PDA according to the present invention. In other embodiments where the .mu.PDA assumes other form factors, the docking bays may be configured accordingly.

A clocked .mu.PDA in this embodiment is configured to produce its I/O display on I/O area 80. The thumbwheel on the M-PDA is accessible while docked and acts as described above in the stand-alone mode in this case. In another aspect, the enhanced display has a re-configured output that enables the user to manipulate the data from the touch-screen alone and/or additional hardware selector buttons and/or a standard keyboard attached to the enhanced display via a dedicated bus port, or even through the expansion port of a docked .mu.PDA. In a further embodiment the enhanced display has a dedicated mouse port and/or a dedicated thumbwheel.

In yet another embodiment, interface unit 79 has an inexpensive, conventional, replaceable battery and/or a rechargeable battery. Also, in another aspect, interface unit 79 may dock two or more individual .mu.PDAs and cross-reference data files between them according to control routines that can manipulate mutually unlocked files. Further still, interface unit 79 may be placed and structurally supported for easy viewing on a dedicated standard or smaller-sized keyboard, connecting to the keyboard as an input device. The keyboard would then automatically serve as the input device.

Interface unit 79 for a .mu.PDA is small and compact enough to slip into a pocket book or briefcase, providing a very portable, yet very powerful, computer.

Migrophone/Voicenotes

FIG. 10 is a plan view of a .mu.PDA 110 with an I/O interface 116, an expansion port 120, and a host interface connector 114. .mu.PDA 110 has all the features previously described and additionally a microphone 88. In this embodiment, control routines in the .mu.PDA use a linear predictive coding (LPC) approach to convert analog input from the microphone to a digital voice recording. This approach uses a minimum of memory, but still is capable of reproducing audio input like the human voice within recognizable limits.

In an alternative embodiment, for better quality voice recording, a two-step integrator may be used in order to separate the analog signal and synthesize a closer digital representation.

With a .mu.PDA so configured, a user's voice notes can be recorded and later uploaded to a host for processing. In future embodiments the digital signals may be converted to text or sent as voicemail on a network. In yet another embodiment, the microphone is integrated with a speaker for editing purposes.

Cellular Telephone Interface

FIG. 11 is an isometric view of a .mu.PDA 10 docked in a dedicated cellular telephone 45 according to an embodiment of the present invention. Telephone 45 has a docking port 49 for a .mu.PDA according to the invention. In this embodiment, port 49 is on one side of telephone 45, and there is a window 51 to provide access to I/O interface 16 of the .mu.PDA after it is docked. With the .mu.PDA docked, all of the software and memory of the .mu.PDA is available to the telephone and a user may operate the phone by I/O interface 16.

In this aspect of the invention, unique control routines and display configurations are provided to enhance use of the cellular phone. For example, all of the user's collection of phone numbers, associated credit card numbers, access codes, etc. are readily available and may be quickly and conveniently accessed and used. In one aspect, a simple input displays alphabet letters to select, and once a letter is selected, a partial list of parties that might be called is displayed. One may scroll through the list by touch input or by use of the thumbwheel of the .mu.PDA and select a highlighted entry. It is not required that the telephone numbers be displayed.

Once a party to be called is selected, the .mu.PDA dials the call, including necessary credit card information stored in the memory of the .mu.PDA for this purpose.

In a further embodiment, the calls are timed and time-stamped and a comprehensive log, with areas for notes during and after, is recorded.

In another embodiment, conversations are digitally recorded and filed for processing later. A future embodiment may include a voice compression program at a host or within cellular phone 45. Compressed voice files, such as, for example, messages to be distributed in a voicemail system, may be downloaded into the .mu.PDA or carried in a larger memory format inside the cellular telephone. The .mu.PDA can then send the files via a host or dedicated modem attached at connector portion 20 to the optional expansion bus 40 (FIG. 6).

The cellular telephone may, in this particular embodiment, have a bus port for digital transmission. In this case, the compression algorithm along with voice system control routines are also established at the receiving end of the transmission to uncompress the signal and distribute individual messages.

In a further embodiment, voice messages may be sent in a wireless format from the cellular telephone in uncompressed digital synthesized form, distributing them automatically to dedicated receiving hosts, or semi-automatically by manually prompting individual voicemail systems before each individual message. In a further aspect of wireless transmission, a microphone/voicenote .mu.PDA as in FIG. 10 may send previously stored voicenotes after docking in a cellular telephone interface.

In Europe and Asia a phone system is in use known as CT2, operating on a digital standard and comprising local substations where a party with a compatible cellular phone may access the station simply by being within the active area of the substation. In one aspect of the present invention, a CT2 telephone is provided with a docking bay for a .mu.PDA, and configured to work with the .mu.PDA. In yet another aspect of the invention, in the CT2 telephone system, and applicable to other digital telephone systems, a compression utility as disclosed above is provided to digitally compress messages before transmission on the CT2 telephone system.

It is roughly estimated that a dedicated compression algorithm may compress ten minutes of voice messages into one minute using the existing CT2 technology. This would save on telephone use charges significantly. In this aspect, there needs be a compatible decompression facility at the receiving station, preferably incorporated into a standard .mu.PDA voicemail system for CT2 or other digital transmissions.

In a further embodiment, control routines are provided to enable the microphone/voicenote .mu.PDA as illustrated in FIG. 10 to carry digital voicenotes, either compressed or uncompressed. When docked in a CT2-compatible .mu.PDA cellular telephone, the .mu.PDA in this embodiment can transmit the digital voicenotes in compressed form.

Speaker/Pager

FIG. 12 is a plan view of a .mu.PDA 210 with a microphone/speaker area 90 and a pager interface 92 according to an embodiment of the present invention. This .mu.PDA has the ability to act as a standard pager, picking up pager signals with installed pager interface 92 and alerting a user through microphone/speaker 90. Once the signals are received, .mu.PDA 210 can be docked in a compatible cellular telephone as illustrated in FIG. 11 and the .mu.PDA will automatically dial the caller's telephone number. All other aspects are as described in the docked mode in the cellular telephone.

In another embodiment, the speaker/pager .mu.PDA can be prompted to generate DTMF tones. The DTMF tones are generated from a caller's telephone number.

The speaker/pager .mu.PDA can store pager requests in its onboard memory. It can also display all pager requests including time and date stamps, identification of the caller, if known, and other related information, on I/O interface 216. In this particular embodiment, a user can receive a page, respond immediately in digital voicenotes on the .mu.PDA via speaker/microphone 90, and then send the response from a dedicated .mu.PDA-compatible cellular telephone or conventional telephone.

Wireless Infrared Interface

FIG. 13 is a plan view of a .mu.PDA 310 with an IR interface 94 according to an embodiment of the present invention. In this embodiment the .mu.PDA may communicate with an array of conventional appliances in the home or office for providing remote control. Unique signals for the appliances are programmed into the .mu.PDA in a learning/receive mode, and filed with user password protection. Once a correct password in entered, an icon-based menu is displayed on I/O area 316 in a user-friendly format. A master routine first queries a user for which device to access. For example, in a residential application, icons are displayed for such things as overhead garage doors, security systems, automatic gates, VCRs, television, and stereos.

In another aspect of the invention, a receiving station such as a host computer or peripheral interface has IR capabilities to communicate data directly from a nearby .mu.PDA with an infrared interface. In a further embodiment the .mu.PDA may interface in a cellular network and act as a wireless modem.

A .mu.PDA may serve as the platform for various peripheral attachments via expansion port 20 (FIG. 1B and others). Upon attachment to a peripheral, a dedicated pin or pins within expansion port 20 signal microcontroller 11, and a peripheral boot-strap application is executed. Interfacing control routines, which may reside in the peripheral or in the memory of the .mu.PDA, are then executed, and the .mu.PDA I/O interface displays the related menu-driven options after the linking is complete.

Scanner

FIG. 14 is a plan view of a .mu.PDA 10 with a scanner attachment 55 according to an embodiment of the present invention. The scanner attachment is assembled to the .mu.PDA, making electrical connection via expansion port 20. In this embodiment the physical interface of the scanner is shaped to securely attach to the .mu.PDA. Scanner attachment 55 has a roller wheel 57 or other translation sensor, which interfaces with wheel 18 of the .mu.PDA, providing translation sensing in operation for the resulting hand-held scanner. In another aspect, scanner attachment 55 has a translation device which transmits the proper signal through expansion port 20. The scanner bar is on the underside, and one or more batteries 59 are provided within the scanner attachment to provide the extra power needed for light generation.

In the scanner aspect of the invention, scanner attachments 55 of different width D2 may be provided for different purposes. The bar may be no wider than the .mu.PDA, or may be eight inches or more in width to scan the full width of U.S. letter size documents, or documents on international A4 paper. Unique control routines display operating information on the .mu.PDA's I/O area 16 for scanning, providing a user interface for setup of various options, such as the width of the scanner bar, and providing identification for files created in the .mu.PDA memory as a result of scan passes. Scanned data stored in the .mu.PDA memory may be quickly transferred to the host via host interface 14 when the .mu.PDA is docked. Unique routines may be provided to automate the process, so the user does not have to search for files and initiate all of the transfer processes.

Facsimile Option

FIG. 15 is a plan view of a .mu.PDA with a fax-modem module 89 attached according to an embodiment of the present invention. A fax and telecommunication capability is provided via conventional telephone lines to the .mu.PDA by fax-modem 89 interfacing to expansion bus interface 20. The fax-modem has internal circuitry for translating from the bus states of the expansion bus to the fax protocol, and a phone plug interface 91. In another aspect, the .mu.PDA can be docked in a host and be used in combination with fax-modem 89 to provide faxing and file transfers of both host and .mu.PDA data files. In this case, the fax-modem routines are displayed on the host monitor.

Printer

FIG. 16 is a plan view of a .mu.PDA with a Centronics adapter interface according to an embodiment of the present invention. A printer connector 93 engages expansion interface 20 by a connector 95 through a cable 97. Translation capability resides in circuitry in connector 93, which is configured physically as a Centronics connector to engage a standard port on a printer.

Barcode Reader and Data Acquisition Peripheral

FIG. 17 is an isometric view of a .mu.PDA 10 docked in a barcode reader and acquisition peripheral 100 according to an embodiment of the present invention. .mu.PDA 10 is docked in docking bay 149. I/O interface 16 displays information through opening 147 according to specialized data acquisition applications. In this particular embodiment peripheral 100 has an IR interface 94, a microphone 103, a scanner port 101 (riot shown), battery pack 105, and a numeric keypad pad 96 implemented as a touch-sensitive array.

Application routines enable the data acquisition peripheral to operate as, for example, a mobile inventory management device. The user may scan barcode labels with scanner 101 and enter information, such as counts, on keypad 96 or by voice input via microphone 103. Since applications of peripheral 100 are very specialized, only a limited voice recognition system is needed. The voice recognition system may prompt other command routines within the master applications as well.

As inventories are collected, the database may be displayed and also manipulated directly via I/O area 16 in open bay 147, or information may be downloaded at a prompt to a nearby host via IR interface 94.

Alternatively to frequent data transmission, data may be stored or an auxiliary option memory location in peripheral 100.

In another aspect, the data acquisition peripheral may be interfaced to the analog output of a monitoring device, such as a strip chart recorder, and may digitize and store the incoming analog signals.

Solar Charger

FIG. 18 is an isometric view of the side of a .mu.PDA 10 opposite the I/0 interface with a solar charger panel 98 according to an embodiment of the present invention. Panel 98 is positioned so that when .mu.PDA 10 is in strong light, such as sunlight, the solar charger absorbs the solar energy and converts it to electricity to recharger battery 15 inside the .mu.PDA. Solar charger 98 may be permanently wired to the circuitry of the .mu.PDA or attached by other means and connected to a dedicated electrical port or the expansion port. The solar charger is placed so that the .mu.PDA can be fully docked in a docking port with the panel in place. In another aspect, a detachable solar charger may be unplugged before docking the .mu.PDA, and the detachable charger may then be of a larger surface area.

Games/Conference Center

FIG. 19 is a largely diagrammatic representation of a Games Center unit 33 according to an aspect of the invention for connecting several .mu.PDA units (37, 39, 41, and 43) together to allow competitive and interactive games by more than one .mu.PDA user. Games Center unit 33 is controlled by an 80486 CPU in this particular embodiment. .mu.PDAs may be connected to the central unit by cable connection via the expansion bus or the host interface of each .mu.PDA, through a connector such as connector 35. The drawing shows four connectors, but there could be as few as two, and any convenient number greater than two.

As a further aspect of the present invention, the gaming center may serve as a conference center where a number of .mu.PDAs may exchange information. In this way, for example through custom routines stored and executable in central unit 33, a manager may update a number of salespeoples' .mu.PDAs, including but not limited to merchandise databases, spreadsheets, price sheets, work assignments, customer profiles, address books, telephone books, travel itineraries, and other related business information while in conference.

Standard Keyboard

FIG. 20 is an isometric view of a keyboard 151 connected by a cord and connector 153 to a .mu.PDA 10 via the expansion port 20. In this example, the keyboard is a mechanical keyboard having a full-size standard key array and an on-board controller and interface for communicating with the .mu.PDA. In other embodiments the keyboard may take many other forms, including a two-layer, flexible, roll-up keyboard as taught in U.S. Pat. No. 5,220,521.

In addition to keyboards, other input devices, such as writing tablets and the like may also be interfaced to a .mu.PDA via expansion port 20.

There are numerous additional ways to combine different embodiments of the .mu.PDA for useful functions. For example, an IR-equipped .mu.PDA attached to scanner 55 may transfer large graphic files in near real time to a host computer. If the files were of text, the host may further process the files automatically through an optical character recognition (OCR) application and send the greatly reduced ASCI files back to the .mu.PDA. As discussed above, the .mu.PDA family of devices establishes a protocol of software security and distribution as well as having the ability to be bus mastered by a host computer system for numerous applications.

Removable Pointer Devices

One of the difficulties faced in the design and development of a miniature computer product, such as a hand-held .mu.PDA as described in much detail above, is in the implementation and connection of input devices. Pointer devices fall into this category, and a number of unique options and alternatives are described herein below for pointer devices storable in and deployable from portable computers. The descriptions below are illustrated primarily with reference to what are known as notebook-type computers, but are considered by the inventors to be equally applicable to hand held devices such as the .mu.PDA devices describes in this specification.

FIG. 21A is an isometric view of a notebook-type computer 1010 with a compartment 1012 having a closure 1018, for storing a pointer device 1014 when the pointer is not needed. The compartment is shown on one side of the housing of the computer, but could as easily be located elsewhere, and there a variety of ways the closure could be provided. The pointer may be any one of many sorts, such as joystick, trackball, or mouse device.

FIG. 21B is an isometric view similar to FIG. 21A showing a mouse-type pointer device 1020 deployed for use from compartment 1012, and connected to the host computer by a cable 1022. The cable may be stored in this case in compartment 1012 along with the pointer device. There are also alternative ways the cable might connect, such as at a parallel or a serial port on the host.

FIG. 21C is an isometric view of a notebook computer showing a cordless mouse device 1022 storable in compartment 1012 and deployed for use. There are several ways communication may be handled for the pointer device in this embodiment. In the embodiment of FIG. 21C the pointer has an infra-red transmitter and the host has an infra-red receiver 1024.

FIG. 21D is an isometric view of a notebook computer showing a trackball pointer device 1028 connected to the host by a cable 1030. The communication system in this case is the same as for a mouse-type device as described above.

FIG. 21E is an isometric view of a notebook computer showing a cordless trackball device 1032 deployed for use. The cordless trackball in this embodiment employs an infra-red coded transmission system sending code according to trackball movement to receiver 1024 at the host.

FIG. 21F is an isometric view of a notebook computer showing a combination pointer/trackball device 1034 deployed for use and connected by a cable 1036 to the host. This device is a combination device operable as a trackball in one orientation, and as a mouse device when inverted so the trackball may make contact with a flat surface. Further details of the combination are described below with reference to FIGS. 25 A-D.

FIG. 21G is an isometric view of a notebook computer showing a combination trackball/pointer device 1038 with cordless communication, and deployed from compartment 1012 for use. In this case, the communication system is infra-red, and there is a receiver 1024 on the host.

FIG. 21H is an isometric view of a general-purpose portable computer 1011 with a removable pointer device 1017 according to an embodiment of the present invention. Computer 1011 comprises a housing 1015 and a tilt-up display 1013. The computer housing encloses standard electronic operating elements, such as a CPU microprocessor and system RAM, not shown in FIG. 21H. There are connectors (not shown) to serial devices and the like, which are typical for portable computers. A keyboard unit 1019 provides a for user input. Removable pointer device 1017, inset in well 1016 in the housing, comprises a trackball design including a rotatable ball 1021 to transmit directional information to the host, left and right control buttons 1023 and 1025 for discrete signalling, and a drag control button 1027. The purpose of drag control button 1027 is to signal that trackball movement is to be directed toward dragging an onscreen virtual object, a procedure well known in the art. Concave depressions 1029 and 1031 on opposite sides of well 1016 allow space for a user to grasp the removable pointer device to snap it in and out of the well so it can be used as a separate unit.

The transmission medium between removable pointer and host in this embodiment is infrared, which is transmitted from a light-emitting diode (LED). Two photodiode receivers are imbedded in the computer housing, one in a wall of the well for stationary mode reception (not shown in FIG. 21H) and one receiver 1033 in the front of the housing for portable mode reception. The photodiode receivers are connected with a common circuitry within the host computer.

FIG. 21I is an isometric view of computer 1011 with pointer device 1017 removed from the well in the housing, deployed for use external to the housing.

FIG. 22 is a plan view of removable pointer device 1017, showing LED transmitter 1024 inside the device facing photodiode receiver 1026 inside a wall of well 1016. In the side walls of well 1016, concave depressions 1029 and 1031 allow a user to grasp removable pointer device 1017 and snap it in or out of well 1016. The removable pointer device is held in place in this embodiment by light resistance provided by spring-loaded ball/detent pairs 1035 and 1037 on both sides of the device. Spring loading may originate from either the pointer device or in the wall of the well. Vertical guide rails along the well walls, not shown in FIG. 22, allow detents 1035 and 1037 to slide smoothly into the well and snap into place once seated. The method of docking and latching a removable pointer device into a location in the computer host is not limited to the description for this embodiment. There are known in the art many other equivalent ways that can satisfactorily perform such a function. For instance, instead of the pointer device being seated squarely in the well, the device can be inserted at a slant into the well and snapped down into a spring-loaded base. The device can be released by the user pressing an indentation near the base of the device. Another variation is for the well to open to the front of the housing so the pointer device can slide in and out on guide rails. Spring-loaded detents along the sides hold the device in place while it is docked in this embodiment.

FIG. 23 is a mostly diagrammatic representation of the internal components of removable pointer device 1017 for the embodiment described for FIGS. 21 and 22. Two rollers, 1045 and 1047, are mounted at right angles and bear against trackball 1021. As trackball 1021 rotates, roller 1045 responds to movements in a first direction and roller 1047 senses movements at 90 to the first direction. The rollers are connected to encoder wheels 1049 and 1051, which transmit signals relative to movement to controller 1065.

Removable pointer device 1017 is powered by a battery 1062 that is rechargeable in this embodiment by charger circuit 1060 when the pointer device is seated in well 1016. Battery charger 1060 receives electrical current from the computer host through a spring-loaded contact base, or any other suitable type of charging contact. In this embodiment a spring wiper contact 1043 is located on one side of the well and a fixed contact 1041 is on the side of the pointer. Contacts are well known in the art and there are many equivalent ways that such a contact can be configured. For example, in other embodiments there may be a female connector on the bottom of the pointer device that plugs into a male connector in the bottom of the host well. Such an arrangement not only serves as an electrical contact, but also holds the pointer device in the well, minimizing or eliminating the need for detents.

Signals produced from the trackball's motion are converted to infrared signals by microprocessor-based controller 1065 and output through LED transmitter 1024 to photodiode receiver 1026 in the well wall, or if the pointer is being used outside the well, photo diode receiver 1033 on the front side of the housing as shown in FIG. 21. Input signals from control buttons 1023, 1025, and 1027 are also processed by controller 1065.

FIG. 24 is a mostly diagrammatic representation of the internal components of a cordless removable pointer device 1068 in an alternative embodiment that uses magnetic induction as the medium of communication between pointer device and host. All electromechanical components in FIG. 24 are the same as those described for the FIG. 23 configuration except electrical signals from the encoders and control buttons are input by a microprocessor-based current controller 1090, which passes the current through a one-turn generator loop 1070, creating a magnetic field represented by exemplary field lines 1071. Receiving loop 1072, which is located in the host housing, transmits a magnetically induced current to a demodulator 1073, which forwards the coded signal to a controller.

There are a number of equivalent ways a receiving apparatus may be configured for reception by magnetic induction. For example, such an apparatus might be built into the case of the host computer, or implemented on an add-on printed circuit board. Also, FIG. 24 is largely diagrammatical, as stated above, and the transmission and receptor loops are not drawn to actual size relative to other components. In general, both loops are much larger than shown, and there may be more than a single turn in some embodiments.

In another embodiment of the invention, a cordless unit is provided having both stationary and portable mode features as described above relative to FIG. 21, and configured to operate both as a trackball and a mouse device. In this embodiment one side of the combined removable pointer device is a typical trackball unit and when the device is turned over, it may be used as a mouse. Operating mode is selected by a switch on the side of the device.

FIG. 25A is a plan view of a combined removable pointer device 1081. Pointer device 1081 comprises on the surface shown in FIG. 25A all the elements described for a trackball unit in the embodiment of FIGS. 21 and 22, with the addition of an operating mode switch 1091 on one side. The user moves switch 1091 to select between trackball and mouse operation. Trackball 1083, control buttons 1093, 1095, and 1089, LED transmitter 1099, and charging intact 1097 are located in the same positions as are their counterparts in the removable trackball of FIGS. 21 and 22.

FIG. 25B is a plan view of the opposite side of combined removable pointer device 1081. In this embodiment, control buttons 1101 and 1103 are flush with the outside surface of the body of the pointer device, so when used as a trackball, the device can sit squarely on a desktop surface or in its well. In a conventional trackball device, the rotator ball is not loosely mounted like that on a mouse so the ball does not naturally fall to the desktop surface when the unit is inverted. This problem is solved in the present embodiment by the relationship between the height of protrusion of the three pushbuttons on the side of trackball 1021, and the height of protrusion of the trackball.

FIG. 25C shows combination pointer device 1081 in contact with a flat surface 1082. Dimension D3 from the casing to the outer surface of any of the control buttons is greater than dimension D4 from the unit casing to the trackball. Slight pressure exerted on the unit causes spring-loaded control buttons 1089, 1093, and 1095 to depress bringing ball 1083 into contact with surface 1082, so lateral movement will cause the ball to rotate.

The phenomenon of riding on the spring-loaded buttons provides a new aspect of control in operating the pointer device as a mouse. For example, in the often-occurring situation with a mouse where surface area available for mouse operations is limited, the mouse often has to be picked up and repositioned on the operating surface. Picking up the mouse so the ball does not touch the operating surface insures that position signals are not transmitted while the mouse is repositioned. With a mouse according to this embodiment of the present invention, the mouse can be repositioned simply by relaxing the slight downward pressure necessary to cause the ball to contact the operating surface. This seems at first encounter to be a small difference, but translates to considerable advantage, especially in situations where the available operating surface is severely limited.

FIG. 25D is a mostly diagrammatic view of the internal components of combined removable device 1081. Internally the trackball and mouse input components share circuitry as shown for the removable pointer device embodiment in FIG. 23, with the addition of operating mode switch 1091 and control buttons 1101 and 1103.

In alternative embodiments, either a removable trackball device or a combined trackball-mouse device as described above may be connected to the host unit by a power cable. There are many ways a cable connection might be implemented for using such devices while removed from the well on the host. For example, at some point on the case of the host computer a small bay may have a cable electrically connected to the host bus and the cable wound on a small reel with a connector on the outward end for connecting to the pointer device when removed from the well. There are many equivalent ways a cable connection might be implemented. In an alternative embodiment, a pointer device sends polar coordinate location signals in response to movements made by a mechanically attached, extendable positional input bar. FIG. 26A is a plan view of such a polar coordinate pointer device 1599 stored in unextended form inside a compartment 1597 in host housing 1595. Positional input bar 1501, which passes through a sensored pivot 1503, can be extended from opening 1500 by the user pulling handle 1507. A preferred location for the device for a right-handed person is on the right side of the housing that contains keyboard 1594, but it could be located in any other place as well, such as on the left side for left-handed users. Operational control buttons 1596, 1597, and 1598 of the type typically used to control discrete pointer signalling, are located in another area of housing 1595 in this embodiment, such as on the left front side.

FIG. 26B is a plan view of polar coordinate pointer device 1599 in extended operating position. Positional input bar 1501 can be held by handle 1507 and freely moved in a horizontal plane over an area adjacent to the computer housing. A stop near the inboard end of positional input bar 1501 limits the maximum distance the bar can be extended. On the outboard end of positional input bar 1501, a pivoted handle 1507 is attached by a vertical pin. Such a handle could have any of a number of different shapes.

In one embodiment, grooved channels (not shown) along the length of the input bar engage mating guides in the pivot to prevent rotation of the bar around the longitudinal axis. There are a number of equivalent ways the engagement and guiding function may be accomplished.

Sensors at pivot 1503, track radial displacement of positional input bar 1501. Other sensors track rotation of the pivot mechanism, which is the angular displacement of positional input bar 1501. There are a number of types and arrangements of bar guides and sensors that would be suitable. Sensor information is transformed from polar coordinates to Cartesian coordinates, and used as pointer input in the same fashion that trackball or mouse positional input is used. Input from control buttons 1596, 1597, and 1598 in FIG. 26A, is interpreted just as control button input from a trackball or mouse device.

FIG. 26C is a graphic illustration of the geometry involved in the transformation of displacement measurements of positional input bar 1501 from R, .THETA. polar coordinates to x,y rectangular coordinates that can be used for screen cursor output. In FIG. 26C, points P.sub.1 and P.sub.2 represent two x,y positions of pivoted handle 1507 on positional input bar 1501 measured from pivot 1503 at P.sub.0. Point P.sub.1 is at radial distance R.sub.1 and angle .THETA..sub.1 from P.sub.0 ; point P.sub.2 is at radial distance R.sub.2 and angle .THETA..sub.2 from P.sub.0. The maximum radial distance, R.sub.max, the bar can be displaced is shown as a circular arc. Through transformation equations, x=R cos .THETA. and y=R sin .THETA., x,y positions of both P.sub.1 and P.sub.2 points can be calculated.

There are a number of variations to the pointer described with reference to FIGS. 26A, 26B, and 26C. For example, the pivot mechanism, bar, and handle could all be a part of a mechanism dockable in the computer case, and removable as a unit to be placed external to the computer and operated. In this alternative, the removable unit could be connected to the host by a cable, or could communicate by infra-red or inductive techniques.

FIG. 27A is a plan view of yet another alternative embodiment of the present invention, wherein a removable, cordless, pointer receives broadcast signals from multiple antennas in or on the host, and echos the signals to a receiver in the host in a manner that allows control circuitry to track the position of the moving pointer. The tracked position of the movable pointer is used in the manner that pointer input from other types of pointers is used.

FIG. 27A shows one edge of a body 1311 of a host computer, having a storage compartment 1313 and three antennas 1315, 1317, and 1319. A movable pointer device 1321 is storable in a compartment 1313 when not in use, and may be removed and deployed, as shown in FIG. 27A, for use.

FIG. 27B is a schematic of internal elements of device 1321, showing a rectifier circuit of two antennas 1323 and 1329 connected with capacitors 1325 and 1327, and a diode 1331. In operation in this particular embodiment, antennas 1315 and 1317 in the host are sending antennas, and antenna 1319 in the host is a receiving antenna.

In one mode of operation, a carrier wave of a common frequency and amplitude is broadcast by each of sending antennas 1315 and 1317, but the signals are broadcast at a pre-programmed phase shift. The rectifier circuit in the pointer device intercepts the broadcast signals, combines (sums) them, and echoes a rectified waveform having a frequency known in the radio arts as the Hull frequency. This signal is received at antenna 1319, where connected circuitry analyzes the signal to determine the position of the pointer relative to the broadcast and receiving antennas.

The receiving antenna intercepts both the original broadcast signals as well as the echoed signal, but the broadcast signals are at a much higher and known frequency than the echoed signal, and are filtered. FIG. 27D is a simplified illustration of an echoed signal 1333 at receiving antenna 1319.

Echoed signal 1333 exhibits an amplitude A.sub.e and a frequency (1/t.sub.e) that are indicative of the position of the pointer device. The amplitude is a function of the ratio of the distances to the pointer from each of the sending antennas, providing a locus, and the position on the locus is fixed by the frequency. The radio principles relied upon for the broadcast cursor are well known in the radio arts, and are no more detailed explanation is presented here.

The information contained in the echoed signal is sufficient to locate the position of the pointer device near the host in essentially real time, and circuitry to provide this information to the host computing elements in a manner to control a display cursor and the like, is well known.

FIG. 27C shows a broadcast pointer system comprising a host 1411, and three antennas 1415, 1417, and 1419, similar to that shown in FIG. 27A, wherein a stylus 1421 is employed rather than a mouse-type pointer. In this embodiment the rectifier circuitry shown in FIG. 27B is implemented in a region 1423 near the point of the stylus. The stylus embodiment operates in the same manner as does the mouse-type pointer described above, except the holding and manipulating of the pointer is in the manner of wielding a pen or a pencil, rather than a mouse. This embodiment provides a convenient way to input cursive writing and printing to the host computer. With appropriate circuitry monitoring and interpreting stylus movement, one may duplicate the functions of a pen-based input system. When not in use, stylus 1421 resides in a compartment 1413 in the host.

Removable pointer devices according to various embodiments of the present invention are particularly applicable to notebook and subnotebook computers. Such devices are not limited to portable computers, however. A removable pointer device as described in the several embodiments above may also be implemented in a keyboard usable with a host computer, such as a desktop or workstation computer, including terminals designed to be used as nodes on a network.

FIG. 28 is an isometric view of a keyboard 1211 having removable pointer device 1213 according to an the embodiment of the invention described above with reference to FIGS. 21A and 21B. Keyboard 1211 in this embodiment has a cable 1215 for attaching to a host, and communicating both keystroke and pointer data to the host, but may also be implemented with a keyboard that communicates in another manner with the host, such as by infrared signals or by inductance coupling.

In various embodiments of keyboards any and all of the embodiments described above relative to a host notebook-type computer may be implemented. In the case of a keyboard, it is usual to have a keyboard controller for coding keystroke data and imparting the data to the host. In the case of a removable pointer device in a keyboard, the pointer movement data is received by the keyboard controller and coded and passed to the host along with (multiplexed with) the keystroke data.

It will be apparent to one skilled in the art that there are a relatively large number of changes that may be made in the embodiments of pointer devices described herein without departing from the spirit and scope of the present invention. Some additions and alternatives have been mentioned above. Different embodiments, for example, can be rendered in different shapes and sizes, and there are many ways known for providing the needed electrical connections and for transmitting signals.

It will be apparent to one with the skill in the art that there are many changes that might be made and many other combinations that might be made without departing from the spirit and scope of the invention. There are, for example, many ways to implement the support structure of the .mu.PDA, and to interconnect the active components. One way has been illustrated by FIG. 2 and described in accompanying text. There are many alternatives to this preferred structure. There is also a broad range of sizes and form factors that might be assumed by devices according to the present invention. The use of well-known PCMCIA form factors has been disclosed, but other sizes and forms might also be provided in alternative embodiments. In larger embodiments, on-board peripherals may be implemented.

In addition to these alternatives, there are various ways the connectivity of a .mu.PDA bus might be provided. The well-known PCMCIA standard has been disclosed as a preference, but other connectivity may also be used in alternative embodiments. Memory types and sizes may vary. Means of providing a security code may vary. The nature of the internal bus may vary. There are many variations that do not depart from the spirit and scope of the invention.