Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`SPRINGPATH, INC.,
`Petitioner,
`
`v.
`
`SIMPLIVITY CORPORATION
`Patent Owner
`________________
`
`Case IPR2016-01779
`Patent 8,478,799
`________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`PURSUANT TO 37 C.F.R. § 42.107(a)
`
`

`
`I.
`II.
`
`III.
`IV.
`
`V.
`
`PAGE
`Introduction......................................................................................................1
`Background of the ’799 Patent ........................................................................3
`The ’799 Patent Discloses an Improved Computer File System ..........3
`A.
`1.
`Object Store.................................................................................3
`2.
`Fingerprints .................................................................................5
`3.
`New Object Structures in the ’799 Patent...................................6
`B.
`The Challenged Claims of the ’799 Patent ...........................................7
`Overview of Li.................................................................................................9
`Claim Construction........................................................................................11
`The Governing Claim Construction Standard.....................................12
`A.
`The Term “Object” Should Be Given Its Plain and Ordinary
`B.
`Meaning...............................................................................................13
`1.
`Petitioner Acknowledges that Any Terms Not Offered for
`Construction by the Petition Should be Given Their Plain
`and Ordinary Meaning ..............................................................14
`The Plain and Ordinary Meaning of “Object” Is Not
`Disclosed by “Block”................................................................14
`Petitioner’s Proposed Constructions of “Fingerprint” and
`“Namespace File System” Are Immaterial .........................................20
`1.
`Construing “Fingerprint” Is Not Necessary..............................20
`2.
`Construing “Namespace File System” Is Not Necessary .........22
`Argument .......................................................................................................24
`Li Does Not Disclose “Objects” as Required by All Challenged
`A.
`Claims..................................................................................................24
`Li Does Not Disclose Fingerprints for Directory Objects as
`Required by All Challenged Claims ...................................................29
`Li Does Not Disclose Certain Mappings Required by All
`Challenged Claims ..............................................................................32
`
`2.
`
`C.
`
`B.
`
`C.
`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`TABLE OF CONTENTS
`
`ii
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`1.
`
`Li Does Not Disclose that the “user i-table” Contains the
`Claimed Inode Map Object Mapping as Required by All
`Challenged Claims ....................................................................32
`Li Does Not Disclose that the Directory Blocks Contains
`the Claimed Directory Object Mapping as Required by
`All Challenged Claims..............................................................34
`Conclusion .....................................................................................................35
`
`2.
`
`VI.
`
`iii
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`TABLE OF AUTHORITIES
`
`Cases
`Advanced Display Sys. v. Kent State Univ.,
`212 F.3d 1272 (Fed. Cir. 2000) ..........................................................................29
`
`Page(s)
`
`Apple, Inc. v. ContentGuard Holdings, Inc.,
`IPR2015-00351, Paper 9 (PTAB June 24, 2015) .........................................21, 23
`
`Aventis Pharma S.A. v. Hospira, Inc.,
`675 F.3d 1324 (Fed. Cir. 2012) ..........................................................................13
`
`Becton, Dickinson and Co. v. One StockDuq Holdings, LLC,
`IPR2013-00235, Paper 30 (PTAB Sept. 25, 2014).............................................13
`
`Cheese Sys. v. Tetra Pak Cheese & Powder Sys.,
`725 F.3d 1341 (Fed. Cir. 2013) ....................................................................29, 32
`
`Ericcson, Inc. v. Intellectual Ventures I LLC,
`IPR2014-00921, Paper 8 (PTAB Dec. 16, 2014) ...............................................13
`
`Hill-Rom Services, Inc. v. Stryker Corporation,
`755 F.3d 1367 (Fed. Cir. 2014) ....................................................................12, 13
`
`In re Translogic Tech., Inc.,
`504 F.3d 1249 (Fed. Cir. 2007) ..........................................................................14
`
`Intellectual Ventures Mgmt, LLC, v. Xilinx, Inc.,
`IPR2012-00019, Paper 33 (PTAB February 10, 2014) ................................12, 13
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) ..........................................................12
`
`Universal Remote Control, Inc. v. Universal Electronics, Inc.,
`IPR2013-00127, Paper 32 (PTAB June 30, 2014) .............................................13
`
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ............................................................................13
`
`Wellman, Inc. v. Eastman Chem. Co.,
`642 F.3d 1355 (Fed. Cir. 2011) ....................................................................13, 20
`
`iv
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`Wowza Media Sys., LLC v. Adobe Systems Inc.,
`IPR2013-00054, No. 12 (PTAB Apr. 8, 2013).............................................12, 13
`
`Other Authorities
`
`37 C.F.R. § 42.107 .....................................................................................................1
`
`37 C.F.R. §100(b); Office Patent Trial Practice Guide, 77 Fed. Reg.
`48,756, 48,766 (Aug. 14, 2012)..........................................................................12
`
`v
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`Description
`
`Exhi
`bit
`2001 Wikipedia: “Object Storage” (available at
`https://en.wikipedia.org/wiki/Object_storage) (last visited Dec. 6, 2016)
`2002 Webopedia: “Inode” (available at
`http://www.webopedia.com/TERM/I/inode.html) (last visited Dec. 20,
`2016)
`2003 Presentation: “Object Storage Technology”, Storage Networking Industry
`Association, 2013 (available at
`http://www.snia.org/sites/default/education/tutorials/2013/spring/file/Brent
`Welch_Object_Storage_Technology.pdf) (last visited Dec. 22, 2016)
`2004 “Object Storage versus Block Storage: Understanding the Technology
`Differences”, August 14, 2014 (available at
`http://www.druva.com/blog/object-storage-versus-block-storage-
`understanding-technology-differences/) (last visited Dec. 22, 2016)
`2005 “Understanding Object Storage and Block Storage use cases”, July 20, 2015
`(available at
`http://cloudacademy.com/blog/object-storage-block-storage/ ) (last visited
`Dec. 22, 2016)
`2006 “OBFS: A File System for Object-based Storage Devices.” Feng, et al.,
`2004
`2007 “Oasis: An active storage framework for object storage platform”, Xie, et
`al., 2015
`2008 Wikipedia: “Namespace” (available at
`https://en.wikipedia.org/wiki/Namespace) (last visited Dec. 6, 2016)
`2009 Webopedia: “Namespace” (available at
`http://www.webopedia.com/TERM/N/namespace.html) (last visited Dec.
`20, 2016)
`
`vi
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`I.
`
`INTRODUCTION
`Patent Owner SimpliVity Corporation (“SimpliVity”) submits this
`
`preliminary response pursuant to 37 C.F.R. § 42.107 to the Petition filed by
`
`Springpath, Inc. (“Springpath” or “Petitioner”). For at least the reasons described
`
`below, Springpath’s Petition has failed to establish the requisite likelihood that it
`
`will prove that the challenged claims of U.S. Patent No. 8,478,799 (“the ’799
`
`Patent”)1 are unpatentable.
`
`The ’799 Patent’s fundamental teachings include an expanded use of
`
`fingerprints for objects in an object-based file system. Li does not teach several
`
`aspects of the claimed invention, three of which are of particular import. First, Li
`
`does not disclose or discuss objects or object-based file systems. Rather, Li
`
`teaches a secure file system on untrusted block storage servers. As discussed in
`
`more detail below, and as Springpath’s expert has long recognized, blocks are not
`
`objects. As such, the discussion of blocks in Li does not disclose the objects of the
`
`’799 Patent.
`
`Second, Li does not disclose fingerprints for the claimed directory objects.
`
`The challenged claims require that directory objects receive fingerprints. If Li
`
`discloses objects at all, and if Li also discloses fingerprints, Li still does not
`
`disclose fingerprints for the construct the Petition points to for the directory object.
`
`1 The ’799 Patent is attached to the Petition as Exhibit 1001.
`
`1
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`Third, Li does not disclose two of the claimed mappings of the ’799 Patent.
`
`The directory objects of the ’799 Patent are required to have a mapping of inode
`
`numbers and file names. Li teaches a mapping of file names to principal/inode
`
`number pairs, which is a very different mapping construct. Additionally, the inode
`
`map objects of the ’799 Patent are required to map file system inode numbers and
`
`object fingerprints. But even if Li discloses object fingerprints, Li teaches an inode
`
`map that maps fingerprints and user inode numbers, not file system inode numbers.
`
`Due to these shortcomings, the Petition should be denied.
`
`All Challenged Claims:
`
`The Petition fails to demonstrate the requisite likelihood of success with
`
`respect to at least each of the following limitations of independent claims 1 and 19:
`
` “object store;”
`
` “an inode map object comprising a mapping of file system inode numbers
`
`and object fingerprints enabling the inode numbers to stay constant while the
`
`object fingerprints change as the file content changes;”
`
` “directory objects, each directory object comprising a mapping of inode
`
`numbers and file names;” and
`
` “wherein each of the inode map object and directory object has its own
`
`object fingerprint derived from the content of the respective object.”
`
`2
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`Because Petitioner cannot show a likelihood of success with respect to
`
`claims 1 and 19, and because each challenged dependent claim depends from either
`
`claim 1 or 19, the Petition should be denied in its entirety.
`
`II.
`
`BACKGROUND OF THE ’799 PATENT
`The ’799 Patent Discloses an Improved Computer File System
`
`A.
`
`The ’799 Patent claims new structures and uses of fingerprints for file
`
`systems that use an object-based file system storage abstraction known as an
`
`“object store,” or “object storage.” ’799 Patent at 10:46-61 (Ex. 1001).
`
`1.
`
`Object Store
`
`Traditional file systems sit directly on top of a block store storage system.
`
`Id. at 10:40-45 (Ex. 1001). These “block stores” could be implemented on a local
`
`storage device or on remote storage devices. Id. at 10:41-43 (Ex. 1001).
`
`Essentially, block stores are storage units, such as a hard disk drive or solid state
`
`drive identified by a logical unit number (“LUN”), that are divided into “blocks”
`
`where file data that cannot fit into a single block is spread out across the file
`
`system in multiple blocks. Id. at 8:59-62 (“Sometimes content can be very large
`
`(many GB), and does not fit contiguously on a disk or persistent medium. The
`
`content is broken up, and stored as discrete units. In the case of traditional file
`
`systems, this would be blocks on disk.”) (Ex. 1001).
`
`3
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`Rather than stacked directly on top of a block store, the computer file system
`
`claimed by the ’799 Patent is “stacked on top of a lightweight object file system,”
`
`also referred to as an “object store.” See id. at 10:47-51 (Ex. 1001). Object stores
`
`organize data into objects rather than blocks. See Wikipedia: “Object Storage”
`
`(Ex. 2001) (“Thus, data is exposed and managed as objects instead of files or
`
`blocks.”).
`
`Object storage systems offer benefits over traditional block store
`
`implementations. For example, object storage is an abstraction that allows the
`
`naming and storage of files to be agnostic to the physical and logical block
`
`addressing of an underlying block storage apparatus. See ’799 Patent at 7:7-9
`
`(Ex. 1001). Another exemplary benefit of object storage systems is that data
`
`structured as objects can be accessed directly by applications through a
`
`programmable interface. Wikipedia: “Object Storage” (“object storage seeks to
`
`enable capabilities not addressed by other storage architectures, like interfaces that
`
`can be directly programmable by the application…”) (Ex. 2001).
`
`The object store of the ’799 Patent may then be stacked on top of an
`
`underlying storage device, such as a LUN, disk partition, or remote device
`
`accessed through network protocols, where objects are stored in physical memory.
`
`’799 Patent at 10:59-67 (Ex. 1001). Figure 1 of the ’799 Patent, reproduced below,
`
`demonstrates the basic structure of the claimed file system. It highlights the object
`
`4
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`store, block storage abstraction, and an underlying storage device for file system
`
`data:
`
`’799 Patent, Figure 1 (annotated) (Ex. 1001).
`
`2.
`
`Fingerprints
`
`In the ’799 Patent, objects in the file system have a fingerprint that is
`
`generated using a cryptographic hash of the object’s content. ’799Patent at 11:10-
`
`14 (Ex. 1001). Essentially, a fingerprint is an identifier generated by a
`
`predetermined hash algorithm applied to an object’s content. Id. at 8:13-24
`
`(Ex. 1001). Because objects in the file system of the ’799 Patent receive a globally
`
`unique object fingerprint, the file system can be implemented with references to
`
`objects using fingerprints of objects, as opposed to physical or logical addresses for
`
`5
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`data blocks. See id. at 15:65-16:8 (Ex. 1001). Importantly, because the
`
`fingerprints of the ’799 Patent are based on an object’s content, the fingerprints
`
`change as the contents of the corresponding object change. See id. at 13:8-11;
`
`32:54-55 (Ex. 1001).
`
`3.
`
`New Object Structures in the ’799 Patent
`
`Unlike known object store implementations, which only stored data and its
`
`associated metadata as objects, the ’799 Patent expands on the object concept by
`
`introducing a new object class called an “hnode.” Hnodes of the ’799 Patent tie
`
`together content, such as a file, and are themselves objects of the file system. ’799
`
`Patent at 7:40-45; 8:58-67 (Ex. 1001). Hnode objects of the ’799 Patent include
`
`inode maps (or imaps), files, and directories. Id. at 7:52-55; 8:58-59; 9:61-62
`
`(Ex. 1001).
`
`Understanding the claimed inode map object of the ’799 Patent requires a
`
`brief explanation of an inode. In traditional file systems, a structure called an
`
`index node (“inode”) contained metadata and the list of data blocks constituting a
`
`file. Id. at 6:44-51 (Ex. 1001). Inodes were referred to by unique integer
`
`identifiers, called inode numbers that did not change during the life of the file. See
`
`Webopedia: “Inode” (Ex. 2002).
`
`Each file object and each directory object in the ’799 Patent receives an
`
`inode number to ensure compatibility with legacy implementations and to ensure
`
`6
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`the user space can interact with the file system. ’799 Patent at 7:2-3, 48-52; 9:24-
`
`25, 60-67 (Ex. 1001). The inode map object of the ’799 Patent maps the
`
`aforementioned inode numbers to object fingerprints. Id. at 32:52-55 (Ex. 1001).
`
`This mapping allows the inode number to remain constant even though the object
`
`fingerprint may change over time. Id. at 32:51-55 (Ex. 1001).
`
`In the ’799 Patent, file objects are a mapping structure of all data and
`
`metadata objects that constitute the file. ’799 Patent at 32:47-50 (Ex. 1001).
`
`Metadata objects store file metadata. Id. at 15:35-37 (Ex. 1001). Finally, directory
`
`objects consist of a mapping of inode numbers and file names. Id. at 32:56-57 (Ex.
`
`1001).
`
`As required by every claim of the ’799 Patent, each of the metadata objects,
`
`file objects, directory objects, and inode map objects receive and are addressed by
`
`object fingerprints. See, e.g., ’799 Patent at 32: 35-60 (claim 1) (Ex. 1001).
`
`B.
`
`The Challenged Claims of the ’799 Patent
`
`Springpath has challenged claims 1-2, 7-13, 17-20, 27, and 33-35 of the ’799
`
`Patent. Springpath does not challenge claims 3-6, 14-16, 21-26, 28-32, or 36.
`
`Each challenged claim requires a namespace file system which accesses an object
`
`store. The claims further require that the object store hold several types of objects,
`
`including file, data, metadata, inode map, and directory objects. Each claim also
`
`requires that each of the aforementioned objects possess a globally unique object
`
`7
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`fingerprint derived from the content of the object. And each claim requires that the
`
`inode map objects contain a mapping of file system inode numbers and object
`
`fingerprints enabling the inode numbers to stay constant while the object
`
`fingerprints change as the file content changes and that the directory objects
`
`contain a mapping of inode numbers and file names.
`
`Claim 1 is exemplary:
`
`1. A computer file system for naming and storing of files on
`one or more computer storage devices, the system
`comprising:
`a namespace file system accessing an object store, the system
`including a memory and a hardware processor in
`communication with the memory, the processor for
`executing program instructions for accessing the object store
`using object fingerprints, the object store holding files,
`data and metadata as objects, each object having a
`globally unique object fingerprint derived from the content
`of the object and used to access the object store, wherein:
`each file object comprising a mapping of object fingerprints for
`the data objects or metadata objects of the file and the file
`object having its own object fingerprint derived from the
`fingerprints of the objects in the file, and wherein the
`object store further includes:
`an inode map object comprising a mapping of file system
`inode numbers and object fingerprints enabling the
`inode numbers to stay constant while the object
`fingerprints change as the file content changes; and
`directory objects, each directory object comprising a
`mapping of inode numbers and file names;
`wherein each of the inode map object and directory object
`has its own object fingerprint derived from the content
`of the respective object.
`’799 Patent, claim 1 (emphasis added); see also claim 19 (Ex. 1001).
`
`8
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`Also relevant to this Preliminary Response are dependent claims 2, 7-13, 17,
`
`and 18 which depend from claim 1, and claims 20, 27, and 33-35 which depend
`
`from claim 19. Additional missing dependent limitations are identified and
`
`discussed below.
`
`III.
`
`OVERVIEW OF LI
`Springpath’s Petition asserts that the challenged claims of the ’799 Patent
`
`are unpatentable for the following grounds:
`
`Ground
`I
`
`References
`Li2
`
`II
`III
`
`Li and Sandberg
`Li
`
`Basis
`§ 102
`
`§ 103(a)
`§ 103(a)
`
`Challenged Claims
`1-2, 7-9, 11-12, 17-20,
`27, 33-35
`10
`13
`
`Li describes the Secure Untrusted Data Repository (“SUNDR”) system,
`
`which is a “network file system designed to store data securely on untrusted
`
`servers.” Li Abstract (Ex. 1003). Li provides a system that enables each client, or
`
`user, of the file system to detect data integrity and consistency failures for data
`
`stored in a remote block store. See id. (Ex. 1003).
`
`The storage system in Li is accessed by remote clients using remote
`
`procedural calls (“RPC”). The RPCs in Li make calls to a distributed remote block
`
`store accessed through a consistency server:
`
`2 The Li reference is attached as Exhibit 1003 to the Petition.
`
`9
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`Li at 122 (left column) (“Fetch and modify, in turn, are implemented in terms of
`
`SUNDR protocol RPCs to the server.”) (Ex. 1003).
`
`Li does not mention objects or object stores, only blocks and block stores.
`
`See generally Li (Ex. 1003). The remote block store disclosed by Li “stores data,
`
`update certificates, and version structures on disk.” Li at 129, right column (Ex.
`
`1003). The block store indexes “most persistent data structures” by their SHA-1
`
`hash to enable a user to detect data integrity problems. Id. at 124, right column
`
`(Ex. 1003). Specifically, Li asserts it “to be computationally infeasible to find any
`
`two different data blocks with the same SHA-1 hash. Thus, when a client requests
`
`the block with a particular hash, it can check the integrity of the response by
`
`hashing it.” Id. at 124, right column (Ex. 1003).
`
`Li’s goal is to provide security on a user level; as a result the Li system
`
`operates on a per user basis rather than on a file system basis as required by the
`
`’799 Patent. Li’s user-level focus is clearly depicted in Figure 2 below:
`
`10
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`Li at 125 (Ex. 1003).
`
`Li explains:
`
`An i-handle is the root of a hash tree containing a user or group i-
`table. (H denotes SHA-1, while H* denotes recursive application of
`SHA- 1 to compute the root of a hash tree.) A group i-table maps
`group inode numbers to user inode numbers. A user i-table maps a
`user’s inode numbers to i-hashes. An i-hash is the hash of an inode,
`which in turn contains hashes of file data blocks.
`
`Li at Fig. 2 Caption (italics in original) (Ex. 1003).
`
`IV.
`
`CLAIM CONSTRUCTION
`The Petition equates the “blocks” disclosed in Li with the “objects” in the
`
`’799 Patent, but does not provide a construction for the term “object” that would
`
`cover blocks. Nor could it. Indeed, the Petition provides no construction of
`
`“object” at all, and acknowledges that the ’799 Patent does not provide a special
`
`definition of “object.” The plain and ordinary meaning of “object,” which does not
`
`encompass blocks, applies.
`
`11
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`The Petition can be evaluated—and should be denied—solely on the basis of
`
`the differences between blocks and objects. It is not necessary for the Board to
`
`resolve any of the claim construction issues presented in the Petition.
`
`Nevertheless, even if one assumes that Petitioner’s proposed constructions are
`
`correct, the Petition still fails for the reasons discussed below.
`
`A.
`
`The Governing Claim Construction Standard
`The broadest reasonable interpretation standard applies in an inter partes
`
`review of a patent that, like the ’799 Patent, will not expire prior to the issuance of
`
`the Final Written Decision. 37 C.F.R. §100(b); Office Patent Trial Practice Guide,
`
`77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012). Applying the broadest reasonable
`
`interpretation, claim terms are given their ordinary and customary meaning, as
`
`would be understood by a person of ordinary skill in the art at the time of the
`
`invention, in light of the language of the claims, the specification, and the
`
`prosecution history of the record. See, e.g., Wowza Media Sys., LLC v. Adobe
`
`Systems Inc., IPR2013-00054, No. 12 at 5 (PTAB Apr. 8, 2013); Intellectual
`
`Ventures Mgmt, LLC, v. Xilinx, Inc., IPR2012-00019, Paper 33 at 9 (PTAB
`
`February 10, 2014); see also Hill-Rom Services, Inc. v. Stryker Corporation, 755
`
`F.3d 1367, 1371 (Fed. Cir. 2014); Phillips v. AWH Corp., 415 F.3d 1303, 1313-
`
`1317 (Fed. Cir. 2005) (en banc).
`
`12
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`Under this test, “[t]here is a ‘heavy presumption’ that a claim term carries its
`
`ordinary and customary meaning.” See Intellectual Ventures, IPR2012-00019,
`
`Paper 33 at 9; Wowza, IPR2013-00054, No. 12 at 6; Universal Remote Control,
`
`Inc. v. Universal Electronics, Inc., IPR2013-00127, Paper 32 at 6 (PTAB June 30,
`
`2014). This heavy presumption is overcome in specific and limited circumstances:
`
`a claim term may be construed contrary to its ordinary meaning only where there is
`
`clear and unambiguous evidence that the patentee, as lexicographer, provided a
`
`special definition for the claim term, or the patentee otherwise disavowed the full
`
`scope of the claim term either in the specification or during prosecution. Ericcson,
`
`Inc. v. Intellectual Ventures I LLC, IPR2014-00921, Paper 8, at 8 (PTAB Dec. 16,
`
`2014); Becton, Dickinson and Co. v. One StockDuq Holdings, LLC, IPR2013-
`
`00235, Paper 30 at 6 (PTAB Sept. 25, 2014); see also Aventis Pharma S.A. v.
`
`Hospira, Inc., 675 F.3d 1324, 1330 (Fed. Cir. 2012); Hill-Rom, 755 F.3d at 1371.
`
`The Board need only construe terms to the extent such construction is
`
`necessary to resolve a controversy material to the Petition. See, e.g., Wellman, Inc.
`
`v. Eastman Chem. Co., 642 F.3d 1355, 1361 (Fed. Cir. 2011); Vivid Techs., Inc. v.
`
`Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`
`B.
`
`The Term “Object” Should Be Given Its Plain and Ordinary
`Meaning
`
`There is no dispute that under the governing broadest reasonable
`
`interpretation standard, “object” should be given its plain and ordinary meaning.
`
`13
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`See Pet. at 24. The plain and ordinary meaning of “object,” when correctly
`
`applied, does not encompass the “blocks” in Li.
`
`1.
`
`Petitioner Acknowledges that Any Terms Not Offered for
`Construction by the Petition Should be Given Their Plain and
`Ordinary Meaning
`
`Petitioner acknowledges that any terms not proposed for construction in the
`
`Petition should be given their plain and ordinary meaning. See Pet. at 24. Under
`
`the broadest reasonable interpretation standard, any claim terms that have not been
`
`specially defined by the patentee are to be given their plain and ordinary meaning.
`
`In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007); see Pet. at 24
`
`(citing In re Translogic Tech., Inc., 504 F.3d 1249) (“Under the broadest
`
`reasonable interpretation standard, claim terms are given their ordinary and
`
`customary meaning… Any claim terms not included should be given their
`
`broadest reasonable interpretation…”). Here, Petitioner did not propose “object”
`
`for construction, and acknowledges that it was not specially defined by the
`
`patentee. See Pet. at 24.
`
`2.
`
`The Plain and Ordinary Meaning of “Object” Is Not Disclosed
`by “Block”
`
`Even though Li does not mention objects, Petitioner argues that Li discloses
`
`the claimed “objects” when it discusses “blocks.” See, e.g., Pet at 24. In so doing,
`
`Petitioner stretches the meaning of “blocks” beyond recognition. Although it does
`
`not dispute that the plain and ordinary meaning of “object” applies, Petitioner does
`
`14
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`not offer any evidence that would support equating an “object” with a “block.”
`
`There is no such evidence. Even Petitioner’s expert, Dr. Long does not equate
`
`blocks with objects.
`
`As the following evidence shows, 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.” ’799 Patent at 11:3-5,
`
`64-65 (Ex. 1001). This plain and ordinary meaning is not disclosed by the well-
`
`understood meaning of “block.”
`
`Indeed, the ’799 Patent itself distinguishes “object” from “block.” The
`
`drafters of the ’799 Patent knew the difference and made clear that the objects of
`
`the ’799 Patent are stored in an object store, which is a different construct than a
`
`block store. For example, the ’799 Patent specification explains how the claimed
`
`object store can co-exist with an existing block store in the LUN 109. It provides:
`
`File systems normally sit on top of a block storage abstraction,
`implemented by block drivers 105. The block storage may be on a
`Logical Unit Number LUN local storage device 109, or it may be on a
`remote LUN using an iSCSI protocol. Block Drivers 105 also have
`well-defined interfaces in an operating system.
`
`In this embodiment, the new file system works alongside the other file
`systems in the kernel. The new file system is composed of a
`namespace file system 107 that is stacked on top of a lightweight
`object file system 108. The interface 152 between the two components
`may be any of various industry standard object interfaces such as the
`ANSI T-10 object standard.
`
`15
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`The Object file system (Object Store) 108 in turn is partitioned such
`that a library of commonly used functions, the Digest, Indexing,
`Compression, Encryption (DICE) library 310 is abstracted out. The
`library 310 may be realized completely in software, or take advantage
`of a variety of hardware acceleration 113 techniques, one of which is
`illustrated.
`
`’799 Patent at 10:40-58 (emphasis added) (Ex. 1001). The drafters made a similar
`
`distinguishing statement during prosecution. See Exhibit 10123, at 33 (Declaration
`
`under 37 CFR § 1.132 at ¶¶ 8-10) (differentiating a block device of the prior art
`
`from the higher level abstraction of the ’799 Patent and stating that “the object
`
`store resides at a different level than the physical level (disks or partitions)... In
`
`contrast, the [prior art] describe[s] a disk partition, which is a logical subdivision of
`
`a disk (block) device.”). These statements demonstrate that the drafters of the ’799
`
`Patent understood that blocks and objects, and their associated storage
`
`mechanisms, are different.
`
`Figure 1 of the ’799 Patent further demonstrates that the block store and the
`
`claimed object store exist at different levels in the hierarchy. The LUN 109 below
`
`the Block Drivers 105 provided in Figure 1 is a potential block store, while the
`
`object store abstraction exists at a higher level than the LUN:
`
`3 “Applicant’s Response Dated May 8, 2013” is attached to the Petition as Exhibit
`
`1012. The Inventor Declaration referenced here is included in that response.
`
`16
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`’799 Patent, Figure 1 (annotated) (Ex. 1001). These statements demonstrate that
`
`the specification alone is sufficient to show that the block store in Li cannot be the
`
`object store of the challenged claims.
`
`The industry also recognizes the difference between objects and blocks. For
`
`example, the Storage Networking Industry Association (“SNIA”) published a
`
`lecture describing object-based storage devices. See Presentation: “Object Storage
`
`Technology” (Ex. 2103). The SNIA provided a depiction of a block-based device
`
`alongside an object-based device, comparing the two and highlighting their
`
`differences:
`
`17
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`
`Presentation: “Object Storage Technology” at 7 (Ex. 2103). The lecture further
`
`noted that “[a] 4TB disk has 1 billion 4KB blocks – [object-based storage device]
`
`hides this.” Id. at 8 (Ex. 2103). The SNIA lecture makes clear that the object
`
`storage system adds an abstraction that hides the management of underlying blocks
`
`from the larger system. See id.
`
`Other literature also demonstrates that persons of skill in the file system
`
`industry know the difference between blocks and objects. See, e.g., “Object
`
`Storage versus Block Storage: Understanding the Technology Differences,” Aug.
`
`14, 2014 (“Object storage, by contrast, doesn’t split files up into raw blocks of
`
`data. Instead, entire clumps of data are stored in, yes, an object that contains the
`
`data, metadata, and the unique identifier.” (italics in original)) (Ex. 2004);
`
`“Understanding Object Storage and Block Storage use cases,” July 20, 2015
`
`(“Block storage volumes can only be accessed when they’re attached to an
`
`operating system. But data kept on object storage devices, which consist of the
`
`18
`
`

`
`Case IPR2016-01779
`U.S. Patent No. 8,478,799
`object data and metadata, can be accessed directly through APIs or http/https.”)
`
`(Ex. 2005).
`
`Even Dr. Long, Springpath’s expert, has long recognized that blocks and
`
`objects are not the same thing. In 2004, Dr. Long co-wrote a paper titled “OBFS:
`
`A File System for Object-based Storage Devices.” Feng, et al. (Exhibit 2006)
`
`(“OBFS Paper”). Dr. Long differentiated blocks and objects very clearly in the
`
`OBFS Paper, explaining that in object-based file systems, files are made up of one
`
`or more data objects that are broken into chunks stored in fixed-size blocks. OBFS
`
`Paper, at Abstract, 9 (Ex. 2106).
`
`Dr. Long also discussed partitioning storage space into two regions, one
`
`region consisting of large blocks of 512 KB size and one region consisting of small
`
`blocks of 4 KB size. OBFS Paper, at 2, 7 (Ex. 2006). As he explained, “[i]n the
`
`worse [sic] case, a small object will be a little smaller than 512 KB, requiring 128
`
`data blocks.” OBFS Paper, at 9 (Ex.