US7315513B2

Method for controlling data flow rate in an internet connection

Summary by NHIP

Dynamic Data Flow Throttling

The method controls data flow rates across a satellite link by calculating a throttling value based on receiver buffer statistics and a forcing factor. This value adjusts the sending rate using the formula T=P(1−1/(1+RBR))(1/(1+SBV s)) to prevent buffer overfilling at the remote node.

Claim Score by NHIP

Read claim 6, the broadest

Abstract

Described herein is a method of controlling data flow between a local network (120) and a remote network (30) via a geostationary satellite link (40, 46, 48). The local network (120) comprises a sending host (22) and a connection splitting node (124) which includes a throttling unit (150). The remote network (30) comprises a receiving host (32) which is connected to a second connection splitting node (142) having a buffer (152) via the internet (34). The data flow rate from the local network (120) is throttled to provide a data flow rate which substantially matches that which can be handled by the remote network (30) so that the buffer (152) at the second connection splitting node (142) is not overfilled.

US7315513B2, drawing sheet 1 — Sheet 1 of 5

Term

Term ended

Expired 25 August 2023, 3.1 years ago.

6 claims: 2 independent, 4 dependent

1
A method of controlling a data flow rate R 0 for a specific flow across an enhancer link from a first network to a second network, wherein the enhancer link comprises first and second connection splitting nodes, each node being associated with a respective one of the first and second networks, the second connection splitting node including a buffer for storing data during transfer to the second network, the method comprising:determining flow rate statistics at the second node, the flow rate statistics including a flow buffer volume SBV s for the specific flow;feeding the flow rate statistics back to the first network, determining for the specific flow a data flow rate R i for data flowing from the second connection splitting node into the second network;and applying at the first connection splitting node a throttling value T to adjust the data flow rate R 0 such that R 0 =TR 1 ;and wherein, the throttling value T is determined in dependence upon the flow rate statistics;and the throttling value T is further determined in dependence upon a forcing factor P whereby a small amount of extra data in the specific flow is pushed across the enhancer link than that indicated by the flow rate of the second splitting node.
6
Broadest claimClaim Score 40, average(NHIP)A method of controlling a data flow rate R 0 for a specific flow across an enhancer link from a first network to a second network, wherein the enhancer link comprises first and second connection splitting nodes, each node being associated with a respective one of the first and second networks, the second connection splitting node including a buffer for storing data during transfer to the second network, the method comprising:determining flow rate statistics at the second node, the flow rate statistics including a flow buffer volume SBV s for the specific flow;feeding the flow rate statistics back to the first network, determining for the specific flow a data flow rate R i for data flowing from the second connection splitting node into the second network;and applying at the first connection splitting node a throttling value T to adjust the data flow rate R 0 such that R 0 =TR i ;and wherein, the throttling value T is determined in dependence upon the flow rate statistics;and the data flow rate R i is determined in accordance with the round trip time of the second network and the amount of data in transit at any one time.

Independent claims2

68 paragraphs in 4 sections, as filed

BACKGROUND OF THE INVENTION

0001The present invention relates to improvements in or relating to internet access, and is more particularly, although not exclusively, concerned with controlled IP flows, where controlled implies a feedback connection.

0002Where TCP/IP (transmission control protocol over internet protocol) traffic flows between the internet as a whole and an essentially private, stub network across long-latency links, access to the internet is sub-optimal. Specifically, if a mobile network built around point-to-point, high latency wireless links (for example, a geostationary satellite link) is connected to the internet, the latencies involved severely restrict the performance of TCP/IP connections. However, TCP/IP is required to use flow control mechanisms for congestion avoidance and congestion recovery, but although this produces poor performance when applied to long-latency connections, it is essential to prevent the internet from collapsing.

SUMMARY OF THE INVENTION

0003It is therefore an object of the present invention to provide a system which improves the performance of controlled IP flows.

0004In accordance with one aspect of the present invention, there is provided a method of controlling data flow rate from a first network to a second network across an enhancer link, the method comprising:

0005determining the data flow rate in the second network;

0006feeding the determined data flow rate back to the first network; and

0007adjusting the data flow rate over the enhancer link in accordance with the determined data flow rate.

0008Preferably, the enhancer link comprises at least one connection splitting node. In a preferred embodiment of the present invention, the. enhancer link comprises first and second connection splitting nodes, each node being associated with a respective one of the first and second networks.

0009Advantageously, the second connection splitting node includes a buffer for storing data during transfer to the second network.

0010The data flow from the first network to the second network may comprise a controlled IP flow. The step of adjusting the data flow rate at the enhancer link in accordance with the determined data flow rate comprises throttling the data flow rate from the first network so that it substantially matches the data flow rate of the second network.

0011This invention introduces various equations which may be used to determine the data flow rate over a controlled IP flow. These equations determine an output flow rate for the enhancer link in accordance with the round trip time of the second network and the amount of data in transit at any one time.

0012Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0013<figref idref="DRAWINGS">FIG. 1</figref> illustrates a conventional geostationary satellite internet connection;

0014<figref idref="DRAWINGS">FIG. 2</figref> illustrates a geostationary satellite internet connection in accordance with the present invention; and

0015<figref idref="DRAWINGS">FIG. 3</figref> illustrates a remote section of the network shown in <figref idref="DRAWINGS">FIG. 2</figref>.

DETAILED DESCRIPTION OF THE DRAWINGS

0016A connection splitting technique has been investigated to improve the performance of TCP/IP connections over long-latency links—specifically geostationary satellites with an end-to-end latency of typically 280 ms have been considered. This has shown that buffer management is an important area to address. The reason for this is that the long round trip time (RTT) means there is a substantial delay before the sender can receive any information about the status of the other end of a flow.

0017The present invention will be described with reference to controlled IP flows, e.g. TCP, RTCP and RTP flows.

0018<figref idref="DRAWINGS">FIG. 1</figref> shows a satellite internet flow 10 in which a local network 20 is connected to a remote network 30 via a geostationary satellite 40. The local network 20 includes a sending host 22 connected to a node 24 via link 26. The remote network 30 includes a receiving host 32 connected to the internet 34 via a link 36 and is connected to a node 42 via a link 44. As shown, the local network 20 is connected to the satellite 40 via node 24 and link 46. Similarly, the remote network 30 is connected to the satellite 40 via node 42 and links 44, 48. Operation of the flow 10 will now be described with respect to the local network 20 sending or transmitting to the remote network 30.

0019In <figref idref="DRAWINGS">FIG. 1</figref>, the sending host 22 is capable of transferring data over a local area network (LAN) (not shown) at speeds of up to 100 Mbit/s to the node 24 which performs connection splitting. As shown, node 24 and node 42 are connected by a satellite link 40, 46, 48 which typically handles data at a speed of 8 Mbit/s and has a typical RTT of 580 ms. When node 24 receives data from the sending host 22, it will automatically restrict the average send rate to that of the satellite link, that is, 8 Mbit/s.

0020It will readily be appreciated that node 24 effects connection splitting, that is, node 24 allows incoming data to be transmitted at a different rate.

0021However, the receiving host 32 in the remote network 30 receives data from the internet 34 via a modem (not shown), and can only accept data at a speed or rate of 56 kbit/s. If the sending host 22 tried to send gigabytes of data to the receiving host 32, it would rapidly be able to flood the flow buffer (not shown) on node 42, stalling the link. Again, node 42 effects connection splitting. It will be appreciated that the fixed link rates given above are by way of example only and that the link rate can be chosen to be any suitable value. Moreover, it is also possible to use a link rate which changes over the lifetime of the connection, for example, due to changes in the network capacity because of other intermittent traffic.

0022To avoid this, the node 24 in the local network 20 needs to control the sending rate of any given flow, based on the rate at which the receiving host 42 is accepting the data. This introduces two problems:—first, how to make an accurate enough assessment of the host data transfer capacity in the remote network 30 and, secondly, how to apply this effectively, given the long round-trip time. A flow which overcomes these problems in accordance with the present invention is shown in <figref idref="DRAWINGS">FIG. 2</figref>.

0023<figref idref="DRAWINGS">FIG. 2</figref> is similar to <figref idref="DRAWINGS">FIG. 1</figref> and identical components which have previously been described are referenced alike. Components which are similar have been given the same reference numerals but with a ‘1’ in front (for example, 120 is similar to 20).

0024A satellite flow 100 is shown in <figref idref="DRAWINGS">FIG. 2</figref> in which a local network 120 is connected to a remote network 30 via a satellite 40. Local network 120 comprises a sending host 22 connected to a node 124 via a link 26. Node 124 includes a throttling unit 150 which enables incoming data from the sending host 22 to be slowed down to accommodate changes in rates in the flow 100. The remote network 30 comprises a receiving host 32 connected to the internet 34 via link 36, the internet 34 being connected to a node 142 via link 44. Node 142 contains a buffer 152 for storing data arriving from the sending host 22 via satellite flow 40, 46, 48, as described above with reference to <figref idref="DRAWINGS">FIG. 1</figref>, prior to sending it into the internet 34. As before, nodes 124 and 142 are connection splitting nodes.

0025<figref idref="DRAWINGS">FIG. 2</figref> considers a single flow from sending host 22 to receiving host 32 across the pair of connection splitting nodes 124 and 142. Here, the current data output rate from node 124 into the satellite link 40, 46, 48 can be expressed as Ro, the current data output rate from node 142 into the internet 34 can be expressed as Ri, and T as a ‘throttling’ value associated with the throttling unit 150 at node 124.

0026In accordance with the present invention, a throttling algorithm is utilised which allows the value of the parameter ‘T’ to be determined within node 124. ‘T’ is a throttling parameter, which is used to throttle (or slow) the traffic passing through it and hence it throttles data traffic which it receives from the sending host 22. The resulting traffic flow out of node 124 into the satellite link 40, 46, 48 is then matched to that of the remote network at node 142.

0027The throttling algorithm uses flow rate statistics from node 142. Every set of data statistics received in a reverse traffic ‘feedback’ frame can be regarded as a delayed snapshot of the flow rate in node 142. For a geostationary satellite link with a typical latency of 280 ms, it is useful to configure the system, so that these ‘snapshots’ typically arrive every 140 ms, that is, at half the link latency.

0028It is useful to introduce the concept of a “data sample” at this point. This is the amount of data flowing through the node 142 for a single flow over the course of the sampling period, for example, 140 ms.

0029Hence, for a 56 kbit/s link, the data sample equates to:

003057344×0.140=8028 bits, that is, approximately 1 kbyte.

0031The number of data samples stored in the buffer 152 at node 142 gives an indication of how long that flow will take to drain the buffer 152 assuming no more data is input. This number is referred to as the session buffer volume (SBV).

0032As described above, the nodes 124 and 142 are connection splitting nodes and need to cooperate with one another if the flow 100 is to have at an optimum performance.

0033As the SBV becomes large, it becomes less important for node 124 to continue to send data at the network output flow rate. In addition, it indicates that the buffer 152 is being overused for that session. The throttling unit 150 in node 124 must therefore throttle the flow back to allow the buffer 152 at node 142 to drain.

0034The SBV measurement is not enough to ensure that the buffer 152 at the node 142 is not overrun. The spare capacity of the buffer 152 in node 142 for all TCP sessions must also be accounted for and this is given by the receiver buffer ratio (RBR).

0035The data that node 124 requires from node 142 can be summarised as: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0036">The SBV for each flow</li><li id="ul0002-0002" num="0037">The ratio of the overall buffer size to its current capacity, that is, the RBR</li></ul></li></ul>

0038The throttling algorithm within the throttling unit 150 of node 124 attempts to match the output rate Ro to that of the output rate Ri of node 142 into the internet 34. This limits the amount of data flowing into node 142 so that its buffer 152 do not overfill.

0039Realising that the measured value of Ri at node 142 is always out of date by 280 ms, that is, by two ‘snapshot’ periods, the throttling value T needs to be determined in accordance with: Ro=TRi (1)

0040Considering the earlier definition of SBV, the following conditions apply:

0041when <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0042">SBV=0 T=1.0</li><li id="ul0004-0002" num="0043">SBV=n T→0.0 as n→∞</li></ul></li></ul>

0044Hence, from equation (1): T=1/(1+SBV) (2)

0045or generally for a specific flow ‘s’ Ts=1/(1+SBVs) (3)

0046Equation (3) is a suitable equation for the data flow aspect of the throttling value T held in throttling unit 150 of node 124.

0047Additionally, to avoid overflow of buffer 152 of node 142, the overall spare capacity of buffer 152 needs to be considered as determined by RBR.

0048The following conditions apply:

0049when <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0050">RBR=0 Tb=0.0</li><li id="ul0006-0002" num="0051">RBR=n Tb→1.0 as n→∞</li></ul></li></ul>

0052Hence: Tb=1−1/(1+RBR) (4)

0053Equation (4) is a suitable equation for the buffering aspect of the throttling value T.

0054In this case, equation (4) applies for the whole system regardless of the number of active sessions.

0055In addition to the above, the algorithm also requires a forcing factor P. This is required to push a small amount of extra data than that indicated by the flow rates of the node 142 across the satellite link 40, 46, 48. If this factor is not included, the send rate from node 124 will converge to the output rate from node 142, and the utilisation of the buffer 152 in node 142 will be zero. If the connection from node 142 to receiving host 32 increases in capacity at this point, node 142 will have no spare data to output and will not be able to detect the extra capacity.

0056A suitable value for the forcing factor is around 105% (1.05). Higher values have been shown to introduce oscillation in the usage of the buffer 152 on node 142 even with a constant flow rate between node 142 and receiving host 32.

0057Hence, the complete formulae for the throttling factor for any flow ‘s’ is given by: T=PTbTS (5) T=P(1−1/(1+RBR))(1/(1+SBVs)) (6)

0058The value thus obtained, T for a session s, is a value between 0 and 1, representing the fraction of the measured flow rate from node 142 to receiving host 32 that should be permitted across the satellite link 40, 46, 48. Any suitable rate control mechanism, for example, a token leaky bucket scheme, can be used to apply the rate control.

0059The above paragraph explains how node 124 calculates a link rate for a connection from information fed back from node 142—but this still requires that node 142 can supply this information correctly. The buffer data is simple—given a pool of buffers the RBR is simply the fraction of free buffers.

0060However, to correctly determine the value of each SBV, node 142 needs to supply a rate for data transfer between itself and the receiving host 32. This has to be a comparatively accurate instantaneous measurement. It cannot be of the form “20 kbyte transferred with connection duration of 10 s=2 kbyte/s” as this does not indicate the achievable output rate.

0061<figref idref="DRAWINGS">FIG. 3</figref> is a more detailed view of the remote network 30 shown in <figref idref="DRAWINGS">FIG. 2</figref>. As identical reference numerals have been used for the same components, no further description is given.

0062In <figref idref="DRAWINGS">FIG. 3</figref>, there is a TCP stack (as an example protocol using a controlled IP flow) within node 142 which is responsible for regenerating the original connection to the receiving host 32. It is within this stack that the rate determination is made. This hinges on two key measurements namely, the round-trip time between node 142 and receiving host 32, and the amount of data in transit.

0063The following procedure is used to determine the RTT of the remote network 30:

0064TCP outputs a segment and if the cycle timer is not active, a timer is started. This starts the measurement process.

0065The following cycle then repeats: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0066">When an acknowledgement is received for the segment being timed, the amount of data in transit is calculated (as the unacknowledged data that has been since the just acknowledged segment). The throughput is calculated based on the cycle time and the quantity of data in transit. At the end of the cycle the timer is restarted. This means that idle time is counted as well as data transfer time and thus avoids calculating the peak rate. However, in order to estimate the achievable throughput, a cycle is not counted unless at least one full size segment of data is transferred. Additionally, the cycle time is smoothed over the last two measured times, so long idle periods have less effect. Should a retransmission occur, the timer is cancelled and will be restarted at the end of the cycle by the first rule for starting the timer.</li></ul></li></ul>

0067It will be appreciated that any other suitable process can be used to determine the RTT of the remote network.

0068The amount of data in transit, at any time, is known by the sliding window of the flow in the remote network 30, that is, between node 142 and sending host 32. Together with the RTT value determined above, the external data rate can be accurately measured.

0069The following method has been used to measure the output rate at the remote end of the link. The calculation is performed in parallel for each connection, and the following definitions apply:

0070TCP·SND_NXT is the sequence number of the next byte to be output by this TCP connection.

0071TCP·SND_UNA is the earliest unacknowledged byte for the TCP connection.

0072The difference between these two values, therefore, gives the quantity of data in transit at the point of measurement. This calculation should be performed before SND_UNA is updated with the value of the received acknowledgement.

0073Alpha and beta set, respectively, the lower and upper thresholds for reporting change in output rate. Without this, every cycle will cause an update which, if the value is comparatively stable, is unnecessary. Values of 0.95 for alpha and 1.1 for beta, for example, can be used to reduce the number of updates. Setting both to a value of 1 will cause the value to be updated for every change.

0074<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>IF</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="245pt" align="left" /><tbody valign="top"><row><entry /><entry>there is an outstanding segment to be timed AND</entry></row><row><entry /><entry>the received ack includes that segment THEN</entry></row><row><entry /><entry>elapsed_time = time_now − cycle_start_time</entry></row><row><entry /><entry>data_in_transit = TCP.SND_NXT − TCP.SND_UNA//see below</entry></row><row><entry /><entry>IF data_in_transit > max_segment_size THEN</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="231pt" align="left" /><tbody valign="top"><row><entry /><entry>Rate_rtt = (rate_rtt/2) + (elapsed_time/2)//smooth the</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="189pt" align="left" /><colspec colname="1" colwidth="70pt" align="left" /><tbody valign="top"><row><entry /><entry>measured</entry></row><row><entry /><entry>cycle time</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="231pt" align="left" /><tbody valign="top"><row><entry /><entry>Cycle_throughput = data_in_transit/rate_rtt</entry></row><row><entry /><entry>smoothed_throughput = (smoothed_throughput/2) + (cycle_throughput/2)</entry></row><row><entry /><entry>IF (smoothed_throughput < last_update * alpha) OR</entry></row><row><entry /><entry> (smoothed_throughput > last_update * beta) THEN</entry></row><row><entry /><entry>update rate with smoothed throughput</entry></row><row><entry /><entry>last_update + smoothed_throughput</entry></row><row><entry /><entry>END IF</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="245pt" align="left" /><tbody valign="top"><row><entry /><entry>END IF</entry></row><row><entry /><entry>cycle_start_time = time_now</entry></row><row><entry /><entry>clear outstanding segment to be timed</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="259pt" align="left" /><tbody valign="top"><row><entry>END IF</entry></row><row><entry>The foregoing diclosure has been set forth merely to illustrate the invention and is not</entry></row><row><entry>intended to be limiting. Since modifications of the disclosed embodiments</entry></row><row><entry>imcorporating the spirit and substance of the invention may occur to persons</entry></row><row><entry>skilled in the art, the invention should be construed to include everything</entry></row><row><entry>within the scope of the appended claims and equivalents thereof.</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0075The foregoing disclosure has been set forth merely to illustrate the invention and is not intended to be limiting. Since modifications of the disclosed embodiments incorporating the spirit and substance of the invention may occur to persons skilled in the art, the invention should be construed to include everything within the scope of the appended claims and equivalents thereof.

Contents4

Every citation, both ways

Citations
Document	Relation	Office	Cited during
US9195956B2	Cited by	United States of America	Applicant
US2009171969A1	Cited by	United States of America	Pre-grant
US9130846B1	Cited by	United States of America	Applicant
US9210177B1	Cited by	United States of America	Applicant
US8904031B2	Cited by	United States of America	Search report
US9967331B1	Cited by	United States of America	Applicant
US2009172025A1	Cited by	United States of America	Pre-grant
US8949470B2	Cited by	United States of America	Applicant
US9614772B1	Cited by	United States of America	Applicant
US9866627B2	Cited by	United States of America	Applicant
US9832069B1	Cited by	United States of America	Applicant
US8533308B1	Cited by	United States of America	Search report
US8418233B1	Cited by	United States of America	Applicant
WO0145332A1	Cites	World Intellectual Property Organization (WIPO)	Applicant
US5694390A	Cites	United States of America	Search report
US5748901A	Cites	United States of America	Search report
US5970048A	Cites	United States of America	Search report
US6097697A	Cites	United States of America	Search report
US6118834A	Cites	United States of America	Search report
US6233224B1	Cites	United States of America	Search report
US6438101B1	Cites	United States of America	Search report
US6654344B1	Cites	United States of America	Search report
WO9722196A1	Cites	World Intellectual Property Organization (WIPO)	Applicant
WO9922477A1	Cites	World Intellectual Property Organization (WIPO)	Applicant
WO9722196	Cites	World Intellectual Property Organization (WIPO)	Third party observation
WO9922477	Cites	World Intellectual Property Organization (WIPO)	Third party observation
WO0145332	Cites	World Intellectual Property Organization (WIPO)	Third party observation
Deepak Bansal, Anurag Chandra, Rajev Shorey, “An Extension of the TCP Flow Control Algorithm for Wireless Networks,” Feb. 17-19, 1999, pp. 207-210.	Non-patent	–	Search report
Brake, A.V.; Badrinath, B.R., “Implementation and Performance Evaluation of Indirect TCP,” Mar. 1997, pp. 260-278.	Non-patent	–	Search report
PCT International Search Report.	Non-patent	–	Third party observation
British Search Report.	Non-patent	–	Third party observation
Deepak Bansal, Anurag Chandra, Rajev Shorey, "An Extension of the TCP Flow Control Algorithm for Wireless Networks," Feb. 17-19, 1999, pp. 207-210.	Non-patent	–	Search report
Brake, A.V.; Badrinath, B.R., "Implementation and Performance Evaluation of Indirect TCP," Mar. 1997, pp. 260-278.	Non-patent	–	Search report
PCT International Search Report.	Non-patent	–	Applicant
British Search Report.	Non-patent	–	Applicant

10 members in 6 offices

This recordMember, by publication datePriority claim

Priority claims5

Priority claims
Document	Office	Kind	Date
99298770	United Kingdom	–	1999-12-18
9929877	United Kingdom	A	1999-12-18
00244673	United Kingdom	–	2000-10-06
0024467	United Kingdom	A	2000-10-06
0004785	United Kingdom	W	2000-12-14

Members10

Family members, oldest first
Document	Office	Kind
GB9929877D0	United Kingdom	D0	2000-02-09
GB0024467D0	United Kingdom	D0	2000-11-22
WO0145332A1	World Intellectual Property Organization (WIPO)	A1	2001-06-21
AU2196401A	Australia	A	2001-06-25
GB2360669A	United Kingdom	A	2001-09-26
EP1238496A1	European Patent Office (EPO)	A1	2002-09-11
US2003103466A1	United States of America	A1	2003-06-05
US7315513B2This record	United States of America	B2	2008-01-01
EP1238496B1	European Patent Office (EPO)	B1	2008-08-06
DE60039785D1	Germany	D1	2008-09-18

42 transactions on the USPTO file

Allowed after 1 non-final rejection.

Non-final rejections: 1
Final rejections: 0
RCEs: 0
Appeals: 0

Over time

Point at a mark for the transaction

Transactions

Prosecution transactions, newest first
	Event	Code
2012-01-30	Expire PatentEXP.	EXP.
2008-01-02	Recordation of Patent Grant MailedPGM/	PGM/
2008-01-01	Patent Issue Date Used in PTA CalculationAllowedPTAC	PTAC
2007-12-12	Issue Notification MailedAllowedWPIR	WPIR
2007-12-05	Dispatch to FDCD1935	D1935
2007-12-05	Application Is Considered Ready for IssuePILS	PILS
2007-12-05	Printer Rush- No mailingTCPB	TCPB
2007-10-25	Supplemental Papers - Oath or DeclarationC600	C600
2007-10-25	Miscellaneous Incoming LetterLET.	LET.
2007-09-19	Issue Fee Payment VerifiedN084	N084
2007-09-19	Issue Fee Payment ReceivedIFEE	IFEE
2007-07-09	Pubs Case Remand to TCPUBTC	PUBTC
2007-06-20	Correction - Drawing NOT RequiredX/DR	X/DR
2007-06-20	Mail Notice of AllowanceAllowedMN/=.	MN/=.
2007-06-20	Mail Formal Drawings RequiredMN/DR	MN/DR
2007-05-01	Formal Drawings RequiredN/DR	N/DR
2007-05-01	Notice of Allowance Data Verification CompletedAllowedN/=.	N/=.
2007-05-01	Case Docketed to Examiner in GAUDOCK	DOCK
2007-02-06	Date Forwarded to ExaminerFWDX	FWDX
2007-01-29	New or Additional Drawing FiledC614	C614
2007-01-29	Response after Non-Final ActionA...	A...
2007-01-03	Case Docketed to Examiner in GAUDOCK	DOCK
2006-10-27	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2006-10-27	Non-Final RejectionNon-final rejectionCTNF	CTNF
2006-09-20	Case Docketed to Examiner in GAUDOCK	DOCK
2006-08-24	Case Docketed to Examiner in GAUDOCK	DOCK
2006-05-24	Case Docketed to Examiner in GAUDOCK	DOCK
2006-04-24	Case Docketed to Examiner in GAUDOCK	DOCK
2006-03-21	Case Docketed to Examiner in GAUDOCK	DOCK
2004-11-19	IFW TSS Processing by Tech Center CompleteTSSCOMP	TSSCOMP
2004-11-19	Claims PTOCPTO	CPTO
2003-03-31	Case Docketed to Examiner in GAUDOCK	DOCK
2003-02-27	Application Dispatched from OIPEOIPE	OIPE
2003-02-25	IFW Scan & PACR Auto Security Review	–
2003-02-10	Notice of DO/EO Acceptance MailedM903	M903
2002-10-29	Reference capture on IDSRCAP	RCAP
2002-06-17	Information Disclosure Statement consideredIDSC	IDSC
2002-06-17	Information Disclosure Statement (IDS) Filed	–
2002-06-17	Information Disclosure Statement (IDS) Filed	–
2002-06-17	Request for Foreign Priority (Priority Papers May Be Included)RQPR	RQPR
2002-06-17	Preliminary AmendmentA.PE	A.PE
2002-06-17	Initial Exam Team nnIEXX	IEXX

5 legal events, as the office reported them to INPADOC

Over the term

Point at a mark for the event

Events

Legal events, newest first
	Event	Code
2012-02-21	Lapsed due to failure to pay maintenance feeLapsedFP	FP
2012-01-30	Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH	STCH
2012-01-01	Lapse for failure to pay maintenance feesLapsedLAPS	LAPS
2011-08-08	Maintenance fee reminder mailedREMI	REMI
2002-10-29	AssignmentAS	AS