This application is a reissue application of U.S. Ser. No. 09/285,706 filed on Apr. 5, 1999, now U.S. Pat. No. 6,148,354 issued on Nov. 14, 2000. More than one reissue application has been filed for the reissue of U.S. Pat. No. 6,148,354. The reissue applications are application Ser. Nos. 10/292,868 (the present application), and 10/293,986 which is a continuation of the present application.
The present invention is related to semiconductor memory devices, and in particular to erasable and programmable nonvolatile memory modules which are connected to a host platform using the USB PC Bus.
Erasable and programmable non-volatile memory modules, hereinafter referred to as flash memory or flash devices, are known in the art for storage of information. Flash devices include electrically erasable and programmable read-only memories (EEPROMs) made of flash-type, floating-gate transistors and are non-volatile memories similar in functionality and performance to EPROM memories, with an additional functionality that allows an in-circuit, programmable, operation to erase pages of the memory. One example of an implementation of such a flash device is given in U.S. Pat. No. 5,799,168, incorporated by reference as if fully set forth herein.
Flash devices have the advantage of being relatively inexpensive and requiring relatively little power as compared to traditional magnetic storage disks. However, in a flash device, it is not practical to rewrite a previously written area of the memory without a preceding page erase of the area. This limitation of flash devices causes them to be incompatible with typical existing operating system programs, since data cannot be written to an area of memory within the flash device in which data has previously. been written, unless the area is first erased. A software management system, such as that disclosed in U.S. Pat. No. 5,404,485, filed on Mar. 5, 1993, which is incorporated as if fully set forth herein, is required to manage these functions of the flash memory device.
Currently, these flash memory devices have a second limitation, which is that they must be either attached statically to the host platform, or attached and detached dynamically using the PCMCIA [Personal Computer Memory Card International Association] interface. Both implementations have drawbacks, including difficulty of use and high cost.
A more useful implementation would follow the USB standard, as described in the USB Specification Version 1.1 which is incorporated as if fully set forth herein. The USB standard offers a smaller form factor and greater ease of use for the end user, while lowering the cost of the implementation. This standard is specified to be an industry-wide standard promoted by companies such as Compaq Computer Corporation, Microsoft, IBM and Intel to serve as an extension to the PC architecture with a focus on Computer Telephony Integration (CTI), the consumer, and productivity applications.
The criteria which were applied to define the architecture for the USB standard include the ease of PC (personal computer) peripheral expansion, low cost, support of transfer rates up to 12 Mb/second and full support for real-time data, voice, audio, and compressed video. This standard also offers protocol flexibility for mixed-mode isochronous data transfers and asynchronous messaging, integration in commodity device technology and provision of a standard interface for rapid integration into any given host product. In addition, the USB standard represents a single model for cabling and attaching connectors, such that all of the details of the electrical functions, including bus terminations, are isolated from the end user. Through the standard, the peripheral devices are self-identifying, and support automatic mapping of functions to a driver. Furthermore, the standard enables all peripheral devices to be dynamically attachable and re-configurable.
A system constructed according to the USB standard is described by three separate, defined areas: USB interconnection, USB devices and the USB host platform. The USB interconnection is the manner in which USB devices are connected to, and communicate with, the host platform. The associated functions and components include the bus topology, which is the connection model between USB devices and the host platform.
The USB physical interconnection has a tiered star topology. A hub is at the center of each star. Each wire segment is a point-to-point connection between the host platform and a hub or function, or a hub connected to another hub or function.
In terms of a capability stack, the USB tasks which are performed at each layer in the system include a data flow model and a schedule. A data flow model is the manner in which data moves in the system over the USB between data producers and data consumers. A schedule determines access to the interconnection, which is shared. Such scheduling enables isochronous data transfers to be supported and eliminates arbitration overhead.
The USB itself is a polled bus. The host controller on the host platform initiates all data transfers. All bus transactions involve the transmission of up to three packets. Each transaction begins when the host controller, on a scheduled basis, sends a USB packet describing the type and direction of transaction, the USB device address, and endpoint number. This packet is referred to as the “token packet.” The USB device, to which the packet is addressed, selects itself by decoding the appropriate address fields. In a given transaction, data is transferred either from the host platform to a device or from a device to the host platform. The direction of data transfer is specified in the token packet. The source of the transaction then sends a data packet or indicates that the source has no data to transfer. The destination, in general, responds with a handshake packet indicating whether the transfer was successful.
The USB data transfer model between a source and destination on the host platform and an endpoint on a device is referred to as a “pipe”. There are two types of pipes: stream and message. Stream data has no USB-defined structure, while message data does. Additionally, pipes have associations of data bandwidth, transfer service type, and endpoint characteristics like directionality and buffer sizes. Most pipes come into existence when a USB device is configured. One message pipe, the default control pipe, always exists once a device is powered, in order to provide access to the configuration, status, and control information for the device.
The transaction schedule for the USB standard permits flow control for some stream pipes. At the hardware level, this prevents situations in which buffers experience underrun or overrun, by using a NAK handshake to throttle the data rate. With the NAK handshake, a transaction is retried when bus time is available. The flow control mechanism permits the construction of flexible schedules which accommodate concurrent servicing of a heterogeneous mix of stream pipes. Thus, multiple stream pipes can be serviced at different intervals with packets of different sizes.
The USB standard, as described, has three main types of packets, including token packets, data packets and handshake packets. An example of each type of packet is shown in background art
A token packet 10, as shown in background art
An ADDR field 14 specifies the address, while an ENDP field 16 specifies the endpoint for token packet 10. For OUT and SETUP transactions, in which PID field 12 specifies that token packet 10 is an OUT packet type or a SETUP packet type, ADDR field 14 and ENDP field 16 uniquely identify the endpoint for receiving the subsequent data packet, shown in
As shown in background art
Background art
These three different types of packets are exchanged during various phases of the transaction which includes a USB device. A schematic block diagram of the functional blocks in a typical USB device 32 is shown in
The USB specification does not define the relationship between different entities in USB abstract device 32, however. Rather, the USB specification describes only the requirements for the packets, and for the electrical and physical connection between USB abstract device 32 and the bus. Therefore the connections and relationships shown in background art
Unfortunately, no such architecture exists for a flash memory device containing one or more flash memory modules, which would enable the flash memory device to connect to a bus defined according to the USB specification and thereby to form part of a USB system on a host platform. For example, U.S. Pat. No. 5,799,168 does not teach or suggest such an implementation for the flash device. As mentioned previously, such an architecture would be particularly useful for a number of reasons, including low cost, ease of use and transparency to the end user.
There is thus a need for, and it would be useful to have, an architecture for defining and describing a flash memory device which is compatible with a USB system and which follows the USB specification, such that the flash memory device could sit on a USB-defined bus and communicate with the host platform through this bus.
The present invention is of a flash memory device, containing one or more flash modules, in which the flash memory is mapped to the address space of an ASIC or a controller which has a USB-defined electrical interface and a USB-defined logical interface. This controller/ASIC (hereinafter termed a “controller”) supports the USB functionality according to the USB standard, thereby supporting enumeration onto the USB bus, as well as data reception and transmission over USB pipes to and from USB endpoints. This controller also supports the functionality and control of the flash memory device, as well as the processing of command and data packets from the host controller. The host controller uses one of several possible protocols, either standard or proprietary, to signal the next command to be performed to the USB flash controller. Thus, the entire device acts as a dynamically attachable/detachable non-volatile storage device for the host platform.
According to the present invention, there is provided a USB flash memory device for connecting to a USB-defined bus, the flash memory device comprising: (a) at least one flash memory module for storing data; (b) a USB connector for connecting to the USB-defined bus and for sending packets on, and for receiving packets from, the USB-defined bus; and (c) a USB controller for controlling the at least one flash memory module and for controlling the USB connector according to at least one packet received from the USB-defined bus, such that data is written to and read from the at least one flash memory module.
Hereinafter, the term “computer” includes, but is not limited to, personal computers (PC) having an operating system such as DOS, Windows™, OS/2™ or Linux; Macintosh™ computers; computers having JAVA™-OS as the operating system; and graphical workstations such as the computers of Sun Microsystems™ and Silicon Graphics™, and other computers having some version of the UNIX operating system such as AIX™ or SOLARIS™ of Sun Microsystems™; or any other known and available operating system, including operating systems such as Windows CE™ for embedded systems, including cellular telephones, handheld computational devices and palmtop computational devices, and any other computational device which can be connected to a network. Hereinafter, the term “Windows™” includes but is not limited to Windows95™, Windows 3.X™ in which “x” is an integer such as “1”, Windows NT™, Windows98™, Windows CE™ and any upgraded versions of these operating systems by Microsoft Inc. (Seattle, Wash., USA).
The present invention is of a flash memory device, containing one or more flash modules, in which the flash memory is mapped to the address space of an ASIC or a controller which has a USB-defined electrical interface and a USB-defined logical interface. This controller/ASIC (hereinafter termed a “controller”) supports the USB functionality according to the USB standard, thereby supporting enumeration onto the USB bus, as well as data reception and transmission over USB pipes to and from USB endpoints. This controller also supports the functionality and control of the flash memory device, as well as the processing of command and data packets from the host controller. The host controller uses one of several possible protocols, either standard or proprietary, to signal the next command to be performed to the USB flash controller. Thus, the entire device acts as a dynamically attachable/detachable non-volatile storage device for the host platform.
While the invention is susceptible to various modifications and can be implemented using many alternative forms, the embodiment is shown by way of example in the drawings and will be described in details in the following pages. It should be understood that one of ordinary skill in the art appreciates that the present invention could be implemented in various other ways. The intention is to cover all modifications and alternatives falling within the spirit of the current invention.
The principles and operation of a USB flash device and system according to the present invention may be better understood with reference to the drawings and the accompanying description, it being understood that these drawings are given for illustrative purposes only and are not meant to be limiting.
Referring now to the drawings,
Host platform 44 is connected to USB flash device 46 according to the present invention through a USB cable 48. Host platform 44 connects to USB cable 48 through a USB host connector 50, while USB flash device 46 connects to USB cable 48 through a USB flash device connector 52. Host platform 44 features a USB host controller 54 for controlling and managing all USB transfers on the USB bus.
USB flash device 46 features a USB flash device controller 56 for controlling the other components of USB flash device 46 and for providing an interface for USB flash device 46 to the USB bus, USB flash device connector 52 and at least one flash memory module 58. Flash memory module 58 is preferably an array of flash memory modules 58 in which the data is stored.
Whenever USB flash device 46 becomes connected to host platform 44, a standard USB enumeration process takes place. In this process host platform 44 configures USB flash device 46 and the mode of communication with USB flash device 46. Although there are many different methods for configuring USB flash device 46, for the purposes of clarity only and without intending to be limiting, the present invention is explained in greater detail below with regard to a method in which host platform 44 issues commands and requests to USB flash device 46 through one endpoint. Host platform 44 queries USB flash device 46 through the other endpoint for status changes, and receives related packets if any such packets are waiting to be received.
Host platform 44 requests services from USB flash device 46 by sending request packets to USB host controller 54. USB host controller 54 transmits packets on USB cable 48. These requests are received by USB flash device controller 56 when USB flash device 46 is the device on the endpoint of the request. USB flash device controller 56 then performs various operations such as reading, writing or erasing data from or to flash memory module(s) 58, or supporting basic USB functionality such as device enumeration and configuration. USB flash device controller 56 controls flash memory module(s) 58 by using a control line 60 to control the power of flash memory module(s) 58, and also through various other signals such as chip enable, and read and write signals for example. Flash memory module(s) 58 are also connected to USB flash device controller 56 by an address/data bus 62. Address/data bus 62 transfers commands for performing read, write or erase commands on flash memory module(s) 58, as well as the addresses and data for these commands as defined by the manufacturer of flash memory module(s) 58.
In order for USB flash device 46 to notify host platform 44 on the result and status for different operations requested by host platform 44, USB flash device 46 transmits status packets using the “status end point”. According to this procedure, host platform 44 checks (polls) for status packets and USB flash device 46 returns either an empty packet if no packets for new status messages are present, or alternatively returns the status packet itself.
A more detailed structure of the functional components of USB flash device 46 is shown in
Connector interface 64 then receives these packets through a first interface component, which is a combined physical and logical interface 66. A functional interface 68 is specifically designed to receive token packets as defined in the USB specification and as previously described with regard to
USB flash device 46 also features an application packet extractor 70 which extracts the application data and commands from the USB application packets, such that application packet extractor 70 supports only application related packets. Next, any requests to USB flash device 46 by host platform 44 (not shown), in the form of read, write, identify and erase commands, are interpreted by an application command interpreter 72. For any commands which involve data or an address, such as read, write and erase commands, an address resolve module 74 translates the address from the logical address space to the physical address space. Host platform 44 (not shown) relates to a linear address space of logical addresses, while USB flash device 46 contains at least one, and preferably a plurality of, flash modules 58, each of which has a physical address space. Thus, a translation must be performed between the logical address space of host platform 44 (not shown) and physical address space or spaces of USB flash device 46. There are many ways to implement such a translation which are suitable for the present invention. One example of a suitable implementation of an address translation method is described with regard to U.S. Pat. No. 5,404,485, previously incorporated by reference as if fully set forth herein, which teaches a method for managing a flash memory as a flash disk and which is suitable for operation with the present invention.
A data handler 76 handles data related aspects of any received commands, and conveying the data through functional interface 68 to and from flash module(s) 58. Optionally and preferably, data handler 76 performs any error correction and detection methods. Application command interpreter 72, data handler 76 and address resolve module 74 all operate with an underlying Memory Technology Driver (MTD) 78 to write, read or erase a particular flash module 58 and the desired address on that flash module 58.
Host platform 44 checks for status changes in USB flash device 46 and reads status packets from USB flash device 46 when a new status packet is available. Using these status packets, USB flash device 46 can transmit, to host platform 44, the results of different commands issued by host platform 44 in its requests (not shown). For example, the read command status packet contains one of the available status words such as “success”, “error” or “invalid address”, which enables host-platform 44 to determine the result of the read command (not shown). Similarly, the erase status packet contains a status word indicating the completion of the erase process. A write status packet is used by USB flash device 46 to notify host platform 44 about the result of the write command, for example whether the command was successful or erroneous, and whether USB flash device 46 is ready for additional write requests from host platform 44.
A Memory Technology Driver, or MTD 78 typically contains routines to read, write and erase the flash memory device controlled by the controller operating MTD 78. In addition, MTD 78 optionally contains an identification routine for recognizing the proper type of flash memory device for which MTD 78 was designed, so that the controller can determine which MTD should be activated upon interacting with a particular flash memory device array. In addition, an identification routine should be able to detect the size of the array of flash memory devices, including the number of flash memory devices within the array, and various features of the flash array geometry, such as interleaving and bus width. This information later enables host platform 44 platform to determine the address space and size of the storage media. U.S. Pat. No. 5,799,168, previously incorporated by reference, discloses an example of such an MTD for a flash device.
Using the above described protocol and architecture, host platform 44 can optionally implement any application which is implementable with any regular memory mapped or I/O mapped flash memory device. For example, host platform 44 can give a standard block device interface to each application, such as a magnetic storage medium “hard disk” drive, as disclosed in the previously described U.S. Pat. No. 5,404,485.
As an example of a preferred embodiment of the present invention, the operation of a host system connected to a USB flash device according to the present invention is described with regard to the processes of identifying, programming, reading and erasing the flash device. For the purposes of illustration only and without intending to be limiting in any way, the exemplary USB flash device has an array of two flash memory modules, each of which is 64 Mbit in size. The address translation table is within the flash device so that host platform operates with logical addresses. All commands and return codes between the flash device and the host platform are carried on USB data packets, and are transferred through USB data pipes. The exact structure of the packets, pipes and timings are described in the USB specification.
The operation of the exemplary device and system according to the present invention is as follows. When the USB flash device is first connected to the host platform, the USB host controller assigns an address to the USB flash device on the USB bus, and also assigns resources as described in the USB specification. The USB flash device actually asks the host platform to assign these resources, and must inform the host platform how much of these resources are needed. Thus, the USB flash disk can optionally support slower device speeds if the USB host platform has already allocated resources to other devices.
The USB controller also negotiates with the flash modules and determines the size and manufacturing type of these modules. The controller then builds an identification structure holding this information, as well as the translation table and logical address space.
After the USB host controller identifies the USB flash device, the host platform often uploads a USB client driver. The driver issues an identification request command to the USB host controller, causing the controller to transmit an identification data packet 80, shown in
In response to the “identify” command, the flash device then sends an identification data packet 84, shown in
All of the packets described in this example are only data packets which are sent on the USB bus. Before each data packet is sent, a USB token packet is transmitted, instructing the USB controller as to the identity of the device end point to which the data packet should be transmitted. Upon successful reception of the packet, the USB controller issues a USB ACK packet as described in the USB specification.
Once the device drivers in the host platform receive this status packet, the drivers can start issuing read and write commands to the USB flash device with the application commands. When a write request is sent, a USB data packet with the operation code for the “write” command, and the buffer containing the data, is transferred to the USB flash device. A write data packet 90 is shown in
When the flash controller finishes the writing process, the controller signals to the host platform that the status of the USB flash memory device has changed, by sending a “write status” packet 100, as shown in
As shown in
When the flash controller receives the data from the flash device, either after the read command was issued, or if an error occurred, the flash controller sends a signal to the host platform to indicate that a new status packet must be read. The host platform issues a read request and receives a “read status” packet 110 as shown in
When the host platform needs to erase an erase unit in the flash device, the host platform issues an “erase request” packet 118, shown in
The erase process generally takes more time then a read or write process. When this erase process is finished, the controller notifies the host platform a new status packet is ready to transmit. The controller then transmits an “erase status” packet 124, as shown in
It will be appreciated that the above descriptions are intended only to serve as examples, and that many other embodiments are possible within the spirit and the scope of the present invention.
Number | Name | Date | Kind |
---|---|---|---|
4203001 | Condon | May 1980 | A |
4958342 | Williams et al. | Sep 1990 | A |
4979167 | McCool | Dec 1990 | A |
5067105 | Borkenhagen et al. | Nov 1991 | A |
5226168 | Kobayashi et al. | Jul 1993 | A |
5291584 | Challa et al. | Mar 1994 | A |
5297148 | Harari et al. | Mar 1994 | A |
5341330 | Wells et al. | Aug 1994 | A |
5375243 | Parzych et al. | Dec 1994 | A |
5388083 | Assar et al. | Feb 1995 | A |
5404485 | Ban | Apr 1995 | A |
5412798 | Garney | May 1995 | A |
5420412 | Kowalski | May 1995 | A |
5437031 | Kitami | Jul 1995 | A |
5459850 | Clay et al. | Oct 1995 | A |
5485519 | Weiss | Jan 1996 | A |
5491774 | Norris et al. | Feb 1996 | A |
5509134 | Fandrich et al. | Apr 1996 | A |
5519843 | Moran et al. | May 1996 | A |
5524230 | Sakaue et al. | Jun 1996 | A |
5532945 | Robinson | Jul 1996 | A |
5535197 | Cotton | Jul 1996 | A |
5535357 | Moran et al. | Jul 1996 | A |
5544356 | Robinson et al. | Aug 1996 | A |
5546402 | Niijima et al. | Aug 1996 | A |
5568134 | Cannon et al. | Oct 1996 | A |
5581723 | Hasbun et al. | Dec 1996 | A |
5588146 | Leroux | Dec 1996 | A |
5602987 | Harari et al. | Feb 1997 | A |
5630093 | Holzhammer et al. | May 1997 | A |
5659705 | McNutt et al. | Aug 1997 | A |
5661677 | Rondeau, II et al. | Aug 1997 | A |
5663901 | Wallace et al. | Sep 1997 | A |
5684742 | Bublitz et al. | Nov 1997 | A |
5719808 | Harari et al. | Feb 1998 | A |
5724285 | Shinohara | Mar 1998 | A |
5732092 | Shinohara | Mar 1998 | A |
5745418 | Ma et al. | Apr 1998 | A |
5760986 | Morehouse et al. | Jun 1998 | A |
5774744 | Story et al. | Jun 1998 | A |
5778418 | Auclair et al. | Jul 1998 | A |
5781028 | Decuir | Jul 1998 | A |
5784581 | Hannah | Jul 1998 | A |
RE35881 | Barrett et al. | Aug 1998 | E |
5799168 | Ban | Aug 1998 | A |
5815426 | Jigour et al. | Sep 1998 | A |
5822251 | Bruce et al. | Oct 1998 | A |
5841424 | Kikinis | Nov 1998 | A |
5845151 | Story et al. | Dec 1998 | A |
5845313 | Estakhri et al. | Dec 1998 | A |
5845332 | Inoue et al. | Dec 1998 | A |
5847997 | Harada et al. | Dec 1998 | A |
5860124 | Matthews et al. | Jan 1999 | A |
5867417 | Wallace et al. | Feb 1999 | A |
5878142 | Caputo et al. | Mar 1999 | A |
5890016 | Tso | Mar 1999 | A |
5928347 | Jones | Jul 1999 | A |
5928370 | Asnaashari | Jul 1999 | A |
5935244 | Swamy et al. | Aug 1999 | A |
5937423 | Robinson | Aug 1999 | A |
5937425 | Ban | Aug 1999 | A |
5938750 | Shaberman | Aug 1999 | A |
5943692 | Marberg et al. | Aug 1999 | A |
5949882 | Angelo | Sep 1999 | A |
5963983 | Sakakura et al. | Oct 1999 | A |
5974486 | Siddappa | Oct 1999 | A |
5991194 | Jigour et al. | Nov 1999 | A |
5991546 | Chan et al. | Nov 1999 | A |
6003135 | Bialick et al. | Dec 1999 | A |
6009480 | Pleso | Dec 1999 | A |
6011486 | Casey | Jan 2000 | A |
6011741 | Wallace et al. | Jan 2000 | A |
6012103 | Sartore et al. | Jan 2000 | A |
6016530 | Auclair et al. | Jan 2000 | A |
6016553 | Schneider et al. | Jan 2000 | A |
6028807 | Awsienko | Feb 2000 | A |
6038320 | Miller | Mar 2000 | A |
6038640 | Terme | Mar 2000 | A |
6044428 | Rayabhari | Mar 2000 | A |
6058441 | Shu | May 2000 | A |
6067625 | Ryu | May 2000 | A |
6069827 | Sinclair | May 2000 | A |
6081850 | Garney | Jun 2000 | A |
6088755 | Kobayashi et al. | Jul 2000 | A |
6088802 | Bialick et al. | Jul 2000 | A |
6102103 | Zobel et al. | Aug 2000 | A |
6109939 | Kondo et al. | Aug 2000 | A |
6128675 | Ko | Oct 2000 | A |
6131141 | Ravid | Oct 2000 | A |
6137710 | Iwasaki et al. | Oct 2000 | A |
6145045 | Falik et al. | Nov 2000 | A |
6145046 | Jones | Nov 2000 | A |
6148354 | Ban et al. | Nov 2000 | A |
6151657 | Sun et al. | Nov 2000 | A |
6163816 | Anderson et al. | Dec 2000 | A |
6168077 | Gray et al. | Jan 2001 | B1 |
6170743 | Okaue et al. | Jan 2001 | B1 |
6174205 | Madsen et al. | Jan 2001 | B1 |
6182162 | Estakhri et al. | Jan 2001 | B1 |
6199122 | Kobayashi | Mar 2001 | B1 |
6216230 | Rallis et al. | Apr 2001 | B1 |
6226202 | Kikuchi | May 2001 | B1 |
6253300 | Lawrence et al. | Jun 2001 | B1 |
6279069 | Robinson et al. | Aug 2001 | B1 |
6279114 | Toombs et al. | Aug 2001 | B1 |
6286087 | Ito et al. | Sep 2001 | B1 |
6292863 | Terasaki et al. | Sep 2001 | B1 |
6330624 | Cromer et al. | Dec 2001 | B1 |
6330648 | Wambach et al. | Dec 2001 | B1 |
6361369 | Kondo et al. | Mar 2002 | B1 |
6370603 | Silverman et al. | Apr 2002 | B1 |
6385667 | Estakhri et al. | May 2002 | B1 |
6418501 | Gama et al. | Jul 2002 | B1 |
6424524 | Bovio et al. | Jul 2002 | B2 |
6425084 | Rallis et al. | Jul 2002 | B1 |
6434648 | Assour et al. | Aug 2002 | B1 |
6453414 | Ryu | Sep 2002 | B1 |
6457099 | Gilbert | Sep 2002 | B1 |
6488542 | Laity | Dec 2002 | B2 |
6493770 | Sartore et al. | Dec 2002 | B1 |
6671808 | Abbott et al. | Dec 2003 | B1 |
6763399 | Margalit et al. | Jul 2004 | B2 |
6920553 | Poisner | Jul 2005 | B1 |
20030057285 | Okaue et al. | Mar 2003 | A1 |
20040039854 | Estakhri et al. | Feb 2004 | A1 |
20060230202 | Lee | Oct 2006 | A1 |
Number | Date | Country |
---|---|---|
1201235 | Dec 1998 | CN |
195 36 206 | Apr 1996 | DE |
196 36 087 | Sep 1997 | DE |
196 31 050 | Feb 1998 | DE |
0 392 895 | Oct 1990 | EP |
0 152 024 | Jun 1991 | EP |
0 703 544 | Mar 1996 | EP |
0 712 067 | May 1996 | EP |
0 859 325 | Aug 1998 | EP |
0 883 083 | Dec 1998 | EP |
0 883 083 | Dec 1998 | EP |
0 883 084 | Dec 1998 | EP |
0 890 905 | Jan 1999 | EP |
0 929 043 | Jul 1999 | EP |
1 001 329 | May 2000 | EP |
0 912 939 | Sep 2001 | EP |
0 917 064 | Nov 2001 | EP |
0 775 956 | May 2002 | EP |
2 179 939 | Nov 1995 | FR |
2 291 990 | Feb 1996 | GB |
2 304 428 | Mar 1997 | GB |
2 325 997 | Dec 1998 | GB |
1 115928 | May 1989 | JP |
5 016746 | Jan 1993 | JP |
6-111589 | Apr 1994 | JP |
8 171623 | Jul 1996 | JP |
8-510072 | Oct 1996 | JP |
09-069067 | Mar 1997 | JP |
10 063442 | Mar 1998 | JP |
10 063804 | Mar 1998 | JP |
10 105296 | Apr 1998 | JP |
10 261774 | Sep 1998 | JP |
10-334206 | Dec 1998 | JP |
11-15928 | Jan 1999 | JP |
11 015928 | Jan 1999 | JP |
11 025681 | Jan 1999 | JP |
11-53485 | Feb 1999 | JP |
11 053485 | Feb 1999 | JP |
11 086578 | Mar 1999 | JP |
2000-207137 | Jul 2000 | JP |
WO 8707063 | Nov 1987 | WO |
WO 9319419 | Sep 1993 | WO |
WO 9613004 | May 1996 | WO |
WO 9803915 | Jan 1998 | WO |
WO 9803915 | Jan 1998 | WO |
WO 9807255 | Feb 1998 | WO |
WO 9829830 | Jul 1998 | WO |
WO 9855912 | Dec 1998 | WO |
WO 9901820 | Jan 1999 | WO |
WO 9901820 | Jan 1999 | WO |
WO 9908196 | Feb 1999 | WO |
WO 9912101 | Mar 1999 | WO |
WO 9945460 | Sep 1999 | WO |
WO 9945460 | Sep 1999 | WO |
WO 9949470 | Sep 1999 | WO |
WO 9949470 | Sep 1999 | WO |
WO 0007088 | Feb 2000 | WO |
WO 0042491 | Jul 2000 | WO |
WO 0049488 | Aug 2000 | WO |
WO 0049488 | Aug 2000 | WO |
WO 0124054 | Apr 2001 | WO |
WO 03030180 | Apr 2003 | WO |
WO 03030180 | Apr 2003 | WO |
Number | Date | Country | |
---|---|---|---|
Parent | 09285706 | Apr 1999 | US |
Child | 10292868 | US |