Petition For Inter Partes Review

UNITED STATES PATENT AND TRADEMARK OFFICE
____________
BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________
Unified Patents Inc.,
Petitioner
v.
Data Speed Technology LLC
Patent Owner

IPR2014- _____
Patent 5,867,686
____________
PETITION FOR INTER PARTES REVIEW

Mail Stop PATENT BOARD, PTAB
Commissioner for Patents
P.O. Box 1450
Alexandria, VA 22313-1450

ii
TABLE OF CONTENTS

I. INTRODUCTION ........................................................................................... 1
II. MANDATORY NOTICES ............................................................................. 2
A. Real Party-in-Interest ............................................................................ 2
B. Related Matters ...................................................................................... 4
C. Identification of Lead and Back-Up Counsel........................................ 7
D. Service Information ............................................................................... 7
III. PAYMENT OF FEES ..................................................................................... 7
IV. REQUIREMENTS FOR INTER PARTES REVIEW ...................................... 7
A. Grounds for Standing ............................................................................ 7
B. Statement of Precise Relief Requested (37 C.F.R. 42.22(a))
and Identification of Challenges (37 C.F.R. 42.104(b)) .................... 8
C. How the Construed Claims are Unpatentable under the
Statutory Grounds identified in 37 C.F.R. 42.104(b)(2) and
Supporting Evidence Relied upon to Support the Challenge ................ 8
D. Threshold Showing of Reasonable Likelihood That Petitioner
Would Prevail With Respect To At Least One Challenged
Claim (35 U.S.C. 314(a)) Has Been Met ........................................... 9
V. FACTUAL BACKGROUND .......................................................................... 9
A. Declaration Evidence ............................................................................ 9
B. The State of the Art as of 1992 ........................................................... 10
C. The Challenged 686 Patent ................................................................ 12
D. Prosecution History ............................................................................. 13
VI. CLAIM CONSTRUCTION (37 C.F.R. 42.104(b)(3)) ............................... 15
A. Support for claim construction ............................................................ 17
iii
VII. THE GROUNDS SHOWING THAT PETITIONER HAS A
REASONABLE LIKELIHOOD OF PREVAILING .................................... 20
A. The Prior Art Discloses Each Claimed Feature And One Of
Ordinary Skill Would Be Led To Form This Combination ................ 22
B. The Proposed Combination Renders Obvious Claim 5s
Defining. . . As A Write New Chain Command .............................. 30
C. The Proposed Combination Discloses An Equivalent To Claim
10s Means For Storing Element ......................................................... 31
D. The Prior Art Relied Upon Was Publicly Available Before
November 9, 1992 ............................................................................... 33
E. Claim Chart Demonstrating How The Proposed Combination
Renders Obvious Claims 1-11 Of The 686 Patent ............................. 33
VIII. CONCLUSION .............................................................................................. 54

1

I. INTRODUCTION
Pursuant to the provisions of 35 U.S.C. 311-319, Unified Patents Inc.,
(Unified or Petitioner) hereby petitions the Patent Trial and Appeal Board to
institute inter partes review of claims 1-11 of US Patent No. 5,867,686 to Conner
et al. (the 686 Patent, Ex. 1001).
In short, the 686 Patent is directed to a mass storage device that is shared by
a number of computers. Ex. 1001, Abstract. To prevent conflict issues, the 686
Patent describes a locking scheme. Id. The mass storage device writes its files
such that the boundary location of the most recently stored data serves as the
starting point for a new allocation. Ex. 1001, Cl. 2. Also, when writing data to the
mass storage device, the 686 Patent stores parametric data about that data. Ex.
1001, Cl. 6.
The prior art relied upon hereinwhich was not before the Examiner
demonstrates that such features were well known before Nov. 9, 1992, one year
before the 686 Patents earliest priority date. Three printed publications that
describe the Amoeba system and which date back to as early as 1981 disclose and
render obvious each of the 686 Patents claims. None of the 686 Patents claims
recite anything more than subject matter that was both well-known and obvious to
one of ordinary skill in the art at the time of the invention.
2

II. MANDATORY NOTICES
Pursuant to 37 C.F.R. 42.8(a)(1), Unified Patents provides the following
mandatory disclosures.
A. Real Party-in-Interest
Pursuant to 37 C.F.R. 42.8(b)(1), Petitioner certifies that Unified Patents is
the real party-in-interest, and further certifies that no other party exercised control
or could exercise control over Unified Patents participation in this proceeding, the
filing of this petition, or the conduct of any ensuing trial.
Unified Patents was founded by intellectual property professionals over
concerns with the increasing risk of non-practicing entities (NPEs) asserting poor
quality patents against strategic technologies and industries. The founders thus
created a first-of-its-kind company whose sole purpose is to deter NPE litigation
by protecting technology sectors, like cloud storage, the technology against which
the 686 Patent is being asserted. Companies in a technology sector subscribe to
Unifieds technology specific deterrence, and in turn, Unified performs many
NPE-deterrent activities, such as analyzing the technology sector, monitoring
patent activity (including patent ownership and sales, NPE demand letters and
litigation, and industry companies), conducting prior art research and invalidity
analysis, providing a range of NPE advisory services to its subscribers, sometimes
acquiring patents, and sometimes challenging patents at the United States Patent
3

and Trademark Office (USPTO). Since its founding, Unified is 100% owned by its
employees; subscribers have absolutely no ownership interest.
Unified has sole and absolute discretion over its decision to contest patents
through the USPTOs post-grant proceedings. Should Unified decide to challenge
a patent in a post-grant proceeding, it controls every aspect of such a challenge,
including controlling which patent and claims to challenge, which prior art to apply
and the grounds raised in the challenge, and when to bring any challenge.
Subscribers receive no prior notice of Unifieds patent challenges. After filing a
post-grant proceeding, Unified retains sole and absolute discretion and control over
all strategy decisions (including any decision to continue or terminate Unifieds
participation). Unified is also solely responsible for paying for the preparation,
filing, and prosecution of any post-grant proceeding, including any expenses
associated with the proceeding.
In the instant proceeding, Unified exercised its sole discretion and control in
deciding to file this petition against the 686 patent, including paying for all fees
and expenses. Unified shall exercise sole and absolute control and discretion of
the continued prosecution of this proceeding (including any decision to terminate
Unifieds participation) and shall bear all subsequent costs related to this
proceeding. Unified is therefore the sole real-party-in-interest in this proceeding.

4

B. Related Matters
The 686 Patent has been asserted in many litigations, none of which involve
Unified Patents. Below, Data Speed Technology LLC is referred to as Data
Speed. The following cases are active:

1. Data Speed v. Autodesk Inc., 1-14-cv-00032 DED, filed January 14, 2014
2. Data Speed v. Egnyte Inc., 1-14-cv-00033 (DED, filed Jan. 14, 2014)
3. Data Speed v. Saba Software Inc., 1-14-cv-00037 (DED, filed Jan. 14, 2014)
4. Data Speed v. Perforce Software Inc., 1-14-cv-00036 (DED, filed Jan. 14,
2014)
5. Data Speed v. Wolters Kluwer U.S. Corporation et al, 1-13-cv-01452 (DED,
filed Aug. 17, 2013)
6. Data Speed v. Thomson Reuters Corporation et al, 1-13-cv-01450 (DED,
7. Data Speed v. Document Logistix Ltd. et al, 1-13-cv-01448 (DED, filed
Aug. 17, 2013)
8. Data Speed v. VMware Inc., 1-13-cv-01451 (DED, filed Aug. 17, 2013)
9. Data Speed v Toshiba America Inc., 1-13-cv-01052 (DED, filed June 10,
2013)
10. Data Speed v. Xerox Corporation, 1-13-cv-00624 (DED, filed Apr. 12,
2013)
5

11. Data Speed v. EMC Corporation, 1-13-cv-00616 (DED, filed Apr. 12, 2013)
12. Data Speed v. World Software Corporation, 1-13-cv-00623 (DED, filed Apr.
12, 2013)
13. Data Speed v. LexisNexis Group, 1-13-cv-00619 (DED, filed Apr. 12, 2013)
The following cases have terminated:
1. Data Speed v. Zoho Corporation, 1-13-cv-00625 (DED, filed Apr. 12, 2013)
2. Data Speed v. Open Text Inc., 1-13-cv-00689 (DED, filed Apr. 16, 2013)
3. Data Speed v. Alfresco Software Ltd., et al 1-13-cv-01443 (DED, filed Aug.
17, 2013)
4. Data Speed v. Box Inc., 1-13-cv-01444 (DED, filed Aug. 17, 2013)
5. Data Speed v. Dassault Systemes SolidWorks Corp., 1-13-cv-01447 (DED,
6. Data Speed v. MindJet LLC, 1-14-cv-00035 (DED, filed Jan. 14, 2014)
7. Data Speed v. Intuit Inc., 1-14-cv-00034 (DED, filed Jan. 14, 2014)
8. Alfresco Software, Inc. et al v. Data Speed, 5-14-cv-00227 (CAND, filed
Jan. 15, 2014)
9. VMware, Inc. v. Data Speed, 5-13-cv-03823 (CAND, Aug. 19, 2013)
10. Data Speed v. Fiserv Inc. et al, 1-13-cv-01449 (DED, filed Aug. 17, 2013)
11. Data Speed v. Cincom Systems Inc., 1-13-cv-01446 (DED, filed Aug. 17,
2013)
6

12. Data Speed v. Blackboard, Inc., 1-13-cv-01445 (DED, filed Aug. 17, 2013)
13. Data Speed v. Adobe Systems Inc., 1-13-cv-01049 (DED, filed June 10,
2013)
14. Data Speed v. Canon U.S.A. Inc., 1-13-cv-01050 (DED, filed June 10, 2013)
15. Data Speed v. Fujitsu America Inc., 1-13-cv-01051 (DED, filed June 10,
2013)
16. Data Speed v. SAP America Inc., 1-13-cv-00690 (DED, filed Apr. 16, 2013)
17. Data Speed v. International Business Machines Corporation, 1-13-cv-00618
(DED, filed Apr. 12, 2013)
18. Data Speed v. Novell Inc., 1-13-cv-00621 (DED, filed Apr. 12, 2013)
19. Data Speed v. Oracle Corporation, 1-13-cv-00622 (DED, filed Apr. 12,
2013)
20. Data Speed v. Cisco Systems Inc., 1-13-cv-00615 (DED, filed Apr. 12,
2013)
21. Data Speed v. Microsoft Corporation, 1-13-cv-00620 (DED, filed Apr. 12,
2013)
22. Data Speed v. Hewlett-Packard Company, 1-13-cv-00617 (DED, filed Apr.
12, 2013)

7

C. Identification of Lead and Back-Up Counsel
Pursuant to 37 C.F.R. 42.8(b)(3), Petitioner provides the following
designation of counsel: Lead counsel is Michael L. Kiklis (Reg. No. 38,939) and
back-up counsel is Scott A. McKeown (Reg. No. 42,866).
D. Service Information
Pursuant to 37 C.F.R. 42.8(b)(4), papers concerning this matter should be
served on the following:

Address: Michael L. Kiklis
Oblon Spivak
1940 Duke Street
Alexandria, VA 22314
Email: cpdocketkiklis@oblon.com
Telephone: (703) 413-2707/(703)413-3000 (main)
Fax: (703) 413-2220

III. PAYMENT OF FEES
The undersigned authorizes the Office to charge the required fees as well as
any additional fees that might be due to Deposit Account No. 15-0030.
IV. REQUIREMENTS FOR INTER PARTES REVIEW
As set forth below and pursuant to 37 C.F.R. 42.104, each requirement for
inter partes review of the 686 patent is satisfied.
A. Grounds for Standing
Petitioner certifies pursuant to 37 C.F.R. 42.104(a) that the 686 Patent is
available for inter partes review and that Petitioner is not barred or estopped from
8

requesting inter partes review challenging the patent claims on the grounds
identified herein.
B. Statement of Precise Relief Requested (37 C.F.R. 42.22(a)) and
Identification of Challenges (37 C.F.R. 42.104(b))
Petitioner requests inter partes review and cancellation of claims 1-11 of the
686 patent as being obvious under 35 U.S.C. 103 in view of the following
printed publications, each of which is prior art pursuant to 35 U.S.C. 102(b):
1. An Overview of the Amoeba Distributed Operating System, Andrew S.
Tanenbaum and Sape J. Mullender, SIGOPS Operating Systems Review,
Vol. 15, Issue 3, July 1981, pp. 51-64 (Overview)(Ex. 1002).
2. The Design of a High-Performance File Server, Robbert van Renesse,
Andrew S. Tanenbaum, Annita Wilschut, Proceedings of the International
Conference on Distributed Computing Systems, Newport Beach, CA, June
1989, pp. 22-27 (High Performance)(Ex. 1003).
3. A Comparison of Two Distributed Systems: Amoeba and Sprite, Fred
Douglis, John K. Ousterhout, M. Frans Kaashoek, Andrew S. Tanenbaum,
Computing Systems, Vol. 4, No. 4, Fall 1991, pp. 353-384
(Comparison)(Ex. 1004).
C. How the Construed Claims are Unpatentable under the Statutory
Grounds identified in 37 C.F.R. 42.104(b)(2) and Supporting
Evidence Relied upon to Support the Challenge
9

The challenged claims are to be construed as indicated in Section VI, below.
Pursuant to 37 C.F.R. 42.104(b)(4), an explanation of how the challenged claims
are unpatentable under the statutory grounds identified above, including the
identification of where each element of the claim is found in the prior art, is
provided in Section VII, below, in the form of a claim chart. Pursuant to 37 C.F.R.
42.104(b)(5), the appendix numbers of the supporting evidence relied upon to
support the challenges and the relevance of the evidence to the challenges raised,
including identifying specific portions of the evidence that support the challenges,
are provided in Section VII, below, in the form of a claim chart.
D. Threshold Showing of Reasonable Likelihood That Petitioner
Would Prevail With Respect To At Least One Challenged Claim
(35 U.S.C. 314(a)) Has Been Met
Information presented in this Petition, including the unpatentability ground
detailed in Section VII, below, establishes a reasonable likelihood that Petitioner
will prevail with respect to at least one of the challenged claims. See 35 U.S.C.
314(a). Indeed, that section, supported by the Hutchinson declaration (Ex. 1005)
demonstrates how the challenged claims are obvious in view of the relied upon
prior art.
V. FACTUAL BACKGROUND
A. Declaration Evidence

10

This Petition is supported by the declaration of Professor Norman
Hutchinson, Ph.D. from the University of British Columbia (attached as Ex. 1005).
Dr. Hutchinson offers his opinion with respect to the skill level of one of ordinary
skill in the art (Ex. 1005, 27, 28, and 31), the content and state of the prior art
(Ex. 1005, 29-31), claim construction (Ex. 1005, 14-23), the teachings and
suggestions that one of ordinary skill would understand based on Exs. 1002-1004
(Ex. 1005, pps. 18-54), the reasons for combining the teachings from Exs. 1002-
1004 (Ex, 1005, 35-45), and the manner in which one of ordinary skill would
combine those teachings (Ex. 1005, pps. 18-54). Dr. Hutchinson is an Associate
Professor of Computer Science at the University of British Columbia. He has over
twenty-five years of experience in distributed systems and has written and lectured
extensively on this topic. See Ex. 1005.
This petition is also supported by a declaration from Ms. Jodi Gregory. Ms.
Gregory authenticates Exs. 1002-1004 and testifies that such exhibits were publicly
available before November 9, 1992, one year before the earliest priority date of the
686 Patent. See Ex. 1006.
B. The State of the Art as of 1992

As Dr. Hutchinson explains, the elements of the 686 Patent claims were
well known to those of ordinary skill in the art in the area of networked or
distributed file systems more than one year before the earliest priority date of the
11

686 Patent. By the late 1980s and early 1990s, networks of individual computers
had become pervasive. Many systems were designed and deployed to take
advantage of the trend towards cheaper and more powerful computers that could be
connected to a communication network. Examples include LOCUS at UCLA and
Cedar at XEROX PARC in the early 1980s, the Network File System (NFS)
developed by Sun, the Andrew File System (AFS) developed at CMU, the Sprite
networked operating system developed at UC Berkeley, the Amoeba distributed
operating system developed at the Vrije University in the Netherlands, and many
others. Exs. 1002-1004; Ex. 1005, 29.
Dr. Hutchinson further explains that these networked and distributed
systems included a number of common features. Each computer in the system ran
an independent copy of the operating system and participated with the other
computers in the system via a collection of network protocols. All of the systems
included a network file server, which could be accessed via the network to which
all the computers were connected. These network file servers provided the ability
for individual client computers to share data with other computers by reading and
writing files from the network file server. Each individual system defined its own
protocol for synchronizing two clients that attempted to perform conflicting
operations at the same time. Ex. 1005, 30.
12

Dr. Hutchinson therefore concludes that information storage systems
accessible via a communication network by a collection of client computers were
well known at the time of the 686 Patent. Some of these file servers had protocols
to prevent concurrent write access to shared data (e.g., LOCUS, Andrew,
Amoeba), some did not (e.g., Suns NFS, Sprite). Some required the length of a
newly created file to be specified by the creator (e.g., Amoeba), some did not (e.g.,
Suns NFS, Andrew). Some supported replication of the stored data to increase its
tolerance to faults (e.g., Amoeba, Andrew), some did not (e.g., Suns NFS, Sprite).
Ex. 1005, 31.
The design space for networked information storage systems was well
understood at the time of the 686 Patent, and thus, Dr. Hutchinson states that it
was well within the skill level of one of ordinary skill in the art to mix and match
these various file system features to accomplish a particular design goal or to
accommodate a particular environment. Ex. 1005, 31. One of ordinary skill was
well aware of the design and implementation of distributed file systems, locking
and unlocking of mass storage devices, and commands to read and write to the
mass storage device. Ex. 1005, 27. In fact, one of ordinary skill had reference
implementations of distributed file systems, including Amoeba, at his or her
disposal. Ex. 1005, 50.
C. The Challenged 686 Patent
13

The 686 Patent is directed to a storage device that is shared among a
number of computers (or hosts). Each of the computers may independently read
and write data to the storage device. The system therefore uses a locking
mechanism to prevent conflict issues from arising. Ex. 1001, abstract, 3:14-30; Ex.
1005, at 12.
The storage device stores data by using the end of a previous allocation as
the starting point for the following allocation. Ex. 1001, 3:33-37, 20:14-40, Cl. 2;
Ex 1005 at 13. In addition to the data that the storage device stores, the storage
device may store additional data (parametric data) in a separate area of memory,
known as the key space, that somehow relates to the stored data. Ex. 1001, Cls. 6,
7, and 9. Although recited in the claims, the term parametric data is not found in
the specification.
D. Prosecution History
The original application was filed with a single independent claim:

14

Ex. 1007, at 2. The Examiner applied three references against this claim,
each of which was argued by the applicant as applying to only a single computer
(or host) rather than multiple computers:

Ex. 1007, at 16-17. The Examiner maintained his rejection, and thus, the applicant
filed a file wrapper continuation in which the applicant proposed a set of claims
that attempted to more clearly require the use of multiple computers.
15

Ex. 1007, at 21-22. Of the newly submitted claims, the Examiner allowed
those requiring on-the-fly allocation, together with the other limitations of the
claims (e.g., claims 1 and 10), those requiring the write new chain command
(claim 5), and those requiring parametric data (e.g., claim 6). Ex. 1007, at 31-32.
Had the Examiner known about the existence of those features in distributed
systems, like the Amoeba system, there is no doubt that the Examiner would never
have allowed these claims.
VI. CLAIM CONSTRUCTION (37 C.F.R. 42.104(B)(3))
The 686 Patent has expired, and thus the Boards review of the claims is
similar to that of a district courts review. In re Rambus, Inc., 694 F.3d 42, 46
(Fed. Cir. 2012). The principles set forth by the court in Phillips v. AWH Corp.,
415 F.3d 1303 (Fed. Cir. 2005) should be applied since the expired claims are not
16

subject to amendment. Those principles include: words of a claim are generally
given their ordinary and customary meaning as understood by a person of
ordinary skill in the art in question at the time of the invention, claims must be read
in view of the patents specification, and the patents prosecution history should be
consulted.
The Petitioner proposes a construction for several terms below, based on
their ordinary and customary meaning or the special meaning provided by the 686
Patent. The Petitioner and Dr. Hutchinson utilize the ordinary and customary
meaning for all other claim terms.
Claim Term Proposed construction
Parametric Data (claims 6, 7, and 9) Data about data
Reserved keys space (claims 6, 8, and
9)
Area for storing data
Defining . . . as a write new chain
command (claim 5)
A command that allocates a specified
number of bytes in one area of the
storage system and allocates a
specified number of bytes in another
area of the storage system.
External bus (claim 10) Any form of communication network
for communicating between computer
systems or between a computer system
and a device outside of the computer
system.
Means for storing at least one byte of
data from the requesting computer into
the identified memory space (claim 10)
Invokes 35 U.S.C. 112(6)
Function: storing at least one byte of
data from the requesting computer into
the identified memory space.
17

Structure: software code in the
memory of a computer that, when
executed by the computer processor,
performs a write command by writing
at least one byte of data into the
identified area of memory of the
computer
Descriptive parameter (claim 11) Data that describes other data

A. Support for claim construction
Parametric data: Parametric data does not appear in the specification. It
appears only in claims 6, 7, and 9. Claim 6 recites storing parametric data . . .
about the at least one data byte and claim 7 recites reading parametric data about
the at least one byte. One of ordinary skill in the art would recognize that the
term parametric is being used in a very broad sense to indicate that the
parametric data somehow relates to the at least one byte of data. Ex. 1005, at
15. Consequently, Dr. Hutchinson concludes that one of ordinary skill would
interpret this claim to mean data about data. Id.
Reserved keys space: This term is described in the specification at 8:60-9:4
and in association with a several commands that operate on the keys space, such as
the WRITE KEYS COMMAND (Ex. 1001, 19:15-19:55), WRITE NEW CHAIN
COMMAND (Ex. 1001, 23:18-25:5), and WRITE NEW KEYS COMMAND (Ex.
1001, 25:6-25:62). Ex. 1005, at 17. Although the specification states that keys
18

are normally used to sort data within a database, the specification does not require
the keys space to be used solely for this purpose. Ex. 1001, 25:6-62. In fact, claim
6 requires that parametric data is stored in the reserved keys space. Therefore, Dr.
Hutchinson concludes that one of ordinary skill would understand this term to
mean an area for storing data. Ex. 1005, at 17.
Defining . . . as a write new chain command: This term was defined by the
patent owner and does not have an ordinary or customary meaning. Ex. 1005, at
18. The write new chain command is described in the 686 Patent at 23:18-25:5;
Figs. 41A and 41B, and the encoding of the command is depicted in Fig. 11.
According to the Specification, the write new chain command takes two
parameters: a data size parameter and a key size parameter (Fig. 11, 23:30-43).
The functionality of the write new chain command is to allocate data size bytes
of space in the data area and key size bytes of space in the key area of the
information storage device. The specific encoding of the write new data command
is given in Fig. 11, with 32 bits used for the data size parameter and 20 bits used
for the key size parameter. Dr. Hutchinson concludes that one of ordinary skill
would understand that defining a write access request as a write new chain
command means that the write access request is limited to the functionality and
parameters of the write new chain command, but not its encoding. Ex. 1005, at
18. Specifically, this term should be construed as a command that allocates a
19

specified number of bytes in one area of the storage system and allocates a
specified number of bytes in another area of the storage system. Id.
External Bus: The term external bus does not appear in the 686 Patents
specification, only the claims. Dr. Hutchinson states that one of ordinary skill
understands that a bus in a computer system refers to an internal communication
network through which devices communicate with each other within a computer
system. Ex. 1005, at 19. The addition of the qualifier external requires that the
bus is used to communicate between a computer system and a device that is
external to the computer system. Per Dr. Hutchinson, one of ordinary skill would
view this as including any form of communication network for communicating
between computer systems or between a computer system and a device outside of
the computer system. Id. This includes computer networks as found in the
networked and distributed computer systems as of the time of the patent. Id.
Means for storing: This element is a means-plus-function element and
subject to construction under 35 U.S.C. 112(6). The specification describes that
the specified functionstoring at least one byte of data from the requesting
computer into the identified memory space is performed by the WRITE
MODIFY UNLOCK command (Ex. 1001, at 17:46-18:42), the WRITE DATA
command (Ex. 1001, at 18:45-19:14), and the WRITE ANY command (Ex. 1001,
at 21:60-22:31). Ex. 1005, at 21-22. Based on the functionality of these
20

commands, Dr. Hutchinson concludes that one of ordinary skill would understand
that the structure that corresponds to the claimed function is software code in the
memory of a computer that, when executed by the computer processor, performs a
write command by writing at least one byte of data into the identified area of
memory of the computer. Ex. 1005, 22.
Dr. Hutchinson explains that the means for storing claim element performs
the claimed function in the following way: by receiving three parametersthe
starting address, the length of the data to write and the data itselfand by writing
the data at the starting address. Id. The length of the data is expressed as two
fields: a size field that describes the size of each record to store and a how
many field that specifies how many records, each of the given size, should be
stored. Id. The length of the data is therefore calculated by multiplying the size
field by the how many field. Id. The result of the means for storing claim
element is that data is stored into the memory space. Id.
Descriptive parameter: The word descriptive appears only in claim 11 and
not in the specification. Dr. Hutchinson explains that the ordinary and customary
meaning of this term, as understood by one of ordinary skill in the art, is that the
descriptive parameter refers to data that describes other data. Ex. 1005, 23.
VII. THE GROUNDS SHOWING THAT PETITIONER HAS A
REASONABLE LIKELIHOOD OF PREVAILING

21

Exs. 1002, 1003, and 1004 describe various features of the Amoeba system
that, when combined as one of ordinary skill would do, disclose every element of
the 686 Patent claims. Amoeba is a capability-based distributed operating system
designed on a micro-kernel foundation. Amoebas development started in 1980 at
the Vrije University in the Netherlands under the direction of Andrew S.
Tanenbaum. The goal of the project was to understand how a large number of
processors could be merged into a coherent system for distributed and parallel
computation. A number of file systems were developed for Amoeba over its
lifetime, starting from a simple Flat File Server, and ending with the Bullet File
Server in Amoeba version 5.0. These file systems included a number of features
found in the 686 Patent. See Ex. 1002, pp. 51-55, 59-61; Ex. 1003, pp. 22-26; Ex.
1004, pp. 361-370; Ex. 1005, 32.
The first file server for Amoeba was known as the Flat File Server. It was
originally implemented as a student programming project and provides a basic file
service programming interface. In addition to the normal operations to create,
delete, read and write files, it also includes the capability of locking a file so that
no other user can access the file for the duration of the existence of the lock, and
storing a limited amount of extra information along with the data stored in files.
See Ex. 1002, pp. 59-61; Ex. 1005, 33.
22

Later in the lifetime of the Amoeba project, another version of the file server
evolved. This file server is known as the Bullet File Server, emphasizing one of its
design goals: to achieve as high performance as is possible, given the constraints
of the technology of the time. The Bullet File Server supports the normal
operations to create, destroy, read and write files. Several design decisions were
made by the designers of the Bullet File Server to achieve high performance. The
first of these is to typically only allow files to be modified during the initial period
of their existence; once a file has been committed, it can no longer be modified
by any process, including its creator. The second design decision is that files will
be stored contiguously on disk and in memory. See Ex. 1003, pp. 22-27; Ex. 1004,
pp. 366-370; Ex. 1005, 34.
A. The Prior Art Discloses Each Claimed Feature And One Of
Ordinary Skill Would Be Led To Form This Combination
Dr. Hutchinson uses three published references describing the Amoeba
system in his analysis to demonstrate that the 686 Patent claims would be
considered obvious to one of ordinary skill in the art as of the earliest priority date
of the 686 Patent. He also provides a number of reasons why one of ordinary skill
would combine the three references in the manner that he proposes in his claim
chart. Importantly, all three publications describe the same system, the Amoeba
system, over the first decade of its lifetime from 1981 through 1991. Anyone
23

investigating information storage systems connected to multiple computers who
was aware of the Amoeba system would have been aware of the multiple research
papers that described the system over its lifetime and would have been led to
consider the features described in those papers. The primary architect of the
Amoeba system, Andrew Tanenbaum, is an author on all three papers. Thus,
someone aware of one would be led to find and consider the others. Also, since
the same individual was involved with all three papers, this is strong evidence that
many persons of ordinary skill that were familiar with Dr. Tanenbaums work had
all of the features of Amoeba over its lifetime at his or her immediate disposal. Ex.
1005, 35.
The Amoeba Bullet File Server is described in the Comparison and High
performance papers (Exs. 1003 and 1004). One of ordinary skill would combine
these two references because they describe the same file system. For ease of
reference, the Bullet File Server is sometimes referred to below as a shorthand
reference for Exs. 1003 and 1004. Ex. 1005, 36.
In 37 of his declaration, Dr. Hutchinson describes how the Bullet File
Server, as described in Exs. 1003 and 1004, discloses many of the features of the
686 Patent claims. For example:
a. Exs. 1003 and 1004 describe an information storage system or a
memory mass storage device. The essence of any file server,
24

including the Bullet File Server described in Exs. 1003 and 1004, is
that the server stores information at the request of its clients. See Ex.
1003 p. 22, 23; Ex. 1004 p. 365.
b. Exs. 1003 and 1004 describe an information storage system that can
be accessed by a collection of computers, sometimes called client
computers, each of which operates under an independent operating
system. See Ex. 1004, p. 361, 363.
c. Exs. 1003 and 1004 describe an information storage system that is
connected to the collection of client computers via an external bus or
computer network. Each client computer makes requests of the server
by sending these requests across the computer network. See Ex. 1004,
p. 354, 355, 358.
d. Exs. 1003 and 1004 describe an information storage system that
accepts write access requests from connected computers. The Bullet
File Server calls these requests create-file requests. A create-file
request indicates the length desired for the file. See Ex. 1004, p. 366.
e. Exs.1003 and 1004 describe responding to a write access request by
allocating memory for the exclusive use of the requesting computer
for the duration of the write access request. Only the originally
25

requesting computer may modify the file until the file is committed by
that requesting computer. See Ex. 1003, p. 24; Ex. 1004, p. 366.
f. Exs. 1003 and 1004 describe using the boundary location (the ending
address) of one request as the starting location of a later request. The
server stores each file in a single contiguous region of the disk and
uses a first-fit allocation policy to locate a region of the disk to store
each newly created file. As a result, the ending address of the
immediately previous allocation request will often be used as the
starting address of the following allocation request. See Ex. 1003, p.
22, 24, 25.
g. Exs. 1003 and 1004 describe using a memory map to record the
boundaries of the reserved address spaces. The memory map is called
the inode table, and it records the location and size of each file. This
memory map is updated each time a write access request is processed
by the server. See Ex. 1003, p. 24.
h. Exs. 1003 and 1004 describe allowing a requesting computer to write
data into the space that the server has allocated in response to a write
access request. These write operations store information into the space
that has been previously allocated. See Ex. 1003, p. 22, 24, 25; Ex.
1004, p. 366.
26

The Amoeba Flat File Server is described in the Overview paper, Ex. 1002.
For ease of reference, the term Flat File Server will sometimes be used to refer to
its description in Ex. 1002. The Flat File Server shares many features in common
with the Bullet File Server because both were developed for the same operating
system (Amoeba) and both are built using the same infrastructure (the underlying
Amoeba communication and object access primitives). Thus, the infrastructure
evidence from Ex. 1002 shows the underlying infrastructure for Exs. 1003 and
1004. Ex. 1005, 38.
The Flat File Server is also an information storage system. In addition to the
features of the Bullet File Server, the Flat File Server associates a small amount of
extra data with each file. An example of the use of this extra data is that Directory
servers may use this information to store information needed to recover from lost
or garbled directories. In this situation, the extra data which is associated with a
particular file is data about data (parametric data); data needed to recover from
lost or garbled directories would be data about the directory data stored in the file.
See Ex. 1002, p. 59; Ex. 1005, 38.
The Flat File Server also includes operations to lock, unlock, read, and write
this extra information. See Ex. 1002, p. 60. The Flat File Server and the Bullet File
Server share much infrastructure and overlap in many ways because they share the
27

same lineage, and thus, one of ordinary skill would be led to combine various
features from the Flat File Server with the Bullet File Server. Ex. 1005, 39.
Dr. Hutchinson states that there are many reasons why one of ordinary skill
in the art would be led to combine various features from the Flat File Server (Ex.
1002) with the Bullet File Server of Exs. 1003 and 1004. First, the two file servers
are directed to the same problem space: file servers that are shared by a number of
connected computers in a distributed system. Second, the two file servers are
directed to the same problem: managing the resources of a mass storage device so
that they can be utilized without conflict by multiple hosts connected to a common
bus. Finally, these two systems were implemented on a common underlying
technology foundation. Both used the primitives of the Amoeba system, including
object structure, capabilities, and transport system. As a result, the features of the
two could be easily combined without encountering any incompatible differences
in technology, and one of ordinary skill would be led to consider the features of
each when designing their system based on their own design goals and target
environment. Ex. 1005, 40.
Specifically, Dr. Hutchinson states that one of ordinary skill would combine
the extra data feature of the Flat File Server with the Bullet File Server, because it
provides the ability to store data that could be used for various management
purposes. For example, extra data could be stored by the Directory server so that it
28

could be used to recover from lost or garbled directories, which is the same
purpose for which it is used in the Flat File Server. A Directory server, or any
other client, that used the Bullet File Server would also be subject to failure due to
lost or garbled information, and thus, one of ordinary skill would necessarily be led
to using the extra data feature of the Flat File Server for this purpose. Ex. 1005,
41.
In addition, Dr. Hutchinson states that one skilled in the art would also
recognize the advantages of using extra data to record information about the
contents of the file, and this would serve as yet another reason why one of skill
would combine the Flat File Servers extra data feature with the Bullet File Server.
For example, extra data could be used to store information about which application
created the corresponding file or should be used to edit it, the format of the data
within the file, or what other files are related to the contents of this file. Extra data
could also be used to record information about how the user wants the file
displayed in file listings, or what order to sort the files into when displaying file
listings. The ability to store extra information that a user wants associated with a
file would lead one of ordinary skill to combine this extra data feature from the
Flat File Server with the Bullet File Server. The common infrastructure shared by
the two file servers would further encourage this combination of the extra data
feature of the Flat File Server with the Bullet File Server. Ex. 1005, 42.
29

Dr. Hutchinson also explains that one of ordinary skill in the art who
combined the extra data feature of the Flat File Server with the Bullet File Server
would naturally include all of the operations of the Flat File Server that deal with
extra data so as to be able to manipulate the data: namely, the operations to read,
write, lock, and unlock the extra data. Ex. 1005, 43.
Additionally, Dr. Hutchinson concludes that one of ordinary skill would
seek to combine the Flat File Servers write operation with the Bullet File Server
(as described in Exs. 1003 and 1004) because the Bullet File Server describes a
write capability without providing much detail, and given the shared lineage of the
systems, this would provide a strong suggestion to one of ordinary skill in the art to
use the write capability from its predecessor, the Flat File Server. The Bullet File
Server contained an operation to write data to a newly created file. As stated in the
Comparison paper, A process may create a new file, specifying its initial contents
and receiving a capability for it. It may then modify the contents, (Ex. 1004, p.
366). The operation to modify the contents is not described in detail, but its
existence is required by the ability to modify the contents of a newly created file.
Therefore, one of ordinary skill would naturally look to combining the Flat File
Servers write operation with the Bullet File Server to provide this write operation.
Ex. 1005, 44.
30

Furthermore, Dr. Hutchinson explains that the fact that the Comparison
paper (Ex. 1004) describes a write operation makes it inherent that one was used
that required an indication of the file to be written, the address or offset within the
file at which the data should be placed, the length of the data, and the data itself
because one of ordinary skill would recognize that such parameters are present in
virtually all write operations. Some systems include additional information, but
these four elements are essential for the writing of file data, whether they are
provided explicitly or implicitly. Ex. 1005, 45.
B. The Proposed Combination Renders Obvious Claim 5s
Defining. . . As A Write New Chain Command

As construed above, claim 5s defining . . . as a write new chain command
means a command that allocates a specified number of bytes in one area of the
storage system and allocates a specified number of bytes in another area of the
storage system. The Amoeba references (Exs. 1002, 1003, and 1004) render this
element obvious because when the extra data feature of the Flat File Server is
combined with the Bullet File Server, as discussed above, Dr. Hutchinson explains
that one of ordinary skill would naturally modify the Bullet File Servers create-
file command to allocate memory not only in the data space but also in the extra
data space. One of ordinary skill would do so for efficiency reasons, thus reducing
the number of programming calls that are needed to be made. In fact, the Flat File
31

Servers create command allocates memory in the extra data space, which lends
further support for why one of ordinary skill would form the combination as Dr.
Hutchinson has described. See Ex. 1002, p. 59. Therefore, when the Flat File
Servers extra data feature is combined with the Bullet File Server, one of ordinary
skill would modify the Bullet File Servers create-file command to allocate
memory in both areas. Moreover, it would be an obvious matter of design choice
for the skilled artisan to make the extra data allocation variable length and
controlled by a parameter. Ex. 1005, 46.
C. The Proposed Combination Discloses An Equivalent To Claim
10s Means For Storing Element
In Amoeba, there are write commands that one of ordinary skill in the art
would recognize as being equivalent to the 686 Patents write data commands that
were identified above (section VI supra) as part of the structure of the means for
storing claim element (i.e., the WRITE MODIFY UNLOCK command, the
WRITE DATA command, and the WRITE ANY command). In the Flat File
Server, for example, the write operation stores at least one byte of data from a
requesting computer into the identified memory space, which has been pre-
allocated. See Ex. 1002, pp. 59-61. Therefore, this write command performs the
same function as the means for storing claim element. The parameters for the Flat
File Servers write operation include a file, an offset, and the bytes to be written,
32

and using these parameters, this write operation then stores the specified bytes at
the offset, which is substantially the same way as the means for storing claim
element. Furthermore, the Flat File Servers write operation results in data being
stored into the memory space, which is substantially the same result as the means
for storing claim element. One of ordinary skill would therefore understand that
the Flat File Servers write operation constitutes an equivalent to the means for
storing claim element. Ex. 1005, 47.
Also, in the Bullet File Server, there is a write operation that is used to
modify a files contents after the file has been created and before it is committed.
See Ex. 1004, p. 366. This write operation therefore stores at least one byte of data
into a pre-allocated memory space, and thus performs the same function as the
means for storing claim element. Although not explicitly specified, Dr.
Hutchinson explains that this write operation must inherently receive the data to be
written, identify where it should be stored, as well as indicate the length of that
data, and it then must inherently store the data at the identified location. These
parameters and the way in which they are used are inherently present in the Bullet
File Server because Dr. Hutchinson states that virtually all write commands
include these parameters and then write the identified data at the identified
location. The way the Bullet File Servers write operation works is therefore
substantially the same as the means for storing claim element. The Bullet File
33

Servers write operation results in data being stored in the memory space, which is
substantially the same as the result of the means for storing element. One of
ordinary skill would therefore understand that the Bullet File Servers write
operation constitutes an equivalent to the means for storing claim element. Ex.
1005, 48.
D. The Prior Art Relied Upon Was Publicly Available Before
November 9, 1992

Both Dr. Hutchinson and Jodi Gregory authenticate Exs. 1002, 1003 and
1004, and testify that these exhibits were publicly available before November 9,
1992, which is one year before the earliest priority date of the 686 Patent. Ex.
1005, 49; Ex. 1006, 6-7.
E. Claim Chart Demonstrating How The Proposed Combination
Renders Obvious Claims 1-11 Of The 686 Patent
The following claim chart demonstrates, on a limitation-by-limitation basis,
how all claims of the 686 Patent are rendered obvious by the Bullet File Servers
description in Exs. 1003 and 1004 and the Flat File Servers description in Ex.
1002, under 35 U.S.C. 103. For ease of reference, the claim chart includes letters
for the individual claim elements (e.g., 1a). This claim chart is directly supported
by and substantially the same as Dr. Hutchinsons claim chart in his declaration.
Ex. 1005, pp. 33-54. Text in italics is explanatory testimony from Dr.
34

Hutchinsons corresponding claim chart. Id. All other text below are direct quotes
from Exs. 1002, 1003 and 1004.
Claim
Language
Correspondence to Proposed Combination (Exs. 1002, 1003,
and 1004)
1. A method of
providing
memory access
to a memory
mass storage
device by a
plurality of
computers,
each
functioning
under an
independent
operating
system, such
method
comprising the
steps of:
Amoeba provides memory access to a memory mass storage
device by a plurality of computers, each functioning under
an independent operating system because Amoeba is a
distributed operating system where file storage (a memory
mass storage device) is shared among the client computers
that make up the system. The memory mass storage device in
an Amoeba system is a file server. Every computer in an
Amoeba system runs an independent operating system.
Access to a memory mass storage device by a plurality of
computers
Both Amoeba and Sprite provide a single globally shared,
location-transparent file system. In either system a user can
access any file system object from any location without
being aware of the location of the object. [Ex. 1004, p. 365]
Specialized servers include filing servers such as the Bullet
file server, and the directory server. The directory server is
used in conjunction with the Bullet server. Its function is to
handle naming and protection of Bullet server files and other
objects in a simple, uniform way. Servers manage the
Amoeba objects, that is, they handle the storage and perform
the operations. [Ex. 1003, p. 23]
On one hand there are public services, such as disk service
(reading and writing raw disk blocks), file service (reading
and writing files), directory service (file naming and
directory management), data base service (relation storage
and query processing), time of day, etc. [Ex. 1002, p. 52]
This paper describes the design of a distributed operating
system, Amoeba, intended to control a collection of
35

machines based on the pool-of-processors model. [Ex.
1002, p. 51]
The Amoeba and Sprite projects began with many similar
goals. Both projects recognized the trend towards large
numbers of powerful but inexpensive processors connected
by high-speed networks, and both projects set out to build
operating systems that would enhance the power and
usability of such configurations. Both design teams focused
on two key issues: shared storage and shared processing
power. The first issue was how to implement a distributed
file system that would allow secondary storage to be shared
among all the processors without degrading performance or
forcing users to worry about the distributed nature of the file
system. [Ex. 1004, p. 355]
Each functioning under an independent operating system
Each computer in an Amoeba system runs an operating
system kernel, known as a micro-kernel. Each computer
functions under an independent operating system kernel.
In contrast, Amoeba implements a microkernel, with a
minimal set of services (most importantly, communication
and low-level process management) implemented within the
kernel. Other services, such as the file system and process
placement, are provided by separate processes that may be
accessed directly from anywhere in the system. As a result,
some services that would be provided independently on each
Sprite workstation (such as the time-of-day clock) may be
provided in Amoeba by a single network-wide server. [Ex.
1004, p. 361]
Considering kernel communication in isolation, Amoeba
and Sprite have more in common than not. Both use RPC to
communicate between kernels on different machines. [Ex.
1004, p. 363]
Ex. 1002 calls the operating system the monitor layer, which
is run on each computer.
36

[Ex. 1002, p. 54]
The physical, data link, and monitor layers are part of the
operating system kernel, and cannot be modified by the user.
If special kernel mode/user mode hardware is available, the
monitor should run in kernel mode, whereas the transport
layer and higher software would normally run in user
mode. [Ex. 1002, p. 55]
(a) receiving a
write access
request
identifying a
memory space
from a
requesting
computer of
the plurality of
computers by
the memory
mass storage
device;
The memory mass storage device in the Amoeba distributed
system can receive a write access request identifying a
memory space from any computer in the system. In the
Bullet File Server, a write access request is a create-file
request, which identifies a memory space (the new file to be
created) and the size of the desired file.
The standard Amoeba file server, known as the Bullet
Server emphasizes network transfer speed and simplicity
[van Renesse et al. 1989]. The Bullet Server provides an
immutable file store, which simplifies file replication. The
server's principal operations are read-file, create-file, and
delete-file. A process may create a new file, specifying its
initial contents and receiving a capability for it. It may then
modify the contents, but the file may not be read until it has
been committed. Once the process has committed the file, it
is immediately written through to disk for reliability. (Write-
through may be disabled at the option of the caller, but this
option is rarely used in practice.) At this point, the file may
be read by anyone with the appropriate permission, but may
37

never be modified. The only permissible operations on a
committed file are reading and deletion. [Ex. 1004, p. 366]
(b) granting
access and
reserving the
memory space
for the
exclusive use
of the
requesting
computer and
denying write
access to the
memory space
by any other
computer of
the plurality of
computers for
the duration of
the access
grant to the
requesting
computer; and
The Amoeba Bullet File Server grants access and reserves
the memory space for the exclusive use of the requesting
computer because it denies accesses by any other computer
until the requesting computer indicates the end of its access
grant by committing the newly created file.
A process may create a new file, specifying its initial
contents and receiving a capability for it. It may then modify
the contents, but the file may not be read until it has been
committed. [Ex. 1004, p. 366]
The Bullet interface consist of four functions:
BULLET.CREATE(SERVER, DATA, SIZE, P-FACTOR) -
> CAPABILITY
BULLET.SIZE(CAPABILITY) ->SIZE
BULLET.READ(CAPABILITY, &DATA)
BULLET.DELETE(CAPABILITY)
The BULLET.CREATE function is the only way to store
data on a Bullet server. The SERVER argument specifies
which Bullet server to use. This enables users to use more
that on Bullet server. The DATA and SIZE arguments
describe the contents of the file to be created. A capability
for the file is returned for subsequent usage. [Ex. 1003, p.
24]
(c) receiving a
write access
request and a
required
memory size
from a second
requesting
computer of
the plurality of
computers.
The memory mass storage device in the Amoeba distributed
system can receive a write access request identifying a
required memory size from any computer in the system. In
the Bullet File Server, a write access request is a create-file
request, which identifies a memory space (the new file to be
created) and the size of the desired file.
The standard Amoeba file server, known as the Bullet
Server emphasizes network transfer speed and simplicity
[van Renesse et al. 1989]. The Bullet Server provides an
immutable file store, which simplifies file replication. The
server's principal operations are read-file, create-file, and
delete-file. A process may create a new file, specifying its
38

initial contents and receiving a capability for it. It may then
modify the contents, but the file may not be read until it has
been committed. Once the process has committed the file, it
is immediately written through to disk for reliability. (Write-
through may be disabled at the option of the caller, but this
option is rarely used in practice.) At this point, the file may
be read by anyone with the appropriate permission, but may
never be modified. The only permissible operations on a
committed file are reading and deletion. [Ex. 1004, p. 366]
2. The method
as in claim 1
further
comprising the
step of
retrieving a
boundary
location of a
most recent
new data store
as a starting
point of an
available
memory space
of the required
memory size
specified in the
access request
from the
second
requesting
computer.
The Amoeba Bullet File Server retrieves the boundary
location of a most recent new data store as a starting point
of an available memory space of the required memory size
specified in the access request from the second requesting
computer because the Bullet File Server services allocation
requests (create-file calls) in first-fit order. This means that
the space allocated to satisfy the access request from the
second requesting computer is at the boundary of a previous
request.
The basic idea behind the design of the Bullet File Server is
to do away with the block model. In fact, we have chosen
the extreme, which is to maintain files contiguously
throughout the system. That is, files are contiguously stored
on disk, contiguously cached in RAM, and kept
contiguously in processes memories. [Ex. 1003, p. 22]
Keeping files contiguous (i.e., not splitting them up in
blocks) greatly simplifies file server design. [Ex. 1003, p.
24]
Creating files is much the same as reading files that were
not in the cache. A large enough part of cache memory has
to be allocated to hold the file, after which it can be filled
with data specified by the client. Also, an inode and a free
part in the disk data section have to be allocated. For this we
use a first fit strategy. [Ex. 1003, p. 25]
Because files are stored contiguously on disk, the boundary
location (upper boundary) of one file allocation will be the
lower boundary of another file. The figure below indicates
39

that a second allocation request of the right size will fill a
hole in the current storage allocation. In particular, when
the disk is initially empty, files will be allocated on disk one
immediately after another. Therefore the boundary location
of a most recent new data store will be used as a string point
of an available memory space for the second allocation
request.

[Ex. 1003, p. 25]
3. The method
as in claim 2
further
comprising the
step of
reserving a
memory space
of the required
The Amoeba Bullet File Server reserves a memory space of
the required memory size adjacent to the boundary location
for the exclusive use of the second requesting computer
through the use of its first-fit storage allocation technique.
The request from the second requesting computer is
processed in the same way as the request from the first
requesting computer was described in claim 1. The memory
40

memory size
adjacent the
boundary
location for the
exclusive use
of the second
requesting
computer.
space allocated to satisfy the request is reserved for the
second requesting computer in exactly the same manner as
it was for the first requesting computer.
The basic idea behind the design of the Bullet file server is
to do away with the block model. In fact, we have chosen
the extreme, which is to maintain files contiguously
throughout the system. That is, files are contiguously stored
on disk, contiguously cached in RAM, and kept
contiguously in processes memories. [Ex. 1003, p. 22]
Keeping files contiguous (i.e., not splitting them up in
blocks) greatly simplifies file server design. [Ex. 1003, p.
24]
part in the disk data section have to be allocated. For this we
use a first fit strategy. [Ex. 1003, p. 25]
Because files are stored contiguously on disk, the boundary
location (upper boundary) of one file allocation will be the
lower boundary of another file. The figure below indicates
that a second allocation request of the right size will fill a
hole in the current storage allocation. In particular, when
the disk is initially empty, files will be allocated on disk one
immediately after another. Therefore the boundary location
of a most recent new data store will be used as a string point
of an available memory space for the second allocation
request.

41

4. The method
as in claim 3
further
comprising the
step of
dynamically
adjusting a
memory map
of the memory
mass storage
device based
upon the
reserved
memory space
for the second
computer.
The Amoeba Bullet File Server dynamically adjusts a
memory map of the memory mass storage device based upon
the reserved memory space for the second computer because
the Amoeba Bullet File Server uses a memory map called
the inode table to maintain information about what areas of
the disk have been allocated.
The disk is divided into two sections. The first is the inode
table, each entry of which gives the ownership, location, and
size of one file. The second section contains contiguous
files, along with the gaps between files. [Ex. 1003, p. 24]
The remaining inodes describe files. An inode consist of
four fields:
1) A 6-byte random number that is used for access
protection. It is essentially the key used to decrypt
42

capabilities that are presented to the server.
2) A 2-byte integer that is called the index. The index has no
significance on disk, but is used for cache management and
will be described later.
3) A 4-byte integer specifying the first block of the file on
disk. Files are aligned on blocks (sectors).
4) A 4-byte integer giving the size of the file in bytes.
When the file server starts up, it reads the complete inode
table into the RAM inode table and keeps it there
permanently. By scanning the inodes it can figure out which
parts of disk are free. It uses this information to build a free
list in RAM. Also unused inodes (inodes that are zero-filled)
are maintained in a list. [Ex. 1003, p. 24]
5. The method
as in claim 1
further
comprising the
step of
defining the
write access
request as a
write new
chain
command.
As construed above, one of ordinary skill would understand
that defining a write access request as a write new chain
command means that the write access request is limited to
the functionality and parameters of the write new chain
command as disclosed in the Specification.
In the Bullet File Server, the create command allocates
memory in the data space by allocating a file at a given size
and locking the file so that it cannot be modified by other
computers.
The server's principal operations are read-file, create-file,
and delete-file. A process may create a new file, specifying
its initial contents and receiving a capability for it. It may
then modify the contents, but the file may not be read until it
has been committed. [Ex. 1004, p. 366]
In the Flat File Server, the create command allocates
memory in the extra data space. The following quote shows
that extra data space is allocated and associated with each
file in the Flat File Server. One of ordinary skill would
understand that this extra data space allocation occurred as
part of a create command.
43

Associated with each file is a small amount of extra data,
not part of the file itself. Directory servers, for example,
may use this information to store information needed to
recover from lost or garbled directories. Special commands
are provided to access the extra information. [Ex. 1002, p.
59]
The Flat File Server's primitive operations are as follows:
I. READ(FilePort, offset, bytes) :data
2. WRITE(FilePort, offset, bytes)
3. READEXTRADATA(FilePort) :data
4. WRITEEXTRADATA(FilePort, data)
5. DESTROY(FilePort)
6. STATUS(FilePort) :data
7. LOCK(FilePort, key, mode):SuccessFlag
8. UNLOCK(FilePort, key)
9. RESTRICT(FilePort, NewRights):NewPort
10. RETRACT(FilePort) :NewPort
11. CREATE(AccountPort) : FilePort
12. RECOVER (AccountPort) :data [Ex. 1002, p. 60]

The write command immediately above includes a typo
because it does not specify a parameter that includes the
data to be written. One of ordinary skill in the art would
understand that it must be present.
As a result, the combination of the Flat File Servers extra
data feature with the Bullet File Server would result in a
modified Bullet File Server create command that allocated
memory in both the data space as well as the extra data
space.
See section VII(B) supra for more discussion.
6. A method of
providing
memory access
to a memory
mass storage
device by a
See claim 1 preamble.
44

plurality of
computers,
each
functioning
under an
independent
operating
system, such
method
comprising the
steps of:
(a) receiving a
write access
request
identifying a
memory space
from a first
requesting
computer of
the plurality of
computers by
the memory
mass storage
device;
See claim 1a.
(b) granting
access and
reserving the
memory space
for the
exclusive use
of the first
requesting
computer and
denying write
access to the
memory space
by any other
See claim 1b.

45

computer of
the plurality of
computers for
the duration of
the access
grant to the
first requesting
computer;
(c) transmitting
a write access
request from
the first
requesting
computer to
the memory
mass storage
device
followed by at
least one data
byte;
After performing a create-file operation on the Bullet File
Server, a client computer may transmit a write access
request that transfers at least one data byte. Once the first
computer has sent an initial write access request to reserve
space, after receiving the access grant from the memory
mass storage device, the first computer then proceeds to
write data to the space that it had previously allocated.
(d) writing the
at least one
data byte from
the first
requesting
computer into
the identified
memory space;
and
The Bullet server is an innovative file server that
outperforms traditional file servers like SUNS NFS by
more than a factor of three. It achieves high throughput and
low delay by a radically different software design than
current file servers in use. Instead of storing files as a
sequence of disk blocks, each Bullet server file is stored
contiguously, both on disk and in the servers RAM cache.
[Ex. 1003, p. 22]
Another design choice, which is closely linked to keeping
files contiguous, is to make all files immutable. That is, the
only operations on files are creation, retrieval, and deletion;
there are no update-in-place operations. [Ex. 1003, p. 22]
46

The simple architectural model of the file service is
reflected in its simple interface. Whole file transfer
eliminates the need for relatively complicated interfaces to
access parts of files. Immutability eliminates the need for
separate update operators. Version management is not part
of the file server interface, since it is done by the directory
service [7].
The Bullet interface consist of four functions:
BULLET.CREATE(SERVER, DATA, SIZE, P-FACTOR) -
> CAPABILITY
BULLET.SIZE(CAPABILITY) -> SIZE
BULLET.READ(CAPABILITY, &DATA)
BULLET.DELETE(CAPABILITY) [Ex. 1003, p. 24]
part in the disk data section have to be allocated. [Ex. 1003,
p. 25]
(e) storing
parametric data
from the first
requesting
computer
about the at
least one data
byte in a
reserved keys
space of the
identified
memory space.
The Flat File Server of the Amoeba system stores
parametric data from a requesting computer about the at
least one data byte in a reserved keys space of the identified
memory space. The Flat File Server calls this keys space the
extra data space. The Flat File Server supports operations
to read and write data to this extra data space. This extra
data space may be used to store parametric information
about the information that is stored in the data space of the
file. One suggested use is to store information needed to
recover from lost or garbled data in the file.
As an example of a file server, we consider one whose
concept of a file is a linear sequence of bytes, numbered
from 0 to the length of the file - 1, with operations to read or
write arbitrary bytes, as in UNIX. [Ex. 1002, p. 59]
47

59]
1. READ(FilePort, offset, bytes) :data
7. The method
as in claim 6
further
comprising the
step of reading
the parametric
data about the
at least one
byte by a
fourth
computer of
the plurality of
computers.
The parametric data about the at least one byte may be read
by a fourth computer. The parametric data or key data is
called extra data in the Amoeba Flat File Server.
Operations are provided to read and write this extra data by
any computer.
59]
48

8. The method
as in claim 6
further
comprising the
step of locking
the reserved
keys space of
the memory
map by the
first computer.
The Amoeba Flat File Server supports locking the reserved
keys space of the memory map by the first computer. In the
Amoeba Flat File Server, the LOCK call locks the file so it
does not respond to any commands. Therefore, any
computer other than the one that locked the file will be
prevented from reading or writing file data or key data
(which is called extra data in the Amoeba Flat File Server).
The LOCK and UNLOCK call provide a simple mutual
exclusion mechanism. A user can try to exclude other
readers or writers or both. Once locked, a file does not
respond to commands from ports other than the one that
locked it. [Ex. 1002, p. 60]
9. The method
as in claim 8
further
comprising the
step of
modifying the
parametric data
of the at least
one data byte
of the reserved
keys space of
the memory
space by the
first computer.
The parametric data of the at least one byte of the reserved
keys space of the memory space may be modified by the first
computer. The parametric data or key data is called extra
data in the Amoeba Flat File Server. Operations are
provided to read and write this extra data. If the first
computer has used the LOCK primitive to prevent other
computers from modifying the extra data for this file, the
first computer is still allowed to modify the extra data using
the WRITEEXTRADATA command.
49

10. A
computer
system
comprising:
See claim 1 preamble.
(a) a memory
mass storage
device;
See claim 1a.
(b) a plurality
of computers,
each
functioning
under an
independent
operating
system,
operably
connected to
the memory
mass storage
device through
an external
bus;
See claim 1 preamble and claim 1b.
An external bus includes the computer network used to
connect the plurality of computers to the memory mass
storage device. Amoeba is built on a collection of
processors connected by a local-area network, or external
bus.
The shift from time-sharing computers to collections of
processors connected by a local-area network has motivated
the development of numerous distributed operating systems
[Abrossimov et al. 1989; Cheriton 1988; Mullender et al.
1990; Ousterhout et al. 1988]. This paper compares two
distributed systems, Amoeba [Mullender et al. 1990;
Tanenbaum et al. 1990] and Sprite [Nelson et al. 1988;
Ousterhout et al. 1988], which have taken two substantially
different approaches to building distributed systems. [Ex.
1004, p. 354]
The Amoeba and Sprite projects began with many similar
goals. Both projects recognized the trend towards large
numbers of powerful but inexpensive processors connected
by high-speed networks, and both projects set out to build
operating systems that would enhance the power and
usability of such configurations. [Ex. 1004, p. 355]
Amoeba's system architecture is organized around a
centralized processor pool, as shown in Figure 1. Each "pool
processor" has a network interface and RAM associated
with it, and these processors are dynamically allocated to
processes as they are needed.
50

[Ex. 1004, p. 358]
(c) a
communication
processor of
the memory
mass storage
device
operably
connected to
the plurality of
computers
through the
external bus
for receiving
an access
request from a
requesting
computer of
the plurality of
computers
identifying a
memory space
of the memory
mass storage
device;
In Amoeba, the transport layer is the communication
processor. Its purpose is to send and receive data across the
computer network (external bus) that connects all the
computers to the file server.
In contrast, Amoeba implements a "microkernel," with a
kernel. [Ex. 1004, p. 361]
Both Amoeba and Sprite implement communication
mechanisms to enable processes to communicate with each
other and to hide machine boundaries. Their mechanisms for
doing so, however, are different. Amoeba presents the whole
system as a collection of objects, on each of which a set of
operations can be performed using RPC. [Ex. 1004, p. 363]
The common infrastructure of the Amoeba system underlies
both the Bullet File Server and the Flat File Server.
The function of the transport layer is to offer a simple and
reliable transport service to the higher layers. In order to
allow any process to communicate reliably with any other
process, its protocol, the transport protocol, should be a
system wide convention. [Ex. 1002, p. 55]
See also claim 1a.

51

(d) a controller
of the memory
mass storage
device
operably
connected to
the
communication
processor for
granting
exclusive write
access to the
identified
memory space
by the
requesting
computer for a
duration of the
access grant to
the requesting
computer;
The Amoeba Bullet File Server is the controller of the
memory mass storage device, it is operably connected to the
communication processor (the transport layer), and it
grants exclusive write access to the identified memory space
by the requesting computer for the duration of the access
grant to the requesting computer. The Bullet File Server is
one of the higher layer processes that use the transport
layer for reliable communication with any other process on
any computer.
In contrast, Amoeba implements a "microkernel," with a
kernel. [Ex. 1004, p. 361]
Both Amoeba and Sprite implement communication
mechanisms to enable processes to communicate with each
other and to hide machine boundaries. Their mechanisms for
doing so, however, are different. Amoeba presents the whole
system as a collection of objects, on each of which a set of
operations can be performed using RPC. [Ex. 1004, p. 363]
See also claim 1b.
(e) means for
storing at least
one byte of
data from the
requesting
computer into
the identified
memory space;
and
In the Flat File Server, the write operation stores at least
one byte of data from a requesting computer into the
identified memory space, which has been pre-allocated. The
parameters for the Flat File Servers write operation
include a file, an offset, and the bytes to be written and this
write operation then stores the specified bytes at the offset.
52

Furthermore, the Flat File Servers write operation results
in data being stored into the memory space.
Additionally, in the Bullet File Server, there is a write
operation that is used to modify a files contents after the
file has been created and before it is committed.
Although not explicitly specified, this write operation must
receive the data to be written, identify where it should be
stored, as well as indicate the length of that data, and it then
must store the data at the identified location. These
parameters and the way in which they are used are
necessarily present in the Bullet File Server because
virtually every write command includes these parameters
and then write the identified data at the identified location.
See further discussion in section VII(C) supra.
(f) a dynamic
memory map
containing a
listing of the
identified
memory space.
The dynamic memory map (inode table) of the Amoeba
Bullet File Server contains a listing of the identified memory
space. The Amoeba Bullet File Server uses the inode table to
maintain information about what areas of the disk have been
allocated.
53

See also claim 4.
11. The system
as in claim 10
wherein the
listing of the
identified
memory space
further
comprises a
descriptor
portion
containing at
least one
descriptive
parameter of
the at least one
byte of data.
The listing of the identified memory space (the Bullet File
Servers inode table) comprises a descriptor portion
containing at least one descriptive parameter of the at least
one byte of data. The extra data of the Flat File Server
contains at least one descriptive parameter of the file data.
59]
"12. RECOVER (AccountPort) :data [Ex. 1002, p. 60]
See also claim 6e.
The Bullet File Server contains a memory map in its inode
table (indicating what data is in use for what purposes, and
which is updated by the allocation requests in claim 4). The
Flat File Server includes the extra data capability. The
combination of the Bullet File Server with the Flat File
Servers extra data capability would store the extra data in
some portion of the address space. The location and bounds
of this portion of the address space would need to be
54

described in the memory map of the Bullet File Server,
otherwise it could not be found.

VIII. CONCLUSION
For the reasons set forth above, Petitioner has established a reasonable
likelihood of prevailing with respect to at least one claim of the 686 Patent.
Therefore, Petitioner respectfully requests that the Patent Trial and Appeal Board
institute an inter partes review and then proceed to cancel claims 1-11.
Respectfully submitted,

OBLON SPIVAK

Dated: September 29, 2014 /Michael L. Kiklis/
Michael L. Kiklis
Reg. No. 38,939

Customer Number
22850
Tel. (703) 413-3000
Fax. (703) 413-2220
(OSMMN 02/10)
55

Petitioners Exhibit List (September 29, 2014)

PETITIONERS EXHIBIT LIST
September 29, 2014

Exhibit Description
Ex. 1001 U.S. Patent No. 5,867,686
Ex. 1002 An Overview of the Amoeba Distributed Operating System,
Andrew S. Tanenbaum and Sape J. Mullender. SIGOPS
Operating Systems Review, Vol. 15, Issue 3, July 1981, pp. 51-
64.
Ex. 1003 The Design of a High-Performance File Server, Robbert van
Renesse, Andrew S. Tanenbaum, Annita Wilschut, Proceedings of
the International Conference on Distributed Computing Systems,
Newport Beach, CA, June 1989, pp. 22-27.
Ex. 1004 A Comparison of Two Distributed Systems: Amoeba and Sprite,
Fred Douglis, John K. Ousterhout, M. Frans Kaashoek, Andrew
S. Tanenbaum. Computing Systems, Vol. 4, No. 4, Fall 1991, pp.
353-384.
Ex. 1005 Declaration of Dr. Norman Hutchinson in support of the Petition.
Ex. 1006 Declaration of Jodi Gregory in support of the Petition.
Ex. 1007 Selected pages from the prosecution history of US. Patent. No.
5,867,686

CERTIFICATE OF SERVICE
The undersigned certifies service pursuant to 37 C.F.R. 42.6(e) and
42.105(b) on the Patent Owner by UPS Next Day Air of a copy of this Petition for
Inter Partes Review and supporting materials at the correspondence address of
record for the 686 patent as well as the address of litigation counsel of record:
Daniel Mitry
212 East 47
th
Street #24J
New York, NY 10017

Stephen B. Brauerman
Bayard, P.A.
222 Delaware Avenue, Suite 900
P.O. Box 25130
Wilmington, DE 19899

Dated: September 29, 2014 By: /Michael L. Kiklis/
Michael L. Kiklis
Reg. No. 38,939

Petition For Inter Partes Review

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Petition For Inter Partes Review

Hochgeladen von

Copyright:

Verfügbare Formate

UNITED STATES PATENT AND TRADEMARK OFFICE

Das könnte Ihnen auch gefallen