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 H

111111111111111111111111111111111111111111111111111111111111111111111111111
US005969705A

United States Patent

[11]

Fisher et al.
[54]

MESSAGE PROTOCOL FOR CONTROLLING
A USER INTERFACE FROM AN INACTIVE
APPLICATION PROGRAM

[75]

Inventors: Stephen Fisher, Menlo Park; Eric
Mathew Trehus, Milpitas, both of
Calif.

[73]

Assignee: Apple Computer, Inc., Cupertino,
Calif.

[21]

Appl. No.: 08/816,492

[22]

Filed:

Related U.S. Application Data
Continuation of application No. 08/312,437, Sep. 26, 1994,
abandoned, which is a continuation of application No.
08/084,288, Jun. 28, 1993, abandoned.

[51]
[52]
[58]

Int. C1. 6
G09G 5/00
U.S. Cl.
345/114; 345/345
345/119, 120,
Field of Search
345/118, 113, 114, 115, 343, 344, 345,
346, 347, 348; 395/155, 156, 157, 158

[56]

U.S. PATENT DOCUMENTS

[57]

Thornburg.
Cason et al. .
Pike.
Agarwal.
Barker et al. .

ABSTRACT

Method and apparatus for a first process operative in a
computer system controlling a user interface on a computer
system display under control of a second process operative
in the computer system. An event handler is installed for the
second process, the event handler servicing events generated
for controlling the user interface display under control of the
second process. The first process may then perform a first set
of functions in the computer system. The first process
generates events for controlling the user interface display,
the events related to the functions performed by the first
process. The event handler receives the events generated by
the first process and updates the user interface on the
computer system display according to the events generated
by the first process and received by the event handler.

(List continued on next page.)
OlliER PUBLICATIONS
"Notebook Tabs as Target Location for Drag/Drop Operations",IB, vol. 35, No.7, Dec. 1992.
Microsoft Corporation, "Microsoft Windows Paint User's
Guide," Version 2.0, 1987, pp. 8-10, 44-45.
Microsoft Corporation, "Microsoft Windows Write User's
Guide," Version 2.0, 1987, pp. 60-65.
Microsoft Corporation, "Microsoft Word: Using Microsoft
Word", Version 5.0, 1989, pp. 69,88-93.

1 Claim, 7 Drawing Sheets

CLIENT APPLICATION
PROGRAM
(BACKGROUND APPLICATION)

llQ

~~
=)

EVENTS

GUI SERVER
APPLICATION PROGRAM
(ACTIVE APPLICATION)

;@

~

~t

/340

Items remaining to be copied:
Reading:

Oct. 19, 1999

Primary Examiner-Chanh Nguyen
Attorney, Agent, or Firm-Blakely, Sokoloff, Taylor &
Zafman

References Cited

4,313,113
1/1982
4,484,302 11/1984
4,555,775 11/1985
4,688,167 8/1987
4,698,624 10/1987

Date of Patent:

5,969,705

Screen Dumps from Microsoft Windows V 3.1, Microsoft
Corporation 1985-1992 (14 pages).
WordPerfect for Windows V 5.1, WordPerfect Corporation,
1991 (16 pages).
Jeffrey M. Richter, "Implementing Drag-and-Drop," Windows 3.1: A Developer's Guide, 2nd Edition, M&T Books,
A Division of M&T Publishing, Inc. (1992), pp. 541-577
(Chapter 9).
Charles Petzold, ''Windows™ 3.1-Hello to TrueType™,
OLE, and Easier DDE; Farewell to Real Mode," Microsoft
Systems Journal, vol. 6, No.5 Sep. 1991, pp. 17-26.
Jeffrey Richter, "Drop Everything: How to Make Your
Application Accept and Source Drag-and-Drop Files,"
Microsoft Systems Journal, vol. 7, No.3, May/Jun. 1992, pp.
19-30.
Future Enterprises Inc., A Microcomputer Education Course
for: U.S. Department of Commerce "Studen Workbook for
Quattro Pro 3.0-Concepts and Basic Uses," 1991 (3
pages).
Inside Macintosh, vol. VI, 1991, pp. 5-1 to 5-117.
Microsoft Windows 3.1, Step by Step, 1991, pp. 168-170.
Apple Computer, Inc., Inside Macintosh, vol. VI Table of
Contents, 5-1 through 6-117 (1991).

Mar. 13, 1997

[63]

Patent Number:

[45]

[19]

1

PowerTalk Manager.res
I

~

5,969,705
Page 2

U.S. PATENT DOCUMENTS
4,698,625 10/1987 McCaskill.
1/1988 Schnarel, Jr. et al. .
4,720,703
4,780,883 10/1988 O'Connor et al. .
4,831,556 5/1989 Oono.
4,862,376 8/1989 Ferriter et al. .
4,868,765 9/1989 Diefendorff.
4,905,185 2/1990 Sakai.
4,922,414 5/1990 Holloway et al. .
4,954,967 9/1990 Takahashi.
5,047,930 9/1991 Martens et al. .
1/1992 Dysart et al. .
5,079,695
5,140,677 8/1992 Fleming et al. .
5,157,763 10/1992 Peters et al. .
5,196,838 3/1993 Meier et al. .
5,202,828 4/1993 Vertelney et al. .

5,214,756 5/1993 Franklin et al. .
5,226,117 7/1993 Miklos.
5,226,163 7/1993 Karsh et al. .
5,228,123 7/1993 Heckel.
5,260,697 11/1993 Barrett et al.
5,287,448 2/1994 Nicol et al. .
5,301,268 4/1994 Takeda.
5,305,435 4/1994 Bronson.
5,333,256 7/1994 Green et al. .
5,339,392 8/1994 Risberg et al. .
5,341,293 8/1994 Vertelney et al. .
5,371,844 12/1994 Andrew et al. .
5,371,851 12/1994 Pieper et al. .
5,400,057 3/1995 Yin.
5,422,993 6/1995 Fleming.
5,442,742 8/1995 Greyson et al. .

345/173

u.s.

Patent

Oct. 19, 1999

5,969,705

Sheet 1 of 7

r--------------------,

.I'-

DISPLAY
121

'"

~

I
I
I

MAIN
MEMORY 104

I
I
I

I ...

)

KEYBOARD
122

I

Y

STATIC
MEMORY j]Q

D

J7
'vi

BUS

I
I

n

101

D
PROCESSOR

1
1

CURSOR
CONTROL 123

MASS STORAGE
DEVICE 107

1
102
1
100
1- - - - - - - - - - - - - - - - - - - -

HARD COpy 1.1'4...-DEVICE 124 I\.
~

FIG. 1

u.s.

Patent

5,969,705

Sheet 2 of 7

Oct. 19, 1999

212
230

•

File Edit View

Label

E!lii

Untitled - 2
v

~From

Subject
Plans for my sabbatical

~~-----,

IMike Cleron

~

,,~

~ Recipients
~John

Evans
Fisher

~ Steve

To IQ
CC

~

Enclosures

~-+D_o_cu_m_e_nt

2_k~40

~41

1
....

Hi Guys,
For my sabbatical, I plan to be the first person to rollerblade accross .
the
.
. . .

Window 1
1 item

76 MB in disk 882k available

D~221

~220

Document

FIG. 2
(PRIOR ART)

u.s.

Patent

5,969,705

Sheet 3 of 7

Oct. 19, 1999

CLIENT APPLICATION
PROGRAM
(BACKGROUND APPLICATION)
310

GUISERVER
APPLICATION PROGRAM
(ACTIVE APPLICATION)

EVENTS

~

,7

340
/

Items remaining to be copied:
Reading:

1

PowerTalk Manager.res

~

FIG. 3

---

I (Stop)

u.s. Patent

5,969,705

Sheet 4 of 7

Oct. 19, 1999

400
410

<Status String>

420"....<Count String>

430

<Action String> <Object Name>

(
451

452

FIG. 4
(PRIOR ART)

450

460

u.s. Patent

Oct. 19, 1999

5,969,705

Sheet 5 of 7

EVENT HANDLER FOR USER INTERFACE
CONTROL OF COpy WINDOW

,....-

5QQ

-, _,5
:,03

DISPLAY NEW COPY WINDOW

ERROR -INDICATE
EVENTNOTHANDLED

507
ELIMINATE COpy WINDOW
DISPLAYED

UPDATE PROGRESS BARTO
PROGRESSVALU8PROGRESSMAX

510

NO

512

ERROR - INDICATE
EVENTNOTHANDLED

FIG. SA

u.s.

Patent

5,969,705

Sheet 6 of 7

Oct. 19, 1999

UPDATE

STATUSSTRING

521

UPDATE COUNTSTRING

523

UPDATE ACTIONSTRING

525

~==--~

UPDATE OBJECTNAMESTRING...-at

527
NO

528

ERROR -INDICATE
EVENTNOTHANDLED

FIG. 58

u.s.

Patent

Sheet 7 of 7

Oct. 19, 1999

5,969,705

DISPLAY GENERIC ALERT

531
DISPLAY "NOTE" ALERT

533
DISPLAY CONFIRM/CANCEL
OPTION

535
DISPLAY CONFIRM/CANCEL
OPTION

537
DISPLAY
CANCELDEFAULTCONFIRM
OPTION

539
DISPLAY SAVECHANGES
OPTION?
NO

543

541

ERROR -INDICATE
EVENTNOTHANDLED

FIG.5C

5,969,705
1

2

MESSAGE PROTOCOL FOR CONTROLLING
A USER INTERFACE FROM AN INACTIVE
APPLICATION PROGRAM

gram may direct a foreground application program to control
its user interface in a specified way.
Another of the objects of the present invention is to allow
a background application program to communicate with a
foreground application program for controlling the user
interface of a computer system display.
Another object of the present invention is to allow a
foreground application program controlling a user interface
to take advantage of the services of a background application program.
Method and apparatus for a first process operative in a
computer system controlling a user interface on a computer
system display under control of a second process operative
in the computer system. An event handler is installed for the
second process, the event handler servicing events generated
for controlling the user interface display under control of the
second process. The first process may then perform a first set
of functions in the computer system, in one embodiment,
such as file management functions (e.g. copying and/or
moving of files in the file system). The first process generates a first set of events for controlling the user interface
display, the first set of events related to the first set of
functions performed by the first process. For example, in
various embodiments, feedback may be given about the
progress of the file management functions (such as copying/
moving specific files, reading from a source, and copying to
a destination). The event handler receives the first set of
events generated by the first process and updates the user
interface on the computer system display according to the
events generated by the first process and received by the
event handler. This may include, showing the progress of the
file management operation, and alerting the user of any
abnormal conditions.
Other features, objects, and advantages of the present will
become apparent from viewing the figures and the description below.

This is a continuation of application Ser. No. 08/312,437,
filed Sep. 26, 1994, now abandoned, which is a continuation
of application Ser. No. 08/084,288, filed Jun. 28, 1993
status: abandoned.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to user interface control in
a computer system. More specifically, the present invention
relates to a messaging protocol which allows one application
program to specify the appearance of an interface of a
computer system while under control of a second application
program.
2. Background Information
In multitasking operating systems, such as the Macintosh
brand System 7.0 operating system available from Apple
Computer, Inc. of Cupertino, Calif., typically, only one
application program is given complete control of the user
interface in order to prevent conflicts. There are
circumstances, however, in which an application program
which does not currently have control of the user interface
will require that some information be presented to a user of
the computer system. Typically, in the prior art, in these
situations, the "inactive" application program must be
"brought to the front" or made the active application (one in
control of the user interface) in order for user interface
control to become available to the application program. If
events or other activities occur within the process that does
not have control of the user interface, then the user may not
be informed of the activity until after the activity has taken
place, when the user brings the background application to
the front. There are some circumstances in which the delay
between the occurrence of the action within the background
process, and the failure to provide feedback upon the computer system display may pose a substantial problem. For
example, data may be overwritten, the user may wish to
abort the task being performed, or he may wish to take
corrective measures to otherwise address the activity occurring in the background task. There thus has arisen a need for
background process to control the user interface which is
currently under control of an "active" or foreground process
within a computer system.
Another situation which frequently occurs is when one
application program requires a complex service such as a file
copying mechanism, but yet does not possess the necessary
code in order to perform these tasks. An active application
can use the services of the inactive application's processes
without possessing the necessary code, and the inactive
application program may drive the user interface of the
"active" application program in order to provide feedback
that the complex operation is taking place. Unfortunately,
prior art techniques have no mechanism for allowing this to
take place.

SUMMARY AND OBJECTS OF THE PRESENT
INVENTION
One of the objects of the present invention is to allow a
background application to provide user interface feedback
when it is not the currently active application program.
Another of the objects of the present invention is to
provide a protocol wherein a background application pro-

5

10

15

20

25

30

35

BRIEF DESCRIPTION OF THE DRAWINGS
40

45

50

55

60

65

The present invention is illustrated by way of example
and not limitation in the figures of the accompanying in
which like references indicate like elements and in which:
FIG. 1 shows an example of a computer system architecture upon which one embodiment of the present invention
may be implemented.
FIG. 2 shows a situation in which a file system manipulation may be performed when the filed management task is
not the "active" application program (the program controlling the user interface).
FIG. 3 shows an event-driven architecture which is used
in one embodiment of the present invention for allowing a
background task to control a user interface of a foreground
application program.
FIG. 4 shows an example of user interface display which
may be controlled directly by a foreground application
program or "server" process, but which may be directed by
and whose functionality may be provided for by a background process (or "client").
FIGS. 5a-5c show process flow diagrams of an event
handler which is registered for use by a server application
program to service events generated by a client application
program for user interface control.
DETAILED DESCRIPTION
The present invention relates to a messaging protocol
between processes and a computer system wherein a first

5,969,705

3

4

process (e.g., a client process) sends messages to a second
process (e.g., a server process) so that the client process can
direct the appearance of the user interface under control of
the server process. In this manner, the client process performs certain functions, and the server process controls all
user interface functions such as the display of feedback for
those functions. For the remainder of this application, various process steps, apparatus, data structures, message
formats, events, parameters, and other information will be
discussed in detail, however, these are merely for illustrative
purposes and are not intended to limit the present invention.
It can be appreciated by one skilled in the art that many
departures and modifications may be made from these
specific embodiments without departing from the overall
spirit and scope of the present invention.
Referring to FIG. 1, a system upon which one embodiment of the present invention is implemented is shown as
100. 100 comprises a bus or other communication means
101 for communicating information, and a processing means
102 coupled with bus 101 for processing information. System 100 further comprises a random access memory (RAM)
or other volatile storage device 104 (referred to as main
memory), coupled to bus 101 for storing information and
instructions to be executed by processor 102. Main memory
104 also may be used for storing temporary variables or
other intermediate information during execution of instructions by processor 102. Computer system 100 also comprises a read only memory (ROM) and/or other static storage
device 106 coupled to bus 101 for storing static information
and instructions for processor 102, and a data storage device
107 such as a magnetic disk or optical disk and its corresponding disk drive. Data storage device 107 is coupled to
bus 101 for storing information and instructions. Computer
system 100 may further be coupled to a display device 121,
such as a cathode ray tube (CRT) or liquid crystal display
(LCD) coupled to bus 101 for displaying information to a
computer user. An alphanumeric input device 122, including
alphanumeric and other keys, may also be coupled to bus
101 for communicating information and command selections to processor 102. An additional user input device is
cursor control 123, such as a mouse, a trackball, stylus, or
cursor direction keys, coupled to bus 101 for communicating
direction information and command selections to processor
102, and for controlling cursor movement on display 121.
Another device which may be coupled to bus 101 is hard
copy device 124 which may be used for printing
instructions, data, or other information on a medium such as
paper, film, or similar types of media. Note, also, that any or
all of the components of system 100 and associated hardware may be used in various embodiments, however, it can
be appreciated that any configuration of the system may be
used for various purposes as the user requires.
In one embodiment, system 100 is one of the Macintosh®
family of personal computers such as the Macintosh®
Quadra™ or Macintosh® Performa™ brand personal computers manufactured by Apple® Computer, Inc. of
Cupertino, Calif. (Apple, Macintosh, Quadra, and Performa
are trademarks ofApple Computer, Inc.). Processor 102 may
be one of the 68000 family of microprocessors, such as the
68030 or 68040 manufactured by Motorola, Inc. of
Schaumburg, Ill.
Note that the following discussion of various embodiments discussed herein will refer specifically to a series of
routines which are generated in a high-level programming
language (e.g., the C++ language available from Symantec
of Cupertino, Calif.) and compiled, linked, and then run as
object code in system 100 during run time. It can be

appreciated by one skilled in the art, however, that the
following methods and apparatus may be implemented in
special purpose hardware devices, such as discrete logic
devices, large scale integrated circuits (LSI's), applicationspecific integrated circuits (ASIC's), or other specialized
hardware. The description here has equal application to
apparatus having similar function.

5

10

15

20

25

30

35

40

45

50

55

60

65

Graphical User Interface
Before discussing the preferred embodiment in detail, a
brief overview of the user interface used in this system is
required. A "windowing" or graphical user interface (GUI)
operating environment is used wherein selections are performed using a cursor control device such as 123 shown in
FIG. 1. Typically, an item is "selected" on a computer
system display such as 121 using cursor control device 123
by positioning a cursor, or other indicator, on the screen over
(or in proximity to) an object on the screen and by depressing a "selection" button which is typically mounted on or
near the cursor control device. The object on the screen is
often an icon which has an associated file or operation which
the user desires to use in some manner. In order to launch a
user application program, in some circumstances, the user
merely selects an area on a computer display represented as
an icon by "double clicking" the area on the screen. A
"double click" selection is an operation comprising, while
positioning the cursor over the desired object (e.g., an icon),
two rapid activations of the selection device by the user.
"Pull-down" or "pop-up" menus are also used in the preferred embodiment. A pull-down or pop-up menu is a
selection which is accessible by depressing the selection
button when the cursor is pointing at a location on a screen
such as a menu bar (typically at the top of the display), and
"dragging" (moving cursor control device 123 while the
selection button is depressed) until the selection the user
wishes to access is reached on the pull-down menu. An item
is indicated as being "selected" on a pull-down menu when
the item is highlighted or displayed in "reverse video"
(white text on a black background). The selection is performed by the user releasing the selection device when the
selection he wishes to make is highlighted. Also, in some
GUI's, as is described in the background above, the "selection" and "dragging" of items is provided to move files about
in the file system or perform other system functions. These
techniques include "dragging and dropping" which comprises making a "selection" of an icon at a first location,
"dragging" that item across the display to a second location,
and "dropping" (e.g., releasing the selection device) the item
at the second location. This may cause the movement of a
file to a subdirectory represented by the second location.
Note also that GUI's may incorporate other selection
devices, such as a stylus or "pen" which may be interactive
with a display. Thus, a user may "select" regions (e.g., an
icon) of the GUI on the display by touching the stylus
against the display. In this instance, such displays may be
touch or light-sensitive to detect where and when the selection occurs. Such devices may thus detect screen position
and the selection as a single operation instead of the "point
(i.e., position) and click (e.g., depress button)," as in a
system incorporating a mouse or trackball. Such a system
may also lack a keyboard such as 122 wherein the input of
text is provided via the stylus as a writing instrument (like
a pen) and the user handwritten text is interpreted using
handwriting recognition techniques. These types of systems
may also benefit from the improved manipulation and user
feedback described herein.
One problem solved by the present invention is illustrated
with reference to FIG. 2. Window 200 of FIG. 2 illustrates

5,969,705

5

6

a typical Macintosh user interface display while one application program, such as an electronic mail program, controls
the user interface display. This is illustrated by the icon
present in the upper right-hand portion 212 of the display
200. The operating system only allows a single application
program to control the user interface at any given time.
However, other application programs such as, those performing file and/or program management functions (e.g., the
"Finder" within the Macintosh brand operating system),
allow the launching of applications, programs, and the
movement of files within the file system. In one embodiment
of the present invention, a user may decide to "enclose" a file
represented by icon 221 in the file system with the mail
message represented on window 230. The application program controlling window 230 does not possess file transfer
or file transfer feedback capabilities, whereas the File System Manager (known as the "Finder" in the Macintosh) does
possess these capabilities. Therefore, it is desired that the
application program controlling window 230 have certain
functions and user interface capabilities of the Finder. In a
typical prior art systems, feedback is provided by the file
management function to show that the file movement or
copy operation is taking place. This typically takes the form
of a progress bar on a typical prior art user interface to show
the progression of the file transfer operation as it takes place
in the file system. For example, if a plurality of files are
moved in the file system, or copied from one media device
to another, file names showing each transfer of each file, and
a darkened representation is shown in the progress bar to
show overall completion of the copying of the files is
represented on the progress bar. This will be illustrated in
more detail below.

Event Manager available from Apple Computer of
Cupertino, Calif.
Interprocess communication is an important aspect of
modern computer system design. For example, such interapplication communication has provided in modern computer systems, such as the Macintosh brand computer's
operating System 7.0, available from Apple Computer of
Cupertino Calif., through a mechanism known as the Event
Manager. The Event Manager and the Apple Event Manager
are used for handling a wide variety of functions within
application programs such as detecting user actions-key
clicks, selections using a cursor control device, the detection
of the insertion of disks into a disk drive on the computer
system, opening files, closing files, or other actions within
the computer system. Typically, processes running within a
Macintosh brand computer system comprise a main program
loop known as an "event" loop which detect the occurrence
of these events in the system. Then, the application typically
branches to portions of the program to allow the event to be
serviced. Such an event driven architecture forms the core of
many application programs within many different types of
computers and operating systems in present use but, in this
embodiment, resides in a system such as 100 described
above.
Various embodiments of the present invention use the
Event Manager and the Apple Event Manager supplied by
Apple Computer for interprocess communication between
applications programs which are operative within computer
system 100 during run time to implement the features
described herein. The event driven architecture for message
passing between a first application program (e.g., a client
application program which is operative in the background),
and a second application program (e.g., a server application
program which is the active application controlling the user
interface), is illustrated with reference to FIG. 3. For
example, using the event driven architecture specified in
Inside Macintosh, Volume 6, pages 5-1 through 6-118,
"client" application program 310 communicates with the
Graphical User Interface (GUI) "server" application program or active application program 330 via events 320. Each
of these events are generated by the client application
program 310 and are detected by the Apple Event Manager.
GUI server application 330 registers a process with the
Apple Event Manager known as an Event Handler so that
whenever defined events are detected, the Apple Event
Manager forwards the event(s) to the registered handler(s)
and cause the handler(s) to be invoked and service the
events. At that point, the handler may determine the appropriate action to take place. In various embodiments of the
present invention described herein, the registered event
handler for GUI server 330 will cause the activation and
modification of a user interface display, in this case, copy
window 340 illustrated in FIG. 3. Upon the launching of the
GUI server application program 330, or any application
program which may become an active application program
during specified user actions (e.g., the copying of file(s), the
server application program will register with the Apple
Event Manager the handler(s) which are used to service the
events, including those generated by any potential client
application programs (e.g., 310 of FIG. 3). In the situation
where a defined event is not serviced by any handler which
are registered by the application program, then, a default
handler supplied by the operating system is instead used for
servicing the events.
For the remainder of this application, in the embodiment
discussed herein, it will be assumed that the "server" (e.g.,
330 of FIG. 3) has registered a handler which will service

5

10

15

20

25

30

Event-Driven Architecture

An operation such as copying or moving files from one
location to another in the file system is a nontrivial task. In
this embodiment, the application program controlling the
user interface defers to the background task the "Finder" so
that it may perform the file management functions for
transfer and/or copy of the file(s). For example, several tasks
need to be performed by the copy/movement process prior
to copying or moving the files. For example, the destination
subdirectory or other file location needs to be scanned to
determine whether any of the transferred file names are
equivalent to those already in the subdirectory. If so, the user
needs to be alerted in order to determine whether he wishes
to overwrite the existing files at that location or, perhaps, use
a different name. In another instance, there may not be
sufficient space at the destination to which the files are being
moved for writing the files. In this instance, the user is
alerted that there was not sufficient space on the storage
medium to store the files, is informed that the operation was
not successful, and any file(s) already written or other
intermediate file information can be deleted. However, in a
situation such as that illustrated in FIG. 2, the underlying file
management process cannot present this user feedback or
alert information to the user because it does not presently
have control of the user interface. The process having
control of window 230, an electronic mail application
program, is currently in control of the user interface. Thus,
an improved means for allowing the background process
(e.g., the Finder) to control the user interface is used in
various embodiments of this invention to present feedback
to the user regarding the underlying functions that are taking
place. This is performed via interprocess communication, in
the Macintosh brand operating system, using Events and the
accompanying operating system Event Manager and Apple

35

40

45

50

55

60

65

5,969,705
7
user interface events. It will also be assumed that a client
program (e.g., 310 of FIG. 3) provides the underlying
functionality for performing the actions represented by the
user interface (e.g., copying files), which occurs upon the
inactive program detecting that a file should be copied (or
moved) from one directory to another, such as a directory for
"Enclosures" within an electronic mail application program.
This function may also be requested by server process 330
sending an event to a handler registered for client process
310, such as "CopyFile" 'File l' to 'Enclosures.'" The
mechanics of this operation, however, will not be described
in detail because they are beyond the scope of the present
invention.

8

430 of the copy window 400 upon detection of the NewCopyWindow event.
objectName is used for specifying the string which will
appear at region 440 on copy window 400. It is used for
5 specifying the name of the object or file being copied.
Feedback can thus provide to the user which object is
currently in the process of being read, written, or verified.
statusString 410 is used to specify the intermediate status of
the copy operation taking place. For example, in certain
10 prior art systems, this string may read "Preparing to Copy,"
"Items Remaining," etc. The status string indicates to the
user the current status of the copy operation taking place.
countString is used for specifying the value which is shown
at region 420 of display 400, such as the number of items
Client to Server Events for Controlling the User
15 (e.g., files or bytes) which are being copied. Thus, in one
Interface
situation, this string may contain "120 bytes" when a file or
file(s) of 120 bytes in length are being copied.
The following events are defined in this new protocol for
progressvalue and progressMax are used for specifying the
communicating from client 310 to user interface server 330:
status of progress bar 450. For example, the progressMax
1. NewCopyWindow;
20 parameter is used for specifying some maximum value at
2. DisposeCopyWindow;
which the progress bar will be completely darken. In an
3. ChangeString;
instance where a total of 120 bytes are being copied,
progressMax may be equal to an integer value, such as 120.
4. ChangeBar; and
The progressValue parameter will thus be used to specify an
5. PresentAlert.
As client application program 310's file copy operations 25 intermediate value from some initial value (in one
embodiment, the integer 0) to the progressMax value. Thus,
progress, certain of these events are issued by client process
on the display, progress bar 450 may be filled with a
310 to server process 330. Moreover, communication is
darkened region 451 up to an intermediate position 452
provided via another set of events from server 330 to client
based upon the fraction progressValue/progressMax. For
310 to indicate the success of the action indicated by the
events, and user interface feedback in response to informa- 30 example, if progressValue equals 60 and progressMax
equals 120, then progress bar 450 will have a representation
tion presented on the user interface by server 330. Adescripsuch as that shown in FIG. 4 wherein 6°1120 or Y2 of the
tion of each of the specific events and the parameters used
progress bar has been darkened. Feedback is thus provided
in each of these events will now be discussed with reference
to the user to illustrate the current completion of the copy
to FIG. 4.
400 of FIG. 4 illustrates a typical copy window which is 35 operation. In typical situations, the progressvalue will have
an initial value such as 0, and the progressMax value will be
displayed during a file copying operation well known in the
some nonzero value, for example, equivalent to an integer
prior art. However, each of the informative portions of the
representing the maximum number of bytes to be copied.
window are displayed with corresponding parameter name
DisposeCopyWindow
for the event in angled brackets (e.g., <status string> 410,
The DisposeCopyWindow event is used for indicating the
<action string> 430, <count string> 420, and <object name> 40
termination of a copy operation. This event causes the
440 ), which is replaced by the strings specified within
server's handler to remove window 400 from the display
parameters associated with the event(s) issued by client
using well known prior art interface techniques. The event
process 310. The events and parameters associated with the
has no parameters because it merely removes from the
events will now be discussed.
45 display the currently displayed progress bar window.
NewCopyWindow
ChangeString
The NewCopyWindow event is signaled by client appliThe ChangeString event has the following parameters:
cation program 310 to indicate that a new copy window
(e.g., 400 in FIG. 4) should be displayed. Using typical prior
art user interface commands, the server application prostringNumber
gram's handler creates upon the display screen a copy 50
statusString ~ 0
window 400 as is illustrated in FIG. 4 with the appropriate
countString ~ 1
actionString ~ 2
strings specified in the event parameters. Each of the event
objectNameString ~ 3
parameters for the NewCopyWindow are specified in the
stringValue
following order:
55
1. actionString (e.g., "reading"I"writing"I"verifying")
stringNumber-For each of the above specified values of
2. objectName (name of object being copied)
stringNumber, the identified string modified in copy window
3. statusString (e.g., "Preparing To Copy," "Items
400 using the ChangeString event according to the string
remaining," etc.)
contained in stringValue. statusString 410, countString 420,
4. countString (how many items are being copied)
60 actionString 430, or objectNameString 440 may be modified
5. progressValue (an initial value, usually 0)
within, copy window 400 illustrated in FIG. 4. The client
application may thus cause updates to be performed within
6. progressMax (a maximum value)
copy window 400 so that the user is informed of the current
actionString is used for specifying the operation being
performed. In typical prior art copy operations, the value
status of the copy operation (such as a current file being
thus is one of the following three strings: "Reading"; "Writ- 65 copied)
stringValue is a string which will replace the string specified
ing"; or "Verifying", for specifying the operation being
performed. The specified action string is placed into region
by the integer value contained in stringNumber.

5,969,705

9

10

ChangeBar
The ChangeBar event has the following parameters:
progressValue (a current value)
progressMax (a maximum value) Each of these parameters are integer values specifying the current progression and the maximum progression of progress bar 450
of copy window 400, is discussed with reference to the
NewCopyWindow event above. The progress bar is
thus adjusted to have a filled in representation, such as
that shown as 451 according to the fraction
progressValue/progressMax. The progress bar is update
by the server's handler using standard prior art user
interface commands.
PresentAlert
The following parameters are defined for the PresentAlert
event:

servlcmg events issued by server 330 to client 310. For
example, if the user wishes to "cancel" an operation, an
event entitled "CopyCancel" may be issued to the client
process 310 in one embodiment of the present invention so
that any ongoing operation(s) may be aborted. This is
detected by a user selecting "Stop" button 460 at any time
during the operation. The cancel operation may be detected
by server 330 by the detection of a "mouseDown" event at
a specific location, such as "Stop" button 460, or its keyboard equivalent (e.g., a command period combination in
the Macintosh). In this case, client application 310's handler
may be alerted that an abort was indicated and take appropriate action.
In another embodiment, responses to alerts such as file
overwrite messages may be sent from server 330 to client
310. In this instance, an integer may be passed as a parameter wherein one value of the integer (e.g., 0) causes the
operation to be aborted or a second value (e.g., 1) causes the
file overwrite to be confirmed. Responses to alerts are
performed using other defined events from GUI server 330
to client 310. The user may be presented with the option of
either confirming replacement of the file or canceling the
copy operation. In one embodiment, when an alert is
presented, client 310 remains idle until a response is made
by a user on the user interface display. Then a corresponding
response event (e.g., AlertReply) with a response parameter
(e.g., an integer value Result containing an integer 0 indicating confirmation of the operation or integer 1 indicating
canceling of the operation) is generated by server 330 to
client 310 to either confirm or cancel the operation being
performed by client 310.
Other user responses to queries, such as alerts, errors, or
other conditions, may also be responded to in this manner,
as detected by GUI server 330 and sent to client 310 via a
registered handler.

alertType
GenericAlert ~ 0
NoteAlert ~ 1
Confirm/Cancel ~ 2
Continue/Cancel ~ 3
CancelDefaultConfirm
SaveChanges ~ 5
alertString

5

10

15

20

~

4

25

alertType is an integer value which is used for specifying the
type of alert displayed which is displayed to the user. Note
that these alerts are all similar to those which are displayed
in typical prior art copy operations upon detection of certain
conditions, abnormal or otherwise. Some of these specified
alerts require that the user respond. For example, the
Confirm/Cancel alert displays a window which requests that
the user "confirm" or "cancel" an ongoing operation. For
example, the Confirm/Cancel alert may be used when the
same file name is detected at a destination directory for a file
which is being copied. Any of the standard alert windows
which may be used in certain prior art copy operations may
be specified using the proper alertType integer value. User
responses to alerts will be provided with events from user
interface server 330 to client 310 via another set of events
discussed below.
alertString is a string value indicating the associated message to be associated with the alert. For example, the client
application program may determine that a file name having
an equivalent file name to a file being copied already resides
at the destination application. In this event, the alertString
may contain a message such as "File 'My File' already
exists. Replace?" In any event, using the foregoing alert
parameters, the PresentAlert event may specify appropriate
alerts to the user.

30

35

Event Handling by Server Application Program
40

45

50

Server to Client Events
All of the above events are shown for illustrative purposes
only and are for the client application process 310 (e.g., the
"Finder" performing the copy operation) alerting server
process 330 (e.g., an electronic mail application program) to
change the user interface display in a specified manner.
However, other events may also be defined to specify other
changes to the user interface display and for other
operations, especially in instances where user interface
response(s) to alerts are required. Because the background
process (e.g., client process 310 ) cannot detect user interface actions (such as selections on the display), the handler
for server process 330 must detect these actions and transmit
response event messages to client process 310. In this case,
client 310 will have its own event handler registered for

55

60

65

FIGS. 5a-5g show a process flow diagram of a typical
event handler which may be registered by server application
program 330 and service events generated by a background
process for controlling the user interface using the messaging protocol of one embodiment of the present invention.
For example, such an event handler may be registered using
the Apple Event Manager described in Inside Macintosh,
Volume VI, Chapter 6, wherein all of the above-described
events are handled by this single handler 500. Handler 500
will typically have a process entry point, such as 501
illustrated in FIG. 5a, and comprise an IF or CASE programming statement in a typical high level programming
language or other condition checking loop, which is illustrated in the remainder of the figures. Then, each of the
events may be checked for, and upon detection of a specific
event, the user interface display specified by the event and
associated parameters may be displayed upon system display 121. For example, it will be determined at step 502
whether a NewCopyWindow event has been detected. If so,
then a new copy window (e.g., 400) is displayed at step 503
with the specified parameters, such as statusString 410,
countString 420, actionString 430, objectName 440 , and
having the progress bar 450 with an appropriate representation as defined by the progressValue/progressMax parameters passed within the event. Upon display of the new copy
window 400 at step 503, process 500 continues and returns
at step 517.
If, however, a NewCopyWindow event was not detected
at step 502, and a window is not currently displayed as

5,969,705
11

12

detected at step 504, then an error condition may be indistep 539. Finally, the SaveChanges parameter is tested for
cated at step 505, such as by issuing an event from server
(alertType=5) at step 540 and then displayed at step 541. If
330 to client 310 to specify an error (e.g.,
any other alertType value is detected, an error is indicated at
"EventNotHandled") to specify that the event was not
step 543, and the process returns at step 517 of FIG. 5a.
serviced. Then, event handler 500 may exit at step 517. If, 5 Otherwise, upon completion of detection of any of the above
however, a window has already been displayed, then the
alertType values, then the option previously displayed is
condition for the various remaining events defined in the
saved for use when the next event is detected in the event
messaging protocol may be checked for using a suitable
handler at step 542, and process 500 returns at step 517 of
programming construct such as a CASE statement or other
FIG.5b.
similar condition-checking statement(s). For example, it is 10
At any rate, upon detection of the all the previous events,
determined at step 506 whether the DisposeCopyWindow
if the events are serviced, then an event message from server
event has been detected. If so, then the copy window
330 to client 310 such as EventHandled is issued, and
displayed upon computer system display 121 is eliminated at
handler 500 returns at step 517. Otherwise, any events
step 507 using well-known prior art user interface
detected which do not fall into one of the categories tested
operations, and handler 500 returns at step 517.
15 for or other events which are not serviced may issue a
suitable error event message, such as EventNotHandled at
Upon the detection of a ChangeString event, as detected
step 517 to indicate to client 310 that the event was not
at step 508, then process 500 proceeds to a more detailed
serviced. Then, the client may take appropriate actions via
sequence of steps to determine the value passed within the
its own event handler.
string number, as reflected on Figure 5b. As is illustrated in
FIG. 5b, it is determined using a condition checking loop, 20
Thus, an invention for a background application controlling the user interface of a foreground application has been
such as a CASE statement or other programming construct,
what the value of stringNumber is. For example, at step 520,
described. Although the present invention has been
it is determined whether stringNumber indicates that the
described particularly with reference to specific embodistatusString should be modified. If so, then statusString 410
ments as illustrated in FIGS. 1-5c, it may be appreciated by
on display 400 is updated at step 521, and the handler returns 25 one skilled in the art that many departures and modifications
at step 517. If, however, the countString is specified at step
may be made by one of ordinary skill in the art without
departing from the general spirit and scope of the present
522 (when stringNumber=l), then the count string (e.g.,
420) is updated at step 523, and the handler returns at step
invention.
517. If, however, the actionString should be modified
What is claimed is:
(stringNumber=2), as detected at step 524, then it is updated 30
1. In a computer system comprising a processor, a display,
a memory, a user input device, a first process operative in the
on the copy window. If, however, stringNumber=3 indicatcomputer system, a second process operative in the coming that objectNameString 440 is sought to be updated, as
puter system as a foreground process and a user interface on
detected at step 526, then objectNameString 440 is updated
said computer system display under the control of the
at step 527, and handler 500 returns at step 517 of FIG 5a
. Any other string number results in an error being generated 35 second process, a method for the first process to perform
at step 528, and a return from the handler at step 517 with
operations for the second process and control a content of
an appropriate error event message to client 310, such as
the user interface on said computer system display, said
"EventNotHandled," indicating that the handler did not
content under control of the foreground second process
operative in said computer system, said first process conservice the event.
Process 500 of FIG. 5a proceeds to step 509 if a Chang- 40 trolling the content to display information regarding the
operations performed by the first process for the second
eString event was not detected. Step 509 determines whether
process, said method comprising the following steps:
the ChangeBar event has been detected. If so, then handler
a. installing an event handling process as part of said
500 proceeds to step 510 which updates progress bar 450
second process, said event handling process when said
using the progressvalue and progressMax parameters passed
second process is operative in said computer system,
in the event. If the value(s) passed are invalid, an error may 45
servicing events generated by the first process for
be indicated via a response event and the update to the
controlling said user interface display under control of
progress bar abort.
said second process;
If, however, the ChangeBar event is not detected at step
b. said second process initiating said first process to
509, then the handler proceeds to determine whether a 50
perform operations for said second process, said second
PresentAlert event has been detected at step 511. Various
process operative in the foreground and said first protypes of alerts can then be checked for, as illustrated in FIG
cess operative in the background;
5c, by checking the alertType parameter. For example, each
d. said first process generating events for controlling said
of the steps illustrated at steps 530-540 on FIG. 5c may be
user interface display while the second process remains
conformed using a typical high-level programming con- 55
as a foreground process and the first process is a
struct such as a CASE statement. Then, upon detection of the
background process, said events providing information
corresponding value in the alertType parameter, the associregarding the operations performed by said first process
ated alert is displayed. For instance, for alertType=O, as
for the second process; and
detected at step 530, the generic alert is tested for and then
e. said event handling process receiving events generated
displayed at step 531. At step 532, the NoteAlert is tested for 60
by said first process, said event handling process updat(with alertType=l) and displayed at step 533. At step 534,
ing said user interface on said computer system display
the Confirm/Cancel alert is tested for (with the alertType=2),
according to said events generated by said first process,
and it is displayed if detected at step 535. At step 536, if the
Continue/Cancel alert type is detected (alertType=3), then
while said first process remains in the background, and
the Confirm/Cancel option window is displayed at step 537. 65
received by said event handling process.
At step 538, the CancelDef aultConfirm option is tested for
(alertType=4), and the corresponding option is displayed at
* * * * *