U.S. patent application number 10/954744 was filed with the patent office on 2005-02-24 for micro personal digital assistant with a compressed bios system.
Invention is credited to Dornier, Pascal, Kikinis, Dan, Seiller, William J..
Application Number | 20050041385 10/954744 |
Document ID | / |
Family ID | 27361261 |
Filed Date | 2005-02-24 |
United States Patent
Application |
20050041385 |
Kind Code |
A1 |
Kikinis, Dan ; et
al. |
February 24, 2005 |
Micro personal digital assistant with a compressed BIOS system
Abstract
A personal digital assistant module with a local CPU, memory,
and I/O interface has a host interface comprising a bus connected
to the local CPU and a connector at a surface of the personal
digital assistant for interfacing to a bus connector of a host
general-purpose computer, providing direct bus communication
between the personal digital assistant and the host general-purpose
computer. In an embodiment, the personal digital assistant also has
a means for storing a security code. The personal digital assistant
according to the invention forms a host/satellite combination with
a host computer having a docking bay, wherein upon docking a
docking protocol controls access by the host to memory of the
personal digital assistant based on one or more passwords provided
by a user to the host. In another embodiment the personal digital
assistant has a compressed BIOS chip, and in yet another embodiment
also has an expansion port connected to the local CPU, and
expansion peripheral devices may be connected and operated through
the expansion port.
Inventors: |
Kikinis, Dan; (Saratoga,
CA) ; Dornier, Pascal; (Sunnyvale, CA) ;
Seiller, William J.; (Scotts Valley, CA) |
Correspondence
Address: |
CENTRAL COAST PATENT AGENCY
PO BOX 187
AROMAS
CA
95004
US
|
Family ID: |
27361261 |
Appl. No.: |
10/954744 |
Filed: |
September 29, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10954744 |
Sep 29, 2004 |
|
|
|
10335451 |
Dec 30, 2002 |
|
|
|
10335451 |
Dec 30, 2002 |
|
|
|
09785574 |
Feb 15, 2001 |
|
|
|
6523079 |
|
|
|
|
09785574 |
Feb 15, 2001 |
|
|
|
08683567 |
Jul 17, 1996 |
|
|
|
08683567 |
Jul 17, 1996 |
|
|
|
08144231 |
Oct 28, 1993 |
|
|
|
5835732 |
|
|
|
|
08683567 |
Jul 17, 1996 |
|
|
|
08019592 |
Feb 19, 1993 |
|
|
|
Current U.S.
Class: |
361/679.3 |
Current CPC
Class: |
H04N 1/00236 20130101;
G06F 9/445 20130101; H04W 88/02 20130101; G06F 21/73 20130101; G06Q
30/0601 20130101; H04M 1/72415 20210101; G06F 1/1635 20130101; G06F
1/203 20130101; G06F 1/169 20130101; H04N 1/00326 20130101; H04N
1/00241 20130101; H04N 2201/0049 20130101; H05K 5/0273 20130101;
H04N 2201/0081 20130101; G06F 21/62 20130101; H04M 3/42314
20130101; H04M 3/42323 20130101; H04N 1/00411 20130101; G06F 1/1626
20130101; H04N 1/107 20130101; G06F 3/0482 20130101; H04M 1/275
20130101; H04M 11/06 20130101; H04W 84/06 20130101; H04N 1/195
20130101; G06F 13/409 20130101; H04N 2201/0053 20130101; G06F
3/0362 20130101; H04N 2201/0063 20130101; G06F 1/206 20130101; H04N
1/00127 20130101; G06F 15/0225 20130101; H04N 2201/0082 20130101;
G06F 2221/2129 20130101; H04M 1/725 20130101; G06F 1/1632 20130101;
H04N 1/00339 20130101; G06F 1/1616 20130101; H04N 2201/0051
20130101 |
Class at
Publication: |
361/683 |
International
Class: |
H05K 005/00 |
Claims
What is claimed is:
1. A digital assistant module that interfaces with a host computer,
comprising: an on-board CPU that manages functions of the digital
assistant module; a memory connected to the CPU that stores data
and executable routines; a user-operable input apparatus; a host
interface adapted so as to provide communications between the
digital assistant module and the host computer upon docking with
the host computer, said host interface cooperating with a host
interface of said host computer whereby a user of said host
computer may select pre-arranged software mixes for loading into
said memory; and an enclosure that houses said CPU, said memory,
said input apparatus, and said host interface.
2. An information vending system, comprising: a data repository
having stored thereon at least one of an information entity and a
program entity; and a communication link by which a stored entity
may be streamed from a data repository to a handheld appliance;
wherein a user of the handheld appliance is enabled to connect the
handheld appliance to the data repository, to select for purchasing
at least one information entity or program entity stored on the
data repository, and to initiate payment for the selected entity,
and wherein the selected entity is streamed to the appliance in
response to the payment.
3. The vending system of claim 2 wherein, after the handheld
appliance is connected to the data repository, information
regarding one or more entities stored on the data repository is
displayed on a display of the handheld appliance.
4. The vending system of claim 2 wherein information relating to
the selected entity is displayed on a display of the handheld
appliance.
5. The vending system of claim 3 further comprising a vending
system display, wherein the information regarding the one or more
entities stored on the data repository is displayed on the vending
system display.
6. The vending system of claim 2 wherein the at least one stored
entity is a program, and the vending system displays for potential
purchase only stored entities that are compatible with the handheld
appliance.
7. The vending system of claim 2 wherein the handheld appliance has
a unique digital identifier that is transmitted to the vending
system when the handheld appliance is connected to the data
repository.
8. The vending system of claim 7 wherein, in response to the
transmission of the digital identifier, the vending system sorts
entities to be displayed for potential purchase according to the
identifier.
9. The vending system of claim 8 wherein the sorting causes only
information about entities that are compatible with the handheld
appliance to be displayed.
10. The vending system of claim 2 wherein the selected entity is s
stored in a memory of the appliance.
11. The vending system of claim 2 further comprising a
removable-media drive, wherein the selected entity is streamed to
the removable media drive and stored thereon.
12. The vending system of claim 2 wherein, prior to selection for
purchase, the user may select a trial version of an entity, which
is streamed free-of-charge or at a reduced price relative to a
regular purchase price associated with the entity.
13. The vending system of claim 11 wherein the user may command the
vending system to access one or more selected programs or files
from the handheld appliance to be stored on a media in the
removable-media drive prior to selecting any entity for trial or
purchase.
14. The vending system of claim 7 wherein a program entity
purchased from the vending system will operate only on the handheld
appliance or a selected subset of like appliances.
15. The vending system of claim 14 wherein the unique identifier is
used as a key or a portion of a key in scrambling or customizing a
purchased entity.
16. The vending system of claim 2 wherein the information entity
includes at least one of local, national, or world news, stock
quotes, financial reports, weather, transportation schedules, road
maps, and email or other messages for the user of the handheld
appliance.
17. The vending system of claim 2 wherein the program entity
includes at least one of a currency exchange application and a
language translator.
18. The vending system of claim 2 wherein the communication link
comprises a wireless link.
19. The vending system of claim 18 wherein the wireless link
comprises at least one of an infrared (IR) link and a radio
frequency (RF) link.
20. The vending system of claim 2 wherein the communication link
comprises a physical link.
21. A handheld appliance, comprising: an interface for
communicating with an external system; a means for browsing and
selecting from a list of digital entities for sale, the list
provided via the interface; a means for initiating payment for one
or more entities selected; and a means for receiving and storing
the one or more digital entities selected and for which payment was
initiated.
22. The appliance of claim 21 wherein the interface is a wireless
interface.
23. The appliance of claim 21 wherein the interface is a physical
interface.
24. The appliance of claim 21 wherein the appliance comprises a
display, and the list of digital entities is displayed on the
display of the appliance.
25. The appliance of claim 21 further comprising a unique digital
identifier transmittable via the communication interface.
26. The appliance of claim 25 wherein the appliance transmits the
unique digital identifier, and the list as a result contains only
entities for sale that are digitally compatible with the
appliance.
27. The appliance of claim 25 wherein the unique digital identifier
is used as a key or a portion of a key in scrambling or customizing
a purchased entity.
28. A method for vending at least one of a digital information
entity and a program entity, comprising steps of: (a) storing one
or more entities to be vended in a data repository coupled to an
intelligent vendor; (b) providing a communication interface for the
intelligent vendor, with which the vendor may stream the one or
more digital entities; (c) providing, via the communication
interface, a list of one or more entities for sale in response to a
request from a potential purchaser; and (d) streaming, via the
communication interface, one or more entities selected for
purchase.
29. The method of claim 26 further comprising accepting payment for
a stored entity before streaming the one or more selected
entities.
30. The method of claim 28 wherein, in step (c), the request is
accompanied by a digital identifier, and the identifier is used in
populating the list of entities for sale.
31. A machine-readable storage medium containing a set of
instructions for causing a handheld appliance to perform a method
including; (a) establishing communication with a system for vending
digital entities; (b) requesting a list of one or more entities for
sale; (c) selecting a selected entity from the list; and (d)
downloading the selected entity.
32. The medium of claim 31 wherein the method further comprises a
step for initiating payment for the selected entity.
33. The medium of claim 31 wherein the method further comprises a
step for transmitting a digital identifier uniquely identifying a
particular class of appliances.
34. The medium of claim 31 further comprising displaying the list
of entities for sale.
35. A machine-readable storage medium containing a set of
instructions for causing a vending system to perform a method
including: (a) establishing communication with an appliance; (b)
providing a list of one or more entities for sale; (c) receiving
from the appliance a selection of a selected entity; and (d)
streaming the selected entity to the appliance.
36. The medium of claim 35 wherein the method comprises an
additional step for receiving a digital identifier, and sorting the
list according to the identifier.
37. The medium of claim 35 wherein the method includes negotiating
payment for a selection before streaming the selection.
Description
CROSS REFERENCE TO RELATED DOCUMENTS
[0001] The present application is a divisional of application Ser.
No. 09/785,574 which is a continuation of application Ser. No.
08/683,567 which is a continuation-in-part of application Ser. Nos.
08/144,231 and 08/019,592.
FIELD OF THE INVENTION
[0002] 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, and to Basic
Input/Output Systems (BIOS) for such devices.
BACKGROUND OF THE INVENTION
[0003] 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
traveling, 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.
[0004] 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:
[0005] 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, rivaling 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 5. Another difficulty is in the fact that the data files a
user manipulates while traveling 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..
[0010] 6. Yet another difficulty with small devices like digital
assistants is in providing embedded code routines, such as BIOS
routines, in a minimum read-only memory (ROM) real estate. There is
a considerable motivation to provide routines embedded in ROM,
because ROM is relatively inexpensive, and always a requirement for
minimum size and cost.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] In addition to the above, it is also desirable that the
.mu.PDA be served with code embedded in one or more ROM chips in a
manner to allow more code to be provided than the apparent capacity
of the ROM.
SUMMARY OF THE INVENTION
[0017] 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.
[0018] In an embodiment, the personal digital assistant module has
a BIOS embedded in ROM in a compressed fashion, along with an
uncompressed portion for testing and initializing system memory on
start-up, and an uncompressed compression utility routine
configured for decompressing the compressed BIOS portion.
[0019] In another 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0025] FIG. 1A is an isometric view of a .mu.PDA according to an
embodiment of the present invention.
[0026] FIG. 1B is a plan view of the .mu.PDA of FIG. 1A.
[0027] FIG. 2 is a cross-sectional view of the .mu.PDA of FIGS. 1A
and 1B.
[0028] FIG. 3 is a block diagram of the .mu.PDA of FIG. 1A and some
peripheral elements.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] FIG. 8 is an isometric illustration of a .mu.PDA software
vending machine in an aspect of the present invention.
[0034] FIG. 9 is a top plan view of a .mu.PDA enhanced user
interface according to an embodiment of the present invention.
[0035] FIG. 10 is a top plan view of a .mu.PDA with a microphone in
an embodiment of the present invention.
[0036] 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.
[0037] FIG. 12 is a plan view of a .mu.PDA with a speaker and pager
interface according to an embodiment of the present invention.
[0038] FIG. 13 is a plan view of a .mu.PDA with an infrared
communication interface according to an embodiment of the present
invention.
[0039] FIG. 14 is a plan view of a .mu.PDA with a scanner
attachment according to an embodiment of the present invention.
[0040] FIG. 15 is a plan view of a .mu.PDA with a fax-modem
attached according to an embodiment of the present invention.
[0041] FIG. 16 is a plan view of a .mu.PDA with a printer adapter
interface according to an embodiment of the present invention.
[0042] 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.
[0043] FIG. 18 is an isometric view of a .mu.PDA with a solar
charger according to an embodiment of the present invention.
[0044] 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.
[0045] FIG. 20 is an isometric view of a .mu.PDA according to the
invention connected by the expansion port to a standard-sized
keyboard.
[0046] FIG. 21 is a diagrammatical representation of a partially
compressed BIOS according to an embodiment of the invention.
[0047] FIG. 22 is a flow chart showing the operation of a computer
from startup following a BIOS routine according to the present
invention.
[0048] FIG. 23 is a diagrammatical representation of a token
decompression scheme according to an embodiment of the
invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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 ICs in a .mu.PDA. This
cross-section is illustrative of a method of construction only.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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
co-pending 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.
[0063] 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.
[0064] I/O 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.
[0065] 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 docking, 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.
[0066] 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.
[0067] 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.
[0068] At one comer, 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.
[0069] 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 maimer, 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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).
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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, transferable to the host to facilitate further
communication.
[0081] 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.
[0082] 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.
[0083] 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).
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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).
[0088] As previously described there is a pin configuration (not
shown) in connector 14 dedicated to signaling 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 signaling 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.
[0089] 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.
[0090] 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).
[0091] 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.
[0092] 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.
[0093] 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).
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] Additional Aspects and Features
[0101] Software Vending Machine:
[0102] 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.
[0103] 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 NXPDA I/O
area on a larger scale.
[0104] 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.
[0105] 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.
[0106] 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.
[0107] 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.
[0108] 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.
[0109] 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.
[0110] 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.
[0111] 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.
[0112] 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.
[0113] 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 traveling 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.
[0114] 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.
[0115] Enhanced Display:
[0116] 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.
[0117] 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.
[0118] A docked .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.
[0119] 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.
[0120] 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.
[0121] Microphone/Voicenotes:
[0122] 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.
[0123] 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.
[0124] 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.
[0125] Cellular Telephone Interface:
[0126] 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.
[0127] 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.
[0128] 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.
[0129] In a further embodiment, the calls are timed and
time-stamped and a comprehensive log, with areas for notes during
and after, is recorded.
[0130] 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).
[0131] 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.
[0132] 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.
[0133] 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.
[0134] 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.
[0135] 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.
[0136] Speaker/Pager:
[0137] 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.
[0138] 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.
[0139] 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.
[0140] Wireless Infrared Interface:
[0141] 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.
[0142] 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.
[0143] Peripherals
[0144] 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.
[0145] Scanner:
[0146] 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.
[0147] 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.
[0148] Facsimile Option:
[0149] 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
SPDA data files. In this case, the fax-modem routines are displayed
on the host monitor.
[0150] Printer:
[0151] 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.
[0152] Barcode Reader and Data Acquisition Peripheral:
[0153] 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 (not shown), battery pack
105, and a numeric keypad pad 96 implemented as a touch-sensitive
array.
[0154] 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.
[0155] 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.
[0156] Alternatively to frequent data transmission, data may be
stored or an auxiliary option memory location in peripheral
100.
[0157] 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.
[0158] Solar Charger:
[0159] FIG. 18 is an isometric view of the side of a .mu.PDA 10
opposite the I/O 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.
[0160] Games/Conference Center:
[0161] 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.
[0162] 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 salespeople's .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.
[0163] Standard Keyboard:
[0164] 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.
[0165] 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.
[0166] 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.
[0167] Compressed BIOS:
[0168] As was described above in the Background" section, it would
be desirable to be able to provide for a .mu.PDA according to an
embodiment of the invention, from a ROM device of fixed storage
capacity, more apparent lines of operable code than could
ordinarily be provided from a ROM of that storage capacity. A
compressed BIOS system is described below for just this purpose,
wherein a BIOS code routine is stored in a compressed portion of a
ROM along with an uncompressed portion configured for testing and
initializing system memory on startup, and an uncompressed portion
comprising a decompression utility configured to decompress the
compressed ROM portion.
[0169] In most BIOS systems for general-purpose computers, the BIOS
is stored in an EPROM device. Upon power up the BIOS initializes
the system, doing basic tasks like accessing and checking the
operation of on-board random-access memory RAM, and typically,
somewhere during the initialization, at least a part of the BIOS
code is copied (the BIOS copies itself) into a portion of the
on-board RAM, although this step is not required, as BIOS routines
may be executed directly from the EPROM device.
[0170] The portion of RAM reserved for BIOS code in a computer is
generally termed "shadow" RAM. The term shadow RAM is also used in
the industry for a particular hardware type of memory device
wherein each volatile memory cell has a connected non-volatile
(EPROM-type) cell. These are more properly called NVRAM devices,
and are not what is meant in this description by shadow RAM. Shadow
RAM for the purpose of this disclosure is simply that portion of
RAM reserved for a copy of part or all of the BIOS code.
[0171] In typical general-purpose computers, as soon as the system
receives power, the BIOS tests and initializes system RAM, then
copies (shadows) itself from the EPROM to the RAM. The BIOS
continues to run in RAM. The purpose of shadowing the BIOS in RAM
is to give the CPU microprocessor much faster access to the BIOS
code than it would have by accessing the EPROM every time a BIOS
code sequence is needed in continuing operations.
[0172] The present invention comprises a means of compressing at
least a significant portion of the BIOS code, storing all of the
BIOS code, including the compressed portion, in EPROM, and
releasing the compressed code on powerup, so all of the code is
available for the computer to use. Also on powerup, the entire code
is shadowed to RAM.
[0173] FIG. 21 is a diagrammatical representation of a compressed
BIOS 1011 according to the present invention. There are three
different portions of the code. Portion 1013 is code to perform all
operations to initialize and test the system RAM, and make it ready
for use, and is a familiar portion of conventional BIOS routines.
This portion in some applications needs to perform such functions
as initializing and testing a memory controller and cache
controllers and cache memory. Portion 1015 is a decompression
utility. Portion 1017 represents the balance of the BIOS code in
compressed form. It will be apparent to those with skill in the art
that there are a number of compression schemes and related
decompression routines that might be used.
[0174] FIG. 22 is a flow chart showing the operation of a computer
from startup following a BIOS routine according to the present
invention. From powerup signal 1019, which is typically derived
from the act of closing the power on switch, operation goes to
initialization operation 1021, during which system RAM is
initialized. In operation 1021, the system runs portion 1013 of
FIG. 21.
[0175] Next, decompression utility 1015 (FIG. 21) is accessed and
run in operation 1023. The decompression utility processes the
balance of the BIOS code (compressed), translates it into operable
code, and shadows it to system RAM. Although such decompression
utilities are available, the code pointing to the compressed
portion of the BIOS, and that which causes the decompressed code to
be shadowed to RAM is not a part of a conventional decompression
routine. These commands are added to the BIOS of the invention.
[0176] After the BIOS is shadowed operation continues (1025) from
the BIOS in system RAM. All remaining BIOS processes, including
testing and initializing the remainder of the computer subsystems
are accomplished in this operating portion.
[0177] One means by which the BIOS code may be compressed is based
on the fact that BIOS routines, as is common in most other coded
instruction sets, make use of frequently repeated code sequences.
EPROMs used for BIOS are typically byte-wide devices, that is, the
device can store "words" of 8 bits. A sixteen bit word requires,
then, two lines of BIOS code.
[0178] In this embodiment frequently repeated code sequences are
replaced in the compressed portion of the BIOS with a token. The
token in this embodiment is a two byte code in which the first byte
is a flag to the decompression utility that the following byte is a
pointer. The pointer portion is an entry to a table which is a part
of the decompression utility, and points to the specific, oft
repeated, code sequence. In a simple such system, the table might
have but one entry.
[0179] As an example, a frequently repeated code sequence in a BIOS
might be a "call keyboard" sequence, which for the purpose of this
example, may be eight lines of code. The token could be two lines
of code in which the first line is the binary representation of the
hexadecimal "FF". In this scheme, hex FF is a flag indicating that
the following byte is a pointer. The pointer, then, can be any
value representable by a digital byte, that is any one of 256
values. The requirement is simply that the decompression utility
associate the pointer with the oft-repeated BIOS code sequence, and
substitute that sequence in decompression and copying the BIOS code
to RAM. In this scheme an oft-repeated code sequence need be stored
only once in the BIOS portion that is the decompression
utility.
[0180] FIG. 233 is a diagrammatical representation of the token
decompression scheme described above. After the BIOS according to
the embodiment of the invention has initialized and tested the RAM,
the decompression utility is booted, and begins to read the
compressed portion of the BIOS at Start 1027. At 1029 the
decompression utility loads the first/next byte from the compressed
portion of the EPROM BIOS. If this byte is hex FF (1031), it is
recognized as a token, and control goes to 1033, where the system
reads the byte following the token flag. This byte is always a
pointer to a code sequence.
[0181] At 1035 the system associates the pointer byte with the code
sequence from a preprogrammed table and loads the associated
sequence. At 1037 the system copies the n lines of code pointed by
the pointer byte to the next n lines in shadow RAM. Control then
goes to decision point 1039 and determines if the last loaded byte
from compressed BIOS was the last byte. If so, control jumps to a
predetermined entry point in the decompressed shadow RAM, and the
BIOS routine continues. If not, control goes back to 1029 and the
next line of compressed code is loaded.
[0182] At decision point 1031, if the hex value is not FF, the code
line loaded from compressed BIOS is copied directly into the next
line in shadow BIOS.
[0183] 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.
[0184] 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 indeed
many variations that do not depart from the spirit and scope of the
invention.
[0185] In addition to the above, there are many non-volatile
memories in which a compressed BIOS may be stored, retrieved, and
decompressed, and several of these have been listed above. The fact
of compressing the routines in the BIOS, including a loadable
decompression routine, extends the capacity of any such finite
non-volatile memory devices and hence the size of a BIOS routine
that may be stored thereon.
[0186] It is also true that there are a truly large number of
compression schemes that might be employed to compress a portion of
the BIOS. The invention should not be limited by the specific code
relationship determined to compress the BIOS code.
* * * * *