This invention relates to semiconductor memory systems, particularly to non-volatile memory systems, and have application to flash electrically-erasable and programmable read-only memories (EEPROMs).
Flash EEPROM systems are being applied to a number of applications, particularly when packaged in an enclosed card that is removably connected with a host system. Current commercial memory card formats include that of the Personal Computer Memory Card International Association (PCMCIA), CompactFlash (CF), MultiMediaCard (MMC) and Secure Digital (SD). One supplier of these cards is SanDisk Corporation, assignee of this application. Host systems with which such cards are used include personal computers, notebook computers, hand held computing devices, cameras, audio reproducing devices, and the like. Flash EEPROM systems are also utilized as bulk mass storage embedded in host systems.
Such non-volatile memory systems include an array of floating-gate memory cells and a system controller. The controller manages communication with the host system and operation of the memory cell array to store and retrieve user data. The memory cells are grouped together into blocks of cells, a block of cells being the smallest grouping of cells that are simultaneously erasable. Prior to writing data into one or more blocks of cells, those blocks of cells are erased. User data are typically transferred between the host and memory array in sectors. A sector of user data can be any amount that is convenient to handle, preferably less than the capacity of the memory block, often being equal to the standard disk drive sector size, 512 bytes. In one commercial architecture, the memory system block is sized to store one sector of user data plus overhead data, the overhead data including information such as an error correction code (ECC) for the user data stored in the block, a history of use of the block, defects and other physical information of the memory cell block. Various implementations of this type of non-volatile memory system are described in the following United States patents and pending applications assigned to SanDisk Corporation, each of which is incorporated herein in its entirety by this reference: U.S. Pat. Nos. 5,172,338, 5,602,987, 5,315,541, 5,200,959, 5,270,979, 5,428,621, 5,663,901, 5,532,962, 5,430,859 and 5,712,180, and application Ser. No. 08/910,947, filed Aug. 7, 1997, and Ser. No. 09/343,328, filed Jun. 30, 1999. Another type of non-volatile memory system utilizes a larger memory cell block size that stores multiple sectors of user data.
One architecture of the memory cell array conveniently forms a block from one or two rows of memory cells that are within a sub-array or other unit of cells and which share a common erase gate. U.S. Pat. Nos. 5,677,872 and 5,712,179 of SanDisk Corporation, which are incorporated herein in their entirety, give examples of this architecture. Although it is currently most common to store one bit of data in each floating gate cell by defining only two programmed threshold levels, the trend is to store more than one bit of data in each cell by establishing more than two floating-gate transistor threshold ranges. A memory system that stores two bits of data per floating gate (four threshold level ranges or states) is currently available, with three bits per cell (eight threshold level ranges or states) and four bits per cell (sixteen threshold level ranges) being contemplated for future systems. Of course, the number of memory cells required to store a sector of data goes down as the number of bits stored in each cell goes up. This trend, combined with a scaling of the array resulting from improvements in cell structure and general semiconductor processing, makes it practical to form a memory cell block in a segmented portion of a row of cells. The block structure can also be formed to enable selection of operation of each of the memory cells in two states (one data bit per cell) or in some multiple such as four states (two data bits per cell), as described in SanDisk Corporation U.S. Pat. No. 5,930,167, which is incorporated herein in its entirety by this reference.
Since the programming of data into floating-gate memory cells can take significant amounts of time, a large number of memory cells in a row are typically programmed at the same time. But increases in this parallelism causes increased power requirements and potential disturbances of charges of adjacent cells or interaction between them. U.S. Pat. No. 5,890,192 of SanDisk Corporation, which is incorporated herein in its entirety, describes a system that minimizes these effects by simultaneously programming multiple chunks of data into different blocks of cells located in different operational memory cell units (sub-arrays).
There are several different aspects of the present invention that provide improvements in solid state memory systems, including those described above. Each of these aspects of the present invention, the major ones being generally and briefly summarized in the following paragraphs, may be implemented individually or in various combinations.
Multiple user data sectors are programmed into a like number of memory blocks located in different units or sub-arrays of the memory array by alternately streaming data from one of the multiple sectors at a time into the array until a chunk of data is accumulated for each of multiple data sectors, after which the chunks are simultaneously and individually stored in respective blocks in different units of the memory. This increases the number of memory cells that may be programmed in parallel without adverse effects.
An error correction code (ECC), or other type of redundancy code, may be generated by the controller from the streaming user data during programming and written into the same memory block as the user data from which it is generated. The redundancy code is then evaluated by the controller when the sector of data is read out of the memory block. A single redundancy code generation circuit is utilized, even when the streaming data is alternated between data chunks of the multiple sectors, by providing a separate storage element for each of the user data sectors being programmed at the same time, in which intermediate results of the generation are temporarily stored for each sector.
Overhead data of the condition, characteristics, status, and the like, of the individual blocks are stored together in other blocks provided in the array for this purpose. Each overhead data record may include an indication of how many times the block has been programmed and erased, voltage levels to be used for programming and/or erasing the block, whether the block is defective or not, and, if so, an address of a substitute good block, and the like. A group of blocks are devoted to storing such records. A large number of such records are stored in each of these overhead blocks. When accessing a specific user data block to perform one or all of programming, reading or erasing, the overhead record for that user data block is first read and its information used in accessing the block. By storing a block's overhead data outside of that block, frequent rewriting of the overhead data, each time the user data is rewritten into the block, is avoided. It also reduces the amount of time necessary to access and read the block overhead data when the block is being accessed to read or write user data. Further, only one ECC, or other redundancy code, need be generated for the large number of overhead records that are stored in this way.
The records from a number of overhead blocks can be read by the controller into an available portion of its random-access memory for ease of use, with those overhead blocks whose records have not been accessed for a time being replaced by more active overhead blocks in a cache-like manner. When a beginning address and number of sectors of data to be transferred is received by the memory controller from the host system, a logical address of the first memory block which is to be accessed is calculated in order to access the overhead record for that block but thereafter the overhead records are accessed in order without having to make a calculation of each of their addresses. This increases the speed of accessing a number of blocks.
Information of defects in the memory, such as those discovered during the manufacturing process, may also be stored in separate blocks devoted for this purpose and used by the controller so that the imperfect memory circuit chips may be included in the memory system rather than discarding them. This is particularly an advantage when a single defect record affects many blocks. One such defect is a bad column that is shared by a large number of blocks. A number of bad column pointers (BCPs) may be stored together as a table in one or more sectors that are devoted in part or entirely to this overhead data. When this is done, the physical location of the streaming user data being written to the memory is shifted when a comparison of the relative physical location within a sector of individual bytes of data with the BCP table indicates that the data byte is being directed to at least one memory cell that is along a bad column. The reverse is performed during reading, where data bits read from memory cells that were skipped over during write because of a bad column are ignored.
Since flash EEPROM cells have, by their nature, a limited life in terms of the number of times that they can be erased and reprogrammed, it is usually prudent to include one or more operational features that tend to even out the wear on the various memory blocks that can be caused by multiple rewrites to the same blocks. One such technique alters from time-to-time the correspondence between the digital data and the memory states that are designated to represent the digital data. To accomplish this in the present memory system, the first one or few bits of the initial byte of the individual sectors of data, termed herein as a flag byte, are used to designate such correspondence. These bits are designated upon writing user data, and all data following the initial bits are transformed on the fly as the streaming data is being transferred to the memory array in accordance with their value. Upon reading a sector of data, these initial bit(s) are read and used to transform back all subsequent data stored in the sector to their original values as the data are being read out of the memory in a stream.
When the memory system is formed of multiple memory cell arrays, such as by using two or more integrated circuit chips that each include such an array, the system's manufacture and use is simplified by accumulating information about each of the memory arrays in the system, and then storing that information as a single record in some convenient location, such as in one of the blocks of one of the memory arrays. This makes it much easier to combine memory arrays having different sizes and/or operating characteristics into a single system. One such record merges the number of blocks of user data available in each of the memory chips in a way that establishes a continuum of logical block addresses of the blocks of all the arrays in the system. When a location of memory is being accessed for a read or write operation, the memory controller then accesses the merged record in a process of converting a logical block address to a physical address of a block in one of the memory arrays.
Such a merged record can be automatically generated and stored during manufacturing by the controller reading the information from each of the memory arrays, merging that information into a single record, and then writing that record into a designated block of one of the memory arrays. Currently, the memory controller is usually provided on a separate integrated circuit chip, with one or more memory cell array chips connected with the controller. It is contemplated, in light of continuing processing technology improvements, that a memory array can also be included on the controller chip. When that amount of memory is insufficient for a particular system, one or more additional circuit chips containing further memory array(s) are then utilized. When two or more physically separate arrays of included in a system, then the generation of the merged record simplifies operation of the controller to address blocks across multiple arrays.
Other characteristics of various memory array circuit chips used to form a system, such as optimal voltage ranges, timing, numbers of pulses used, characteristics of voltage pumps, locations of overhead blocks, and the like, can vary without adverse effects. These operating characteristics can also be tabulated into a single system file for access by the micro-controller, or, more conveniently, the micro-controller can be operated to first access those of such characteristics as are necessary from an individual memory array chip before accessing that chip to read or write data. In either case, this allows the memory system to be formed with memory chips having different characteristics without any degradation in its performance. The manufacturing of non-volatile memory systems is simplified since all the memory array chips in a system need not be the selected to be the same.
Additional aspects, features and advantages of the present invention are included in the following description of specific embodiments, which description should be taken in conjunction with the accompanying drawings.
User data is transferred between the controller 11 and multiple memory arrays 17, 19 and 21, in this example, over the lines 15. The memory arrays are individually addressed by the controller. Specifically, the data bus within the lines 15 can be one byte wide. The memory system shown in
The controller 11 includes a micro-processor or micro-controller 23 connected through controller interface logic 25 to internal memories and interfaces with external components. A program memory 27 stores the firmware and software accessed by the micro-controller 23 to control the memory system operation to read data from the connected memory array(s) and transmit that data to the host, to write data from the host to the memory chip(s), and to carry out numerous other monitoring and controlling functions. The memory 27 can be a volatile re-programmable random-access-memory (RAM), a non-volatile memory that is not re-programmable (ROM), a one-time programmable memory (OTP) or a re-programmable flash EEPROM system. If the memory 27 is re-programmable, the controller can be configured to allow the host system to program it. A random-access-memory (RAM) 29 is used to store, among other data, data from tables read from the non-volatile memory that are accessed during reading and writing operations.
A logic circuit 31 interfaces with the host communication lines 13, while another logic circuit 33 interfaces with the memory array(s) through the lines 15. Another memory 35 is used as a buffer to temporarily store user data being transferred between the host system and non-volatile memory. The memories in the controller are usually volatile, since memories with fast access and other characteristics desired for efficient controller access have that characteristic, and may be combined physically into a single memory. A dedicated circuit 36 accesses the streaming user data being transferred to the memory and inserts dummy bytes into the data stream in order to avoid writing valid user data to memory cells in bad columns. A dedicated processing circuit 37 also accesses the streaming user data being transferred between the controller and flash interfaces 25 and 33 for generating an ECC, or other type of redundancy code, based upon the user data. When user data is being transferred into the non-volatile memory, the generated ECC is appended onto the user data and simultaneously written into the same physical block of the non-volatile memory as part of the same sector as the user data. The circuits 36 and 37 are described further below, with respect to
The non-volatile memory chip 17 includes a logic circuit 39 for interfacing with the controller through the lines 15. Additional components of the memory chip are not shown for simplicity in explanation. The purpose of the logic circuit 39 is to generate signals in separate buses and control lines. Various control signals are provided in lines 41 and a power supply 43 to the memory array circuits is also controlled through the interface 39. A data bus 45 carries user data being programmed into or read from the non-volatile memory, and an address bus 47 carries the addresses of the portion of the memory being accessed for reading user data, writing user data or erasing blocks of memory cells.
The floating gate memory cell array of a single non-volatile memory chip is itself divided into a number of units that each have its own set of supporting circuits for addressing, decoding, reading and the like. In this example, eight such array units 0–7, denoted by reference numbers 51–58, are illustrated. Physically, as an example, the memory array on a single chip is divided into quadrants, each quadrant including two units that are in part connected together and share a common word line decoding circuit (y-decode), such as a y-decoder 61 between memory cell units 4 (55) and 5 (56). This memory architecture is similar to that described in aforementioned U.S. Pat. No. 5,890,192, except there are eight units instead of the four units (quads) illustrated in that patent.
Each of the array units has a bit line decoder (x-decode), such as x-decoder 63 connected to the array unit 5 (56), through which user data is read.
Referring specifically to
A block of cells is formed, in the array example being described, from each pair of rows that surround an erase gate, such as the rows 70 and 76 of the array unit 5 (
If, rather than storing two bits of data per floating gate, only one bit is stored per floating gate, twice the number of cells are needed for each operable block. This can be accomplished, in effect, by doubling the length of each row in a manner illustrated in
As an alternative to the two state configuration shown in
Data is preferably transferred in chunks between the controller buffer memory 35 (
Rather than transferring a chunk of user data in parallel between the buffer memory 35 and one of the memory arrays, a data bus within the lines 15 is designed to carry only a few bits data in parallel, one byte in a specific example. This reduces the number of lines 15 that are necessary and, more importantly, reduces the number of user data pads that need to be included on each of the memory array chips in the system. With one byte being transferred at a time, there thus needs to be 66 such transfers for a each chunk. These byte wide user data transfers extend between the buffer memory 35 and, through interface circuits 33 and 39, the memory cell array master register 69, if a block within the array unit 5 is being addressed, or another of the array master registers associated with another unit if a block within that other unit is being addressed.
During programming, bytes of a sector of user data received from the host system are successively transferred into the memory array master register one at a time until a chunk of data has been accumulated, and then the chunk is transferred in parallel to the slave register (such as register 67 for the array unit 5). As the chunk is being transferred out of the master register and into the slave register, bytes of the next chunk of the sector are being transferred into the master register. Chunks are transferred in parallel, one at a time from the slave register, to programming and verifying circuits (circuit 65 for the array unit 5), which causes the a number of memory cells of an addressed block of the associated array unit to be programmed to their respective target threshold levels. The loading of one chunk into the master register preferably overlaps programming of the previous chunk of data from the slave register by the programming and verifying circuits.
During reading, the process is reversed, memory cell threshold values representative of a chunk of data being read one at a time from one of the array units into its reading circuit (circuit 65 for the array unit 5) where the stored values are converted into data bits. Those successive chunks of data are then transferred one at a time into the slave register for the array unit, thereafter in parallel to the master register, and then one byte at a time over the lines 15 to the data buffer 35 of the controller for transfer to the host system. As a chunk is being transferred out of the master register and to the controller, a new chunk of data is being transferred into the slave register from the read circuits.
Rather than completing the transfer of chunks of data of one sector before commencing another, it is preferred to alternately transfer chunks of multiple sectors between the buffer memory 35 and different ones of the array units 0–7. This is illustrated in
As illustrated in
This programming technique has an advantage that multiple chunks of user data may be simultaneously programmed into different units of the memory on a single chip, or, alternatively, into different units spread among two or more memory chips. This is preferred to the simultaneous programming of multiple sectors of data into a common block of one unit since the cells being programmed are, by the technique of
The technique of
The stream of user data bytes at the output of the multiplexer 121 is applied as one input to a multiplexer 125. The multiplexer 125 normally passes that data stream from lines 114 through its output to one input of another multiplexer 112 An exception is when all the user data bytes of a sector have been passed out of the buffer 35, at which time a final series of bytes containing an ECC code for the sector of user data is added onto the end of user data through lines 116. The output of the multiplexer 125 provides the byte wide stream of user data and overhead information of the data for writing into physical blocks of the non-volatile memory.
That stream of user data is normally passed, one byte at a time, through the multiplexer 112 to the flash memory. An exception to this is when a BCP hit signal in line 108 is active, indicating that the byte of user data is being directed to a location of the flash memory that includes a bad column. In that case, the address applied to the buffer 35 is not incremented by the micro-controller 23 but rather a fill byte contained in a register 110 is inserted into the data stream instead of the usual byte of user data. The next byte of user data from the buffer 35 is delayed until the next transfer cycle when the BCP hit signal is inactive. The bits of the fill byte within the register 110 can be written by the micro-controller 23. The output of the multiplexer 112 provides the byte wide stream of user data and overhead information of the data that is written into physical blocks of the non-volatile memory, as well as possible fill bytes to avoid the effects of bad columns. The memory system being described can operate without the circuit of
Referring to
In order to pause the ECC generator 127 when fill bytes are being inserted into the data stream by the BCP processing, the generator 127 is disabled by a combination of the BCP hit signal in the line 108 being active and a signal in the line 116 indicating that the data at the output of the muliplexer 121 is valid. A logic circuit 138 combines the signals 108 and 116 in order to generate a disable signal for the ECC generator 127.
After the ECC generator has received the last byte of data of a sector being stored, the final result is inserted in the last chunk of the data stream by operating the multiplexer 125, in response to a control signal in a line 129, to switch from receiving the input from the multiplexer 121 to receiving the result from the ECC generation circuit 127. The ECC is then stored in the same block of the memory array as the sector of user data from which it was generated. At the end of generating and inserting ECCs into the data stream for each of a group of four sectors of data, the registers 133–136 are reset by a signal in a line 141.
Referring to
A second input of the comparitor 132 is formed from the contents of registers 128 and 130. These registers contain the current physical memory location for storage of the chunk and byte, respectively, to which the byte of data at the output of the multiplexer 121 is destined for storage within the flash memory. These registers are loaded by the micro-controller 23. Their combined physical memory byte address is then compared by the comparitor 132 with that of one of the BCPs from the registers 118 of the destination memory unit for that data byte. When the first byte of user data for a given unit is present at the output of the multiplexer 121, its physical memory address from registers 128 and 130 is compared with BCP0 of the one of the registers 118 for that unit. If there is a positive comparison, then the BCP hit signal in line 108 becomes active. This results in the current byte of user data of ECC to be held and the fill byte from the register 110 inserted instead. The fill byte will then be written to the byte of memory cells including the bad column, instead of the current data byte.
The BCP hit signal also causes the count in the one of the registers 122 for that unit to switch the multiplexer 120 to select the next BCP1 for that memory unit. The BCP processor is then ready for this process to again take place when the physical memory byte location matches that of the next in order BCP for that unit. A stalled data byte is written during the next cycle, assuming this next physical address comparison does not result in another BCP hit, in which case the data byte is stalled yet another cycle. This process continues until the data stream formed of the current four sectors of data has been transferred to the flash memory, after which the process is repeated for different memory locations stored in the registers 128 and 130 in which the new sectors of data are to be written, and possibly changing the BCPs stored in one or more of the planes of registers 118 if the new data is to be written into one or more different memory units than before.
Referring again to
The BCP processing and ECC generation circuits of
Referring to
It will be noted that the overhead information that is stored in a block along with a sector of data is limited to information about the data itself and does not include physical overhead information about the block or its operation. Prior memory systems, particularly those which emulate a disk drive by storing 512 byte sectors of user data, have also stored, in the individual user data blocks, information about the block's characteristics in terms of experience cycles, numbers of pulses or voltages required to program or erase the block of cells, defects within the block, and like information about the storage media, in addition to an ECC generated from the data stored in the block. As part of the present invention, however, this type of information about the physical block is stored in another block. As a specific example, individual block overhead records containing such information of a large number of blocks are stored in other memory blocks dedicated to such overhead information and which do not contain user data. Such information of the memory array that affects a number of blocks, such as the identification of bad columns, is stored in yet other memory blocks in order to minimize the memory space that is required for such information. In either case, the overhead information for a given block is read from these other blocks as part of the process of accessing the given block to either read data from it or program data into it. The block overhead information is usually read by the controller prior to accessing the block to read or write user data.
This arrangement of blocks thus requires that a number of spare blocks be provided in addition to the number of user data blocks necessary to fill the address space specified for the memory array. The overhead records for these blocks designate their status as spares in the flag byte, and whether they are good or defective spare blocks. If a good spare block, the record contains the same bytes 1–3 as the record of
Any defects of the memory cell array that affect many blocks of cells, such as defective columns as can occur when a bit line has a short circuit to some other element, are stored in other blocks in order to compact the block overhead records. An example shown in
During operation of the memory, the BCP table of
The controller 11 may access a number of user data sectors in response to receipt from a host system of a command containing an address, such as a in a cylinder/head/sector format, as in a disk drive, or as a logical block. The controller then calculates a logical address of a beginning block corresponding to the beginning sector address provided by the host. The memory system address space for a given array chip may be expressed as a continuum of logical block addresses (LBAs) that represent all available blocks on the chip in its good memory units for storing user data. The block overhead records are logically arranged in that same order. The controller then first reads the block overhead record in its RAM 29 that corresponds to the first data sector specified by the host while a physical address within the memory array of the user data block is being calculated from its LBA. After accessing the first user data block and its overhead information, the logical block address need not be recalculated for each subsequent block that is addressed for data of the particular file. A simple counter will step through the overhead records that have been organized in the order of their respective user data blocks. If all of the necessary overhead records are not in the controller's RAM 29 at the time of this access, the required overhead data sectors are preferably first read from the non-volatile memory into the RAM 29, including those of substitute blocks whose addresses are contained in the initial overhead records.
One advantage of storing the block overhead data in records separate from the block is the reduced number of times that such records must be rewritten. In the present embodiment, the overhead blocks of data need not be rewritten frequently, perhaps only two or three times during the lifetime of the memory system and some times not at all. Any change to the overhead information record for one block is held as long as possible in a controller memory before rewriting the overhead data sector in which record exists, and then it can be done in the background without being part of an erase or programming cycle. But when the overhead data of a block is stored in that block, the overhead data must be reprogrammed each time the block is erased. In the examples described herein where only one sector of user data is stored in a block, overhead data would have to be rewritten in one block every time a sector of user data is written into that memory block. This can also require the overhead information to be written twice into the same block, once before writing the user data and once after doing so, in order to compensate for effects due to programming adjacent cells, particularly when being programmed in multiple states where the tolerance of such effects is less.
Although the memory system examples being described store only one sector of user data in each of the individual blocks, various aspects of the present invention apply equally well where two or more sectors of data, each with its flag and ECC bytes, are stored in individual blocks of the memory cell array.
Part of the boot information is a physical address of reserved block 0 and its copy, which, in a specific example, contains the bad column pointers of
The other reserved sectors contain information that is useful to the controller to operate the memory array chip on which they are located, or useful to the entire memory system. Reserved block 1, for example, can contain data of system parameters that appears on only the first logical memory array chip of the system, including a specification of the data interface 13 of the controller with the host system. Another reserved block may contain manufacturing information, for example. The data stored in the boot information and reserved blocks are written as part of the manufacturing process. This data may be made modifiable after manufacture, either in part or in total.
In a specific example, the entry in the table of
In addition to storing a record of the number of good units and sectors from which the merged table of
These characteristics that can be different among memory chips include various optimal voltages and timing, as well as minimum and maximum permitted values, for use to program, read, erase, scrub and refresh the chip. The optimal number of programming pulses, their durations, frequency and magnitudes, as well as operating characteristics of voltage pumps on the chip, including ranges of maximum and minimum values can also be included. The number of sectors per unit and other information needed by the controller to translate a logical block address to a physical one within the particular chip are also stored. Pointers to spare units and blocks within units may also be included. Other information includes pointers to the physical locations of the reserved sectors so that they need not all be stored in the same blocks in each memory chip of a system. The number of user data blocks for which data is included in each of the overhead blocks (
The flag byte 145 (
An inverse transform takes place when the sector of data is read from the flash memory, as illustrated in
The least significant bits 4–7 of the flag byte 145 illustrated in
Although specific examples of various aspects of the present invention have been described, it is understood that the present invention is entitled to protection within the scope of the appended claims.
This application is a continuation of application Ser. No. 10/841,406, filed May 6, 2004, now U.S. Pat. No. 6,996,008 issued on Feb. 7, 2006, which is a continuation of application Ser. No. 10/422,216, filed Apr. 23, 2003, now U.S. Pat. No. 6,760,255, issued on Jul. 6, 2004, which is a continuation of application Ser. No. 10/176,880, filed Jun. 21, 2002, now U.S. Pat. No. 6,580,638, issued on Jun. 17, 2003, which is a continuation of Ser. No. 09/505,555, filed Feb. 17, 2000, now U.S. Pat. No. 6,426,893, issued on Jul. 30, 2002, which applications are incorporated herein in their entirety by this reference.
Number | Name | Date | Kind |
---|---|---|---|
3633175 | Harper et al. | Jan 1972 | A |
4051460 | Yamada et al. | Sep 1977 | A |
4250570 | Tsang et al. | Feb 1981 | A |
4281398 | McKenny et al. | Jul 1981 | A |
4287570 | Stark | Sep 1981 | A |
4398248 | Hsia et al. | Aug 1983 | A |
4450559 | Bond et al. | May 1984 | A |
4498146 | Martinez | Feb 1985 | A |
4525839 | Nozawa et al. | Jun 1985 | A |
4616311 | Sato | Oct 1986 | A |
4654847 | Dutton | Mar 1987 | A |
4746998 | Robinson et al. | May 1988 | A |
4748320 | Yorimoto et al. | May 1988 | A |
4757474 | Fukushi et al. | Jul 1988 | A |
4774700 | Satoh et al. | Sep 1988 | A |
4780855 | Iida et al. | Oct 1988 | A |
4800520 | Iijima | Jan 1989 | A |
4829169 | Watanabe | May 1989 | A |
4896262 | Wayama et al. | Jan 1990 | A |
4914529 | Bonke | Apr 1990 | A |
4945535 | Hosotani et al. | Jul 1990 | A |
5172338 | Mehrotra et al. | Dec 1992 | A |
5200959 | Gross et al. | Apr 1993 | A |
5218691 | Tuma et al. | Jun 1993 | A |
5270979 | Harari et al. | Dec 1993 | A |
5303198 | Adachi et al. | Apr 1994 | A |
5315541 | Harari et al. | May 1994 | A |
5337275 | Garner | Aug 1994 | A |
5341339 | Wells | Aug 1994 | A |
5353256 | Fandrich et al. | Oct 1994 | A |
5357475 | Hasbun et al. | Oct 1994 | A |
5388083 | Assar et al. | Feb 1995 | A |
5404485 | Ban | Apr 1995 | A |
5428621 | Mehrotra et al. | Jun 1995 | A |
5430859 | Norman et al. | Jul 1995 | A |
5457658 | Niijima et al. | Oct 1995 | A |
5471478 | Mangan et al. | Nov 1995 | A |
5479638 | Assar et al. | Dec 1995 | A |
5485595 | Assar et al. | Jan 1996 | A |
5504760 | Harari et al. | Apr 1996 | A |
5524230 | Sakaue et al. | Jun 1996 | A |
5532962 | Auclair et al. | Jul 1996 | A |
5535328 | Harari et al. | Jul 1996 | A |
5544119 | Wells et al. | Aug 1996 | A |
5544356 | Robinson et al. | Aug 1996 | A |
5559956 | Sukegawa | Sep 1996 | A |
5566314 | DeMarco et al. | Oct 1996 | A |
5602987 | Harari et al. | Feb 1997 | A |
5603001 | Sukegawa et al. | Feb 1997 | A |
5652720 | Aulas et al. | Jul 1997 | A |
5663901 | Wallace et al. | Sep 1997 | A |
5673383 | Sukegawa | Sep 1997 | A |
5677872 | Samachisa et al. | Oct 1997 | A |
5712179 | Yuan | Jan 1998 | A |
5712180 | Guterman et al. | Jan 1998 | A |
5787484 | Norman | Jul 1998 | A |
5798968 | Lee et al. | Aug 1998 | A |
5835413 | Hurter et al. | Nov 1998 | A |
5835935 | Estakhri et al. | Nov 1998 | A |
5838614 | Estakhri et al. | Nov 1998 | A |
5862080 | Harari et al. | Jan 1999 | A |
5890192 | Lee et al. | Mar 1999 | A |
5907856 | Estakhri et al. | May 1999 | A |
5909449 | So et al. | Jun 1999 | A |
5924113 | Estakhri et al. | Jul 1999 | A |
5928370 | Asnaashari | Jul 1999 | A |
5930167 | Lee et al. | Jul 1999 | A |
5930815 | Estakhri et al. | Jul 1999 | A |
5946714 | Miyaunchi | Aug 1999 | A |
5953737 | Estakhri et al. | Sep 1999 | A |
5963970 | Davis | Oct 1999 | A |
5999446 | Harari et al. | Dec 1999 | A |
6014755 | Wells et al. | Jan 2000 | A |
6034897 | Estakhri et al. | Mar 2000 | A |
6040997 | Estakhri | Mar 2000 | A |
6041001 | Estakhri | Mar 2000 | A |
6076137 | Asnaashari | Jun 2000 | A |
6081878 | Estakhri et al. | Jun 2000 | A |
6115785 | Estakhri et al. | Sep 2000 | A |
6122195 | Estakhri et al. | Sep 2000 | A |
6125435 | Estakhri et al. | Sep 2000 | A |
6130836 | Matsubara et al. | Oct 2000 | A |
6141249 | Estakhri et al. | Oct 2000 | A |
6151247 | Estakhri et al. | Nov 2000 | A |
6202138 | Estakhri et al. | Mar 2001 | B1 |
6223308 | Estakhri et al. | Apr 2001 | B1 |
6282624 | Kimura et al. | Aug 2001 | B1 |
6345001 | Mokhlesi | Feb 2002 | B1 |
6426893 | Conley et al. | Jul 2002 | B1 |
6580638 | Conley et al. | Jun 2003 | B2 |
6684289 | Gonzalez et al. | Jan 2004 | B1 |
6760255 | Conley et al. | Jul 2004 | B2 |
6763480 | Harari et al. | Jul 2004 | B2 |
20010004326 | Terasaki | Jun 2001 | A1 |
20050144357 | Sinclair | Jun 2005 | A1 |
Number | Date | Country |
---|---|---|
0 557 723 | Jun 1984 | AU |
3812147 | Nov 1988 | DE |
0220718 | May 1987 | EP |
0548564 | Nov 1992 | EP |
0686976 | Dec 1995 | EP |
59-45694 | Mar 1984 | JP |
59-45695 | Mar 1984 | JP |
60-076097 | Apr 1985 | JP |
62-283496 | Dec 1987 | JP |
62-283497 | Dec 1987 | JP |
64-70843 | Mar 1989 | JP |
WO 9944113 | Sep 1999 | WO |
WO 0030116 | May 2000 | WO |
WO0219334 | Mar 2002 | WO |
Number | Date | Country | |
---|---|---|---|
20060109712 A1 | May 2006 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10841406 | May 2004 | US |
Child | 11323576 | US | |
Parent | 10422216 | Apr 2003 | US |
Child | 10841406 | US | |
Parent | 10176880 | Jun 2002 | US |
Child | 10422216 | US | |
Parent | 09505555 | Feb 2000 | US |
Child | 10176880 | US |