|Publication number||US5778057 A|
|Application number||US 08/599,573|
|Publication date||Jul 7, 1998|
|Filing date||Feb 9, 1996|
|Priority date||Feb 9, 1996|
|Also published as||CA2254135A1, CA2254135C, EP0904652A1, WO1997029579A1|
|Publication number||08599573, 599573, US 5778057 A, US 5778057A, US-A-5778057, US5778057 A, US5778057A|
|Original Assignee||Bell Communications Research, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (4), Non-Patent Citations (2), Referenced by (33), Classifications (19), Legal Events (14)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of Invention
The present invention relates to congestion control of telephone traffic in a signalling network, and more particularly, to a method of managing congestion caused by a sudden increase in the volume of traffic to a single telephone number.
2. Discussion of Related Art
A sudden increase in the volume of traffic to a single telephone number of Service Control Point (SCP) service numbers, such as 800 numbers, is typically caused by media-stimulated mass calling events. These events are usually initiated by announcements on TV or radio asking viewers to call a single number to register a vote, to buy a ticket, or to win a prize, for example. Although, there are several congestion control methods in existence that can be invoked to remedy the situation, they cause other calls which are not directed to the single congested number to be either throttled or discarded in the network.
For example, there is a congestion control procedure in the Signaling System 7 (SS7) protocol called Transfer Controlled (TFC). This procedure is invoked when certain thresholds on the signalling link transmit buffer are exceeded. However, the TFC as a Message Transfer Part (MTP)3 layer procedure is mainly designed to protect the links during congestion. The overflow traffic messages are throttled or discarded based on their priority and the level of congestion in the signaling link transmit buffers. When TFC is invoked, signalling messages are controlled without any explicit relationship to a particular dialed number or specific service. In other words all messages belonging to all calls and services that share the congested link are subject to control.
Another well known congestion control method, which is termed Automatic Code Gapping (ACG), operates between Service Switching Points (SSP), of the network, and SCP. The ACG procedure is invoked based on certain measurements in the SCP. Depending on the level of overload in the SCP, a gap interval and duration is transmitted to the SSP. This reduces the number of calls to a plurality of numbers on a Numbering Plan Area (NPA) code or, where N is any digit from 2 to 9 and X is any digit from 0 to 9, on an (NPA-NXX) basis.
The ACG generally protects the SCP from congestion, but situations arise where the overloading of a single number can render the ACG ineffective. For example, a mass calling event was widely advertised in one local Access Transport Area (LATA) and all calls were routed to a single 800 number that had only a few operators answering the calls. Four links in the D-link Quad (one link in each link set) connected the Local Signal Transfer Points (LSTP) to the Regional Signal Transfer Points (RSTP). Thus, the D-link quad connecting the LATA, which was originating the calls, had a capacity of about 280 queries per second using 100 octets for the size of each query message. The capacity of the SCP was about 450 queries per second. Since the D-link quad had a smaller capacity than the SCP, the D-link quad became congested while the SCP still had sufficient capacity. This resulted in the Transfer Controlled procedure being invoked on the D-link quad, which in turn dropped several calls to all of the 800 numbers and any other messages that shared the D-link quad.
The known procedures for handling large amounts of traffic to a single number, such as choke networks, and the SCP capability of associating a number of lines with a particular number require advance notice to the phone company in order to be effective. Unfortunately, subscribers do not always provide such notice, nor do they advise the company of the number of operators that are to be assigned to a particular number.
In light of the foregoing, there is a need for a method of managing overload events directed to a single telephone number that does not require notifying the phone company in advance of the anticipated overloading or the number of operators that will be available to handle such calls, and also does not adversely affect calls to other numbers of the particular service.
Accordingly, the present invention is directed to a method of managing a sudden increase in traffic to a single telephone number that substantially obviates one or more of the problems due to limitations and disadvantages of the related art.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and obtained by the apparatus and method particularly pointed out in the written description and claims hereof as well as the appended drawings.
To achieve these and other advantages, and in accordance with the purpose of the invention, as embodied and broadly described, the invention is a method of managing overload events directed to a single subscriber telephone number n which includes the steps of sampling SCP calls for a fraction of all queries during successive measurement intervals, processing Termination Notification (TN) messages received during each current successive measurement interval (T), determining an amount of overloading of a telephone number n following each measurement interval in accordance with a processed TN message, and invoking ACG on the number n at times when the determined amount of overloading is excessive.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.
The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate the embodiment of the invention, and together with a description serve to explain the principles of the invention.
FIG. 1 is a flow chart illustrating the steps in one embodiment of the method of the present invention; and
FIG. 2 illustrates a network configuration that incorporates the teachings of the present invention.
In describing the preferred embodiments, reference is made to the drawings wherein like reference numerals refer to like parts to the extent possible.
In accordance with the present invention, the method of managing overload events directed to a single subscriber telephone number n, comprises the step of sampling SCP calls for all queries received at SCP during successive measurement intervals.
As herein embodied and referring to FIG. 1, initially the well-known SCP-based call sampling procedure is enabled for sampling calls during selected measurement intervals as indicated at step 10. Such measurement interval can be any interval of time that will provide meaningful information concerning the activity of a particular number, such as ten seconds, for example.
SCP-based call sampling, which permits the local phone company to obtain information on how the calls for a particular subscriber are being completed, operates as follows. The SCP, after receiving a query message from a SSP, can respond to that message by requesting the SSP to send a Termination Notification message to the SCP reporting the status of the sampled call. The TN message includes information about each call mainly for billing and maintenance purposes. Specifically, the TN message includes information as to the duration of a completed call, and whether or not a particular call was answered, received a busy signal, or was lost. For the purposes of the present invention, instead of using the SCP call sampling on request per customer, the method of the present invention requires that SCP be enabled, for 1 of all the queries, for example, and remain enabled for the duration of the corresponding measurement interval.
In accordance with the present invention, the method includes processing the received TN messages during each current successive measurement interval. As herein embodied, and as indicated generally at 12 of FIG. 1, the method includes assigning the called number contained in the incoming query to the Echo Data field of the response message, then calculating the number of busy calls Bn, the number of answered calls An, the number of no-answer calls Gn, and the number of erroneous (lost) calls En associated with a telephone number n occurring during the measurement interval T as indicated at step 13.
The foregoing parameters are obtained from the SSP as follows: The call processing record in the SCP requires that the response from the SCP may request the SSP to send termination information about a call. The termination information will contain a 6-octet echo data field. The SSP associates the number in this echo data field with the call so that it may be included in a termination message returned to the SCP when the call terminates. However, the Private Virtual Network (PVN) requirements do not specify what should be put in the echo data field. Well known SCPs currently use an Automatic Message Accounting (AMA) related index instead of the called number in the echo data field. The dialed number is then determined by a translation of the AMA index. The TN message also includes Network Management Control list overflow indication, answer indication, connect time, and error indication. For the error indication, PVN requires five different types of error conditions, namely, (1) caller abandoned before receipt of the response message, (2) SSP timer expiration, (3) SSP failure, (4) bad data in response message, and (5) protocol error in TCAP portion of the response message. Thus, the parameter En in the present invention refers to the sum of the above listed errors.
In accordance with the present invention the method includes the step of determining the amount of overloading of a telephone number n following each measurement interval in accordance with a processed TN message. As herein embodied, and as indicated in step 14 of FIG. 1, at the end of the current measurement interval, the percentage of the total calls to the number n occurring during the measurement interval that received a busy signal or were not included because of errors, referred to herein as fBn, is calculated as follows: ##EQU1## The value En is included in this definition because during congestion some of the calls may not be successfully completed. Therefore, a high value of fBn would indicate a possible congestion and the fact that the operators are exhausted.
Also, at the end of the current measurement interval, the estimated rate of attempted calls to the number n during the measurement level, referred to herein as Rn is calculated as follows: ##EQU2## where fs is the percentage of all transactions to an SCP that are requested to send a TN message and where T denotes the length of SCP measurement interval in seconds during which Termination Notification messages are collected and processed. The term fs is greater than zero and less than or equal to one.
The invention includes creating a ranked order list of numbers with the highest incoming rate as indicated at step 15.
In accordance with the present invention, the method includes invoking automatic code gapping on the number n at times when the determined amount of overloading is excessive. As embodied herein, and as illustrated in step 16 of FIG. 1, the value Rn is compared to a threshold value O1 and value fBn is compared to a threshold value O2. Preferably, the method should first compare Rn to the threshold O1, and if Rn is greater than O1, then the value fBn is compared to the threshold O2. If fBn exceeds this threshold, then automatic code gapping (ACG) is invoked.
A more detailed description of the operation of a typical network will be given in connection with FIG. 2. An example of the operation of the network without the benefit of the present invention is first described, which description is followed by an example with the benefit of the present invention.
Assuming a single 800 number 1-800-555-1111 is advertised in LATA A defined by arrow 20. The 1-800-555-1111 calls are translated in SCPs 22 and 23, and then routed to a location in a different LATA Z defined by arrow 24. Suppose the capacity of single SCP 22 is 450 queries per second. Assume that there is only one link in D-link set 26, and a total of 4 links in a D-link quad 28 connecting LSTP pair 30 and 32 to RSTP pair 34 and 36, which is a common sizing. Using 100 octet for the size of a query message, the capacity of a single D-link is simply 70 queries per second. Thus, the D-quad 28 consisting of 4 links will have a capacity of 4×70 or 280 queries per second.
Suppose the Service Control Point (SCP) load prior to the media event was at 40 percent of its capacity, 0.4×450=180 or about 200 queries per second. Also suppose that the media event adds a sudden additional 100 queries per second to the load of a single SCP 22, which provides a total of 200 new queries to the mated SCP 23. Thus, the total new load on a single SCP is now 300 queries per second which consists of the 200 queries of background traffic and an additional 100 queries per second of new traffic focused on a single telephone number. However, the total load of 300 is still below the SCP capacity of 450. Thus SCP 22 or 23 is not overloaded, and the ACG procedure will not be invoked.
However, the 200 queries per sec of new traffic, which is carried over the D-quad 28 to both mated SCPs 22 and 23 plus the base load that existed on the D-links (0.4×70×4=112), is sufficient to drive the D-link quad 28 of LATA A into overload; the base load is the existing traffic load on the D-links associated with normal traffic before the start of the additional traffic that will be generated due to a focused overload event. This will cause the TFC procedure to be invoked which will request switches not to send messages of certain priority depending on the congestion level in the transmit links of the D-quad. During this time, switches will throttle those messages destined to use the D-quad regardless of whether they belong to the 1-800-555-1111 or any other service. The above example, taken from a real event, clearly illustrates that it is possible for the SCP 22 or 23 not to be congested while another segment of the network is congested, such as the D-quad. The irony is that the call level control method that could have helped effectively, namely ACG, would not be invoked unless the event was a priori known by network managers before hand, such that a very low threshold was put on the specific number.
Note that adding another link to the link sets in D-quad 28 does not necessarily solve the problem, but shifts the overload to another segment of the network. If the D-link sets had two links, each resulting in a capacity of 560 queries per second, then, depending on the amount of new load, either SCP 22,23, or the quad 28 connecting LATA A to the IC, or more likely the Alless-links 30 connecting the target switch, shown as SSP 40 in FIG. 2 to the LSTP 30, would get congested depending on the number of voice trunks available.
Now, a description of the operation will be given where the network includes the present invention. With 1% call sampling enabled, the SCP 22, 23 prior to a media event would have received on average of 0.01×200=2 TN messages per second. Using a measurement interval of 30 seconds as an example, there would be 60 TN messages available during a measurement interval. Using the rule that usually 70 percent of calls are answered, one would not have more than a few busy calls to a given number. Therefore, busy counts associated with any number will not be enough to exceed the threshold O2, and ACG will not be invoked. After the media event, SCP will receive 0.01×300 =3 TN messages per second or a total of 90 TN messages during the measurement interval. Statistically, 1/3 of these 90 TN messages, or 30 TN, will belong to the 1-800-555-1111 number. Now if a high percentage, such as 28 out of 30 of these TN messages have a busy status, then one can reasonably conclude that approximately 28 to 30 percent of 100 queries per second are going to be busy. The percent busy for the 1-800-555-1111 will now exceed the threshold of O2 =0.95, and ACG will be invoked on that 10-digit number.
It is possible to wait for an average call holding time and then examine the number of TN messages and, depending on the value of busy counts and rate, either use a larger gap or remove the gap (or have it increase or decrease on a percentage basis). Preferably, the step of processing includes a substep of constructing a table at the SCP for each measurement interval. As herein embodied, a table similar to Table 2-1 is preferably created and maintained in the SCP for the number contained in the TN messages for each measurement interval.
TABLE 2-1______________________________________Number Bn An Gn En fBn Rn______________________________________1-800-555-1111 18 2 0 9 0.93 2901-800-555-2222 3 1 1 1 0.67 601-800-555-3333 2 3 0 0 0.4 501-800-555-4444 5 19 3 5 0.31 320______________________________________
Suppose as an example, there are 4 numbers contained in the samples. The SCP will then compute fBn and Rn for each number n=1,2,3,4. First a test or calculation 1 is performed with 01 =200. The numbers passing test 1 are 1-800-555-1111 and 1-800-555-4444. Next test 2 is performed with 02 =0.90. The only number satisfying test 2 is 1-800-555-1111. Thus, a 10-digit ACG can be invoked on 1-800-555-1111. Based on thresholding of this list, a gap can be put on a specific number, and this information can be sent to SSPs to control the rate of calls that can be originated to that number. The control levels can increase or decrease by first choosing a certain gap level, and then monitoring the number of busy calls and the rate received during the next measurement interval. If the count of busy calls received and rate for the number is still high, a larger gap interval can be set and the process can be repeated until the proper gap is found.
The numbers with both Rn >01 and fB >02 are selected for call gapping. At this time, network managers should be notified by proper alarms or displays. Note that this method does not disable or replace the regular ACG procedure that exists in the SCP. If SCP receives a high rate of queries, regardless of which number and call status, ACG procedure is invoked to protect the SCP for overload. After this ACG is invoked on number n abatement threshold A1 for the call attempt rate, is used to remove the ACG. Only if Rn <A1 is ACG removed. One can also place an abatement threshold on percent busy. However, doing that implies that the network will not be able to use operators to their maximum. Having only an abatement threshold for rate means that as long as the volume of the calls are below a certain threshold, the control will be removed regardless of the status of calls. The gap value and duration, and A1 can be set by network manager. A guideline for setting the abatement threshold is to select A1 such that A1 <<min(CD - quad' CIC). CD -quad denotes the capacity of the smallest D-quad connecting and LSTP pair to the regional RSTP. CIC denotes the capacity of the smallest IC quad connecting on LSTP to an ICSTP pair.
It is possible to include the following optional test 0 before test 1 and test 2. Test 0: if Rn >min(CD - quad' CIC) is true, then perform test 1 and test 2. Test 0 is intended to make sure that if the load presented to SCP is less that the minimum of other resources in the network, no control actions are taken. Performing test 0 implies that if the network has capacity to process calls, even if these calls are going to be busy, there will not be any control put on these calls. Controls are invoked only if the volume of calls is greater than the capacity of a network segment. As described previously, this situation will start affecting other calls, un-related to the number.
The concept of percent busy and high call attempt rate estimated and obtained using the methods and algorithms presented herein can also be used as a decision node in the service logic of a customer in the AIN SCP. If the calls to a particular destination are receiving very high busy treatments, alternate locations may be specified in the service logic for routing the calls. Basically, a dynamic call distribution logic can be created where the network routes the calls to multiple locations based on volatility of traffic and availability of operators in different sites. This feature would be useful for customers which have pools of operators at different sites, and the traffic demand may vary quickly based on some advertisement on TV (e.g., Home Shopping network).
In sum, the method of the present invention is advantageous in that it does not require expensive software changes to the SSPs. The SSP is only required to return a TN message with an index called ED that SCP assigns via the response message from SCP to SSP. The SSP then just inserts this index in the TN message and sends it back to SCP with other information relating to the call. This procedure is already part of 800, PVN, and AIN requirements. In this invention, the SCP must assign the called number contained in the Query message in the ED field.
This method requires that call sampling be active at all times. However, the percentage of call sampling can be set to very low values, e.g., 1%. This will only add one message for every 100 query response pair. The advantage of using call sampling is that it is already part of the requirements for 800, PVN, and AIN, and should be already implemented by SSPs. The other advantage is that the information is collected from all SSPs in a very convenient form through the SS7 network as opposed to using an external link monitoring system that must be present on many links. In addition, the percentage of sampling could be easily adjusted by network administrators via Service Management System (SMS).
By sampling the calls, SCP only has to examine a rather small number of TN messages in order to determine that a focused overload condition exists. Thereby, having a smaller impact on processor real-time capacity. The product of fs ×T determines the number of available samples where T as noted before denotes the length of SCP measurement interval in seconds during which Termination Notification messages are collected and processed. Both fs and T can be used to adjust the control. For example, by shortening T and increasing fs, one can increase the quickness of the number detection algorithm. And similarly by having a longer T one can improve the reliability of the decision process by collecting more samples over a longer time period.
The method inherently indicates that the local telephone companies do not need to know how many operators or physical lines are behind a given number. Apparently, service providers do not like to always share this information with the local company. The method of the present invention estimates that operators are exhausted based on the count of busy treatment via the TN message.
The procedure attempts to protect the network from overload and not just the SCP or the links. The procedure is fair because it controls the calls that are causing congestion, and more importantly it controls the calls when the majority of them are going to busy. It uses existing SS7 standardized TN format. It re-uses the existing SCP and SSP ACG capability.
While a certain preferred embodiment of the invention has been illustrated and described, it is understood that the invention is not limited to but may be variously embodied and practiced within the scope of the following claims and their equivalents.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4224479 *||Feb 21, 1979||Sep 23, 1980||Bell Telephone Laboratories, Incorporated||Method of controlling call traffic in a communication switching system|
|US5524145 *||Apr 6, 1995||Jun 4, 1996||Bell Atlantic Network Services, Inc.||Incoming call completion threshold restriction|
|US5570410 *||Oct 13, 1994||Oct 29, 1996||Bellsouth Corporation||Dynamic resource allocation process for a service control point in an advanced intelligent network system|
|US5581610 *||Oct 19, 1994||Dec 3, 1996||Bellsouth Corporation||Method for network traffic regulation and management at a mediated access service control point in an open advanced intelligent network environment|
|1||IEEE/ACM Transactions on Networking, vol. 3, No. 5, Oct. 1995, by "Donald E. Smith", Ensuring Robust Call Throughput and Fairness for SCP Overload Controls, pp. 538-548.|
|2||*||IEEE/ACM Transactions on Networking, vol. 3, No. 5, Oct. 1995, by Donald E. Smith , Ensuring Robust Call Throughput and Fairness for SCP Overload Controls, pp. 538 548.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US5923742 *||Feb 14, 1997||Jul 13, 1999||At&T Grp.||System and method for detecting mass addressing events|
|US5949865 *||Aug 18, 1997||Sep 7, 1999||Ericsson Inc.||Management of calling name delivery in telephone networks providing for telephone number portability|
|US6018519 *||Nov 10, 1995||Jan 25, 2000||Nokia Telecommunications Oy||Overload prevention in a telecommunications network node|
|US6160875 *||Sep 14, 1998||Dec 12, 2000||Lg Information & Communications, Ltd.||Method of managing overload of message in the communication system|
|US6252950 *||Sep 30, 1998||Jun 26, 2001||Lucent Technologies Inc.||Predictive bursty real-time traffic control for telecommunications switching systems|
|US6266402 *||Apr 27, 1998||Jul 24, 2001||Alcatel Usa Sourcing, L.P.||Apparatus and method for detecting focused overload|
|US6275572 *||Oct 13, 1998||Aug 14, 2001||Fujitsu Limited||Congestion control method and system in an exchange|
|US6317601 *||Dec 4, 1998||Nov 13, 2001||Lucent Technologies Inc.||Automatic code gapping (ACG) for wireless systems|
|US6330313 *||Jan 14, 1998||Dec 11, 2001||British Telecommunications Public Limited Company||Communications network|
|US6351525 *||Sep 22, 1998||Feb 26, 2002||Telefonaktiebolaget L M Ericsson (Publ)||Method and apparatus for conservation of switching exchange resources|
|US6453028 *||Feb 28, 2000||Sep 17, 2002||Lucent Technologies Inc.||Dynamic traffic management in an intelligent network of a telephone system|
|US6473402 *||Mar 11, 1997||Oct 29, 2002||Nortel Networks Limited||Communications link interconnecting service control points of a load sharing group for traffic management control|
|US6603851 *||Aug 5, 1999||Aug 5, 2003||Sprint Communications Company, L.P.||Telecommunications service control point with code blocking|
|US6741694||Apr 15, 2003||May 25, 2004||Sprint Communications Company L.P.||Telecommunications service control point with code blocking|
|US6996225 *||Jan 31, 2002||Feb 7, 2006||Cisco Technology, Inc.||Arrangement for controlling congestion in an SS7 signaling node based on packet classification|
|US7130402 *||Jan 23, 2003||Oct 31, 2006||Ntt Docomo, Inc.||Communication request processing system communication request processing method communication request processing apparatus|
|US7200408 *||Dec 15, 1999||Apr 3, 2007||Lucent Technologies Inc.||Selective blocking in a communication network|
|US7366292 *||Nov 2, 2001||Apr 29, 2008||At&T Knowledge Ventures, L.P.||Call management reports|
|US7453803 *||Nov 30, 2004||Nov 18, 2008||Sprint Communications Company L.P.||Congestion control for packet communications|
|US7756034 *||Nov 29, 2005||Jul 13, 2010||Cisco Technology, Inc.||System and method for handling network overload|
|US7760639 *||Nov 29, 2005||Jul 20, 2010||Cisco Technology, Inc.||System and method for handling network overload|
|US8014510||Nov 29, 2005||Sep 6, 2011||Cisco Technology, Inc.||Arrangement for controlling congestion in an SS7 signaling node based on packet classification|
|US8059799 *||Aug 16, 2007||Nov 15, 2011||Sprint Communications Company L.P.||Algorithm to make optimal use of network resources during a mass calling event|
|US8315245 *||Sep 21, 2005||Nov 20, 2012||At&T Intellectual Property I, L.P.||Overload call control in a VoIP network|
|US20030086552 *||Nov 2, 2001||May 8, 2003||Sbc. Technology Resources, Inc||Call management reports|
|US20030152206 *||Jan 23, 2003||Aug 14, 2003||Ntt Docomo, Inc||Communication request processing system communication request processing method communictaion request processing apparatus|
|US20060078008 *||Nov 29, 2005||Apr 13, 2006||Bordonaro Frank G||Arrangement for controlling congestion in an SS7 signaling node based on packet classification|
|US20060187841 *||Feb 24, 2005||Aug 24, 2006||Tekelec||Methods, systems, and computer program products for suppressing congestion control at a signaling system 7 network node|
|US20070070989 *||Sep 21, 2005||Mar 29, 2007||Savoor Raghvendra G||Overload call control in a VOIP network|
|US20070121502 *||Nov 29, 2005||May 31, 2007||Cisco Technology, Inc.||System and method for handling network overload|
|US20070121515 *||Nov 29, 2005||May 31, 2007||Cisco Technology, Inc.||System and method for handling network overload|
|US20080152119 *||Mar 11, 2008||Jun 26, 2008||At&T Knowledge Ventures, L.P.||Call management reports|
|WO2007064422A2 *||Oct 19, 2006||Jun 7, 2007||Cisco Tech Inc||System and method for handling network overload|
|U.S. Classification||379/221.08, 379/111, 379/134, 379/221.06, 379/196|
|International Classification||H04M7/00, H04Q3/66, H04M3/36, H04Q3/00|
|Cooperative Classification||H04Q2213/13563, H04Q3/0029, H04Q2213/13528, H04M3/36, H04Q2213/13561, H04Q3/66, H04M7/00|
|European Classification||H04Q3/66, H04M3/36, H04Q3/00D3|
|Feb 9, 1996||AS||Assignment|
Owner name: BELL COMMUNICATIONS RESEARCH, INC., NEW JERSEY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ATAI, AMIR;REEL/FRAME:008695/0554
Effective date: 19960208
|Oct 4, 1999||AS||Assignment|
|Jan 4, 2002||FPAY||Fee payment|
Year of fee payment: 4
|Jan 30, 2002||REMI||Maintenance fee reminder mailed|
|Apr 5, 2005||AS||Assignment|
|Dec 15, 2005||FPAY||Fee payment|
Year of fee payment: 8
|Jul 6, 2007||AS||Assignment|
Owner name: TELCORDIA TECHNOLOGIES, INC.,NEW JERSEY
Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:JPMORGAN CHASE BANK, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:019520/0174
Effective date: 20070629
|Jul 17, 2007||AS||Assignment|
Owner name: WILMINGTON TRUST COMPANY, AS COLLATERAL AGENT,DELA
Free format text: SECURITY AGREEMENT;ASSIGNOR:TELCORDIA TECHNOLOGIES, INC.;REEL/FRAME:019562/0309
Effective date: 20070629
|Mar 17, 2009||AS||Assignment|
Owner name: TELCORDIA TECHNOLOGIES, INC.,NEW JERSEY
Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:WILMINGTON TRUST COMPANY;REEL/FRAME:022408/0410
Effective date: 20090220
|Jun 26, 2009||AS||Assignment|
Owner name: TELCORDIA LICENSING COMPANY LLC, NEW JERSEY
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TELCORDIA TECHNOLOGIES, INC.;REEL/FRAME:022878/0821
Effective date: 20090616
|Dec 22, 2009||FPAY||Fee payment|
Year of fee payment: 12
|Jun 11, 2010||AS||Assignment|
Owner name: TELCORDIA TECHNOLOGIES, INC.,NEW JERSEY
Free format text: RELEASE;ASSIGNOR:WILMINGTON TRUST COMPANY, AS COLLATERAL AGENT;REEL/FRAME:024515/0622
Effective date: 20100430
Owner name: TELCORDIA TECHNOLOGIES, INC., NEW JERSEY
Free format text: RELEASE;ASSIGNOR:WILMINGTON TRUST COMPANY, AS COLLATERAL AGENT;REEL/FRAME:024515/0622
Effective date: 20100430
|Nov 8, 2010||AS||Assignment|
Owner name: TTI INVENTIONS B LLC, DELAWARE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TELCORDIA LICENSING COMPANY LLC;REEL/FRAME:025322/0054
Effective date: 20100128
|Feb 10, 2012||AS||Assignment|
Owner name: INTELLECTUAL VENTURES II LLC, DELAWARE
Free format text: MERGER;ASSIGNOR:TTI INVENTIONS B LLC;REEL/FRAME:027682/0210
Effective date: 20120206