Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`Paper 9
`Entered: March 21, 2017
`
`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 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 9
`Entered: March 21, 2017
`
`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 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-01780
`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 8, “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-01779
`
`(concurrently filed). Pet. 3; Paper 6, 1.
`
`
`2
`
`
`
`
`
`IPR2016-01780
`Patent 8,478,799
`
`C. The ’799 Patent (Ex. 1101)
`The ’799 Patent discloses computer file system data structures and
`
`methods and apparatus for naming and storing files. See Ex. 1101, 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. 1101, 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 many file systems typically
`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-01780
`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. 1101, 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-01780
`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 a hnode. See Ex. 1101,
`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 a hnode specialized into files, directories, and imaps. See
`Ex. 1101, 6:16–18. Directory 505 is a mapping of inode numbers to file
`5
`
`
`
`
`
`IPR2016-01780
`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-01780
`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-01780
`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. 27–57):
`Statutory
`Reference(s)
`Claim(s)
`Basis
`§ 102 (b) Atkin2
`1, 2, 7–9, 12, 17–19, 27, and 35
`Atkin and
`§ 103
`10, 20, 33, and 34
`Sandberg3
`§ 103
`Atkin and Li4
`11, 20, 33, and 34
`§ 103
`Atkin
`13
`The Petition also relies on the Declaration of Dr. Darrell D. E. Long
`(Ex. 1102).
`
`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).
`
`
`2 Ex. 1104, US Patent No. 7,747,663 B2 (filed Mar. 5, 2008) (“Atkin”).
`3 Ex. 1116, Russel Sandberg et al., Design and Implementation of the Sun
`Network Filesystem, PROCEEDINGS OF THE SUMMER USENIX CONFERENCE,
`1985, at 119 (“Sandberg”).
`4 Ex. 1103, 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”).
`8
`
`
`
`
`
`IPR2016-01780
`Patent 8,478,799
`
`Petitioner proposes explicit constructions for the terms “fingerprint”
`and “namespace file system.” See Pet. 23–26. Patent Owner disagrees with
`Petitioner’s proposed constructions, and provides alternative constructions
`for “fingerprint” and “namespace file system.” See Prelim. Resp. 23–26.
`Patent Owner proposes an explicit construction for “object,” as distinct from
`the meaning for the term “block.” See id. at 14–22. As demonstrated in the
`analysis below, we need not construe explicitly the broadest reasonable
`interpretation of “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, 12, 17–19, 27, and 35
`over Atkin
`a. Atkin (Ex. 1104)
`Atkin discloses a system and methods for storing information
`
`efficiently using and underlying content addressable storage (CAS). See Ex.
`1104, 1:44–46.
`
`Figure 1 of Atkin is reproduced below:
`
`
`Figure 1 depicts a combination of a conventional CAS system with a file
`system front end (e.g., data input). See Ex. 1104, 2:29–32. Storage system
`9
`
`
`
`
`
`IPR2016-01780
`Patent 8,478,799
`100 include a CAS used as block store 106, and file server 102 that receives
`data operations (e.g., creation and/or modification of data/file(s)) and
`metadata operations (e.g., inserting a file in a directory, changing
`permissions, removing a file) from client 104. See id. at 2:33–39, 49–52.
`File server 102 chunks the received data into data blocks to be stored in
`block store 106, and sends to commit server 112 a list of operations to apply
`to metadata. See id. at 2:52–55. File server 102 includes block cache 114,
`for caching data blocks stored in data block store 106, metadata cache 116,
`for caching metadata information, and uncommitted block table 118, used to
`store content addresses of data blocks recently written by file server 102 but
`not yet committed in a version of file system 108. See id. at 3:15–22, 49–54.
`Block store 106 stores data blocks organized into file system 108. See
`
`Ex. 1104, 2:55–58. Block store 106 includes update log 110 for storing a
`log containing operations that must be applied to commit server 112 to
`create file system 108. See id. at 2:58–60, 3:2–6. Commit server 112
`updates metadata of file system 108. See id. at 4:13–15. Commit server 112
`includes commit metadata cache 120 for storing metadata prior to generating
`a new version of file system 108. See id. at 4:21–23. In operation, storage
`system 100 processes file writes (e.g., storing data blocks in block store 106)
`and metadata updates (e.g., storing a version file system 108 in block store
`106) asynchronously. See id. at 6:19–22. Instead of writing a new file
`system version each time a data block is stored in block store 106, storage
`system 100 may batch multiple updates of the file system into a single file
`system write by commit server 112. See id. at 6:22–30.
`
`
`
`10
`
`
`
`IPR2016-01780
`Patent 8,478,799
`
`Figure 2 of Atkin is reproduced below:
`
`
`Figure 2 depicts file system 108. See Ex. 1104, 4:6–7, 5:31–32. File system
`108 is a data structure that emulates a tree structure. See id. at 4:7–8, 5:34–
`35. File system 108 has a Unix-like structure where files, directories, and/or
`symbolic links, such as data blocks 202 (e.g., data blocks received from file
`server 102) and or associated information are represented by inodes 204.
`See id. at 5:43–47. Inodes 204 are data structures in the Unix-like structure
`that store basic information (e.g., metadata, content addresses) about data
`files and other data structures. See id. at 5:47–50. Inodes 204 are root
`blocks of inode trees 206, which may be B+trees and provide mapping to
`data blocks 202 using the addresses of data blocks 202. See id. at 5:50–53.
`Each inode 204 is indexed by an individual inode number in imap block 208
`that is part of imap tree 210. See id. at 5:55–57. Imap tree 210 is a data
`structure, such as a B+tree; with a root block, that is imap 212. See id. at
`
`
`
`11
`
`
`
`IPR2016-01780
`Patent 8,478,799
`5:57–58. Imap 212 includes imap tree 210 and is an array of inode numbers
`and addresses of inodes 204 split into fixed sized imap blocks 208 and
`indexed by imap tree 210. See id. at 5:62–65. Imap 212, as a mapping of
`inodes 204, keeps track of valid inode numbers that are in use and content
`addresses for corresponding inodes 204. See id. at 5:65–67. Imap 212 is
`stored in superblock 214. See id. at 6:6–7. Superblock 214 incorporates
`pointers to imap 212, parameters for file system 108, and a version number
`of the file system. See id. at 6:7–9. File system 108 has a superblock for
`each version of file system 108 written by commit server 112. See id. at
`6:13–15.
`
`b. Claims 1, 2, 7–9, 12, 17–19, 27, and 35
`Petitioner contends that Atkin discloses “an inode map object
`
`comprising a mapping of file system inode numbers and object
`fingerprints . . . wherein each of the inode map object and directory object
`has its own object fingerprint derived from the content of the respective
`object,” as recited in claim 1 and independent claim 19. Pet. 37–40.
`Specifically, Petitioner asserts that Atkin discloses imap 212 is a mapping of
`inode numbers and content addresses (i.e., fingerprints) for corresponding
`inodes 204. See id. at 37–38 (quoting Ex. 1104, 5:55–6:2); see also
`Ex. 1104 ¶¶ 98–100 (Petitioner’s expert Dr. Long testifying identically). To
`address the remaining requirement that each inode map object has its own
`object fingerprint derived from the content of the respective object,
`Petitioner asserts the following:
`Atkin discloses this limitation. For example, Atkin
`explains that imap 212 is a block. See Atkin at 5:57–58 (“The
`imap tree 210 is itself a data structure, such as a B+ tree, with a
`
`
`
`12
`
`
`
`IPR2016-01780
`Patent 8,478,799
`root block that is imap 212” (emphasis added).) Decl. ¶ 103
`(Ex. 1102).
`. . .
`
`
`
`Because each block is represented by a content address
`derived from the content of that block, a person of ordinary
`skill would understand that the imap and the directory objects
`are represented by content addresses (i.e., fingerprints) derived
`from their content. Decl. ¶ 105 (Ex. 1102).
`
`
`
`
`Pet. 39–40 (quoting Ex. 1104, 5:42–47); see Ex. 1102 ¶¶ 103–105
`(Petitioner’s expert testifying identically).
`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 argument that Atkin does not disclose
`generating a content address (i.e., fingerprint) for imap 212. See Prelim.
`Resp. 37–39. Instead of disclosing a content address, Atkin discloses that
`superblock 214 incorporates pointers to imap 212. See Ex. 1104, 6:6–9. We
`give little weight to Dr. Long’s opinion (see Ex. 1102 ¶¶ 103, 105) because
`it is not supported by underlying facts. See 37 C.F.R. § 42.65. For example,
`there is insufficient underlying facts to support the premise that each block
`disclosed in Atkin’s file system 108 is represented by a content address. See
`Pet. 39‒40. Patent Owner correctly points out that, although Atkin discloses
`that content addresses are generated for data blocks 202, there is no
`disclosure in Atkin that imap 212 is a data block. See id. at 38–39
`(reproducing Ex. 1104, Fig. 2 with annotations).
`
`
`
`13
`
`
`
`IPR2016-01780
`Patent 8,478,799
`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, 12, 17, 18, 27, and 35 are anticipated by
`Atkin.
`
`2. § 103 Unpatentability of Claims 10, 20, 33, and 34 over Atkin and
`Sandberg, Claims 11, 20, 33, and 34 over Atkin and Li,
`and Claim 13 over Atkin
`Claims 10, 11, and 13 depend from claim 1, and claims 20, 33, and 34
`
`depend from claim 19. As applied by Petitioner, the teachings of Sandberg,
`Li, and the additional teachings of Atkin do not remedy the deficiencies of
`Atkin discussed in the preceding section. See Pet. 48–57. 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, 11, 13, 20, 33 and 34 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-01780
`Patent 8,478,799
`
`PETITIONER:
`
`Jason Kipnis
`Theodoros Konstantakopoulos
`
`Jason.Kipnis@wilmerhale.com
`Theodoros.Konstantakopoulos@wilmerhale.com
`Wilmer Cutler Pickering Hale and Dorr LLP
`
`PATENT OWNER:
`
`Michael T. Renaud
`Michael J. McNamara
`
`mtrenaud@mintz.com
`mmcnamara@mintz.com
`SimpliVity_IPRs@mintz.com
`Mintz, Levin, Cohn, Ferris,
`Glovsky and Popeo, P.C.
`
`
`
`
`
`
`
`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
