`
`
`DECLARATION OF DR. NORMAN HUTCHINSON, Ph.D.
`
`
`I, Dr. Norman Hutchinson, Ph.D., declare as follows:
`
`
`
`(1.)
`
`I am currently a Professor of Computer Science at the
`
`University of British Columbia in the Faculty of Science, where I have
`
`worked since 1991. Previously I was a Professor of Computer Science at the
`
`University of Arizona.
`
`(2.)
`
`For more than 30 years, I have studied, designed, and worked in
`
`the field of computer science. My experience includes more than 25 years
`
`of teaching and research, with research interests including distributed
`
`systems, programming languages and compilers for distributed systems, file
`
`systems, network protocols, and operating systems.
`
`(3.)
`
`I received a Bachelor of Science (Honors) degree in Computer
`
`Science from the University of Calgary in 1982, a Master of Science degree
`
`in Computer Science from the University of Washington in 1985, and a
`
`Doctor of Philosophy degree in Computer Science from the University of
`
`Washington in 1987.
`
`(4.)
`
`Over the last three decades, I have architected, developed, and
`
`evaluated a large number of operating systems and distributed systems:
`
`Eden and Emerald at the University of Washington; the x-kernel at the
`
`
`
`1
`
`Unified Patents Inc., Exhibit 1005, pg. 1
`
`
`
`University of Arizona; Elephant, Kea, Tui, Mammoth, Remus, Parallax,
`
`Capo, DOHA and others at the University of British Columbia. These
`
`systems have included object-oriented systems and languages for distributed
`
`systems (Eden and Emerald), operating systems (x-kernel and Kea), file
`
`systems (Elephant, Mammoth, Parallax, Capo), process migration systems
`
`(Emerald and Tui), systems for high availability (Remus) and browser based
`
`middleware for interactive applications (DOHA).
`
`(5.)
`
`In 2001 I co-founded Silicon Chalk, Inc., which developed
`
`distributed software to enhance the utility of laptops in the classroom. This
`
`software included the ability to share information from the instructor to the
`
`students, from the students back to the instructor, and directly between
`
`students, including replication of both control information and instructional
`
`content. I served as Silicon Chalk’s Chief Technical Officer until 2005
`
`when it was abandoned.
`
`(6.)
`
`I have served on the Program Committees for over a dozen
`
`scientific conferences and symposiums covering the fields of distributed
`
`computing, operating systems, object-oriented programming and
`
`architecture. I have been a reviewer for more than 40 journals and funding
`
`agencies in computer science.
`
`
`
`2
`
`Unified Patents Inc., Exhibit 1005, pg. 2
`
`
`
`(7.)
`
`I have supervised 12 Ph.D. students in Computer Science, and
`
`an additional 45 M.Sc. students. I have taught undergraduate and graduate
`
`courses for more than 25 years in programming, programming languages,
`
`compilers, operating systems, distributed systems, and networking. Overall
`
`I have contributed to the education of more than 2,200 students.
`
`(8.)
`
`I am the author or co-author of over 60 journal and conference
`
`publications. Many of these publications describe distributed computing
`
`systems, some of which are directed specifically to client-server interaction
`
`and storage systems. Below is a list of my publications that are particularly
`
`relevant to the above topics:
`
` A. Black, N.C. Hutchinson, E. Jul, H. Levy and L. Carter,
`“Distribution and abstract types in Emerald”, IEEE Transactions on
`Software Engineering, 13(1):65-76, January 1987.
`
` E. Jul, H.M. Levy, N.C. Hutchinson and A.P. Black, “Fine-grained
`mobility in the Emerald system”, ACM Transactions on Computer
`Systems, 6(1):109-133, February 1988.
`
` A. Black, N.C. Hutchinson, E. Jul and H. Levy, “Object structure in
`the Emerald system”. In Proceedings of the ACM Conference on
`Object-Oriented Programming Systems, Languages and Applications,
`pp. 78-86, ACM October 1986.
`
` L.L. Peterson, N.C. Hutchinson, S.W. O'Malley and H.C. Rao, “The
`x-kernel: A platform for accessing internet resources'', IEEE
`Computer, 23(5), May 1990.
`
` Alistair Veitch and Norman C. Hutchinson, “Kea - A Dynamically
`Extensible and Configurable Operating System Kernel”, Proceedings
`of the Third International Conference on Configurable Distributed
`
`
`
`3
`
`Unified Patents Inc., Exhibit 1005, pg. 3
`
`
`
`Systems, pp. 123-129, Annapolis Maryland, May 1996.
`
` Norman C. Hutchinson, Stephen Manley, Michael Federwisch, Guy
`Harris, Dave Hitz, Steven Kleiman and Sean O'Malley, “Logical vs.
`Physical File System Backup''. Proceedings of the Third Usenix
`Symposium on Operating System Design and Implementation, pp.
`239--249, February, 1999.
`
` Douglas J. Santry, Michael J. Feeley, Norman C. Hutchinson and
`Alistair C. Veitch, “Elephant: The File System That Never Forgets”.
`Proceedings of the Seventh Workshop on Hot Topics in Operating
`Systems, Rio Rico, Arizona, March 1999, pp. 2--7.
`
` Douglas J. Santry, Michael J. Feeley, Norman C. Hutchinson, Alistair
`C. Veitch, Ross W. Carton, and Jacob Ofir, “Deciding when to forget
`in the Elephant file system”. Proceedings of the Seventeenth ACM
`Symposium on Operating Systems Principles, Kiawah Island, SC,
`December 1999, pp. 110--123.
`
` Peter Smith and Norman C. Hutchinson, “Heterogeneous Process
`Migration: The Tui System”. Software – Practice and Experience,
`28(6), pp. 611--639, May, 1998.
`
` D. Makaroff, Norman C. Hutchinson, “Development and Evolution of
`a Heterogeneous Continuous Media Server: a case study”. Journal
`of Software Maintenance and Evolution: Research and Practice,
`17(2), pp. 143--167, Apr 2005.
`
` Dmitry Brodsky, Michael J. Feeley and Hutchinson, Norman C.,
`“Topology Sensitive Replica Selection”, Proceedings of the 25th
`Symposium on Reliable Distributed Systems, Leeds, UK, October
`2006, pp. 18-28.
`
` Dutch T. Meyer, Gitika Aggarwal, Brendan Cully, Geoffrey Lefebvre,
`Michael J. Feeley, Norman C. Hutchinson and Andrew Warfield,
`“Parallax: Virtual Disks for Virtual Machines”, Proceedings of the
`Third EuroSys Conference (EuroSys '08), Glasgow, Scotland, April
`2008, pp. 41-54.
`
`
`
`
`4
`
`Unified Patents Inc., Exhibit 1005, pg. 4
`
`
`
` Brendan Cully, Geoffrey Lefebvre, Dutch Meyer, Mike Feeley,
`Norman C. Hutchinson, Andrew Warfield, “Remus: High Availability
`via Asynchronous Virtual Machine Replication”, Proceedings of the
`Fifth USENIX Symposium on Networked Systems Design and
`Implementation, San Francisco, CA, April 2008, pp. 161-174.
`
`
`(9.)
`
`I am a member of several professional organizations for
`
`
`
`Computer Scientists, including the Association of Computing Machinery
`
`(ACM) and the Institute of Electrical and Electronics Engineers (IEEE).
`
`(10.)
`
`A copy of my curriculum vitae, which describes in further
`
`detail my qualifications, responsibilities, employment history, honors,
`
`awards, professional associations, invited presentations, and publications is
`
`attached to this declaration.
`
`(11.)
`
`I have reviewed United States Patent No. 5,867,6861 (“the ‘686
`
`Patent,” Ex. 1001) to Kenneth K. Connor et al., the file history of the ‘686
`
`Patent, as well as the patents and applications referenced in the section of the
`
`‘686 Patent entitled “Related U.S. Application Data.” I have also reviewed
`
`the publications cited in the footnotes of this declaration and referenced in
`
`the inter partes review petition submitted herewith.
`
`
`
`
`
`
`
`1 Connor, K.H., Hunter, J.G., Spar, G.P., Anderson, B., “High Speed Real-
`Time Information Storage System.” U.S. Patent No. 5,867,686, filed
`November 8, 1995, claiming priority to November 9, 1993 (Ex. 1001).
`5
`
`
`
`Unified Patents Inc., Exhibit 1005, pg. 5
`
`
`
`Summary of the ‘686 Patent
`
`(12.)
`
`The ‘686 Patent describes an information storage system that is
`
`shared among a number of client computers,2 each of which runs their own
`
`copy of an operating system. The storage server allows connected hosts to
`
`read and write data from the server, and includes a component that locks a
`
`portion of the address space for the exclusive use of an individual writing
`
`client.3 By providing a command system for reserving storage space, the
`
`information storage system can be used by multiple hosts connected to a
`
`common bus without conflict.
`
`(13.)
`
` The claims of the ‘686 Patent discuss:
`
`A command to reserve space to a particular caller, such reserved space
`
`being writable only by the reserving caller until the reserving caller
`
`releases a lock which the storage system granted it when the space was
`
`reserved.4
`
`Managing space in the storage system by using the end of a previous
`
`allocation as the starting point of the following allocation.5 This storage
`
`management technique is known by a number of different names in the
`
`
`
`2 Ex. 1001, 1:9-18.
`3 Ex. 1001, 3:13-28.
`4 Ex. 1001, 3:13-28, 42:66-43:14.
`5 Ex. 1001, 3:33-37, 20:14-40, 43:14-23.
`6
`
`
`
`Unified Patents Inc., Exhibit 1005, pg. 6
`
`
`
`computing literature, including log-structured storage, extent-based
`
`storage, and a first-fit storage management policy.
`
`Writing what the patent claims call “parametric data” about the data
`
`that has been stored in the storage system. The specification of the patent
`
`does not describe this parametric data, however the claims indicate that
`
`the parametric data is stored in the key space of the information storage
`
`system, which is described in the specification.6 From claim 6 we can
`
`infer that the parametric data is provided by the same client that made the
`
`original allocation request and that the parametric data is somehow
`
`“about the at least one data byte” for which the original allocation was
`
`performed.7
`
`CLAIM INTERPRETATION
`
`(14.)
`
`I understand that the ‘686 Patent has expired. I further
`
`understand that in an inter partes review of an expired patent, words of a
`
`claim “are generally given their ordinary and customary meaning” as
`
`understood by a person of ordinary skill in the art at the time of the
`
`invention. I also understand that claims must be read in view of the patent’s
`
`specification, at least in part because the specification may reveal that the
`
`patentee served as his own lexicographer. Further, the patent’s prosecution
`
`
`
`6 Ex. 1001, 13:30-35, 19:15-20, 19:38-55.
`7 Ex. 1001, 43:30-44:6.
`
`
`
`7
`
`Unified Patents Inc., Exhibit 1005, pg. 7
`
`
`
`history should be considered. In comparing the claims of the ‘686 Patent to
`
`the known prior art, I have carefully considered the ‘686 Patent’s claims,
`
`‘686 Patent’s specification, and the ‘686 Patent’s file history in view of my
`
`experience and knowledge in the relevant field. In my opinion, most of the
`
`claim terms of the ‘686 Patent are used in their ordinary and customary
`
`sense as one skilled in the relevant field would understand them. However,
`
`there are some terms that do not have an ordinary and customary meaning
`
`because they are unique to the ‘686 Patent. There are a number of terms used
`
`in the claims that deserve some discussion in this context, and I discuss them
`
`below.
`
`(15.)
`
`Parametric data (claims 6, 7 and 9)
`
`The term parametric data does not appear in the specification of the ‘686
`
`Patent and only appears in claims 6, 7, and 9. Nevertheless, from the context
`
`in which it is used in the claims, I believe that one of ordinary skill in the art
`
`would interpret this term to mean merely “data about data.” One of ordinary
`
`skill would recognize that the term “parametric” is being used in a very
`
`broad sense here to indicate that the parametric data somehow relates to the
`
`“at least one data byte.” For example, claim 6 states: “storing parametric
`
`data . . . about the at least one data byte” and claim 7 states: “reading
`
`
`
`8
`
`Unified Patents Inc., Exhibit 1005, pg. 8
`
`
`
`parametric data about the at least one byte.” I have assumed this meaning of
`
`the term in my analysis.
`
`(16.)
`
`Although not part of the definition of “parametric data,” I will
`
`nevertheless note that the context of claim 6 further indicates that the
`
`parametric data is provided to the memory mass storage device or
`
`information storage system by the same requesting computer that makes the
`
`initial write access request, and refers to the parametric data being stored in
`
`the key space of the information storage system (see claim 6: “storing
`
`parametric data . . . in a reserved keys space).
`
`(17.)
`
`Reserved keys space (claims 6, 8, and 9)
`
`The keys space is described in the Specification at 8:60-9:4, and in
`
`association with a number of commands that operate on the keys space (e.g.,
`
`the WRITE KEYS COMMAND 19:15-19:55, WRITE NEW CHAIN
`
`COMMAND 23:18-25:5, and WRITE NEW KEYS COMMAND 25:6-
`
`25:62). The Specification states that keys are normally used to sort the data
`
`within the database, but does not require that the key space be used solely
`
`for keys (‘686 Patent at 25:6-62). Instead, claim 6 indicates that parametric
`
`data, which I have previously stated would be understood by one skilled in
`
`the art to mean data about data, is stored in the reserved keys space.
`
`Therefore I believe that one skilled in the art would understand the reserved
`
`
`
`9
`
`Unified Patents Inc., Exhibit 1005, pg. 9
`
`
`
`keys space to be an area for storing data. I have assumed this meaning of the
`
`term in my analysis.
`
`(18.)
`
`Defining … as a write new chain command (claim 5)
`
`This phrase appears in claim 5 where it further qualifies the write access
`
`request that appears in claim 1. The term “write new chain command” is
`
`unique to the ‘686 Patent and does not have an ordinary or customary
`
`meaning in the industry. Rather, this term was defined by the Patent Owner.
`
`The write new chain command is described 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. 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.
`
`Specifically, this term should be construed as a command that allocates a
`
`
`
`10
`
`Unified Patents Inc., Exhibit 1005, pg. 10
`
`
`
`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. I have
`
`assumed this meaning of the term in my analysis.
`
`(19.)
`
`External bus (claim 10)
`
`I note that the term “external bus” does not appear in the ‘686 Patent’s
`
`specification, only the claims. A bus in a computer system normally refers
`
`to an internal communication network through which devices communicate
`
`with each other within a computer system. The addition of the qualifier
`
`“external” implies that the bus is used to communicate between a computer
`
`system and a device that is external to, meaning not contained inside of, the
`
`computer system. 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. This includes computer networks as found in the networked and
`
`distributed computer systems as of the time of the patent. I have assumed
`
`this meaning of the term in my analysis.
`
`(20.) Means for storing at least one byte of data from the requesting
`
`computer into the identified memory space (claim 10)
`
`This element is found in claim 10, and I have been informed that it is known
`
`as a “means-plus-function” claim element in which a function is specified
`
`
`
`11
`
`Unified Patents Inc., Exhibit 1005, pg. 11
`
`
`
`without the corresponding structure. I have been informed that means-plus-
`
`function claim elements are interpreted as covering the structure described in
`
`the specification for performing the specified function as well as equivalents
`
`thereof. I therefore reviewed the ‘686 Patent to identify the structure that
`
`corresponds to the specified function: “storing at least one byte of data from
`
`the requesting computer into the identified memory space.” I note that the
`
`function states “the identified memory space” and refers back to the
`
`“communication processor” element, where an access request is received
`
`“identifying a memory space.” I therefore interpret this claim element to
`
`mean that “the identified memory space” must have been pre-allocated.
`
`This function is performed in the patent by the WRITE MODIFY UNLOCK
`
`command (described in the Specification at 17:46 – 18:42), the WRITE
`
`DATA command (described in the Specification at 18:45 – 19:14), and the
`
`WRITE ANY command (described in the Specification at 21:60 – 22:31).
`
`(21.)
`
`Based on the functionality of these commands, 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. I have
`
`assumed this structural definition in my analysis.
`
`
`
`12
`
`Unified Patents Inc., Exhibit 1005, pg. 12
`
`
`
`(22.)
`
`I have been informed that in order to constitute a structural
`
`“equivalent,” the prior art feature must perform the same functionality in
`
`substantially the same way to produce substantially the same result. The
`
`‘686 Patent’s write data commands that I identify for the “means for storing”
`
`claim element perform the claimed function in the following way: by
`
`receiving three parameters–the starting address, the length of the data to
`
`write and the data itself–and by writing the data at the starting address. 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. The length of the data is
`
`therefore calculated by multiplying the size field by the how many field.
`
`The result of the means for storing claim element is that data is stored into
`
`the memory space.
`
`(23.)
`
`Descriptive parameter (claim 11)
`
`The word “descriptive” appears only in claim 11, and not in the
`
`specification. I have therefore used the ordinary and customary meaning of
`
`this term as understood by one of ordinary skill in the art, which is that the
`
`descriptive parameter refers to data that describes other data.
`
`ANTICIPATION
`
`
`
`13
`
`Unified Patents Inc., Exhibit 1005, pg. 13
`
`
`
`(24.)
`
`I have been informed that claims may be found invalid as
`
`anticipated. I understand this to mean that a claim is invalid if there is a
`
`single prior art reference that discloses each limitation of the claim either
`
`expressly or inherently.
`
`INHERENCY
`
`(25.)
`
`I understand a limitation to be inherently disclosed in a prior art
`
`reference if it is necessarily present in the reference.
`
`OBVIOUSNESS
`
`(26.)
`
`I have been informed that a patent claim can be found
`
`unpatentable as obvious where the differences between the subject matter
`
`sought to be patented and the prior art are such that the subject matter as a
`
`whole would have been obvious at the time the invention was made to a
`
`person having ordinary skill in the relevant field. I understand that an
`
`obviousness analysis involves a consideration of (1) the scope and content of
`
`the prior art; (2) the differences between the claimed invention and the prior
`
`art; (3) the level of ordinary skill in the pertinent field; and (4) secondary
`
`considerations of non-obviousness.
`
`ONE OF ORDINARY SKILL IN THE ART
`
`(27.)
`
`I have been informed that “a person of ordinary skill in the
`
`relevant field” is a hypothetical person to whom an expert in the relevant
`
`
`
`14
`
`Unified Patents Inc., Exhibit 1005, pg. 14
`
`
`
`field could assign a routine task with reasonable confidence that the task
`
`would be successfully carried out. I have been informed that the level of
`
`skill in the art is evidenced by the prior art references. The prior art
`
`discussed herein demonstrates that a person of ordinary skill in the field, at
`
`the time of the ‘686 Patent’s earliest priority date, 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.
`
`(28.)
`
`Based on my experience I have an understanding of the
`
`capabilities of a person of ordinary skill in the relevant field. I have
`
`supervised and directed many such persons over the course of my career.
`
`Further, I had those capabilities myself at the time the ‘686 Patent was filed.
`
`STATE OF THE ART AS OF 1992
`
`(29.)
`
`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 ‘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
`
`
`
`15
`
`Unified Patents Inc., Exhibit 1005, pg. 15
`
`
`
`LOCUS8 at UCLA and Cedar9 at XEROX PARC in the early 1980s, the
`Network File System (NFS)10 developed by Sun, the Andrew File System
`(AFS)11 developed at CMU, the Sprite12 networked operating system
`developed at UC Berkeley, the Amoeba13 distributed operating system
`
`developed at the Vrije University in the Netherlands, and many others.
`
`(30.)
`
`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 listed above
`
`included a network file server, which could be accessed via the network to
`
`
`
`which all the computers were connected. These network file servers
`
`8 The LOCUS distributed operating system, Bruce Walker, Gerald Popek,
`Robert English, Charles Kine, Greg Thiel. SOSP '83 Proceedings of the
`ninth ACM symposium on Operating systems principles, pp. 49-70
`9 The Cedar Programming Environment: A Midterm Report and
`Examination, Warren Teitelman, CSL-83-11, June 1984.
`10 The Sun Network File System: Design, Implementation, and Experience.
`Russel Sandberg, Proceedings of the Summer 1986 USENIX Technical
`Conference, 1986.
`11 Scale and Performance in a Distributed File System, Howard, J.H., Kazar,
`M.L., Nichols, S.G., Nichols, D.A., Satyanarayanan, M., Sidebotham, R.N.,
`& West, M.J. (February 1988). ACM Transactions on Computer Systems 6
`(1): 51–81.
`12 The Sprite Network Operating System, John K. Ousterhout, Andrew R.
`Cherenson, Frederick Douglis, Michael N. Nelson, and Brent B. Welch.
`IEEE Computer, February 1988, pp. 23-36.
`13 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.
`16
`
`
`
`Unified Patents Inc., Exhibit 1005, pg. 16
`
`
`
`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.
`
`(31.)
`
`From this we can see 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. The file servers included in
`
`the systems identified above demonstrate a wide range of design choices.
`
`Some file servers had protocols to prevent concurrent write access to shared
`
`data (e.g., LOCUS, Andrew, Amoeba), some did not (e.g., Sun’s 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., Sun’s NFS, Andrew). Some
`
`supported replication of the stored data to increase its tolerance to faults
`
`(e.g., Amoeba, Andrew), some did not (e.g., Sun’s NFS, Sprite). The design
`
`space for networked information storage systems was well understood at the
`
`time of the ‘686 Patent, and thus, it was well within the skill level of one of
`
`ordinary skill to mix and match these various file system features to
`
`accomplish a particular design goal or to accommodate a particular
`
`environment.
`
`
`
`
`
`17
`
`Unified Patents Inc., Exhibit 1005, pg. 17
`
`
`
`THE AMOEBA DISTRIBUTED OPERATING SYSTEM
`
`(32.)
`
`I have used three published research papers that describe the
`
`Amoeba system in my declaration, which I hereafter designate as
`
`Overview,14 High performance,15 and Comparison.16 The file systems
`
`included in the Amoeba distributed operating system are particularly
`
`relevant to the technology of the ‘686 Patent. In fact, they share every
`
`feature of the ‘686 Patent claims. Amoeba is a capability-based distributed
`
`operating system designed on a micro-kernel foundation. Amoeba’s
`
`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
`
`
`
`14 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. 1002).
`15 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. 1003).
`16 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. 1004).
`18
`
`
`
`Unified Patents Inc., Exhibit 1005, pg. 18
`
`
`
`Patent. See Ex. 1002, pp. 51-55, 59-61, Ex. 1003, pp. 22-26, Ex. 1004, pp.
`
`361-370.
`
`(33.)
`
`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.
`
`(34.)
`
`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 which is 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 taken 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
`
`
`
`19
`
`Unified Patents Inc., Exhibit 1005, pg. 19
`
`
`
`contiguously on disk and in memory. See Ex. 1003, pp. 22-27, Ex. 1004, pp.
`
`366-370.
`
`REASONS TO COMBINE
`
`(35.)
`
`I have used three published references describing the Amoeba
`
`system in my analysis to demonstrate that the ‘686 Patent claims are obvious
`
`to one of ordinary skill in the art as of the earliest priority date of the ‘686
`
`Patent. All three of these publications describe the same system, the Amoeba
`
`system, over the first decade of its lifetime from 1981 through 1991. Anyone
`
`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 of these research papers so someone aware of one of them would
`
`would be led to find the others, in fact the third published paper
`
`(Comparison17) explicitly references the second one (High performance18).
`
`
`
`17 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. 1004).
`18 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. 1003).
`
`
`
`20
`
`Unified Patents Inc., Exhibit 1005, pg. 20
`
`
`
`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. Tanenbaum’s work had all of the features of Amoeba over its lifetime at
`
`his or her disposal.
`
`(36.)
`
`The Amoeba Bullet File Server is described in the Comparison
`
`(Ex. 1004) and High performance papers (Ex. 1003). One of ordinary skill
`
`would combine these two references because they describe the same file
`
`system. For ease of reference, I will simply refer to the Bullet File Server
`
`below, even though I am referring to the Comparison and High performance
`
`papers.
`
`(37.)
`
`The Bullet File Server discloses many of the features of the
`
`‘686 Patent claims. For example:
`
`a. It is an information storage system or a memory mass storage
`
`device. The essence of any file server, including the Bullet File
`
`Server, is that the server stores information at the request of its
`
`clients. See Ex. 1003 p. 22, 23, Ex. 1004 p. 365.
`
`b. It can be accessed by a collection of computers, normally called
`
`client computers, each of which operates under an independent
`
`operating system. See Ex. 1004, p. 361, 363.
`
`
`
`21
`
`Unified Patents Inc., Exhibit 1005, pg. 21
`
`
`
`c. It 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. It accepts write access requests from connected computers. The
`
`Bullet File Server calls these create-file requests. A create-file
`
`request indicates the length desired for the file. See Ex. 1004,
`
`p. 366.
`
`e. It responds 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 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. It uses 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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
