throbber
Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`
`Chart showing Obviousness of U.S. Patent No. 8,301,906 (“the ’906 patent”) over
`U.S. Patent No. 7,020,835 (“Loaiza”) in view of U.S. Patent No. 7,937,404
`(“Tripathi”).
`
`
`Patent Claim
`1. An apparatus for writing
`checksum information on a
`data content on a storage
`medium, comprising:
`
`
`
`a provider for providing
`checksum information
`based on a data content;
`and
`
`Invalidity Support
`A preamble is not generally considered limiting.
`Georgetown Rail Equip. Co. v. Holland L.P., 867
`F.3d 1229, 1236 (Fed. Cir. 2017). To the extent that
`the Board finds otherwise, Loaiza discloses, or at
`least renders obvious, this element.
`
`Loaiza generates a checksum from a block of data.
`See EX1006, 3:27-29 (“According to one
`technique, a physical checksum calculation is
`performed on a block of data.”).
`
`Loaiza also discloses that the checksum is stored on
`a storage medium. See EX1006, 6:9-12 (“In one
`embodiment, prior to causing a block of data to be
`written to data storage unit 112, application 204
`initiates a physical checksum calculation process
`220 to generate a checksum value for inserting into
`the data block.”); see also Fig. 2.
`
`Therefore, Loaiza discloses, or at least renders
`obvious, each element of the preamble of claim 1.
`EX1002 at ¶75.
`Loaiza discloses, or at least renders obvious, this
`limitation, regardless of whether this is interpreted
`as a means-plus-function or traditional element.
`
`Loaiza shows that a checksum is created based on
`the data content. See EX1006, 6:9-18. In particular,
`Loaiza discloses that, to create a checksum, a
`“logical operation” is performed on the data that is
`contained in a data block. See EX1006, 6:9-18. Fig.
`2, following, shows, in Step 220, a “Physical
`Checksum Calculation.” This is the “provider” of
`
`Unified Patents
`EX1009
`Page 1 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`the checksum information that calculates the
`checksum data and provides it to the storage device
`controller 206 for writing to the disk. See EX1006,
`6:17-18 and 6:51-53. A PHOSITA would also
`know that the checksum information could have
`been written separately from the data block. See
`EX1006, 6:34-39. Loaiza makes it clear that storing
`the checksum separately is a separate
`“embodiment” from storing it “in the data block.”
`See EX 1006, 31-34.
`
`Unified Patents
`EX1009
`Page 2 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`
`
`EX1006, Fig. 2; see also EX1006, 8:62-63 (“a
`physical checksum calculation process is performed
`on the block of data.”); 8:51-56; Fig. 4A.
`Alternatively, if this claim element is interpreted as
`a means-plus-function claim, Loaiza teaches both
`the function and the structure of the term. The
`
`Unified Patents
`EX1009
`Page 3 of 23
`
`

`

`
`
`a writer for writing the data
`content, the checksum
`information and control
`information on a physical
`or logical location of the
`checksum information on
`the storage medium,
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`function would be to provide the checksum
`calculation based on the block of data which Loaiza
`discloses. EX1006, 6:3-12, EX1002 at ¶76.
`Regarding structure, Loaiza discloses, for example,
`an XOR or ADD function performed on the data to
`create the checksum. EX1006, 6:13-15; EX1002 at
`¶76. The hashing algorithms identified by the ’906
`Patent’s specification (SHA-1 (SHA-Secure Hash
`Algorithm), SHA-256, MD5 (MD=Message Digest
`Algorithm) or custom AES-128 (AES-Advanced
`Encryption Standard)) were all well-known before
`the patent was filed. See, e.g., EX1012, 4:4-18
`(disclosing the SHA and MD5 algorithms in 2004).
`Therefore, Loaiza discloses, or at least render
`obvious in view of the knowledge of a PHOSITA,
`this element, even under a means plus function
`interpretation.
`Loaiza discloses, or at least renders obvious, this
`limitation, either alone or in view of Tripathi. The
`claim recites that the writer writes three
`classifications of components to the storage
`medium: (1) data content; (2) checksum
`information; and (3) control information about the
`physical or logical location of the checksum
`information. EX1002 at ¶77; see EX1001, 4:2-5.
`Loaiza discloses a writer that writes (1) data
`content; (2) the checksum information; and (3)
`control information. See EX1002 at ¶¶77-78.
`
`As an initial matter, Loaiza discloses a storage
`medium:
`Data storage unit 112 represents one or
`more nonvolatile memory components
`that are used for storing data for
`application 204. Data storage unit 112
`is not limited to any particular type of
`storage medium. In particular, as used
`herein, the term nonvolatile memory
`is broadly defined as any type of
`
`Unified Patents
`EX1009
`Page 4 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`storage or persistent
`persistent
`media
`that can be used
`for
`persistently storing information. In
`this example, data storage unit 112
`represents a Redundant Array of
`Independent Disks or Drives (RAID)
`that includes a disk array unit 210 and
`one or more disks 114-118.
`EX1006, 5:47-56 (emphasis added). In all cases,
`the “writer” is the “Storage device controller” 206,
`as follows.
`With respect to (1) data content; (2) checksum
`information; and (3) control information about the
`physical or logical location of the checksum
`information:
`
`(1) Loaiza discloses that the data block is stored
`to one or more disks 114-118 (i.e., the storage
`medium), possibly over a network. See EX1006,
`6:51-53; 8:58-61; see also EX1006, 16:10-11 (“A
`method for storing a data block to a nonvolatile
`memory…” (claim 5)). Thus, Loaiza discloses a
`writer for writing the data content. See EX1002 at
`¶¶75, 77.
`
`(2) Loaiza generates a checksum from a block of
`data. See EX1006, 3:27-29 (“According to one
`technique, a physical checksum calculation is
`performed on a block of data.”). Loaiza discloses
`that the checksum is stored on a storage medium.
`See EX1006, 6:9-12 (“In one embodiment, prior to
`causing a block of data to be written to data storage
`unit 112, application 204 initiates a physical
`checksum calculation process 220 to generate a
`checksum value for inserting into the data block.”);
`Fig. 2; 8:62-65; see also EX1006, 16:21-24 (“The
`method as recited in claim 5, further comprising
`storing, in association with the data block,
`
`Unified Patents
`EX1009
`Page 5 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`checksum data used in the physical checksum
`verification to the nonvolatile memory.” (claim 6)).
`Thus, Loaiza discloses a writer for writing the
`checksum information. See EX1002 at ¶¶75, 77. A
`PHOSITA would also know that the checksum
`information could have been written separately
`from the data block. See EX1006, 6:34-39; EX1002
`at ¶78. Loaiza makes it clear that storing the
`checksum separately is a separate “embodiment”
`from storing it “in the data block”. See EX1006,
`31-34.
`
`(3) Loaiza discloses that control information
`regarding the location of the checksum information
`is also written to the storage medium, in one of
`several ways. See EX1002 at ¶¶75, 77. The
`physical address on a storage medium where a data
`block is stored may be stored within the block. See
`EX1006, 10:32-35 (“a desired block address (or a
`portion thereof) may be stored in each data block to
`identify a physical or logical address (or a portion
`thereof) where the data block is to be stored in
`nonvolatile memory”); 10:47-52; EX1006, 15:57-
`58, 61-63 (“A method for evaluating a data block,
`the method comprising… verifying whether
`address data contained within the data block
`specifies a location in nonvolatile memory where
`the data block is to be stored…” (claim 1));
`EX1002 at ¶67. Loaiza further discloses that the
`checksum is stored on a storage medium; and, in
`fact, may be stored in the data block. See EX1006,
`6:9-12 (“In one embodiment, prior to causing a
`block of data to be written to data storage unit 112,
`application 204 initiates a physical checksum
`calculation process 220 to generate a checksum
`value for inserting into the data block.”); Fig. 2;
`8:62-65. As the data block is stored with the
`checksum, storing the address of the data block on
`
`Unified Patents
`EX1009
`Page 6 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`the storage medium also stores the address of the
`checksum. EX1002 at ¶77.
`
`Loaiza also discloses that the checksums
`themselves can be written separately from the data,
`e.g. in a separate lookup table or database for later
`processing. EX1006, 6:31-39 (“Checksum values
`may be maintained separate from data blocks and
`… checksum values could be passed in routine
`calls or maintained in a lookup table or database
`and then retrieved as needed.”). Thus, Loaiza
`discloses maintaining checksum values in a
`separate lookup table or database. A PHOSITA
`would have understood that the index to the lookup
`table or database would have disclosed a logical
`location of the checksum because it would refer to
`the location in the lookup table or database where
`the checksum is located. That is, a PHOSITA
`would have recognized that to put information in a
`lookup table or database so that it could be
`retrieved later, the location within the lookup table
`or database would be needed to retrieve the data.
`As a result, a PHOSITA reading Loazia’s
`disclosure that the checksum is stored in a lookup
`table or a database would have found it at least
`obvious, if not inherent, to store the logical location
`of the checksum within the table or database (e.g.,
`an index) in order to retrieve it from the table or
`database when it was needed. EX1002 at ¶78. This
`is because storing information in a table or database
`to retrieve it later was well known, and a very
`common approach for retrieving the data from the
`lookup table or database was storing the location
`information so that the data could be looked up or
`otherwise retrieved. EX1002 at ¶78. For example,
`several methods would have been available to the
`PHOSITA for constructing such a lookup table or
`database to store the associated checksum
`information. One option would be to take the Inode
`
`Unified Patents
`EX1009
`Page 7 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`style data structure and add a pointer to the
`checksum location in the checksum table. Then
`checksum information can be retrieved by looking
`up the location of the checksum when the Inode
`data structure for the file is accessed. Other options
`would include creating a table of checksums or
`checksum locations indexed by the Inode number.
`EX1002 at ¶78. Thus, Loaiza alone discloses or at
`least renders obvious writing the claimed control
`information regarding the location of the checksum
`information.
`
`Regardless, Loaiza in combination with Tripathi
`discloses or at least renders obvious this claim
`element. EX1002 at ¶¶64-66, 77-78. As will be
`explained in more detail below, Loaiza discloses
`that data and its checksum (i.e., related data) can be
`written separately to a storage medium. EX1006,
`6:34-39; EX1002 at ¶65. Tripathi discloses a
`specific technique for how to store data, separately
`store related data, and store the location of the
`related data: storing data in an inode-based file
`system where the logical address of the related data
`is stored as part of the metadata of the (primary)
`data. EX1007, 4:25-45; EX1002 at ¶65. A
`PHOSITA would have recognized that checksums,
`though not mentioned in Tripathi, are the type of
`information that would be desirable to prefetch
`with associated data. EX1002 at ¶65. The
`combination would operate such that Loaiza would
`store the data and its checksum separately (as it
`expressly teaches) and store the location of the
`checksum in the inode table entry corresponding to
`the data (alongside other metadata of the file as
`Tripathi teaches). This discloses or at least renders
`obvious writing the claimed control information on
`the location of the checksum.
`
`
`Unified Patents
`EX1009
`Page 8 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`Tripathi discloses a method of using caching and
`prefetching of data stored on a storage medium
`such that overall speed of accessing data files is
`increased. EX1002 at ¶68. Tripathi discloses
`accessing a first file, then accessing a metadata file
`that indicates a prefetching policy, then, according
`to a prefetching policy, access other files to
`prefetch along with the first file. Tripathi discloses
`the metadata uses block addresses to specify the
`other files to prefetch. A PHOSITA would have
`understood this pointer system as an effective way
`to quickly access a file and prefetch its checksum.
`EX1002 at ¶68.
`
`More specifically, as disclosed in Tripathi, when a
`file is requested, the file system accesses an inode
`table1 to retrieve the inode entry corresponding to
`the file requested (after checking cache maintained
`by the operating system). See EX1007, 4:25-29.
`Tripathi uses the “inode” information to try to
`locate the file in a disc cache. See EX1007, 4:31-
`35. If the file has not yet been located, Tripathi
`discloses retrieving the file and returning it to the
`requester. See EX1007, 4:43-45. First, however, the
`system checks to see if the file has a “prefetch”
`record associated with it, saved as metadata 228
`(which is also an inode entry), that is associated
`with a file and stored in inode table 214. See
`EX1007, 4:48-50, 6:35-38, FIGS. 2-3; see also
`EX1007, 9:7-10 (“16. A data processing system as
`claimed in claim 1, further comprising: an inode
`table that stores the metadata associated with the
`file and with other files.”).
`
`
`1 The inode (index node) is a data structure in a Unix-style file system that
`describes a file-system object such as a file or a directory. Each inode stores the
`attributes and disk block location(s) of the object's data. File-system object
`attributes may include metadata (times of last change, access, modification), as
`well as owner and permission data. EX1002 at ¶65.
`
`Unified Patents
`EX1009
`Page 9 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`
`The metadata comprises information such as the
`logical or physical file location(s) of the files to
`prefetch. See EX1007, 6:9-30, 10:3:6 (“an inode
`operations field containing a pointer to a block of
`routine addresses that are specific to an underlying
`file system and which perform operations in
`relation to the inode”).
`
`Tripathi discloses that the metadata is stored to a
`disc. “It will be appreciated that a copy of the
`prefetch table 230 can also be stored with the file
`204.” EX1007, 5:4-5. Note the prefetch information
`can also be stored separately from the file. EX1007,
`5:7-11. The file is stored on the hard disc drive.
`The files are the “data blocks” fetched “from the
`hard disc drive.” See EX1007, 4:42-46; see also
`4:5-48 (part of a general discussion on file access).
`This the metadata is stored on hard disc drive (with
`the file).
`
`The concept of associating conventional file
`location information with prefetch data of other
`information that is likely to be needed, and
`performing a prefetch, is a general one. Though the
`embodiment described in Tripathi is explained in
`the context of a UNIX operating system, these
`concepts could be practiced by a PHOSITA as a
`user program or application. EX1002 at ¶71.
`
`Thus, Tripathi discloses associating the location of
`a data block in a separate location from the data
`block and associating the data with other metadata,
`such as prefetch data. See EX1007, 5:4-11; EX1002
`at ¶72.
`
`In combination with Loaiza, a PHOSITA would
`have known that prefetching checksum data would
`be useful as it is an example of “data requested by
`
`Unified Patents
`EX1009
`Page 10 of 23
`
`

`

`
`
`such that a baseline reader
`and an enhanced reader
`can read the data content,
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`the application” that could be a prefetched block.
`EX1007, 1:51-57. In this case, the “application” in
`Tripathi is the “application” specified in Loaiza.
`EX1002 at ¶72.
`In combination with Loaiza, a PHOSITA would
`know that a related file to prefetch as disclosed by
`Tripathi would be a checksum file as disclosed by
`Loaiza, such that the metadata comprises at least
`one logical address pointing to the checksum. See
`EX1002 at ¶74. One of skill in the art would have
`sought out the technique disclosed in Tripathi
`because Loaiza sought to reduce the time required
`to access a file and Tripathi’s prefetching was one
`such solution. EX1002 at ¶¶58, 59. And a
`PHOSITA would expect the combined system to
`improve Loazia in the same way the technique
`improved Tripathi. KSR, 550 U.S. at 417. Thus,
`information regarding the location of the checksum
`information is written to the storage medium, as
`recited by the ’906 patent. EX1002 at ¶74.
`This limitation is a purpose statement that is not
`limiting. EX1002 at ¶51. In case the Board decides
`otherwise, the following discussion explains why
`this limitation is disclosed or at least rendered
`obvious.
`
`Loaiza discloses, or at least renders obvious, this
`limitation. EX1002 at ¶75. Loaiza discloses a
`verification sequence for retrieving previously-
`written data from nonvolatile memory as shown in
`Fig. 4B. Specifically, Loaiza discloses identifying,
`locating, and retrieving a data block from non-
`volatile memory (i.e., the storage medium). See
`EX1006, 9:43-53; Fig. 4B. The process is
`illustrated in Fig. 4B, and in particular, Step 454:
`
`Unified Patents
`EX1009
`Page 11 of 23
`
`

`

`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`
`EX1006, Fig. 4B (Step 454). The baseline and
`enhanced reader functions are both performed, as
`disclosed by Loaiza, by application 204, which is
`disclosed as representing “a variety of different
`software applications that are configured to
`manipulate data and to store and retrieve data from
`
`Unified Patents
`EX1009
`Page 12 of 23
`
`

`

`
`
`the enhanced reader can
`read and process the
`control information and the
`checksum information and
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`data storage unit 112.” EX1006, 5:64-66. Loaiza
`also discloses a baseline reader and an enhanced
`reader, as discussed in the next two elements. Thus,
`Loaiza discloses, or at least renders obvious, this
`element. See EX1002 at ¶75.
`This limitation is a purpose statement that is not
`limiting. EX1002 at ¶51. In case the Board decides
`otherwise, the following discussion explains why
`this limitation is disclosed, or at least rendered
`obvious, by Loaiza in view of Tripathi.
`
`Loaiza, either alone or in view of Tripathi,
`discloses, or at least renders obvious, this
`limitation. Loaiza discloses a reader that can read
`and process the control information and the
`checksum information. See EX1002 at ¶¶80-82. For
`example, Loaiza discloses an embodiment that
`reads a block location identifier (that is, an example
`of control information) previously stored in the data
`block, and processes that identifier to verify that the
`data block is stored in the correct location on the
`storage medium. EX1006. 10:37-43. The reader as
`disclosed by Loaiza can also process checksum
`information that it reads from the data block.
`EX1006, 9:61-67.10:6-11 see also EX1006, 16:21-
`24 (“The method as recited in claim 5, further
`comprising storing, in association with the data
`block, checksum data used in the physical
`checksum verification to the nonvolatile memory.”
`(claim 6)).
`
`For the alternative embodiment where the
`checksum is stored in a separate table or database, a
`PHOSITA would know to perform the simple
`modifications needed to retrieve the separately
`stored checksum data after referencing the table.
`EX1002 at ¶81.
`Further, in the alternative embodiment where the
`control information is stored separately from the
`
`Unified Patents
`EX1009
`Page 13 of 23
`
`

`

`
`
`the baseline reader ignores,
`skips or does not read the
`checksum information.
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`data block, a PHOSITA would know how to
`perform the simple modifications in light of the
`combination of Loaiza and Tripathi, as a PHOSITA
`would know, as discussed in more detail with
`respect to element 1(c), above, and would have
`been motivated to replace the data file of Tripathi
`with a checksum as generated by Loaiza, such that
`the metadata comprises at least one logical address
`pointing to the checksum and one logical address
`pointing to the data block. See EX1002 at ¶¶74, 80.
`
`This limitation is a purpose statement that is not
`limiting. EX1002 at ¶51. In case the Board decides
`otherwise, the following discussion explains why
`this limitation is disclosed or at least rendered
`obvious.
`
`Loaiza discloses, or at least renders obvious, this
`limitation. As discussed, above, Loaiza discloses a
`data block that comprises data content, checksum
`information, and control information, where said
`data block is written to a storage medium. EX1006,
`6:9-12, 6:31-39, 6:51-53, 8:58-65, 10:32-35, 10:47-
`52, Fig. 2. In the disclosed verification sequence for
`retrieving data from non-volatile memory shown in
`particular by Fig. 4B (as previously discussed,
`above), a data block is identified (Fig. 4B, step
`452), located, and retrieved (Fig. 4B, step 454).
`EX1006, 9:48-53, Fig. 4B. Loaiza discloses that, in
`step 456 in Fig. 4, “one or more components may
`optionally perform a physical checksum
`verification procedure to verify the integrity of the
`retrieved data block.” EX1006, 9:54-56 (emphasis
`added). An optional checksum verification process
`may be skipped, which would therefore ignore the
`checksum information. EX1006, 9:54-56. Thus, the
`checksum information regarding that data block is
`ignored, skipped, or not read, as recited by the
`claim element. EX1002 at ¶82.
`
`Unified Patents
`EX1009
`Page 14 of 23
`
`

`

`
`
`
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`
`The ’906 patent does not require that the baseline
`and enhanced readers be separate devices; rather,
`the ’906 patent teaches the opposite—the readers
`may be functions implemented on the same
`component. EX1002 at ¶52. And this is what
`Loaiza teaches as well. Thus, Loaiza discloses or at
`least renders this limitation obvious.
`
`3. The
`apparatus of
`claim 1,
`wherein the
`writer is
`adapted for
`writing on
`an optical
`disc, the
`optical disc
`having a
`user data
`area being
`adapted for
`storing the
`data
`content,
`wherein the
`writer is
`adapted for
`writing the
`control
`information
`on the
`physical or
`logical
`location of
`the
`checksum
`
`Loaiza explicitly discloses that “[c]ommon forms of computer-
`readable media include, for example, … a CD-ROM, any other
`optical medium…”. EX1006, 14:32-35. Thus, Loaiza in view of
`Tripathi disclose, or at least renders obvious, writing to an optical
`disc. EX1002 at ¶84.
`
`Moreover, such technology was exceedingly well known in the art
`at the time of the ’906 patent. See EX1002 at ¶84; EX1011, 1:28-
`31; EX1017, pp. 18-19. One contemporary example that provides
`additional details of what was known to a PHOSITA, is U.S.
`Patent No. 5,235,585 to Bish, which discloses the standardized
`details of such optical discs (or disks). See, e.g., EX1011, 1:28-31
`(“Peripheral storage devices include … optical storage devices.”);
`2:16 (“An optical disc is an example of a storage medium…”);
`EX1002 at ¶84. Bish, as exemplary of the specifics of commonly
`known media at the time, further discloses that optical discs, as an
`industry standard, comprise a “user zone,” or user data area.
`EX1011, 2:66-3:3, 3:6-10; EX1002 at ¶84. Thus, Bish
`demonstrates that “the optical disc having a user data area being
`adapted for storing the data content” was within the knowledge of
`a PHOSITA and therefore at least obvious. EX1002 at ¶84; Yeda
`Research and Development Co., Ltd. v. Mylan Pharmaceuticals
`Inc., Nos. 2017-1594, -1595, -1596 at *16-17 (Fed. Cir., Oct. 12,
`2018) (holding that the Board can consider non-prior art evidence
`in considering the knowledge, motivations, and expectations of a
`PHOSITA).
`
`Further, the element “writing the control information on the
`physical or logical location of the checksum information or
`
`Unified Patents
`EX1009
`Page 15 of 23
`
`

`

`
`
`information
`or integrity
`information
`into the user
`data area.
`
`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`integrity information into the user data area” is also disclosed.
`Loaiza discloses that the data blocks written to the storage medium
`are associated with an application. EX1006, 6:9-15. Contemporary
`standards for optical discs, including CD-ROMs, defined a user
`data area to which such information was written. EX1017, pp. 18-
`19; EX1002 at ¶84. A PHOSITA would have known that
`application data is commonly written to a user area of a disc.
`EX1002 at ¶84. As discussed above with respect to claim 1,
`element (c), Loaiza discloses the location information (i.e., the
`claimed “control information) could be written together with the
`data and the checksum in the data blocks on the storage medium.
`
`Also, Loaiza’s teaching that the checksum could be stored
`separately at least renders obvious writing the control information
`into the data area. As explained above with respect to claim 1,
`element (c), Loaiza teaches that the checksum information could
`be stored in a lookup table or database which a PHOSITA would
`have understood included location information (e.g., an index) so
`that the checksum could be retrieved. A PHOSITA would have
`further understood that there were commonly just two choices as
`to where to store the table or database: in an area for user data or
`in a different area. EX1002 at ¶84. This alone is sufficient to
`render storing it in the user data area obvious. KSR, 550 U.S. at
`421. What’s more, the user data area would have been the choice
`most common for a PHOSITA to choose because Loaiza discloses
`that the data being stored is part of an application as discussed
`above. EX1002 at ¶84.
`
`Finally, Tripathi’s teachings also render obvious storing the
`claimed control information in a user data area. As discussed
`above with respect to claim 1, element (c), Tripathi discloses
`storing location information on a related file (e.g., a checksum as a
`PHOSITA would have understood) in a filesystem table of
`metadata. A PHOSITA would have further understood that there
`were commonly just two choices as to where to store such a table:
`in an area for user data or in a different area. EX1002 at ¶84. This
`alone is sufficient to render storing it in the user data area obvious.
`KSR, 550 U.S. at 421. While it may have been common to store
`filesystem tables in an area for system data, a PHOSITA would
`
`Unified Patents
`EX1009
`Page 16 of 23
`
`

`

`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`have understood that in the context of an optical disc, it would
`have been advantageous to include the filesystem table in a user
`data area so that it could be modified as files were added rather
`given the inflexible nature of rewriting data in an optical disc.
`EX1002 at ¶85. As such, a PHOSITA would have known that the
`inode tables of Tripathi could have been implemented in a user
`data area. This also renders this limitation obvious.
`Thus, Loaiza in combination with Tripathi, discloses, or at least
`renders obvious, the elements of this claim. See EX1002 at ¶84.
`Loaiza generates a checksum from a block of data. See EX1006,
`3:27-29 (“According to one technique, a physical checksum
`calculation is performed on a block of data.”). As discussed above,
`Loaiza discloses that the checksum is stored on a storage medium.
`See EX1006, 6:34-39; Fig. 2; 8:62-65; EX1002 at ¶¶77-78, 85; see
`also EX1006, 16:21-24 (“The method as recited in claim 5, further
`comprising storing, in association with the data block, checksum
`data used in the physical checksum verification to the nonvolatile
`memory.” (claim 6)). The checksum process is performed on each
`file saved to the storage medium; therefore, Loaiza discloses that
`checksums are provided for all data files stored on the storage
`medium. EX1006, 4:59-62. For example, Loaiza discloses
`verifying each block of data associated with an application when
`saving all the data to backup storage. EX1006, 12:28-33.
`
`Loaiza does not explicitly disclose that the checksum information
`is written to the logical end of the storage medium. But such a
`feature was well known to a PHOSITA. EX1002 at ¶85. EX1018,
`for example, explains that when writing new information to a
`CDROM, each piece of new information is written to the logical
`end of the data written so far. EX1002 at ¶85. If the checksum was
`calculated after the data was written, the checksum would be
`written to the logical end of the data written so far. Id. As
`discussed above, Loaiza describes collecting the checksums of the
`files into a single table. Id.; EX1006, 6:34-39. Since that table has
`to refer to all the data sets it would be reasonable to a PHOSITA to
`write the checksum table to the CD last if the CD is being written
`incrementally. EX1002 at ¶85. Since the items are written
`sequentially in order that would place the checksum table at the
`logical end of the CD. Id. Further, it was known to a PHOSITA
`
`
`
`4. The
`apparatus of
`claim 1,
`wherein the
`data content
`comprises
`data files,
`wherein the
`provider for
`providing
`the
`checksum
`information
`is adapted
`for
`providing
`checksum
`information
`for all data
`files stored
`on the
`storage
`medium and
`wherein the
`writer is
`adapted for
`writing the
`checksum
`information
`or the
`
`Unified Patents
`EX1009
`Page 17 of 23
`
`

`

`Case No. IPR2019-00491
`U.S. Patent No. 8,301,906
`
`that a CD would need to have any new data written to the end of
`the drive, since previously-written data could not be deleted. Id.
`Thus, Loaiza either alone or in view of Tripathi discloses, or at
`least renders obvious, the elements of this claim. See EX1002 at
`¶¶85.
`
`Loaiza in combination with Tripathi teach or at least render
`obvious a chunk table. Loaiza discloses that the checksums
`themselves can be written to a separate lookup table or database
`for later processing. EX1006, 6:31-39 (“Checksum values may be
`maintained separate from data blocks and … checksum values
`could be passed in routine calls or maintained in a lookup table or
`database and then retrieved as needed.”). Tripathi discloses
`accessing a first file, then accessing a metadata file that indicates a
`prefetching policy, then, according to a prefetching policy, access
`other files or blocks to prefetch along with the first file. The
`metadata can use block addresses to specify the other files to
`prefetch.
`
` PHOSITA would have understood this as an effective way to
`quickly access a file and prefetch its checksum. EX1002 at ¶68.
`The table of Tripathi thus teaches a chunk table, in that the address
`of the data and the address of the checksum are both stored and
`associated in the metadata stored in that table. EX1007, 5:4-5;
`EX1002 at ¶86. Specifically, the address of the data and the
`address of the checksum are stored and associated in the metadata.
`See also element (c) of claim 1, above. Note, the ’906 patent
`describes a “chunk table specifying an association between data
`and checksums or integrity information.” EX1001, 4:10-11;
`EX1002 at ¶86. Tripathi further discloses that the metadata is
`stored to a disc. “It will be appreciated that a copy of the prefetch
`table 230 can also be stored with the file 204.” EX1007, 5:4-5.
`Note the prefetch information can also be stored separately from
`the file. EX1007, 5:7-11. The file is stored on the hard disc drive.
`The files are the “data blocks” fetched “from the hard disc drive.”
`See EX1007, 4:42-46; see also 4:5-48 (part of a general discussion
`on file access).
`
`
` A
`
`
`
`integrity
`information
`to the
`logical end
`of the
`storage
`medium.
`6. The
`apparatus of
`claim 1,
`wherein the
`writer is
`adapted for
`writing a
`control
`information
`comprising
`a chunk
`table
`specifying
`an
`association
`between
`data content
`and
`checksum
`information
`or integrity
`information
`on the
`storage
`medium.
`
`Unified Patents
`EX1009
`Page 18 of 23
`
`

`

`
`
`7. The
`apparatus of
`claim 1,
`wherein the
`writer is
`adapted for
`writing a
`128-bit
`checksum
`for a data
`segment to
`the storage
`medium.
`
`8. The
`apparatus of
`claim 1,
`which is
`impleme

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket