IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In the Inter Partes Review of:
`
`Trial Number: To Be Assigned
`
`
`
`U.S. Patent No. 8,478,799
`
`Filed: June 25, 2010
`
`Issued: July 2, 2013
`
`Inventor(s): Arthur J. Beaverson, Paul
`Bowden
`
`Assignee: Hewlett Packard Enterprise
`Development, LP
`
`
`
`
`
`
`
`
`
`
`
`Title: Namespace File System
`Accessing an Object Store
`
`Mail Stop Inter Partes Review
`Commissioner for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`Panel: To Be Assigned
`
`
`
`
`
`
`
`
`
`DECLARATION OF PRASHANT SHENOY, PhD, UNDER
`37 C.F.R. § 1.68 IN SUPPORT OF PETITION FOR
`INTER PARTES REVIEW OF U.S. PATENT NO. 8,478,799
`
`
`
`
`1
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`TABLE OF CONTENTS
`
`
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 4
`
`Background and Qualifications ....................................................................... 6
`
`III. Understanding of Patent Law .......................................................................... 8
`
`IV. Background OF Technology ......................................................................... 11
`
`A. Computer Storage Systems, and Their Evolution.................................. 11
`
`B. Cryptographic Hash ............................................................................... 20
`
`V.
`
`’799 Patent ..................................................................................................... 22
`
`A. Background of the ’799 Patent .............................................................. 22
`
`B. Summary of the ’799 Patent .................................................................. 22
`
`C. Prosecution History of the ’799 Patent .................................................. 29
`
`D. Other IPR Proceedings Against ’799 Patent .......................................... 32
`
`E. Representative Claim ............................................................................. 33
`
`VI. Level of Ordinary Skill in the Pertinent Art .................................................. 34
`
`VII. Broadest Reasonable Interpretation ............................................................... 36
`
`A. “namespace file system” ........................................................................ 37
`
`B. “object” .................................................................................................. 39
`
`C. “program code means which, when executed by a process, performs the
`steps of method claim 19” ..................................................................... 40
`
`VIII. CHALLENGES ............................................................................................. 42
`
`A. Background on Prior Art References ..................................................... 43
`
`1. Muthitacharoen .............................................................................. 43
`
`2. Dabek ............................................................................................. 55
`
`
`
`
`
`2
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`3. Agrawal .......................................................................................... 59
`
`
`
`4. Bondurant ....................................................................................... 61
`
`5. McKusick ....................................................................................... 62
`
`6. Bunte .............................................................................................. 65
`
`B. Claims 1-4, 7-9, 11-14, 17-22, 27, 28, and 30-35 are obvious over
`Muthitacharoen and Dabek .................................................................... 69
`
`1. Reasons to Combine Muthitacharoen and Dabek .......................... 69
`
`C. Claims 5 and 6 are Obvious over Muthitacharoen, Dabek, and Agrawal
` ................................................................................................................ 72
`
`1. Reasons to Combine Muthitacharoen and Dabek with Agrawal ... 72
`
`D. Claims 10, 15, and 26 are Obvious over Muthitacharoen, Dabek, and
`McKusick ............................................................................................... 75
`
`1. Reasons to Combine Muthitacharoen and Dabek with McKusick 75
`
`E. Claims 29 and 30 are Obvious over Muthitacharoen, Dabek, and Bunte
` ................................................................................................................ 77
`
`1. Reasons to Combine Muthitacharoen and Dabek with Bunte ....... 77
`
`F. Claims 16 and 36 are Obvious over Muthitacharoen, Dabek, and
`Bondurant ............................................................................................... 80
`
`1. Reasons to Combine Muthitacharoen and Dabek with Bondurant 81
`
`IX. DETAILED CLAIM ANALYSIS ................................................................. 84
`
`X.
`
`Conclusion ...................................................................................................196
`
`
`
`
`
`
`
`
`
`
`3
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`I, Prashant Shenoy, do hereby declare as follows:
`
`
`
`I.
`
`INTRODUCTION
`1.
`
`I have been retained as an independent expert witness on behalf of
`
`Cisco Systems, Inc. (“Cisco”) for the above-captioned Petition for Inter Partes
`
`Review (“IPR”) of U.S. Patent No. 8,478,799 (“the ’799 patent”). I am being
`
`compensated at my usual and customary rate for the time I spend in connection
`
`with this IPR. My compensation is not affected by the outcome of this IPR.
`
`2.
`
`I have been asked to provide my opinions regarding whether claims
`
`1-22 and 26-36 (“the Challenged Claims”) of the ’799 patent are invalid, either
`
`because they were anticipated or because they would have been obvious to a
`
`person having ordinary skill in the art (“POSITA”) at the time of the alleged
`
`invention. It is my opinion that all of the limitations of claims 1-22 and 26-36
`
`would have been obvious to a POSITA after reviewing Muthitacharoen, Dabek,
`
`Agrawal, Bondurant, McKusick, and Bunte.
`
`3.
`
`The ’799 patent issued on July 2, 2013, from U.S. Patent Appl. No.
`
`12/823,922 (“the ’922 Application”), filed on June 25, 2010. The ’922 Application
`
`is a continuation-in-part of U.S. Patent Appl. No. 12/823,452 (“the ’452
`
`Application”), also filed June 25, 2010, and which issued as U.S. Patent No.
`
`8,880,544 (“the ’544 Patent”) on November 4, 2014. Both, the ’922 Application
`
`
`
`
`
`4
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`and the ’452 Application claim priority to U.S. Provisional Application No.
`
`
`
`61/269,633 (“the ’633 Provisional Application”) filed on June 26, 2009.
`
`4.
`
`The ’799 patent names Arthur J. Beaverson and Paul Bowden as the
`
`purported inventors. Further, the ’799 patent identifies SimpliVity Corporation as
`
`the initial assignee of the ’799 patent.
`
`5.
`
`In preparing this Declaration, I have reviewed, among other things,
`
`the ’799 patent, the file history of the ’799 patent, numerous prior art and technical
`
`references from the time of the alleged invention, and documents from two other
`
`IPR proceedings (i.e., IPR2016-01779 and IPR2016-01780) which were initiated
`
`against the ’799 patent.
`
`6.
`
`I understand that claims in an IPR are given their broadest
`
`reasonable interpretation in view of the patent specification and the understandings
`
`of a POSITA. I further understand that this is not the same claim construction
`
`standard as one would use in a District Court proceeding.
`
`7.
`
`In forming the opinions expressed in this Declaration, I relied upon
`
`my education and experience in the relevant field of art, and have considered the
`
`viewpoint of a POSITA, as of June 26, 2009. My opinions are based, at least in
`
`part, on the following:
`
`
`
`“Muthitacharoen”: Athicha Muthitacharoen, et al., “Ivy: A
`
`Read/Write Peer-to-Peer File System,” Proceedings of the 5th
`
`
`
`
`
`5
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`Symposium on Operating Systems Design and Implementation (OSDI
`
`
`
`’02), OPERATING SYSTEMS REVIEW, Vol. 36, Issue SI (Winter 2002).
`
`
`
`“Dabek”: Frank Dabek, et al., “Wide-area cooperative storage with
`
`CFS,” Proceedings of the 18th ACM Symposium on Operating
`
`Systems Principles (SOSP’01), OPERATING SYSTEMS REVIEW, Vol.
`
`35, No. 5 (Dec. 2001).
`
`
`
`“Agrawal”: Nitin Agrawal, et al., “Design Tradeoffs for SSD
`
`Performance,” USENIX’08: 2008 USENIX Annual Technical
`
`Conference (Jun. 25, 2008).
`
`
`
`
`
`
`
`“Bondurant”: U.S. Patent No. 8,028,106 to Bondurant et al.
`
`“McKusick”: Marshall Kirk McKusick, et al., THE DESIGN AND
`
`IMPLEMENTATION OF THE FREEBSD OPERATING SYSTEM (2005).
`
`“Bunte”: U.S. Patent No. 8,140,786 to Bunte et al.
`
`II. BACKGROUND AND QUALIFICATIONS
`8.
`I have more than two decades of experience in the relevant field of
`
`technology for the ’799 patent—computer file system data structures, and methods
`
`and apparatus for the naming and storing of files. This includes experience in
`
`distributed and operating systems, networking, and data management. I am
`
`proficient in file systems, including content-addressable file systems, using various
`
`
`
`
`
`6
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`data structures for storage and management of files. I have published over 225
`
`
`
`technical papers that have been cited in other publications more than 15,000 times.
`
`9.
`
`Over the years, I have led research and industry collaboration
`
`projects in areas such as storage and file systems, Web and Internet systems,
`
`content distribution, streaming media, database systems, cloud computing,
`
`virtualization, RFID and sensor networks, and energy systems. During that time, I
`
`have consulted with both large companies and startups in a technical advisory role
`
`related to product architecture, intellectual property (IP) issues, and applied
`
`research.
`
`10. My qualifications are set forth in my curriculum vitae, a copy of
`
`which is submitted as exhibit CSCO-1005 with this declaration. A list of my prior
`
`engagements, including a list of cases in which I have provided deposition or trial
`
`testimony, is included in exhibit CSCO-1005.
`
`11.
`
`I received my Bachelor of Technology (B.Tech.) degree in 1993
`
`from the Department of Computer Science and Engineering at The Indian Institute
`
`of Technology (“IIT”), Mumbai, India. IIT awarded me the Institute Medal for
`
`being the top ranking undergraduate student. In 1994, I received my Master of
`
`Science (M.S.) degree in Computer Sciences from The University of Texas at
`
`Austin. In 1998, I received my Doctor of Philosophy (Ph.D.) also from the
`
`Department of Computer Sciences at The University of Texas at Austin. My
`
`
`
`
`
`7
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`dissertation was recognized by the department as the Best Doctoral Dissertation of
`
`
`
`1998-1999.
`
`12.
`
`From 1998 until 2009, I worked as an Assistant and then Associate
`
`Professor at the Department of Computer Science at the University of
`
`Massachusetts Amherst. In that capacity, I taught graduate courses on distributed
`
`systems and undergraduate courses on operating systems. The courses covered in-
`
`depth discussions of storage, I/O, and file systems.
`
`13.
`
`Since 2009, I have been working as a Professor at the College of
`
`Information and Computer Sciences at the University of Massachusetts Amherst.
`
`In 2016, I was appointed as Associate Dean of the College of Information and
`
`Computer Sciences. I currently work in both these capacities.
`
`III. UNDERSTANDING OF PATENT LAW
`14.
`I understand that prior art to the ’799 patent includes patents and
`
`printed publications in the relevant art that predate the priority date of the alleged
`
`invention recited in the ’799 patent. For purposes of this Declaration, I have been
`
`asked to apply June 26, 2009, the filing date of the ’633 Provisional Application, as
`
`the priority date.
`
`15.
`
`I understand that a claim is invalid if it is anticipated. Anticipation
`
`of a claim requires that every element of a claim be disclosed expressly or
`
`
`
`
`
`8
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`inherently in a single prior art reference, arranged in the prior art reference as
`
`
`
`arranged in the claim.
`
`16.
`
`I also understand that a claim is invalid if it would have been
`
`obvious. Obviousness of a claim requires that the claim would have been obvious
`
`from the perspective of a POSITA at the time the alleged invention was made. I
`
`understand that a claim could have been obvious from a single prior art reference
`
`or from a combination of two or more prior art references.
`
`17.
`
`I understand that an obviousness analysis requires an understanding
`
`of the scope and content of the prior art, any differences between the alleged
`
`invention and the prior art, and the level of ordinary skill in evaluating the
`
`pertinent art.
`
`18.
`
`I further understand that certain factors may support or rebut the
`
`obviousness of a claim. I understand that such secondary considerations include,
`
`among other things, commercial success of the patented invention, skepticism of
`
`those having ordinary skill in the art at the time of invention, unexpected results of
`
`the invention, any long-felt but unsolved need in the art that was satisfied by the
`
`alleged invention, the failure of others to make the alleged invention, praise of the
`
`alleged invention by those having ordinary skill in the art, and copying of the
`
`alleged invention by others in the field. I understand that there must be a nexus—a
`
`connection—between any such secondary considerations and the alleged invention.
`
`
`
`
`
`9
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`I also understand that contemporaneous and independent invention by others is a
`
`
`
`secondary consideration tending to show obviousness.
`
`19.
`
`I further understand that a claim would have been obvious if it unites
`
`old elements with no change to their respective functions, or alters prior art by
`
`mere substitution of one element for another known in the field and that
`
`combination yields predictable results. While it may be helpful to identify a reason
`
`for this combination, common sense should guide and no rigid requirement of
`
`finding a teaching, suggestion, or motivation to combine is required. When a
`
`product is available, design incentives and other market forces can prompt
`
`variations of it, either in the same field or different one. If a POSITA can
`
`implement a predictable variation, obviousness likely bars its patentability. For the
`
`same reason, if a technique has been used to improve one device and a POSITA
`
`would recognize that it would improve similar devices in the same way, using the
`
`technique would have been obvious. I understand that a claim would have been
`
`obvious if common sense directs one to combine multiple prior art references or
`
`add missing features to reproduce the alleged invention recited in the claims.
`
`20.
`
`I am not aware of any allegations by the named inventor of the ’799
`
`patent or any assignee of the ’799 patent that any secondary considerations tend to
`
`rebut the obviousness of any Challenged Claim of the ’799 patent.
`
`
`
`
`
`10
`
`CSCO-1004
`
`

`

`
`
`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`IV. BACKGROUND OF TECHNOLOGY
`A. Computer Storage Systems, and Their Evolution
`21.
`Computer storage systems, including storage devices, file systems
`
`and object storage systems were all well-known concepts many years before the
`
`priority date of the ’799 patent.
`
`22.
`
`Early storage systems and file systems date back to the era of the
`
`mainframe computers in the 1970s. Storage systems consist of physical storage
`
`devices that store data in a persistent manner. Early storage devices consisted of
`
`magnetic disk drives, tape drives, and optical disk drives, among others. Solid state
`
`memory technologies such as random-access memory (RAM), read only memory
`
`(ROM), erasable programmable read only memory (EPROM), and flash memory
`
`have been around for decades and date back to the 1970s and 1980s. While RAM,
`
`also known as main memory, is volatile in nature, technologies such as ROM,
`
`EPROM and flash memory store data in a non-volatile and persistent manner.
`
`23.
`
`Storage devices allow data to be stored on them in granularity of
`
`blocks. A block, also referred as a page in some storage devices, is the smallest
`
`unit of data that may be read from or written to the device. A block has a unique
`
`address that is used to access it from the storage device. For example, in many
`
`storage devices, blocks are sequentially numbered from 0 to N, and the block
`
`
`
`
`
`11
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`number serves as the block address. Thus, hardware storage devices such disks
`
`
`
`provide a block-based storage abstraction to higher-level software.
`
`24. While data on a storage device can be accessed using block
`
`addresses, operating systems provide an easier to use logical abstraction to users
`
`and their applications. Users typically store and access data using the abstraction of
`
`a file and do not have to deal with the low-level details of where files are stored on
`
`a storage device or block addresses. Typically, undergraduate textbooks discussing
`
`Operating Systems from the early 2000s define a file as a named collection of
`
`logically related data. Thus, a file has a name, and users access a file and its data
`
`using its name, rather than block addresses. In other words, the OS provides a
`
`logical file-based storage abstraction to its users and user applications.
`
`25.
`
`A typical file system allows files to be organized into directories and
`
`sub-directories (also known as folders and sub-folders) for user convenience,
`
`yielding a hierarchical organization of data on the storage device. Since both files
`
`and directories have names, this results in a hierarchical name space for data stored
`
`in the file system.
`
`26.
`
`Traditionally, a file system maintains metadata information to map
`
`file names to block addresses. This metadata enables a file system translate user
`
`requests to access a file (using the file name) to internal block addresses on the
`
`storage device.
`
`
`
`
`
`12
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`27.
`In case of the UNIX file system, the file metadata information is
`
`
`
`stored in a data structure called an index node (often shortened to i-node or inode).
`
`See Bach at 22. An i-node stores information such as the owner of the file, the size
`
`of the file, file permission, as well as the identification of disk blocks that contain
`
`the file’s data. See Bach at 61-62.
`
`28.
`
`Thus, a file can be of variable size, and the file systems partition a
`
`file into smaller blocks that are stored on disk and maintain the mapping of block
`
`numbers to block addresses in the i-node. Traditional file systems used block-
`
`based storage devices. While many file systems commonly use fixed size blocks to
`
`store file data, this is not universally true. File systems designed in the 1990s and
`
`early 2000s to store video files often used variable block sizes to store video files.
`
`Examples of such file systems include the Symphony multimedia file system
`
`(1999) and Exedra streaming server. The Symphony multimedia file system had
`
`features such as “a storage manager that supports multiple block sizes.” See
`
`Prashant Shenoy, et al., “Symphony: An Integrated Multimedia File System” at
`
`124, Proceedings of SPIE 3310, Multimedia Computing and Networking 1998.
`
`The Exedra streaming server stored data on “strides” and employed a “stride-based
`
`allocation scheme may be based on variable sized strides.” See U.S. Patent No.
`
`7,103,595, 6:51-52 & 9:48-50. Variable block sizes allowed greater flexibility in
`
`organizing files such as digital video on storage devices.
`
`
`
`
`
`13
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`29.
`Both the block-based storage at the disk level and file-based storage
`
`
`
`at the file system level were found to have several limitations. These limitations
`
`led to the emergence of object-based storage systems in the late 1990s and early
`
`2000s. The concept was proposed in a university research project led by Garth
`
`Gibson at Carnegie Mellon University as well as a Belgium company named
`
`FilePool in the mid-1990s. See Garth Gibson, et al., “A Cost-Effective, High-
`
`Bandwidth Storage Architecture,” PROCEEDINGS OF THE 8TH CONFERENCE ON
`
`ARCHITECTURAL SUPPORT FOR PROGRAMMING LANGUAGES AND OPERATING
`
`SYSTEMS (1998).
`
`30.
`
`A research paper on the topic describes some of the characteristics
`
`and uses of object-based storage systems:
`
`A storage object is a logical collection of bytes on a storage
`device, with well-known methods for access, attributes
`describing characteristics of the data, and security policies that
`prevent unauthorized access. Unlike blocks, objects are of
`variable size and can be used to store entire data structures,
`such as files, database tables, medical images, or multimedia.
`
`two
`the convergence of
`regarded as
`Objects can be
`technologies: files and blocks. Files provide user applications
`with a higher-level storage abstraction that enables secure data
`sharing across different operating system platforms, but often at
`the cost of limited performance due to file server contention.
`14
`CSCO-1004
`
`
`
`
`
`

`

`
`
`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`Blocks offer fast, scalable access to shared data; but without a
`file server to authorize the I/O and maintain the metadata, this
`direct access comes at the cost of limited security and data
`sharing.
`Mike Mesnier, et al., “Object-Based Storage,” IEEE COMMUNICATION MAGAZINE
`at 84 (Aug. 2003).
`31.
`Gibson described similar concepts in his original proposal:
`
`Using an object interface in storage rather than a fixed-block
`interface moves data layout management to the disk. In
`addition, NASD partitions are variable-sized groupings of
`objects, not physical regions of disk media, enabling the total
`partition space to be managed easily, in a manner similar to
`virtual volumes or virtual disks [IEEE95, Lee96].
`Gibson at 94.
`
`
`32.
`
`Thus, object-based storage systems were designed to address
`
`limitations of using fixed block sizes in storage devices and file-based organization
`
`in file systems. As noted by Mesnier, object-based storage combines the ease of
`
`access of files with the performance of blocks:
`
`Objects can provide the advantages of both files and blocks.
`Like blocks, objects are a primitive unit of storage that can be
`directly accessed on a storage device (i.e., without going
`through a server); this direct access offers performance
`advantages similar to blocks. Like files, objects are accessed
`using an interface that abstracts storage applications from the
`
`
`
`
`
`15
`
`CSCO-1004
`
`

`

`
`
`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`metadata necessary to store the object, thus making the object
`easily accessible across different platforms. Providing direct,
`file-like access to storage devices is therefore the key
`contribution of object-based storage.
`Mesnier at 84.
`
`
`33.
`
`Figure 3 of Mesnier shows the block-based and object-based storage
`
`systems, and also that the object layer sits between block and file system:
`
`Mesnier, Fig. 3 at 86.
`
`
`
`34.
`
`The use of object-based storage to implement a traditional file
`
`system abstraction was also well known in the art. For example, Mesnier teaches
`
`“In particular, object-based file systems will be relatively straightforward to
`
`implement (a file system need only give up control over block management), and
`
`16
`CSCO-1004
`
`
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`an OS’s I/O subsystem can be introduced to objects by virtue of a new class driver,
`
`
`
`similar to those that already exist for disk and tape.” Mesnier at 87. Mesnier also
`
`points to a reference implementation in Linux to demonstrate how this may be
`
`done: “Reference code from Intel Labs shows how both can be done in Linux.”
`
`Mesnier at 87. Thus, the use of objects in file storage systems were well
`
`understood long before the priority date of the ‘799 patent.
`
`35.
`
`As storage systems evolved from block-based storage to object-
`
`based storage, file systems also evolved to store their data and meta-data using
`
`objects rather than blocks. This is shown in Figure 3 (above) of Mesnier which
`
`depicts a file system that is implemented on top of an object interface. In such a
`
`file system, all data and meta-data would be stored as objects. This would include
`
`files, directories, inodes for files and directories, super-block, data blocks and any
`
`other data structure maintained by the file system, all of which would be written
`
`and read as objects from the underlying object storage system. Such objects (e.g.,
`
`a file, metadata, etc.) can be of variable size. Indeed, Dabek states that “[t]he
`
`maximum size of a block is on the order of tens of kilobytes,” indicating that
`
`DHash supported storing files and metadata as objects having variable sizes.
`
`Dabek at 204. Dabek’s file system “uses DHash blocks and block identifiers in
`
`place of disk blocks and disk addresses.” Id. In Dabek, “each block is either a
`
`piece of a file or a piece of file system meta-data, such as a directory.” Thus, a
`
`
`
`
`
`17
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`POSITA would understand that in a file system implemented using an object
`
`
`
`storage system, all data and meta data structures (e.g., files, metadata, directories,
`
`snapshots, the directory inode, the file inode, the directory inode block, and the
`
`data blocks), taken separately or in various combinations, are “objects” under the
`
`plain and ordinary meaning of the term at the time of the ’799 patent.
`
`36.
`
`During this evolution of computer storage systems from block-based
`
`to object-based file systems, the terminology used to describe them needed to
`
`develop as well. Initially, even as the file systems were allowing for more
`
`abstraction, some artisans in the field continued to use the term “block” to refer to
`
`the new file system constructs. This led to some confusion, so eventually, those in
`
`the art began to use other terms to refer to the new file system constructs, including
`
`the term “object,” as already discussed, or the term “fragment.” This transition was
`
`not entirely smooth, however, as individuals would sometimes use multiple terms
`
`almost interchangeably, allowing context to clarify. For example, one 2005 survey
`
`article described distributed hash tables (such as DHash) as storing both “objects”
`
`and “blocks”:
`
`An important location strategy used in several systems is
`Distributed Hash Table (DHT). It uses hashing of file or
`resource names to locate the object.
`
`…
`
`
`
`
`
`18
`
`CSCO-1004
`
`

`

`
`
`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`CFS uses Distributed Hash table (Dhash) for storage of
`blocks.
`
`See Ragib Hasan, et al., “A Survey of Peer-to-Peer Storage Techniques for
`
`Distributed File Systems” at 3 & 4, International Conference on Information
`
`Technology: Coding and Computing (2005). A 2006 article directed to distributed
`
`storage systems, including DHash, described that DHash stores data as objects:
`
`For example, DHash stores the copies of all the objects
`with keys in a particular range on the successor nodes of
`that key range; the result is that those nodes store similar
`sets of objects, and can exchange compressed summaries
`of the objects they store when they want to check that
`each object is replicated a sufficient number of times [6].
`
`See Chun et al., “Efficient Replica Maintenance for Distributed Storage Systems”
`
`at 50, NSDI ’06: 3rd Symposium on Networked Systems Design & Implementation
`
`(2006). Notably, this 2006 article and Dabek shared multiple authors—Frank
`
`Dabek, M. Frans Kaashoek, and Robert Morris—implementing file systems using
`
`DHash as the storage system.
`
`37.
`
`Eventually, by the time of the ’799 patent, the field had settled on
`
`the terminology to distinguish “blocks” from “objects” as those concepts would be
`
`understood to a POSITA.
`
`38.
`
`Thus, the use of objects in file storage systems were well understood
`
`long before the priority date of the ’799 patent.
`
`19
`
`
`
`CSCO-1004
`
`

`

`
`
`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`B. Cryptographic Hash
`39.
`The notion of a cryptographic hash function was also known well
`
`before the priority date of the ’799 patent. A hash function is a function that maps
`
`an input of arbitrary size to a fixed size output, which is known as a “fingerprint,”
`
`“hash digest,” or simply “hash” or “digest” of the input. See Schneier, APPLIED
`
`CRYPTOGRAPHY at 30. A cryptographic hash function is a special type of hash
`
`function that has certain properties that make it suitable for cryptographic and
`
`security applications. In particular, such hash functions have a very low
`
`probability of hash collisions, which means the chances of finding two inputs that
`
`produce the same hash are exceedingly small. Cryptographic hash functions are
`
`also robust to brute-force attacks, which makes it computationally very expensive
`
`to generate the original input from its output hash value using brute force methods.
`
`40.
`
`Cryptographic hash functions have been used for many decades. For
`
`example, the message digest 5 (MD5) hash function is an IETF standard from
`
`1992. See R. Rivest, “The MD5 Message-Digest Algorithm,” Request for
`
`Comments 1321, Internet Engineering Task Force (Apr. 1992). Secure Hash
`
`Algorithm (SHA) is another family of cryptographic hash functions that was
`
`proposed in the 1990s. Many variants of SHA cryptographic hash functions have
`
`been designed such as SHA-0, SHA-1, SHA-2 and SHA-3. As discussed above,
`
`the terms such as “fingerprint,” “hash digest,” or simply “hash” or “digest” were
`
`
`
`
`
`20
`
`CSCO-1004
`
`

`

`Declaration of Prashant Shenoy Under 37 C.F.R. § 1.68 in Support of
`Petition for Inter Partes Review of U.S. Patent No. 8,478,799
`used in the art to denote the hash output mapped to arbitrary-sized input in these
`
`
`
`cryptographic hash functions. See Schneier, APPLIED CRYPTOGRAPHY at 30.
`
`41.
`
`The use of cryptographic hash functions in object storage systems
`
`was also well known. The Venti Storage system, a prior art reference mentioned in
`
`the file history of the ’799 patent, uses “a unique hash of a block’s contents acts as
`
`the block identifier for read and write operations.” See Sean Quinlan, et al.,
`
`“Venti: a new approach to archival storage,” PROCEEDINGS OF FAST 2002
`
`CONFERENCE OF FILE AND STORAGE TECHNOLOGIES at 2 (2002). The reference
`
`further states “Venti identifies data blocks by a hash of their contents. By using a
`
`collision-resistant hash function with a suf