The entire disclosure of Japanese Patent Application No. 2000-90661 filed on Mar. 29, 2000 including specification, claims, drawings and summary is incorporated herein by reference in its entirety.
The present invention relates to a technique for collecting or gathering statistical traffic data by capturing a TCP/IP traffic which flows on the Internet line. Specially, the present invention enables to collecting, by managing a TCP-level information in a certain direction, a traffic in another direction where it is impossible to directly capture the traffic.
A performance analysis, which measures such statistical traffic data as an amount of transferred data, becomes important according to a spread of the Internet. As described in Japanese Patent laid-open Application No. 11-252111, the inventors considered that it was possible to recognise a situation of the Internet by measuring a TCP-level statistical information (for example, an amount of re-transferred data, a waiting time for establishing a connection etc.), then developed a traffic monitor which can collect the TCP-level statistical traffic information in addition to an IP-level information by monitoring a backbone line of the Internet. The traffic monitor was developed under such a condition that it was possible to monitor segments of both directions in a TCP communication on the same line.
However, as an IP routing is controlled according to each direction, there is a case that traffics of both directions do not flow on the same line. Namely, because it can be considered that a going route and a return route are different each other in a real network configuration, there is a case that traffics of both direction can not be captured.
It is known the MRTG technique for collecting IP-level statistical traffic information such as an amount of segments per a unit time or an amount of bytes per a unit time respectively in a router. Further, it is known the SNIFFER technique for collecting TCP-level statistical traffic information such as an amount of segments or an amount of bytes respectively at every application in addition to the IP-level statistical traffic information. However, each technique has a condition that it is possible to monitor segments of both direction in the TCP communication on the same line.
An object of the present invention provides a method for collecting, by managing the TCP-level information in a certain direction, at least a traffic in another direction where it is impossible to directly capture the traffic.
A method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
Another method derived from the preferred embodiment comprises steps of:
In the method, it is possible to efficiently avoid an extraordinary amount by calculating the HTTP throughput only when the continuous ACK segments than a predetermined quantity such as 10 are detected.
Another method derived from the preferred embodiment comprises steps of:
In the method, it is possible to efficiently avoid an extraordinary amount by calculating the HTTP throughput only when the continuous ACK segments than a predetermined quantity such as 10 are detected.
Another method derived from the preferred embodiment comprises steps of:
In the method, it is possible to efficiently avoid an extraordinary amount by calculating the FTP throughput only when the continuous ACK segments than a predetermined quantity such as 10 are detected.
Another method derived from the preferred embodiment comprises steps of:
In the method, it is possible to efficiently avoid an extraordinary amount by calculating the FTP throughput only when the continuous DATA segments than a predetermined quantity such as 10 are detected.
a) shows a sample of the sequence chart for collecting the amount of the received data.
b) shows a sample of the duplicated bytes.
a) shows a sample of the sequence chart for collecting the HTTP response time and the HTTP throughput.
b) shows a sample of the sequence chart for collecting the HTTP response time and the HTTP throughput.
a) shows a sample of the sequence chart for collecting the FTP throughput.
b) shows a sample of the sequence chart for collecting the FTP throughput.
Referring to the drawings, embodiments of the present invention will be described.
(1) List of TCP-Level Information
The module 2 is connected with an Internet line 15. For example, the line is a backbone line which composes a part of the Internet. The module 2 captures a segment (called a packet) by monitoring a traffic on the line 15, for example, in a predetermined period, then sends the captured segment to the module 3.
In a network shown in
In the network shown in
Further, it is assumed that a traffic from the terminal(C) 7 to the terminal(A) 7 flows, as shown by a dotted line 17a, via the router 14, the Internet 10, the router 12 and the router 11 successively. It is also assumed that a traffic from the terminal(A) 7 to the terminal(C) 9 flows, as shown by a solid line 17b, via the router 11, the router 13, the Internet 10 and the router 14 successively. In this case, the module 2 can only capture the traffic in one direction shown by the dotted line 17a. In other words, the module 2 can not capture the traffic in other direction shown by the solid line 17b.
The module 3 calculates such a statistical traffic information as an amount of the transferred data, based on the segment captured by the module 2.
In the calculation, the module 3 identifies a type of the captured segment by using six flag bits in a TCP header of the captured segment.
A segment of which SYN bit only is “1” is called an SYN segment, and a segment of which SYN bit and ACK bit only are “1” is called an SYN+ACK segment.
A segment of which SYN bit only is “1” among the SYN bit, an FIN bit and the ACK bit, and which has a user data, is called a DATA segment. A segment of which SYN bit only is “1” among the SYN bit, an FIN bit and the ACK bit, but which has not the user data, is called a ACK segment.
Further, the module 3 identifies a connection to which the captured segment belongs, for example, based on an IP address included in the captured segment.
When the captured segment is the DATA segment, the module 3 identifies its sequence number, a user data length and an acknowledgment number. When the captured segment is the ACK segment, the module 3 identifies its acknowledgment number.
Further, the module 3 determines a sequence number [seq_nxt] of a DATA segment to be sent next by referring to the status transition table stored in the memory 5, at every detection of the DATA segment, based on a sequence number of the already detected DATA segment, then the module 3 manages the next sequence number [seq_nxt]. The next sequence number [seq_nxt] is equal to the maximum sequence number which already transferred.
The module 3 determines an acknowledgment [ack_nxt] of an ACK segment to be sent next by referring to the status transition table stored in the memory 5, at every detection of the ACK segment, based on an acknowledgment number of the already detected ACK segment, then the module 3 manages the next sequence number [seq_nxt]. The module 3 also determines a window size [win] of the detected ACK segment having the maximum acknowledgment number by referring to the status transition table stored in the memory 5, at every detection of the ACK segment, based on an acknowledgment number of the detected ACK segment.
The module 4 stores the calculated traffic information from he module 3 in the memory 5. The traffic information is classified by an IP address or a connection or an application.
Examples of the calculation in the module will be explained. It is possible to identify whether a communication is a communication from a client or a communication from a server by identifying whether the captured traffic is a traffic from a side which sent the SYN segment or a traffic from a side which sent the SYN+ACK segment.
[Collection of an Amount of Transmitted Data at the Side which Sent the SYN Segment]
Referring to a sequence chart shown in
As shown in
As shown in
ini—sdt=(SEQn+LENn)−SEQ1 equation (1)
Namely, the amount [ini_sdt] of transmitted bytes is a difference between the sequence number [SEQ1] of the first detected DATA segment, and a sum of the sequence number [SEQn] of the last detected DATA segment and the user data length [LENn] of the last detected DATA segment.
It is possible to calculates only one of the amount of transmitted segment and the amount of transferred bytes.
[Collection of an Amount of Transmitted Data from the Side which Sent the SYN+ACK Segment]
Referring to a sequence chart shown in
As shown in
As shown in
rsp—sdt=(SEQn+LENn)−SEQ1 equation (2)
Namely, the amount [rsp_sdt] of transmitted bytes is a difference between the sequence number [SEQ1] of the first detected DATA segment, and a sum of the sequence number [SEQn] of the last detected DATA segment and the user data length [LENn] of the last detected DATA segment.
It is possible to calculates only one of the amount of transmitted segment and the amount of transferred bytes.
[Collection of an Amount of Received Data at the Side which Sent the SYN Segment]
Referring to a sequence chart shown in
As shown in
ini—rdt=ACKn−ACK1 equation (3)
Namely, the amount [ini_rdt] of received data is a difference between the acknowledgment number [ACK1] of the first detected ACK or DATA segment and the acknowledgment number [ACKn] of the last detected ACK or DATA segment.
[Collection of an Amount of Received Data at the Side which Sent the SYN+ACK Segment]
Referring to a sequence chart shown in
As shown in
ini—rdt=ACKn−ACK1 equation (4)
Namely, the amount [rsp_rdt] of received data is a difference between the acknowledgment number [ACK1] of the first detected ACK or DATA segment and the acknowledgment number [ACKn] of the last detected ACK or DATA segment.
Next, referring to
[Collection of a Re-Transmitted Amount at the Side which Sent the SYN Segment]
To collect the re-transmitted amount from the side which sent the SYN segment, from a traffic in a direction which can be monitored, the SYN segment is detected. Further, the DATA segment, which belongs to same connection as the detected SYN segment, is detected as shown in
When the DATA segment is detected after the SYN segment in the monitored direction, it is judged whether a sequence number [SEQ] of the newly detected DATA segment is less than the above-mentioned next sequence number [seq_nxt] which was determined at the last DATA segment detection. When the sequence number [SEQ] is less than the next sequence number [seq_nxt], it is judged there was a re-transmission at the side which had sent the SYN segment.
As indicated by following equation (5), the new amount [ini_ret num] of re-transmitted segment is obtained by adding 1 to the last obtained amount of re-transmitted segment.
ini—ret—num=ini—ret—num+1 equation(5)
As indicated by following equation (5), the new amount [ini_ret] of re-transmitted bytes is obtained by adding bytes of a shaded part 18 or a shaded part 19 shown in
ini—ret=ini—ret+min(seq—nxt−SEQ,LEN) equation(6)
Namely, the amount [ini_ret] is obtained by adding a smaller one out of a first value [seq_nxt]−[SEQ] and a second value [LEN] to the last obtained amount of re-transmitted bytes. The first value [seq nxt]−[SEQ] is a difference between the determined next sequence number [seq_nxt] and a sequence number [SEQ] of the newly detected DATA segment. The second value [LEN] is a user data length of the newly detected DATA segment.
It is possible to calculates only one of the amount of re-transmitted segment and the amount of re-transmitted bytes.
In
Further in
[Collection of a Re-Transmitted Amount from the Side which Sent the SYN+ACK Segment]
To collect the re-transmitted amount at the side which sent the SYN+ACK segment, from a traffic in a direction which can be monitored, the SYN+ACK segment is detected. Further, the DATA segment, which belongs to same connection as the detected SYN+ACK segment, is detected as shown in
When the DATA segment is detected after the SYN+ACK segment in the monitored direction, it is judged whether a sequence number [SEQ] of the newly detected DATA segment is less than the above-mentioned next sequence number [seq_nxt] which was determined at the last DATA segment detection. When the sequence number [SEQ] is less than the next sequence number [seq_nxt], it is judged there was a re-transmission at the side which had sent the SYN+ACK segment.
As indicated by following equation (7), the new amount [rsp_ret num] of re-transmitted segment is obtained by adding 1 to the last obtained amount of re-transmitted segment.
rsp—ret—num=rsp—ret—num+1 equation(7)
As indicated by following equation (8), the new amount [rsp_ret] of re-transmitted bytes is obtained by adding bytes of a shaded part 18 or a shaded part 19 shown in
rsp—ret=rsp—ret+min(seq—nxt−SEQ,LEN) equation(8)
Namely, the amount [rsp_ret] is obtained by adding a smaller one out of a first value [seq_nxt]−[SEQ] and a second value [LEN] to the last obtained amount of re-transmitted bytes. The first value [seq_nxt]−[SEQ] is a difference between the determined next sequence number [seq_nxt] and a sequence number [SEQ] of the newly detected DATA segment. The second value [LEN] is a user data length of the newly detected DATA segment.
It is possible to calculates only one of the amount of re-transmitted segment and the amount of re-transmitted bytes.
Next, referring to
[Collection of an Amount of Missing Data Segment at the Side which Sent the SYN Segment]
To collect the amount of missing DATA segment at the side which sent the SYN segment, from a traffic in a direction which can be monitored, the SYN segment is detected. Further, a new ACK segment, which belongs to same connection as the detected SYN segment, is detected as shown in
When the new ACK segment is detected after the SYN segment in the monitored direction, an acknowledgment number [ACK] and an window size [WIN] of the newly detected DATA segment are compared with the above-mentioned next acknowledgment number [ack_nxt] and the present window size [win] which were determined at the last ACK segment detection. When both of following equations (9) and (10) are completed, it is judged there was a missing DATA segment at the side which had sent the SYN segment.
ACK=ack_nxt equation (9)
WIN=win equation (10)
Practically, when both of the equations (9) and (10) are completed two or more times about ACK segments of which sets of the acknowledgment number [ACK] and the window size [WIN] are equal to each other, as indicated following equation (11), the new amount [ini_recv_drop_num] of missing DATA segment, at a side which sent the detected SYN segments, is obtained by adding 1 to the last obtained amount of missing DATA segment.
ini—recv—drpo—num=ini—recv—drpo—num+1 equation (11)
For above-mentioned calculation, a duplicated ACK flag is introduced in this embodiment. A word “dupack” represents the duplicated ACK flag.
Then, only when a value of the dupack flag is equal to “0” as indicated by following equation (12), it is judged whether both of following equations (13) and (149 are completed. Herein, the equation (13) is equal to the equation (9) and the equation (14) is equal to the equation (10).
dupack=“0” equation (12)
ACK=ack_nxt equation (13)
WIN=win equation (14)
Further, only when both of the equations (13) and (14) are completed, as indicated by following equation (15), 1 is added to the last obtained amount [ini_recv_drop] of missing DATA segment. Still further, as shown by following equation (16), the value of the dupack flag is changed to “1”. Herein, the equation (13) is equal to the equation (11).
The value of the dupack flag is managed by the module 3, as follows.(1) An initial value of the dupack flag is set “0”. (dupack=“0”)
As mentioned above, when the SYN segment is detected and the ACK segment, which belongs to same connection as the detected SYN segment, is detected, it is judged whether the acknowledgment number [ACK] and window size [WIN] of the detected ACK segment are respectively equal to the determined next acknowledgment number [ack_nxt] and the determined present window size [win].
At each time when both of the equations (9) and (10) are satisfied by the newly detected two or more ACK segments which have same acknowledgment number and same window size, the new amount [ini_recv_drop_num] of missing DATA segment at the side which sent the detected SYN segments, is obtained by adding 1 to the last obtained amount of missing DATA segment.
Referring a sequence chart shown in
Because [ACK]=2920, [WIN]=8192 in the second ACK segment, [ACK] is not equal to [ack_nxt], then, [ack_nxt] is changed to 2920. The value of the dupack flag is not changed from “0”.
The second ACK segment and the third DATA segment have the same acknowledgment number [ACK=2920] and the same window size [WIN=8192], further these acknowledgment number [ACK=2920] and window size [WIN=8192] are respectively equal to the determined next acknowledgment number [ack_nxt=2920] and the determined present window size [win=8192]. Then, the amount of the missing DATA segment becomes 1 by adding 1 to the last amount (0) of the missing DATA segment and the value of the dupack flag is changed from “0” to “1”, when the third DATA segment is detected.
The second ACK segment and the fourth DATA segment have the same acknowledgment number [ACK=2920] and the same window size [WIN=8192], further these acknowledgment number [ACK=2920] and window size [WIN=8192] are respectively equal to the determined next acknowledgment number [ack_nxt=2920] and the determined present window size [win=8192]. However, because the value of the dupack flag is “1” when the fourth DATA segment is detected, the amount of the missing DATA segment is not increased and the value of the dupack flag is not changed from “1”.
The fifth ACK segment has an acknowledgment number [ACK=4380] and an window size [WIN=8192], then the acknowledgment number [ACK=4380] is different from the acknowledgment number [ACK=2920] of the second, third and fourth DATA segment.
Further, when the fourth DATA segment is detected, the determined next acknowledgment number [ack_nxt] is 2920 and the determined present window size [win] is 8192.
Therefore, because [ACK] is not equal to [ack_nxt] when the fifth DATA segment is detected, the next acknowledgment number [ack_nxt] changed to 4380 and the value of the dupack flag is returned to “0”.
The fifth ACK segment and the sixth DATA segment have the same acknowledgment number [ACK=4380] and the same window size [WIN=8192], further these acknowledgment number [ACK=4380] and window size [WIN=8192] are respectively equal to the determined next acknowledgment number [ack_nxt=4380] and the determined present window size [win=8192]. Then, the amount of the missing DATA segment becomes 2 by adding 1 to the last amount (1) of the missing DATA segment and the value of the dupack flag is changed from “0” to “1”, when the sixth DATA segment is detected.
When the seventh ACK segment and the eighth DATA segment, the amount of the missing DATA segment is not increased. Namely,
Further, when the seventh DATA segment is detected, the determined next acknowledgment number [ack_nxt] is 5840 and the determined present window size [win] is 8192. Therefore, because [WIN] is not equal to [win] when the eighth DATA segment is detected, the present window size [win] changed to 16384 and the value of the dupack flag is “0”.
[Collection of an Amount of Missing Data Segment at the Side which Sent the SYN+ACK Segment]
To collect the amount of missing DATA segment at the side which sent the SYN+ACK segment, from a traffic in a direction which can be monitored, the SYN+ACK segment is detected. Further, a new ACK segment, which belongs to same connection as the detected SYN+ACK segment, is detected as shown in
When the new ACK segment is detected after the SYN+ACK segment in the monitored direction, an acknowledgment number [ACK] and an window size [WIN] of the newly detected DATA segment are compared with the above-mentioned next acknowledgment number [ack_nxt] and the present window size [win] which were determined at the last ACK segment detection.
By introducing the dupack flag as mentioned in collecting the amount of missing DATA segment at the side which sent the SYN segment, is judged whether all of following equations (17), (18) and (19) are satisfied.
dupack=“0” equation (17)
ACK=ack_nxt equation (18
WIN=win equation (19)
Under the condition of dupack=“0” as indicated by the equation (17), when both of the equations (18) and (19) are completed, as indicated following equation (20), the new amount [rsp_recv_drop_num] of missing DATA segment, at a side which sent the detected SYN segments, is obtained by adding 1 to the last obtained amount of missing DATA segment, further the value of the dupack flag is changed from “0” to “1” as indicated following equation (21).
rsp—recv—drpo—num=rsp—recv—drpo—num+1 equation (20)
dupck=“1” equation (21)
In other words, when the SYN+ACK segment is detected and the ACK segment, which belongs to same connection as the detected SYN+ACK segment, is detected, it is judged whether the acknowledgment number [ACK] and window size [WIN] of the newly detected ACK segment are respectively equal to the determined next acknowledgment number [ack_nxt] and the determined present window size [win].
At each time when both of the equations (18) and (19) are satisfied by the newly detected two or more ACK segments which have same acknowledgment number and same window size, the new amount [rsp_recv_drop_num] of missing DATA segment at the side which sent the detected SYN+ACK segments, is obtained by adding 1 to the last obtained amount of missing DATA segment.
Next, referring to
[Description of HTTP Communication]
An HTTP communication is achieved by an HTTP request from a client to a server and an HTTP response from the server to the client. The HTTP request and the HTTP response respectively comprise plural DATA segments. Usually, because the HTTP response includes such a content as a text and an image, a total bytes of the DATA segments of the HTTP response is greater than that of the HTTP request. Further, plural ACK segments are sent from the server and the client respectively corresponding to each group of DATA segments from the client and the server.
[Collection of an HTTP Response Time at a Side which Sent an SYN Segment]
Referring to a sequence chart shown in
The HTTP response time [ini_http_rsp_time], at the side which sent the SYN segment, is obtained by calculating a time difference from the last segment of the HTTP request to the first segment of the HTTP response. A boundary between the HTTP request and the HTTP response is a boundary between the continuous plural DATA segments and the continuous plural ACK segments.
Therefore as shown in
The HTTP throughput [ini_http_tpt], at the side which sent the SYN segment, is obtained by calculating a ratio of an amount of total bytes of the HTTP response to a time difference between a first segment and a last segment of the HTTP response. It is desirable in a precise to obtain an HTTP throughput during the HTTP response, because the total bytes of the DATA segments of the HTTP response is usually greater than that of the HTTP request.
As shown in
Further, as indicated in the following equation (22), the HTTP throughput [ini_http_tpt] at the side which sent the SYN segment is obtained by calculating a ratio of the amount [http_rsp_byt] of the total bytes to the time difference [http_rsp_dtime].
ini_http_tpt=http_rsp_byt/http_rsp_dtime equation (22)
In the calculation of the HTTP throughput [ini_http_tpt], it is possible to efficiently avoid an extraordinary amount by calculating the HTTP throughput only when the continuously detected ACK segments than a predetermined quantity such as 10.
It is possible to calculates only one of the HTTP response time and the HTTP throughput. Further, it is possible to obtain the HTTP throughput by calculating a ratio of the amount of the total bytes of the HTTP request, to a time difference between the first segment and the last segment of the HTTP request.
[Collection of an HTTP Response Time at a Side which Sent an SYN+ACK Segment]
Referring to a sequence chart shown in
The HTTP response time [rsp_http_rsp_time], at the side which sent the SYN+ACK segment, is obtained by calculating a time difference from the last segment of the HTTP request to the first segment of the HTTP response. A boundary between the HTTP request and the HTTP response is a boundary between the continuous plural ACK segments and the continuous plural DATA segments.
Therefore as shown in
As shown in
Further, as indicated in the following equation (23), the HTTP throughput [rsp_http_tpt] at the side which sent the SYN+ACK segment is obtained by calculating a ratio of the amount [http_rsp_byt] of the total bytes to the time difference [http_rsp_dtime].
rsp_http_tpt=http_rsp_byt/http_rsp_dtime equation (23)
In the calculation of the HTTP throughput [rsp_http_tpt], it is possible to efficiently avoid an extraordinary amount by calculating the HTTP throughput only when the continuously detected ACK segments than a predetermined quantity such as 10.
It is possible to calculates only one of the HTTP response time and the HTTP throughput. Further, it is possible to obtain the HTTP throughput by calculating a ratio of the amount of the total bytes of the HTTP request, to a time difference from the first segment to the last segment of the HTTP request.
Next, referring to
[Description of FTP Communication]
An FTP communication is achieved by a control TCP connection for transmitting control data and a data TCP connection for transmitting a file. In the data TCP connection, because DATA segments may be transmitted in large quantities from a server to a client, it is possible to calculate a throughput. Further, ACK segments are transmitted in large quantities from a server to a client, in response to the large quantity of DATA segments from the server. In the data TCP connection, an SYN segment is sent by the server and an SYN+ACK segment is sent by the client.
[Collection of FTP Throughput at a Side which Sent SYN+ACK segment]
Referring to a sequence chart shown in
In the embodiment, the FTP throughput [ini_ftp_tpt], at the side which sent the SYN+ACK segment, is obtained by calculating a ratio of an amount of total bytes of the file to a time difference between a first segment and a last segment in the file transmission.
As shown in
Further, as indicated in the following equation (24), the FTP throughput [ini_ftp_tpt] at the side which sent the SYN+ACK segment is obtained by calculating a ratio of the amount [ftp_byt] of the total bytes to the time difference [ftp_dtime].
ini—ftp—tpt=ftp—byt/ftp—dtime equation (24)
In the calculation of the FTP throughput [ini_ftp_tpt], it is possible to efficiently avoid an extraordinary amount by calculating the FTP throughput only when the continuously detected ACK segments than a predetermined quantity such as 10.
[Collection of FTP Throughput at a Side which Sent SYN Segment]
Referring to a sequence chart shown in
In the embodiment, the FTP throughput [rsp_ftp_tpt], at the side which sent the SYN segment, is obtained by calculating a ratio of an amount of total bytes of the file to a time difference between a first segment and a last segment in the file transmission.
As shown in
Further, as indicated in the following equation (25), the FTP throughput [rsp_ftp_tpt] at the side which sent the SYN segment is obtained by calculating a ratio of the amount [ftp_byt] of the total bytes to the time difference [ftp_dtime].
rsp—ftp—tpt=ftp—byt/ftp—dtime equation (25)
In the calculation of the FTP throughput [rsp_ftp_tpt], it is possible to efficiently avoid an extraordinary amount by calculating the FTP throughput only when the continuously detected DATA segments than a predetermined quantity such as 10.
As mentioned-above, it is possible to identify the collected statistical traffic data, based on detecting the SYN segment or the SYN+ACK segment. Namely, it is possible to identify whether a monitored communication is the communication from the server or the communication from the client, based on detecting the SYN segment or the SYN+ACK segment.
[Effect of the Invention]
By the present invention, it is possible to estimate a traffic in a certain direction, where it is impossible to directly capture the traffic, from the opposite direction. Then, a large quantity of the traffic can be collected, and the present invention is useful for searching the traffic in the backbone line connected with the Internet.
Number | Date | Country | Kind |
---|---|---|---|
2000-090661 | Mar 2000 | JP | national |
Number | Name | Date | Kind |
---|---|---|---|
4652915 | Heller, III | Mar 1987 | A |
5444849 | Farrand et al. | Aug 1995 | A |
5802106 | Packer | Sep 1998 | A |
6091710 | Mawhinney | Jul 2000 | A |
6178450 | Ogishi et al. | Jan 2001 | B1 |
6182139 | Brendel | Jan 2001 | B1 |
6201791 | Bournas | Mar 2001 | B1 |
6219706 | Fan et al. | Apr 2001 | B1 |
6269099 | Borella et al. | Jul 2001 | B1 |
6411986 | Susai et al. | Jun 2002 | B1 |
6427169 | Elzur | Jul 2002 | B1 |
6427173 | Boucher et al. | Jul 2002 | B1 |
6449266 | Hottinen et al. | Sep 2002 | B1 |
6560630 | Vepa et al. | May 2003 | B1 |
6587435 | Miyake et al. | Jul 2003 | B1 |
6625166 | Tsukamoto et al. | Sep 2003 | B1 |
6650636 | Bradshaw et al. | Nov 2003 | B1 |
6654923 | Grenier et al. | Nov 2003 | B1 |
6691165 | Bruck et al. | Feb 2004 | B1 |
6711137 | Klassen et al. | Mar 2004 | B1 |
6728885 | Taylor et al. | Apr 2004 | B1 |
6757255 | Aoki et al. | Jun 2004 | B1 |
6907042 | Oguchi | Jun 2005 | B1 |
6925060 | Mangin | Aug 2005 | B1 |
Number | Date | Country |
---|---|---|
11-252111 | Sep 1999 | JP |
Number | Date | Country | |
---|---|---|---|
20010027485 A1 | Oct 2001 | US |