throbber
Case: 3:10-cv-00243-bbc Document #: 131 Filed: 03/16/11 Page 1 of 67
`
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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-01945
`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

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