310083
DESCRIPTION
Unified's IPR against Data SpeedTRANSCRIPT
-
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,
filed Aug. 17, 2013)
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,
filed Aug. 17, 2013)
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.
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]
(d) writing the at least one data byte from the first requesting computer into the identified memory space; and
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 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.
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: 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.
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]
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.
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]
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.
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: 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