UNITED STATES PATENT AND TRADEMARK OFFICE

———————

BEFORE THE PATENT TRIAL AND APPEAL BOARD

———————

Cisco Systems, Inc., Petitioner

———————

Case IPR2017-01933

———————

PETITION FOR INTER PARTES REVIEW

OF

U.S. PATENT NO. 8,478,799

1 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

TABLE OF CONTENTS

PETITIONER’S EXHIBIT LIST ...... 5

I. Mandatory Notices ...... 13

A. Real Party-in-Interest ...... 13

B. Related Matters ...... 13

C. Lead and Back-up Counsel and Service Information ...... 13

II. Grounds for Standing ...... 14

III. Introduction ...... 14

IV. Relief Requested and Overview of Reasons Therefor ...... 15

V. Description of the Technology ...... 15

A. Evolution of Computer Storage Systems ...... 15

B. Cryptographic Hash ...... 16

C. The ’799 Patent ...... 17

1. Summary of the ’799 Patent ...... 17

2. Prosecution History ...... 20

3. Previous IPR Proceedings ...... 20

D. Page Citations and Quotations ...... 21

VI. Identification of Challenges and Claim Construction ...... 21

A. Challenged Claims ...... 21

B. Claim Construction ...... 21

C. Statutory Grounds for Challenges ...... 24

2 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

D. Petitioner’s Challenges Are Not Cumulative or Duplicative of Prior Patent Office Proceedings ...... 25

E. Identification of How the Construed Claims Are Unpatentable ...... 26

1. Challenge #1: Claims 1-4, 7-9, 11-14, 17-22, 27, 28, and 31-35 are obvious over Muthitacharoen and Dabek ...... 26

a. Summary of Muthitacharoen ...... 26

b. Summary of Dabek...... 28

c. Reasons to Combine Muthitacharoen and Dabek ...... 29

d. Detailed Claim Analysis ...... 31

Claim 1 ...... 31

2. Challenge #2: Claims 5, 6 are unpatentable as being obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and Agrawal ...... 71

a. Brief summary of Agrawal ...... 71

b. Reasons to Combine Muthitacharoen/Dabek with Agrawal .. 72

c. Detailed Claim Analysis ...... 72

3. Challenge #3: Claims 10, 15, and 26 are unpatentable as being obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and McKusick ...... 74

a. Brief summary of McKusick ...... 74

b. Reasons to Combine Muthitacharoen/Dabek with McKusick ...... 75

c. Detailed Claim Analysis ...... 76

4. Challenge #4: Claims 29 and 30 are obvious over Muthitacharoen, Dabek, and Bunte...... 81

3 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

a. Brief summary of Bunte ...... 81

b. Reasons to Combine Muthitacharoen/Dabek with Bunte ...... 81

c. Detailed Claim Analysis ...... 83

5. Challenge #5: Claims 16 and 36 are unpatentable as being obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and Bondurant ...... 85

a. Brief summary of Bondurant ...... 85

b. Reasons to Combine Muthitacharoen/Dabek with Bondurant ...... 86

c. Detailed Claim Analysis ...... 87

VII. Conclusion ...... 90

VIII. Certificate of Word Count ...... 91

IX. Certificate of Service ...... 92

4 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

PETITIONER’S EXHIBIT LIST

August 11, 2017

1001 U.S. Patent No. 8,478,799 (“the ’799 patent”)

1002 Prosecution History of the ’799 patent

1003 U.S. Prov. App. No. 61/269,633 (“the ’633 provisional”)

1004 Declaration of Dr. Prashant Shenoy Under 37 C.F.R. § 1.68

1005 Curriculum Vitae of Dr. Prashant Shenoy

1006 Intentionally omitted

1007 Athicha Muthitacharoen, et al., “Ivy: A Read/Write Peer-to-Peer

File System,” Proceedings of the 5th Symposium on Operating

Systems Design and Implementation (OSDI ’02), OPERATING

SYSTEMS REVIEW, Vol. 36, Issue SI (Winter 2002).

1008 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).

1009 Nitin Agrawal, et al., “Design Tradeoffs for SSD Performance,”

USENIX’08: 2008 USENIX Annual Technical Conference (Jun. 25,

2008).

5 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1010 U.S. Patent No. 8,028,106 to Bondurant et al. (“Bondurant”)

1011 Marshall Kirk McKusick, et al., THE DESIGN AND IMPLEMENTATION

OF THE FREEBSD OPERATING SYSTEM (2005).

1012 “Robust and Efficient Data Management for a Distributed Hash

Table” by Josh Cates (“Cates”).

1013 Marice J. Bach, THE DESIGN OF THE UNIX OPERATING SYSTEM

(1986) (selected pages).

1014 Prashant Shenoy, et al., “Symphony: An Integrated Multimedia File

System,” Proceedings of SPIE 3310, Multimedia Computing and

Networking 1998.

1015 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).

1016 Mike Mesnier, et al., “Object-Based Storage,” IEEE

COMMUNICATION MAGAZINE (Aug. 2003).

1017 R. Rivest, “The MD5 Message-Digest Algorithm,” Request for

Comments 1321, Internet Engineering Task Force (Apr. 1992).

6 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1018 Sean Quinlan, et al., “Venti: a new approach to archival storage,”

PROCEEDINGS OF FAST 2002 CONFERENCE OF FILE AND STORAGE

TECHNOLOGIES (2002).

1019 Petition for Inter Partes Review, IPR2016-01779 (Sept. 14, 2016).

1020 Patent Owner Response, IPR2016-01779 (Dec. 27, 2016).

1021 Petition for Inter Partes Review, IPR2016-01780 (Sept. 14, 2016).

1022 Patent Owner Response, IPR2016-01780 (Dec. 27, 2016).

1023 Bruce Eckel, C++ INSIDE & OUT (1992) (selected pages).

1024 Mendel Rosenblum, THE DESIGN AND IMPLEMENTATION OF A LOG-

STRUCTURED FILE SYSTEM (1995) (selected pages).

th 1025 WEBSTER’S NEW WORLD COMPUTER DICTIONARY, 10 Ed. (2003)

(selected pages).

1026 MICROSOFT COMPUTER DICTIONARY, 5th Ed. (2002) (selected

pages).

1027 AMD Athlon Processor Technical Brief, Rev. D (Dec. 1999).

1028 Stevens, et al., “The first collision for full SHA-1,” Cryptology

ePrint Archive, Report 2017/190 (2017).

1029 Andrew S. Tanenbaum, MODERN OPERATING SYSTEMS, 2d Ed.

(2001) (selected pages).

7 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

th 1030 Alan Freedman, COMPUTER DESKTOP ENCYCLOPEDIA, 9 Ed. (2001)

(selected pages).

1031 Sang-Won Lee, et al., “A Case for Flash Memory SSD in Enterprise

Database Applications,” Proceedings of the 2008 ACM SIGMOD

International Conference on Management of Data (2008).

1032 Bruce Schneier, APPLIED CRYPTOGRAPHY, 2d Ed. (1996) (selected

pages).

1033 Martin Placek, “Storage Exchange: A Global Platform for Trading

Distributed Storage Services,” Master of Engineering Science

Thesis, The University of Melbourne (Jul, 2006).

1034 Ragib Hasan, et al., “A Survey of Peer-to-Peer Storage Techniques

for Distributed File Systems,” International Conference on

Information Technology: Coding and Computing (2005).

1035 Frequently Asked Questions for FreeBSD 2.X, 3.X and 4.X,

archived at https://web.archive.org/web/20020404064240/http://

www.freebsd.org:80/doc/en_US.ISO8859-1/books/faq/install.html.

1036 AMD Athlon Processor Module Data Sheet, Rev. M (Jun. 2000).

1037 AMD Athlon™ Processor Quick Reference FAQ (Feb. 3, 2000).

1038 U.S. Patent No. 7,103,595 to Anastasiadis, et al.

8 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1039 U.S. Patent No. 8,140,786 to Bunte et al.

1040 Decision Denying Institution of Inter Partes Review, IPR2016-

01779 (March 22, 2017).

1041 Decision Denying Institution of Inter Partes Review, IPR2016-

01780 (March 21, 2017).

1042 MARC Record Information for Operating Systems Review –

Proceedings of the Fifth ACM Symposium on Operating Systems

Design and Implementation (OSDI’02), available at the WRLC

online catalog, accessed July 20, 2017.

1043 Bibliographic Record Information for Operating Systems Review –

Proceedings of the Fifth ACM Symposium on Operating Systems

Design and Implementation (OSDI’02), available at the WRLC

online catalog, accessed July 20, 2017.

1044 MARC Record Information for Operating Systems Review –

Proceedings of the 18th ACM Symposium on Operating Systems

Principles (SOSO’01), available at the online catalog of the Library

of Congress, accessed July 31, 2017.

9 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1045 Bibliographic Record Information for Operating Systems Review –

Proceedings of the 18th ACM Symposium on Operating Systems

Principles (SOSO’01), available at the online catalog of the Library

of Congress, accessed July 31, 2017.

1046 Scans of Issue, Operating Systems Review – Proceedings of the 18th

ACM Symposium on Operating Systems Principles (SOSO’01), Vol.

35, No. 5, pp. 202-15, obtained from a CD-ROM from Auburn

University.

1047 MARC Record Information for Operating Systems Review –

Proceedings of the 18th ACM Symposium on Operating Systems

Principles (SOSO’01) CD-ROM, available at the Auburn University

Library online catalog, accessed July 28, 2017.

1048 Bibliographic Record Information for Operating Systems Review –

Proceedings of the 18th ACM Symposium on Operating Systems

Principles (SOSO’01) CD-ROM, available at the Auburn University

Library online catalog, accessed July 28, 2017.

1049 Scan of CD-ROM and CD-ROM Case, Operating Systems Review –

Proceedings of the 18th ACM Symposium on Operating Systems

Principles (SOSO’01) CD-ROM obtained from the Auburn

University Library.

10 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1050 Byung-Gon Chun, et al., “Efficient Replica Maintenance for

Distributed Storage Systems,” PROCEEDINGS OF NSDI ’06: 3RD

SYMPOSIUM ON NETWORKED SYSTEMS DESIGN & IMPLEMENTATION

(2006).

1051 Scanned pages of Dabek, F., et al., 2001, “Wide-area cooperative

storage with CFS,” Operating Systems Review – Proceedings of the

18th ACM Symposium on Operating Systems Principles (SOSO’01),

Vol. 35, No. 5, pp. 202-15, obtained from a CD-ROM from Auburn

University.

1052 Intentionally omitted.

1053 Intentionally omitted.

1054 Declaration of Ingrid Hsieh-Yee, PhD Under 37 C.F.R. § 1.68

1055 Declaration of Michele Nelson Under 37 C.F.R. § 1.68

1056 Declaration of David Bader Under 37 C.F.R. § 1.68

1057 MARC Record Information for THE DESIGN AND IMPLEMENTATION

OF THE FREEBSD OPERATING SYSTEM (2005), available at the online

catalog of the Library of Congress, accessed August 3, 2017.

11 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1058 Bibliographic Record Information for THE DESIGN AND

IMPLEMENTATION OF THE FREEBSD OPERATING SYSTEM (2005),

available at the online catalog of the Library of Congress, accessed

August 3, 2017.

1059 Scanned pages of Marshall Kirk McKusick, et al., THE DESIGN AND

IMPLEMENTATION OF THE FREEBSD OPERATING SYSTEM (2005),

obtained from the George Mason University Library.

1060 MARC Record Information for THE DESIGN AND IMPLEMENTATION

OF THE FREEBSD OPERATING SYSTEM (2005), available at the online

catalog of the George Mason University Library, accessed August 3,

2017.

1061 Bibliographic Record Information for THE DESIGN AND

IMPLEMENTATION OF THE FREEBSD OPERATING SYSTEM (2005),

available at the online catalog of the George Mason University

Library, accessed August 3, 2017.

12 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

I. Mandatory Notices

A. Real Party-in-Interest

The Petitioner and real party in interest is Cisco Systems, Inc.

B. Related Matters

As of the filing date of this petition and to the best knowledge of the

Petitioner, U.S. Patent No. 8,478,799 (“the ’799 patent,” CSCO-1001) has been involved in the following litigation filed by SimpliVity Corp. (“SimpliVity”):

SimpliVity Corp. v. Springpath Inc., No. 4-15-cv-13345 (D. Mass 2016). The ’799 patent was also the subject of two prior inter partes review proceedings—

IPR2016-01779 and IPR2016-01780—both filed by Springpath, Inc.

(“Springpath”).

C. Lead and Back-up Counsel and Service Information

Lead Counsel David L. McCombs Phone: 214-651-5533 HAYNES AND BOONE, LLP Fax: 214-200-0853 2323 Victory Ave. Suite 700 [email protected] Dallas, TX 75219 USPTO Reg. No. 32,271

Back-up Counsel Theodore M. Foster Phone: 972-739-8649 HAYNES AND BOONE, LLP Fax: 214-200-0853 2323 Victory Ave. Suite 700 [email protected] Dallas, TX 75219 USPTO Reg. No. 57,456

13 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Back-up Counsel Philip W. Woo Phone: 650-687-8818 HAYNES AND BOONE, LLP Fax: 214-200-0853 2323 Victory Ave. Suite 700 [email protected] Dallas, TX 75219 USPTO Reg. No. 39,880

Back-up Counsel Pranay Pattani Phone: 972-739-6975 HAYNES AND BOONE, LLP Fax: 214-200-0853 2323 Victory Ave. Suite 700 [email protected] Dallas, TX 75219 USPTO Reg. No. 66,587

II. Grounds for Standing

Petitioner certifies that the ’799 patent is available for inter partes review and that Petitioner is not barred or estopped from requesting inter partes review challenging the patent claims on the grounds identified in this petition.

III. Introduction

The ’799 patent generally relates to computer storage systems, and in particular data structures for naming and storing files. According to the patent, previous file systems had tightly controlled what content was stored where, resulting in an architecture that was difficult to extend to modern storage needs.

The ‘799 patent describes a file system based on a flexible “object” storage concept. But object-based file systems were already known in the art before the priority date of the ’799 patent. Because the ’799 patent claims technology that was already known, its claims are unpatentable.

14 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

IV. Relief Requested and Overview of Reasons Therefor

Petitioner asks that the Board review the accompanying prior art and

analysis, institute an inter partes review trial of claims 1-22 and 26-36 of the ’799

patent (the “Challenged Claims”), and cancel those claims as unpatentable. This

petition and the declaration of Dr. Prashant Shenoy explain how the prior art would

have rendered obvious the Challenged Claims to a person of ordinary skill in the

art (POSITA) when the ’799 patent was filed.

V. Description of the Technology

A. Evolution of Computer Storage Systems

Before the priority date of the ’799 patent, computer storage systems— including devices such as disk drives—were well-known. CSCO-1004, ¶¶21-22.

Such storage devices allowed data to be stored in granularity of blocks, each block having a unique address for access. CSCO-1004, ¶23. As computers’ storage needs evolved over time, new techniques for organizing and storing data were explored. By the early 2000s, many individuals were working on storage techniques that came to be known as object-based storage systems. CSCO-1004,

¶24-29; see generally CSCO-1034.

As computer storage systems evolved from block-based to object-based file systems, the terminology used to describe them also evolved. CSCO-1004, ¶¶29-

36. Initially, some people in the field continued to use the term “block” to refer to

15 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 the new file system constructs. CSCO-1004, ¶36; CSCO-1008, p.202 (“DHash —

Stores unstructured data blocks”); CSCO-1007, pp.34, 35, Fig. 2. Some individuals would use multiple terms almost interchangeably, allowing context to clarify. CSCO-1004, ¶36; CSCO-1034, pp.3, 4. Eventually, those in the art came to use the term “object” when discussing the new file system constructs. CSCO-

1004, ¶¶36-38; CSCO-1050, p.50 (“DHash stores the copies of all the objects…”);

CSCO-1015, p.93, Fig. 1; CSCO-1016, pp.84, 87; see also CSCO-1056, ¶¶12-13,

24 (showing articles are prior art). By the time of the ’799 patent, the field had settled on the terminology to distinguish “blocks” from “objects,” but it must be remembered that this was not always the case, especially when considering papers published earlier in the development of object-based storage. CSCO-1004, ¶¶36-

38.

B. Cryptographic Hash

A POSITA would have been familiar with cryptographic hash functions,

which were well-known before the priority date of the ’799 patent. CSCO-1004,

¶¶39-41; CSCO-1018, p.2; CSCO-1032, p.30. A hash function is a function that

maps any input to a fixed size output, also known as a “fingerprint,” “hash digest,”

or simply “hash.” CSCO-1004, ¶¶39-40; CSCO-1017, p.1; CSCO-1018, pp.3, 4;

CSCO-1032, p.30. A cryptographic hash function has a very low probability of

two inputs producing the same hash output, making it suitable for cryptographic

16 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 purposes. CSCO-1004, ¶39. Cryptographic hash functions have been used for many decades. CSCO-1004, ¶40; CSCO-1007, p.32; CSCO-1018, pp.2, 3; CSCO-

1032, p.30. For example, Secure Hash Algorithm (SHA) is a family of cryptographic hash functions (including SHA-1) developed in the 1990s. CSCO-

1004, ¶¶40-41; CSCO-1007, p.32; CSCO-1018, p.4; CSCO-1028, Abstract.

C. The ’799 Patent

1. Summary of the ’799 Patent

The ’799 patent relates to “computer file system data structures and to methods and apparatus for the naming and storing of files.” CSCO-1001, 1:6-8.

The ’799 patent alleges that legacy (prior art) file systems exercise “tight control of the what (content) and the where (placement of data),” which “results in an architecture that is difficult to extend to modern storage needs.” Id., 6:57-61.

To alleviate the alleged inefficiencies in prior art file systems, the ’799 patent purports to provide “new data structures … for implanting a new file system.” Id., 6:66-7:1. The ’799 file system includes a namespace file system and an object store, as illustrated in Fig. 1:

17 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Namespace file system

Object store

CSCO-1004, ¶¶43-44; CSCO-1001, Fig. 1 (annotated).

Like admitted prior art file systems, the namespace file system described in the ’799 patent “has files, a directory structure, links, a superblock, and so forth.”

CSCO-1001, 8:48-49, 6:21-30, 6:36-43. The patent attempts to differentiate its system from the prior art, in that “the namespace file system doesn’t contain any data directly, instead all data is stored in objects.” CSCO-1001, 8:50-51.

The ’799 patent describes an “object store,” which in one embodiment “is a

flat collection of opaque data (objects).” Id., 8:9-10. “Each object is unique” and

“may be of varying size.” Id., 8:10, 11:2-5. “The object may be raw data, or

metadata (e.g., a record of the creation of and any changes to the raw data).” Id.,

18 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

15:35-37. Fig. 2 illustrates the object store 108 in further detail:

Objects

CSCO-1004, ¶¶45-46; CSCO-1001, Fig. 2 (annotated).

In the ’799 patent, the name of an object is derived from the object’s content using, for example, a cryptographic hash. See CSCO-1001, 7:32-35, 8:12-16.

“This enables the object name to be globally unique and identifiable, i.e., a fingerprint of the [object’s] content.” CSCO-1001, 7:33-36. The ’799 patent gives, as an example, the Secure Hash Algorithm (SHA) hash function, which it describes as providing a “sufficiently strong cryptographic hash [that] is acceptable for generating object names (fingerprints).” CSCO-1001, 8:16-21. The namespace file system uses the globally unique object fingerprint (i.e., object name) to access

19 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 objects stored in the object store. CSCO-1001, 15:65-16:3. This is accomplished with various mapping structures, which “map” object fingerprints to the underlying objects. See, e.g., CSCO-1001, Abstract, 7:7-67, 13:37-38.

2. Prosecution History

The ’799 patent issued from U.S. App. No. 12/823,922 filed on June 25,

2010, claiming the benefit of U.S. Provisional App. No. 61/269,633, filed on June

26, 2009. CSCO-1001. During prosecution, the Examiner rejected the claims in light of various prior art references.1 CSCO-1002, pp.116, 126-127, 301. The

applicant amended the claims to require a mapping system based on objects, with

each object having a fingerprint derived from its contents. In particular, the claims

were amended to recite “an inode map object,” “directory objects comprising a

mapping of inode numbers and file names,” and “each of the inode map object and

directory object has its own object fingerprint derived from the content of the

respective object.” CSCO-1002, pp.48, 148.

3. Previous IPR Proceedings

The ’799 patent was the subject of two prior IPR proceedings. See CSCO-

1019, p.2; CSCO-1021, p.2. The Office denied both IPR petitions. See CSCO-

1040, p.14; CSCO-1041, p.14.

1The applicants also overcame rejections under 35 U.S.C. §§ 101 and 112.

20 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

D. Page Citations and Quotations

Petitioner cites to exhibits’ original page numbers where possible. Unless otherwise indicated, bold italic emphasis in quoted material has been added.

Claim language is quoted in italics throughout to distinguish it from other quoted

material.

VI. Identification of Challenges and Claim Construction

A. Challenged Claims

Petitioner challenges claims 1-22 and 26-36.

B. Claim Construction

This petition applies the broadest reasonable interpretation in light of the specification. See 37 C.F.R. § 42.100(b). Under the broadest reasonable

construction, claim terms are given their ordinary meaning as would be understood

by one of ordinary skill in the art in the context of the entire disclosure. In re

Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Petitioner may

advocate a different claim interpretation in forums applying a different standard.

Constructions for some terms in the claims have been previously provided by the Patent Owner in the prior IPR proceedings, as discussed below. For terms not addressed below, Petitioner submits that no specific construction is necessary for this proceeding.

1. “namespace file system” (all claims)

21 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

The ’799 patent recites the term “namespace file system” in the claims and

specification. The ’799 patent describes that, in one embodiment, a “namespace

file system… has files, a directory structure, links, a superblock, and so forth.”

CSCO-1001, 8:48-49. The ’799 patent, however, does not provide an express

definition for a “namespace file system.” See id.

In the two previous IPR proceedings against the ’799 patent, the petitioner

proposed the following construction: “The term ‘namespace file system’ should be

construed to mean ‘a file system that accesses data and metadata as objects that are

referred to by name.’” CSCO-1019, pp.23-24, CSCO-1021, pp.25-26. The patent

owner disagreed, taking the position that “[t]he ’799 Patent does not provide a

special definition of ‘namespace file system’ that strays from the well-understood

plain and ordinary meaning of the term.” CSCO-1020, p.22, CSCO-1022, p.25.

According to the patent owner, the well understood meaning of the term

“namespace file system” in the art of computer science at large, and specifically in

the file systems space, is “a file system that uses names.” Id.

This petition applies the Patent Owner’s claim construction of “namespace file system” as meaning “a file system that uses names.” CSCO-1004, ¶¶75-79.

2. “object” (all claims)

As of the ’799 patent’s priority date, the term “object” had a well understood meaning to a POSITA. CSCO-1004, ¶80. The ’799 patent does not specially

22 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 define “object,” but rather uses the term according to its plain and ordinary meaning. CSCO-1004, ¶80. This is confirmed by the patent owner in the prior

IPR proceedings. CSCO-1020, p.13; CSCO-1022, p.16. As such, the term

“object” in the ’799 patent should have its plain and ordinary meaning.

In the prior IPR proceedings, however, the patent owner argued that “object” stands in contrast to “block” as follows:

[A] block of a block storage system should be understood as “a generally fixed sized portion of a disk.” An “object,” by contrast, is not associated with a fixed amount of disk space; it simply means “a logical abstraction of variable size of data, such as a file.” CSCO-1020, p.15, CSCO-1022, p.17.

This petition applies the plain and ordinary meaning of the term “object.”

CSCO-1004, ¶¶81-85. However, as also discussed below, the prior art also renders the claims obvious under the Patent Owner’s alternative construction of “a logical abstraction of variable size of data, such as a file.” CSCO-1004, ¶¶81-85, 194-197.

3. “program code means which, when executed by a process, performs the steps of method claim 19” (claim 27)

This is a means-plus-function limitation. The corresponding structure in the specification is a computer program written in any form of programming language.

CSCO-1001, 16:56-66; CSCO-1004, ¶¶87-88. Accordingly, the broadest reasonable interpretation is “a computer program that, when executed, performs

23 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 the steps of claim 19.” CSCO-1004, ¶88.

C. Statutory Grounds for Challenges

Challenge #1: Claims 1-4, 7-9, 11-14, 17-22, 27, 28, and 31-35 are obvious under 35 U.S.C. § 103 over “Ivy: A Read/Write Peer-to-Peer File System,”

authored by Muthitacharoen et al. (“Muthitacharoen,” CSCO-1007), and “Wide- area cooperative storage with CFS,” authored by Dabek et al. (“Dabek,” CSCO-

1008).

Muthitacharoen was published in the Winter 2002 special issue of Operating

Systems Review journal, which was received by the George Washington University

Library on April 3, 2003, and available to the public shortly thereafter. CSCO-

1054, ¶¶16, 24; see generally, CSCO-1054, ¶¶16-27. Dabek was published in the

December 2001 issue of Operating Systems Review journal, which was received by the Library of Congress on October 29, 2001, and was available to the public shortly thereafter. CSCO-1054, ¶¶28, 36; see generally, CSCO-1054, ¶¶28-48.

Accordingly, Muthitacharoen and Dabek are prior art under 35 U.S.C. § 102(b).

Challenge #2: Claims 5 and 6 are obvious under 35 U.S.C. § 103 over

Muthitacharoen, Dabek, and “Design Tradeoffs for SSD Performance,” authored by Agrawal et al. (“Agrawal,” CSCO-1009). Agrawal was presented at a conference, published the proceedings given to conference attendees, and published on the USENIX website on June 25, 2008. CSCO-1055, ¶¶13, 15, 18;

24 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 see generally, CSCO-1055, ¶¶3-19. Agrawal is prior art under 35 U.S.C. § 102(b).

Challenge #3: Claims 10, 15, and 26 are obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and THE DESIGN AND IMPLEMENTATION OF THE

FREEBSD OPERATING SYSTEM by Marshal McKusick et al. (“McKusick,” CSCO-

1011). McKusick was accessible to the public at the Library of Congress around

November 26, 2004, and is prior art under 35 U.S.C. § 102(b). CSCO-1054, ¶56; see generally, CSCO-1054, ¶¶49-64.

Challenge #4: Claims 29 and 30 are obvious under 35 U.S.C. § 103 over

Muthitacharoen, Dabek, and U.S. Patent No. 8,140,786 to Bunte et al. (“Bunte,”

CSCO-1039). Bunte was filed on December 4, 2007, and published as

US2008/0229037 on September 18, 2008, and is therefore prior art under 35

U.S.C. §§102(a) and (e).

Challenge #5: Claims 16 and 36 are obvious under 35 U.S.C. § 103 over

Muthitacharoen, Dabek, and U.S. Patent No. 8,028,106 to Bondurant et al.

(“Bondurant,” CSCO-1010). Bondurant was filed on July 3, 2008, published as

U.S. Publication No. 2009/0013140 on January 8, 2009, and is therefore prior art

under 35 U.S.C. §§102(a) and (e).

D. Petitioner’s Challenges Are Not Cumulative or Duplicative of Prior Patent Office Proceedings

This petition is Petitioner’s first challenge, of any kind, raised against the

’799 patent at the Patent Office. Furthermore, this petition presents new arguments

25 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 and new references never previously considered by the Office for any claim.

Specifically, the Office has never evaluated Muthitacharoen, Dabek, Agrawal,

McKusick, Bunte, or Bondurant regarding the ’799 patent. Additionally, the prior

IPR proceedings challenged only on a subset of claims compared to the claims challenged in this petition. Finally, the prior IPR proceedings did not benefit from analysis and explanation of the prior art provided by Dr. Shenoy. See CSCO-1004.

The previous IPR proceedings are therefore no basis for denying this petition under

35 U.S.C. § 325(d) because “those cases do not address the merits of any ground raised in the Petition[].” See IPR2015-00547, Paper 25 at 23.

E. Identification of How the Construed Claims Are Unpatentable

1. Challenge #1: Claims 1-4, 7-9, 11-14, 17-22, 27, 28, and 31-35 are obvious over Muthitacharoen and Dabek

a. Summary of Muthitacharoen

Muthitacharoen describes Ivy, a “multi-user read/write peer-to-peer file

system.” CSCO-1007, p.31. “Ivy does not require a dedicated server; instead, it

stores all data and meta-data in the DHash [9] peer-to-peer block storage system.”

CSCO-1007, p.31.

Like the system in the ’799 patent, the DHash storage system identifies

stored data using a hash value computed from the stored data. CSCO-1007, p.32.

DHash uses the SHA-1 hash algorithm for computing these hash values, which are

then used as keys for storing and retrieving the corresponding data. CSCO-1007,

26 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 p.32.

Ivy employs “a set of logs” and “stores its logs in DHash.” CSCO-1007, p.31. Muthitacharoen shows in Table 2 the types of log records, including log records for creating files and directories, writing data to a file, and removing files.

CSCO-1007, p.34.

“Each Ivy participant periodically constructs a private snapshot of the file system in order to avoid traversing the entire log.” CSCO-1007, p.35. “A snapshot contains the entire state of the file system.” CSCO-1007, p.35. Like the log records, Ivy’s snapshot data structure is stored in DHash to make it persistent.

CSCO-1007, p.35. As Muthitacharoen illustrates in Fig. 2 (below), the snapshot data structure stored in DHash includes the contents of files, directories, and meta- data. The components of the file system refer to one another using hash values

(e.g., H(F)):

27 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

CSCO-1007, p.35.

b. Summary of Dabek.

Dabek describes further details of the DHash storage system into which Ivy stores all data and meta-data. CSCO-1008, p.202. Similar to Muthitacharoen,

Dabek describes a peer-to-peer file system, called “Cooperative File System

(CFS),” that stores data in DHash. CSCO-1008, p.202.

Dabek explains that DHash stores the data in each data block on multiple

servers. See CSCO-1008, p.207 & Fig. 1. Dabek’s CFS servers run on “machines

scattered over the Internet” and can be “nodes” or “ordinary Internet hosts.”

CSCO-1008, p.205, 210.

Figure 1 illustrates the structure of the CFS system:

28 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

CSCO-1008, p.204.

As seen from Fig. 1 above, “[t]he CFS client software layers a file system on top of DHash.” CSCO-1008, p.209. “The client file system FS uses the DHash layer to retrieve blocks” stored in the CFS servers. CSCO-1008, p.204.

c. Reasons to Combine Muthitacharoen and Dabek

A POSITA would have found it obvious to combine the teachings of

Muthitacharoen and Dabek. CSCO-1004, ¶¶141-146.

First, Muthitacharoen explicitly cites Dabek as a reference providing further details about the DHash storage system. CSCO-1007, p.31 (“the DHash [9] peer- to-peer block storage system”) & p.43 (“[9] F. Dabek,… Wide-area cooperative storage with CFS”). Therefore, Muthitacharoen would have directed a POSITA to consider the teachings of Dabek for further information about the concepts discussed in Muthitacharoen. CSCO-1004, ¶142. This fact, alone, provides

29 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 sufficient motivation to combine their teachings.

Second, both Muthitacharoen and Dabek are analogous in that they each describe a peer-to-peer file system that uses the DHash storage system.

Muthitacharoen describes Ivy, “a multi-user read/write peer-to-peer file system” that “stores all data and meta-data in the DHash [9] peer-to-peer block storage system.” CSCO-1007, p.31. Dabek similarly describes a peer-to-peer file system that uses “a distributed hash table (DHash) for block storage.” CSCO-1008, p.202.

Both Muthitacharoen and Dabek recognize various challenges associated with designing shared peer-to-peer file systems used by unmanaged participants, and propose solutions to address these challenges. CSCO-1007, p.31; CSCO-1008, p.202.

Because Muthitacharoen describes storing and retrieving data using the

DHash storage system, and Dabek describes in detail how the DHash storage system stores and retrieves data, a POSITA would have found it obvious to combine the teachings of Muthitacharoen and Dabek. CSCO-1004, ¶145. For instance, it would have been obvious for a POSITA to supplement the description of the DHash storage system in Muthitacharoen with the detailed description of the same DHash system in Dabek. CSCO-1004, ¶145. The combination of

Muthitacharoen and Dabek would have yielded predictable results of the Ivy file system, described in Muthitacharoen, operating according to the known techniques

30 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 for storing data to and retrieving data from the DHash storage system. CSCO-

1004, ¶145.

d. Detailed Claim Analysis

Claim 1 [1.0] “A computer file system for naming and storing of files on one or more computer storage devices, the system comprising:” Muthitacharoen and Dabek render obvious this preamble.

First, Muthitacharoen discloses “a computer file system” because

Muthitacharoen teaches “Ivy is a multi-user read/write peer-to-peer file system”

running on “a 1.2 GHz AMD Athlon computer running FreeBSD 4.5 at MIT.”

CSCO-1007, pp. 31, 38.

Second, Ivy names a newly created file using a file name received with a

create request: “The request contains … a file name. Ivy appends an Inode log

record with a new random i-number and a Link record that contains … the file’s

name.” CSCO-1007, p.33. The names of files are stored in directory inode

blocks, which “hold a list of name/i-number pairs.” CSCO-1007, p.35.

Muthitacharoen also teaches Ivy “stores all data and meta-data in the DHash [9]

peer-to-peer block storage system,” and supports writing to a file. CSCO-1007,

p.31, 33. A file is stored as an i-node that “contains file attributes as well as a list

of DHash keys of blocks holding the file’s contents.” CSCO-1007, p.35. “Each i-

node is stored in its own DHash block.” CSCO-1007, p.35. Thus, Muthitacharoen

31 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 discloses that the Ivy file system is “for naming and storing of files.” CSCO-1004,

¶¶174-179.

Third, Dabek describes that DHash, in turn, stores data on multiple CFS servers. CSCO-1008, p.204 (“Each CFS server has two software layers: a DHash storage layer and a Chord layer. The server DHash layer is responsible for storing keyed blocks…”), p.207 (“DHash replicates each block on CFS servers to increase availability”); Fig. 1.

Multiple CFS servers

CSCO-1004, ¶¶180-183; CSCO-1008, p.204 (annotated).

Dabek also explains that “CFS servers run[] on a testbed of 12 machines scattered over the Internet” and “could be ordinary Internet hosts,” which are simply computers connected to a network. CSCO-1008, pp.4, 9; CSCO-1026,

32 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 p.256; see also CSCO-1056, ¶6 (showing CSCO-1026 published in 2003).

Because DHash stores data on servers that are computers, a POSITA would have understood that Dabek’s servers are “one or more computer storage devices.”

CSCO-1004, ¶¶184-186. Alternatively, a POSITA would have understood the servers to store data on hard disk drives, the most common “computer storage” device at the time. CSCO-1004, ¶149.

Thus, the Ivy file system for naming and storing files in DHash, which comprises multiple servers, as disclosed by Muthitacharoen and Dabek, renders obvious “A computer file system for naming and storing of files on one or more

computer storage devices.” CSCO-1004, ¶187.

[1.1] “a namespace file system accessing an object store,”

As discussed above, “namespace file system” is interpreted to include “a file

system that uses names.” CSCO-1004, ¶¶76-79, 188.

As discussed in [1.0], Muthitacharoen describes the Ivy file system, which

uses names, for example, when creating or reading a file. CSCO-1007, p.33 (“A

LOOKUP request contains a file name…” & “…an NFS CREATE request…

contains… a file name.”). The Ivy file system also includes a directory inode

block, which “hold[s] a list of name/i-number pairs.” CSCO-1007, p.35. In Table

2, Muthitacharoen discloses additional instances in which the Ivy file system uses

names, such as with the “Link,” “Unlink,” “Rename,” “Prepare,” and “Cancel” log

33 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 record types. CSCO-1007, p.34.

Because Muthitacharoen discloses that the Ivy file system uses names,

Muthitacharoen discloses “a namespace file system.” CSCO-1004, ¶188-191.

Muthitacharoen also discloses the Ivy file system “accessing an object store.” First, Muthitacharoen discloses that Ivy stores all data and metadata in the

DHash storage system, including in a snapshot data structure having directory inode, file inode, directory inode block, and data blocks as shown in Fig. 2.

CSCO-1007, p.31, 35, Fig. 2.

CSCO-1007, p.35.

Second, the claim limitation “accessing an object store” contains the term

34 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

“object,” which should have its plain and ordinary meaning.

Object-based storage systems were in their infancy when Muthitacharoen

was published, and the terminology in the field was still evolving at that time and

was not standardized. CSCO-1004, ¶110. While Muthitacharoen does not

expressly use the word “object,” based on Muthitacharoen’s detailed description of

the Ivy file system and its underlying DHash storage system, a POSITA would

understand various data structures in the snapshot data structure (e.g., snapshot

block, directory inode D, file inode F, directory inode block E, and data blocks B1,

B2), taken separately or in various combinations, are “objects” under the plain and

ordinary meaning of the term. CSCO-1004, ¶¶110-112; see also CSCO-1050, p.50

(“DHash stores the copies of all the objects…”).

These various data structures in Muthitacharoen would also be “objects” under the construction of the term proposed by the patent owner in the prior IPR proceedings—i.e., “An ‘object,’ […] is not associated with a fixed amount of disk space; it simply means ‘a logical abstraction of variable size of data, such as a file.’” A POSITA would understand that files can be of variable size depending on the amount of data contained in them and directories can be of variable size depending on the number of files contained in them. CSCO-1004, ¶113.

Consequently, meta-data for files and directories such as inodes and inode block will also have variable size. CSCO-1004, ¶113. Furthermore, Dabek—like

35 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Muthitacharoen—stores file data in DHash blocks and states that “The maximum size of any block is on the order of tens of kilobytes.” CSCO-1008, p.204. A

POSITA would have understood from Dabek’s statement that DHash blocks do not have a fixed size, but instead are variable-sized (up to a maximum). CSCO-1004,

¶¶35, 323-325. Finally, Muthitacharoen discloses that these data structures are identified by various keys (e.g., H(D), H(F), H(E), H(B1), H(B2)), which are formed by a hash of the structure’s contents, and are, thus, also a logical abstraction of their contents. CSCO-1004, ¶113; CSCO-1007, p.35, Fig. 2.

Based on the above, Muthitacharoen discloses that the various data structures of Muthitacharoen’s snapshot data structure are “objects,” and that these

“objects” are stored in the DHash storage system. Thus, Muthitacharoen’s DHash

storage system discloses the “object store.” CSCO-1004, ¶¶192-198.

Muthitacharoen further teaches that the Ivy file system (“namespace file

system”) accesses the DHash storage system (“object store”) to retrieve the

contents of a stored object, or for other operations, such as file name lookup and

file read. CSCO-1004, ¶¶199-200; CSCO-1007, p.32, 33.

Thus, Muthitacharoen and Dabek render obvious “a namespace file system

accessing an object store,” as claimed.

[1.2] “the system including a memory and a hardware processor in communication with the memory,” Muthitacharoen teaches that Ivy runs on a “1.2 GHz AMD Athlon

36 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 computer,” which a POSITA would have understood to include a “hardware processor.” CSCO-1007, p.38; CSCO-1004, ¶¶202-203. A POSITA would have also understood that a computer employing an AMD Athlon processor would include a memory, such as dynamic random access memory, for storing information being processed by the processor, and instructions for controlling its operation. CSCO-1004, ¶¶204-207. Therefore, Muthitacharoen renders obvious

“the system including a memory and hardware processor in communication with the memory.”

[1.3] “the processor for executing program instructions for accessing the object store using object fingerprints,” Muthitacharoen further discloses that Ivy is programmed with instructions

“written in C++” (CSCO-1007, p.38), which a POSITA would understand execute on the AMD Athlon (“processor”). CSCO-1004, ¶¶208-211. Muthitacharoen further describes how the programmed processor accesses an interface to the

DHash storage system (“object store”): “Ivy uses DHash through a simple interface: put(key, value) and get(key).” CSCO-1007, p.32.

Muthitacharoen discloses that Ivy’s key k, used with the “get(k)” command, is a

SHA-1 cryptographic hash of the value v, or contents, of the associated data

structure. CSCO-1007, p.32. Ivy’s SHA-1 cryptographic hash keys are “object fingerprints,” similar those described in the ’799 patent, that uniquely identify the associated data structures. CSCO-1004, ¶¶212-214; CSCO-1001, 30:5-7. Thus,

37 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Muthitacharoen renders obvious “the processor for executing program instructions

for accessing the object store using object fingerprints.” CSCO-1004, ¶ 215.

[1.4] “the object store holding files, data and metadata as objects,” As discussed in [1.1], Muthitacharoen discloses the DHash storage system

(“object store”), which stores the snapshot data structure as a collection of objects.

Fig. 2 of Muthitacharoen shows the data (e.g., data blocks B1, B2 for file inode F) and metadata (of snapshot block) stored in the DHash storage system:

Metadata stored in DHash

file stored in DHash

data stored in DHash

CSCO-1004, ¶¶216-218; CSCO-1007, p.35 (annotated).

Muthitacharoen teaches that all of the blocks (in various combinations,

“objects”) shown in Fig. 2 (collectively, a snapshot data structure) are stored in

DHash: “Participants store their snapshots in DHash.” CSCO-1007, p.35.

38 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Thus, Muthitacharoen discloses “the object store holding files, data and metadata as objects.” CSCO-1004, ¶¶216-218.

[1.5] “each object having a globally unique object fingerprint derived from the content of the object and used to access the object store,” As discussed in [1.1], Muthitacharoen teaches “objects” in the form of data structures stored in the DHash snapshot (e.g., snapshot block, directory inode D, file inode F, directory inode block E, and data blocks B1, B2, taken separately or in various combinations). Muthitacharoen also teaches that each of these objects that

“make up a snapshot are content-hash blocks,” each of which “requires the block’s key to be the SHA-1 [10] cryptographic hash of the block’s value.”

CSCO-1007, p.32, Fig. 2. A POSITA would have considered Ivy’s keys (“object fingerprints”) calculated using the SHA-1 cryptographic function to be unique with respect each other. CSCO-1004, ¶¶219-222; CSCO-1001, 8:43-46. Therefore, a

POSITA would have understood that the SHA-1 hash value is a “globally unique object fingerprint derived from the content of the object.” CSCO-1004, ¶223.

Ivy’s keys generated from the SHA-1 cryptographic hash are used for accessing files, directories, data and metadata from DHash, such as through the

“get(key)” interface. CSCO-1007, p.32, 35. Therefore, Muthitacharoen discloses “each object having a globally unique object fingerprint derived from the content of the object and used to access the object store.” CSCO-1004, ¶224-225.

39 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

[1.6] “wherein: each file object comprising a mapping of object fingerprints for the data objects or metadata objects of the file” Fig. 2 of Muthitacharoen shows that the DHash snapshot data structure includes a file inode F (“file object”) and its file contents, data blocks B1, B2, etc.

(“data objects”):

Mappings of object fingerprints for data objects of the file

Data objects of the file

File object

CSCO-1004, ¶226; CSCO-1007, p.35 (annotated).

Muthitacharoen further discloses in Fig. 2 that file inode F comprises keys

H(B1), H(B2), etc. (“object fingerprints”) pointing to respective data blocks B1,

B2, etc. (“data objects”) as indicated by the curved arrows. The purpose of an inode (short for index-node) is to maintain an index for the data contained in the file. CSCO-1007, p.35; CSCO-1004, ¶¶227-228. As shown in Fig. 2, the first entry in the index of file inode F (“file object”) contains the key H(B1) (“object

40 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 fingerprint”) for block B1 (“data object”), the second entry stores the key H(B2) for block B2, and so on, thus providing a mapping of object fingerprints for the data objects or metadata objects of the file. CSCO-1004, ¶¶229-230.

Thus, Muthitacharoen discloses “wherein: each file object comprising a mapping of object fingerprints for the data objects or metadata objects of the file.”

CSCO-1004, ¶231.

[1.7] “and the file object having its own object fingerprint derived from the fingerprints of the objects in the file,”

As discussed in [1.4] and [1.6], Muthitacharoen describes a file inode (“file object”). CSCO-1007, p.35. As Muthitacharoen illustrates in Fig. 2 (below), the file object has its own hash value H(F) (“own object fingerprint”) derived from the hash values H(B1) and H(B2) (“fingerprints”) of the blocks B1 and B2 (“objects in the file”) that comprise the contents of a file.

41 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Object fingerprint File object objects in derived from keys the file H(B1), H(B2), etc.

CSCO-1004, ¶¶232-234; CSCO-1007, p.35.

Thus, Muthitacharoen renders obvious “the file object having its own object fingerprint derived from the fingerprints of the objects in the file.” CSCO-1004,

¶235.

[1.8] “and wherein the object store further includes: an inode map object comprising a mapping of file system inode numbers and object fingerprints”

Muthitacharoen describes maintaining a “snapshot block” that provides a mapping between the Ivy file system’s i-numbers (“inode numbers”) and the content-hash values, or keys (“object fingerprints”) for the corresponding blocks

(“objects”) stored in DHash (“the object store”). CSCO-1007, p.35; CSCO-1004,

¶237-238. Thus, the snapshot block is “an inode map object comprising a

42 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 mapping of file system inode numbers and object fingerprints.” CSCO-1004,

¶237-238. The snapshot block is illustrated in Fig. 2:

object fingerprint

file system inode number

Inode map object

CSCO-1004, ¶236; CSCO-1007, p.35 (annotated).

Muthitacharoen discloses that “Participants store their snapshots in DHash”

(“the object store”). CSCO-1007, p.35. Thus, Muthitacharoen teaches “wherein the object store further includes: an inode map object….” CSCO-1004, ¶236.

[1.9] “enabling the inode numbers to stay constant while the object fingerprints change as the file content changes;”

Muthitacharoen teaches that each file and directory in Ivy is identified by an i-number (“inode number”) assigned at the time of creation:

File creation. When an application creates a new file, the kernel NFS client code sends the local Ivy server an NFS

43 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

CREATE request. The request contains the directory i-number and a file name. Ivy appends an Inode log record with a new random i-number and a Link record that contains the i-number, the file’s name, and the directory’s i-number. Ivy returns the new file’s i-number in a file handle to the NFS client.

CSCO-1007, p.33.

An application writes data to the file by sending a “WRITE request” using the assigned i-number. CSCO-1007, p.33. When an application sends a “READ request” identifying the file’s i-number, “Ivy scans the log accumulating data from

Write records” pertaining to the file. CSCO-1007, p.33. Since the same i-number is used for writing data to a file multiple times (thereby creating multiple “Write records”) and subsequently reading the file, a POSITA would have understood that the i-number (“inode number”) does not change (“stay[s] constant”) when data is written to a file. CSCO-1004, ¶¶239-243. Accordingly, Muthitacharoen renders obvious “enabling the inode numbers to stay constant.” Id.

While the i-number stays constant, however, the DHash key (“object fingerprint”) will change when the file content changes. As discussed in [1.3] and

[1.5], the SHA-1 hash values (used as DHash keys) depend on the content of the

DHash block. CSCO-1007, p.32. As discussed in [1.5], the SHA-1 has a value that would have been considered “globally unique,” and therefore, that it was practically impossible to change the content of a file without also changing its

44 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

SHA-1 hash value (“object fingerprint”). CSCO-1004, ¶244. Thus,

Muthitacharoen renders obvious that “the object fingerprints change as the file content changes.” CSCO-1004, ¶245.

[1.10] “and directory objects, each directory object comprising a mapping of inode numbers and file names;”

Muthitacharoen describes a DHash snapshot data structure that includes

“directory inode blocks” that, as shown in Fig. 2, include a mapping between i-

numbers (“inode numbers”) and names (“file names”). Although only one directory is shown in Fig. 2, a POSITA would have understood from the ellipses in the directory inode and snapshot block that the Ivy file system allows for many directories, and hence, multiple directory inode blocks (“directory objects”).

CSCO-1004, ¶246-249. Thus, Muthitacharoen teaches “directory objects, each directory object comprising a mapping of inode numbers and file names.”

45 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Directory object

inode number

file name

CSCO-1004, ¶246; CSCO-1007, p.35 (annotated).

[1.11] “wherein each of the inode map object and directory object has its own object fingerprint derived from the content of the respective object.”

As discussed in [1.8] and [1.10], Muthitacharoen describes a snapshot block

(“inode map object”) and a directory inode block (“directory object”), which—as illustrated in Fig. 2 below—are both part of the snapshot data structure:

46 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Inode map object

Directory object

CSCO-1004, ¶¶250-251; CSCO-1007, Fig. 2, p.35.

Muthitacharoen teaches that “All of the blocks that make up a snapshot [data structure] are content-hash blocks.” CSCO-1007, p.35. As discussed above in

[1.3] and [1.5], a content-hash block is identified by a key that is the SHA-1 cryptographic hash of the block’s contents (“object fingerprint derived from the content of the respective object”). CSCO-1007, p.31; CSCO-1004, ¶252-255.

Thus, the snapshot block (“inode map object”) and directory inode block

(“directory object”) each have their own SHA-1 hash key (“own object

fingerprint”). CSCO-1004, ¶256. Accordingly, Muthitacharoen renders obvious

“wherein each of the inode map object and directory object has its own object

fingerprint derived from the content of the respective object.” Id.

47 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

[2.0] The file system of claim 1, [2.1] wherein: object references are mapped by the object fingerprints.

Muthitacharoen illustrates in Fig. 2 (below) that an object stored in DHash is referenced using its hash value (“object fingerprint”). CSCO-1004, ¶258. A

POSITA would have understood the figure is simply an example, and that

Muthitacharoen contemplated the Ivy file system including multiple “object references” that “are mapped by the object fingerprints.” CSCO-1004, ¶258-259.

file object

object fingerprint object reference mapped by object fingerprint

CSCO-1004, ¶258; CSCO-1007, p.35 (annotated).

[3.0] The file system of claim 2, [3.1] further comprising: the object store contains an index of object fingerprints, object locations and object reference counts.

Muthitacharoen discloses a snapshot data structure, shown in Fig.2 (below)

48 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 which acts as an “index” to facilitate access to files. The snapshot data structure, stored in DHash (“object store”), includes a “file map” that “records the DHash key of the i-node associated with each i-number.” CSCO-1007, p.35. As discussed above in [1.3], each DHash key is an “object fingerprint.” Dabek explains that the DHash key also operates as the “object location.” Specifically, each server storing data has “an identifier drawn from the same 160-bit identifier space as block identifiers.” CSCO-1008, p.202. The server whose identifier most closely follows a block’s DHash key is termed the block’s “successor” and is responsible for storing the block. CSCO-1008, p.202, 207; CSCO-1004, ¶261-265.

Thus, the DHash key identifies which server stores the block, and hence, the block’s “object location.”

CSCO-1007, p.35.

49 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Muthitacharoen describes calculating a “link count,” which is “the number

of links to a file.” CSCO-1007, p.33. A POSITA would have understood that the

“link count” is an “object reference count.” CSCO-1004, ¶¶266-268. It would have been obvious to a POSITA to store the link count for each file in the snapshot data structure to avoid requiring a scan of Ivy’s entire log every time a link count needs to be determined. CSCO-1004, ¶¶269-272. Scanning through the log would be inefficient and potentially time consuming, and therefore, undesirable. CSCO-

1004, ¶272. It also would have been obvious to a POSITA because the link count is part of the file system’s state, and Muthitacharoen teaches that the “snapshot contains the entire state of the file system.” CSCO-1007, p.35; CSCO-1004, ¶272.

[4.0] The file system of claim 3, wherein: [4.1] the object store index is stored in non-volatile memory.

As discussed in [3.1], Muthitacharoen discloses a snapshot data structure that is an “index” to data stored in DHash (“object store”). Thus, the snapshot data

structure is “the object store index.” CSCO-1004, ¶274.

Muthitacharoen teaches that users of the Ivy file system “store their

snapshots in DHash to make them persistent.” CSCO-1007, p.35. A POSITA

would have recognized that “persistent” storage is effectively synonymous with

“non-volatile memory.” CSCO-1004, ¶¶274-275; CSCO-1026, pp.367, 399

(providing similar definitions of “persistent storage” and “non-volatile memory”).

Since DHash stores the snapshot data structure persistently, it would have been

50 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

obvious to a POSITA that the “object store index is stored in non-volatile

memory.” CSCO-1004, ¶276.

[7.0] The file system of claim 1, [7.1] wherein: the file object mapping comprises a linear list, a tree structure or an indirection table.

294. As discussed above in [1.6], Muthitacharoen teaches a file inode (“file object”) that includes a mapping of hash values, or keys, to respective data blocks.

Thus, the file inode includes a “file object mapping.” CSCO-1004, ¶297. The

example file inode illustrated in Fig. 2 (below) shows that the file inode F includes

a linear list of hash values:

Mappings of linear list of object fingerprints for data objects of the file

Data objects of the file

File object mapping including a linear list of object fingerprints

CSCO-1004, ¶297; CSCO-1007, p.35 (annotated).

51 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Thus, Muthitacharoen’s example file inode F renders obvious “the file object

mapping comprises a linear list, a tree structure, or an indirection table.” CSCO-

1004, ¶298.

[8.0] The file system of claim 1, wherein: [8.1] the file objects include a root object…

As discussed below and in [1.8], Muthitacharoen’s snapshot block identifies

the DHash key (“object fingerprint”) of every file and directory stored in the Ivy file system. CSCO-1004, ¶301. Accordingly, the snapshot block is a “root object.” Id. A POSITA would have understood that the snapshot block is one of the “file objects” in the Ivy file system because computers used “several types of files,” including “system files” and “special files.” CSCO-1029, p.383; CSCO-

1004, ¶300; see also CSCO-1056, ¶2 (showing CSCO-1029 published in 2001).

Similar to a directory, the snapshot block is a “system file[] for maintaining the structure of the file system.” CSCO-1029, p.383; see also CSCO-1011, p.621

(defining “directory” as “a special type of file that contains entries that are references to other files”). Accordingly, a POSITA would have considered the snapshot block (“root object”) to simply be a special type of “file object” in the Ivy file system. CSCO-1004, ¶300.

[8.1] …having its own object fingerprint derived from all of the objects in the file system…

“Ivy stores the snapshot block in DHash under its content-hash,” so the

52 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 snapshot block also has its own DHash key (“its own object fingerprint”). CSCO-

1007, p.35, 32; CSCO-1004, ¶¶301-303.

As Muthitacharoen illustrates in Fig. 2, the content of the snapshot block includes the hash values of directory inodes and file inodes, which in turn include the hash values of directory inode blocks and data blocks, respectively. The content of the snapshot block—and therefore its DHash key—is “derived from all of the objects in the file system.” Id. Thus, Muthitacharoen’s snapshot block renders obvious “a root object having its own object fingerprint derived from all of the objects in the file system.”

root object

CSCO-1004, ¶301; CSCO-1007, p. 35 (annotated).

53 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

[8.1] …such that every object in the file system is accessible through the root object.

Muthitacharoen teaches that a “snapshot contains the entire state of the file system” and that “Ivy finds information in a snapshot based on i-number.” CSCO-

1007, p.35. As Fig. 2 shows below, locating a file or directory, identified by i- number, requires referencing the snapshot block (“root object”) to determine the corresponding DHash key for the file or directory:

Directory object E is accessible through the root object

File object F and its data blocks are accessible through the root object

root object

CSCO-1004, ¶304; CSCO-1007, p.35 (annotated).

The snapshot block also includes “a version vector referring to the most recent record from each log that the snapshot incorporates.” CSCO-1007, p.35.

Each log record includes a “prev field contain[ing] the previous [log] record’s

54 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

DHash key.” CSCO-1007, p.32 & Fig. 1. Thus, all of the log records are linked together by their “prev” (previous) fields, and all of the linked log records are accessible through the “version vector” in the snapshot block (“root object”).

CSCO-1004, ¶305-306. Thus, Muthitacharoen renders obvious “such that every object in the file system is accessible through the root object.” CSCO-1004, ¶307.

[9.0] The file system of claim 8, wherein [9.1] a change of content of any file system object changes the root object and

As discussed above in [8.1], Muthitacharoen’s snapshot block (“root object”) contains the DHash keys (“object fingerprints”) derived from the contents of all of the files and directories stored in the file system. Muthitacharoen employs the SHA-1 cryptographic hash algorithm, which is the same algorithm described in the ’799 patent. CSCO-1007, p.31; CSCO-1001, 8:16-24. A POSITA would have understood that any change to SHA-1 algorithm’s input will cause a change in its output. CSCO-1004, ¶309. Any change to a file or directory in Ivy’s file system will change the DHash key stored in the snapshot block for that file or directory’s corresponding i-number. Id. Thus, Muthitacharoen renders obvious “a change of content of any file system object changes the root object.” Id.

[9.2] tracking changes in the root object provides a history of file system activity.

Muthitacharoen’s Ivy file system provides “the whole operation history to every client.” CSCO-1007, p.42. This history is accessed through the “snapshot block [root object] that contains… a pointer to the previous snapshot.” CSCO-

55 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

1007, p.35. The previous snapshot, in turn, would further include a pointer to the snapshot that preceded it. CSCO-1004, ¶310-311. Each snapshot “contains the entire state of the file system” as of a “point in time.” CSCO-1007, p.35, 32. The changes reflected in these snapshot blocks track the activity occurring in the file system over time. CSCO-1004, ¶311. Thus, Muthitacharoen renders obvious

“tracking changes in the root object provides a history of file system activity.”

[11.0] The file system of claim 1, wherein: [11.1] the fingerprint is an [sic] cryptographic hash digest of the object content.

As discussed above in [1.1], Muthitacharoen teaches storing files as blocks

(“objects”) in the DHash storage system where each block is identified by a DHash key (“fingerprint”). DHash “requires the block’s key to be the SHA-1 [10] cryptographic hash of the block’s value.” CSCO-1007, p.32. The ’799 patent identifies the SHA-1 algorithm as an example algorithm for producing cryptographic hash digests. CSCO-1001, 8:16-24. A block’s value is its “object content,” and therefore Muthitacharoen renders obvious that “the fingerprint is a[] cryptographic hash digest of the object content.” CSCO-1004, ¶¶39-40, 319-320.

[12.0] The file system of claim 1, wherein: [12.1] the object size is variable.

Muthitacharoen and Dabek render this limitation obvious. As discussed in

[1.4], Muthitacharoen’s Ivy file system stores all of its data as blocks (“objects”) in the DHash storage system. Muthitacharoen does not expressly refer to the sizes of

56 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 these blocks. Dabek explains that when DHash stores blocks such as “a piece of a file or a piece of file system meta-data”—as in Ivy’s file system—“[t]he maximum

size of any block is on the order of tens of kilobytes.” CSCO-1008, p.204.

Because Dabek refers only to a “maximum size” of a block, it would have been

obvious to a POSITA that some blocks could be smaller than the maximum size.

CSCO-1004, ¶323-324. Dabek does not even provide a specific number that is the

“maximum size,” but instead only refers to the general range of “on the order of

tens of kilobytes.” CSCO-1008, p.204. Thus, from Dabek’s description, it would

have been obvious to a POSITA that DHash does not employ fixed-sized blocks,

but instead, “the object size is variable.” CSCO-1004, ¶325.

[13.0] The system of claim 1, wherein: [13.1] the file system is a POSIX standard compliant file system.

Muthitacharoen teaches that “Ivy presents applications with a conventional

file system interface.” CSCO-1007, p.31. The Ivy file system “runs on FreeBSD,”

which a POSITA would have recognized as a POSIX-compliant operating system,

since both FreeBSD and the IEEE POSIX.1 standard are based on 4BSD. CSCO-

1004, ¶¶327-329; CSCO-1011, pp.7-11. Since FreeBSD is POSIX-compliant, a

POSITA would have understood that a “conventional file system interface” on

FreeBSD would also be “a POSIX standard compliant file system.” CSCO-1004,

¶329.

Muthitacharoen also teaches that Ivy provides the standard interfaces for

57 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 handling files, such as read, write, open, and close. CSCO-1004, ¶330; CSCO-

1007, p.36. The ’799 patent refers to such standard interfaces as an indication of

POSIX compliance. CSCO-1001, 9:58-59. For this additional reason,

Muthitacharoen renders obvious that “the file system is a POSIX standard compliant file system.”

Another engineer’s description of Muthitacharoen’s Ivy file system in 2006 confirms that skilled artisans considered Ivy to be a POSIX-compliant file system.

CSCO-1033, Table 2.5, p.37; CSCO-1004, ¶331.

[14.0] The file system of claim 1, wherein the object store further includes: [14.1] a location index that includes a reference count for each object, the reference count indicating the number of times the object is referenced.

As analyzed above in [3.1], Muthitacharoen discloses a snapshot data structure (“index”) stored in DHash (“object store”). The snapshot data structure includes a file map that lists the DHash key for every file and directory in the file system. CSCO-1007, p.35. The DHash key identifies the location of the corresponding block. CSCO-1004, ¶333. Thus, the snapshot data structure is a

“location index.” Id.

As also analyzed in [3.1], it would have been obvious to a POSITA for the snapshot data structure to include a link count (“reference count”) of the number of links to the block in the file system (“indicating the number of times the object is referenced”). CSCO-1004, ¶334.

58 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Thus, Muthitacharoen renders obvious “wherein the object store further

includes: a location index that includes a reference count for each object, the reference count indicating the number of times the object is referenced.” CSCO-

1004, ¶335-335.

[17.0] The file system of claim 1, including: [17.1] a stack wherein the object store comprises a lower portion of the stack and the file system comprises an upper portion of the stack.

As discussed above in [1.1], Muthitacharoen describes the Ivy file system

(“file system”) that stores data to a DHash storage system (“object store”).

Muthitacharoen further describes how “Ivy uses DHash through a simple interface: put(key, value) and get(key).” CSCO-1007, p.32. A POSITA would have understood, therefore, that Ivy depends on DHash and that, when the components are arranged in a stack, Ivy is organizationally above DHash. CSCO-

1004, ¶¶356-357.

Such a stacked arrangement of components is illustrated in Dabek, which shows (below) that a file system (“FS,” such as Muthitcharoen’s Ivy file system) in an upper portion of the stack, while DHash is in a lower portion of the stack.

CSCO-1004, ¶¶357-358.

59 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

upper portion of the stack

lower portion of the stack

CSCO-1004, ¶358; CSCO-1008, p.204 (annotated).

Thus, Muthitacharoen and Dabek render obvious “a stack wherein the object store comprises a lower portion of the stack and the file system comprises an upper portion of the stack.”

[18.0] The file system of claim 1, wherein: [18.1] the namespace file system and the object store are implemented in one or more of digital electronic circuitry, computer hardware, firmware, a computer program in a non-transitory machine-readable storage device, or combinations thereof.

As discussed above in [1.1], Muthitacharoen describes the Ivy file system

(“namespace file system”) that stores data in a DHash storage system (“object store”). Muthitacharoen teaches that Ivy and DHash can run “on the same computer.” CSCO-1007, p.39. Alternatively, there may be multiple “DHash servers on a WAN,” or wide-area network. CSCO-1007, p.39; CSCO-1004, ¶361.

A POSITA would have understood that the computer or computers running Ivy

60 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 and DHash would include “digital electronic circuitry” and “computer hardware.”

CSCO-1004, ¶¶361-362. Thus, Muthitacharoen renders obvious that “the namespace file system and the object store are implemented in one or more of digital electronic circuitry, [or] computer hardware….”

Muthitacharoen also discloses that Ivy “runs on FreeBSD,” a well-known

UNIX-like operating system. CSCO-1007, p.38; CSCO-1004, ¶361. It would have been obvious to a POSITA that a computer running FreeBSD would have a hard drive or other similar “non-transitory machine-readable storage device” storing the Ivy software as a “computer program.” CSCO-1004, ¶361. DHash also

operates on computers and servers, such “nodes[] running Linux 2.4.18 on 1.2

GHz Pentium II CPUs.” CSCO-1007, p.38; CSCO-1004, ¶363-365. Thus,

Muthitacharoen renders obvious that “the namespace file system and the object

store are implemented in… a computer program in a non-transitory machine- readable storage device.” CSCO-1004, ¶366.

[19.0] A method comprising:

Muthitacharoen describes the Ivy file system, which is implemented as

“software.” CSCO-1007, p.38. A POSITA would have understood that the Ivy software, when executed by a computer, performs a “method.” CSCO-1004, ¶367.

[19.1] a namespace file system accessing an object store,

This limitation is the same as [1.1] and would have been obvious for the

61 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 reasons analyzed above. CSCO-1004, ¶368.

[19.2] the object store holding files, data and metadata as objects,

This limitation is the same as [1.4] and would have been obvious for the reasons analyzed above. CSCO-1004, ¶369.

[19.3] each object having an object fingerprint which is globally unique and derived from its content and used to access the object store; and

This limitation is substantially the same as [1.5] and would have been obvious for the reasons analyzed above. CSCO-1004, ¶370.

[19.4] each file object comprising a mapping of object fingerprints for the data objects or metadata objects of the file,

This limitation is substantially the same as [1.6] and would have been obvious for the reasons analyzed above. CSCO-1004, ¶371.

[19.5] and the file object having its own object fingerprint derived from the fingerprints of the objects in the file; and

This limitation is substantially the same as [1.7] and would have been obvious for the reasons analyzed above. CSCO-1004, ¶372.

[19.6] maintaining in the object store an inode map object comprising a mapping of file system inode numbers and object fingerprints

As discussed above in [1.8], Muthitacharoen describes a “snapshot block”

(“inode map object”) that provides a mapping between the Ivy file system’s i- numbers (“inode numbers”) and corresponding content-hash values, or keys

(“object fingerprints”). CSCO-1004, ¶373. Thus, the snapshot block is “an inode

62 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 map object comprising a mapping of file system inode numbers and object fingerprints.” Id.

Muthitacharoen further describes maintaining the snapshot block in the

DHash storage system (“the object store”). “Ivy is configured to construct a snapshot every 20 new log records, or when 60 seconds have elapsed since the construction of the last snapshot.” CSCO-1007, p.38. For example, a POSITA would have recognized that the content-hash key for a file (identified by an i-number) would change when additional data was written to that file. CSCO-

1004, ¶373. Because Muthitacharoen describes keeping the snapshot block up-to- date in this way, Muthitacharoen renders obvious “maintaining in the object store an inode map object comprising a mapping of file system inode numbers and object fingerprints.” CSCO-1004, ¶373-374.

[19.7] enabling the inode numbers to stay constant while the object fingerprints change as the file content changes;

This limitation is the same as [1.9] and would have been obvious for the

reasons analyzed above. CSCO-1004, ¶375.

[19.8] and maintaining in the object store directory objects, each directory object comprising a mapping of inode numbers and file names;

As discussed above in [1.10], Muthitacharoen teaches directory inode blocks

that are “directory objects, each directory object comprising a mapping of inode

numbers and file names.” CSCO-1004, ¶376.

63 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

The directory inode blocks (“directory objects”) are part of the snapshot data structure that, as discussed in [19.6], Muthitacharoen teaches maintaining in

DHash (“the object store”). For example, when updating a snapshot, directory operations such as creating a directory entry, removing an entry, or renaming an entry are processed. CSCO-1007, p.35 (“For each i-number that occurs in the new log records, Ivy… performs the operation indicated by each log record…”);

CSCO-1004, ¶¶376-378. Thus, it would have been obvious to a POSITA that

Muthitacharoen teaches “maintaining in the object store directory objects….”

CSCO-1004, ¶379.

[19.9] wherein each of the inode map object and directly [sic, directory] object has its own object fingerprint derived from the content of the respective object.

This limitation is substantially the same as [1.11] and would have been obvious for the reasons analyzed above. CSCO-1004, ¶380.

[20.0] The method of claim 19, comprising: [20.1] maintaining a location index for mapping object fingerprints and physical locations of the objects.

As discussed above in [14.1] and [3.1], Muthitacharoen discloses a snapshot data structure that is a “location index.” CSCO-1004, ¶383. As discussed in

[19.6], Muthitacharoen renders obvious “maintaining” the snapshot data structure

(“location index”) by periodically updating the snapshot data structure. CSCO-

1004, ¶386.

As discussed in [3.1], the snapshot data structure includes a “file map” that

64 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

“records the DHash key of the i-node associated with each i-number.” CSCO-

1007, p.35. Thus the file map provides a “mapping” between i-numbers and

DHash keys. As further discussed in [3.1], Dabek explains that a block’s DHash key (“object fingerprint”) is used to identify the DHash server storing the contents of the block. CSCO-1008, pp. 202, 204, and 207. A POSITA would have understood that the DHash server storing a block is the “physical location of the object[].” CSCO-1004, ¶¶384-385. Thus, the file map in the snapshot block is “for mapping object fingerprints and physical locations of the objects.” CSCO-1004,

¶387. Muthitacharoen and Dabek render obvious “maintaining a location index for mapping object fingerprints and physical locations of the objects.” Id.

Alternatively, Dabek describes how a DHash server locates the server responsible for storing a particular block using the Chord protocol. With Chord, a

DHash server on a node is identified “by hashing the node’s IP address.” CSCO-

1008, p.205. “Chord views the IDs as occupying a circular identifier space. Keys are also mapped into this ID space.” CSCO-1008, p.205. “Chord defines the node responsible for a key to be the successor of that key’s ID.” CSCO-1008, p.205.

To locate the server responsible for a particular block, a DHash server

“maintains a list of the identities and IP addresses of its r immediate successors on the Chord ring.” CSCO-1008, p.205. This list is called the “successor list.”

CSCO-1008, p.205. It would have been obvious to a POSITA that the successor

65 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 list is a “location index” that maps between values in the hash ID space—such as

DHash keys (“object fingerprints”)—and IP addresses of servers (“physical

locations of the objects.”) For these additional reasons, Muthitacharoen and Dabek render obvious “maintaining a location index for mapping object fingerprints and physical locations of the objects.” CSCO-1004, ¶¶388-390.

[21.0] The method of claim 20, wherein: [21.1] the location index includes reference counts for the objects.

As discussed in [20.1], Muthitacharoen discloses a snapshot data structure

(“location index”). Also, as discussed above in [3.1], it would have been obvious to a POSITA for Muthitacharoen’s snapshot data structure to include “object reference counts.” There is no meaningful distinction between the language

“object reference counts” in [3.1] and “reference counts for the objects” recited in

[21.1.]. Thus, Muthitacharoen’s snapshot data structure renders obvious that “the

location index includes a reference counts for the objects.” CSCO-1004, ¶392.

[22.0] The method of claim 21, wherein: [22.1] the fingerprints, location index, inode map object, the file objects and directory objects comprise a file system.

As discussed above, Muthitacharoen teaches that DHash keys

(“fingerprints”), a snapshot data structure (“location index”), snapshot block

(“inode map object”), file inodes (“file objects”) and directory inode blocks

(“directory objects”) are all part of the Ivy file system (“file system”). CSCO-1004,

¶394.

66 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

[27.0] A computer program embodied in a non-transitory machine-readable storage device comprising program code means which, when executed by a process, performs the steps of method claim 19.

As construed, the “program code means…” refers to a computer program.

Since Ivy was written in the well-known C++ programming language, a

POSITA would have understood that the Ivy file system software was a “computer program.” CSCO-1004, ¶¶399-400. Muthitacharoen teaches that the “Ivy

[software] is available from http://www.pdos.lcs.mit.edu/ivy/.” CSCO-1007, p.43.

It would have been obvious to a POSITA that the Ivy software was “embodied in a non-transitory machine-readable storage device” at the www.pdos.lcs.mit.edu webserver, since the webserver needed to retain the software from the time it was loaded to the server until a reader of the Muthitacharoen article accessed the server to download the software. CSCO-1004, ¶401. Additionally, it would have been obvious to a POSITA that a computer running the Ivy file system would store the

Ivy software on “a non-transitory machine-readable storage device.” CSCO-

1004, ¶¶402-403. As discussed above regarding claim 19, a computer running the

Ivy file system “performs the steps of method claim 19.” Thus, Muthitacharoen and Dabek render obvious “A computer program embodied in a non-transitory machine-readable storage device comprising program code means which, when executed by a process, performs the steps of method claim 19.”

[28.0] The method of claim 19, including: [28.1] generating a snapshot of the file system from the fingerprint of the inode

67 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 map object.

As discussed in [1.8], Muthitacharoen teaches a snapshot block (“inode map object”) that is stored in “DHash under its content-hash,” or DHash key

(“fingerprint”). CSCO-1007, p.35. Muthitacharoen further teaches that the Ivy file system “updates the participant’s log-head to refer to the new snapshot.”

CSCO-1007, p.35. “The log-head is a public-key block with a fixed DHash key, which makes it easy for other participants to find.” CSCO-1007, pp.32-33. It would have been obvious to a POSITA that by storing the snapshot block’s DHash key for others to find and use, the Ivy file system is “generating a snapshot of the file system from the fingerprint of the inode map object.” CSCO-1004, ¶¶407-410.

[31.0] The method of claim 19, wherein: [31.1] the inode map object includes a fingerprint of a previous inode map.

A POSITA would have understood that the ’799 patent refers to the terms

“inode map object” and “inode map” interchangeably. CSCO-1001, 9:8 & 13:37;

CSCO-1004, ¶432.

As discussed in [9.2], Muthitacharoen describes a snapshot block (“inode map object”) that “contains… a pointer to the previous snapshot.” CSCO-1007, p.35. It would have been obvious to a POSITA that the “pointer to the previous snapshot” would be the DHash key of the previous snapshot block (“fingerprint of a previous inode map”). CSCO-1004, ¶¶433-436. Thus, Muthitacharoen renders

obvious that “inode map object includes a fingerprint of a previous inode map.”

68 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

[32.0] The method of claim 31, wherein: [32.1] the previous inode map fingerprints comprise a history of snapshots of the file system.

As discussed in [31.1] and [9.2], Muthitacharoen teaches that each snapshot block (“inode map”) includes a pointer (“fingerprint”) to a previous snapshot block. Each snapshot “contains the entire state of the file system” as of a “point in time.” CSCO-1007, p.35, 32. Thus, it would have been obvious to a POSITA that the series of DHash keys of snapshot blocks (with each snapshot block pointing to its predecessor) are “previous inode map fingerprints” that “comprise a history of snapshots of the file system.” CSCO-1004, ¶¶438-442.

[33.0] The method of claim 19, including: [33.1] maintaining in the object store a location index of object names and physical object locations.

As discussed in [14.1] and [20.1], Muthitacharoen maintains a snapshot data structure (“location index”) in the DHash storage system (“object store”). As discussed in [3.1], the snapshot data structure includes a “file map” that “records the DHash key of the i-node associated with each i-number.” CSCO-1007, p.35.

As Muthitacharoen illustrates in Fig. 2, the snapshot data structure includes directory inode blocks that associate an i-number with a filename (“object name”).

The snapshot data structure also includes a file map that associates each i-number with a DHash key. As discussed in [3.1] and [20.1], each DHash key identifies the

“physical location of the object.” CSCO-1004, ¶445-450. Thus, because the file

69 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 map in the snapshot data structure maps between filenames in a directory (“object names”) and DHash keys (“physical object locations”), Muthitacharoen renders obvious a “location index of object names and physical object locations.”

[34.0] The method of claim 19, wherein: [34.1] the file object mapping is indexed by an offset into the content of the file,

As discussed above in [1.6], Muthitacharoen teaches a file inode (“file object mapping”) that maps to the contents of a file by including keys H(B1) and H(B2) that identify the contents of the file, B1 and B2. A POSITA would have recognized that the file inode provides the keys as an ordered sequence corresponding to the sequence of the blocks in the file. CSCO-1004, ¶452. Thus, the first key is H(B1), the second key is H(B2), and so on. Within the file’s contents, the second block B2 is offset from the first block B1. Id. Thus, the ordinal number of the DHash keys in sequence represents an “index,” and corresponds to an “offset into the content of the file.” Id.

[34.2] and comprises a linear list, a tree structure, or an indirection table.

As analyzed in [7.1], the file inode (“file object mapping”) includes a “linear list.” CSCO-1004, ¶¶297-298.

[35.0] The method of claim 19, including: [35.1] adding, modifying or deleting an object of the file and generating a new file object fingerprint.

Muthitacharoen teaches that Ivy is a “read/write” file system that allows a user to add a content block to a file (“an object of the file”) by “send[ing] a WRITE

70 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 request containing the file’s i-number, the written data, and the file offset.”

CSCO-1007, pp. 31, 33. Muthitacharoen further teaches modifying or deleting content, for example, by “using ordinary file system operations to modify or delete data.” CSCO-1007, p.31, 38; CSCO-1004, ¶457. Thus, Muthitacharoen renders obvious “adding, modifying or deleting an object of the file.” CSCO-1004, ¶457-

458.

As discussed in [1.7] and [1.9], modifying the content of a file produces an updated DHash key for the file’s file inode (“generating a new file object fingerprint”). CSCO-1004, ¶¶459-460.

2. Challenge #2: Claims 5, 6 are unpatentable as being obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and Agrawal

a. Brief summary of Agrawal

Agrawal describes the benefits of “solid-state disks (SSDs),” which

“represent a sea change in the architecture of computer storage subsystems.”

CSCO-1009, p. 57. According to Agrawal, SSDs provide a number of advantages

over other forms of computer memory: “These devices are capable of producing

not only exceptional bandwidth, but also random I/O performance that is orders of

magnitude better than that of rotating disks. Moreover, SSDs offer both a

significant savings in power budget and an absence of moving parts, improving

system reliability.” Id. Agrawal also teaches that SSDs can be “NAND-flash

based.” Id.

71 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

b. Reasons to Combine Muthitacharoen/Dabek with Agrawal

A POSITA would have found it obvious to combine the teachings of

Muthitacharoen and Dabek with Agrawal for at least the reasons discussed below

in [5.1] and [6.1]. CSCO-1004, ¶¶148-153.

c. Detailed Claim Analysis

[5.0] The file system of claim 4, wherein: [5.1] the non-volatile memory comprises solid state disk.

As discussed in [4.1], a POSITA would understand that DHash of the

Muthitacharoen/Dabek system stores data “in non-volatile memory.” CSCO-1004,

¶279. Agrawal describes different forms of solid-state disks (SSDs). CSCO-1009, p. 57. It would have been obvious to a POSITA to employ the solid-state disks, as taught by Agrawal, in the non-volatile memory of DHash for at least the following reasons. CSCO-1004, ¶279.

Muthitacharoen and Dabek do not expressly state what kind of storage device is employed at the DHash servers that their systems used to store the data.

CSCO-1004, ¶¶279; CSCO-1007, pp. 31-32; CSCO-1008, p. 202. At the time of

Muthitacharoen’s publication (2002), the most commonly used bulk storage device for computers was a hard disk drive, which was known to be slow and consume a lot of power. CSCO-1004, ¶¶148-149; CSCO-1030, p. 414; see also CSCO-1056,

¶4 (showing CSCO-1030 published in 2001). A POSITA implementing the file systems in Muthitacharoen and Dabek would have been motivated to consult

72 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 references that described alternative storage devices. CSCO-1004, ¶150; CSCO-

1009, p. 57. Indeed, engineers had written about the “long tradition of alternatives to disk technology.” CSCO-1024, p. 50; see also CSCO-1056, ¶3 (showing

CSCO-1024 published in 1994).

In this regard, a POSITA would have found relevant the teachings of

Agrawal. CSCO-1004, ¶151. Agrawal realizes that “[s]olid-state disks (SSDs) have the potential to revolutionize the storage system landscape….” CSCO-1009, p. 57. According to Agrawal, the advantages of SSDs include “random I/O performance that is orders of magnitude better,… significant savings in power budget,” and “improv[ed] system reliability.” Id. Others in the field also recognized the advantages of SSD, such as flash memory, over disk drives.

CSCO-1031, p. 1075 (“The trend in market is also very clear. Computer hardware manufacturers have already launched new lines of mobile personal computers that did away with disk drives altogether, replacing them with flash memory SSD

(Solid State Drive).”); see also CSCO-1056, ¶18 (showing CSCO-1031 published in June 2008). SSDs were designed to be drop-in replacements for traditional hard disks. CSCO-1004, ¶151-152; CSCO-1009, p. 59; CSCO-1030, p.910 (“a solid state disk looks like a standard disk drive to the operating system”). Indeed,

Agrawal itself teaches: “Each SSD must contain host interface logic… to enable the SSD to mimic a hard disk drive.” CSCO-1009, p. 59. Thus, a POSITA would

73 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 have an expectation of success in employing an SSD in the DHash servers of

Muthitacharoen. CSCO-1004, ¶148.

Thus, Muthitacharoen and Dabek, in combination with Agrawal, render obvious “the non-volatile memory comprises solid state disk.” CSCO-1004,

¶¶280-290.

[6.0] The file system of claim 5, wherein: [6.1] the memory comprises flash memory.

As discussed in [5.1], a POSITA would have been motivated to employ the solid-state disks (SSDs), as taught by Agrawal, in the non-volatile memory of

Muthitacharoen/Dabek system’s DHash for all of the advantages that SSDs provide over disk drives. CSCO-1004, ¶293. Agrawal also teaches a SSD that is

“NAND-flash based” or “NAND-flash memory.” CSCO-1009, p. 57, 58. As such, Agrawal’s solid state storage device “comprises flash memory.” CSCO-

1004, ¶294.

Thus, Muthitacharoen, Dabek, and Agrawal render obvious “the memory comprises flash memory.” CSCO-1004, ¶295.

3. Challenge #3: Claims 10, 15, and 26 are unpatentable as being obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and McKusick

a. Brief summary of McKusick

129. McKusick describes the FreeBSD Operating System, including “the

concepts, data structures, and algorithms used in implementing FreeBSD’s system

74 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 facilities.” CSCO-1011, p.xxi.

b. Reasons to Combine Muthitacharoen/Dabek with McKusick

A POSITA would have found it obvious to combine the teachings of

Muthitacharoen and Dabek with McKusick. CSCO-1004, ¶155. In particular, a

POSITA implementing Muthitacharoen’s Ivy file system would look to the

teachings of McKusick because Muthitacharoen states that the Ivy file system

“runs of FreeBSD” and because McKusick describes the “concepts, data structures,

and algorithms used in implementing FreeBSD’s system facilities.” CSCO-1011 at

xxi; CSCO-1004, ¶155; CSCO-1007 at 38. A POSITA would have understood

that McKusick “is of direct use to the professionals who work with FreeBSD

systems” such as Muthitacharoen’s Ivy file system. CSCO-1011 at xxi; CSCO-

1004, ¶156. Through the teachings of McKusick, a POSITA would learn (i) “the

capabilities and limitations of the [FreeBSD] system,” (ii) “how to effectively and

efficiently interface to the [FreeBSD] system,” (iii) how to extend, enhance, and

interface to the system, and (iv) “how to maintain, tune, and configure the

[FreeBSD] system.” CSCO-1011 at xxi; CSCO-1004, ¶156. The combination of

Muthitacharoen and McKusick is merely the ordinary use McKusick’s common

programming techniques to enable implementation of a file system, such as

Muthitacharoen’s Ivy, to run on FreeBSD. CSCO-1004, ¶157.

75 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

c. Detailed Claim Analysis

[10.0] The file system of claim 1, wherein: [10.1] the namespace file system is provided as a layer in a storage stack between a virtual file system layer and a block storage abstraction layer.

Muthitacharoen and McKusick render obvious this feature.

First, as discussed in [1.1], Muthitacharoen discloses the Ivy file system, which is a “namespace file system.” Muthitacharoen teaches that the Ivy file system “acts as a local loop-back NFS v3 [6] server.” CSCO-1007, p.32.

Muthitacharoen also explains that the Ivy file system runs on FreeBSD. Id., p.38.

Second, McKusick describes the details of FreeBSD, and a POSITA would have been motivated to look to the teachings of McKusick for details about

FreeBSD. CSCO-1004, ¶152-157, CSCO-1011, p. xix.

Third, McKusick explains that FreeBSD has a “virtual-node, or vnode, layer.” CSCO-1011, p. 240. McKusick’s vnode layer corresponds to the claimed

“virtual file system layer.” CSCO-1004, ¶¶314-315, CSCO-1011, p. 240. Fig. 6.1 of McKusick shows the position of the vnode (VNODE) layer, specifically, above the NFS layer in the system stack:

76 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

CSCO-1004, ¶314; CSCO-1011, p.216, Fig. 6.1 (annotated).

A POSITA would have understood that the implementation of Ivy

(“namespace file system”) as a loop-back NFS module would reside underneath the

VNODE layer (“virtual file system layer”) of FreeBSD, and thus would be accessed through system calls to the NFS layer of FreeBSD. CSCO-1004, ¶316.

Fourth, Muthitacharoen also discloses that the DHash system (where Ivy stores all data) is a “peer-to-peer block storage system.” CSCO-1007, p.31. A

POSITA would thus understand that DHash has a storage layer that is the claimed

“block storage abstraction layer.” CSCO-1004, ¶317.

Fifth, the arrangement of Ivy (“namespace file system”) between the

77 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

VNODE layer (“virtual file system layer”) of FreeBSD and DHash storage layer

(“block storage abstraction layer”) is illustrated in Fig. 4 of Muthitacharoen below, which has been annotated to show the location of the FreeBSD VNODE layer (as explained by McKusick) above the NFS layer (CSCO-1004, ¶316-317;

CSCO-1007, Fig. 4):

VNODE layer

block storage abstraction layer

namespace file system layer NFS layer

virtual file system layer

CSCO-1004, ¶316; CSCO-1007, p.38, Fig. 4 (annotated).

Thus, Muthitacharoen in combination with McKusick render obvious “the namespace file system is provided as a layer in a storage stack between a virtual file system layer and a block storage abstraction layer.” CSCO-1004, ¶317.

78 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

[15.0] The file system of claim 14, including: [15.1] a transaction log of object activity, including reads, writes, deletes and reference count updates.

Muthitacharoen and McKusick render obvious this claim element.

First, Muthitacharoen discloses: “An Ivy file system consists of a set of logs, one log per participant. A log contains all of one participant’s changes to file system data and meta-data.” CSCO-1007, p.32. A POSITA would have recognized that a log containing all of a user’s changes to the file system data and meta-data is a “transaction log.” CSCO-1004, ¶¶337-338.

Second, Muthitacharoen’s logs contain various types of log records.

CSCO-1007, p.34, Table 2. For example, “Ivy will append a Write log record containing the same information,” which is information relating to a “write” operation. CSCO-1004, ¶¶338-339; CSCO-1007, p.34, Table 2.

Muthitacharoen discloses that the “Unlink” log record is used to “remove a file,” which a POSITA would have recognized is information relating to a “delete” operation. CSCO-1004, ¶¶340-341; CSCO-1007, p.34.

As analyzed in [14.1], Muthitacharoen renders obvious a “reference count.”

The “Unlink” log record in Muthitacharoen would also contain information

relating to “reference count updates.” This is because Muthitacharoen’s “Unlink”

operation is substantially similar to how the “delete” operation functions in

ordinary FreeBSD file systems. For example, McKusick explains that a “delete”

79 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 operation (in an ordinary FreeBSD file system) will decrement the reference count for an inode, and only if the reference count is then zero, free the inode for reuse.

CSCO-1011, p.298; CSCO-1004, ¶340. Muthitacharoen also discloses that the

“Link” log record is used to “create a directory entry,” which a POSITA, for the reasons discussed in [3.1], a POSITA would recognize as containing information relating to “reference count updates.” CSCO-1004, ¶341; CSCO-1007, p.34.

While Muthitacharoen does not expressly state that the Ivy file system stores log records relating to “reads,” it would have been obvious to a POSITA that a

“read” log record type could be added to the Ivy file system in order to track such file activity. CSCO-1004, ¶342. A POSITA would have been motivated to add such a feature because, among other things, FreeBSD (on which Ivy runs) normally stores for each file the “time that the file was … most recently read.”

CSCO-1011, p.297; CSCO-1004, ¶¶342-343.

Thus, Muthitacharoen in combination with McKusick render obvious “a

transaction log of object activity, including reads, writes, deletes and reference

count updates.” CSCO-1004, ¶344.

[26.0] The method of claim 21, including: [26.1] generating a transaction log of all object activity including reads, writes, deletes and reference count updates.

There is no meaningful difference between the features of “a transaction log

of object activity…,” as recited in [15.1], and the features of “a transaction log of

80 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 all object activity…,” as recited in [26.1]. CSCO-1004, ¶396. Therefore, as analyzed in [15.1], Muthitacharoen and McKusick render obvious that generating

Ivy’s log is “generating a transaction log of all object activity including reads, writes, deletes and reference count updates,” as recited in [26.1]. CSCO-1004,

¶397-398.

4. Challenge #4: Claims 29 and 30 are obvious over Muthitacharoen, Dabek, and Bunte.

a. Brief summary of Bunte

Bunte describes creating multiple backup copies of data, for example,

“creating an archived copy from one or more secondary copies are created from an

original data set, or primary or production copy, such as data from a file system.”

CSCO-1039, 4:17-20. Bunte creates the archived copy “during or soon after

creating other secondary copies.” CSCO-1039, 4:25-29. Bunte explains that it is

important to “create a copy of data (such as an archive copy) that is independent of

the system that created the data.” CSCO-1039, 1:45-48. For example, Bunte

discloses creating both “Onsite” and “Offsite” archive copies. CSCO-1039, Fig.

12.

b. Reasons to Combine Muthitacharoen/Dabek with Bunte

Muthitacharoen and Dabek describe storing data on DHash servers that may

be “scattered over the Internet.” CSCO-1008, p.210. This provides resiliency

against server failures. CSCO-1008, p.209. A POSITA would have recognized,

81 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 however, that Muthitacharoen’s Ivy file system relies heavily on DHash and requires a continuous Internet connection. CSCO-1004, ¶¶159-160; CSCO-1007, p. 32 (“Ivy operates best in a fully connected network”).

Muthitacharoen discusses an example of “disconnecting a laptop from the network.” CSCO-1007, p.37. In that scenario, it would be beneficial to have locally (e.g., accessible by the disconnected laptop) “replicas of all the log-heads and the user’s current snapshot,” but Muthitacharoen notes that “there is not currently a way to ask DHash to do this.” CSCO-1007, p.37. Bunte teaches the technique of backing up data on independent data archives to provide access to the data when anything—such as failure of the primary storage system or loss of access to the primary storage system—happens to disconnect access to the data.

CSCO-1004, ¶¶161.

A POSITA would have found it obvious to meet the needs of

Muthitacharoen’s disconnected laptop by applying the techniques of Bunte, such as to “routinely copy data produced and/or stored by [] computer systems in order to retain an archive of the data.” CSCO-1039, 1:37-39; CSCO-1004, ¶¶161-163. In particular, Bunte illustrates an example of a “selective copy” of certain data from an “offsite” archive to an “onsite” archive. CSCO-1039, Fig. 12.

82 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

CSCO-1039, Fig. 12.

A POSITA would have recognized that Bunte’s selective copy technique could be applied to Muthitacharoen’s system to create locally (“onsite”) an

“independent” copy of the data stored on various DHash servers (“offsite”).

CSCO-1004, ¶424. A POSITA would have found it obvious to apply Bunte’ techniques to Muthitacharoen to allow Muthitacharoen’s laptop to have access to the data even when disconnected from the network. CSCO-1004, ¶161-163.

c. Detailed Claim Analysis

[29.0] The method of claim 19, including: [29.1] publishing the inode map fingerprint to another object store.

Muthitacharoen teaches that the DHash key of the snapshot block (“inode map fingerprint”) is stored in a user’s log head. CSCO-1007, p.35.

83 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Muthitacharoen also suggests that a computer should have “replicas of all the log- heads and the user’s current snapshot” in case of disconnection from the network.

CSCO-1007, p.37.

Bunte explains that such a “replica” can be made by copying data from an

“offsite” data store (e.g., DHash servers) to an “onsite” data store (e.g., local to the computer). CSCO-1039, Fig. 12. It would have been obvious to a POSITA that this “onsite” data store could be a second DHash storage system. CSCO-1004,

¶424. Notably, Muthitacharoen discloses an example where “Ivy, and a single

DHash server[] ran on the same computer.” CSCO-1007, p.39. Furthermore,

Bunte describes its backup system manipulating “data objects already under management by the system, such as files, emails, attachments, application data.”

CSCO-1039, 4:47-49. Because Bunte describes storing “data objects” in its data archives, a POSITA would have understood Bunte’s data archives to be “object stores.” CSCO-1004, ¶133.

Accordingly, Muthitacharoen and Bunte suggest storing (“publishing”) a

log-head—which includes the snapshot block’s DHash key (“inode map

fingerprint”)—in a second DHash storage system or in an independent data archive

(“to another object store”). CSCO-1004, ¶424.

[30.0] The method of claim 19, including: [30.1] performing disaster recovery using the inode map fingerprint as a snapshot of the file system.

84 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

Bunte describes restoring data from an archive copy, for example, restoring data from a backup “should anything happen to the original data.” CSCO-1039,

1:67-2:2. Bunte notes that data can be “lost or corrupted.” CSCO-1039, 13:35. A

POSITA would have been familiar with the possibility of lost or corrupted data, for example, from failed or malfunctioning computer equipment (e.g., a “disaster”).

CSCO-1004, ¶428. Bunte’s restoration of data after a data loss teaches

“performing disaster recovery.” CSCO-1004, ¶428.

As discussed in [29.1], the DHash key of the snapshot block is the “inode map fingerprint.” As discussed in [28.1], the snapshot data structure, identified by the snapshot block’s DHash key (“inode map fingerprint”), is a “snapshot of the file system.” Since the snapshot data structure “contains the entire state of the file system” (CSCO-1007, p.35), it would have been obvious to a POSITA to use the snapshot data structure to locate data when recovering from a data loss

(“disaster”). CSCO-1004, ¶¶422, 429. Thus, Muthitacharoen and Bunte render obvious “performing disaster recovery using the inode map fingerprint as a snapshot of the file system.”

5. Challenge #5: Claims 16 and 36 are unpatentable as being obvious under 35 U.S.C. § 103 over Muthitacharoen, Dabek, and Bondurant

a. Brief summary of Bondurant

Bondurant, in the field of data storage systems, explains that “[d]ata de- duplication, known as commonality factoring, is a process of reducing storage

85 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 needs by eliminating redundant data.” CSCO-1010, 1:18-20, 35-37. “Data de- duplication is a resource intensive process,” which requires “top-of-the-line multi- core/multi-processor servers.” Id., 1:45-50. Because “the overall cost and power consumption of these multi-core/multi-processes servers are high,” Bondurant provides “a system for accelerating commonality factoring for storing data….” Id.,

1:52-54, 3:62-63. Bondurant teaches that “hardware and/or software can be used to accelerate the commonality factoring process.” Id., 2:9-10.

b. Reasons to Combine Muthitacharoen/Dabek with Bondurant

The use of hardware acceleration to improve software performance (e.g., for video decoding, network packet processing, and performing cryptographic functions) was a well-known concept before the priority date of the ’799 patent.

CSCO-1004, ¶166. It would have been obvious to a POSITA to employ well- known hardware acceleration methods, as taught by Bondurant, to improve the performance of the Ivy software of Muthitacharoen and Dabek. Id.

Like Muthitacharoen and Dabek, Bondurant relates to data storage systems, and describes computing the SHA-1 hash of the contents of data stored in the storage system. CSCO-1007, p.31; CSCO-1008, p.202, 208; CSCO-1010, 1:18.

Muthitacharoen’s performance testing showed that “the most expensive operations in the Ivy and DHash servers are SHA-1 hashes and memory copies.” CSCO-

1007, p.39. A POSITA would have recognized, therefore, that the performance of

86 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 the Ivy file system could be improved by accelerating the SHA-1 hash calculations.

CSCO-1004, ¶¶167-170.

It would have been obvious to a POSITA to apply Bondurant’s hardware acceleration to Muthitacharoen’s performance of the SHA-1 hashing algorithm for efficient calculation of DHash keys. CSCO-1004, ¶171. The combination of

Muthitacharoen and Dabek with Bondurant would simply be an application of the known technique of hardware acceleration, as taught by Bondurant, to the known performance of the SHA-1 hashing algorithm in Muthitacharoen and Dabek to yield predictable results of performing the SHA-1 hashing algorithm faster and more efficiently. Id. A POSITA would have also realized that doing so would have advantageously reduced the overall cost and power consumption of

Muthitacharoen’s file system. Id; CSCO-1010, 1:52-54.

c. Detailed Claim Analysis

[16.0] The file system of claim 1, including: [16.1] a hardware accelerator for implementing one or more of generating and storing the objects.

Muthitacharoen and Bondurant render obvious the features recited in [16.1].

First, as discussed in [1.6] and [7.1], Muthitacharoen teaches that the file

inode F is an object (specifically, a “file object”) comprising a linear list of the

keys H(B1), H(B2), etc. CSCO-1004, ¶348. And as discussed above in [1.5],

Muthitacharoen also teaches that the keys H(B1), H(B2), etc. are calculated using

87 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 the SHA-1 hash function on respectively unique contents B1, B2, etc. CSCO-

1004, ¶347-349.

Second, Bondurant teaches that “[d]ata de-duplication, known as commonality factoring, is a process of reducing storage needs by eliminating redundant data.” CSCO-1010, 1:18-20 and 35-37. Bondurant’s data de- duplication process includes a step of “calculating identifiers, e.g., hash identifiers, based on the unique chunks.” Id., 1:64-67. “Different hash algorithms such as message digest algorithm (MD5), secure hash algorithm-1 (SHA-1), and secure hash algorithm-2 (SHA-2) may be used in various embodiments.” Id., 10:51-54.

Third, Bondurant’s teachings would have led a POSITA to understand that

Bondurant’s use of the SHA-1 algorithm to calculate hash identifiers is analogous to Muthitacharoen’s use of the SHA-1 cryptographic hash function on respectively unique contents to calculate the keys. CSCO-1004, ¶351.

Fourth, Bondurant further teaches that the use of the SHA-1 algorithm to calculate the identifier for each chunk is processor intensive (“[d]ata de-duplication is a resource intensive process”), and that, therefore, it is appropriate for and could benefit from application of hardware acceleration. CSCO-1004, ¶352; CSCO-1010,

1:45-47.

Fifth, taking the cue from Bondurant, a POSITA would have recognized that

Muthitacharoen’s use of the SHA-1 cryptographic hash function is also resource

88 Petition for Inter Partes Review of U.S. Patent No. 8,478,799 and processor intensive, and could benefit from application of hardware acceleration. CSCO-1004, ¶353. Therefore, it would have been obvious to a

POSITA to apply hardware acceleration to Muthitacharoen’s use of the SHA-1 cryptographic hash function for generating the file inode F. CSCO-1004, ¶353.

Thus, Muthitacharoen and Bondurant render obvious “a hardware

accelerator for implementing one or more of generating and storing the objects.”

CSCO-1004, ¶354.

[36.0] The method of claim 35, including: [36.1] utilizing hardware acceleration to perform one or more of object generation, compression and encryption.

There is no meaningful difference between the features of “generating . . .

the objects,” as recited in [16.1], and the features of “object generation,” as recited

in [36.1]. Therefore, as analyzed in [16.1], Muthitacharoen and Bondurant render

obvious “utilizing hardware acceleration to perform one or more of object

generation, compression and encryption,” as recited in [36.1]. CSCO-1004, ¶¶464-

465.

89 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

VII. Conclusion

For the reasons above, Petitioner has established a reasonable likelihood of

prevailing with respect to at least one claim of the ’799 patent and asks for an inter

partes review trial and cancellation of claims 1-22 and 26-36.

Respectfully submitted,

August 11, 2017 /David L. McCombs/ David L. McCombs Registration No. 32,271

90 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

VIII. Certificate of Word Count

Pursuant to 37 C.F.R. § 42.24, the undersigned attorney for the Petitioner,

Cisco Systems, Inc., declares that the argument section of this Petition has 13,998

words, according to the word count tool in Microsoft Word™.

/David L. McCombs/ David L. McCombs Counsel for Petitioner Registration No. 32,271

91 Petition for Inter Partes Review of U.S. Patent No. 8,478,799

IX. Certificate of Service

The undersigned certifies, in accordance with 37 C.F.R. §§ 42.105 and 42.6, that service was made on the Patent Owner as detailed below. Date of service August 11, 2017

Manner of service FEDERAL EXPRESS

Documents served Petition for Inter Partes Review, including Exhibit List; Exhibits 1001-1005, 1007-1051, and 1054-1061

Persons served Hewlett Packard Enterprise 3404 E. Harmony Road Mail Stop 79 Fort Collins CO 80528

/David L. McCombs/ David L. McCombs Counsel for Petitioner Registration No. 32,271

92