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 K

111111111111111111111111111111111111111111111111111111111111111111111111111
US005915131A

United States Patent

[19]

[11]

Knight et al.
[54]

[45]

5,553,245
5,572,675

METHOD AND APPARATUS FOR
HANDLING I/O REQUESTS UTILIZING
SEPARATE PROGRAMMING INTERFACES
TO ACCESS SEPARATE I/O SERVICES

[73]

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

[21]

Appl. No.: 08/435,677

[22]

Filed:

May 5, 1995
6

Int. C1.
U.S. Cl.

G06F 9/40; G06F 13/14
395/892; 395/682; 395/828;
395/702; 707/104; 345/333
Field of Search
395/828, 702,
395/834, 200.2, 892, 682, 309; 345/333;
707/104

[56]

References Cited

6/1986
2/1988
3/1990
1/1991
7/1992
9/1992
3/1993
7/1995
2/1996
4/1996
7/1996
7/1996

Castel et al.
Nichols
Bennett et al.
Tignor et al.
Coyle, Jr. et al.
Basso et al.
Lary et al.
Rimmer et al.
Bondy et al.
Cook et al.
Feeney et al.
Taylor et al.

l

364/200
370/85
380/10
364/200
395/650
395/325
395/425
395/275
395/500
395/800
395/834
379/201

[57]

BLOCK
STORAGE
API

A computer system handling multiple applications wherein
groups of I/O services are accessible through separate application programming interfaces. Each application has multiple application programming interfaces by which to access
different families of I/O services, such as I/O devices.
20 Claims, 8 Drawing Sheets

f--

SCSI
MANAGER
API

io3

io2

J

204 USER MODE WORLD
KERNEL WORLD

11

2?5

~6

FILE
MANAGER
FPISERVER

2 08

BLOCK
STORAGE
FPISERVER

FILE
MANAGER
FAMILY
~
HFS
FILE
SYSTEM

BLOCK
STORAGE

~L-

395/284
395/200.2

ABSTRACT

APPLICATION 201
FILE
f-MANAGER
API

9/1996 Su et al.
11/1996 Bergler

Primary Examiner-Thomas C. Lee
Assistant Examiner-Rehana Perveen
Attorney, Agent, or Firm-Blakely, Sokoloff, Taylor &
Zafman

U.S. PATENT DOCUMENTS
4,593,352
4,727,537
4,908,859
4,982,325
5,129,086
5,148,527
5,197,143
5,430,845
5,491,813
5,513,365
5,535,416
5,537,466

Jun. 22, 1999

Forin, A., et al. entitled "An I/O System for Mach 3.0,"
Proceedings of the Usenix Mach Symposium 20-22, Nov.
1991, Monterey, CA, US, 20-22 Nov. 1991, pp. 163-176.
Steve Lemon and Kennan Rossi, entitled "An Object Oriented Device Driver Model," Digest of Papers Compcon
'95, Technologies for the Information Superhighway 5-9,
Mar. 1995, San Francisco, CA, USA pp. 360-366.
Glenn Andert, entitled "Object Frameworks in the Taligent
OS," Intellectual Leverage: Digest of Papers of the Spring
Computer SOCI International Conference (Compcon), San
Francisco, Feb. 28-Mar. 4, 1994, Feb. 24, 1994, Institute of
Electrical and Electronics Engineers, pp. 112-121.
Hu, 'Interconnecting electronic mail networks: Gateways
and translation strategies are proposed for backbone networks to interchange incompatible electronic documents on
multivendor networks', Data Communications, p. 128, vol.
17, No. 10, Sep. 1988.
Knibbe, 'IETF's Resource Reservation Protocol to facilitate
mixed voice, data, and video nets', Network World, p. 51,
Apr. 24, 1995.

Inventors: Holly N. Knight, La Honda; Carl D.
Sutton, Palo Alto; Wayne N.
Meretsky, Los Altos; Alan B. Mimms,
San Jose, all of Calif.

[58]

5,915,131

OTHER PUBLICATIONS

[75]

[51]
[52]

Patent Number:
Date of Patent:

~
DISK
DRIVER

tl--

11

207

SCSI
MANAGER
FPISERVER
SCSI
MANAGER
FAMILY
~
SIM

109

121

DISPLAY

HARD COPY
DEVICE
124

LAN

108

MODEM

107

MASS
STORAGE

'\r--

,A--

-

/'--

~

r

lr--1-

~

SOUND
CHIP 125

/

1/0 BUS
101

FLOPPY DISK
DRIVE 126

)

)

I--

/

181

~

)

n
FIG. 1

TEMP.
SENSOR

CURSOR
CONTROL 123

J

I

I

CLK

t

LOCAL
B~100

I

DECODER
154

1~7A

184 TO
CLOCK
GENERATOR
160

~

MICROCONTROLLER
127

BUS
TRANSLATOR!
INTERFACE
UNIT
140

~

SIGNAL 182

POW~ r-...

KEYBOARD
122

1/0
CONTROLLER
130

TIMER 150

~

CLK ,

I

VDD
SWITCH
153

COMPONENTS

TO OTHER

HOT INDICATION )
SIGNAL 183

POWER
SUPPLY 1521]

"'-

160

CLOCK
GENERATOR

..

FROM I '0
INTERFJ E
140

NON-VOLATILE
MEMORY
106

MAIN
MEMORY
104

PROCESSOR
103
V DD '.4-

d

=

=-

~

~

~

Ul
....

~

\C

Ul
....

QIO

'"
o"'"
....,

....

~
~

'JJ.

'""'"
'0
'0
'0

~N

N

?

~

=

~

~
.....
.....

~

•
'JJ.
•

u.s. Patent

5,915,131

Sheet 2 of 8

Jun. 22, 1999

APPLICATION 201
FILE
MANAGER
API

L-

BLOCK
I-I-SCSI
STORAGE
MANAGER
API
API I
'.
203
204 USER MODE WORLD

I--

""

io2

KERNEL WORLD

!1

2?5
FILE
MANAGER
FPISERVER

BLOCK
STORAGE
FPISERVER

FILE
MANAGER
FAMILY

BLOCK
STORAGE
FAMILY

~

~

208
L-

HFS
FILE
SYSTEM

{

I-

L-

!7

2»6

DISK
DRIVER

l
FIG. 2

I-

297

SCSI
MANAGER
FPISERVER
SCSI
MANAGER
FAMILY

~

'-

SIM

I-

u.s. Patent

Jun. 22, 1999

Sheet 3 of 8

5,915,131

APPLICATION 302

P_R_O_C_E_D_U_R_Er-C_A_L_L......l:~ _~
_

__

IFPI~~:ARYI

~~~~~AMMING

~~~ERFACE

KERNEL MESSAGE

USER MODE WORLD

KERNEL MESSAGE

KERNEL WORLD

FPISERVER
304
PROCEDURE CALL

-lor

FAMILY:
305
PROCEDURE CALL

PLUG-IN
_______________ PROGRAMMING
INTERFACE
PLUG-IN
306
307

FIG. 3

u.s. Patent

Xlib u

Jun. 22, 1999

5,915,131

Sheet 4 of 8

~

~4

~5

Zlib u

USER MODE WORLD

~)
X
FPI
SERVER

401

......

Y
FPI
SERVER

408

KERNEL WORLD

409

X 411

Y 412

r------>o~1"'--___,1-.,
Z
FPI
SERVER
410

Z 413

X FAMILY
IMPLEMENTATION

Z FAMILY
IMPLEMENTATION

414
~

416

~
Z

X
'- PLUG IN -

'- PLUG IN - ../

417

419

FIG.4

403

u.s. Patent

Sheet 5 of 8

Jun. 22, 1999

5,915,131

Dlib u
503
USER MODE WORLD
KERNEL WORLD

Z
FPI
SERVER

z
Z FAMILY
IMPLEMENTATION

~
Z

.

502

/

r---~---.

D FPI

J...-=';-

SERVER

D
505

'- PLUG IN "-...I-_----Ir
~
501
;:===~=======::::=.J

FIG. 5

504

u.s. Patent

Jun. 22, 1999

5,915,131

Sheet 6 of 8

FAMILY

FAMILY

A

B
SHARED CODE
AND/OR DATA

601

602

FIG. 6

u.s. Patent

Jun. 22, 1999

Sheet 7 of 8

5,915,131

APPLICATION 710

~

711

APls

IV
USER MODE WORLD
KERNEL WORLD

7~

v

~ FPI SERVER

7~

>

ACCEPT
FUNCTION

STREAMS
~
WORLD

IPROTOCOL I
IPROTOCOL I
IPROTOCOL I
?

~

NETWORK
DEVICE ~,./
DRIVER

FIG. 7

> SINGLE

TASK

u.s. Patent

Jun. 22, 1999

Sheet 8 of 8

5,915,131

APPLICATION a01

~
API

a02

P

--~-

USER MODE WORLD
KERNEL WORLD
803

FPISERVER
FAMILY
804
WRAPPER
TASK

FIG. 8

5,915,131
1

2

METHOD AND APPARATUS FOR
HANDLING I/O REQUESTS UTILIZING
SEPARATE PROGRAMMING INTERFACES
TO ACCESS SEPARATE I/O SERVICES

FIG. 1 a block diagram of one embodiment in the computer system of the present invention.
FIG. 2 is an overview of the I/O architecture of the present
invention.
FIG. 3 illustrates a flow diagram of I/O service request
handling according to the teachings of the present invention.
FIG. 4 illustrates an overview of the I/O architecture of
the present invention having selected families accessing
other families.
FIG. 5 illustrates extended programming family interface
of the present invention.
FIG. 6 illustrates plug-in modules of different families
that share code and/or data.
FIG. 7 illustrates a single task activation model according
to the teachings of the present invention.
FIG. 8 illustrates a task-per-plug-in model used as an
activation model according to the teachings of the present
invention.

5

FIELD OF THE INVENTION
The invention relates to the field of computer systems;
particularly, the present invention relates to handling service
requests generated by application programs.

10

BACKGROUND OF THE INVENTION
Application programs running in computer systems often
access system resources, such as input/output (I/O) devices.
These system resources are often referred to as services.
Certain sets of services (e.g., devices) have similar characteristics. For instance, all display devices or allADB devices
have similar interface requirements.
To gain access to I/O resources, applications generate
service requests to which are sent through an application
programming interface (API). The service requests are converted by the API to a common set of functions that are
forwarded to the operating system to be serviced. The
operating system then sees that service requests are
responded to by the appropriate resources (e.g., device). For
instance, the operating system may direct a request to a
device driver.
One problem in the prior art is that service requests are not
sent directly to the I/O device or resource. All service
requests from all applications are typically sent through the
same API. Because of this, all of the requests are converted
into a common set of functions. These common set of
functions do not have meaning for all the various types of
I/O devices. For instance, a high level request to play a
sound may be converted into a write function to a sound
device. However, the write function is not the best method
of communicating sound data to the sound device. Thus,
another conversion of write data to a sound data format may
be required. Also, some functions do not have a one-to-one
correspondence with the function set of some I/O devices.
Thus, it would be desirable to avoid this added complexity
and to take advantage of the similar characteristics of classes
of I/O devices when handling I/O requests, while providing
services and an environment in which to run those services
that is tuned to the specific device needs and requirements.

15

20

DETAILED DESCRIPTION OF THE PRESENT
INVENTION
25

30

35

40

45

SUMMARY OF THE INVENTION
A method and apparatus for handling I/O requests is
described. In the present invention, the I/O requests are
handled by the computer system having a bus and a memory
coupled to the bus that stores data and programming instructions. The programming instructions include application
programs and an operating system. A processing unit is
coupled to the bus and runs the operating system and
application programs by executing programming instructions. Each application programs have multiple separate
programming interfaces available to access multiple sets of
I/O services provided through the operating system via
service requests.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be understood more fully from
the detailed description given below and from the accompanying drawings of various embodiments of the invention,
which, however, should not be taken to limit the invention
to the specific embodiments, but are for explanation and
understanding only.

50

55

60

65

A method and apparatus handling service requests is
described. In the following detailed description of the
present invention numerous specific details are set forth in
order to provide a thorough understanding of the present
invention. However, it will be apparent to one skilled in the
art that the present invention may be practiced without these
specific details. In other instances, well-known structures
and devices are shown in block diagram form, rather than in
detail, in order to avoid obscuring the present invention.
Some portions of the detailed descriptions which follow
are presented in terms of algorithms and symbolic representations of operations on data bits within a computer
memory. These algorithmic descriptions and representations
are the means used by those skilled in the data processing
arts to most effectively convey the substance of their work
to others skilled in the art. An algorithm is here, and
generally, conceived to be a self-consistent sequence of steps
leading to a desired result. The steps are those requiring
physical manipulations of physical quantities. Usually,
though not necessarily, these quantities take the form of
electrical or magnetic signals capable of being stored,
transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for
reasons of common usage, to refer to these signals as bits,
values, elements, symbols, characters, terms, numbers, or
the like.
It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate
physical quantities and are merely convenient labels applied
to these quantities. Unless specifically stated otherwise as
apparent from the following discussions, it is appreciated
that throughout the present invention, discussions utilizing
terms such as "processing" or "computing" or "calculating"
or "determining" or "displaying" or the like, refer to the
action and processes of a computer system, or similar
electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities
within the computer system's registers and memories into
other data similarly represented as physical quantities within
the computer system memories or registers or other such
information storage, transmission or display devices.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may

5,915,131

3

4

comprise a general purpose computer selectively activated
selections to processor 103, and a cursor control 123, such
or reconfigured by a computer program stored in the comas a trackball, stylus, mouse, or trackpad, etc., for controlling cursor movement. The system also includes a sound
puter. The algorithms and displays presented herein are not
chip 125 coupled to I/O controller 130 for providing audio
inherently related to any particular computer or other apparatus. Various general purpose machines may be used with 5 recording and play back. Sound chip 125 may include a
sound circuit and its driver which are used to generate
programs in accordance with the teachings herein, or it may
various audio signals from the computer system. I/O conprove convenient to construct more specialized apparatus to
troller 130 may also provide access to a floppy disk and
perform the required method steps. The required structure
for a variety of these machines will appear from the descripdriver 126. The processor 103 controls I/O controller 130
tion below. In addition, the present invention is not 10 with its peripherals by sending commands to I/O controller
130 via local bus 100, interface unit 140 and I/O bus 101.
described with reference to any particular programming
language. It will be appreciated that a variety of programBatteries or other power supply 152 may also be included
to provide power necessary to run the various peripherals
ming languages may be used to implement the teachings of
and integrated circuits in the computer system. Power supthe invention as described herein.
Overview of the Computer System of the Present Invention 15 ply 152 is typically a DC power source that provides a
constant DC power to various units, particularly processor
Referring to FIG. 1, an overview of a computer system of
the present invention is shown in block diagram form. The
103. Various units such as processor 103, display 121, etc.,
present invention may be implemented on a general purpose
also receive clocking signals to synchronize operations
microcomputer, such as one of the members of the Apple
within the computer systems. These clocking signals may be
family of personal computers, one of the members of the 20 provided by a global clock generator or multiple clock
generators, each dedicated to a portion of the computer
IBM personal computer family, or one of several other
computer devices which are presently commercially availsystem. Such a clock generator is shown as clock generator
able. Of course, the present invention may also be imple160. In one embodiment, clock generator 160 comprise a
mented on a multi-user system while encountering all of the
phase-locked loop (PLL) that provides clocking signals to
costs, speed, and function advantages and disadvantages 25 processor 103.
I/O controller 140 includes control logic to coordinate the
available with these machines.
As illustrated in FIG. 1, the computer system of the
thermal management. Several additional devices are
present invention generally comprises a local bus or other
included within the computer system to operate with the
control logic within I/O controller 140. A timer 150, a switch
communication means 100 for communicating information,
a processor 103 coupled with local bus 100 for processing 30 153 and a decoder 154 are included to function in connection
information, a random access memory (RAM) or other
with the control logic. In one embodiment, decoder 154 is
dynamic storage device 104 (commonly referred to as a
included within bus interface unit 140 and timer 150 is
main memory) coupled with local bus 100 for storing
included in I/O controller 130.
Switch 153 is a p-channel power MOSFET, which has its
information and instructions for processor 103, and a readonly memory (ROM) or other non-volatile storage device 35 gate connected to the power signal 182, its source to the
power supply and its drain to processor's VDD pin.
106 coupled with local bus 100 for storing non-volatile
information and instructions for processor 103.
In one embodiment, processor 103 is a member of the
PowerPCTM family of processors, such as those manufacThe computer system of the present invention also
includes an input/output (I/O) bus or other communication
tured by Motorola Corporation of Schaumberg, Ill. The
means 101 for communication information in the computer 40 memory in the computer system is initialized to store the
operating system as well as other programs, such as file
system. A data storage device 107, such as a magnetic tape
directory routines and application programs, and data inputand disk drive, including its associated controller circuitry,
ted from I/O controller 130. In one embodiment, the operis coupled to I/O bus 101 for storing information and
ating system is stored in ROM 106, while RAM 104 is
instructions. A display device 121, such as a cathode ray
tube, liquid crystal display, etc., including its associated 45 utilized as the internal memory for the computer system for
accessing data and application programs. Processor 103
controller circuitry, is also coupled to I/O bus 101 for
accesses memory in the computer system via an address bus
displaying information to the computer user, as well as a
hard copy device 124, such as a plotter or printer, including
within bus 100. Commands in connection with the operation
its associated controller circuitry for providing a visual
of memory in the computer system are also sent from the
representation of the computer images. Hard copy device 50 processor to the memory using bus 100. Bus 100 also
includes a bi-directional data bus to communicate data in
124 is coupled with processor 103, main memory 104,
non-volatile memory 106 and mass storage device 107
response to the commands provided by processor 103 under
through I/O bus 101 and bus translator/interface unit 140. A
the control of the operating system running on it.
modem 108 and an ethernet local area network 109 are also
Of course, certain implementations and uses of the
coupled to I/O bus 101.
55 present invention may neither require nor include all of the
Bus interface unit 140 is coupled to local bus 100 and I/O
above components. For example, in certain implementations
a keyboard or cursor control device for inputting informabus 101 and acts as a gateway between processor 103 and
the I/O subsystem. Bus interface unit 140 may also provide
tion to the system may not be required. In other
translation between signals being sent from units on one of
implementations, it may not be required to provide a display
the buses to units on the other bus to allow local bus 100 and 60 device displaying information. Furthermore, the computer
system may include additional processing units.
I/O bus 101 to co-operate as a single bus.
The operating system running on processor 103 takes care
An I/O controller 130 is coupled to I/O bus 101 and
controls access to certain I/O peripherals in the computer
of basic tasks such as starting the system, handling
system. For instance, I/O controller 130 is coupled to
interrupts, moving data to and from memory 104 and
controller device 127 that controls access to an alpha- 65 peripheral devices via input/output interface unit 140, and
managing the memory space in memory 104. In order to take
numeric input device 122 including alpha-numeric and other
care of such operations, the operating system provides
keys, etc., for communicating information and command

5,915,131

5

6

multiple execution environments at different levels (e.g.,
request may be communicated from application level to the
file system family, resulting in one or more requests to the
task level, interrupt level, etc.). Tasks and execution enviblock storage family, and finally one or more to the SCSI
ronments are known in the art.
family to complete a service request. Note that in one
Overview of the Present Invention
In one embodiment, the computer system runs a kernel- 5 embodiment, there is no hierarchical relationship among
families; all families are peers of each other.
based, preemptive, multitasking operation system in which
Families in the Present Invention
applications and I/O services, such as drivers, operate in
A family provides a distinct set of services to the system.
separate protection domains (e.g., the user and kernel
For example, one family may provide network services,
domains, respectively). The user domain does not have
while another provides access to a variety of block storage
direct access to data of the kernel domain, while the kernel 10
mediums. A family is associated with a set of devices that
domain can access data in the user domain.
have similar characteristics, such as all display devices or all
The computer system of the present invention uses one or
ADB devices.
more separate families to provide I/O services to the system.
In one embodiment, each family is implemented in softEach I/O family provides a set of I/O services to the system.
ware that runs in the computer system with applications. A
For instance, a SCSI family and its SCSI interface modules 15 family comprises software that includes a family program(SIMs) provide SCSI based services, while a file systems
ming interface and its associated FPI library or libraries for
family and its installable file systems provide file manageits clients, an FPI server, an activation model, a family
ment services. In one embodiment, an I/O family is impleexpert, a plug-in programming interface for its plug-ins, and
mented by multiple modules and software routines.
a family services library for its plug-ins.
FIG. 3 illustrates the interaction between these compoEach family defines a family programming interface (FPI) 20
nents. Referring to FIG. 3, a family programming interface
designed to meet the particular needs of that family. An FPI
provides access to a given family's plug-ins, which are
(FPI) 301 provides access to the family's services to one or
dynamically loaded pieces of software that each provide an
more applications, such as application 302. The FPI 301 also
instance of the service provided by a family. For example,
provides access to plug-ins from other families and to
within the file systems family (File Manager), a plug-in 25 system software. That is, an FPI is designed to provide
callers with services appropriate to a particular family,
implements file-system-specific services. In one
whether those calls originate from in the user domain or the
embodiment, plug-ins are a superset of device drivers, such
operating system domain.
that all drivers are plug-ins, but not all plug-ins are drivers.
For example, when an application generates data for a
Access to services is available only through an I/O
family's programming interface. In one embodiment, hard- 30 video device, a display FPI tailored to the needs of video
ware is not directly accessible to application software, nor is
devices is used to gain access to display services. Likewise,
it vulnerable to application error. Applications have access
when an application desires to input or output sound data,
to hardware services only through an I/O family's programthe application gains access to a sound family of services
ming interface. Also, the context within which an I/O service
through an FPI. Therefore, the present invention provides
runs and the method by which it interacts with the system is 35 family programming interfaces tailored to the needs of
defined by the I/O family to which it belongs.
specific device families.
FIG. 2 illustrates the relationship between an application,
Service requests from application 302 (or other
several I/O families, and their plug-ins. Referring to FIG. 2,
applications) are made through an FPI library 303. In one
an application 201 requests services through one or more
embodiment, the FPI library 303 contains code that passes
family FPIs, shown in FIG. 2 as File Manager API 202, 40 requests for service to the family FPI server 304. In one
embodiment, the FPI library 303 maps FPI function calls
Block Storage API 203, and SCSI Manager API 204. The
File Manager API 202, Block Storage API 203, and SCSI
into messages (e.g., kernel messages) and sends them to the
FPI server 304 of the family for servicing. In one
Manager API 204 are available to one or more applications
in the user domain.
embodiment, a family 305 may provide two versions of its
In one embodiment, the service requests from application 45 FPI library 303, one that runs in the user domain and one that
201 (and other applications) are sent through File Manager
runs in the operating system kernel domain.
API 202, Block Storage API 203, and/or SCSI Manager API
In one embodiment, FPI server 304 runs in the kernel
204, etc., and flow as messages to family FPI servers
domain and responds to service requests from family clients
205-207, which reside in the kernel domain. In one
(e.g., applications, other families, etc.). FPI server 304
embodiment, the messages are delivered using a kernel- 50 responds to a request according to the activation model (not
supplied messaging service.
shown) of the family 305. In one embodiment, the activation
Any communication method may be used to communimodel comprises code that provides the runtime environcate service requests to I/O families. In one embodiment,
ment of the family and its plug-ins. For instance, FPI server
kernel messaging is used between the FPI libraries and the
304 may put a request in a queue or may call a plug-in
FPI server for a given family, between different families, and 55 directly to service the request. As shown, the FPI server 304
between plug-ins of one family and another family. The
forwards a request to the family 305 using a procedure call.
communication method used should be completely opaque
Note that if FPI library 303 and the FPI server 304 use kernel
to a client requesting a family service.
messaging to communicate, the FPI server 304 provides a
Each of the FPI servers 205-207 permit access to a
message port.
Each family 305 includes an expert (not shown) to
distinct set of services. For example, File Manager FPI 60
maintain knowledge of the set of family devices. In one
server 205 handles service for the file manager family of
services. Similarly, the Block Storage FPI server 206
embodiment, the expert comprises code within a family 305
handles service requests for the block storage family of
that maintains knowledge of the set of family plug-ins
serVIces.
within the system. At system startup and each time a change
Note that FIG. 2 shows three families linked by kernel 65 occurs, the expert is notified.
In one embodiment, the expert may maintain the set of
messages. Messages flow from application level through a
family to another family, and so on. For instance, a service
family services using a central device registry in the system.

5,915,131
7

8

The expert scans the device registry for plug-ins that belong
system and block storage plug-ins are not drivers (in that
to its family. For example, a display family expert looks for
drivers back hardware).
display device entries. When a family expert finds an entry
Applications, plug-ins from other I/O families, and other
system software can request the services provided by a
for a family plug-in, it instantiates the plug-in, making it
available to clients of the family. In one embodiment, the 5 family's plug-ins through the family's FPI. Note also that
system notifies the family expert on an ongoing basis about
plug-ins are designed to operate in the environment set forth
new and deleted plug-ins in the device registry. As a result,
by their family activation model.
the set of plug-ins known to and available through the family
In one embodiment, a plug-in may comprises two code
remains current with changes in system configuration.
sections, a main code section that runs in a task in the kernel
Note that family experts do not add or alter information in 10 domain and an interrupt level code section that services
the device registry nor do they scan hardware. In one
hardware interrupts if the plug-in is, for instance, a device
embodiment, the present invention includes another level of
driver. In one embodiment, only work that cannot be done at
task level in the main code section should be done at
families (i.e., low-level families) whose responsibility is to
interrupt level. In one embodiment, all plug-ins have a main
discover devices by scanning hardware and installing and
removing information for the device registry. These low- 15 code section, but not all have interrupt level code sections.
level families are the same as the families previously disThe main code section executes and responds to client
cussed above (i.e., high level family) in other ways, i.e. they
service requests made through the FPI. For example, sound
have experts, services, an FPI, a library, an activation model
family plug-ins respond to sound family specific requests
and plug-ins. The low-level families' clients are usually
such as sound playback mode setting (stereo, mono, sample
other families rather than applications. In one embodiment, 20 size and rate), sound play requests, sound play cancellation,
etc. The interrupt level code section executes and responds
families are insulated from knowledge of physical connecto interrupts from a physical device. In one embodiment, the
tivity. Experts and the device registry are discussed in more
detail below.
interrupt level code section performs only essential
A plug-in programming interface (PPI) 306 provides a
functions, deferring all other work to a higher execution
family-to-plug-in interface that defines the entry points a 25 levels.
plug-in supports so that it can be called and a plug-in-toAlso because all of the services associated with a parfamily interface that defines the routines plug-ins call when
ticular family are tuned to the same needs and requirements,
the drivers or plug-ins for a given family may be as simple
certain events, such as an I/O completion, occur. In addition,
as possible.
PPI 306 defines the path through which the family and its
plug-in exchange data.
30 Family Programming Interfaces
A family services library (not shown) is a collection of
In the present invention, a family provides either a userroutines that provide services to the plug-ins of a family. The
mode or a kernel-mode FPI library, or both, to support the
family's FPI. FIG. 4 illustrates one embodiment of the I/O
services are specific to a given family and they may be
layered on top of services provided by the kernel. Within a
architecture of the present invention. Referring to FIG. 4,
family, the methods by which data is communicated, 35 three instances of families 401-403 are shown operating in
memory is allocated, interrupts are registered and timing
the kernel environment. Although three families are shown,
services are provided may be implemented in the family
the present invention may have any number of families.
In the user mode, two user-mode FPI libraries, Xlib u 404
services library. Family services libraries may also maintain
state information needed by a family to dispatch and manage
and Zlib u 405, are shown that support the FPIs for families
requests.
40 X and Z, respectively. In the kernel environment, two
For example, a display family services library provides
kernel-mode FPI libraries, Ylib k 406 and Zlibk , 407, for
routines that deal with vertical blanking (which is a concern
families Y and Z, respectively, are shown.
Both the user-mode and the kernel-mode FPI libraries
of display devices). Likewise, SCSI device drivers manipupresent the same FPI to clients. In other words, a single FPI
late command blocks, so the SCSI family services library
contains routines that allow block manipulation. A family 45 is the only way family services can be accessed. In one
embodiment, the user-mode and kernel mode libraries are
services library that provides commonly needed routines
simplifies the development of that family's plug-ins.
not the same. This may occur when certain operations have
meaning in one mode and not the other. For example,
Through the PPI 306, a call is made to a plug-in 307. In
operations that are implemented in the user-mode library,
one embodiment, a plug-in, such as plug-in 307, comprises
dynamically loaded code that runs in the kernel's address 50 such as copying data across address-space boundaries, may
space to provide an instance of the service provided by a
be unnecessary in the kernel library.
family. For example, within the file systems family, a plug-in
In response to service requests, FPI libraries 404 and 405
map FPI functions into messages for communication from
implements file-system-specific services. The plug-ins
the user mode to the kernel mode. In one embodiment, the
understand how data is formatted in a particular file system
such as HFS or DOS-FAT. On the other hand, it is not the 55 messages are kernel messages.
responsibility of file systems family plug-ins to obtain data
The service requests from other families are generated by
plug-ins that make calls on libraries, such as FPI libraries
from a physical device. In order to obtain data from a
406 and 407. In one embodiment, FPI libraries 406 and 407
physical device, a file system family plug-in communicates
map FPI functions into kernel messages and communicate
to, for instance, a block storage family. In one embodiment,
block storage plug-ins provide both media-specific drivers, 60 those messages to FPI servers such as Y FPI server 409 and
such as a tape driver, a CD-ROM driver, or hard disk driver,
Z FPI server 410 respectively. Other embodiments may use
and volume plug-ins that represent partitions on a given
mechanisms other than kernel messaging to communicate
physical disk. Block storage plug-ins in turn may make SCSI
information.
family API calls to access data across the SCSI bus on a
In the example, the Z family 403 has both a user-mode
physical disk. Note that in the present invention, plug-ins are 65 library 405 and a kernel-mode library 407. Therefore, the
a superset of device drivers. For instance, plug-ins may
services of the Z family may be accessed from both the user
include code that does not use hardware. For instance, file
mode and the kernel mode.

5,915,131

9

10

In response to service request messages, X FPI server
408, Y FPI server 409 and Z FPI server 410 dispatch
requests for services to their families. In one embodiment,
each of FPI servers 408-410 receives a kernel message,
maps the message into a FPI function called by the client,
and then calls the function in the family implementation
(414-416).
In one embodiment, there is a one-to-one correspondence
between the FPI functions called by clients and the function
called by FPI servers 408-410 as a result. The calls from FPI
serves 408-410 are transferred via interfaces 411-413. For
instance, X interface 411 represents the interface presented
to the FPI server 408 by the X family 414. It is exactly the
same as the FPI available to applications or other system
software. The same is true ofY interface 412 and Z interface
413.
The X family implementation 414 represents the family
activation model that defines how requests communicated
from server 408 are serviced by the family and plug-in(s). In
one embodiment, X family implementation 414 comprises
family code interfacing to plug-in code that completes the
service requests from application 400 via server 408.
Similarly, the Y family implementation 415 and Z family
implementation 416 define their family's plug-in activation
models.
X plug-in 417, Y plug-in 418 and Z plug-in 419 operate
within the activation model mandated by the family and
provide code and data exports. The required code and data
exports and the activation model for each family of drivers
is family specific and different.
Extending Family Programming Interfaces
A plug-in may provide a plug-in-specific interface that
extends its functionality beyond that provided by its family.
This is useful in a number of situations. For example, a block
storage plug-in for a CD-ROM device may provide a block
storage plug-in interface required of the CD-ROM device as
well as an interface that allows knowledgeable application
software to control audio volume and to play, pause, stop,
and so forth. Such added capabilities require a plug-inspecific API.
If a device wishes to export extended functionality outside
the family framework, a separate message port is provided
by the device and an interface library for that portion of the
device driver. FIG. 5 illustrates the extension of a family
programming interface.
Referring to FIG. 5, a plug-in module, Z plug-in 501,
extends beyond the Z family boundary to interface to family
implementation D 502 as well. A plug-in that has an
extended API offers features in addition to those available to
clients through it's family's FPI. In order to provide extra
services, the plug-in provides additional software shown in
FIG. 5 as an interface library Dlib u 503, the message port
code D FPI server 504, and the code that implements the
extra features D 505.
Sharing Code and Data Between Plug-ins
In one embodiment, two or more plug-ins can share data
or code or both, regardless of whether the plug-ins belong to
the same family or to different families. Sharing code or data
is desirable when a single device is controlled by two or
more families. Such a device needs a plug-in for each family.
These plug-ins can share libraries that contain information
about the device state and common code. FIG. 6 illustrates
two plug-ins that belong to separate families and that share
code and data.
Plug-ins can share code and data through shared libraries.
Using shared libraries for plug-ins that share code or data
allows the plug-ins to be instantiated independently without

encountering problems related to simultaneous instantiation.
Referring to FIG. 6, the first plug-in 601 to be opened and
initialized obtains access to the shared libraries. At this
point, the first plug-in 601 does not share access. When the
second plug-in 602 is opened and initialized, a new connection to the shared libraries is created. From that point, the
two plug-ins contend with each other for access to the shared
libraries.
Sharing code or data may also be desirable in certain
special cases. For instance, two or more separate device
drivers may share data as a way to arbitrate access to a
shared device. An example of this is a single device that
provides network capabilities and real time clock. Each of
these functions belong to a distinct family but may originate
in a single physical device.
Activation Models in the Present Invention
An activation model defines how the family is implemented and the environment within which plug-ins of the
family execute. In one embodiment, the activation model of
the family defines the tasking model a family uses, the
opportunities the family plug-ins have to execute and the
context of those opportunities (for instance, are the plug-ins
called at task time, during privileged mode interrupt
handling, and so forth), the knowledge about states and
processes that a family and its plug-ins are expected to have,
and the portion of the service requested by the client that is
performed by the family and the portion that is performed by
the plug-ins.
Each model provides a distinctly different environment
for the plug-ins to the family, and different implementation
options for the family software. Examples of activation
models include the single-task model, the task-per-plug-in
model, and the task-per-request model. Each is described in
further detail below. Note that although three activation
models are discussed, the choice of activation model is a
design choice and different models may be used based on the
needs and requirements of the family.
In one embodiment, the activation model uses kernel
messaging as the interface between the FPI libraries that
family clients link to and the FPI servers in order to provide
the asynchronous or synchronous behavior desired by the
family client. Within the activation model, asynchronous I/O
requests are provided with a task context. In all cases, the
implementation of the FPI server depends on the family
activation model.
The choice of activation model limits the plug-in implementation choices. For example, the activation model
defines the interaction between a driver's hardware interrupt
level and the family environment in which the main driver
runs. Therefore, plug-ins conform to the activation model
employed by its family.
Single-Task Model
One of the activation models that may be employed by a
family is referred to herein as the single-task activation
model. In the single-task activation model, the family runs
as a single monolithic task which is fed from a request queue
and from interrupts delivered by plug-ins. Requests are
delivered from the FPI library to an accept function that
enqueues the request for processing by the family's processing task and wakes the task if it is sleeping. Queuing,
synchronization, and communication mechanism within the
family follow a set of rules specified by the family.
The interface between the FPI Server and a family implementation using the single-task model is asynchronous.
Regardless of whether the family client called a function
synchronously or asynchronously, the FPI server calls the
family code asynchronously. The FPI server maintains a set

5

10

15

20

25

30

35

40

45

50

55

60

65

5,915,131
11

12

of kernel message IDs that correspond to messages to which
the FPI server has not yet replied. The concept of maintaining kernel message IDs corresponding to pending I/O server
request messages is well-known in the art;
Consider as an example family 700, which uses the
single-task activation model, shown in FIG. 7. Referring to
FIG. 7, an application 710 is shown generating a service
request to the family's APIs 711. APIs 711 contain at least
one library in which service requests are mapped to FPl
functions. The FPI functions are forwarded to the family's
FPI server 701. FPI server 701 dispatches the FPI function
to family implementation 703, which includes various protocols and a network device driver that operate as a single
task. Each protocol layer provides a different level of
serVIce.
The FPI server 701 is an accept function that executes in
response to the calling client via the FPI library (not shown).
An accept function, unlike a message-receive-based kernel
task, is able to access data within the user and kernel bands
directly. The accept function messaging model requires that
FPI server 701 be re-entrant because the calling client task
may be preempted by another client task making service
requests.
When an I/O request completes within the family's
environment, a completion notification is sent back to the
FPI server 701, which converts the completion notification
into the appropriate kernel message ID reply. The kernel
message ID reply is then forwarded to the application that
generated the service request.
With a single-task model, the family implementation is
insulated from the kernel in that the implementation does it
not have kernel structures, IDs, or tasking knowledge. On
the other hand, the relationship between FPI server 701 and
family code 702 is asynchronous, and has internal knowledge of data structures and communication mechanisms of
the family.
The single-task model may be advantageously employed
for families of devices that have one of several characteristics: (1) each I/O request requires little effort of the
processing unit. This applies not only to keyboard or mouse
devices but also to DMA devices to the extent that the
processing unit need only set up the transfer, (2) no more
than one I/O request is handled at once, such that, for
instance, the family does not allow interleaving of I/O
requests. This might apply to sound, for example, or to any
device for which exclusive reservation is required (i.e.,
where only one client can use a device at a time). The
opposite of a shared resource. Little effort for the processor
exists where the processor initiates an I/O request and then
is not involved until the request completes, or (3) the family
to be implemented provides its own scheduling mechanisms
independent of the underlying kernel scheduling. This
applies to the Unix™ stream programming model.
Task-Per-Plug-In Model
For each plug-in instantiated by the family, the family
creates a task that provides the context within which the
plug-in operates.
FIG. 8 illustrates the task-per-plug-in model. Referring to
FIG. 8, an application 801 generates service requests for the
family, which are sent to FPI 802. Using an FPI library, the
FPI 802 generates a kernel message according to the family
activation model 804 and a driver, such as plug-in driver
805.
In one embodiment, the FPI server 803 is a simple
task-based message-receive loop or an accept function. FPI
server 803 receives requests from calling clients and passes
those requests to the family code 804. The FPI server 803 is

responsible for making the data associated with a request
available to the family, which in turn makes it available to
the plug-in that services the request. In some instances, this
responsibility includes copying or mapping buffers associated with the original request message to move the data from
user address space to the kernel level area.
The family code 804 consists in part of one or more tasks,
one for each family plug-in. The tasks act as a wrapper for
the family plug-ins such that all tasking knowledge is
located in the family code. A wrapper is a piece of code that
insulates called code from the original calling code. The
wrapper provides services to the called code that the called
code is not aware of.
When a plug-in's task receives a service request (by
whatever mechanisms the family implementation uses), the
task calls its plug-in's entry points, waits for the plug-in's
response, and then responds to the service request.
The plug-in performs the work to actually service the
request. Each plug-in does not need to know about the
tasking model used by the family or how to respond to event
queues and other family mechanisms; it only needs to know
how to perform its particular function.
For concurrent drivers, all queuing and state information
describing an I/O request is contained within the plug-in
code and data and within any queued requests. The FPI
library forwards all requests regardless of the status of
outstanding I/O requests to the plug-in. When the client
makes a synchronous service request, the FPI library sends
a synchronous kernel message. This blocks the requesting
client, but the plug-in's task continues to run within its own
task context. This permits clients to make requests of this
plug-in even while another client's synchronous request is
being processed.
In some cases of a family, a driver (e.g., 805) can be either
concurrent or nonconcurrent. Nevertheless, clients of the
family may make synchronous and asynchronous requests,
even though the nonconcurrent drivers can handle only one
request at a time. The device manager FPI server 803 knows
that concurrent drivers cannot handle multiple requests
concurrently. Therefore, FPI server 803 provides a mechanism to queue client requests and makes no subsequent
requests to a task until the task signals completion of an
earlier I/O request.
When a client calls a family function asynchronously, the
FPI library sends an asynchronous kernel message to the FPI
server and returns to the caller. When a client calls a family
function synchronously, the FPI library sends a synchronous
kernel message to the FPI server and does not return to the
caller until the FPI server replies to the message, thus
blocking the caller's execution until the I/O request is
complete.
In either case, the behaviors of the device manager FPI
server 803 is exactly the same: for all incoming requests, it
either queues the request or passes it to the family task,
depending on whether the target plug-in is busy. When the
plug-in signals that the I/O operation is complete, the FPI
server 803 replies to the kernel message. When the FPI
library receives the reply, it either returns to the synchronous
client, unblocking its execution or it notifies the asynchronous client about the I/O completion.
The task-per-plug-in model is intermediate between the
single-task and task-per-request models in terms of the
number of tasks it typically uses. The task-per-plug-in model
is advantageously used where the processing of I/O requests
varies widely among the plug-ins.
Task-Per-Request Model
The task-per-request model shares the following characteristics with the two activation models already discussed:

5

10

15

20

25

30

35

40

45

50

55

60

65

5,915,131

13

14

(1) the FPI library to FPI server communication provides the
sented by the entry and that contain a reference to the driver
in control of the device.
synchronous or asynchronous calling behavior requested by
Multiple low-level experts are used, where each such
family clients, and (2) the FPI library and FPI server use
expert is aware of the connection scheme of p~ysical d~vic~s
kernel messages to communicate I/O requests between
to the system and installs and removes that mformatIOn m
themselves. However, in the task-per-request model, the FPI
server's interface to the family implementation is com- 5 the device tree portion of the device registry. For example a
low-level expert, referred to herein as a bus expert or a
pletely synchronous.
motherboard expert, has specific knowledge of a piece of
In one embodiment, one or more internal family request
hardware such as a bus or a motherboard. Also, a SCSI bus
server tasks, and, optionally, an accept function, wait for
expert scans a SCSI bus for devices, and installs an entry
messages on the family message port. An arriving message
containing information describing an I/O request awakens 10 into the device tree for each device that it finds. The SCSI
bus expert knows nothing about a particular device for
one of the request server tasks, which calls a family function
which it installs an entry. As part of the installation, a driver
to service the request. All state information necessary to
handle the request is maintained in local variables. The
gets associated with the entry by the SCSI bus expert. The
request server task is blocked until the I/O request
driver knows the capabilities of the device and specifies that
completes, at which time it replies to the kernel mess.age 15 the device belongs to a given family. This information is
from the FPI library to indicate the result of the operatIOn.
provided as part of the driver or plug-in descriptive structure
After replying, the request server task waits for more mesrequired of all plug-ins as part of their PPI implementation.
sages from the FPI library.
Low-level experts and family experts use a device registry
As a consequence of the synchronous nature of the
notification mechanism to recognize changes in the system
interface between the FPI server and the family 20 configuration and to take family-specific action in response
implementation, code calling through this interface remains
to those changes.
running as a blockable task. This calling code is either the
An example of how family experts, low-level experts, and
request server task provided by the family to service the I/O
the device registry service operate together to stay aware of
(for asynchronous I/O requests) or the task of the requester
dynamic changes in system configuration follows: Suppose
of the I/O (for certain optimized synchronous requests).
a motherboard expert notices that a new bus, a new network
The task-per-request model is advantageously employed 25 interface and new video device have appeared within the
for a family where an I/O request can require continuous
system. The motherboard expert adds a bus node, a network
attention from the processor and multiple I/O requests can
node, and a video node to the device tree portion of the
be in progress simultaneously. A family that supports dumb,
device registry. The device registry service notifies all
high bandwidth devices is a good candidate for this model.
software that registered to receive notifications of these
In one embodiment, the file manager family uses the task- 30 events.
per-request model. This programming model requires the
Once notified that changes have occurred in the device
family plug-in code to have tasking knowledge and to use
registry, the networking and video family experts scan the
kernel facilities to synchronize multiple threads of execution
device registry and notice the new entry belonging to their
contending for family and system resources.
family type. Each of the experts adds an entry in the family
Unless there are multiple task switches within a family, 35 subtree portion of the device registry.
the tasking overhead is identical within all of the activation
The SCSI bus expert notices an additional bus, and probes
models. The shortest task path from application to I/O is
for SCSI devices. It adds a node to the device registry for
completely synchronous because all code runs on the calleach SCSI device that it finds. New SCSI devices in the
er's task thread.
device registry result in perusal of the device registry by the
Providing at least one level of asynchronous call between 40 block storage family expert. The block storage expert
an application and an I/O request results in better latency
notices the new SCSI devices and loads the appropriate
results from the user perspective. Within the file system, a
drivers, and creates the appropriate device registry entries, to
task switch at a file manager API level allows a user-visible
make these volumes available to the file manager. The file
application, such as the Finder™, to continue. The file
manager receives notification of changes to the block stormanager creates an I/O tasks to handle the I/O request, and
age family portion of the device registry, and notifies the
that task is used via synchronous calls by the block storage 45 FinderTM that volumes are available. These volumes then
and SCSI families to complete their part in I/O transaction
appear on the user's desktop.
processing.
Whereas, many alterations and modifications of the
The Device Registry of the Present Invention
present invention will no doubt become apparent to a person
The device registry of the present invention comprises an
of ordinary skill in the art after having read the foregoing
operating system naming service that stores system infor- 50 description, it is to be understood that the particular embodimation. In one embodiment, the device registry is responment shown and described by way of illustration are in no
sible for driver replacement and overloading capability so
way to be considered limiting. Therefore, reference to the
that drivers may be updated, as well as for supporting
details of the various embodiments are not intended to limit
dynamic driver loading and unloading.
the scope of the claims which themselves recite only those
In one embodiment, the device registry of the present 55 features regarded as essential to the invention.
invention is a tree-structured collection of entries, each of
Thus, a method and apparatus for handling I/O requests in
which can contain an arbitrary number of name-value pairs
a computer system has been described.
called properties. Family experts examine the device regisWe claim:
try to locate devices or plug-ins available to the family.
1. A computer system comprising:
Low-level experts, discussed below, describe platform harda bus;
ware by populating the device registry with device nodes for 60
at least one memory coupled to the bus for storing data
insertion of devices that will be available for use by appliand programming instructions that include applications
cations.
and an operating system; and
In one embodiment, the device registry contains a device
a processing unit coupled to the bus and running the
subtree pertinent to the I/O architecture of the present
operating system and applications by executing proinvention. The device tree describes the configuration and 65
gramming instructions, wherein an application has a
connectivity of the hardware in the system. Each entry in the
first plurality of tailored distinct programming interdevice tree has properties that describe the hardware repre-

5,915,131
15

16

faces available to access a plurality of separate sets of
10. The computer system defined in claim 9 wherein the
first programming interface is responsive to request from
computer system services provided through the operapplications and from other program structures.
ating system of the computer system via service
11. The computer system defined in claim 9 wherein the
requests.
2. The computer system defined in claim 3 wherein each 5 first programming interface comprises at least one library for
converting functions into messages.
of the first plurality of tailored distinct programming inter12. The computer system defined in claim 9 wherein the
faces are tailored to a type of I/O service provided by each
first server receives a message corresponding a service
set of I/O services.
request from the first programming interface, maps the
3. A computer system comprising:
10 message into a function called by the client, and then calls
a bus;
the function.
at least one memory coupled to the bus for storing data
13. The computer system defined in claim 9 wherein the
and programming instructions that include applications
message comprises a kernel message.
and an operating system, wherein the operating system
14. A computer system comprising:
comprises a plurality of servers, and each of the first
a bus;
plurality of programming interfaces transfer service 15
at least one memory coupled to the bus for storing data
requests to one of the plurality of servers, wherein each
and programming instructions that comprise applicaof the plurality of servers responds to service requests
tions and an operating system;
from clients of the separate sets of I/O services; and
a processing unit coupled to the bus and running the
operating system and applications by executing proa processing unit coupled to the bus and running the
operating system and applications by executing pro- 20
gramming instructions, wherein the operation system
provides input/output (I/O) services through a tailored
graming instructions, wherein an application has a first
distinct one of plurality of program structures, each
plurality of tailored distinct programming interfaces
available to access a plurality of separate sets of I/O
tailored distinct program structure comprising:
a first programming interface for receiving service
services provided through the operating system via
25
service requests.
requests for a set of I/O services of a first type,
4. The computer system defined in claim 3 wherein
a first server coupled to receive service requests and to
service requests are transferred as messages in a messaging
dispatch service requests to the I/O services,
system.
an activation model to define operating environment in
5. The computer system defined in claim 4 wherein each
which a service request is to be serviced by the set of
of the plurality of servers supports a message port.
30
I/O services, and
6. The computer system defined in claim 3 wherein at
at least one specific instance of the set of I/O services
least one of the plurality of servers is responsive to service
that operate within the activation model, wherein one
requests from applications and from at least one other set of
of the said at least one specific instances comprises
I/O services.
a service that accesses another program structure,
7. The computer system defined in claim 3 wherein the 35
and further wherein said one of said at least one
operating system further comprises a plurality of activation
specific instances communicates to said another promodels, wherein each of the plurality of activation models is
gram structure of a second type using a message
associated with one of the plurality of servers to provide a
created using a library sent to the server of said
runtime environment for the set of I/O services to which
another program structure.
access is provided by said one of the plurality of servers.
15. The computer system defined in claim 9 wherein two
8. The computer system defined in claim 7 wherein at 40
or more I/O services share code or data.
least one instance of a service is called by one of the plurality
16. The computer system defined in claim 15 wherein said
of servers for execution in an environment set forth by one
two or more I/O services are different types.
of the plurality of activation models.
17. The computer system defined in claim 9 wherein the
9. A computer system comprising:
45 program structure further comprises a storage mechanism to
a bus;
maintain identification of available services to which access
at least one memory coupled to the bus for storing data
is provided via the first server.
and programming instructions that comprise applica18. A computer implemented method of accessing I/O
tions and an operating system;
services of a first type, said computer implemented method
a processing unit coupled to the bus and running the
comprising the steps of:
operating system and applications by executing pro- 50
generating a service request for a first type of I/O services;
gramming instructions, wherein the operating system
a tailored distinct family server, operating in an operating
provides computer system services through a tailored
system environment and dedicated to providing access
distinct one of a plurality of program structures, each
to service requests for the first type of I/O service,
tailored distinct program structure comprising:
receiving and responding to the service request based
a first programming interface for receiving service 55
on an activation model specific to the first type of I/O
requests for a set of computer system I/O services of
services; and
a first type,
a processor running an instance of the first type of I/O
a first server coupled to receive service requests and to
services that is interfaces to the file server to satisfy the
dispatch service requests to the computer system I/O
service request.
60
services,
19. The method defined in claim 18 wherein the service
an activation model to define an operating environment
request is generated by an application.
in which a service request is to be serviced by the set
20. The method defined in claim 18 wherein the service
of computer system I/O services, and
request is generated by an instance of an I/O service running
at least one specific instance of the set of computer
in the operating system environment.
system I/O services that operate within the activation 65
model.
* * * * *

UNITED STATES PATENT AND TRADEMARK OFFICE

CERTIFICATE OF CORRECTION
PATENT NO.5, 915,131
DATED
June 22, 1999
INVENTOR(S) : Knight, et ale
It is certified that error appears in the above-identified patent and that said Letters Patent is hereby
corrected as shown below:

In column 15 at line 14 delete ''the'' and insert -- a __
In column 15 at line 54 delete ":" and insert -- ; -In column 16 at line 20 delete "operation" and
insert -- operating -In column 16 at line 58 delete "interfaces" and
insert -- interfaced --

Signed and Sealed this
Eighteenth Day of January, 2000
Attest:

~~
Q. TODD DICKINSON

Attesting Officer

Commissioner of Patents and Trademarks