Ex Parte 5,915,131 et al

Patent Trial and Appeal Board

Dec 18, 2012

90011311 (P.T.A.B. Dec. 18, 2012)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
90/011,311 11/01/2010 5,915,131 0314896.131 1355
45217 7590 12/18/2012
APPLE INC./BSTZ
BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 OAKMEAD PARKWAY
SUNNYVALE, CA 94085-4040
EXAMINER
CHOI, WOO H
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
12/18/2012 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte
APPLE, INC.

____________

Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161
Technology Center 3900
____________

Before RICHARD M. LEBOVITZ, STEPHEN C. SIU, and
MICHAEL R. ZECHER, Administrative Patent Judges.

LEBOVITZ, Administrative Patent Judge.

DECISION ON APPEAL
This is a decision on appeal by the Patent Owner from the Patent
Examiner’s rejections of claims 1-6 in an ex parte reexamination of U.S.
Patent No. 5,915,131, issued June 22, 1999. The Board’s jurisdiction for
this appeal is under 35 U.S.C. §§ 6 and 134. We affirm.

Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

2
STATEMENT OF THE CASE
A request for ex parte reexamination of U.S. Patent 5,915,131
(hereinafter, “the ‘131 patent) was made by a Third Party Requester on
November 1, 2010, pursuant to 35 U.S.C. §§ 302-307 and C.F.R. § 1.510.
Reexamination was ordered for claims 1-20. The patentability of claims 7-
20 was confirmed by the Examiner. App. Br. 3 (Appeal Brief, filed
February 15, 2012). Claims 1-6, however, remain rejected by the Examiner.
The rejections are appealed. An oral hearing was held on November 7,
2012. A transcript will be entered into the record in due course. This is the
decision on the appeal.
The claims stand rejected by the Examiner as follows:
1. Claim 1 under 35 U.S.C. § 102(a) as anticipated by Teaff.1
Answer 3-4.
2. Claims 1-6 under 35 U.S.C. § 102(a) as anticipated by Andert.2
Answer 4-6.
Claim 1 is representative and reads as follows:
A computer system comprising:
a bus;
at least one memory coupled to the bus for storing data
and programming instructions that include
applications and an operating system; and
a processing unit coupled to the bus and running the
operating system and applications by executing
programming instructions, wherein an application

1 Danny Teaff et al., The Architecture of the High Performance Storage
System (4th NASA Goddard Conference on Mass Storage Systems and
Technologies, March 29-30 1995).
2 U.S. Patent 5,566,346 (filed Dec. 21, 1993) (issued Oct. 15, 1996).
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

3
has a first plurality of tailored distinct
programming interfaces available to access a
plurality of separate sets of computer system
services provided through the operating system of
the computer system via service requests.

CLAIM INTERPRETATION
The main dispute in the rejections at issue in this appeal is whether the
cited publications describe a computer system comprising a “plurality of
tailored distinct programming interfaces available to access a plurality of
separate sets of computer system services.” We must therefore first interpret
this phrase before comparing the claims to the cited prior art.
During reexamination, claims are given their broadest reasonable
interpretation as they would be understood in the context of the
specification. In re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed.
Cir. 2004); In re Suitco Surface, Inc., 603 F.3d 1255, 1259 (Fed. Cir. 2010).
For this reason, the patent specification is the starting point when
interpreting a claim.
The ‘131 Patent does not explicitly define “tailored distinct
programming interfaces.” However, the patent does provide guidance as to
how it should be interpreted.
The ‘131 Patent teaches that to gain access to input/out (“I/O”)
devices, “applications generate service requests to which are sent through an
application programming interface (API).” ‘131 Patent, col. 1, ll. 19-27.
The ‘131 Patent explains:
The service requests are converted by the API to a common set
of functions that are forwarded to the operating system to be
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

4
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.
‘131 Patent, col. 1, ll. 21-27.
The ‘131 identifies a problem with the prior art APIs: “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.” ‘131 Patent, col. 1, ll. 28-31. To address this issue,
the inventors describe APIs which are tailored to specific devices, rather
than using the same API for each device.
The inventors state in the “Summary of the Invention” that each
application program has “multiple separate programming interfaces
available to access multiple sets of I/O services.” ‘131 Patent, col. 1, ll. 56-
58. The inventors explain that separate families of programing interfaces
(FPI) are designed to meet the particular needs of a programming interface
family. Id. at col. 5, ll. 20-21. The ‘131 Patent gives several examples:
● “For example, when an application generates data for a video
device, a display FPI tailored to the needs of video devices is used to gain
access to display services.” Id. at col. 6, ll. 29-31.
● “For example, within the file systems family (File Manager), a
plug-in implements file-system-specific services.” Id. at col. 5, ll. 24-26.
● “That is, an FPI is designed to provide callers with services
appropriate to a particular family, whether those calls originate from in the
user domain or the operating system domain.” Id. at col. 6, ll. 25-28
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

5
The ‘131 Patent summarizes: “Therefore, the present invention
provides family programming interfaces tailored to the needs of specific
device families.” Id. at col. 6, ll. 34-36. As indicated above, this is achieved
using APIs specifically designed for the special purpose (video and calls)
and using specifics components (e.g., a plug-in for the file manager).
In light of the statement of the problem and the description of how it
was addressed, a person of ordinary skill in the art would construe “tailored
distinct programming interfaces” to mean different programming interfaces
that are designed (“tailored”) with different components to provide access to
the specific service functions of the device. See, e.g., ‘131 Patent, col. 1, ll.
56-58; col. 6, ll. 25-31 (pertinent passages reproduced above). The
programming interfaces are thus different or distinct from each by having
different components and/or displays that perform different functions and
operations depending on the needs of the device.

ANTICIPATION BY TEAFF
Findings of Fact (“FF”)
FF1. Teaff describes the “High Performance Storage System
(HPSS),” a system designed to improve the performance and capacity of
available storage systems. Teaff, p. 1.
FF2. Teaff describes the HPSS architecture as a highly modular with
software components “loosely coupled, with open application program
interfaces (APIs) defined at each component level.” Teaff, p. 4.
FF3. Teaff refers to multiple API’s for different software
components. These include (FF4-FF10):
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

6
FF4.
Most users will access HPSS at its high level interfaces-
currently client API, FTP (both parallel and sequential), NFS,
Parallel File System (PFS), with AFS/DFS, Unix Virtual File
System (VFS), and Data Management Interface Group (DMIG)
interfaces in the future) [11,15,18,19]. However, APIs are
available to the underlying software components for
applications, such as large scale data management, digital
library or video-on-demand requiring high performance or
special services.
Teaff, p. 4.
FF5. “APIs have been turned over to the IEEE Storage System
Standards Working Group as a basis for its standards activities.” Teaff, p. 5.
FF6. Teaff describes a Client API:
Client API
The HPSS Client file server API mirrors the POSIX file system
interface specification where possible. The Client API also
supports extensions to allow the programmer to take advantage
of the specific features provided by HPSS (e.g., class-of-
service, storage/access hints passed at file creation and support
for parallel data transfers).
Teaff, p. 11
FF7. For the Storage System Manager (SSM), Teaff states that the
“operations performed by SSM are usually accomplished through standard
HPSS server APIs.” Teaff, p. 15.
FF8. Figure 7 shows an SSM with a “Client API” and a “Sammi
API.” Teaff, p. 16.
FF9. Appendix A is titled: “Application Programming Interfaces
(APIs) to HPSS Components.
App
App
Paten

eal 2012-0
lication 90
t No. 5,9
FF10. A
09761
/011,311
15.161
n excerpt of Append
7
ix A is rep

roduced below:

Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

8
Legal Principles
“To anticipate a claim, a prior art reference must disclose every
limitation of the claimed invention, either explicitly or inherently.” In re
Schreiber, 128 F.3d 1473, 1477 (Fed. Cir. 1997). When the limitations of a
claim are not expressly described in the prior art, the PTO must show “sound
basis for believing” that despite the failure of the prior art to describe them,
the limitations are inherently there and “the products of the applicant and the
prior art are the same.” In re Spada, 911 F.2d 705, 708 (Fed. Cir. 1990).

Discussion
The Examiner found that Teaff discloses a computer system
comprising a “plurality of tailored distinct programming interfaces” as
recited in claim 1. Answer 4 & 6-7. Patent Owner challenges this
determination. App. Br. 5. Patent Owner contends that the Examiner failed
“to provide sufficient evidence or technical/scientific reasoning to establish
that Teaff's explicit disclosure would expressly, inherently, or be capable of
having a plurality of tailored distinct interfaces as called for in claim 1.” Id.
at 6. Patent Owner argues:
While the Patent Owner acknowledges Teaff's explicit
disclosure in Appendix A lists multiple APIs for different
clients with different [sic], the Patent Owner respectfully
disagrees with the Examiner [sic] inference (Ans. 6) that those
APIs satisfy the plurality of tailored distinct programming
interfaces as called for in claim 1. At most, Teaff just describes
a listing APIs within a library provided by the HPSS wherein
the APIs are for some clients and for a particular functionality.
Reply Br. 3.
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

9
Patent Owner’s arguments are not supported by sufficient evidence.
We have interpreted “plurality of tailored distinct programming interfaces”
to mean different programming interfaces that are designed (“tailored”) with
different components or displays to provide access to the specific service
functions of the device. Thus, the different programming interfaces recited
in claim 1 must perform different functions, e.g., a video API for accessing a
video device and a call API to provide a call service. See supra at p. 4.
There is adequate evidence that the APIs described in Teaff meet this
limitation.
First, Teaff expressly identifies different APIs with different names.
For example, Teaff refers to a Client API and a SAMMI API, suggesting
that the APIs have different names because they perform different functions
as required by claim 1. FF5 & FF6.
Second, Teaff also refers to multiple APIs (FF2-FF5), and states they
are available for different services (FF4) – again suggesting the APIs
perform a different function depending upon the service they are coupled
with.
Third, and foremost, Teaff has a long list of APIs, each with a
different name and a different description of what it does. FF10. For
example, Teaff describes a Name Server which is said to provide multiple
APIs for performing different operations: “ns_Insert” for “Insert a bitfile
object into a directory” and “ns_Delete” for “Delete a name space object.”
FF10. Teaff also describes a HPSS Client Library with APIs with different
functionalities: “hpss_Open” for “Optionally create and open an HPSS file”
and “hpss_Close” for “Close a file.” FF10. The most logical explanation is
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

10
that the listed APIs are not the same API performing different functions, but
instead different APIs designed to perform the stated function.
Based on this evidence, the Examiner had a factual basis to find that
Teaff described the claimed “plurality of tailored distinct programming
interfaces” as that phrase would be properly construed by one of ordinary in
the art in the context of the ‘131 Patent specification. Patent Owner
contends that the Examiner’s finding lacked sufficient evidence and
reasoning, but did not point to a specific defect. To the contrary, Teaff
expressly describes APIs that perform different functions and operations,
providing more than ample basis to find the disputed limitation in the prior
art. Spada, 911 F.2d at 708.

ANTICIPATION BY ANDERT
Findings of Fact
FF11. Andert describes an input/output (IO) architecture for a
computer system. Andert, col. 1, ll. 10-15.
FF12. Andert describes IO service frameworks “for enabling an end
user (such as a human operator, an operating system function, an application
program, etc.) to perform these and other input/output services. In particular,
an end user can interact with these IO service frameworks to perform any
supported input/output operations.” Andert, col. 8, ll. 38-44.
FF13.
Some of the input/output services provided by the IO system of
a preferred embodiment include (a) Mass Storage IO services;
(b) Keyboard processing services; (c) Mouse/Pointing device
processing services; (d) SCSI services; (e) Serial
App
App
Paten

And

the s
eal 2012-0
lication 90
t No. 5,9
commun
services
managem
ert, col. 8,
FF14. F
FIG. 1 il
ervices the
FF15.
Th
of the sp
are show
These IO
device fr
mouse p
bus fram
09761
/011,311
15.161
ications p
; (g) Deskt
ent servic
ll. 31-37
igure 1 is
lustrates in
y provide
e major IO
ecific serv
n in FIG.
service f
amework
ort, a desk
ework 102
ort service
op bus IO
es.
reproduced
put/outpu
and devic
service f
ices they p
1 (services
ramework
102A, wh
top bus, an
B, which
11
s; (f) Expa
services; a
below:
t service f
es they acc
ramework
rovide an
and devic
s 102 inclu
ich provid
d a serial
provides s
nsion bus
nd (h) Po
ramework
ess.
s 102, alo
d devices
es are sho
de (1) a m
es services
mouse; (2
ervices re
managem
wer
s along wi
ng with so
they acces
wn as ova
ouse/poin
relating t
) a desktop
lating to an
ent

th some of
me
s,
ls).
ting
o a

Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

12
access bus; (3) a serial port framework 102C, which provides
services relating to the synchronous and asynchronous transfer
of data via serial ports; (4) a power management framework
102D, which provides services relating to power sensing and
screen management; (5) a parallel port framework 102E, which
provides services relating to interaction with parallel-type
devices (such as printers, portable disks, network interfaces,
etc.); (6) an expansion bus management framework 102F,
which provides services relating to the interaction with
expansion buses; (7) a mass storage device framework, which
provides services relating to mass storage devices; (8) a
keyboard framework 102H, which provides services relating to
key-board input devices; and (9) a SCSI bus framework 102I,
which provides services relating to a SCSI bus and devices
connected to this bus.
Col. 8, ll. 45-67
FF16. “Each framework may present its clients with an appropriate
and desirable interface instead of being confined to a "one-size-fits-all"
paradigm enforced across all frameworks.” Col. 5, ll. 8-11.
FF17.
In the description of Device Access Managers, it is stated:
Why have Device Access Managers 208 instead of classic
drivers? The answer is in the expanded role that is required of
the IO ensembles of a preferred embodiment. Each type of
device has differences in access rules and protocol. Constricting
this diversity into a "one-size-fits-all" interface abstraction is
common practice among current OS architectures. To honor
the goal of enabling innovation, it must be recognized that any
given set of these access protocols may be diverse. Thus, each
category of device must be allowed to define its own abstract
interface.
Col. 11, ll. 25-35.

Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

13
Discussion
The issue in this rejection is whether Andert describes a
computer system with “a first plurality of tailored distinct
programming interfaces available to access a plurality of separate sets
of computer system services.” The Examiner found that Andert’s
description of IO service frameworks met the limitation of
“programming interfaces” as recited in the claims. Answer 5; FF12.
The Examiner further found that the IO service frameworks were
described and shown by Andert to be “tailored” and “distinct”
programming interfaces, particularly as shown in Figure 1 and its
description. Answer 5; FF12-FF15.
Patent Owner challenges this determination, and provides a
declaration by David Wilson, Ph.D., to support this position. Dr. Wilson has
a Ph.D. in Applied Physics and stated that he has over 20 years of
experience in developing and teaching advanced computer technologies.
Wilson Decl., Exhibit 1.
The examiner bears the burden of presenting at least a prima facie
case of anticipation. In re King, 801 F.2d 1324, 1327 (Fed. Cir. 1986). Once
that burden is met, Appellant has the burden of providing arguments and
evidence to rebut it. In re King, 801 F.2d at 1327.
After considering the totality of the evidence, we conclude that the
Examiner put forth sufficient evidence to establish that Andert describes a
“plurality of tailored distinct programming interfaces,” and that Patent
Owner did not provide sufficient evidence to rebut the Examiner’s
determination. We explain our reasoning as follows.
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

14
Andert describes IO service frameworks for enabling an end user to
perform input/output services. FF12. It is undisputed that the service
frameworks meet the limitation of “programming interfaces.” Figure 1 of
Andert shows distinct interfaces 102A-102I for each service. FF14. These
are identified by different names, depending upon the input/output service.
For example, several of the services are named as follows: “Mouse/Pointing
Dev” (102A), “Serial” (102C), and “Keyboard” (102H). FF14. The distinct
interfaces are described by Andert as having different functions. FF15. For
example:
● mouse/pointing device framework 102A, which provides services
relating to a mouse port, a desktop bus, and a serial mouse;
● desktop bus framework 102B, which provides services relating to
an access bus; and
● serial port framework 102C, which provides services relating to the
synchronous and asynchronous transfer of data via serial ports.
Andert also states that the frameworks “may present [their]
clients with an appropriate and desirable interface instead of being
confined to a ‘one-size-fits-all’ paradigm enforced across all
frameworks.” FF16. Andert acknowledges that “a ‘one-size-fits-all’
interface abstraction is common practice among current OS
architectures,” but concluded that to enable innovation, “each
category of device must be allowed to define its own abstract
interface.” FF17. Thus, Andert expressly teaches against using the
same framework for each device.
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

15
Based on this evidence – (1) the different names of the service
frameworks (FF14), (2) their different stated functions (FF15), and (3)
the explicit disclosure that frameworks may be different rather than
“one-size-fits-all” (FF16 & FF17) – the Examiner had reasonable
basis to believe that differently named IO frameworks described in
Andert perform different functions and thus are “tailored” as that term
would be reasonably construed in light the ‘131 patent. The burden
thus properly shifted to Patent Owner to show that Andert’s
frameworks are not tailored. Spada, 911 F.2d at 708.
Patent Owner contends there is no explicit description of
tailored interfaces. App. Br. 9; Reply Br. 6. Patent Owner’s expert,
Dr. David Wilson, testified in his written declaration that Andert does
not disclosed a tailored interface as recited in the claims. Dr. Wilson
stated:
One of Andert,,s [sic] frameworks, the IO Service Framework,
provides an interface to a client of a particular I/O service.
Andert provides no description of the interface to this
framework and therefore I conclude that Andert does not
disclose that the interface to the IO Service Framework is
tailored.
Wilson Decl. ¶ 12.
Dr. Wilson also testified:
Beyond the fact that Andert does not disclose a tailored
interface, I do not understand the IO Service Frameworks in
Andert to be a tailored interface. As I stated in my previous
declaration, filed as Exhibit A to Patent Owner,,s [sic] June 13,
2011 Response to Non-final Office Action, a person of ordinary
skill in the art would be more familiar with the traditional
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

16
interfaces to I/O services, which were not tailored to the
specific I/O device being accessed. Therefore, even when
reading Andert in view of my knowledge of the state-of-the-art,
a practice that I am told is inconsistent with an anticipation
analysis, I do not understand the Andert reference to disclose a
tailored interface.
Wilson Decl. ¶ 13.
Dr. Wilson’s testimony is not persuasive. To begin, Dr. Wilson did
not address the Examiner’s findings regarding the different descriptions of
the programming interfaces by Andert at col. 8, ll. 45-67 (Answer 5; FF15),
the disparagement by Andert of the one size fits all approach (FF16 &
FF17), and the specific disclosure in Andert that “each category of device
must be allowed to define its own abstract interface” (FF17). The latter
provides sound factual evidence that the programming interfaces of Andert
are distinct and tailored.
Dr. Wilson states that traditional interfaces to I/O services were not
tailored. Wilson Decl. ¶ 13. But whatever was conventional at the time the
‘131 Patent was filed is not dispositive in view of the strong teachings in
Andert of programming interfaces with different names and different
functions, and the criticism of the standard one-size-fits-all approach.
For the foregoing reasons, we affirm the rejection of claim 1.

Claim 3
Independent claim 3 is also directed to a computer system having “a
first plurality of tailored distinct programming interfaces available to access
a plurality of separate sets of I/O services.” The same reasons that claim 1 is
prima facie anticipated over Andert therefore apply here.
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

17
Patent Owner contends that Andert’s disclosure of 1) a listing of I/O
services (a) through (h), col. 8, lines 30-37, and 2) an expression stating that
I/O service frameworks enable an end user to perform the aforementioned
services do not establish by a preponderance of the evidence that Andert
either explicitly or inherently discloses the claimed plurality of tailored
distinct interfaces. App. Br. 12.
We do not agree. To the contrary, Andert expressly identifies the
services with different names and different functions, and distinguishes the
framework services from a one size fits all approach. The most logical and
reasonable conclusion is that Andert’s interfaces are distinct and tailored.
We thus affirm the rejection of claim 3.

Claims 2-6
Claims 2-6 were not separately argued. We thus affirm the rejection
of these claims for the reasons given by the Examiner.

SUMMARY
We affirm the anticipation rejection of claim 1 over Teaff and the
anticipation rejection of claims 1-6 over Andert.

TIME PERIOD FOR RESPONSE
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a).

AFFIRMED
Appeal 2012-009761
Application 90/011,311
Patent No. 5,915.161

18

KMF
Patent Owner:
APPLE INC./BSTZ
BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 Oakmead Parkway
Sunnyvale, CA 94085-4040

Third Party Requester:
Joseph J. Richetti
BRYAN CAVE LLP
1290 Avenue of the Americas
New York, NY 10104