Case IPR2016-01780
`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-01780
`Patent 8,478,799
`________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`PURSUANT TO 37 C.F.R. § 42.107(a)
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`TABLE OF CONTENTS
`
`C.
`
`2.
`
`C.
`
`I.
`II.
`
`PAGE
`Introduction......................................................................................................1
`Background of the ’799 Patent ........................................................................3
`A.
`The ’799 Patent Discloses an Improved Computer File System ..........3
`1.
`Object Store.................................................................................3
`2.
`Fingerprints .................................................................................5
`3.
`New Object Structures in the ’799 Patent...................................6
`The Challenged Claims of the ’799 Patent ...........................................7
`B.
`III. Overview of Atkin ...........................................................................................9
`A.
`Overview of Atkin.................................................................................9
`B.
`The File Server 102 in Atkin Assigns Content Addresses for
`File Data ..............................................................................................11
`The Commit Server 112 in Atkin Does Not Assign Content
`Addresses for Metadata or File System Information ..........................12
`IV. Claim Construction........................................................................................14
`A.
`The Governing Claim Construction Standard.....................................14
`B.
`The Term “Object” Should Be Given Its Plain and Ordinary
`Meaning...............................................................................................16
`1.
`Petitioner Acknowledges that Any Terms Not Offered for
`Construction by the Petition Should be Given Their Plain
`and Ordinary Meaning ..............................................................16
`The Plain and Ordinary Meaning of “Object” Is Not
`Disclosed by “Block”................................................................17
`Petitioner’s Proposed Constructions of “Fingerprint” and
`“Namespace File System” Are Immaterial .........................................23
`1.
`Construing “Fingerprint” Is Not Necessary..............................23
`2.
`Construing “Namespace File System” Is Not Necessary .........24
`Argument .......................................................................................................26
`A.
`Atkin Does Not Disclose “Objects” as Required by All
`Challenged Claims ..............................................................................27
`
`V.
`
`ii
`
`

`
`1.
`
`2.
`
`2.
`
`3.
`
`B.
`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`The Blocks in Atkin Do Not Disclose the Claimed
`“Objects”...................................................................................28
`The Cited Portion of Dubnicki Was Not Incorporated
`into Atkin and Dubnicki Does Not Transform Atkin into
`an Object Storage System .........................................................30
`Atkin Does Not Disclose Generating Fingerprints for “Metadata
`Objects,” “File Objects,” “Directory Objects,” and “Inode Map
`Objects” As Required By All Challenged Claims ..............................32
`1.
`Atkin Does Not Disclose that “Metadata Objects”
`Receive Fingerprints as Required by All Challenged
`Claims .......................................................................................32
`Atkin Does Not Disclose that “File Objects” Receive
`Fingerprints as Required by All Challenged Claims ................35
`Atkin Does Not Disclose that “Inode Map Objects”
`Receive Fingerprints as Required by All Challenged
`Claims .......................................................................................37
`Atkin Does Not Disclose that “Directory Objects”
`Receive Fingerprints as Required by All Challenged
`Claims .......................................................................................39
`VI. Conclusion .....................................................................................................39
`
`4.
`
`iii
`
`

`
`TABLE OF AUTHORITIES
`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`Page(s)
`
`Cases
`Apple, Inc. v. ContentGuard Holdings, Inc.,
`IPR2015-00351, Paper 9 (PTAB June 24, 2015) .........................................24, 26
`
`Aventis Pharma S.A. v. Hospira, Inc.,
`675 F.3d 1324 (Fed. Cir. 2012) ..........................................................................16
`
`Becton, Dickinson and Co. v. One StockDuq Holdings, LLC,
`IPR2013-00235, Paper 30 (PTAB Sept. 25, 2014).............................................16
`
`Entegris, Inc. v. Pall Corp.,
`Civ. No. 06-10601-GAO, 2008 U.S. Dist. LEXIS 25352 (D. Mass.,
`Mar. 31, 2008).....................................................................................................30
`
`Ericcson, Inc. v. Intellectual Ventures I LLC,
`IPR2014-00921, Paper 8 (PTAB Dec. 16, 2014) ...............................................16
`
`Hill-Rom Services, Inc. v. Stryker Corporation,
`755 F.3d 1367 (Fed. Cir. 2014) ....................................................................15, 16
`
`In re Translogic Tech., Inc.,
`504 F.3d 1249 (Fed. Cir. 2007) ..........................................................................17
`
`Intellectual Ventures Mgmt, LLC, v. Xilinx, Inc.,
`IPR2012-00019, Paper 33 (PTAB February 10, 2014) ......................................15
`
`Medimmune, LLC v. PDL Biopharma, Inc.,
`Case No. 08-05590-JF, 2010 U.S. Dist. LEXIS 21169 (N.D. Cal.,
`Feb. 22, 2010) .....................................................................................................30
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) (en banc) ..........................................................15
`
`Universal Remote Control, Inc. v. Universal Electronics, Inc.,
`IPR2013-00127, Paper 32 (PTAB June 30, 2014) .............................................15
`
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ............................................................................16
`
`iv
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`Wellman, Inc. v. Eastman Chem. Co.,
`642 F.3d 1355 (Fed. Cir. 2011) ....................................................................16, 23
`
`Wowza Media Sys., LLC v. Adobe Systems Inc.,
`IPR2013-00054, No. 12 (PTAB Apr. 8, 2013)...................................................15
`
`Zenon Envtl., Inc. v. United States Filter Corp. (“Zenon”),
`506 F.3d 1370 (Fed. Cir. 2007) ....................................................................30, 31
`
`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)..........................................................................15
`
`v
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`TABLE OF EXHIBITS
`
`Description
`
`Exhi
`bit
`2101 Wikipedia: “Object Storage” (available at
`https://en.wikipedia.org/wiki/Object_storage) (last visited Dec. 6, 2016)
`2102 Webopedia: “Inode” (available at
`http://www.webopedia.com/TERM/I/inode.html) (last visited Dec. 20,
`2016)
`2103 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)
`2104 “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)
`2105 “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)
`2106 “OBFS: A File System for Object-based Storage Devices.” Feng, et al.,
`2004
`2107 “Oasis: An active storage framework for object storage platform”, Xie, et
`al., 2015
`2108 Wikipedia: “Namespace” (available at
`https://en.wikipedia.org/wiki/Namespace) (last visited Dec. 6, 2016)
`2109 Webopedia: “Namespace” (available at
`http://www.webopedia.com/TERM/N/namespace.html) (last visited Dec.
`20, 2016)
`
`vi
`
`

`
`Case IPR2016-01780
`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. Atkin does not teach several
`
`aspects of the claimed invention, two of which are of particular import. First,
`
`Atkin does not disclose or discuss objects or object-based file systems. Rather,
`
`Atkin teaches mounting a file system directly above a content addressable block
`
`storage system. As discussed in more detail below, and as Springpath’s expert has
`
`long acknowledged in his academic writing, blocks are not objects. As such, the
`
`discussion of blocks in Atkin does not disclose the objects of the ’799 Patent.
`
`Second, Atkin does not disclose fingerprinting many of the objects claimed
`
`in the ’799 Patent. The challenged claims require that data objects, metadata
`
`objects, file objects, directory objects, and inode map objects receive fingerprints.
`
`1 The ’799 Patent is attached to the Petition as Exhibit 1101.
`
`1
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`If Atkin discloses objects at all, and if Atkin also discloses fingerprints, the only
`
`object that receives a fingerprint in Atkin is a data object. Atkin does not teach the
`
`required fingerprints for the other objects.
`
`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”
`
` “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
`
` “wherein each of the inode map object and directory object has its own
`
`object fingerprint derived from the content of the respective object.”
`
`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.
`
`2
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`II.
`
`BACKGROUND OF THE ’799 PATENT
`
`A.
`
`The ’799 Patent Discloses an Improved Computer File
`System
`
`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. 1101).
`
`1.
`
`Object Store
`
`Traditional file systems sit directly on top of a block store storage system.
`
`Id. at 10:40-45 (Ex. 1101). These “block stores” could be implemented on a local
`
`storage device or on remote storage devices. Id. at 10:41-43 (Ex. 1101).
`
`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. 1101).
`
`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. 1101). Object stores
`
`organize data into objects rather than blocks. See Wikipedia: “Object Storage”
`
`3
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`(Ex. 2101) (“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.
`
`1101). Another exemplary benefit of object storage systems is that data structured
`
`as objects can be accessed directly by applications through a programmable
`
`interface. See 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. 2101).
`
`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. 1101). Figure 1 of the ’799 Patent, reproduced below,
`
`demonstrates the basic structure of the claimed file system. It highlights the object
`
`store, block storage abstraction, and an underlying storage device for file system
`
`data:
`
`4
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`’799 Patent, Fig 1 (Ex. 1001) (annotated).
`
`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. ’799 Patent at 11:10-
`
`14 (Ex. 1101). Essentially, a fingerprint is an identifier generated by a
`
`predetermined hash algorithm applied to an object’s content. Id. at 8:13-24
`
`(Ex. 1101). 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
`
`data blocks. See id. at 15:65-16:8 (Ex. 1101). Importantly, because the
`
`fingerprints of the ’799 Patent are based on an object’s content, the fingerprints
`
`5
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`change as the contents of the corresponding object change. See id. at 13:8-11;
`
`32:54-55 (Ex. 1101).
`
`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. 1101). 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. 1101).
`
`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. 1101). 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. 2102).
`
`Each file object and each directory object in the ’799 Patent receives an
`
`inode number to ensure compatibility with legacy implementations and to ensure
`
`the user space can interact with the file system. ’799 Patent at 7:2-3, 48-52; 9:24-
`
`25, 60-67 (Ex. 1101). The inode map object of the ’799 Patent maps the
`
`6
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`aforementioned inode numbers to object fingerprints. Id. at 32:52-55 (Ex. 1101).
`
`This mapping allows the inode number to remain constant even though the object
`
`fingerprint may change over time. Id. at 32:51-55 (Ex. 1101).
`
`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. 1101).
`
`Metadata objects store file metadata. Id. at 15:35-37 (Ex. 1101). Finally, directory
`
`objects consist of a mapping of inode numbers and file names. Id. at 32:56-57 (Ex.
`
`1101).
`
`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. 1101).
`
`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 that 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
`
`fingerprint derived from the content of the object. And each claim requires that the
`
`directory objects contain a mapping of inode numbers and file names.
`
`7
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`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. 1101).
`
`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.
`
`8
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`III.
`
`OVERVIEW OF ATKIN
`
`Springpath’s Petition asserts that claims of the ’799 Patent are unpatentable
`
`for the following grounds:
`
`Ground
`I
`II
`III
`IV
`
`References
`Atkin2
`Atkin and Li
`Atkin and Sandberg
`Atkin
`
`Basis
`§ 102
`§ 103(a)
`§ 103(a)
`§ 103(a)
`
`Challenged Claims
`1-2, 7-9, 12, 17-19, 27, 35
`11, 20, 33-34
`10
`13
`
`Atkin is directed to implementing faster access to block stores which may
`
`be, among other things, implemented as a content addressable storage (“CAS”)
`
`system. Atkin at 1:46-48 (Ex. 1104). Clients retrieve information from a CAS
`
`system by providing a content-based identifier to the CAS block store.
`
`Conventional CAS systems are typically archival systems that store immutable
`
`data blocks. See id. at 1:24-25 (Ex. 1104). Atkin does not discuss object-based
`
`file systems or object stores. Atkin also does not describe assigning a content
`
`address to anything other than file data blocks.
`
`A.
`
`Overview of Atkin
`
`Atkin accomplishes its goal of faster access in a CAS by bifurcating tasks
`
`between a file server and a commit server. Atkin at 1:48-52 (Ex. 1104). Atkin’s
`
`storage system (depicted in Figure 1 below) provides a file server 102 (blue) and a
`
`commit server 112 (red) for storing data and file system information in block store
`
`2 The Atkin reference is attached as Exhibit 1104 to the Petition.
`
`9
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`106 (yellow). The file server 102 and the commit server 112 write information to
`
`the block store in very different ways. This is important because according to
`
`Atkin only the file server 102, and not the commit server 112, assigns content
`
`addresses for data.
`
`Atkin, Figure 1 (annotated) (Ex. 1004).
`
`The file server 102 reads and writes data from/to the block store 106 while
`
`commit server 112 writes any data that is not file content to the block store 106
`
`“separately from and without regard to the file server 102.” Atkin at 2:33-43;
`
`2:49-55; 2:61 (metadata is any data that is not file content) (Ex. 1104). “In this
`
`way, writing data to the storage by the file server 102 and writing metadata to the
`
`storage by the commit server 112 is performed asynchronously, facilitating
`
`efficient high throughput reads and writes of large files.” Id. at 2:43-47
`
`10
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`(Ex. 1104). Put simply, only file content is stored in the block store 106 by the file
`
`server 102, while everything else, including metadata and file system information,
`
`is stored in the block store 106 through the commit server 112. See id. at 2:33-61.
`
`B.
`
`The File Server 102 in Atkin Assigns Content Addresses for
`File Data
`
`The file server 102 handles requests to read, write, or modify file data that
`
`will receive a content address. Upon receiving a write request, for example, “[t]he
`
`file server 102 chunks data received from the client 104 into data blocks (e.g.,
`
`generates data blocks) . . . and writes these data blocks to the block store 106.”
`
`Atkin 3:23-28 (Ex. 1104). The file server 102 receives a content address from the
`
`block store 106 that will be assigned to a new file data block, unless the data is
`
`already stored in the block store 106. See id. at 3:23-38 (Ex. 1104). Atkin does
`
`not discuss generating content addresses in any other context.
`
`The file server 102 also records any metadata operations associated with
`
`each data block it creates or modifies by applying the modifications to metadata
`
`that is already stored in the metadata cache 116. Atkin 3:33-44 (Ex. 1104). The
`
`file server then communicates metadata and file system updates to the commit
`
`server 112 either directly or by writing records to update log 110 that are
`
`retrievable by the commit server. Id. at 4:33-41 (Ex. 1104). Atkin does not
`
`11
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`discuss assigning a content address for any information stored by commit server
`
`112.
`
`C.
`
`The Commit Server 112 in Atkin Does Not Assign Content
`Addresses for Metadata or File System Information
`
`The commit server 112 takes the metadata updates from the file server 102
`
`and generates a new version of the file system 108. Atkin at 6:27-30; 8:28-31 (Ex.
`
`1104). Creating this new version of the file system 108 “requires updating each
`
`block in inode tree 204 and thus imap tree 210 in addition to superblock 214…”
`
`Id. at 6:33-37 (Ex. 1104). The superblock, imap, and inode structures written by
`
`the commit server to the block store contain information about the file system and
`
`are shown in red below:
`
`12
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`Id., Figure 2 (annotated) (Ex. 1104).
`
`Atkin does not describe providing content addresses for any of the stored
`
`information associated with the file system structures shown in red. Atkin states
`
`that the commit server updates the structures shown in red above to create a new
`
`file system version that is accessed by timestamps and version numbers. Atkin at
`
`7:64-8:8 (Ex. 1104). Metadata, which in Atkin includes inode 204, inode tree 206,
`
`imap tree 210, imap 212, superblock 214 and other information, is written to the
`
`13
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`block store “separately from and without regard to the file server 102.” Id. at 2:40-
`
`43 (Ex. 1104). The metadata and file system information stored in block store 106
`
`by the commit server 112 does not receive a content address, because file server
`
`102 is the only component in Atkin that discloses “generating a content address.”
`
`Id. at 3:28-33 (Ex. 1104).
`
`IV.
`
`CLAIM CONSTRUCTION
`
`The Petition equates the “blocks” disclosed in Atkin “to objects” of 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.
`
`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
`
`14
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`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).
`
`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
`
`15
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`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.
`
`See Pet. at 24. The plain and ordinary meaning of “object,” when correctly
`
`applied, does not encompass the “blocks” in Atkin.
`
`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.
`
`16
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`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 Atkin does not discuss objections, Petitioner argues that Atkin
`
`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 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,
`
`17
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`64-65 (Ex. 1101). 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.
`
`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. 1101). The drafters made a similar
`
`distinguishing statement during prosecution. See Exhibit 11123, at 33 (Declaration
`
`3 “Applicant’s Response Dated May 8, 2013” is attached to the Petition as Exhibit
`
`1112. The Inventor Declaration referenced here is included in that response.
`
`18
`
`

`
`Case IPR2016-01780
`U.S. Patent No. 8,478,799
`
`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