`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