Patent Grant
6925477
An appendix (appearing now in paper format to be replaced later in microfiche format) forms part of this application. The appendix, which includes a source code listing relating to an embodiment of the invention, includes 95 frames on 1 microfiche.
This patent document (including the microfiche appendix) contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
This invention relates to transferring records between incompatible databases.
Databases are collections of data entries which are organized, stored, and manipulated in a manner specified by applications known as database managers (hereinafter, the term “database” also refers to a database manager combined with a database proper). The manner in which database entries or records are organized in a database is known as the record structure of the database. Fields and records of a database may have many different characteristics depending on the database's purpose-and utility.
Databases can be said to be incompatible with one another when the data structure (or record structure) of one is not the same as the data structure (or record structure) of another, even though some of the content of the records is substantially the same. For example, one database may store names and addresses in the following fields: FIRST_NAME, LAST_NAME, and ADDRESS. Another database may, however, store the same information with the following structure: NAME, STREET_NO., STREET_NAME, CITY_STATE, and ZIP. Although the content of the records is intended to contain the same kind of information, the organization of that information is completely different.
Often users of incompatible databases want to be able to transfer records from one database to another incompatible database to populate the incompatible database with new records or to synchronize the two databases with one another. To do so, typically, a field map is used which is a set of relationships or correlations between the fields of the two databases to one another. Various types of data structures can be used to represent a field map in computer memory. Field mapping is generally described in the commonly assigned U.S. Pat. No. 5,392,390, incorporated herein by reference.
In a first aspect, in order to for example transfer data between two databases, a computer program automatically establishes a field map between the record structures of the two databases using information identifying the record structure of one of the databases. The field map is established automatically by correlating a first plurality of the fields of the first database to a second plurality of the fields of the second database. The data stored in the first plurality of fields of a plurality of the records of the first database is then translated in accordance with the field map.
Embodiments of this aspect of the invention have the advantage that a computer program does not use a predetermined field map and requires little or no input from the user for establishing the field map.
In a second aspect, prior to transmitting data between two databases during a data transfer session, information identifying the record structure of the one of the first and second databases is transmitted to a computer program and, based on that information, a data transfer protocol is established. Data stored in a plurality of fields of a plurality of the records of the first database is then transmitted, according to the database transfer protocol, from the first database to the second database.
Embodiments of this aspect of the invention may include the following advantages. By transmitting the identifying information prior to transmitting the data, the specifics of the data transfer session can be established in the data transfer protocol. In this manner, the efficiency of the data transfer session is increased, for example, by limiting the number of transmitted fields or by limiting the transmitted records to only those which meet a search criteria.
In a third aspect, in order to transmit data between two databases, information identifying the record structure of one of the two databases is transmitted to a computer program. This transmitted information identifies both the categories and the properties of a plurality of fields of the record structure of one of the two databases. Data stored in a plurality of fields of a plurality of the records of the first database is then transmitted from one of the two databases to the other one of the two databases. The transmitted data is then processed using the identifying information.
Embodiments of this aspect of the invention, by providing both the categories and properties of the fields, can provide a better picture of the data structure of a database to a computer program. Therefore, the computer program can more accurately process the data transmitted from the database. For example, the computer program can more accurately translate the records of the database to a form compatible with the record structure of another database.
Preferred embodiments of the invention may include one or more of the following features.
Data stored in the plurality of fields of the plurality of the records of the first database is transmitted to the second database. The data may be translated before the data is transmitted or may be translated after the data is received at its destination. The transmitted data may be stored in the second database or at least one record of the second database may be synchronized with the transmitted data. Additionally, the first database may be stored on a first computer and the second database on a second computer. In that case, the data is transmitted from the first computer to the second computer.
All or part of the fields in the data structure of the first computer is mapped onto all or part of the fields in the structure of the second computer.
The information identifying the record structure of one of the first and second databases identifies the record structure according to a selected protocol, where the selected protocol provides a syntax for identifying the characteristics of a field of that databases.
The identifying information identifies categories of the fields in the record structure of the one of the first and second databases according to the selected protocol and the fields of the first database are correlated to the fields of the second database based on the identified categories of the fields. The categories of the fields in the record structure of the one of the first and second databases can be classified into a plurality of mapping classes and the fields of the first database are correlated to the second plurality of the fields of the second database based on the plurality of mapping classes. Mapping rules are applied to the plurality of mapping classes to correlate the fields. One of the mapping rules can indicate that fields of the one of the databases having a selected class, if absent in the other one of the databases, are to be mapped to fields having a selected class.
The fields of the first and second databases are further characterized by having selected properties and the identifying information identifies the selected properties of the fields of one of the first and second databases according to the selected protocol. During translation, the data in the fields is then modified based on the identified properties.
The identifying information can be transmitted to a computer program where the computer program correlates the fields of the first and second databases to establish the field map. The transmitted information may be in a format according to a selected protocol and then be converted into the identifying information.
Establishing the data transfer protocol can include correlating the fields of the first database to the fields of the second database to establish a field map, using information identifying the record structure of one of the first and second databases. Establishing the data transfer protocol can also include determining a plurality of fields of the first database to be transmitted based on the plurality of the fields of the first database which were mapped, where the plurality of fields to be transmitted can be less than all of the fields of the records of the first database. Establishing the data transfer protocol can also include determining a plurality of records of the first database to be transmitted based on a selected criterion, where the selected criterion includes a criterion for searching a first database and selecting records matching the selected criterion.
The invention may be implemented in hardware or software, or a combination of both. Preferably, the technique is implemented in computer programs executing on programmable computers that each include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code is applied to data entered using the input device to perform the functions described above and to generate output information. The output information is applied to one or more output devices.
Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
Each such computer program is preferably stored on a storage medium or device (e.g., ROM or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described in this document. The system may also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.
Other features and advantages of the invention will become apparent from the following description of preferred embodiments, including the drawings, and from the claims.
We will describe various embodiments of computer programs and systems for transferring records between a database stored on a remote computer and an incompatible database stored on a host computer in detail below. It should be noted that the term “computer” as used here includes any device being capable of manipulating electronic data and typically having a processor and memory. Such a device can be, but is not limited to, a hand held computer, a personal digital assistant, and a personal computers such as a desktop computer or a notebook computer. Such a device can also be an electronic device having some “intelligence” or processing capability, such as an “intelligent” paging device or cellular telephone. It should also be noted we will use the terms “host” and “remote” for conveniently differentiating between the components of a first computer and a second computer and the programs running on the first and second computers. The first and second computers may be in any other type of relationship such as peer to peer, client/server, etc.
Briefly, in some embodiments described here, at the time of a data transfer session between the remote and host computers, the fields of the records of the remote database are dynamically and automatically mapped to the fields of the records of the host database. The fields are dynamically mapped in that a computer program generates a field map without having any previous information as to the data structure of at least one of the databases. This information is provided during the data transfer session. The fields are automatically mapped in that a computer program generates a field map during the data transfer session based on a set of predetermined criteria. The computer program does not use a predetermined field map and requires little or no input from the user for generating the field map. The map is then used to translate records of the remote database into a format compatible with the data structure of the host database.
To enable such dynamic and automatic mapping, in some embodiments, the remote computer sends the host computer a record structure data packet. The record structure data packet, based on a predefined field identification protocol, identifies the characteristics of the record structure of the remote database to the host computer. The host computer then uses that information to generate a field map for the two databases.
We will now describe an example of a computer system which may execute various embodiments of the programs described here for transferring data between two databases. Referring to
Each of the host and remote computers 10, 30 includes a long term storage device storing a database (respectively, referred to as host database 32 and remote database 34), which may be a database of a personal information manager (PIM) application. Each of the host and remote computers 10, 30 further includes a memory 14, 34 and a central processing unit (CPU) 16, 36. Each of the memory 14, 34 stores at least two types of computer software programs (which may be stored on a long term storage medium and loaded into memory 14, 34): host and remote data transfer programs 22, 42 for transferring records between the host and remote computers 10, 30 and host and remote data processing programs 24, 44 for processing the transferred records by, for example, populating or synchronizing the records of the database stored in the long term storage with the transferred records. It should be noted that data transfer programs 22, 42 typically constitute a module in either data processing programs 24, 44 or databases 12, 32.
Host and remote databases 12, 32 each has a record structure specifying the organization of the data in each of the records of the database. Each record typically includes a number of fields. In order to facilitate communicating the record structure of these databases between remote computer 30 and host computer 10, data transfer programs 22, 42 use a field identification protocol. A field identification protocol provides a syntax for identifying and communicating characteristics of a field of a database. It provides two types of information: information identifying a “category” for the field and information identifying a “property” of a field.
The category of a field defines the type of information the field is designed or meant to contain. Databases are generally designed to store data for a particular application, for example, airline reservations, medical records, etc. In the case of personal information manager (PIM) applications, several types of databases are typically used, where the type of a database corresponds to the type of data stored in the database: appointments, “to do” lists, address books, expense records, general notes records, and e-mails. For these types of databases, a field identification protocol preferably provides a comprehensive list of field categories such that the fields of most, if not all, of commercially available PIM databases can be categorized according to the categories in the field identification protocol. (The same can also be done for other types of databases.) For example, in the case of an address book type database, the categories may include: name, last name, first name, middle initial, address, street name, city, state, home telephone number, business telephone number, etc. Then, for example, the record structure of remote database 32 may include a field that is of the category “name”. The record structure of host database 12 may include equivalent fields of the categories “last name,” “first name,” and “middle initial,” but not necessarily a field of the category “name”. In other embodiments, the field identification protocol provides a list of field categories for a selected group of databases or for those databases designed to conform to the protocol.
The property of a field indicates the limits or rules imposed on the manner in which data is stored in that field. The property of a field is in addition to the category of that field and is typically database specific. The property of a field can be the number of bytes used to store the data in that field. The property of a field can also include one or more rules governing the permissible content of the data, such as one or more rules from the following exemplary list of rules:
As mentioned, a field identification protocol provides a syntax for remote and host data transfer programs 22, 42 to communicate with one another the data structure of their respective databases. Such a syntax includes, for example, assigning to each field category a designation (for example, a numerical, alphabetical, or alphanumerical code or name) identifying that field category, such as “Addr” for address, “Tell” for the first telephone number, “Appt:date” for a date field of an appointment type record. The syntax also includes a manner of communicating the possible properties of the various fields, for example, by using designations (for example, a numerical, alphabetical, or alphanumerical code or name) identifying a type of property, such as “field_size” for designating the number of bytes in a field, “ApptDate_format” for designating a format of a date field, “value_range” for designating the range of permissible values, or “maximum_text_size” for designating the maximum number of the characters in a text field.
Generally, a record structure of a database can be mapped to a record structure of another database based on the categories of the fields of the databases, as will be described below. However, in some circumstances, the properties of the fields can affect the accuracy of the mapping. For example, the content of a field or the number of bytes representing a field may have to be modified during translating the field according to the map so that a field fits the record structure of the other database. (This process is described as “sanitization” in the '490, '926, and '645 applications.) Therefore, the records of the two databases can be more accurately mapped and translated if both the categories and the properties of the fields of the databases are known.
Referring to
Referring to
To begin the data transfer session, one of the remote or host computers 10, 20 initiates a data transfer session (step 305). Remote data transfer program 42 then sends a record structure data packet including information identifying the record structure of remote database 32 to host computer 10 (step 310). To identify the record structure of the remote database to the host database, remote data transfer program 42 uses a field identification protocol, which we will refer to as the “external field identification protocol”. Using the external field identification protocol, remote data transfer program 42 constructs the record structure data packet to include the appropriate information and codes which identify the categories and properties of the fields of the records of remote database 32. In some embodiments, only the categories of the fields are identified.
Host data transfer program 22 uses the record structure packet from remote data transfer program 42 to automatically map the records of remote database 12 to the records of host database (step 320).
We will describe the automatic mapping process in detail below in reference to FIG. 4. However, briefly, host data transfer program 22 uses a series of automatic field mapping rules to correlate the fields in the record structure of remote database 32 to the fields in the record structure of host database 12. Hence, host data transfer program 22 develops a field map for mapping the records of the remote database to the records of the host database.
Referring to
In steps 410-430, host data transfer program 22, automatically correlates the fields of the records of the remote database to the fields of the records of the host database to develop a field map. We will now describe an exemplary method used by host data transfer program 22. In this exemplary method, the internal field identification protocol not only provides a manner for classifying fields based on the categories and properties, but also divides the field categories into, for example, five field classes for automatic mapping: generic, high priority, common, free, and application specific fields.
The first class designates the field categories which are present in the record structure of most, if not all, databases of a specific type (e.g. address book database). In other words, the first class designates fields that are “generic” for the type of database being mapped. For example, for an address book type database, such fields would include name, address, and telephone. According to the automatic mapping rules, host data transfer program 22 maps generic fields of one database to the generic fields of the other database (step 410). In some cases, a group of fields in one database contain the same information as a single field in another database. For example, one database may have a “name” field while the other database may have separate “first name”, “middle initial”, and “last name” fields. In that case, the group of fields is mapped to the single field.
Other four classes designate field categories which are not generic to the type of database being mapped. According to the automatic mapping rules, these other fields are mapped in a pre-specified order of priority, if there are suitable fields in the other database for them. The first of these non-generic classes are the fields that are designated to have high priority for mapping. Host data transfer program 22 maps these fields first and maps them to an unmapped field of the other database (step 415). The second non-generic class designates the common fields which are the fields which most commonly are present in the type of database being mapped but it is not uncommon for a database of this type not to contain them. For example, in the case of address book databases, most, but not all, databases have fields for notes or for a second set of address and telephone number. According to the automatic mapping rules, host data transfer program 22 maps common fields of the remote database to the common fields and, based on user preferences, free fields (for the third non-generic class, described below) of the host database based on their category and properly designation (step 420).
The third non-generic class designates free fields and the fourth non-generic class designates database specific fields. Free fields are those fields which do not fall into any of the previous classes. Host data transfer program 22 maps high priority fields to the free fields and, based on user preferences, common fields of the other database (step 425). Database specific fields are those fields which are unique to a database and are typically not supported by another database. They are therefore not mapped. In this case, in some embodiments, the user maps the database specific field. At the end of this process, the data structures of the remote and host databases are mapped onto one another.
As stated above, another aspect of mapping is using the field property information to determine whether the received data needs to be modified for proper translation. To determine what modification is necessary, the properties of the field of the remote database and the mapped field or fields of host database 12 are compared. It is then determined what changes are necessary to make the remote database records to conform to the properties of the fields of the host database records. For example, if a field in the remote database is a four-byte field and it is mapped onto a two-byte field, then the field needs to be trimmed. (Similar data modifications may also be performed on host database records to conform them to remote database records when sending the host database records to the remote database, for example, at the end of synchronization.)
Referring back to
The data transfer protocol may also contain other features. For example, as mentioned above, in some embodiments, host data transfer program 22 may also request that the remote database to translate the remote database records using the map developed in step 320 before transmitting the records. In some embodiments, host data transfer program 22 may request that remote data transfer program 42 transmit only those records fitting a particular search criteria, specified based on the database record structure received from remote data transfer program 42.
As it is readily apparent, establishing a data transfer protocol at the beginning of the session provides a variety of advantages. Host database transfer program 22 can develop a field map which can be used throughout the data transfer session. Additionally, the map can be sent to remote data transfer program 42 for translating the records prior to transmitting them. Moreover, host and remote database transfer programs 22, 42 can limit the amount of data transferred during the session by remote data transfer program 42 by limiting the number of transmitted fields or by limiting the transmitted records to only those which meet a search criteria.
After agreeing to a data transfer protocol for the duration of the data transfer session, remote data transfer program then sends the data contained in the records of remote database 32, based on the agreed upon data transfer protocol (step 340). Host computer then processes the received data, as will be described below in reference to
Referring to
In other embodiments, host data processing program 24 synchronizes the records of host database 12 with the received records of remote database 32 (or those fields which were received). Referring to
After synchronization, host data transfer program 24 translates back those remote database records which need to be updated as a result of synchronization (step 560). Host data transfer program 24 then transmits those records to remote database 32.
Other embodiments are within the scope of the following claims.
For example, remote data transfer program 42 can develop a map based on a record structure data packet from host data transfer program 22. Remote data transfer program 42 can then automatically map the two databases and then use the map to translate the records before transmitting them to the host data transfer program 22.
In other embodiments, instead of agreeing to data transfer protocol at the beginning of a data transfer, the field category and property information may be send with each record and then processed by the other computer.
In some embodiments, the host and remote databases, and all relevant programs described here, are stored on a single computer and the processing and transferring of data is performed on the same computer. In other embodiments, a field identification protocol supporting only field categories is used.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4162610 | Levine | Jul 1979 | A |
| 4432057 | Daniell et al. | Feb 1984 | A |
| 4807154 | Scully et al. | Feb 1989 | A |
| 4807155 | Cree et al. | Feb 1989 | A |
| 4807182 | Queen | Feb 1989 | A |
| 4817018 | Cree et al. | Mar 1989 | A |
| 4819156 | DeLorme et al. | Apr 1989 | A |
| 4819191 | Scully et al. | Apr 1989 | A |
| 4827423 | Beasley et al. | May 1989 | A |
| 4831552 | Scully et al. | May 1989 | A |
| 4866611 | Cree et al. | Sep 1989 | A |
| 4875159 | Cary et al. | Oct 1989 | A |
| 4939689 | Davis et al. | Jul 1990 | A |
| 4956809 | George et al. | Sep 1990 | A |
| 4980844 | Demjanenko et al. | Dec 1990 | A |
| 5065360 | Kelly | Nov 1991 | A |
| 5124912 | Hotaling et al. | Jun 1992 | A |
| 5134564 | Dunn et al. | Jul 1992 | A |
| 5136707 | Block et al. | Aug 1992 | A |
| 5142619 | Webster, III | Aug 1992 | A |
| 5155850 | Janis et al. | Oct 1992 | A |
| 5170480 | Mohan et al. | Dec 1992 | A |
| 5187787 | Skeen et al. | Feb 1993 | A |
| 5197000 | Vincent | Mar 1993 | A |
| 5201010 | Deaton et al. | Apr 1993 | A |
| 5210868 | Shimada et al. | May 1993 | A |
| 5220540 | Nishida et al. | Jun 1993 | A |
| 5228116 | Harris et al. | Jul 1993 | A |
| 5237678 | Kuechler et al. | Aug 1993 | A |
| 5251151 | Demjanenko et al. | Oct 1993 | A |
| 5251291 | Malcolm | Oct 1993 | A |
| 5261045 | Scully et al. | Nov 1993 | A |
| 5261094 | Everson et al. | Nov 1993 | A |
| 5272628 | Koss | Dec 1993 | A |
| 5276876 | Coleman et al. | Jan 1994 | A |
| 5278978 | Demers et al. | Jan 1994 | A |
| 5278982 | Daniels et al. | Jan 1994 | A |
| 5283887 | Zachery | Feb 1994 | A |
| 5293627 | Kato et al. | Mar 1994 | A |
| 5301313 | Terada et al. | Apr 1994 | A |
| 5315709 | Alston, Jr. et al. | May 1994 | A |
| 5323314 | Baber et al. | Jun 1994 | A |
| 5327555 | Anderson | Jul 1994 | A |
| 5333252 | Brewer, III et al. | Jul 1994 | A |
| 5333265 | Orimo et al. | Jul 1994 | A |
| 5333316 | Champagne et al. | Jul 1994 | A |
| 5339392 | Risberg et al. | Aug 1994 | A |
| 5339434 | Rusis | Aug 1994 | A |
| 5355476 | Fukumura | Oct 1994 | A |
| 5375234 | Davidson et al. | Dec 1994 | A |
| 5392390 | Crozier | Feb 1995 | A |
| 5396612 | Huh et al. | Mar 1995 | A |
| 5412801 | de Remer et al. | May 1995 | A |
| 5421012 | Khoyi et al. | May 1995 | A |
| 5434994 | Shaheen et al. | Jul 1995 | A |
| 5444851 | Woest | Aug 1995 | A |
| 5455945 | VanderDrift | Oct 1995 | A |
| 5463735 | Pascucci et al. | Oct 1995 | A |
| 5475833 | Dauerer et al. | Dec 1995 | A |
| 5511188 | Pascucci et al. | Apr 1996 | A |
| 5519606 | Frid-Nielsen et al. | May 1996 | A |
| 5530853 | Schell et al. | Jun 1996 | A |
| 5530939 | Mansfield, Jr et al. | Jun 1996 | A |
| 5557518 | Rosen | Sep 1996 | A |
| 5560005 | Hoover et al. | Sep 1996 | A |
| 5568402 | Gray et al. | Oct 1996 | A |
| 5581753 | Terry et al. | Dec 1996 | A |
| 5581754 | Terry et al. | Dec 1996 | A |
| 5583793 | Gray et al. | Dec 1996 | A |
| 5596574 | Perlman et al. | Jan 1997 | A |
| 5600834 | Howard | Feb 1997 | A |
| 5608865 | Midgely et al. | Mar 1997 | A |
| 5613113 | Goldring | Mar 1997 | A |
| 5615109 | Eder | Mar 1997 | A |
| 5615364 | Marks | Mar 1997 | A |
| 5619689 | Kelly | Apr 1997 | A |
| 5623540 | Morrison et al. | Apr 1997 | A |
| 5630081 | Rybicki et al. | May 1997 | A |
| 5649182 | Reitz | Jul 1997 | A |
| 5659741 | Eberhardt | Aug 1997 | A |
| 5666530 | Clark et al. | Sep 1997 | A |
| 5666553 | Crozier | Sep 1997 | A |
| 5671407 | Demers et al. | Sep 1997 | A |
| 5682524 | Freund et al. | Oct 1997 | A |
| 5684984 | Jones et al. | Nov 1997 | A |
| 5684990 | Boothby | Nov 1997 | A |
| 5689706 | Rao et al. | Nov 1997 | A |
| 5701423 | Crozier | Dec 1997 | A |
| 5704029 | Wright, Jr. | Dec 1997 | A |
| 5706452 | Ivanov | Jan 1998 | A |
| 5706509 | Tso | Jan 1998 | A |
| 5708812 | Van Dyke et al. | Jan 1998 | A |
| 5708840 | Kikinis et al. | Jan 1998 | A |
| 5710922 | Alley et al. | Jan 1998 | A |
| 5727202 | Kucala | Mar 1998 | A |
| 5729735 | Meyering | Mar 1998 | A |
| 5737539 | Edelson et al. | Apr 1998 | A |
| 5745712 | Turpin et al. | Apr 1998 | A |
| 5758083 | Singh et al. | May 1998 | A |
| 5758150 | Bell et al. | May 1998 | A |
| 5758337 | Hammond | May 1998 | A |
| 5758355 | Buchanan | May 1998 | A |
| 5778388 | Kawamura et al. | Jul 1998 | A |
| 5781908 | Williams et al. | Jul 1998 | A |
| 5790789 | Suarez | Aug 1998 | A |
| 5809494 | Nguyen | Sep 1998 | A |
| 5813009 | Johnson et al. | Sep 1998 | A |
| 5813013 | Shakib et al. | Sep 1998 | A |
| 5819272 | Benson | Oct 1998 | A |
| 5819274 | Jackson, Jr. | Oct 1998 | A |
| 5832218 | Gibbs et al. | Nov 1998 | A |
| 5832489 | Kucala | Nov 1998 | A |
| 5838923 | Lee et al. | Nov 1998 | A |
| 5845293 | Veghte et al. | Dec 1998 | A |
| 5857201 | Wright, Jr. et al. | Jan 1999 | A |
| 5870759 | Bauer et al. | Feb 1999 | A |
| 5870765 | Bauer et al. | Feb 1999 | A |
| 5875242 | Glaser et al. | Feb 1999 | A |
| 5877760 | Onda et al. | Mar 1999 | A |
| 5878415 | Olds | Mar 1999 | A |
| 5884323 | Hawkins et al. | Mar 1999 | A |
| 5884324 | Cheng et al. | Mar 1999 | A |
| 5884325 | Bauer et al. | Mar 1999 | A |
| 5892909 | Grasso et al. | Apr 1999 | A |
| 5897640 | Veghte et al. | Apr 1999 | A |
| 5924094 | Sutter | Jul 1999 | A |
| 5926816 | Bauer et al. | Jul 1999 | A |
| 5926824 | Hashimoto | Jul 1999 | A |
| 5928329 | Clark et al. | Jul 1999 | A |
| 5943676 | Boothby | Aug 1999 | A |
| 5956508 | Johnson et al. | Sep 1999 | A |
| 5966714 | Huang et al. | Oct 1999 | A |
| 5974238 | Chase, Jr. | Oct 1999 | A |
| 5995980 | Olson et al. | Nov 1999 | A |
| 5999947 | Zollinger et al. | Dec 1999 | A |
| 6098078 | Gehani et al. | Jan 2000 | A |
| 6081806 | Chang et al. | Jun 2000 | A |
| 6125369 | Wu et al. | Sep 2000 | A |
| 6141664 | Boothby | Oct 2000 | A |
| 6212221 | Wakayama et al. | Apr 2001 | B1 |
| 6216131 | Liu et al. | Apr 2001 | B1 |
| 6247135 | Feague | Jun 2001 | B1 |
| 6272074 | Winner | Aug 2001 | B1 |
| 6330568 | Boothby et al. | Dec 2001 | B1 |
| 6401104 | LaRue et al. | Jun 2002 | B1 |
| 20010014890 | Liu et al. | Aug 2001 | A1 |
