310083

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: [email protected] 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]

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 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]

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. [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]

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

47

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: 1. 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]

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.


The Flat File Server's primitive operations are as follows: 1. 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

48

10. RETRACT(FilePort) :NewPort 11. CREATE(AccountPort) : FilePort 12. RECOVER (AccountPort) :data [Ex. 1002, p. 60]

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.

The Flat File Server's primitive operations are as follows: 1. 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]

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 minimal set of services (most importantly, communication and low-level process management) implemented within the 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 minimal set of services (most importantly, communication and low-level process management) implemented within the 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.

The Flat File Server's primitive operations are as follows: 1. 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

52

10. RETRACT(FilePort) :NewPort 11. CREATE(AccountPort) : FilePort 12. RECOVER (AccountPort) :data [Ex. 1002, p. 60]

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.

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

53

files, along with the gaps between files. [Ex. 1003, p. 24]

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.


The Flat File Server's primitive operations are as follows: 1. 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]

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.

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]

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 47th 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

310083

Documents

claim construction

challenged claim

patent trial

obvious claim

united states patent

claim chart demonstra

proposed combination

prior art