This invention relates to the field of online digital content distribution and more particularly, to a system and method for facilitating music distribution and authentication over a communications network.
The internet has created a highway for users and companies to share digitized content. Online services allow digitized content stored on servers to be shared by multiple users via the internet. Online services also allow users to play digitized content stored in an Internet-connected repository.
It is advantageous for online service providers to detect and verify whether or not the user has a physical copy of digitized content, such as a CD or DVD, prior to allowing the user access to the digitized content.
The present invention system identifies and authenticates digitized content, such as compact audio disc (hereinafter “CD-Audio,” or “CD”) residing in a CD-Audio-compatible drive of a computer and verifies that the CD is authentic or an exact replica. However, the present invention is not limited to CD verification. In certain embodiments of the invention, digitized content stored on DVDs or other medium including a physical disc, disc drive, or in solid state memory devices, may be verified. The invention may be practiced in a number of electronic devices, including personal computers, disc players such as CD players and DVD players, and other electronic devices. In certain embodiments according to the present invention, a verification database is created from a set of master CDs. The verification database contains records of CDs and a corresponding table-of-contents, also known as a table-of-contents identifier, (hereinafter “TOC”) and corresponding selected audio data from the CD.
After the verification database is created, verification of a CD to the master CD may be performed. The CD is first identified by matching the TOC from the CD against the verification database. Using the TOC data the system identifies one or more master CDs with a similar TOC. The identified CDs are then authenticated by matching selected audio data from the CD against the verification database created from a set of master CDs.
In the following embodiments of the invention, common reference numerals are used to represent the same components. If the features of an embodiment are incorporated into a single system, these components can be shared and perform all the functions of the described embodiments.
In
The Client 121 is a general purpose personal computer programmed to read CDs from the CD reader 123. The Client 121 is typically located at a remote location 117 which is connected to the network 113 via a communications link 119. In one embodiment the Client 121 is used by an Internet user computing from their home or office. The communications link 119 may be a dial-in modem connecting to an internet service provider or a broad-band service such as DSL or cable internet access.
The Server 111 is programmed to receive information from the Client 121 for verification with information stored in the Verification Database 106. The Server 111 is typically programmed to facilitate multiple connections from Clients 121 and 129, each with a CD Reader 123 and 131 respectively, and connected to the Network 113 via a communications link 115. The Clients 121 and 129 are also connected to the Network 113 via communications likes 119 and 127 respectively. Typically the Server 111 and the Verification Database 106 are located at a Server Facility 101 to optimize system performance. In another embodiment, the Server 111 may be located in a separate facility from the Verification Database 106. In a preferred embodiment of the invention the Server 111 is a high performance micro-computer running the UNIX operating system.
Before the Server 111 can identify and verify CDs for the Client 121, the corresponding CD data must be stored in the Verification Database 106. An Encoding Computer 103 is programmed to read master CDs from a CD reader 105 and store data about the CD in the Verification Database 106. Alternatively, data about the CD is computed from digital audio files stored on a computer that contain a copy of the audio data found on a master CD.
The Verification Database 106 is comprised of a Verification Table 107 and an Identification Table 109. Creation of the Verification Database 106 is accomplished by computing and storing entries in the database for each CD to be identified and verified by the Encoding Computer 103. Each database entry comprises several elements of identification and verification data which are computed from the TOC and audio data extracted from an original, authentic CD title.
In one embodiment of the present invention the various components and computers of the system communicate with each other using a general connection-oriented protocol such as the Transmission Control Protocol/Internet Protocol (TCP/IP), which is described in Internetworking with TCP/IP, 3d. ed., Douglas E. Comer, (1995), which is hereby incorporated by reference. However, the present invention is not limited to TCP/IP or any other particular network architecture, software or hardware which may be described herein. The principles of the invention apply to other communications protocols, network architectures, hardware and software which may come to compete with or even supplant the state of the art at the time of the invention.
In
Disc Identifier—A value assigned during database creation that uniquely identifies the CD.
TOC Identifier—A hash value computed from the CD TOC.
Disc Length—Total length (in blocks) of the audio portion of the CD.
First Track Length—Length (in blocks) of the first audio track on the CD.
Last Track Length—Length (in blocks) of the last audio track on the CD.
Shortest Track Length—Length (in blocks) of the shortest audio track on the CD.
Longest Track Length—Length (in blocks) of the longest audio track on the CD.
Disc Songprint—An identifying value computed from the CD audio data.
Once created, the entire Identification Table 109 may be sorted by and stored in ascending or descending order using the value of the Disc Length field to facilitate faster look ups.
In
Descriptive Data—Includes CD title and artist.
Disc Identifier—A value assigned during database creation that uniquely identifies the CD.
TOC Identifier—A hash value computed from the CD TOC.
Disc Songprint—An identifying value computed from the CD audio data.
Track Data—The following fields are included for each track:
Key Data—The following fields are included for each key:
The Encoding Computer 103 calculates a TOC identifier. A TOC identifier is computed from the CD TOC data by computing a cryptographic hash value using SHA-1 (Secure Hash Algorithm) of the concatenation of the lengths, in blocks, of each track on the CD represented as 4-byte values and truncating the resulting 20-byte hash value to 8 bytes.
The Encoding Computer 103 calculates a songprint. A songprint is a 128-byte value that represents the spectral content of a region of a digital audio recording. It is computed by the following steps:
The two stereo channels are averaged to produce a single channel.
The songprint region is divided into 512-byte chunks. Any partial chunks are discarded. Additionally, for each chunk, the following computations are made:
Each of the first 64 bytes of the songprint value is computed as follows:
Each of the final 64 bytes of the songprint value is computed as follows:
The Encoding Computer 103 uses the region to generate the songprint; the region varies between the Disc and Track Songprints and the Key Songprints. The Encoding Computer 103 selects the songprint region by first identifying the length of any “silent” audio at the beginning of the track. This is accomplished by reading 4096-byte blocks of audio data and computing a root-mean-square (RMS) of the amplitude of the samples (the two channels are averaged for each sample during this computation).
The end of the initial silent portion of a track is located by finding the first block that has an RMS amplitude which exceeds the predefined threshold. The beginning of the songprint region is then computed by adding a predefined offset. The length of the songprint region is a predefined value.
For Track Songprints, the RMS amplitude threshold for detecting the end of the initial silence is 0.001. The predefined offset from the end of the initial silence to the beginning of the songprint region is 30 seconds (30*75*2352 bytes). The predefined length of the songprint region is 5 seconds (5*75*2352 bytes).
A Disc Songprint is defined as the Track Songprint for the first track on the CD. The Key Songprint region is the same as the key region. This is because no silence detection or region offset is applied. The Key Songprint region length, like the key region length, is 4096 bytes.
The Encoding Computer 103 generates a Track Alignment Guide. A Track Alignment Guide comprises a 4-byte sample search value and a 4-byte hash value computed from the audio data block midway through the track. If the track is an odd number of blocks in length, the block at the midpoint is used. If the track is an even number of blocks in length, the block immediately after the midpoint is used.
The 4-byte sample search value is the first 4 bytes of the audio data block. The 4-byte hash value is computed by hashing the first 64 bytes of the audio data block using the SHA-1 algorithm and truncating the result to 4 bytes.
The Encoding Computer 103 generates a Key Alignment Guide. A Key Alignment Guide comprises eight 2-byte samples taken from the audio data contained within a key region. The samples are taken at 292-sample intervals starting with the first sample contained within the key region (samples offsets 0, 292, 584, 876, 1168, 1460, 1752, and 2044).
The Encoding Computer 103 generates a Key Hash Data. Key Hash Data is computed by hashing all the bytes contained within the key region using the SHA-1 algorithm and storing the entire 20-byte hash result.
In
In
In block 305 Initial Request Processing is performed by the server upon receipt of an Initial Request message from the client. The server receives the Initial Request message from the client and proceeds to extract the TOC and Disc Songprint. The server, using the Identification Table, then locates the entry that best matches the TOC and Disc Songprint provided by the client. The server performs a binary search of the Identification Table (which is sorted by Disc Length) to find the entry that most nearly matches the disc length specified in the TOC.
In block 305, beginning with the entry in the Identification Table identified above, the server compares all neighboring entries to the TOC and Disc Songprint provided by the client. For each entry, the server first tests whether the disc length specified by the TOC and the disc length recorded in the table entry are within a specified limit. The server then computes the root-mean-square (RMS) of the differences between each of the first-, last-, shortest-, and longest-track fields of the table entry and the corresponding data from the TOC. The RMS difference must fall within a specified limit. Finally, the server computes the RMS difference between the corresponding data points (each of the 128 bytes) in the table entry songprint and the Disc Songprint provided by the client.
In block 307, the server selects the entry in the Identification Table that has the smallest RMS difference between the songprint and the one provided by the client, the Best Match. If that RMS difference does not fall within a specified limit, the verification fails and the server constructs a Disc Not Found message in block 309. If the RMS for the Best Match falls within the specified limit, the process proceeds to block 311.
In another embodiment, the server computes the RMS difference between the client-provided and database-provided values for each of the disc length, the first-, last-, shortest-, and longest-track fields, and each of the 128 bytes of the songprint and weights those individual differences to compute a single weighted-difference value representing the overall fit between the client-provided and database-provided data. The server selects as the Best Match the entry in the Identification Table that results in the smallest weighted-difference. In an alternate embodiment, the server selects all the entries which have weighted-difference values less than a predefined threshold and attempts to verify each of these Matches.
In block 311, the server locates the entries in the Verification Table corresponding to the Best Match values. Because each entry in the Verification Table contains a large number of usable verification keys, in block 313, the server selects a smaller subset of key candidates that will be used in the current disc verification. The subset is selected using a pseudo-random sequence that is seeded with the client network address and the current time reduced to half-day resolution (i.e., the same key candidates will be selected for a given network address during a given half day).
In block 313, the key region (the region of audio data on the CD from which each key was computed) is enlarged using the pseudo-random sequence so that the actual key region starts at a pseudo-random offset within the enlarged key region. In addition to the real key candidates selected from the Verification Table entry, a set of decoy keys are also generated, also using the address/time-seeded pseudo-random sequence (i.e., the same decoy key candidates will be generated for a given network address during a given half day). The decoy keys are chosen so as not to overlap the audio data regions from which the real keys are derived. In an alternate embodiment, a random sequence is used to select and adjust keys and generate decoy keys so that each verification attempt by a client causes the server to specify a different set of verification regions.
The server then proceeds to construction of a Verification Response message. The Verification Response message is constructed by the server in response to an Initial Request message from the client. It is also constructed in response to a Verification Request message from the client that fails the verification test as discussed below.
Also in block 313, from the key candidates selected during Initial Request Processing, the server selects one or more keys and includes the offset and length data for each key region in the Verification Response message. A key candidate is used only once during a single disc verification. When all key candidates have been used and the disc has not been successfully verified, the verification fails.
From the decoy key candidates selected during Initial Request Processing, the server selects one or more decoy keys and includes the offset and length data for each key region in the Verification Response message. A decoy key candidate is used only once during a single disc verification. The server generates enough decoy keys during Initial Request Processing so that the decoy keys are not exhausted before the disc keys.
The state of the disc verification process is encrypted and included in the Verification Response message. This includes the presumed identity of the disc, the selected key candidates, the generated decoy key candidates, and the key usage information (which keys/decoys have been requested from the client). The state information is returned to the server by the client in the Verification Request message and is decrypted by the server and used to restore the state of the verification process. The Track Alignment Guide data stored in the Verification Database entry is included in the Verification Response message. Finally, the Verification Response message is sent to the client.
In block 315, for each of the key regions requested by the server, the client determines in which track the region resides, checks the track alignment, and reads the requested data. The client begins track alignment by reading a block from the midpoint of that track and attempting to locate audio data that matches the Track Alignment Guide Data supplied by the server. If the track alignment data is not found, the client reads and searches adjoining blocks until the alignment data is found or a predefined number of blocks have been searched.
The client then computes the offset between the expected location of the track alignment data and the apparent location. After adjusting the location of the requested audio data region by the alignment offset computed, the client reads the audio data from the disc and includes it in the Verification Request message. The client includes the TOC data in the Verification Request message since the server preserves no client state. The Encoded State Information included by the server in the Verification Response message is copied by the client unmodified into the Verification Request message. The Verification Request message is sent to the server. In an alternate embodiment, the client state information is maintained by the server for the duration of the client verification session and is not sent to or received from the client.
In block 317, the server receives the Verification Request message from the client and proceeds to extract the Key Region data. Verification Request Processing is then performed by the server upon receipt of a Verification Request message from the client. The Encoded State Information is extracted, decoded, and used to restore the state of the verification process. For each key region supplied by the client, the server tests the client-supplied data against the corresponding Key Data stored in the disc's entry in the Verification Table. Any data supplied by the client for a decoy key region is discarded.
The server then attempts to locate the actual key region within the enlarged key region data supplied by the client by locating the region that provides the greatest number of values that match the corresponding values in the Key Alignment Guide Data. The server computes a hash value, using the SHA-1 algorithm, of the key region identified in the alignment step. This hash value is compared with the value stored with the Key Data in the disc's entry in the Verification Table. If the values match exactly, the verification is successful, and the server constructs a Verified Response message. On the other hand, if the values do not match exactly, a Key Songprint is computed by the server.
In block 319, a Key Songprint is computed from the key region identified in the alignment step. An RMS difference is computed between the corresponding individual byte values of the songprint computed from the client-supplied data and the songprint that is stored with the Key Data in the disc's entry in the Verification Table. If the RMS difference is less than or equal to a predefined threshold value, the verification is successful and the process follows the Yes path from block 319 to block 321 where the server constructs a Verified Response message.
Returning to block 319, if the server determines the RMS difference exceeds the threshold, the process continues to block 323 and if one or more of the key candidates selected during Initial Request Processing have not yet been requested from the client, the process follows the Yes Path from block 323 to block 313 and the server proceeds to construct a new Verification Response message.
Returning to block 321, the Verified Response message is constructed by the server upon completion of a successful verification. The server includes identifying information for the verified disc including, for example, the disc's title and artist. Additional information is included as required by the overall application.
The server also computes the offset between the expected location of the key region within the enlarged key region and the actual location. This offset value is included in the Verified Response message to enable the client to adjust data read operations in future verifications. The server computes and encrypts authorization data, as required by the overall application, which the client can present to third-parties as credentials certifying that the disc has been verified. The Verified Response message is sent to the client.
Returning to block 323, if the RMS difference exceeds the threshold and all key candidates have been exhausted, the verification fails. The process then follows the No path to block 325 where a Not Verified Response message is constructed by the server upon failing to locate in the Identification Table an entry that acceptably matches the disc being verified.
The client may also be programmed to respond in a particular manner to any of the system's messages, including a Verified message, a Not Verified message, or a Not Found message. For example, if the CD is verified, the client may be programmed to display information about the CD, or to automatically play the CD.
Number | Name | Date | Kind |
---|---|---|---|
3568156 | Thompson | Mar 1971 | A |
4384329 | Rosenbaum | May 1983 | A |
4833610 | Zamora | May 1989 | A |
5062143 | Schmitt | Oct 1991 | A |
5182708 | Ejiri | Jan 1993 | A |
5241674 | Kuorsawa | Aug 1993 | A |
5303150 | Komeda | Apr 1994 | A |
5303302 | Burrows | Apr 1994 | A |
5371807 | Register | Dec 1994 | A |
5392212 | Geist | Feb 1995 | A |
5404505 | Levinson | Apr 1995 | A |
5418951 | Damashek | May 1995 | A |
5497488 | Akizawa | Mar 1996 | A |
5499046 | Schiller et al. | Mar 1996 | A |
5539635 | Larson, Jr. | Jul 1996 | A |
5548507 | Martino | Aug 1996 | A |
5583763 | Atcheson | Dec 1996 | A |
5592511 | Schoen | Jan 1997 | A |
5608622 | Church | Mar 1997 | A |
5616876 | Cluts | Apr 1997 | A |
5661787 | Pocock | Aug 1997 | A |
5675786 | McKee et al. | Oct 1997 | A |
5678054 | Shibata | Oct 1997 | A |
5706365 | Rangarajan | Jan 1998 | A |
5708709 | Rose | Jan 1998 | A |
5713016 | Hill | Jan 1998 | A |
5721827 | Logan | Feb 1998 | A |
5726909 | Krikorian | Mar 1998 | A |
5740134 | Peterson | Apr 1998 | A |
5751672 | Yankowski | May 1998 | A |
5754938 | Herz | May 1998 | A |
5758257 | Herz | May 1998 | A |
5764235 | Hunt | Jun 1998 | A |
5774357 | Hoffberg et al. | Jun 1998 | A |
5790423 | Lau et al. | Aug 1998 | A |
5790935 | Payton | Aug 1998 | A |
5809246 | Goldman | Sep 1998 | A |
5819160 | Foladare | Oct 1998 | A |
5842010 | Jain | Nov 1998 | A |
5862220 | Perlman | Jan 1999 | A |
5862339 | Bonnaure | Jan 1999 | A |
5864868 | Contois | Jan 1999 | A |
5872921 | Zahariev | Feb 1999 | A |
5881234 | Schwab | Mar 1999 | A |
5883986 | Kopec | Mar 1999 | A |
5884312 | Dustan | Mar 1999 | A |
5898833 | Kidder | Apr 1999 | A |
5913040 | Rakavy | Jun 1999 | A |
5913041 | Ramanathan | Jun 1999 | A |
5926207 | Vaughan | Jul 1999 | A |
5930526 | Iverson | Jul 1999 | A |
5930768 | Hooban | Jul 1999 | A |
5931907 | Davies | Aug 1999 | A |
5941951 | Day | Aug 1999 | A |
5945988 | Williams | Aug 1999 | A |
5950189 | Cohen | Sep 1999 | A |
5956482 | Agraharam | Sep 1999 | A |
5960430 | Haimowitz | Sep 1999 | A |
5969283 | Looney | Oct 1999 | A |
5977964 | Williams | Nov 1999 | A |
5983176 | Hoffert et al. | Nov 1999 | A |
5987525 | Roberts et al. | Nov 1999 | A |
5996015 | Day | Nov 1999 | A |
6000008 | Simcoe | Dec 1999 | A |
6009382 | Martino | Dec 1999 | A |
6012098 | Bayeh | Jan 2000 | A |
6020883 | Herz | Feb 2000 | A |
6021203 | Douceur et al. | Feb 2000 | A |
6026398 | Brown | Feb 2000 | A |
6026439 | Chowdhury | Feb 2000 | A |
6029195 | Herz | Feb 2000 | A |
6031795 | Wehmeyer | Feb 2000 | A |
6035268 | Carus | Mar 2000 | A |
6038527 | Renz | Mar 2000 | A |
6038591 | Wolfe | Mar 2000 | A |
6047251 | Pon | Apr 2000 | A |
6047268 | Bartoli | Apr 2000 | A |
6047320 | Tezuka | Apr 2000 | A |
6047327 | Tso | Apr 2000 | A |
6052717 | Reynolds | Apr 2000 | A |
6061680 | Scherf et al. | May 2000 | A |
6064980 | Jacobi | May 2000 | A |
6065051 | Steele et al. | May 2000 | A |
6065058 | Hailpern | May 2000 | A |
6070185 | Anupam | May 2000 | A |
6085242 | Chandra | Jul 2000 | A |
6097719 | Benash | Aug 2000 | A |
6102406 | Miles | Aug 2000 | A |
6105022 | Takahashi | Aug 2000 | A |
6131082 | Hargrave | Oct 2000 | A |
6134532 | Lazarus | Oct 2000 | A |
6138142 | Linsk | Oct 2000 | A |
6154773 | Roberts et al. | Nov 2000 | A |
6161132 | Roberts et al. | Dec 2000 | A |
6161139 | Win | Dec 2000 | A |
6167369 | Schulze | Dec 2000 | A |
6182142 | Win | Jan 2001 | B1 |
6185560 | Young | Feb 2001 | B1 |
6192340 | Abecassis | Feb 2001 | B1 |
6205126 | Moon | Mar 2001 | B1 |
6222980 | Asai | Apr 2001 | B1 |
6225546 | Kraft | May 2001 | B1 |
6226618 | Downs et al. | May 2001 | B1 |
6230192 | Roberts et al. | May 2001 | B1 |
6230207 | Roberts et al. | May 2001 | B1 |
6240459 | Roberts et al. | May 2001 | B1 |
6246672 | Lumelsky | Jun 2001 | B1 |
6249810 | Kiraly | Jun 2001 | B1 |
6252988 | Ho | Jun 2001 | B1 |
6263313 | Milsted | Jul 2001 | B1 |
6272456 | de Campos | Aug 2001 | B1 |
6272495 | Hetherington | Aug 2001 | B1 |
6282548 | Burner | Aug 2001 | B1 |
6292795 | Peters | Sep 2001 | B1 |
6298446 | Schreiber | Oct 2001 | B1 |
6314421 | Sharnoff | Nov 2001 | B1 |
6317761 | Landsman | Nov 2001 | B1 |
6321205 | Eder | Nov 2001 | B1 |
6321221 | Bieganski | Nov 2001 | B1 |
6330593 | Roberts et al. | Dec 2001 | B1 |
6343317 | Glorikian | Jan 2002 | B1 |
6353849 | Linsk | Mar 2002 | B1 |
6370315 | Mizuno | Apr 2002 | B1 |
6370513 | Kolawa | Apr 2002 | B1 |
6389467 | Eyal | May 2002 | B1 |
6389538 | Gruse et al. | May 2002 | B1 |
6405203 | Collart | Jun 2002 | B1 |
6430539 | Lazarus | Aug 2002 | B1 |
6434535 | Kupka et al. | Aug 2002 | B1 |
6438579 | Hosken | Aug 2002 | B1 |
6487598 | Valencia | Nov 2002 | B1 |
6490553 | Van Thong | Dec 2002 | B2 |
6505203 | Adler | Jan 2003 | B1 |
6512763 | DeGolia, Jr. | Jan 2003 | B1 |
6513061 | Ebata | Jan 2003 | B1 |
6522769 | Rhoads et al. | Feb 2003 | B1 |
6526411 | Ward | Feb 2003 | B1 |
6532477 | Tang | Mar 2003 | B1 |
6535854 | Buchner et al. | Mar 2003 | B2 |
6538996 | West | Mar 2003 | B1 |
6557026 | Stephens, Jr. | Apr 2003 | B1 |
6560403 | Tanaka et al. | May 2003 | B1 |
6560704 | Dieterman | May 2003 | B2 |
6587127 | Leeke | Jul 2003 | B1 |
6611812 | Hurtado et al. | Aug 2003 | B2 |
6611813 | Bratton | Aug 2003 | B1 |
6614914 | Rhoads | Sep 2003 | B1 |
6615208 | Behrens | Sep 2003 | B1 |
6655963 | Horvitz | Dec 2003 | B1 |
6657117 | Weare | Dec 2003 | B2 |
6658151 | Lee | Dec 2003 | B2 |
6661787 | O'Connell | Dec 2003 | B1 |
6677894 | Sheynblat | Jan 2004 | B2 |
6725446 | Hahn | Apr 2004 | B1 |
6741980 | Langseth | May 2004 | B1 |
6757740 | Parekh | Jun 2004 | B1 |
6807632 | Carpentier et al. | Oct 2004 | B1 |
6889383 | Jarman | May 2005 | B1 |
6925441 | Jones, III et al. | Aug 2005 | B1 |
6952523 | Tanaka et al. | Oct 2005 | B2 |
20010005823 | Fischer | Jun 2001 | A1 |
20010042107 | Palm | Nov 2001 | A1 |
20010042109 | Bolas | Nov 2001 | A1 |
20010044855 | Vermeire | Nov 2001 | A1 |
20010052028 | Roberts et al. | Dec 2001 | A1 |
20010055276 | Rogers | Dec 2001 | A1 |
20020002039 | Qureshey | Jan 2002 | A1 |
20020004839 | Wine | Jan 2002 | A1 |
20020007418 | Hegde | Jan 2002 | A1 |
20020010621 | Bell | Jan 2002 | A1 |
20020010714 | Hetherington | Jan 2002 | A1 |
20020010789 | Lord | Jan 2002 | A1 |
20020013852 | Janik | Jan 2002 | A1 |
20020016839 | Smith | Feb 2002 | A1 |
20020035561 | Archer | Mar 2002 | A1 |
20020045717 | Grenda | Apr 2002 | A1 |
20020056004 | Smith | May 2002 | A1 |
20020065857 | Michalewicz | May 2002 | A1 |
20020082901 | Dunning | Jun 2002 | A1 |
20020095387 | Sosa | Jul 2002 | A1 |
20020099696 | Prince | Jul 2002 | A1 |
20020099737 | Porter | Jul 2002 | A1 |
20020111912 | Hunter et al. | Aug 2002 | A1 |
20020129123 | Johnson | Sep 2002 | A1 |
20020152204 | Ortega | Oct 2002 | A1 |
20020175941 | Hand | Nov 2002 | A1 |
20030002608 | Glenn | Jan 2003 | A1 |
20030007507 | Rajwan | Jan 2003 | A1 |
20030028796 | Roberts et al. | Feb 2003 | A1 |
20030046283 | Roberts | Mar 2003 | A1 |
20030083871 | Foote | May 2003 | A1 |
20030093476 | Syed | May 2003 | A1 |
20030133453 | Makishima | Jul 2003 | A1 |
20030135513 | Quinn et al. | Jul 2003 | A1 |
20030139989 | Churquina | Jul 2003 | A1 |
20030165200 | Pugel | Sep 2003 | A1 |
20030182139 | Harris | Sep 2003 | A1 |
20030190077 | Ross | Oct 2003 | A1 |
20030206558 | Parkkinen | Nov 2003 | A1 |
20050149759 | Vishwanath et al. | Jul 2005 | A1 |
Number | Date | Country |
---|---|---|
A5303198 | Feb 1997 | AU |
763380 | Mar 2000 | AU |
0173639 | May 1986 | EP |
0 847 156 | Sep 1997 | EP |
1010098 | Apr 1998 | EP |
1324567 | Apr 1998 | EP |
0955592 | Apr 1999 | EP |
0 955 592 | Nov 1999 | EP |
1010098 | Jun 2000 | EP |
1 050 833 | Aug 2000 | EP |
1236354 | Sep 2002 | EP |
1324567 | Jul 2003 | EP |
2306869 | Nov 1995 | GB |
11-514482 | Dec 1999 | JP |
2001202368 | Jul 2001 | JP |
2001521642 | Nov 2001 | JP |
WO 9825269 | Jun 1998 | WO |
WO 9847080 | Oct 1998 | WO |
WO 9847080 | Oct 1998 | WO |
WO 9927681 | Jun 1999 | WO |
WO 9943111 | Aug 1999 | WO |
WO 0046681 | Feb 2000 | WO |
WO 0031964 | Jun 2000 | WO |
WO 0046681 | Aug 2000 | WO |
WO 0133379 | Oct 2000 | WO |
WO 0135667 | Nov 2000 | WO |
WO 0154323 | Jan 2001 | WO |
WO 0173639 | Oct 2001 | WO |
WO 0242862 | May 2002 | WO |
WO 03012695 | Feb 2003 | WO |
Number | Date | Country | |
---|---|---|---|
20020111993 A1 | Aug 2002 | US |