Trials@uspto.gov
`571-272-7822
`
`Paper 8
`Entered: March 22, 2017
`
`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 B2
`____________
`
`Before KRISTEN L. DROESCH, KALYAN K. DESHPANDE, and
`MICHAEL J. FITZPATRICK, Administrative Patent Judges.
`
`DROESCH, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314, 37 C.F.R. § 42.108
`
`
`571-272-7822
`
`Paper 8
`Entered: March 22, 2017
`
`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 B2
`____________
`
`Before KRISTEN L. DROESCH, KALYAN K. DESHPANDE, and
`MICHAEL J. FITZPATRICK, Administrative Patent Judges.
`
`DROESCH, Administrative Patent Judge.
`
`DECISION
`Denying Institution of Inter Partes Review
`35 U.S.C. § 314, 37 C.F.R. § 42.108
`
`
`
`IPR2016-01779
`Patent 8,478,799
`
`I. INTRODUCTION
`A. Background
`Springpath, Inc. (“Petitioner”) filed a Petition (Paper 3, “Pet.”) for
`
`inter partes review of claims 1, 2, 7–13, 17–20, 27, and 33–35 (“the
`challenged claims”) of U.S. Patent No. 8,478,799 B2 (“the ’799 Patent”).
`See 35 U.S.C. §§ 311–312. SimpliVity Corporation (“Patent Owner”)
`timely filed a Preliminary Response (Paper 7, “Prelim. Resp.”). See
`35 U.S.C § 313.
`
`We have authority under 35 U.S.C. § 314 and 37 C.F.R. § 42.4. An
`inter partes review may not be instituted unless it is determined that “the
`information presented in the petition filed under section 311 and any
`response filed under section 313 shows that there is a reasonable likelihood
`that the petitioner would prevail with respect to at least 1 of the claims
`challenged in the petition.” 35 U.S.C. § 314(a).
`
`After considering the Petition and Preliminary Response, for the
`reasons provided below, we determine, based on the record before us, that
`there is not a reasonable likelihood Petitioner would prevail in showing any
`of claims 1, 2, 7–13, 17–20, 27, and 33–35 is unpatentable.
`
`B. Related Proceedings
`The parties indicate the ’799 Patent is involved in the following
`
`related matters:
` SimpliVity Corp. v. Springpath, Inc., Case No. 4:15-cv-13345-TSH
`
`(D. Mass); and
`petition for inter partes review in Case No. IPR2016-01780
`
`(concurrently filed). Pet. 2; Paper 5, 1.
`
`
`2
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`
`C. The ’799 Patent (Ex. 1001)
`The ’799 Patent discloses computer file system data structures and
`
`methods and apparatus for naming and storing files. See Ex. 1001, 1:4–6.
`Figure 1 of the ’799 Patent is reproduced below:
`
`
`Figure 1 depicts various storage components in operating system kernel 101.
`See Ex. 1001, 10:25–26. POSIX® file system 104, Network File System
`(NFS) 102, and a new file system composed of namespace file system 107
`stacked on top of lightweight object file system 108 connected to virtual file
`system (VFS) 103. See id. at 10:30–38, 63–65. The new file system works
`alongside other file systems in kernel 101, and typically many file systems
`work in parallel. See id. at 10:38–39, 46–47. VFS 103 is used to abstract
`out common features of the file systems and provide a consistent user
`interface 160 to user 100. See id. at 10:33–39. “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 storage device 109, or
`it may be on a remote LUN.” Id. at 10:40–44. Object file system or object
`store 108 creates an object container that may sit on top of a raw LUN, a
`3
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`partition on a disk, or a large file. See id. at 10:59–61. Object store 108 may
`reference containers via network stack 106. See id. at 10:61–63. NFS 102
`sits on top of network stack 106, and network stack 106 is connected to LUN
`109 and Cloud 110. See id. at 10:63–67.
`
`Figure 2 of the ’799 Patent is reproduced below:
`
`
`Figure 2 depicts object store 108 of Figure 1 and various components. See
`Ex. 1001, 5:4–6, 11:1–2. Object store 108 contains binary, opaque objects
`P 201, Q 202, and R 203. An object can be of varying size, and resides at
`some offset in object container 206. See id. at 11: 3–9. Each object has a
`name or fingerprint (e.g., H(q), H(p), H(r)) which is a cryptographic digest
`or hash of the object’s entire content. See id. at 11:10–13. Index 204 keeps
`track of object names, object locations, and object references. See id. at
`11:14–15. There is an index entry for every object in the system, each entry
`containing a fingerprint of the object’s content, a reference count, physical
`locator (e.g., logical block number, reference to cloud object), and flags. See
`id. at 11:40–61. Object container 206 is a randomly addressable persistent
`
`
`
`4
`
`
`
`IPR2016-01779
`Patent 8,478,799
`storage abstraction, such as a raw LUN, a file, a partition on a disk, or a
`device across a Wide Area Network. See id. at 11:64–67.
`
`Figure 4 of the ’799 Patent is reproduced below:
`
`
`Figure 4 depicts a set of objects grouped together in an hnode. See
`Ex. 1001, 7:13–15, 12:51–52. Hnode 401 is a sequence of content, like a
`file that can be read, written, appended to, created, deleted, and truncated.
`See id. at 12:55–57. The data sequence is broken into discrete objects (e.g.,
`S 401, T 411, U 412) where the names of each object are stored in mapping
`table 402 which records the fingerprints (e.g., H(S), H(T), H(U)) of each
`object. See id. at 12:63–66. Hnode 401 is an object itself. See id. at 13:8.
`
`Figure 5 of the ’799 Patent is reproduced below:
`
`
`Figure 5 depicts an hnode specialized into files, directories, and imaps. See
`Ex. 1001, 6:16–18. Directory 505 is a mapping of inode numbers to file
`5
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`names. See id. at 13:31–33. Imap or inode map 502 translates inode
`numbers from directory 501 into an object digest or fingerprint. See id. at
`13:37–38.
`
`D. Illustrative Claims
`Claims 1 and 19 are independent, claims 2, 7–13, 17, and 18 depend
`
`from claim 1, and claims 20, 27, and 33–35 depend from claim 19. Claims 1
`and 19 are illustrative:
`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.
`
`
`
`
`
`6
`
`
`
`IPR2016-01779
`Patent 8,478,799
`19. A method comprising:
`a namespace file system accessing an object store, the object
`store holding files, data and metadata as objects, each object
`having an object fingerprint which is globally unique and
`derived from its content and used to access the object store;
`and
`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
`maintaining in the 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; and
`maintaining in the object store directory objects, each directory
`object comprising a mapping of inode numbers and file
`names;
`wherein each of the inode map object and directly1 object has
`its own object fingerprint derived from the content of the
`respective object.
`
`
`
`
`
`1 The word “directly” appears to be a typographical error of “directory.”
`7
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`
`E. Asserted Grounds of Unpatentability
`Petitioner challenges the patentability of the following claims on the
`
`following grounds based on the following references (Pet. 24–51):
`Statutory
`Reference(s)
`Claim(s)
`Basis
`1, 2, 7–9, 11, 12, 17–20, 27, and 33–35 § 102 (b) Li2
`10
`§ 103
`Li and Sandberg3
`13
`§ 103
`Li
`The Petition also relies on the Declaration of Dr. Darrell D. E. Long
`(Ex. 1002).
`
`II. ANALYSIS
`A. Claim Construction
`Claims of an unexpired patent that will not expire before issuance of a
`
`final written decision are interpreted using the broadest reasonable
`interpretation in light of the specification. See 37 C.F.R. § 42.100(b);
`Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–46 (2016). Under
`the broadest reasonable interpretation standard, claim terms are given their
`ordinary and customary 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 proposes explicit constructions for the terms “fingerprint”
`and “namespace file system.” See Pet. 21–24. Patent Owner disagrees with
`
`
`2 Ex. 1003, Jinyuan Li et al., Secure Untrusted Data Repository (SUNDR),
`USENIX ASSOCIATION OSDI ’04: 6TH SYMPOSIUM ON OPERATING
`SYSTEMS DESIGN AND IMPLEMENTATION, 2004, at 121 (“Li”).
`3 Ex. 1004, Russel Sandberg et al., Design and Implementation of the Sun
`Network Filesystem, PROCEEDINGS OF THE SUMMER USENIX CONFERENCE,
`1985, at 119 (“Sandberg”).
`
`8
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`Petitioner’s proposed constructions, and provides alternative constructions
`for “fingerprint” and “namespace file system.” See Prelim. Resp. 20–23.
`Patent Owner proposes an explicit construction for “object,” asserting that
`the meaning is distinct from the meaning for the term “block.” See id. at 11–
`20. As demonstrated in the analysis below, we need not construe explicitly
`the broadest reasonable interpretation of the terms “fingerprint,” “namespace
`file system,” and “object.” We need not construe explicitly any remaining
`claim term or phrase.
`
`B. Asserted Grounds of Unpatentability
`1. § 102 Unpatentability of Claims 1, 2, 7–9, 11, 12, 17–20, 27, and 33–35
`over Li
`a. Li (Ex. 1003)
`Li discloses a Secure Untrusted Data Repository (SUNDR) network
`
`file system. See Ex. 1003, title, 1214, col. 2.
`
`Figure 1 of Li is reproduced below:
`
`
`Figure 1 depicts SUNDR’s basic architecture. See Ex. 1003, 122, col. 1.
`SUNDR provides a file system interface to remote storage. See id. When
`applications access the file system, the client software internally translates
`their system calls into fetch and modify operations, which are implemented
`as SUNDR protocol RPCs (remote procedure calls) to the server. See id.
`
`
`4 All page references are to the original page numbers of the document.
`9
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`The server runs server software on a network machine with dedicated
`SUNDR disks or partitions to host one or more file systems. See id. Server
`functionality is divided between two programs, a consistency server, which
`handles update certificates and version structures, and a block store, which
`actually stores data, update certificates, and version structures on disk. See
`id. at 129, col. 2.
`
`Figure 2 of Li is reproduced below:
`
`
`Figure 2 depicts the persistent data structures SUNDR stores and indexes by
`hash. See Ex. 1003, 124, col. 2. “The block store indexes most persistent
`data structures by their 20-byte SHA-1 hashes, making the server a kind of
`large, high-performance hash table.” Id. In Figure 2, Li illustrates a
`directory block comprising a mapping of file names (e.g., “locore.S” and
`“main.c”) to principle, i-number pairs (e.g., (u2, 5), (g, 4)). See id. at Fig. 2.
`Li describes the principle is the user or group allowed to write the file, and i-
`number is a per-principal inode number. See id. at 124, col. 2. “Inodes
`themselves contain SHA-1 hashes of file data blocks and indirect blocks.”
`Id.; see id. at 125, Fig. 2 legend. Li illustrates inode i4 includes metadata,
`and a mapping of offsets to hashes H(d0) and H(d1) of file data blocks d0, d1,
`and an arrow pointing from inode i4 to file data block d0. See id. at Fig. 2.
`Li further illustrates, in Figure 2, an arrow pointing from inode i6 to
`10
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`directory block and another arrowing pointing from inode i6 to an unknown
`element. See id. A user’s i-table includes mapping of user i-numbers to i-
`hashes (e.g., H(i2) through H(i6)). See id. at 125, Fig. 2 legend. An i-hash
`(e.g., H(i2) through H(i6)) is a hash of an inode (e.g., i2 through i6). See id.
`A group i-table maps group inode numbers to user inode numbers. See id.
`An i-handle (e.g., group g’s i-handle, user u2’s i-handle) is a recursive
`application of a hash algorithm to compute the root of a hash tree containing
`a user or group i-table. See id.
`
`b. Claims 1, 2, 7–9, 11, 12, 17–20, 27, and 33–35
`Petitioner contends that Li discloses “each directory object comprising
`
`a mapping of inode numbers and file names; wherein each . . . directory
`object has its own object fingerprint derived from the content of the
`respective object,” as recited in independent claims 1 and 19. Pet. 33–35.
`Specifically, Petitioner contends that Li’s annotated Figure 2 “shows a
`directory block where the file name ‘locore.S’ is mapped to user u2’s inode
`number 5,” and, therefore, discloses “each directory object comprising a
`mapping of inode numbers and file names.” Pet. 33–34 (citing Ex. 1003,
`124, col. 2, reproducing Fig. 2); see Ex. 1002 ¶ 89 (Petitioner’s expert Dr.
`Long testifying identically). To address the remaining requirement that each
`directory object has its own object fingerprint derived from the content of
`the respective object, Petitioner makes the following assertions:
`A person of ordinary skill would understand that Li discloses
`that directories have their own fingerprints. For example,
`referring again to Fig. 2 of Li, a person of ordinary skill would
`understand that inode i6 represents a directory, because the
`blocks of data pointed to by inode i6 are directory blocks (as
`illustrated by the depicted directory block). Directory inode i6
`also has a fingerprint H(i6), which is stored in user u2’s i-table.
`11
`
`
`
`
`
`IPR2016-01779
`Patent 8,478,799
`Pet. 35–36 (reproducing Fig. 2 with annotations); see Ex. 1002 ¶ 92
`(Petitioner’s expert testifying identically). In sum, Petitioner’s position is
`that the directory block illustrated in Figure 2 of Li describes the limitation
`“each directory object comprising a mapping of inode numbers and file
`names” and Li’s illustration of inode i6 and hash H(i6) describes the
`limitation “each . . . directory object has its own object fingerprint derived
`from the content of the respective object.”
`Petitioner’s arguments are insufficient to demonstrate that Li discloses
`each and every limitation of the claims, as arranged in the claims. See
`Therasense, Inc. v. Becton, Dickenson and Co., 593 F.3d 1325, 1332 (Fed
`Cir. 2010) (“Anticipation requires the presence in a single prior art
`disclosure of all elements of a claimed invention arranged as in the claim.”).
`We agree with Patent Owner’s arguments that Li does not disclose
`calculating a hash value of the directory block. See Prelim. Resp. 29. Patent
`Owner points out that Li discloses “[t]he block store indexes most
`persistent data structures by their 20-byte SHA-1 hashes,” (id. (quoting
`Ex. 1003, 124, col. 2)), and we agree with Patent Owner that there is no
`explicit indication in Li that directory blocks are the kind of data structure
`that are hashed. See id.
`Petitioner’s arguments also do not explain sufficiently how Li’s
`illustrations of inode i6 pointing to directory block and having its own of i-
`hash H(i6) discloses that Li’s directory block has a fingerprint or hash
`derived from the content of the directory block, as required as required by
`claims 1 and 19. Although we recognize that Li illustrates in Figure 2 an
`arrow pointing from inode i6 to the directory block (see Ex. 1003, Fig. 2), we
`agree with Patent Owner that the Petition does not provide a description of
`
`
`
`12
`
`
`
`IPR2016-01779
`Patent 8,478,799
`the means by which Li’s inode i6 refers to the directory block. See Prelim.
`Resp. 31; see also id. (Patent Owner asserting inode i4 demonstrates that
`inodes can contain information that is not hashed, such as the illustrated
`metadata entry). Li’s disclosure is silent regarding whether inode i6 includes
`a directory block hash or fingerprint derived from the content of the
`directory block. See Ex. 1003; see also Prelim. Resp. at 32 (“there is no
`indication that inodes contain hashes of anything other than a file data
`block.)” Lastly, to the extent Petitioner asserts that Li’s inode i6 discloses
`the claimed directory object, Petitioner’s arguments do not explain
`sufficiently how Li’s disclosure of inode i6 discloses “a mapping of inode
`numbers and file names,” as recited in claims 1 and 19. See Prelim Resp. 30
`(“inode i6 does not contain the directory object mapping required by the
`claim, and thus cannot be the directory object.”). It is axiomatic that “claims
`cannot be ‘treated . . . as mere catalogs of separate parts, in disregard of the
`part-to-part relationships set forth in the claims and that give the claims their
`meaning.’” Therasense, 593 F.3d at 1332 (quoting Lindemann
`Maschinenefabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1459
`(Fed. Cir. 1984).
`Therefore, based on the record before us, there is not a reasonable
`likelihood Petitioner would prevail in showing that independent claims 1 and
`19, and dependent claims 2, 7–9, 11, 12, 17, 18, 20, 27, and 33–35 are
`anticipated by Li.
`
`2. § 103 Unpatentability of Claim 10 over Li and Sandberg,
`and Claim 13 over Li
`Claims 10 and 13 depend from claim 1. As applied by Petitioner, the
`
`teachings of Sandberg, and the additional teachings of Li do not remedy the
`
`
`
`13
`
`
`
`IPR2016-01779
`Patent 8,478,799
`deficiencies of Li discussed in the preceding section. See Pet. 46–51.
`Accordingly, for the same reasons as those addressing claims 1 and 19 in the
`preceding section, based on the record before us, there is not a reasonable
`likelihood Petitioner would prevail in showing that claims 10 and 13 are
`unpatentable.
`
`III. CONCLUSION
`For the foregoing reasons, based on this record there is not a
`reasonable likelihood Petitioner would prevail in showing any of claims 1, 2,
`7–13, 17–20, 27, and 33–35 of the ’799 Patent is unpatentable.
`
`IV. ORDER
`Accordingly, it is ORDERED that inter partes review of U.S. Patent
`
`No. 8,478,799 is not instituted based on this Petition.
`
`
`
`
`
`14
`
`
`
`IPR2016-01779
`Patent 8,478,799
`
`PETITIONER:
`
`WILMER CUTLER PICKERING HALE AND DORR LLP
`
`Jason Kipnis
`Theodoros Konstantakopoulos
`
`Jason.Kipnis@wilmerhale.com
`Theodoros.Konstantakopoulos@wilmerhale.com
`
`PATENT OWNER:
`
`MINTZ, LEVIN, COHN, FERRIS,
`GLOVSKY AND POPEO, P.C.
`
`Michael T. Renaud
`Michael J. McNamara
`
`mtrenaud@mintz.com
`mmcnamara@mintz.com
`SimpliVity_IPRs@mintz.com
`
`
`
`
`
`
`
`15
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
