Apple, Inc. v. Motorola, Inc. et al

Filing 12

AMENDED COMPLAINT for Patent Infringement against Motorola Mobility, Inc., Motorola, Inc., filed by Apple, Inc.. (Attachments: #1 Exhibit A - '949 patent, #2 Exhibit B - '002 patent, #3 Exhibit C - '315 patent, #4 Exhibit D - RE '486 patent, #5 Exhibit E - '354 patent, #6 Exhibit F - '263 patent, #7 Exhibit G - '983 patent, #8 Exhibit H - '705 patent, #9 Exhibit I - '647 patent, #10 Exhibit J - '852 patent, #11 Exhibit K - '131 patent, #12 Exhibit L - '337 patent, #13 Exhibit M - '867 patent, #14 Exhibit N - '721 patent, #15 Exhibit O - '599 patent) (Peterson, James) [Transferred from Wisconsin Western on 12/1/2011.]

EXHIBIT B

111111111111111111111111111111111111111111111111111111111111111111111111111
US006493002Bl

(54)

United States Patent

(10)

Christensen

(12)

(45)

5,202,961
5,416,895
5,428,730
5,588,105
5,617,526
5,640,498
5,644,334
5,659,693
5,678,034
5,757,371
5,825,357
6,133,898

METHOD AND APPARATUS FOR
DISPLAYING AND ACCESSING CONTROL
AND STATUS INFORMATION IN A
COMPUTER SYSTEM
Steven W. Christensen, Milpitas, CA
(US)

(75)

Inventor:

(73)

Assignee: Apple Computer, Inc., Cupertino, CA
(US)

( *)

Notice:

This patent issued on a continued prosecution application filed under 37 CFR
1.53(d), and is subject to the twenty year
patent term provisions of 35 U.S.c.
154(a)(2).

Filed:

Related U.S. Application Data
Continuation of application No. 08/316,237, filed on Sep.
30, 1994, now abandoned.

(51)
(52)
(58)

Int. CI?
G06F 3/00
U.S. Cl.
345/779; 345/772
395/345, 350,
Field of Search
395/352,354,326,339,340,341, 973,
974; 345/348, 350, 352, 354, 326, 339,
340, 341, 973, 974, 700, 764, 771-772,
776-779, 781, 784, 788, 791, 798-800,
833, 856

A
A
A
A
A
A

*
*
*
*
*

8/1989
12/1989
1/1990
6/1990
2/1992
9/1992

Takagi
Takagi et al.
Gest et al.
Takagi et al.
Takagi
Hullot et al.

IQ FILE
I . -.
i~ -

0483777
483777
0584391
584392

...

J~

12.6 MB IN DISK

CJ

APPLEUNK POWERBOOK EDmON

~

MACTERt.lINAL

~

MOVI PLAYER

.. - - - - -

313.6 MB AVAILABLE

CJ
CJ
CJ CJ

EXPRESS t.lODEM

REMOTE ACCESS CUENT FOLDER

0

RESEDIT

TOOLS

4f13

SIMPLE TEXT

WORD

~

::::~N~~:E
QUICKTIM~

:::

rIT___

~

8:51K

2ITEMS. 12.6 MB IN DISK

$J

SERlAl TOOL

33K

:

~T~~L

~~~

Do, Q!IClolll 0 00000100000 W0

A

50 Claims, 13 Drawing Sheets

APPLI{ffIONS··

10 ITEMS

Al

10/1991
5/1992
8/1992
3/1994

An interactive computer-controlled display system having a
processor, a data display screen, a cursor control device for
interactively positioning a cursor on the data display screen,
and a window generator that generates and displays a
window on a data display screen. The window region
provides status and control information in one or more data
display areas. The individiual data display areas may be
controlled through the use of controls and indicators on the
control strip itself using cursor control keys.

EDIT VIEW LABEL SPECIAL
EXTENSIONS

A2
A

ABSTRACT

(57)

345/794
345/166
345/841
345/453
345/803
345/790

NAME

345/720
707/503
345/740
345/779
345/779
345/790
345/419
345/779
345/520
345/779
345/779
345/790

Primary Examiner---Crescelle N. dela Torre
(74) Attorney, Agent, or Firm-Blakely, Sokoloff, Taylor &
Zafman LLP

U.S. PATENT DOCUMENTS
4,862,389
4,885,704
4,896,291
4,931,957
5,091,866
5,146,556

Anderson et al.
Baker et al.
Foster et al.
Gran et al.
Chew
Jones et al.
Hansen et al.
Chew
Gran et al.
Malamud et al.
Ludolph et al.

* cited by examiner

References Cited

(56)

*
*
*
*
*
*
*
*
*

5/1995
6/1995
12/1996
4/1997
6/1997
7/1997
8/1997
10/1997
5/1998
10/1998
10/2000

EPO 0 584 392 A1, Cohausz, English Translation of the
German patent document, Mar. 1992.*
"PCT Written Opinion", Oct. 4, 1996.
Steven Harris, et al.: "Inside WordPerfect 6 for Windows",
1994, USA, pp. 1104-1108.
Mark A. Benge, Matt Smith: "Designing Custom Controls",
Spring 1993, USA, pp. 72-85.
International Search Report, PCT/US 95/11025, Jan. 03,
1996.

Mar. 20, 1997

(63)

* 4/1993 Mills et al.

OTHER PUBLICATIONS

Appl. No.: 08/821,004

(22)

A
A
A
A
A
A
A
A
A
A
A
A

FOREIGN PATENT DOCUMENTS

EP
EP
EP
EP

Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.c. 154(b) by 0 days.
(21)

Patent No.:
US 6,493,002 BI
Date of Patent:
*Dec. 10,2002

__._ ..
..._

_:~

313.6 MB A

'1-4I11~~II~),jII(])

F

11111(1)11 :00;49 .4lollr-[)

109

108

[DISPLAY

-

~

TIMER
150

IFLOPPY
DRIVE

DISK ~
126 f".rV

jW

[ SOUND
CHIP
125

'" 7

'"
181

.-

"-

130

184

TO
CLOCK
GENERATOR
160

L

CURSOR
CONTROL 123

1 J
KEYBOARD
122

154

~

140

1INTERFA/0
FROM I
CE

NONVOLATILE
MEMORY
106

MAIN
MEMORY
104

V DD

103

PROCESSOR

.l- GENERATOR
CLOCK 160
eLK

v

"-

v

h

~
.-

;:.

LOCAL BUS 100 )

~
.--

L.

DECODER

TEMP. ~T1
1 2 7 : SENSOR 127A

140

'I

.A

K

r---

POWER
SIGNAL
182 ' - BUS
TRANSLATOR/
INTERFACE
UNIT

I~

j

SWITCH V DD
153

HOT INDICATION
SIGNAL 183 ---..

~

TO OTHER
COMPONENTS

I/O
MICROCONTROLLER ~ CONTROLLER

I/O BUS 101,

CLK-

.11-_

121 1'1

[HARD COpy
DEVICE 124

ILAN

IMODEM

[MASS
STORAGE 107

FIG. I

POWER
SUPPLY152

d

•
'JJ.
•

SIZE

12.6 MB IN DISK

83K

33K
2BK

61K

SERIAl TOOL

TEXT TOOL

TIY TOOL

~
~
~

21TEMS

I I

WORD

12.6 MB IN DISK

TOOLS

[2]

\

-

Lt
-

313.6 MB A\

SIMPLE TEXT

'/"

FIG, 2A

200

\..

IQ!:dll(~111[g ~III 0 00000100000 W~III-*- DDDDDDDD.IIID~II~~II~~~II~"III<l) ~11C911 :OO~9 ~1I[)11I:~9J

831K

~

66K ~[Ef

PRINTMONITOR

QUICKTIME'TU

g

RESEDIT

PRINTER SHARE

MOVIEPLAYER

[]

[]

~

0

REMOTE ACCESS CUENT FOLDER

[]

MACTERMINAL

.. 0::

~

..

EXPRESS MODEM

APPLEUNK POWERBOOK EDmON

~

313.6 MB AVAILABLE

[]

10 ITEMS

APPLICATIONS

[]

D

~

~

fi

~

,.

[

L:

r;

l.=

rr

NAME

EXTENSIONS

QFILE EDIT VIEW LABEL SPECIAL

&

~m

CDC

d

•
'JJ.
•

u.s. Patent

Dec. 10, 2002

200~

Sheet 3 of 13

US 6,493,002 BI

MODULE DISPLAY AREA

CLOSE BOX

202

201

DRAG/SIZE TAB
203

LEFT SCROLL ARROW
204
RIGHT SCROLL ARROW
205

FIG. 28
-------------,
HIDE BATIERY LEVEL
HIDE BATIERY CONSU~TI6N
HIDE TIME REMAINING

~

0 00000100000 If ~ ~«- 0000
FIG. 2C

BATIERY MONITOR
THE POWER ADAPTER IS
CONNECTED AND RECHARGING
ONE OF THE BATIERIES.

FIG. 2D

u.s.

Patent

o~

Dec. 10,2002

0 000001 DODO ~ ~

US 6,493,002 BI

Sheet 4 of 13

-:0.-

§3o DDDDOI~DDD~~~-#-

00000000

~

0

~

\

00000000 ~~D ~~

.a.
~o ODD~IODDDO W~-*- 00000000 • ~D ~ ~

.a.
§3o DDDDOIODDDDW~EI- ODODOO~D ~~

23

-#- 00000000 ~[[ODDDOIODDDD ~D ~ ~
FIG. 2E

u.s. Patent

Dec. 10,2002

(

+

Sheet 5 of 13

US 6,493,002 BI

210

(211

o00000100000 W~

mo7

-

00000100000 W~~~

212

FIG. 2F

CONTROL STRIP

@ SHOW CONTROL STRIP

o HIDE

CONTROL STRIP

FIG. 3

~

u.s. Patent

US 6,493,002 BI

Sheet 6 of 13

Dec. 10, 2002

MAIN LOOP
(CALLED BY OPERATING SYSTEM)

FIG. 4

SAVE PREVIOUS CONTEXT,
SETUP STRIP'S CONTEXT

401
SECONDARY
INITIALIZATION

RUN SECONDARY
INITIALIZATION

COMPLETE?

403

YES
404
DETERMINE THE
USER E.VENT TYPE

NULL EVENT
(IDLE)?

RUN IDLE TASKS
YES

406

405
NO

MOUSE CLICK?

>---~

PROCESS MOUSE CLICK

YES

407

408

NO
RESTORE PREVIOUS

CONTEXT

409
EXIT

1------1

u.s. Patent

Dec. 10,2002

US 6,493,002 BI

Sheet 7 of 13

CONTROL STRIP MAIN LOOP
,IRUN SECONDARY INITALIZATION

SECONDARY
INITIALIZATION

NO

CREATE THE STRIP'S
WINDOW

502

NO
YES
INITIALIZE STRIP'S FONT,
COLOR
504
OPEN,INITIALIZE EXTERNAL
MODULES
505
SET STRIP'S DEFAULT
SCREEN LOCATION,SIZE

LOAD USER
CONFIGURATION
DRAW THE STRIP'S
CONTENTS

FIG. 5

506

507

508

u.s. Patent

Dec. 10,2002

US 6,493,002 BI

Sheet 8 of 13

MODULES
OPEN. INITIALIZE
EXTERNAL MODULES

505
NO

OPEN MODULE FILE

602
LOAD MODULE CODE
INTO MEMORY
CALL MODULE TO
INITIALIZE ITSELF

CALL MODULE TO GET
MODULE'S FEATURES

CALL MODULE TO GET
ITS DISPLAY WIDTH

603

604

605

606

CLOSE MODULE FILE

607

FIG. 6

u.s.

Patent

US 6,493,002 BI

Sheet 9 of 13

Dec. 10,2002

CONTROL STRIP MAIN LOOP
LDRAW THE STRIP'S CONTENTS
DRAW THE STRIP S
CONTENTS

"'>------1\10·---.

MORE MODULES "'>-----NO-----'
TO DRAW?

702

Y S

THIS MODULE
NEED TO BE
REDRAWN?

N

703
704
IS
THIS MODULE
A BUTTON?

YES

NO

DRAW STATUS-ONLY
BACKGROUND
GRAGHICS

DRAW BUTTON
BACKGROUND
GRAGHICS

705

L - -_ _

~

706

CALL MODULE TO
DRAW ITSELF

FIG. 7

14------J

u.s. Patent

Dec. 10, 2002

RUN IDLE TASKS

US 6,493,002 BI

Sheet 10 of 13

CONTROL STRIP MAIN LOOP
LRUN IDLE TASKS

801

DRAW THE STRIP'S
CONTENTS

WINDOW UPDATE
PENDING?

802
NO

HAS STRIP'S
CONFIGURATION
CHANGED?

YES

803

IS IT
SAFE TO
SAVE NOW?
NO

YE

SAVE STRIP'S
CONFIGURATION
TO DISK

804

805

NO
CALL CURRENT
IDLE MODULE TO ~
RUN ITS IDLE TASK
806

807

808

DOES MODUL
NEED TO SAVE
SETTINGS?

YE

IS IT SAFE TO
SAVE NOW?

809
NO

810

NO

812

FIG. 8

SAVE MODULE'S
SETTINGS
TO DISK

811

u.s. Patent

US 6,493,002 BI

Sheet 11 of 13

Dec. 10, 2002

CONTROL STRIP MAIN LOOP
!-PROCESS MOUSE CLICK
PROCESS MOUSE
CLICK

901
DETERMINE WHICH
MODULE WAS CLICKED ON

902
YES

MOVE MODULE'S DISPLAY,
OR MOVE ENTIRE STRIP

904

NO

CLICKABLE
MODULE?

;::---

NO-~

905

TRACK THE MOUSE CLICK

MOUSE
STILL IN
MODULE'S
BOUNDS?

>--NO---.l

CALL THE MODULE TO
PROCESS THE CLICK

908
POST PROCESS
THE CLICK
L--

FIG. 9

909
~

EXIT

u.s. Patent

Dec. 10, 2002

Sheet 12 of 13

US 6,493,002 BI

CONTROL STRIP MAIN LOOP
!-POST PROCESS THE CLICK

MODULE WANTS TO
UPDATE SETTINGS?

YES

FLAG THAT THIS MODULE
HAS A SAVE PENDING

1002

1001
NO
MODULE
NEEDS TO
RESIZE
DISPLAY?

YES

CALL MODULE TO
UPDATE ITS WIDTH

1003

1004
NO

MODULE WANTS
TO BE CLOSED?

YES

CLOSE THE
MODULE

1006

1005
NO

RESIZE OR
CLOSE?

YES

REPOSITION AND REDRAW
MODULE DISPLAYS

1008

1007

MODULE HELP
STATE CHANGE?

YES

INVALIDATE OLD
HELP STATE

1 10

1009
NO

e&m

FIG. 10

u.s.

Patent

Dec. 10,2002

Sheet 13 of 13

US 6,493,002 BI

-+oJ

I

I

.c

C'l

c==J

Ck:
Q)

[Ill]

.c

IIIIIIIl

0

om
OJ]]

•

0.
0
(/)

0.
L-

~
a

CD

...-..
ex)
.c

....

.;

'--'

I

I

.....J
0.
0

c=J
OIIIJ

.c
0.
a
L-

1111111111
111111111111

Q)

r-

~
0

(J]J]]

-

. 0 - 811I118111I

I

>
.

.....
'+Q)

:...J

a.
0

l-

.e.

0.

a
L-

C2
a

.0

.c
-+oJ

"0

c=J
I

~
..c:
a.
a
L-

C2
0

CD
-+oJ

Q)

0

CD

(/)

-.

<.!)

lJ....

-+oJ

.c

0"
0::

C\J

0IIIllIIIlI

a
lJ...
..c:
0.
a
L-

_lIIlHllml

'2
0

<.!)
l..L.

CD

mil

.....
....

I

OIIIJ

(J]J]]
1111111111

rnn

ITlIIIIIl
ITIIIIJ

ITIIIJ
c==J
c=J

-+oJ

Q)

-I
Q)

0.
0
(/)

.e.

0.

a

L-

e"
L-

a

CD

-.

US 6,493,002 Bl
1

2

METHOD AND APPARATUS FOR
DISPLAYING AND ACCESSING CONTROL
AND STATUS INFORMATION IN A
COMPUTER SYSTEM

The present invention overcomes these problems by providing a status and control information display. The display
of the present invention is in an easily accessible format.
Also, the display may be configured to permanently display
in a visible manner control and status indicia.

5

This is a continuation of application Ser. No. 08/316,237,
filed Sep. 30, 1994, now abandoned.

SUMMARY OF THE INVENTION

FIELD OF THE INVENTION
The present invention relates to the field of computer
systems; particularly, the present invention relates to displaying a status and control function bar or window to
enable access of user selected indicia to a computer system
user.

10

15

BACKGROUND OF THE INVENTION

An interactive computer-controlled display system is
described. In the present invention, the display system
includes a processor, a data display screen, and a cursor
control device for interactively positioning a cursor on the
data display screen. The present invention also includes a
window generator that generates and displays a window
(e.g., a control strip) on a data display screen. In one
embodiment, the window comprises a control and/or status
window for display on the desktop of the computer system
The window displays graphics depicting at least one display
area of indicia. The individual data areas may be controlled
through the use of controls and indicators in the window
itself using cursor control keys.

Typically, a computer system contains a processor, a bus,
and other peripheral devices. The processor is responsible
for executing instructions using the data in the computer
system. The bus is used by the processor and the peripheral 20
devices for transferring information between one another.
BRIEF DESCRIPTION OF THE DRAWINGS
The information on the bus usually includes data, address
The present invention is illustrated by way of example,
and control signals. The peripheral devices comprise storage
25 and not by way of limitation, in the figures of the accomdevices, input/output (I/O) devices, etc.
panying drawings and in which like reference numerals refer
Computer systems also include information management
to similar elements and in which:
systems that coordinate the display of information to the
user. Currently, the art in computer display management
FIG. 1 is a block diagram of one embodiment of the
computer system of the present invention.
provides the capability of displaying data in rectangular
portions (commonly referred to as windows) of a display 30
FIG. 2A displays a computer desktop illustrating the
screen. Such information management systems include the
control strip of the present invention as well as opened
Finder™ interface of the computer systems manufactured by
windows.
Apple Computer, Inc. of Cupertino, Calif. Controls are
FIG. 2B illustrates one embodiment of the control strip of
typically provided to resize and move windows within the
the present invention.
confines of the physical display boundaries.
35
FIG. 2C illustrates a pop-up menu displayed from the
Windows may be used to display information regarding
control strip of the present invention.
application programs, as well as information produced by
FIG. 2D illustrates a help balloon displayed from the
system programs, that are run on the computer system.
control strip of the present invention.
Many of these system and control programs provide status
FIG. 2E illustrates the process of moving a display area
and control information and functionality. Some of the 40
from one position to another in the control strip.
system control programs also provide options with respect to
FIG. 2F shows the control strip window graphics generthe information they provide and the functions they perform.
ated by processing logic being combined with graphics
These options can be accessed and/or selected by moving a
generated by a module to illustrate the creation of the
cursor at a predetermined point in the window and "clicking" a mouse or performing requisite key strokes. Access to 45 resulting control strip.
FIG. 3 illustrates one embodiment of the control panel of
these programs may require locating the program (e.g.,
the present invention.
locating and entering a folder) before execution. The time
necessary to access such programs may be unduly long. It is
FIG. 4 is a flow chart of one embodiment of the process
desirable to provide a less obtrusive manner of accessing
for the control strip of the present invention.
such system and control programs.
50
FIG. 5 is a flow chart of one embodiment of the secondary
The computer system is often capable of displaying
initialization process of the present invention.
multiple windows or data areas on the display screen at the
FIG. 6 is a flow chart of one embodiment of the open and
same time. Windows may overlap each other. The informainitialization process for the external modules of the present
tion contained in the portion of the window that is overinvention.
lapped is not visible. The window that is entirely visible to 55
FIG. 7 is a flow chart of one embodiment of the process
the computer user is typically the active window. Therefore,
for drawing the contents of the control strip of the present
a program, such as a system or control program may be
invention.
running, while another program displaying information in
FIG. 8 is a flow chart of one embodiment of the process
another window is selected as active and thereafter covers,
for running idle tasks in the sent invention.
partially or completely, the windows or data areas displayed 60
FIG. 9 is a flow chart of one embodiment of the process
by the system/control program. Sometimes the user may
for responding to a mouse click occurring in the control strip
wish to have an unobstructed view of the system/control
of the present invention.
data area, regardless of the window selected as active (even
FIG. 10 is a flow chart of one embodiment of the process
when the windows overlap each other). Thus, it is desirable
at times to have windows that are always visible to the user. 65 for post processing a mouse click in the present invention.
However, it is also desirable to be able to eliminate that
FIG. 11 illustrates a bar graph for display in a data display
window at times based on the user's requirements.
area in the control strip of the present invention.

US 6,493,002 Bl

3

4

FIG. 12 illustrates a bar graph that results after using
arrow direction icons.

programs in accordance with the teachings herein, or it may
prove convenient to construct more specialized apparatus to
perform the required method steps. The required structure
for a variety of these machines will appear from the description below. In addition, the present invention is not
described with reference to any particular programming
language. It will be appreciated that a variety of programming languages may be used to implement the teachings of
the invention as described herein.

DETAILED DESCRIPTION OF IRE
INVENTION

5

A method and apparatus for providing status and control
indicia. In the following detailed description of the present
invention numerous specific details are set forth, such as
types of status indicia, instruction names, etc., in order to
provide a thorough understanding of the present invention. 10
OVERVIEW OF THE COMPUTER SYSTEM OF
However, it will be apparent to one skilled in the art that the
IRE PRESENT INVENTION
present invention may be practiced without these specific
details. In other instances, well-known structures and
Referring to FIG. 1, an overview of a computer system of
the present invention is shown in block diagram form. The
devices are shown in black diagram form, rather than in
15 present invention may be implemented on a general purpose
detail, in order to avoid obscuring the preset invention.
microcomputer, such as one of the members of the Apple
The present description includes material protected by
family of personal computers, one of the members of the
copyrights, such as illustrations of graphical user interface
IBM personal computer family, or one of several other
images which the assignee of the present invention owns.
computing and assistant devices which are presently comThe assignee hereby reserves its rights, including copyright,
in these materials, and each such material should be 20 mercially available. Of course, the present invention may
also be implemented on a multi-user system while encounregarded as bearing the following notice: Copyright Apple
tering all of the costs, speed, and function advantages and
Computer, Inc., 1993. The copyright owner has no objection
disadvantages available with these machines. The preferred
to the facsimile reproduction by anyone of the patent docuembodiment of the present invention is implemented on an
ment or the patent disclosure, as it appears in the Patent and
Trademark Office file or records, but otherwise reserves all 25 Apple PowerBook™ computer system developed by the
assignee of the present invention.
copyrights whatsoever.
As illustrated in FIG. 1, the computer system of the
Some portions of the detailed descriptions which follow
present invention generally comprises a local bus or other
are presented in terms of algorithms and symbolic representations of operations on data bits within a computer 30 communication means 100 for communicating information,
a processor 103 coupled with local bus 100 for processing
memory. These algorithmic descriptions and representations
information, a random access memory (RAM) or other
are the means used by those skilled in the data processing
dynamic storage device 104 (commonly referred to as a
arts to most effectively convey the substance of their work
main memory) coupled with local bus 100 for storing
to others skilled in the art. An algorithm is here, and
generally, conceived to be a self-consistent sequence of steps 35 information and instructions for processor 103, and a readonly memory (ROM) or other non-volatile storage device
leading to a desired result. The steps are those requiring
106 coupled with local bus 100 for storing non-volatile
physical manipulations of physical quantities. Usually,
information and instructions for processor 103.
though not necessarily, these quantities take the form of
The computer system of the present invention also
electrical or magnetic signals capable of being stored,
transferred, combined, compared, and otherwise manipu- 40 includes an input/output (I/O) bus or other communication
means 101 for communication information in the computer
lated. It has proven convenient at times, principally for
system. A data storage device 107, such as a magnetic tape
reasons of common usage, to refer to these signals as bits,
and disk drive, including its associated controller circuitry,
values, elements, symbols, characters, terms, numbers, or
is coupled to I/O bus 101 for storing information and
the like.
It should be borne in mind, however, that all of these and 45 instructions. A display device 121, such as a cathode ray
tube, liquid crystal display, etc., including its associated
similar terms are to be associated with the appropriate
controller circuitry, is also coupled to I/O bus 101 for
physical quantities and are merely convenient labels applied
displaying information to the computer user, as well as a
to these quantities. Unless specifically stated otherwise as
hard copy device 124, such as a plotter or printer, including
apparent from the following discussions, it is appreciated
that throughout the present invention, discussions utilizing 50 its associated controller circuitry for providing a visual
representation of the computer images. Hard copy device
terms such as "processing" or "computing" or "calculating"
124 is coupled with processor 103, main memory 104,
or "determining" or "displaying" or the like, refer to the
non-volatile memory 106 and mass storage device 107
action and processes of a computer system, or similar
through I/O bus 101 and bus translator/interface unit 140. A
electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities 55 modem 108 and an ethernet local area network 109 are also
coupled to I/O bus 101.
within the computer system's registers and memories into
Bus interface unit 140 is coupled to local bus 100 and I/O
other data similarly represented as physical quantities within
bus 101 and acts as a gateway between processor 103 and
the computer system memories or registers or other such
the I/O subsystem. Bus interface unit 140 may also provide
information storage, transmission or display devices.
The present invention also relates to apparatus for per- 60 translation between signals being sent from units on one of
the buses to units on the other bus to allow local bus 100 and
forming the operations herein. This apparatus may be speI/O bus 101 to co-operate as a single bus.
cially constructed for the required purposes, or it may
comprise a general purpose computer selectively activated
An I/O controller 130 is coupled to I/O bus 101 and
or reconfigured by a computer program stored in the comcontrols access to certain I/O peripherals in the computer
puter. The algorithms and displays presented herein are not 65 system. For instance, I/O controller 130 is coupled to
controller device 127 that controls access to an alphainherently related to any particular computer or other apparatus. Various general purpose machines may be used with
numeric input device 122 including alpha-numeric and other

US 6,493,002 Bl
5

6

keys, etc., for communicating information and command
selections to processor 103, a cursor control 123, such as a
trackball, stylus, mouse, or trackpad, etc., for controlling
cursor movement, and a temperature sensor 127A for measuring the internal system temperature. The system also
includes a sound chip 125 coupled to I/O controller 130 for
providing audio recording and play back. Sound chip 125
may include a sound circuit and its driver which are used to
generate various audio signals from the computer system.
I/O controller 130 may also provide access to a floppy disk
and driver 126. The processor 103 controls I/O controller
130 with its peripherals by sending commands to I/O
controller 130 via local bus 100, interface unit 140 and I/O
bus 101.
Batteries or other power supply 152 may also be included
to provide power necessary to run the various peripherals
and integrated circuits in the computer system. Power supply 152 is typically a DC power source that provides a
constant DC power to various units, particularly processor
103. Various units such as processor 103, display 121, etc.,
also receive clocking signals to synchronize operations
within the computer systems. These clocking signals may be
provided by a global clock generator or multiple clock
generators, each dedicated to a portion of the computer
system. Such a clock generator is shown as clock generator
160. In one embodiment, clock generator 160 comprise a
phase-locked loop (PLL) that provides clocking signals to
processor 103.
In one embodiment, processor 103 is a member of the
68000 family of processors, such as the 68040 processor
manufactured by Motorola Corporation of Schaumberg, Ill.
The memory in the computer system is initialized to store
the operating system as well as other programs, such as file
directory routines, control programs, system programs and
application programs, and data inputted from I/O controller
130. The operating system running on processor 103 takes
care of basic tasks such as starting the system, handling
interrupts, moving data to and from memory 104 and
peripheral devices via input/output interface unit 140, and
managing the memory space in memory 104. In one
embodiment, the operating system is stored in ROM 106,
while RAM 104 is utilized as the internal memory for the
computer system for accessing data and application programs.
Processor 103 accesses memory in the computer system
via an address bus within bus 100. Commands in connection
with the operation of memory in the computer system are
also sent from the processor to the memory using bus 100.
Bus 100 also includes a bi-directional data bus to communicate data in response to the commands provided by
processor 103 under the control of the operating system
running on it.
Of course, certain implementations and uses of the
present invention may neither require nor include all of the
above components. For example, in certain implementations
a keyboard or cursor control device for inputting information to the system may not be required. Furthermore, the
computer system may include additional processing units.

the display areas is individually and variably sized. The size
of the control strip itself may also be variably sized. In one
embodiment, the size may be adjusted such that none, all, or
only a portion of the display areas within its boundaries are
visible. The size of the control strip may also be varied such
that only a portion of one display area is visible in the control
strip. FIG. 2A displays a computer desktop illustrating the
control strip of the present invention as well as opened
windows. FIG. 2B illustrates one embodiment of the control
strip of the present invention.
Each of the variably sized data areas may be sensitive to
user input for control. That is, a user may interact with the
individually display data areas. Different parts of the control
strip either display information or act as buttons, or both.
Note that buttons may display information on their surface.
When the user clicks a button, it is highlighted. In one
embodiment, buttons may also display additional elements
such as pop-up menus (shown in FIG. 2C) or help messages
(e.g., balloons shown in FIG. 2D). Thus, in one embodiment,
control of the individual data areas is accomplished, in part,
through the use of small button controls and indicators in the
form of various icons.
Each of the display areas is associated with a programming module. Each of the modules provides a specific status
or control function. In one embodiment, the module is
represented by a disk file containing the code necessary for
the module to interact with the control strip as well as other
elements such as text, icons, pictures, etc. Modules may be
designed to be responsive to selection from cursors via a
mouse, trackpad, or cursor control keys, such as on a
keyboard. Many of the modules are able to provide control
to various system functionality, and may provide menus to
do the same.
The control strip is a control panel that provides the
operating environment for control strip modules. In one
embodiment, the control strip runs on any Macintosh™
computer using a System 7.0 or later operating system. The
control strip of the present invention may be designed to run
on computer systems using other operating systems.
In one embodiment, the control strip is implemented in a
private window layer that appears in front of the windows of
all the application layers. That is, the control strip window
appears on top of all application programming windows that
may be generated as part of the execution of an application
program. This prevents other windows from obscuring it. In
one embodiment, processing logic in the computer system
may maintain a list of windows ordered from the frontmost
window on the screen being at the top of the list and the
bottommost window being at the bottom of the list. Processing logic can maintain the control strip window at the
top of the list.
The control strip of the present invention may include
windowing configurations that are shown as being horizontal or vertical on the screen. Furthermore, the present
invention is not limited to a single row or column of status
and control data areas. In other words, multiple rows and
columns of module data areas may be included in the
window of the control strip.

OVERVIEW OF THE PRESENT INVENTION
The present invention provides a control and/or status
window for display on the desktop of the computer system.
The control and status window will be referred to herein as
the control strip. The control strip of the present invention is
a window of graphics depicting one or more display areas
for control and/or status indicia. In one embodiment, each of

5

10

15

20

25

30

35

40

45

50

55

60

65

CONTROL STRIP MANIPULATION
The control strip, such as shown in FIG. 2B, may also be
moved to different portions of the display screen. However,
in one embodiment, the window for the control strip may be
moved to any location on the display as long as the right
and/or left edge of the strip is attached to the right or left
edge, respectively, of the display. The user may also hold

US 6,493,002 Bl
7

8

down the option key and drag the tab 203 of the control strip
200 with the use of a cursor control device (e.g., trackpad,
trackball, mouse) to move the control strip to a new position
on the display.
In one embodiment, the user may adjust the size of the
control strip window. Adjustments to the size of the window
may comprise either an increase in the height of the window,
the width of the window, or both. In one embodiment, only
the width of the control strip window may altered. The
definition and use of windows is well-known in the art. In
one embodiment, the control strip 200 has a tab 203 on its
unattached end. The user can drag tab 203 to adjust the
length of the strip. By "clicking" on tab 203, i.e. selection
through the use of the trackpad, mouse, cursor control keys,
etc., the user is able to shift from a minimal control strip size
to a maximum control strip size, and vice versa. In its
minimal size, the graphics of the modules in the control strip
are not visible and only the tab is showing. In its maximum
size, all of the modules in the control strip are showing.
Recognizing cursor controlled selections through the use of
trackpad, trackball, mouse, cursor control keys, etc., as well
as the tracking of movements of the cursor made by the same
are well-known in the art.
Scroll arrows, such as left scroll arrow 204 and right scroll
arrow 205, are provided on the control strip that enable the
window of the control strip to be scrolled to the left or right,
respectively. Use of scroll arrows with windows is wellknown in the art.
The user may also hide the control strip. In one
embodiment, to make the control strip disappear completely,
the user can click the Hide button in the control strip control
panel, as described later in conjunction with FIG. 3. A close
box 201 is also included in control strip 200 In one
embodiment, by holding the option key and clicking a
display area, the user can drag the display area to another
position in the control strip. An example of the process of
moving one display area to another position on the control
strip is shown in FIG. 2E. Referring to FIG. 2E, the user
selects one of the display areas by, for instance, positioning
the cursor over the display area. When the user "clicks" the
display area, its border becomes highlighted. While clicking,
the display area is dragged to another location in the control
strip module display area. When the user has moved the
display area to the location of his choice, the user stops
"clicking" The control strip display areas are then rearranged.
After the user rearranges the parts of the control strip, the
new arrangement is saved. The saving operation may be
deferred until resources, such as the hard disk is ready (e.g.,
spinning) or until just before the computer system is shut
down or restarted. In other words, in computer systems in
which the hard disk is not turned on all the time in order to
save power, the saving operation may be deferred until the
hard disk has been turned on by another.

The control strip may also include a battery monitor that
displays the status of the battery or batteries. In one
embodiment, the battery monitor displays the current power
drain in a manner similar to a car's miles per gallon (MPG)
indicator. The needle for the power drain indicator indicates
the drain relative to the maximum possible. The control strip
of the present invention allows this display to be updated
frequently so if the user increased the LCD display screen's
brightness level, the needle would animate to denote the
consequence of the action.
Another control strip module displays the state of File
Sharing (e.g., on, off, or users connected) that may be
currently employed on the computer system. The file sharing
module also lets the user turn file sharing on or off and lets
the user open a control panel to control processing to setup
file sharing on the computer system.
The control strip of the present invention may also
provide a module to allow the internal hard disk power to be
turned off (to save power), and to indicate whether is
currently on or off.
The control strip may also provide power settings that
allow the user to select between maximum battery conservation or maximum computer performance without opening
a control panel. In one embodiment, the power settings
portion of the control strip also allow the user to open up the
power savings control panel. The control strip of the present
invention may also include a function that places the computer in sleep mode or allows the user to select the sound
volume.
Other modules, for example, may provide time and/or
date information, may list currently running programming
applications, may indicate the amount of available memory,
may control a CD drive, may provide access to audio
controls and status information. Therefore, the control strip
acts as a status and control function bar, or windowing area,
that provides running modules to be displayed in an arrangement that is to be displayed, such an arrangement being
modifiable such that the size of the window or bar may be
changed.
In one embodiment, the control strip is controllable
through a control panel. An exemplary display of such
control panel is shown in FIG. 3. Use of control panels is
well-known in the art. Using the control panel in FIG. 3, the
user is able to hide or show the control strip by clicking the
corresponding button in the control panel. Note that in one
embodiment, the control panel may also be used to change
the font and size of the text in the control strip window.

5

10

15

20

25

30

35

40

45

50

55

EXEMPLARY CONTROL/STATUS
INFORMATION
The control strip of the present invention provides a
standard screen location for a collection of individual modules that provide status and control functions. In one
embodiment, the control strip functions include a network
switch that shows whether a network connection for the
computer system, such as an AppleTalk™ network
connection, is on or off and lets the user turn the network
connection on or off without having to locate and execute
other network connection software on the computer system
(e.g., without having to open the Chooser™).

60

65

PROCESSING LOGIC FOR THE PRESENT
INVENTION
The present invention includes computer processing logic
for generating the control strip of the present invention. This
processing logic is described, in part, in the flow charts
shown in FIGS. 4-10. In addition to the computer resources
described earlier, the present invention relies upon the
availability of an operating system and system functions
capable of displaying windows, information in windows,
characters, and cursor symbols on the display devices.
System functions for interfacing with the cursor control
devices and cursor function keys, including the tracking of
cursor location within a window, are also required. These
resources are standard processing components known in the
art.
When the processor of the present invention is first
powered up, the operating system logic obtains control and
initializes the system components such as read/write

US 6,493,002 Bl

9

10

memory, the display device, the cursor control device, the
cursor function keys, and keyboard. During this initialization process or in response to a user command, the operating
system displays the control strip of the present invention.
In one embodiment, the control strip initialization is
performed in two stages. The first stage begins by initially
loading at least one routine at start up. Upon loading
necessary routines, the operating system allocates storage
for global variables use. Next, resources are loaded for use
by the control strip processing logic. These resources
include the visual components or indicia that is to appear in
the control strip, such as pictures, icons, text, etc. The
processing logic for the control strip is patched into the
operating system.
Later, as a second stage of the initialization during the set
up process, the control strip processing logic causes each of
the module files to be opened one at a time. The code for the
module is loaded. An initialization routine is run in response
to a call, during which time, the module itself determines if
it can run. This information is conveyed to the control strip.
The processing logic then causes the window to be displayed
and calls the modules to run themselves and appear in the
control strip. FIG. 2F shows the control strip window
graphics generated by processing logic being combined with
graphics generated by a module to illustrate the creation of
the resulting control strip.
FIG. 4 is a flowchart of the processing logic responsible
for generating the control strip of the present invention and
processing events that occur involving the control strip. In
one embodiment, the control strip main processing is called
by the operating system. Referring to FIG. 4, the processing
begins by saving the previous context and sets up the context
of the control strip (processing block 401). The previous
context refers to the state of the computer system prior to
performing control strip processing. The previous context
may correspond to an application program running immediately prior to the control strip processing being called. The
context may include settings up its memory space, providing
access to its global variables, etc.
Next, a test determines if the secondary initialization has
been done (processing block 402). If the secondary initialization has not been done, processing continues at processing block 403 where a secondary initialization process is
run, and processing thereafter continues at processing block
409. The secondary initialization process causes the processing logic to initialize the control strip. One embodiment
of the secondary initialization process is described in FIG. 5.
On the other hand, if the window of the control strip is
allocated, processing continues at processing block 404
where the processing logic awaits a user event and determines the type of such an event.
Then a test determines if the user event type is a null event
(processing block 405). That is, a test determines whether
the user event type is idle or not. If the user event type is a
null event, processing continues at processing block 406
where idle tasks are run, and processing thereafter continues
at processing block 409. Thus, during idle periods, tasks
involved with the control strip window may be run as well
as tasks of the modules. Examples of module tasks may
include updating help messages (e.g., due to a help feature
being enabled on the computer system) and saving updated
state information (e.g., display area on screen moved to new
location, display area resized, module made invisible; module indicates state is changed and that it must be saved). On
the other hand, if the event type is not a null event,
processing continues at processing block 407.

At processing block 407, a test determines if there has
been a "click" of the mouse within the area defined by the
control strip. If there has been a click of the mouse within
the control strip, the mouse click is processed (processing
block 408), and processing continues at processing block
409. The mouse click processing determines the location of
the mouse click, which module in the controls strip was
selected, or "clicked-on", if any, and any action to be taken
based on that location. One embodiment of the mouse click
processing is described in FIG. 9. If a mouse click has not
occurred within the control strip, processing continues
directly to processing block 409.
At processing block 409, the previous context is restored
and the processing logic exits to return control to the
operating system.
One embodiment of the secondary initialization process
called by the control strip main processing logic is described
in a flowchart in FIG. 5. Referring to FIG. 5, the secondary
initialization process begins by testing whether the Finder™
has started up (processing block 501). If the Finder™ has not
started up, the secondary initialization process ends.
However, if the Finder™ has started up, the window of the
control strip is created (processing block 502).
Then a test determines whether the creation of the window of the control strip was successful (processing block
503). If the creation of the window of the control strip was
not successful, the process ends. The creation of the window
may not be successful because, for instance, there is not
enough memory, missing system resources, etc. On the other
hand, if the creation of the window of the control strip was
successful, the font and color of the control strip are initialized (processing block 504). Then external modules are
opened and initialized (processing block 505), the default
screen location and size of the control strip are set
(processing block 506), the user configuration is loaded
(processing block 507), and the contents of the control strip
are drawn (processing block 508). The user configuration
may include screen location for the control strip, the saved
display order of the modules, the window size of the control
strip, etc. Then the secondary initialization process ends.
The default screen location and size of the control strip are
stored in memory and accessed. In one embodiment, these
values may be changed by the computer user, such as by
interacting with the control strip itself. In another
embodiment, the default values are determined and permanently set by a system designer. Note that specification of the
font, color, default screen location and size may not be
required in lieu of the user configuration. Likewise, by using
solely the default settings, the user configuration is not
required.
One embodiment of the process for opening and initializing external modules such as may be invoked by the
secondary initialization process is shown in FIG. 6. Referring to FIG. 6, the processing logic begins by testing whether
there are more module files to be opened (processing block
601). If there are no more module files (e.g., all the modules
have been opened and loaded), then the process ends. The
modules are opened and initialized one at a time. If there are
more module files, the processing logic opens the module
file (processing block 602) and loads the module code into
memory (processing block 603). The processing logic calls
the module to initialize itself (processing 604). The module
is then also called by the processing logic to obtain the
features of the module (processing block 605) and to obtain
the width of the module's area, as well as features of the
module (processing block 606). The features of the module

5

10

15

20

25

30

35

40

45

50

55

60

65

US 6,493,002 Bl
11

12

include help messages to be displayed when the module is
"clicked on" with the cursor. Then the module file is closed
(processing block 607) and the processing loops back to
processing block 601. By looping back to processing block
601, the processing logic is able to provide the initialization
procedures to all the modules, such that when all the
modules have been processed the process ends. When the
process ends, it returns in a manner well-known in the art to
the processing logic that called (e.g., initiated) it.
One embodiment of a process for drawing the contents of
the control strip (processing block 508), such as used at
processing block 508 of FIG. 5, is described in FIG. 7.
Referring to FIG. 7, the processing logic initially determines
if the control strip is visible (processing block 701). If the
control strip is not visible, processing ends. That is, if the
user has hidden the control strip, the present invention will
not draw its contents.
On the other hand, if the control strip is visible, processing
continues at processing block 702 enters a looping structure
where the processing logic tests whether there are more
modules to draw. If there are no more modules to draw,
processing ends and control returns to the process that called
it. If there are more modules to draw, processing continues
at processing block 703 where the processing logic tests
whether the particular module needs to be redrawn. A
module may need to be drawn when the information being
displayed needs to be updated. For example, as the amount
of energy in the battery is changing due to energy consumption from the computer system, an update to the battery
indicia in the control strip must be made. If the module does
not need to be redrawn, processing loops back to processing
block 702 where the more modules test is repeated. On the
other hand, if the module needs to be redrawn processing
continues at processing block 704 where the processing
logic determines whether the module is a button. If the
module is a button, processing continues at processing block
705 where the background graphics of the button are drawn,
and processing continues to processing block 707. If the
module is not a button, the status-only background graphics
are drawn (processing block 706) and processing continues
at processing block 707. Note that in one embodiment, the
type of background graphics may be obtained using a
message sent to the module requesting its features.
At processing block 707, the processing logic makes a call
to the module to draw itself. That is, it is the responsibility
of the module itself to draw its status for control indicia.
Thereafter processing loops back to processing block 702.
One embodiment of the processing for running idle tasks
in FIG. 4 is described in a flowchart in FIG. 8. Referring to
FIG. 8, the processing logic begins by determining whether
a window update is pending (processing block 801). If a
window update is pending, the processing continues at
processing block 802 when the contents of the control strip
are drawn. Window updates may be required due to a change
in status in one of the modules. Changes may also be due to
a reordering of the control strip entries. Note that one
embodiment of the process to draw the control strip is shown
in FIG. 7. Thereafter processing continues at processing
block 803. If a window update is not pending processing
continues directly to processing block 803.
At processing 803, processing logic tests whether the
configuration of the control strip has changed. If the configuration of the control strip has not changed, processing
continues at processing block 806. If the configuration of the
control strip has changed, processing continues at processing block 804 where a test determines whether it is safe to

perform a save operation. This determination is based on
whether the resources are available (i.e., H.D. is turned on)
to perform the save operation. If it is not safe to perform a
save operation, processing continues at processing block
806. However, if it is safe to save control strip, processing
continues at processing block 805 where the configuration of
the control strip is saved to disk. Thereafter processing
continues to processing block 806.
At processing block 806, the current idle module is called
to run its idle task. In one embodiment, the processing logic
of the present invention allows only one module to run its
idle tasks during each a call to the processing of FIG. 8 (e.g.,
the currently designated module) to reduce overhead time.
Identification of the current module is based on an ID
associated with each of the modules.
Then the idle task undergoes post processing (processing
block 807), and the ID of the next module is updated to idle
(processing block 808). That is, the module designated as the
current module for the next call to the processing of FIG. 8
will be the next module in the list of modules. An example
of the post processing is shown in FIG. 10.
Then, the processing logic determines whether the module needs to save settings for use later (processing block
809). If the module does not need to save its settings,
processing continues to processing block 812. On the other
hand, if the settings of the module are to be saved, the
processing logic tests whether the settings may be saved at
this time (processing block 810). One reason the settings
may not be saved is that the hard disk may be powered down
or turned off. If the settings cannot be saved at this time,
processing continues at processing block 812. If the settings
of the module may be saved at this time, the processing logic
causes the module settings to be saved to disk (processing
block 811). Thereafter, processing continues at processing
block 812.
At processing block 812, the help messages for the control
strip are updated, and processing ends and returns to the
control of the main processing logic.
One embodiment of the mouse click processing of the
present invention, such as used in FIG. 4, is shown in a
flowchart in FIG. 9. Referring to FIG. 9, the processing logic
determines whether a mouse click has occurred inside the
control strip (processing block 901). In one embodiment,
this determination may be made by comparing the current
location of the cursor with the location of the control strip
(e.g., status bar). If a mouse click has not occurred inside the
control strip, then processing loops back upon itself, retesting repeatedly until a mouse click does occur. When a mouse
click occurs within the control strip, processing continues at
processing block 902 where a determination is made as to
upon which module the cursor was during the click.
The processing logic then determines whether a move
operation is being selected by the mouse (processing block
903). If a move operation has been chosen, the display of the
module is moved or the entire control strip is moved
(processing block 904) and the processing logic ends the
mouse click process and exits to control of the processing
logic that called this procedure. The determination of
whether to move a module or the entire strip is based on the
user's keystrokes or mouse movements. On the other hand,
if a move operation is not to occur, processing continues at
processing block 905.
At processing block 905 the processing logic determines
whether the module on which the click occurred is a
"clickable" module, as opposed to a status only module,
(processing block 905). That is, the processing logic tests

5

10

15

20

25

30

35

40

45

50

55

60

65

US 6,493,002 Bl

13

14

whether the module provides any additional functionality
when a mouse moves the cursor to select an element in the
control strip. If the module is not "clickable," processing
ends. If the module is clickable, processing continues to
process processing block 906 where the mouse click is
tracked, i.e., the location of the cursor.
Next, a test determines if the mouse is still within the
bounds of the module (processing block 907). If the mouse
is not within the bounds of the module, processing ends.
However, if the mouse is within the boundaries of the
module, the module is called to process the click (processing
block 908) and the click undergoes post processing
(processing block 909). Thereafter, the process ends.
One embodiment of the process for post processing the
mouse click is shown in FIG. 10. Referring to FIG. 10, the
processing logic begins by determining whether the module
desires to update its settings (processing block 1001). If the
settings for the module are to be updated, processing continues at processing block 1002 where a flag is set to indicate
that the module has a save pending, and processing continues to processing block 1003. The settings for a module may
have to be updated due to user interaction, such as in the case
of an option for a module being turned off or a module
acquiring data as part of its functionality. If the settings of
a module do not have to be updated, processing continues
directly to processing block 1003. Setting may need to be
updated when the module is displaying information that is
changing frequently.
At processing block 1003, a test determines whether the
module needs to resize the display. If the display of the
module must be resized, processing continues at processing
block 1004 where the module is called to update its width.
Then processing continues at processing block 1005. On the
other hand, if the display of the module does not need to be
resized, processing continues directly to processing block
1005.
At processing block 1005, the processing logic determines whether the module desires to be closed. If the
module desires to be closed, processing continues at processing block 1006 where the module is closed immediately.
Then processing continues at processing block 1007. If the
module does not desire to be closed, processing continues to
processing block 1007.
At processing block 1007, a test determines whether the
control strip is to be resized or closed. If the control strip
needs to be resized or closed, processing continues at
processing block 1008 where the module displays are repositioned and redrawn, and then processing continues at
processing block 1009. If the control strip is not to be resized
or closed, processing continues directly to processing block
1009.
At processing block 1009, a test determines whether the
help state of the module is to be changed. The help state
refers to help messages that the modules provide to users
generally. If the help state of the module is to be changed,
processing continues at processing block 1010 where the old
help state of the module is invalidated and the process ends.
If the module help state does not need to be changed,
processing ends. Changes to the help state may occur due to
a global change in the computer system, such as when a
particular help feature (e.g., help balloons) is enabled.

etc., are contained in a file on a disk. The control strip
processing logic draws the strip which acts as the background for the individual modules. Each module is responsible for drawing the icons and other objects that make up its
user interface.
Contents of Module Files
In one embodiment, the module file includes only a single
resource containing the code necessary for the module to
interact with the control strip. A module file may contain
more than one code resource if it is to provide multifunctional support. In that case, each module in the file is loaded
and initialized separately and treated as an independent
entity.
Module Interface
The interface of the module to the control strip comprises
a code resource. In one embodiment, using the Macintosh™
computer, the type of the code resource is 'sdev'. This code
is responsible for performing all of the functions required by
the control strip as well as any functions that are custom to
the module itself. The module's entry point is at the beginning of the resource and is defined as

5

10

15

20

25

30

35

40

45

50

55

60

ADDING CONTROL STRIP MODULES
In one embodiment, the control strip of the present
invention operates as a shell with individual control and
status modules added. Each module and its icons, pictures,

65

pascal long ControlStripModule (long message, long
params, Rect *statusRect, GraftPtr statusport);
Interactions between a module and the control strip are
managed by passing messages to the module to tell it what
to do or to obtain information about the module and its
capabilities. In one embodiment, each module is required to
observe Macintosh™ Pascal register saving conventions;
that is, it may trash 680xO processor registers DO, D1, D2,
AO, and AI, but must preserve all other registers across its
call. Note that other operating systems and implementations
of the present invention may have different restrictions.
The message field comprises a message number from the
list in the section "Control Strip Module Messages" that
indicates to the module the action to perform.
The params field signifies the result returned by the
initialize call to the module. This would typically be a
pointer to a pointer (e.g., the handle) to the private variables
to be used by the module since modules cannot have global
variables. This result is passed to the module on all subsequent calls. Note that in embodiments where modules can
have global variables, such a field may be eliminated.
The statusRect field comprises a pointer to a rectangle
within the control strip defining the area that a module may
draw within.
The statusPort field specifies a pointer to the graphics port
of the control strip. The graphics port may be either a color
or black-and-white graphics port, and depends on the computer system on which the control strip is running.
The result value returned by the module varies depending
on the message sent to it. Results for each message are
described below in the sections on the individual messages.
CONTROL STRIP MODULE REFERENCE
In one embodiment, control strip modules interact with
the control strip processing logic in three ways: by accepting
messages, by calling utility routines, and by calling the
operating system manager (e.g., a call to Gestalt selectors).
The next three sections describe each of those interactions.
Control Strip Module Messages
In one embodiment, all control strip modules respond to
messages from the control strip processing logic, which is
responsive to user interaction with the control strip displayed on the screen. The following messages have been
defined:

US 6,493,002 Bl
15

16

embodiment, this bit is set when, for example, a module
has a pop-up menu associated with it. If this bit is
cleared, the control strip tracks the cursor until the
Message name
Message No. Description
mouse button is released, then sends an sdevMouse5
Click message, described below, to the module to
sdevlnitModule
o
Initialize the module
sdevCloseModule
1
Clean up before being closed
notify it that there was a mouse-down event.
sdevFeatures
Return the feature bits
2
c) sdevHasCustomHelp (2)-If this bit is set, the module
sdevGetDisplayWidth
Return the current width of the
3
is responsible for displaying its own help messages.
module's display
4
Periodic tickle when nothing else is
sdevPeriodicTickle
These help messages may be customized depending on
happening
10
its current state. If the bit is cleared, the control strip
Update the interface in the control
sdevDrawStatus
5
displays a generic help message when the cursor passes
strip
over the its display area and Balloon Help, or other
User has clicked on the module's
sdevMouseClick
display area
help-based information provider, is on.
sdevSavSettings
Save any changed settings in the
7
d) sdevKeepModuleLocked (3)-If this bit is set, the code
module's preferences file
15
of the module is kept locked and protected. In one
Display a help balloon, if the
sdevShowBalloonHelp
8
module has one
embodiment, this bit is set only if the module is passing
the address of one of its routines to a routine external
to the module (e.g., installing itself in a queue).
sdevInitModule
sdevGetDisplayWidth
The sdevInitModule message is the first message sent to 20
The sdevGetDisplayWidth message is sent to a module to
a module after the module has been loaded from its file.
determine how much horizontal space (in pixels) its display
Initialization allows the module to initialize its variables and
currently requires on the control strip. In response to the
to determine whether it can run on a particular machine. For
message, the module return the number of pixels as its result.
example, if the function of the module is to display battery
In one embodiment, the returned width does not comprise
information, it may be only able to run on a portable
25 the maximum width required for any configuration, but
computer, such as the Powerbook manufactured by Apple
instead, reflects how much space it currently requires. Note
Computer.
that this useful because, in one embodiment, its possible for
In response to receiving the sdevInitModule message, the
a module to request that its display be resized.
module loads and detaches any resources (e.g., text, code,
sdevPeriodicTickle
icons, etc.) in its resource file that will be used. Also, space 30
The sdevPeriodicTickle message is passed to the module
is allocated in the global variables for handles to those
periodically to allow the module to update its display due to
detached resources.
changes in its state. In one embodiment, this message occurs
The sdevInitModule message returns a result depending
at regular intervals, while in other embodiments, there is no
on its success at installing itself. In one embodiment, a
minimum or maximum interval between "tickles." In
positive result (~O) indicates successful installation. The
35 response to the sdevPeriodicTickle message, the module
processing logic passes this result value to the module on all
returns, as its result, some bits that signal requests for actions
subsequent calls. A negative result indicates an error
from the control strip processing logic. In one embodiment,
condition, and installation of the module is aborted by the
there are 32 bits returned. All undefined bits in the result are
control strip processing logic. Also if a negative result
reserved for future use and, in one embodiment, are set to O.
occurs and installation has been aborted, the module does
40 The bits are defined as:
not receive a close message.
a) sdevResizeDisplay (O)-If this bit is set, the module
sdevCloseModule
resizes its display. The control strip processing logic
The sDevCloseModule message is sent to a module when
sends a sdevGetDisplayWidth message to the module
it should be closed. In one embodiment, the module itself
and then updates the control strip on the display.
decides when to be closed. A module may be closed when 45
b) sdevNeedToSave (I)-If this bit is set, the module
it no longer is required to be running, such as when a battery
needs to save changed settings to disk. The control strip
level indicator no longer needs to be running when the
processing logic marks the request but may defer the
computer system is receiving its power from an outlet. When
actual save operation to a better time (e.g., when the
the module receives this message, it disposes of all the
hard disk is spinning).
detached resources it loaded as well as its global storage. No 50
result is expected.
c) sdevHelpStateChange (2)-If this bit is set, the help
sdevFeatures
message of the module needs to be updated due to a
The sdevFeatures message queries the module for the
change in state. If a help balloon is being displayed for
features it supports. This message returns as its result a
the module, the control strip processing logic removes
bitmap consisting of I bits for supported features and 0 bits 55
the previous help balloon with a new help balloon for
for unsupported features. In one embodiment, there are 32
the current state.
bits returned. All undefined bits are reserved for future
d) sdevCloseNow (3)-If this bit is set, the module is
features, and, in one embodiment, are set to O. The bits are
requesting to be closed. The control strip processing
defined as:
logic calls the module to save its settings, then calls the
a) sdevWantMouseClicks (O)-If this bit is set, the control 60
module again to close itself by, for example, disposing
strip notifies the module of mouse down events. If this
of any loaded resources, disposing of private storage,
bit is not set, the control strip assumes that the module
etc.
only displays status information with no user interacsdevDrawStatus
tion.
The sdevDrawStatus message indicates that the module
b) sdevDontAutoTrack (I)-If this bit is set, the control 65 has to redraw its display to reflect the most recent state. In
strip highlights the display of the module and then calls
one embodiment, this message is sent when the user clicks
the module to perform mouse tracking. In one
on the display area of the module, when any of the display

US 6,493,002 Bl
17

18

of the module is resized, or when the control strip itself
pascal Boolean SBlsControlStripVisible ( );
The SBlsControlStripVisible routine returns a Boolean
needs to be updated, perhaps in response to a screen saver
value indicating whether or not the control strip is currently
deactivation.
visible. It returns a value of "true" if the control strip is
The statusRect parameter points to a rectangle bounding
the display area of the module, in local coordinates. All 5 visible, or a value of "false" if it's hidden.
In one embodiment, the SBIsControlStripVisible call
drawing done by a module within the bounds of the control
returns a value of "true" even when the control strip is not
strip is limited to the module's display rectangle. In other
visible. That happens whenever the control strip is not
embodiment, drawing may extend outside the display rectaccessible in the current environment. As soon as that
ange of the module. The clipping region of the control strip's
condition changes, the control strip becomes visible again
window is set to the visible portion of the display rectangle 10
and the returned value correctly reflects the actual state.
of the module so that all the elements in the display may be
SBShowHideControlStrip
drawn. If the clipping region is to be changed, the initial
The SBShowHideControlStrip routine shows or hides the
clipping region should be observed to avoid drawing over
control strip. An exemplary call follows:
other items in the control strip.
pascal void SBShowHideControlStrip (Boolean showIt);
sdevMouseClick
15
The SBShowHideControlStrip routine determines the visWhen the user clicks in a display area of the module, the
ibility state for the control strip based on the value of the
control strip processing logic calls the module with the
"showIt" parameter. Passing a value of "true" makes the
sdevMouseClick message if the sdevWantMouseClicks bit
control strip visible, and passing a value of "false" hides it.
is set in the features of the module.
If the sdevDontAutoTrack bit is also set, the control strip 20 Modules may not need to call this routine. However, the
SBShowHideControlStrip routine provides a means for
processing logic draws the display of the module in its
other software to hide the control strip when it is in the way.
highlighted state and then sends the sdevMouseClick mesCalling the SBShowHideControlStrip routine with a
sage to the module. If the sdevDontAutoTrack bit is not set,
"showIt" value of "true" mayor may not show the control
the control strip processing logic tracks the cursor until the
mouse button is released. If the cursor is still within the 25 strip, depending on the current environment. If the control
strip is not accessible, it does not become visible. If a
display area of the module, the control strip processing logic
"showIt" value of "true" is passed to this routine, then the
sends the sdevMouseClick message to notify the module
control strip becomes visible when the environment
that a click occurred. In either case, the module can then
changes.
perform the appropriate function in response to a mouseSBSafeToAccessStartupDisk
down event.
30
The SBSafeToAccessStartupDisk routine determines
This message returns the same result as the sdevPeriodwhether the internal hard disk is turned on so that processing
icTickle message.
logic of the present invention can determine whether to
sdevSaveSettings
make a disk access or postpone it until a time when the disk
The sdevSaveSettings message is passed to the module
when the control strip processing logic has determined that 35 is already spinning. An exemplary call follows:
pascal Boolean SBSafeToAccesStartupDisk ( );
the configuration information may be saved to the disk (e.g.,
The SBSafeToAccessStartDisk routine returns a Boolean
HD turned on, etc.). In one embodiment, the sdevSaveSetvalue of "true" if the disk is turned on and "false" if it is not.
tings message is sent only if the module had previously set
SBOpenModuleResourceFile
the sdevNeedToSave bit in the result of a sdevPeriodicTickle
The SBOpenModuleResourceFile routine opens a module
or sdevMouseClick message. The call returns an error code 40
resource file. An examplary call follows:
(File Manager, Resource Manager, or the like) indicating the
pascal short SBOpenModuleResourcFile (OSType
success of the save operation. The control strip processing
file Creator);
logic continues to send this message to the module until the
The SBOpenModuleResourceFile routine opens the
module returns a result of 0, indicating a successful save.
45 resource fork of the module file whose creator is
sdevShowBalloonHelp
"fileCreator", and return the file's reference number as its
The control strip processing logic calls the module with
result. If the file cannot be found or opened, the SBOpenthe sdevShowBalloonHelp message if Balloon Help is
MduleResourceFile routine returns a result of -l.
turned on, the module has previously set the sdevHasCusThe SBOpenModuleResourceFile routine also provides a
tomHelp bit in its features, and the cursor is over the
module's display area. In such a case, the module calls the 50 means for a module to load in large or infrequently used
resources that it doesn't usually need, but that it requires for
Help Manager to display a help balloon describing the
a particular operation.
current state of the module. The module returns a value of
SBLoadPreferences
o if successful or an appropriate error result if not.
The SBLoadPreferences routine loads a resource from a
UTILITY ROUTINES
55 preferences file. An examplary call follows:
In one embodiment, the control strip processing logic
pascal OSErr SBLoadPreferences (ConstStr255Param
provides a set of utility routines that are available to control
prefsResourceNarne, Handle *preferences);
strip modules. They are provided to promote a consistent
The SBLoadPreferences routine loads a resource containuser interface within the control strip and to reduce the
ing a module's configuration information from the preferamount of duplicated code that each module would have to 60 ences file of the control strip. The PrefsResourceName
include to support common functions. Therefore, in an
parameter points to a Pascal string containing the name of
embodiment that does not include these utility routines, a
the resource. The "Preferences" parameter points to a variportion or all of the modules may include duplicated code
able that holds a handle to the resource read from the file.
supporting common functions.
The handle does not need to be preallocated.
SBlsControlStripVisible
65
If either prefsResourceName or preferences contains a nil
pointer, the SBLoadPreferences routine does nothing and
The SBlsControlStripVisible routine determines whether
returns a result of paramErr. If the resource is successfully
the control strip is visible. An exemplary call follows:

US 6,493,002 Bl

19

20

loaded, the SBLoadPreferences routine returns a result of O.
The SBLoadPreferences routine also returns other Memory
Manager and Resource Manager errors if it fails during
some art of the process.
SBSavePreferences
The SBSavePreferences routine saves a resource to a
preferences file. An exemplary call follows:
pascal OSErr SBSavePreferences (ConstStr255Param
prefsResourceNarne, Handle preferences);
The SBSavePreferences routine saves a resource containing a module's configuration information to the preferences
file of the control strip. The PrefsResourceName parameter
points to a Pascal string containing the name of the resource.
The "preferences" parameter contains a handle to a block of
data which will be written to the file.
If either prefsResourceName or preferences has a nil
value, the SBSavePreferences routine does nothing and
returns a result of paramErr. if the resource is successfully
saved, the SBSavePreferences routine returns a result of O.
The SBSavePreferences routine can also return other
Memory Manager and Resource Manager errors if it fails
during some part of the process.
SBGetDetachedString
The SBGetDetachedIndString routine obtains a string
from a detached resource. An exemplary call follows:
pascal void SBGetDetachedIndString (StringPtr the
String, Handle stringList, short whichString);
The SBGetDetachedIndString routine is the detached
resource version of GetIndString. The parameter thestring
points to a Pascal string; the stringList is a handle to a
detached 'STR#' resource; and whichString is the index
(l-n) into the array of Pascal strings contained in the
detached resource. The SBGetDetachedIndString routine
copies the string whose index is whichString into the space
pointed to by theString. If whichString is out of range, the
SBGetDetachedIndString routine returns a zero-length
string.
SBGetDetachIconSuite
The SBGetDetachIconSuite routine sets up a detached
icon suite. An exemplary call follows:
pascal OSErr SBGetDetachIconSuite (Handle
*theIconSuite, short theResID, unsigned long selector);
The SBGetDetachIconSuite routine creates a new icon
suite, loads all of the requested icons, and then detaches the
icons. The parameter theIconSuite points to the location
where the handle to the icon suite is stored; the parameter
theResID is the resource ID of the icons that make up the
icon suite; and the parameter "selector" indicates which
icons are to be loaded into the suite. In one embodiment, the
"selector" parameter contains one (or a combination of) the
following values:

module is open. This is typically the case during a module's
initialization call.
SBTrackpopupMenu
The SBTrackpopupMenu routine manages a pop-up
menu. An exemplary call follows:
pascal short SBTrackpopupMenu (const Rect
*moduleRect, MenuHandle theMenu);
The SBTrackpopupMenu routine handles setting up and
displaying a pop-up menu associated with a module. The
module passes a pointer to its display rectangle and a handle
to the menu to use. In one embodiment the menu is displayed
immediately above and adjacent to the display rectangle of
the module, yet this is not required. By doing so, the user is
allowed to view the current configuration or to change the
settings. The SBTrackpopupMenu routine returns an indication as to which menu item was selected, or 0 if no item
was selected (e.g., because the user moved the cursor outside
the menu's bounds).
SBTrackSlider
The SBTrackSlider routine displays and sets an arbitrary
parameter. An exemplary call follows:
pascal short SBTrackSlider (const Rect *moduleRect,
short ticksOnSlider, short initiaIValue);
The SBTrackSlider routine displays an unlabeled slider
above the module's display rectangle. The slider may be
used for displaying and setting the state of an arbitrary
parameter. The parameter "ModuleRect" contains a pointer
to the module's display rectangle; "ticksOnSlider' is the
upper bounds of the value returned by the slider; and
"initiaIValue" is the starting position (0 to ticksOnSlider -1).
When the user releases the mouse button, the SBTrackSlider
routine returns the final position.
SBShowHelpString
The SBShowHelpString routine displays a help balloon.
An exemplary call follows:
pascal OSErr SBShowHelpString (const Rect
*moduleRect, StringPtr helpstring);
The SBShowHelpString routine displays a module's help
balloon. The module passes a pointer to its display rectangle
and a pointer to a Pascal string, and the routine displays the
balloon if possible. If the help dstring has a length of 0 or the
Help Manager is unable to display a balloon, an error result
is returned. If the SBShowHelpString routine successfully
displays the help balloon, it returns a result of O.
SBGetBarGraphWidth
The SBGetBarGraphWidth routine determines how wide
a bar graph drawn by the SBDrawBarGraph routine
(described below) will be so that a module can calculate its
display width. An exemplary call follows:
pascal short SBGetBarGraphWidth (short barCount);
The SBGetBarGraphWidth routine returns the width of a
bar graph containing barCount segments. If barCount has a
value less than 0, the SBGetBarGraphWidth routine returns
a width of O.
SBDrawBarGraph
The SBDrawBarGraph routine draw as bar graph. An
exemplary call follows below:
pascal void SBDrawBarGraph (short level, short
barCount, short direction, Point barGraphTopLeft);
The SBDrawBarGraph routine draws a bar graph containing the number of segments specified by the barCount
parameter in a module's display area. If the value of
barCount is less than or equal to 0, the SBDrawBarGraph
routine does nothing.
The bar graph is drawn relative to the location specified
by barGraphTopLeft. FIG. 11 illustrates the manner in which
the point barGraphTopLeft determines the position of the
bar graph.

svAllLargeData

OxOOOOOOFF

svAllSmallData

xOOOOFFOO

svAllMiniData

OxOOFFOOOO

load large 32-by-32-pixel icons
('ICN#', 'io14', 'io18')
load small 16-by-16-pixel icons
('ics#', 'ics4', 'ics8')
load mini 12-by-12-pixel icons
('icm#', icm4', 'icm8')

5

10

15

20

25

30

35

40

45

50

55

60

These values may be ORed together to load combinations
of icon sizes. The SBGetDetachIconSuite routine returns an
appropriate error code if it's unsuccessful, or 0 if it was able
to load the icon suite. Note that if none of the icons
comprising the icon suite could be found, the call returns the
error "resNotFound. In one embodiment, the SBGetDetachIconSuite routine is called only when the resource file of the

65

US 6,493,002 Bl

21

22

The "level" parameter determines how many segments
description, it is to be understood that the particular embodiment shown and described by way of illustration is in no
are highlighted. The value of "level" should be in the range
way intended to be considered limiting. Therefore, referof 0 to barCount -1. If the value of "level" is less than 0, no
ences to details of the preferred embodiment are not
segments in the bar graph are highlighted; if "level" is
greater than or equal to barCount, all segments in the bar 5 intended to limit the scope of the claims which in themselves
recite only those features regarded as essential to the invengraph are highlighted.
tion.
The direction parameter specifies which way the bar
Thus, a method and apparatus for generating a window
graph will be drawn to show a larger level. In one
displaying control and status indicia has been described.
embodiment, the direction parameter specifies one of the
I claim:
10
following values:
1. An interactive computer-controlled display system
#define BarGraphSlopeLeft -1 //max end of sloping
comprising:
graph is on the left #define BarGraphFlatRight 0 //max
a processor;
end of fiat graph is on the right #define BarGraphSloa data display screen coupled to the processor;
peRight 1 //max end of sloping graph is on the right
a cursor control device coupled to said processor for
FIG. 12 illustrates the resulting bar graph for each direc- 15
positioning a cursor on said data display screen;
tion value. The arrows indicate which wayan increasing
a window generation and control logic coupled to the
level value is displayed. In one embodiment, for sloped
processor and data display screen to create an operating
versions of the bar graph, the number of segments specified
environment for a plurality of individual programming
by the barCount value may not be larger than 8. If a larger
modules associated with different application programs
barCount value is passed, the SBDrawBarGraph routine 20
that provide status and/or control functions, wherein
draws nothing.
the window generation and control logic generates and
SBModalDialoglnContext
displays a first window region having a plurality of
The SBModalDialoglnContext routine may be used in
display areas on said data display screen, wherein the
place of the ModalDialog routine to prevent background
first window region is independently displayed and
applications from being run while the modal dialog window 25
independently active of any application program, and
wherein each of the plurality of display areas is assois visible. An exemplary call is as follows:
ciated with one of the plurality of individual programpascal
void
SBModalDialoglnContext
ming modules, the first window region and the plurality
(ModalFilterProcPtr filterProc, short *itemHit);
of independent display areas implemented in a window
The SBModalDialoglnContext routine is a special version
layer that appears on top of application programming
of ModalDialog that doesn't allow background applications 30
windows that may be generated; and
to be run while a modal dialog window is visible. The
an indicia generation logic coupled to the data display
SBModalDialoglnContext routine is used when the
screen to execute at least one of the plurality of
occurence of context switching is not desired.
individual programming modules to generate informaGESTALT SELECTOR
35
tion for display in one of the plurality of display areas
in the first window region, wherein at least one of the
The control strip processing logic installs two "Gestalt"
plurality of display areas and its associated programselectors to return information to locations external to the
ming module is sensitive to user input, and further
computer system. One selector returns software attributes,
wherein the window generation and control logic and
and the other returns the current version of the processing
40
the indicia generation logic use message-based comlogic (e.g., software).
munication to exchange information to coordinate
gestaltControlStripAttr
activities of the indicia generation logic to enable
The selector "gestaltControlStripAttr (,sdev') return 32
interactive display activity.
bits describing the attributes of the current version of the
2. The display system defined in claim 1 wherein the first
control strip processing logic. In one embodiment, only the
45 window region comprises a control strip.
following bit is defined:
3. The display system defined in claim 1 wherein said at
gestaltControlStripExists 0 l=control strip is installed
least one display area is variably sized.
gestaltControlStripVersion
4. The display system defined in claim 1 wherein size of
The selector gestaltControlStripVersion ('csvr') returns
the first window region is variable.
the version of control strip processing logic that is installed. 50
5. The display system defined in claim 4 wherein the first
The format of the returned version is the same as that of the
window region is sized such that none of the plurality of
numeric part of a Macintosh™ computer system resource,
display areas is visible.
that is:
6. The display system defined in claim 4 wherein the first
55
Bits
Bits
Bits
Bits

31-24
23-20
19-16
15-8

Major part of the version, in BCD
Minor part of the version, in BCD
Bug release version, in BCD
Release stage:
$80~final
$60~beta

60

$40~alpha
$20~development

Bits 7-0

Revision level of nonreleased version, in binary

Whereas many alterations and modifications of the
present invention will no doubt become apparent to a person
of ordinary skill in the art after having read the foregoing

65

window region is sized such that all of the plurality of
display areas are visible.
7. The display system defined in claim 4 wherein the first
window region is sized such that a portion of the plurality of
display areas is visible.
8. The display system defined in claim 1 wherein at least
one of the plurality of the display areas only displays
information.
9. The display system defined in claim 1 wherein at least
one of the display areas acts to provide access to control
information when selected.
10. The display system defined in claim 9 wherein said at
least one of the plurality of display areas displays an
additional display element.

US 6,493,002 Bl
23
11. The display system defined in claim 1 wherein each of
the plurality of display areas is individually and variably
sized.
12. The display system defined in claim 1 wherein the first
window region always appears in front of application windows.
13. The display system defined in claim 1 wherein the first
window region is implemented in a private window layer
that appears in front of windows for all applications layers.
14. An interactive computer-controlled display system
comprising:
a processor;
a data display screen coupled to the processor;
a cursor control device coupled to said processor for
positioning a cursor on said data display screen;
window generation and control logic coupled to the
processor and data display screen to create an operating
environment for a plurality of individual programming
modules associated with different application programs
that provide status and/or control functions, wherein
the window generation and control logic generates and
displays a first window-region having a plurality of
display areas on said data display screen, wherein the
first window region is independently displayed and
independently active of any application program, and
wherein each of the plurality of display areas is associated with one of the plurality of individual programming modules, the first window region and the plurality
of independent display areas implemented in a window
layer that appears on top of application programming
windows that may be generated; and
at least one indicia graphics generation logic coupled to
the processor and the window generation and control
logic, wherein said at least one indicia graphics generation logic generates user sensitive graphics for display in at least one data display area by executing at
least one of the plurality of individual programming
modules;
wherein the window generation and control logic determines when said at least one data display area has
been selected by the user and signals said at least one
indicia graphics generation logic in response to user
selection, and further wherein said at least one indicia graphics generation logic initiates a response
from said at least one of the plurality of programming modules.
15. The display system defined in claim 14 wherein the
first window region is always visible to the user.
16. The display system defined in claim 14 wherein the
first window region comprises a control strip.
17. The display system defined in claim 14 wherein said
at least one display area is variably sized.
18. The display system defined in claim 14 wherein each
of the plurality of display areas is individually and variably
sized.
19. The display system defined in claim 14 wherein the
first window region always appears in front of application
windows.
20. The display system defined in claim 14 wherein the
first window region is implemented in a private window
layer that appears in front of windows for all applications
layers.
21. A method for generating control information compris-

24

ferent application programs that provide status and/or
control functions;
generating a first window sized to accommodate a plurality of display areas for indicia resulting from execut5
ing at least one of the plurality of individual programming modules, wherein each of the plurality of display
areas is associated with one of the plurality of individual programming modules, and wherein the first
window is independently displayed and independently
10
active of any application program, the first window
region and the plurality of independent display areas
implemented in a window layer that appears on top of
application programming windows that may be generated;
15
displaying the indicia in each of said plurality of display
areas by executing one of a plurality of individual
programming modules corresponding to each indicia;
selecting one of the indicia, wherein the selecting comprises a first programming module determining which
20
of said plurality of display areas is selected and sending
a message to a programming module of said plurality of
individual programming modules responsible for generating a display of a selected indicia;
said programming module performing a function in
25
response to a selection.
22. The method defined in claim 21 wherein one of said
plurality of indicia comprises status information.
23. The method defined in claim 21 wherein one of said
30 plurality of indicia comprises control information.
24. The method defined in claim 21 further comprising:
the first programming module requesting a set of features
supported by said programming module, wherein said
requesting comprises sending a first message to said
programming module; and
35
said programming module returning a second message
indicative of features supported by said programming
module, such that said first programming module interacts with said programming module in response to user
interaction with the first programming module based on
40
indicated features as set forth by said programming
module.
25. A system comprising:
a window generation and control logic to create an
45
operating environment for a plurality of individual
programming modules associated with different application programs that provide status and/or control
functions, wherein the window generation and control
logic generates and displays a first window region
50
having a plurality of display areas, wherein the first
window region is independently displayed and independently active of any application program, and
wherein each of the plurality of display areas is associated with one of the plurality of individual program55
ming modules, the first window region and the plurality
of independent display areas implemented in a window
layer that appears on top of application programming
windows that may be generated;
an indicia generation logic coupled to the data display
60
screen to execute at least one of the plurality of
individual programming modules to generate information for display in one of the plurality of display areas
in the first window region, wherein at least one of the
plurality of display areas and its associated program~:
~
ming module is sensitive to user input, and further
wherein the window generation and control logic and
creating an operating environment for a plurality of
the indicia generation logic use message-based comindividual programming modules associated with dif-

US 6,493,002 Bl

25

26

munication to exchange information to coordinate
activities of the indicia generation logic to enable
interactive display activity.
26. An interactive computer-controlled display system
comprising:
a means for positioning a cursor on a data display screen;
a means for creating an operating environment for a
plurality of individual programming modules associated with different application programs that provide
status and/or control functions, wherein a first window
region is displayed having a plurality of display areas
on said data display screen, wherein the first window
region is independently displayed and independently
active of any application program, and wherein each of
the plurality of display areas is associated with one of
the plurality of individual programming modules, the
first window region and the plurality of independent
display areas implemented in a window layer that
appears on top of application programming windows
that may be generated; and
a means for executing at least one of the plurality of
individual programming modules to generate information for display in one of the plurality of display areas
in the first window region, wherein at least one of the
plurality of display areas and its associated programming module is-sensitive to user input, wherein an
interactive display activity is enabled.
27. The display system defined in claim 26 wherein the
first window region comprises a control strip.
28. The display system defined in claim 26 wherein said
at least one of the plurality of display areas is variably sized.
29. The display system defined in claim 26 wherein size
of the first window region is variable.
30. The display system defined in claim 29 wherein the
first window region is sized such that none of the plurality
of display areas is visible.
31. The display system defined in claim 29 wherein the
first window regions is sized such that all of the plurality of
display areas are visible.
32. The display system defined in claim 29 wherein the
first window regions is sized such that a portion of the
plurality of display areas is visible.
33. The display system defined in claim 26 wherein said
at least one of the plurality of display areas only displays
information.
34. The display system defined in claim 26 wherein said
at least one of the plurality of display areas acts to provide
access to control information when selected.
35. The display system defined in claim 34 wherein said
at least one of the data areas display an additional display
element.
36. The display system defined in claim 26 wherein each
of the plurality of display areas is individually and variably
sized.
37. The display system defined in claim 26 wherein the
first window region always appears in front of application
windows.
38. The display system defined in claim 26 wherein the
first window region is implemented in a private window
layer that appears in front of windows for all application
layers.
39. An interactive computer-controlled display system
comprising:
a means for positioning a cursor on said data display
screen;
a means for creating an operating environment for a
plurality of individual programming modules associ-

ated with different application programs that provide
status and/or control functions, wherein a first window
region is displayed having a plurality of display areas
on said data display screen, wherein the first window
region is independently displayed and independently
active of any application program, and wherein each of
the plurality of display areas is associated with one of
the plurality of individual programming modules, the
first window region and the plurality of independent
display areas implemented in a window layer that
appears on top of application programming windows
that may be generated;
a means for generating user sensitive graphics for display
in at least one data display area;
a means for determining when said at least one data
display area has been selected by the user; and
a means for initiating a response from said at least one of
the plurality of programming modules.
40. The display system defined in claim 39 wherein the
first window region is always visible to the user.
41. The display system defined in claim 39 wherein the
first window region comprises a control strip.
42. The display system defined in claim 39 wherein said
at least one data display area is variably sized.
43. The display system defined in claim 39 wherein each
of the plurality of display areas is individually and variably
sized.
44. The display system defined in claim 39 wherein the
first window region always appears in front of application
windows.
45. The display system defined in claim 39 wherein the
first window region is implemented in a private window
layer that appears in front of windows for all applications
layers.
46. A computer readable medium containing executable
computer program instructions, which when executed by a
data processing system, cause the data processing system to
perform a method for generating control information comprising:
creating an operating environment for a plurality of
individual programming modules associated with different application programs that provide status and/or
control functions;
generating a first window sized to accommodate a plurality of display areas for indicia resulting from executing at least one of the plurality of individual programming modules, wherein each of the plurality of display
areas is associated with one of the plurality of individual programming modules, and wherein the first
window is independently displayed and independently
active of any application program, the first window
region and the plurality of independent display areas
implemented in a window layer that appears on top of
application programming windows that may be generated;
displaying the indicia in each of the plurality of display
areas by executing one of a plurality of individual
programming modules corresponding to each indicia;
and
selecting one of the indicia, wherein the selecting comprises a first programming module determining which
of the plurality of display areas is selected and sending
a message to a programming module of the plurality of
individual programming modules responsible for generating a display of a selected indicia, and the programming module performing a function in response to a
selection.

5

10

15

20

25

30

35

40

45

50

55

60

65

US 6,493,002 Bl
27
47. The computer readable medium as set forth in claim
46 wherein ones of the indicia comprises status information.
48. The computer readable medium as set forth in claim
46 wherein one of the indicia comprises control information.
49. The computer readable medium as set forth in claim 5
46 further comprising:
the first programming module requesting a set of features
supported by said programming module, wherein
requesting comprises sending a first message to said
programming module; and
10
said programming module returning a second message
indicative of features supported by said programming
module, such that said first programming module interacts with said programming module in response to user
interaction with the first programming module based on 15
indicated features as set forth by said programming
module.
50. A system comprising:
a means for window generation and control to create an 20
operating environment for a plurality of individual
programming modules associated with different application programs that provide status and/or control
functions, wherein the means for window generation
and control generates and displays a first window

28
region having a plurality of display areas, wherein the
first window region is independently displayed and
independently active of any application program, and
wherein each of the plurality of display areas is associated with one of the plurality of individual programming modules, the first window region and the plurality
of independent display areas implemented in a window
layer that appears on top of application programming
windows that may be generated;
a means for indicia generation coupled to the data display
screen to execute at least one of the plurality of
individual programming modules to generate information for display in one of the plurality of display areas
in the first window region, wherein at least one of the
plurality of display areas and its associated programming module is sensitive to user input, and further
wherein the means for window generation and control
and the means for indicia generation use messagebased communication to exchange information to coordinate activities of the means for indicia generation to
enable interactive display activity.

* * * * *