`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF WISCONSIN
`
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
`
`SANDISK CORPORATION,
`
`Plaintiff,
`
`v.
`
`KINGSTON TECHNOLOGY CO., INC. and
`KINGSTON TECHNOLOGY CORP.,
`
`OPINION and ORDER
`
`10-cv-243-bbc
`
`Defendants.
`- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
`
`In this patent infringement suit, plaintiff SanDisk Corporation contends that
`
`defendants Kingston Technology Co., Inc. and Kingston Technology Corp. are infringing
`
`plaintiff’s United States Patents Nos. 7,397,713 (‘713 patent); 7,492,660 (‘660 patent);
`
`7,657,702 (‘702 patent); 7,532,511 (‘511 patent); 7,646,666 (‘666 patent); and 7,646,667
`
`(‘667), all of which are related to flash memory technology. Now before the court are the
`
`parties’ cross motions for construction of certain terms found in the claims being asserted
`
`in these patents. I construe the terms as provided below.
`
`OPINION
`
`A. Background
`
`In a previous case between the parties, a consolidated action including Cases Nos. 07-
`
`cv-605-bbc and 07-cv-607-bbc, plaintiff asserted several patents against defendants that
`
`1
`
`IPR2015-01949
`Exhibit 2001
`Page 1 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 2 of 67
`
`relate to flash memory technology, and in particular, technology known as “flash EEPROM”
`
`(Electrically Erasable Programmable Read Only Memory). In the consolidated action, I
`
`construed several claim terms related to the patents at issue in that case, U.S. Patents Nos.
`
`6,757,842 (‘842 patent); 6,149,316 (‘316 patent); 5,719,808 (‘808 patent); 6,426,893 (‘893
`
`patent); and 6,763,424 (‘424 patent). The patents asserted in this case are related to those
`
`patents; each of the patents asserted in this lawsuit is a divisional patent or a continuation
`
`of one of the patents that plaintiff asserted against defendants in the consolidated action and
`
`shares a specification with those patents. There are three separate “groups” of patents in this
`
`case, which relate to the patents in the consolidated action as follows:
`
`•
`
`•
`
`the ‘713 and ‘660 patents are entitled “Flash EEPROM System” and share a
`
`specification with the ‘842 patent, ‘316 patent and‘808 patent;
`
`the ‘702 patent is entitled “Partial Block Data Programming and Reading
`
`Operations in a Non-Volatile Memory” and shares a specification with the
`
`‘424 patent; and
`
`•
`
`the ‘511, ‘666 and ‘667 patents are entitled “Flash EEPROM System with
`
`Simultaneous Multiple Data Sector Programming and Storage of Physical
`
`Block Characteristics in Other Designated Blocks” and share a specification
`
`with the ‘893 patent.
`
`2
`
`IPR2015-01949
`Exhibit 2001
`Page 2 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 3 of 67
`
`B. Claims to be Construed:
`
`The parties seek construction of fifteen terms, as follows.
`
`A. Terms from the ‘713 and ‘660 patents:
`
`1.
`
`2.
`
`“Address register file” (‘713 pat., cl. 1) and “register file” (‘713 pat., cl.
`11); and
`
`“defective memory location” (‘660 pat., cl. 1) and “defective location”
`(‘660 pat., cl. 15);
`
`B. Terms from the ‘702 patent:
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`“Logical addresses” (‘702 pat., cls. 1, 16, 24 and 33);
`
`“Page” (‘702 pat., cl. 1);
`
`“Sub-array” (‘702 pat., cls. 1 and 33)
`
`“updatable data structure” (‘702 pat., cl. 1) and “updatable address
`information” (‘702 pat., cl. 16);
`
`“memory controller” (‘702 pat., cls. 24 and 33); and
`
`The “Update Programming Step,” as the parties call it (‘702 pat., cls.
`1, 16, 24 and 33).
`
`C. Terms from the ‘511, ‘666 and ‘667 patents:
`
`1.
`
`2.
`
`3.
`
`“Defective” (‘511 pat., cl. 7);
`
`“Attach the calculated redundancy codes” (‘667 pat., cl. 5) and “adding
`the generated code to the user data” (‘511 pat., cl. 1);
`
`“Generating a redundancy code” (‘511 pat., cls. 1 and 15);
`
`3
`
`IPR2015-01949
`Exhibit 2001
`Page 3 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 4 of 67
`
`4.
`
`5.
`
`6.
`
`7.
`
`“Storing, in individual ones of the second group of said blocks” (‘511
`pat., cls. 14 and 6 and ‘667 pat., cl. 1);
`
`“A record stored in the memory system” (‘666 pat., cl. 1);
`
`“A controller adapted to [] communicate user data” (‘667 pat., cl. 1);
`and
`
`“A controller adapted to [] write data” (‘667 pat., cl. 1).
`
`As was the case in the consolidated action, the parties’ disputes about the meaning
`
`of each term relate to differing views about the scope of the claims more than differing views
`
`about which language is clearest and easiest to understand. For that reason, although I will
`
`resolve the parties’ disputes regarding whether the disputed limitations they identify should
`
`apply to the terms at issue, I will not endeavor to provide specific definitions for each term.
`
`As I explained to the parties in the consolidated action, providing such specific definitions
`
`tends only to encourage disputes about the meaning of those definitions. Sandisk v. Phison
`
`Electronics Corp., Case No. 07-cv-607-bbc, dkt. #582, at 5 (“It is counterproductive to
`
`resolve claims construction disputes by replacing them with new ones for the parties to
`
`dispute about at summary judgment.”). To the extent the parties seek to use specific
`
`language to describe a given claim term to the jury, they can move in limine.
`
`C. ‘713 Patent and ‘660 Patent
`
`1. “Address register file” (‘713 pat., cl. 1) and “register file” (‘713 pat., cl. 11)
`
`4
`
`IPR2015-01949
`Exhibit 2001
`Page 4 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 5 of 67
`
`Surrounding Claim
`Language
`
`Plaintiff’s Proposed
`Construction
`
`Defendants’ Proposed
`Construction
`
`controller
`said
`wherein
`includes an address register
`file, and is such as to allow a
`host logical address from
`said host system to be
`converted to a physical
`address of said nonvolatile
`s e m i c o n d u c t o r
`f l a s h
`memory based on data
`stored
`in
`said address
`register file, [’713—1]
`
`controller
`said
`wherein
`includes a register file to
`store defect mapping data;
`[’713—11]
`
`An “address register file” is a
`memory structure within the
`controller having data that
`allows a host logical address
`from said host system to be
`converted to a physical
`address of said nonvolatile
`s e m i c o n d u c t o r
`f l a s h
`memory
`
`the controller includes a file
`that can be loaded into a
`register and is sufficient to
`map the logical addresses
`corresponding to a defective
`memory
`location to the
`physical address of a
`replacement good memory
`location
`
`is a
`file”
`The “register
`t h e
`m e m o r y w i t h i n
`controller used to store
`defect mapping data.
`
`For these terms, the parties’ principal disputes are (1) whether “address register file”
`
`from claim 1 and “register file” from claim 11 of the ‘713 patent mean the same thing (and
`
`thus whether claim 1's “address register file” must be used to store defect mapping data and
`
`claim 11's “register file” must allow a logical address from a host system to be converted to
`
`a physical flash address); (2) whether the “address register file” from claim 1 must include
`
`all the information needed to map the logical address corresponding to a defective location
`
`to a physical address of a replacement location; and (3) whether the “register file” from claim
`
`11 must contain a defect map. Defendants seek all of these limitations.
`
`5
`
`IPR2015-01949
`Exhibit 2001
`Page 5 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 6 of 67
`
`a. The terms “address register file” from claim 1 and “register file” from claim 11 do not
`mean the same thing
`
`Defendants argue that the two claim terms are identical because “the term ‘register
`
`file’ should have a single meaning for all of the claims.” Dkt. #109, at 8. However, the fact
`
`that the term “register file” may have a single meaning does not mean that the “address
`
`register file” described in detail in claim 1 must include all the features described in detail
`
`with respect to the “register file” in claim 11 or vice versa. Indeed, the fact that the
`
`requirements of each term are described in detail is evidence that the term “register file” is
`
`a general term and the claims describe separate, distinct tasks that the claimed “register file”
`
`must perform in each instance.
`
`Defendants’ contention that the “address register file” in claim 1 and the “register
`
`file” in claim 11 both include the requirements described in each separate claim works only
`
`if the requirements listed in each claim were already part of the meaning of “register file,”
`
`meaning it would be superfluous to list those requirements. The claim language does not
`
`support a reading of these two terms as identical for the simple reason that both terms are
`
`followed by specific language describing the data that must be stored in the claimed “file”
`
`in each instance. The specific language from each of these independent claims cannot be
`
`lifted out and transported to the other simply because both refer to a “register file.”
`
`Defendants point to the specification as evidence that there is only one type of
`
`6
`
`IPR2015-01949
`Exhibit 2001
`Page 6 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 7 of 67
`
`“register file,” but their sole citation relating to storage in a register file is a statement that
`
`“the defect pointer map” is “stored in the register file 509.” ‘713 pat., col. 9, ln. 45.
`
`Apparently, their view is that such a “defect pointer map” must include both the defect
`
`mapping data described in claim 11 and the address conversion data described in claim 1.
`
`Defendants do not explain why this is so, but more important, the statement they rely on
`
`occurs in the context of describing Figure 6, which “illustrates the read data path control in
`
`the preferred embodiment.” Id., col. 8, lns. 59-60. Although Figure 6 illustrates both “load[ing]
`
`the header information (Head, Cylinder and sector) into a holding register file 509,” id., col.
`
`9, lns. 3-5, and “load[ing] . . . bad address locations into the holding register file 509,” id.,
`
`col. 9, lns. 25-26; it remains nothing more than a preferred embodiment. The fact that a
`
`preferred embodiment contains limitations is not a sufficient reason to import those
`
`limitations into the claim itself, especially when doing so would disregard the broader claim
`
`language. Phillips v. AWH Corp., 415 F.3d 1303, 1323 (Fed. Cir. 2005) (claim should not
`
`be limited simply because specific embodiment shows requested limitation).
`
`According to defendants, the use of the term “file” in “register file” in claims 1 and
`
`11 and throughout the specification supports a finding that there can be only one such
`
`“register file,” that all relevant “register” data must be “stored in the same place.” Dkt.
`
`#109, at 9. However, without any suggestion in the specification or the terms that only one
`
`“register file” can exist, there is no basis for reading in such a limitation. Indeed, the
`
`7
`
`IPR2015-01949
`Exhibit 2001
`Page 7 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 8 of 67
`
`specification refers to “a holding register file” used for storing header information, id., col.
`
`9, ln. 4-5, suggesting that a separate “register file” could be used to store other information.
`
`In conclusion, the two terms at issue do not mean the same thing. The “address register file”
`
`in claim 1 need not be “used to store defect mapping data” as required in claim 11 and the
`
`“register file” in claim 11 need not be “such as to allow a host logical address from said host
`
`system to be converted to a physical address of said nonvolatile semiconductor flash memory
`
`based on data stored” in the address register file as required in claim 1.
`
`b. The “address register file” need not contain all the information needed to convert a host
`logical address into a physical address
`
`According to defendants, the claimed “file” must contain enough information to allow
`
`a host logical address from the host system to be converted to a physical address “without
`
`using information stored elsewhere or engaging in any separate calculations or other
`
`operations.” Dkt. #109, at 10. As a starting point, this argument relates only to claim 1's
`
`“address register file” because, as explained above, the “register file” in claim 11 need not
`
`contain address conversion data. However, even for claim 1's address register file, the claim
`
`language does not reach as far as defendants contend. The claim requires only that the
`
`address register file contain enough data to “allow a host logical address . . . to be converted
`
`to a [flash] physical address . . . based on data stored in said address register file.”
`
`8
`
`IPR2015-01949
`Exhibit 2001
`Page 8 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 9 of 67
`
`Defendants contend that the requirement that the conversion be “based on data stored in
`
`said address register file” means that must be based only on such data. However, the word
`
`“only” is absent from the claim, and thus the claim language alone does not support its
`
`imposition.
`
`Defendants contend that the specification also supports their position, pointing to the
`
`following statement:
`
`When the controller is given an address to access data, the controller compares
`this address against the sector defect map. If a match occurs then access to the
`defective sector is denied and the substitute address present in the defect map
`is entered and the corresponding substitute sector is accessed instead.
`
`‘713 pat., col. 11, lns. 47-52. Although defendants suggest that this language is used to
`
`describe the “invention,” it appears in a paragraph describing “another embodiment.” Again,
`
`without more, the presence of certain features in an embodiment do not support reading a
`
`limitation into the claim itself. In short, defendants’ citations fail to support a requirement
`
`that claim 1's “address register file” contain all the information needed to perform the
`
`claimed address conversion.
`
`c. The “register file” in claim 11 need not contain a “defect map”
`
`Defendants also contend that the claimed “register file” must contain a defect map,
`
`by which they seem to mean that it must contain all defect mapping data. Because, as
`
`9
`
`IPR2015-01949
`Exhibit 2001
`Page 9 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 10 of 67
`
`explained above, the two terms at issue do not have the same meaning, this argument would
`
`apply only to claim 11. However, neither the claim language nor the specification supports
`
`requiring a defect map to be stored in the “register file” in claim 11. Defendants point to the
`
`following passages:
`
`One feature of the invention allows defect mapping at cell level in which a
`defective cell is replaced by a substitute cell from the same sector. The defect
`pointer which connects the address of the defective cell to that of the
`substitute cell is stored in a defect map. Every time the defective cell is
`accessed, its bad data is replaced by the good data from the substitute cell.
`
`***
`
`The present invention also has provision for defect mapping of the whole
`sector, but only after the number of defective cells in the sector has exceeded
`the cell defect mapping’s capacity for that specific sector. . . . When the
`number in a sector exceeds a predetermined value, the controller marks that
`sector as defective and maps it to another sector. The defect pointer for the
`linked sectors may be stored in a sector defect map.
`
`‘713 pat., col. 2, lns. 30-36 and col. 11, lns. 31-39.
`
`Neither passage establishes that claim 11 requires the register file to contain a
`
`complete defect map. The passages provide only that the claimed invention provides for
`
`defect mapping at both the cell and sector level and that a cell-level defect pointer is stored
`
`in a defect map and a sector-level pointer “may be” stored in such a map. Neither passage
`
`ties the defect map to the claimed “register file.”
`
`Even if the discussion of a defect map suggested storage of the map in the claimed
`
`10
`
`IPR2015-01949
`Exhibit 2001
`Page 10 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 11 of 67
`
`register file, at most, this would make such storage a preferred embodiment of claim 11, not
`
`an element of the claim. The claim language states that the “register file” in claim 11 must
`
`store “defect mapping data,” not a defect map. In the specification, the inventor referred to
`
`both a “defect map” and “defect mapping data,” without ever equating the two. At most,
`
`a “defect map” is a specific sort of “defect mapping data.” Because the claim language uses
`
`broader language, the narrower “defect map” is not a limitation of the claim. Thus, claim
`
`11's “register file” need only store “defect mapping data,” not a defect map.
`
`The parties do agree on one point about the meaning of the claim terms: “the ‘defect
`
`mapping data’ in the asserted claims contains enough information to directly link each
`
`defective memory location to a replacement memory location.” Defs.’ Br., dkt. #109, at 10-
`
`11; Plt.’s Resp. Br., dkt. #117, at 5. However, neither party is seeking that construction, and
`
`in light of their agreement, there is no dispute to resolve with respect to this aspect of the
`
`claim term.
`
`2. “defective memory location” (‘660 pat., cl. 1) and “defective location” (‘660 pat., cl. 15)
`
`Surrounding Claim
`Language
`
`Plaintiff’s Proposed
`Construction
`
`Defendants’ Proposed
`Construction
`
`11
`
`IPR2015-01949
`Exhibit 2001
`Page 11 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 12 of 67
`
`receiving a logical address at
`a controller for the flash
`m e m o r y
`a r r a y
`a n d
`determining that the logical
`address corresponds to a
`defective memory location
`[’660—1]
`
`a selecting unit receiving a
`logical address for the flash
`memory array, determining
`that the
`logical address
`corresponds to a defective
`location [’660—15]
`
`The term “defective” refers
`to a condition whereby the
`block (as a whole) is deemed
`unusable.
`
`A memory location may be
`deemed defective when the
`bit fails to program and/or
`erase.
`
`the
`that
`determining
`received
`logical address
`corresponds to a memory
`l o c a t i o n w h i c h h a s
`accumulated such a number
`of defective cells that the
`defects cannot be corrected
`by the error correction codes
`(ECC) corresponding
`to
`data stored in the memory
`location
`
`The parties agree that the claimed “defective memory location” in claim 1 of the ‘660
`
`patent and “defective location” from claim 15 of the ‘660 patent have the same meaning, but
`
`they disagree about what that meaning must be. The parties’ disputes for this term are: (1)
`
`whether the claimed “defective memory location” must always be an entire block or could
`
`also be a single cell; and (2) whether a memory location can be “deemed defective” even if
`
`the defects can still be corrected by error correction code. (Plaintiff suggests that there is a
`
`third dispute, whether a memory location can be deemed defective other than by use of the
`
`error correction code. However, defendants do not seek a construction that would impose
`
`any limitation on “the reason a certain memory location becomes defective.” Defs. Resp. Br.,
`
`dkt. #119, at 7.)
`
`12
`
`IPR2015-01949
`Exhibit 2001
`Page 12 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 13 of 67
`
`a. “Defective memory location” is not limited to a “block”
`
`As defendants point out, the patent refers both to defective blocks, also known as
`
`sectors, and defective cells, or bits. ‘660 pat., col. 11, lns. 28-30 (describes marking “sector”
`
`as defective and maps it to another sector); id., col. 11, lns. 18-21 (describes writing
`
`“collection of bits” flagged as defective into memory at “alternative defects data locations”).
`
`Moreover, the claim uses the term “memory location” instead of “block.”
`
`Defendants’ citations support reading the claimed “memory location” more broadly
`
`than “block,” as defendants contend. Plaintiff contends that the surrounding claim language
`
`shows otherwise. ACTV, Inc. v. Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir. 2003)
`
`(court must consider context of surrounding words of claim when construing term). As
`
`plaintiff points out, in claim 1 of the ‘660 patent, “defective memory location” appears in
`
`step (a), which involves determining that a logical address received by the controller
`
`“corresponds to a defective memory location.” The next step in claim 1 involves
`
`“determining . . . a block of the flash memory array to access based on the received logical
`
`address.” This citation does not support a requirement that the claimed memory location
`
`be of a “block.” The mere fact that a block is ultimately accessed “based on the received
`
`logical address” does not mean the address must refer to an entire block; a logical address of
`
`a single cell within a block could allow a controller to determine which block to access.
`
`13
`
`IPR2015-01949
`Exhibit 2001
`Page 13 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 14 of 67
`
`b. Meaning of “defective”
`
`The parties’ principal disagreement is about what is required for a memory location
`
`to be deemed “defective.” The term is not defined in the claims or specification, and the
`
`surrounding language of the claims provides no guidance on what the term means. Plaintiff
`
`contends that the term must be read broadly, citing its expert’s assertion that a person of
`
`ordinary skill in the art would understand that a block is “defective” when it is deemed
`
`“unusable by the controller of the system.” In addition, plaintiff points to two instances in
`
`the specification describing designating memory locations as defective, contending these
`
`disclosures show that the controller decides whether a block is defective. First, the
`
`specification explains that “[i]f a bit fails to verify after prolonged program/verify cycling, the
`
`controller will designate that bit as defective and update the defect map accordingly.” ‘660
`
`pat., col. 11, lns. 4-6. Next, the specification adds that “[w]hen the number [of defective
`
`cells] in a sector exceeds a predetermined value, the controller marks that sector as defective
`
`and maps it to another sector.” Id., col. 11, lns. 28-30.
`
`Plaintiff’s citations support their position that the controller determines when a block
`
`is defective. However, plaintiff is not merely seeking a construction that the controller
`
`determines when a block is defective. Instead, they are attempting to argue that the criteria
`
`a controller may apply when determining this may be extremely broad: a block may be
`
`deemed defective when a bit fails to program or erase. In other words, when a single bit goes
`
`14
`
`IPR2015-01949
`Exhibit 2001
`Page 14 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 15 of 67
`
`bad, the controller may deem the entire block “defective.” (Defendants point out that a
`
`single block averages 2.16 million bits these days, but the specification was dealing with a
`
`less drastic scale, refer to “sectors,” or blocks, of only 512 bytes, or 4,096 bits. ‘660 pat., col.
`
`5, lns. 1-2.)
`
` The cited language does not support plaintiff’s broad construction. Although the
`
`controller may deem a block defective at some “predetermined value,” nothing suggests that
`
`value could be any number of bits, including a single bit. Indeed, plaintiff’s suggestion that
`
`any value can be set as the “predetermined value” would make the term “defective”
`
`meaningless: the predetermined value could just be set at 0 and then all fully functional
`
`blocks would be defective blocks.
`
`Moreover, plaintiff’s reading of “defective” would result in large numbers of non-
`
`defective cells going unused because they reside within a block containing a single defective
`
`cell. Although such “wastefulness” in itself is not necessarily a problem, it is a problem in
`
`the context of this patent because the specification explains that avoiding wastage is a key
`
`aspect of the invention:
`
`In a disk system made from such [flash] memory devices, low cost
`considerations necessitate efficient handling of defects. [Aside from the use
`of flash memory chips instead of conventional memory, a]nother important
`feature of the invention enables the error correction scheme to conserve as
`much memory as possible. Essentially, it calls for the defective cells to be
`remapped cell by cell rather than by throwing away the whole sector (512
`bytes typically) whenever a defect occurs in it.
`
`15
`
`IPR2015-01949
`Exhibit 2001
`Page 15 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 16 of 67
`
`‘660 pat., col. 7, lns. 42-51. Elsewhere, the specification explains that “the present invention
`
`has provision for defect mapping of the whole sector, but only after the number of defective
`
`cells in the sector has exceeded the cell defect mapping’s capacity for that specific sector.”
`
`Id., col. 11, lns. 24-27; see also id., col. 7, ln. 65-col. 8, ln. 5 (“One important feature of the
`
`present invention is the ability for the system to correct for hard errors whenever they occur.
`
`. . . Also during read operation, defective cells are detected and located by the [error
`
`correction code]. As soon as a defective cell is identified, the controller will apply defect
`
`mapping to replace the defective cell with a space cell located usually within the same sector.
`
`This dynamic correction of hard errors, in addition to conventional error correction schemes,
`
`significantly prolongs the life of the device.”).
`
`Thus, plaintiff’s construction will not be adopted. The patent specification’s
`
`description of the “present invention” as “conserv[ing] as much memory as possible” and
`
`providing for defect mapping “only after the number of defective cells has exceeded the cell
`
`defect mapping’s capacity” makes it clear that an entire block should be deemed defective
`
`only in limited circumstances; the presence of one single defective bit would not suffice.
`
`Trading Technologies International, Inc. v. eSpeed, Inc., 595 F.3d 1340, 1353-54 (Fed. Cir.
`
`2010) (describing limitation as part of “the present invention” or “the invention” is strong
`
`evidence that claims should be limited); see also Honeywell International, Inc. v. ITT
`
`Industries, Inc., 452 F.3d 1312, 1318 (Fed. Cir. 2006) (four references to fuel filter as “this
`
`16
`
`IPR2015-01949
`Exhibit 2001
`Page 16 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 17 of 67
`
`invention” or “the present invention” warranted limiting the invention to fuel filter).
`
`Moreover, these descriptions support defendant’s view that determining when a block
`
`or other memory location becomes “defective” should relate to the capacity of the error
`
`correction code (or at least the “error correction scheme” to the extent there is a difference)
`
`to correct the defects within that block. As mentioned above, the invention limits the
`
`availability of sector defect mapping to “after the number of defective cells in the sector has
`
`exceeded the cell defect mapping’s capacity for that specific sector.” ‘660 pat., col. 11, lns.
`
`24-27. Although the specification does not explain what that “capacity” must be except to
`
`note that it is some “predetermined value,” another aspect of the invention is that it includes
`
`an “error correction scheme” aimed at conserving “as much memory as possible” and
`
`“essentially” remapping defects cell-by-cell within a sector. Id., col. 7, lns. 42-51.
`
`Plaintiff contends that the reference to conserving “as much memory as possible”
`
`using an “error correction scheme” need not amount to a limitation on block defect mapping
`
`and suggests that the reference is related to aspects of the invention other than the claim
`
`term in dispute. However, when plaintiff was asked at the claims construction hearing to
`
`identify some other part of the patent that might “carry out” the concept of conserving as
`
`much memory as possible, plaintiff could not identify any. Hrg. Tr., dkt. #127, at 14-18.
`
`(The closest plaintiff comes is to note that the “columns of the patent,” the specification,
`
`refers to both sector mapping and cell mapping.)
`
`17
`
`IPR2015-01949
`Exhibit 2001
`Page 17 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 18 of 67
`
`Thus, the invention includes a requirement that the controller must wait until the
`
`memory location’s cell defect mapping “capacity” has been reached to deem the memory
`
`location defective and in the meantime must use an “error correction scheme” to
`
`“essentially” remap cell-by-cell.
`
`1. “Logical addresses” (‘702 pat., cls. 1, 16, 24 and 33)
`
`D. ‘702 Patent
`
`Surrounding Claim Language
`
`Plaintiff’s
`Proposed
`Construction
`
`Defendants’ Proposed
`Construction
`
`18
`
`IPR2015-01949
`Exhibit 2001
`Page 18 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 19 of 67
`
`first
`programming a
`plurality [group] of pages
`in a first block, each
`individual page being
`p r o g r a m m e d w i t h
`original data and an
`address
`sufficient
`to
`identify the individual
`page of data
`
`— n o n - p h y s i c a l
`address associated
`with the data
`
`— “logical address” is
`not
`limited to an
`address sufficient to
`identify an individual
`page of data
`
`— A “logical address”
`is not necessarily
`programmed into a
`first plurality of pages
`in a first block.
`
`programming a first group of a
`plurality of pages in at least the first
`and second blocks with original data,
`the pages of original data having
`logical addresses associated therewith
`[’702—1]
`
`into
`programming original data
`individual ones of a first plurality of
`pages in at least a first block, the
`original data having logical addresses
`associated therewith [’702—16]
`
`programming the received plurality of
`pages of original user data into a first
`plurality of pages of storage elements
`[’702—24]
`
`programming the received plurality of
`pages of original data into a first
`plurality of pages of storage elements
`[’702—33]
`
`There are two issues related to this term: (1) whether the logical address must be of
`
`a specific page of data; and (2) whether the logical address must be programmed into the
`
`page or pages to which it is designated. The parties agree that a logical address is a non-
`
`physical address associated with certain data, but disagree about where the logical address
`
`must be located and what details it must include.
`
`19
`
`IPR2015-01949
`Exhibit 2001
`Page 19 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 20 of 67
`
`a. “Logical address” need not refer to a specific “page”
`
`According to defendants, the claimed “logical address” must refer to a specific “page”
`
`as opposed to only part of a page or multiple pages. Defendants point out that the asserted
`
`claims repeatedly refer to data in terms of pages. However, the claim language at issue does
`
`not restrict the language as defendants suggest. For example, claim 1 requires “pages of
`
`original data having logical addresses associated therewith.” ‘702 pat., cl. 1. (Claim 16
`
`leaves out the word “pages.”) However, the language does not suggest that there can be only
`
`one page for each logical address or one logical address for each page.
`
`Defendants do not cite any reference in the claim language or the specification that
`
`would prevent such a setup. Instead, they argue only that the ‘702 patent is a “page-based
`
`system” and for such a system to work, “the logical address of each page must be sufficient
`
`to identify that individual page.” Defs.’ Resp. Br., dkt. #119, at 11. This is not the right
`
`time to be arguing about whether the patent will “work.” Indeed, the law prohibits
`
`construing claims more narrowly just to fix an unworkable patent. Chef America, Inc. v.
`
`Lamb-Weston, Inc., 358 F.3d 1371, 1374 (Fed. Cir. 2004) (“[C]ourts may not redraft
`
`claims, whether to make them operable or to sustain their validity.”). To the extent there
`
`is an enablement problem because the disclosures in the patent would not create a workable
`
`product, that is a matter for summary judgment or trial.
`
`In short, defendants offer no persuasive reason why the claimed “logical addresses”
`
`20
`
`IPR2015-01949
`Exhibit 2001
`Page 20 of 67
`
`
`
`Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 21 of 67
`
`must be limited to referring to a single page and why a page could not have more than one
`
`such “logical address.”
`
`b. “Logical address” need not be programmed into th