Note: Descriptions are shown in the official language in which they were submitted.
CA 0220~308 1997-06-23
TELECOMMUNICATIONS SYSTEM WITH ACTIVE DATABASE
This is a division of copending C~n~ n Patent Application Serial No.
2,113,595 which was filed on January 17, 1994.
Background of the Invention
The present invention relates to telecommunications.
Increasing competition in the provision of telecommunications services is a
worldwide trend. Competition is evolving to the point that many telecommunications
services can be obtained from a range of telecommunications service providers. This
includes both services provided to consumers, such as basic long-distance service, and
10 business-oriented services, such as sophisticated outbound calling programs. Moreover,
the existence of competition among the various service providers has had the effect of
subjecting the rates charged for telecommunications services to the forces of the
marketplace, rather than being set by regulatory m~nd~te.
Summarv of the Invention
It has now been realized that technologies that are ~ ellLly available today
can be harnessed to further extend the concept of free-market pricing for
telecommunications services--particularly the per-call rates charged for telephone calls.
In accordance with the invention, a telecommunications service provider, such as an
interchange carrier, makes its rate information for at least one service--such as basic
long-distance service--available in a database. That information is updated on an
ongoing basis in response to such "rate-controlling" data as the current levels of traffic
within the various portions of the service provider's network; observed trends in those
levels over time; or rates currently offered by other service providers. Given the
availability of such a database in accordance with the invention, switching equipment
which originates subscribers' calls--such as a PBX or central office--can obtain the rate
information stored therein and use it as a basis for d~tel ",i~ g which provider to use
at any given time. The invention is advantageous for the service providers in that they
can, for example, match their rate schedules to take advantage of unique callingpatterns that may develop in the course of a day; or stimulate or discourage traffic in
particular parts of their networks to match dem~n-l with capacities. They can also use
CA 0220~308 1997-06-23
.
- 2 -
it to take into account rate changes initiated by other service providers. The invention
is advantageous for subscribers because it allows them to "shop" for the lowest
possible rates.
In accordance with one aspect of the present invention there is provided a
S method for use by equipment which routes a telephone call from an origin~ting
location to a destination location via a selected one of at least two telecommunications
carriers, the method comprising the steps of: receiving from at least a first one of the
telecommunications carriers, via a telecommunications ~ign~ ; path connected to said
equipment, the toll rate applicable for the call if routed via said first
telecommunications carrier, said ~ign~llin~ path including an SS7 .~ign~llin~; link or an
ISDN D channel; selecting a particular one of the telecommunications carriers as a
function of at least the toll rate received from said first telecommunications carrier, and
routing the call via the facilities of the selected telecommunications carrier.
In accordance with another aspect of the present invention there is provided a
method for use by equipment which routes a telephone call from an origin~ting
location to a destination location via a selected one of at least two telecommunications
carriers, the method comprising the steps of: receiving a request from said origin~ting
location to initiate said telephone call; launching, in response to receipt of said request,
a query, requesting rate information applicable to calls which originate from said
equipment, to at least a first one of the telecommunications carriers, via a
telecommunications sign~lling path connected to said equipment, to determine the toll
rate applicable for the call if routed via said first telecommunications carrier; receiving
that toll rate from said first telecommunications carrier in response to said query;
selecting a particular one of the telecommunications carriers as a function of at least
the toll rate received from said first telecommunications carrier; and routing the call
via the facilities of the selected telecommunications carrier.
Brief Description of the Drawings
The present invention, taken in conjunction with the invention described in
copending C~ns~ n Patent Application Serial No. 2,113,595 which was filed on
January 17, 1994, will be described in detail hereinbelow with the aid of the
accompanying drawings, in which:
CA 0220~308 1997-06-23
FIG. 1 depicts an illustrative telecommunications network in whiclh the
invention is implemented;
FIGS. 2-5 are flowcharts showing steps carried out within the network of
FIG. 1 to implement various embodiments of the invention, and
FIG. 6 is a flowchart showing steps carried out within the network of FIG. 1
to update toll rates stored in a rate database within the network.
Detailed Description
FIG. 1 shows a telecommunications network in which the invention is
implemented. The network illustratively includes three interconnected
10 telecommunications service providers' networks: local exchange carrier (LEC)
network 30 and interexch~nge carrier (IXC) networks 10 and 20. These three networks
all provide services to subsGribers associated with station sets 35-1 through 35-N
connected to cenkal office 31 within LEC network 30.
IXC networks 10 and 20 have the same basic skucture. Accordingly, only
15 one--IXC network 10--is shown in detail. In particular, network 10 includes a plurality
of toll switch complexes, three of which are shown in the FIG.--namely complexes 11,
12 and 13, which are interconnected via interoffice trunks 115, 116 and 125. A toll
switch complex typically serves a number of LEC central offices, and in this case it is
toll switch complex 13 that serves central office 31 via voice path 139.
SS7 sign~ling between central office 31 and IXC network 10 is carried out by
way of link 32 and signal transfer point (STP) 35 connecting to STP 15 within
network 10 via link 34. In general, network 10 will have a number of STPs and STP
35 could, alternatively, be connected to an STP other than STP 15. Each of the STPs
is, in actuality, a pair of STP units. This provides each STP installation with load-
25 sharing and backup capabilities. Thus the links shown in FIG. 1 as being connected to
an STP are, in actuality, divided between the two STP units of an STP pair. Network
10 further includes a .~ign~ling control point, or SCP, 17. This is, in essence, a
database, to which queries are directed from within network 10 to obtain, for example,
routing information for "800" and "900" type calls and authorization codes for virtual
30 private network (VPN)-type calling.
Also shown in FIG. 1 is a PBX 40 located on a subscriber's premises serving
statlon sets such as station sets 45-1 through 45-M. PBX 40 is interconnected with
CA 0220~308 l997-06-23
cenkaloffice31 and network 10 via respective ISDN PRI, ~i~n~ling links. In
particular, B channels 43 and D channels 42 extend to central office 31, while Bchannels 48 and D channels 49 extend to switch complex 12.
Each of the toll switch complexes comprises a "host" toll switch and an SS7
5 ~ign~ling interf~qce. Toll switch complex 11, in particular, includes toll switch 111
serving as host. The SS7 signaling interface is common network interface (CNI) ring
112 described, for example, in U.S. Patent 4,752,924 issued June 21,1988 to J. W.
Darnell et al. Toll switch 111 connects to CNI ring 112 via path 113. Although not
explicitly shown in the FIG., path 113 illustratively includes an intermediary processor
10 which controls the passage of information between the switch and the CNI ring.
Toll switch complexes 12 and 13 are configured similarly. In particular,
complex 12 (13) includes toll switch 121(131) serving as host for CNI ring 122(132).
Toll switch 121 (131) is substantially identical to toll switch 111 and connects to CNI
ring 122(132) via path 123 (133).
SS7 si~;n~ling among various ones of the network elements just described is
provided over a number of SS7 links. In particular, CNI ring 112 has an SS7
connection to STP 15 via link 117. Similar SS7 connections are provided for CNI
rings 122 and 132 via links 127 and 137, respectively. Finally, a CNI ring (not
shown) within SCP 17is connected to STP 15 via link 171.
Also included within IXC network 10 is network monitor and control system
18, which is discussed at a more opportune point hereinbelow.
Central office 31 interconnects with IXC network 20 via voice path 39. It
also has an SS7 connection to network 20 via SS7 link 32, STP 35 and SS7 link 36.
Additionally, PBX 40iS connected to IXC network 20 via ISDN PRI B channels 46
25 and PRI D channels 47.
In the operation of the network of FIG. 1, a major function of the sign~ling
carried out over the SS7 links is to allow two network elements to be correctly
connected. In this process, the SS7 signaling may relate to such functionalities as
~ circuit set-up/tear-down and database (e.g., SCP) lookup in order to implernent, for
30 example, number translation for "800" service. The SS7 sign~ling capability is also
used to another purpose. Specifically, at least one of the IXC net~,vorks makes its rate
information for at least one service--such as basic long-distance service--available in a
~l~t~ e In this embodiment, more specifically, IXC network 10 m~int~in~ the rate
CA 0220~308 1997-06-23
database 16 in which its rates for long-distance service are m~int~ined. Illustratively,
IXC network 20 m~int~in.s a similar database, although, as will be discussed in further
detail below, this is not required.
Illustratively, both PBX 40 and central office 31 access the rate information in5 rate database 16 and in the rate (l~t~h~ce maintained by IXC network 20. That rate
information is then used as a basis for determining, at any particular time, which of the
two IXCs a particular call is to be routed to. That det~rmin~tion, in this example, is
based simply on which one of the two IXCs is offering the lower rate at the time,
although it could take into account other factors such as the existence of discount plans
10 offered by the various service providers.
In the case of the PBX, the choice of IXC is made within the PBX and the
call is routed to the selected IXC via the PBX's direct connection thereto. In the case
of central office 31, it is assumed that the local exchange carrier which operates that
central office offers a "lowest-cost call," or LCC, service to its subscribers wherein the
15 subscriber's local switching office determines the lowest-cost interexchange carrier for
a dialed call and automatically routes the call to that carrier.
It may not be determinable in the first instance which IXC is the lowest-cost
provider. For example, one carrier may have the lower initial-period charge while the
other has the lower per-minute-thereafter charge. In such situations, some
20 pre~lçtPrmined methodology can be used to make a decision as to which carrier to use.
For example, the decision could simply be based on the average length of all
interexchange calls; or on a generalized model of call durations between the
geographical locations in question; or on statistical information about call durations
from the particular station set in question, either generally or to the specific dialed
25 location. The existence of special billing plans offered by service providers for which
particular subscribers may be signed up could also be taken into account in making a
carrier choice. If the rates offered by the two carriers are the same, or if a lowest-cost
provider for a call is otherwise not able to be identified, the call can simply be routed
to a pre-identified default provider, currently referred to in the United States30 telecommunications industry as the "primary interexchange carrier," or PIC.
Rate database 16 is accessed via STP 15 and SS7 link 161 using standard
network database access mechzlni.~m~. In particular, central of~lce 31 can access rate
database 16 using nothing more than a standard SS7 TCAP mes~~ing to extract the
CA 0220~308 1997-06-23
desired information. PBX 40 could similarly query rate database 16 if it had an SS7
link to an STP. Indeed, certain large business customers' PBXs already have SS7 links
in place in order to communicate with SCPs to, for example, avail themselves of so-
called intelligent call processing (ICP) services. In the present embodiment, however,
S PBX 40 is not provisioned with SS7 ~i~;n~linp capabilities. Rather, its access to the
rate databases of the two IXC networks is via its ISDN connections thereto. Here,
again, standard techniques can be used, it is already known how to provision PBXs
with the capability of ~ccessing network databases such as SCP 17 for ICP using ISDN
~ign~ling as described in further detail below.
The accessing of rate database 16 could be on a call-by-call basis. That is,
whenever a subscriber at, for example, station set 35-1 connected to central office 31,
or at station set 45-1 connected to PBX 40, enters the digits of a telephone number, the
central office or PBX l~llnches a query to the various IXC networks to obtain the
current rate information for the call in question. Alt~rn~tively7 a carrier's entire
15 schedule of long-distance rates applicable to calls originzltin~ from the PBX or central
office in question could be accessed periodically--for exarnple, every quarter-hour--and
stored locally in the PBX or central office, thereby obviating the need for a database
query for every call.
Advantageously, the LECs and IXCs could establish a protocol whereby rate
20 changes are made available within the rate database sufficiently in advance of when
they are effective so as to allow the LEC to be sure that it is always in possession of
the current rates. For example, it could be arranged that rate changes will be made
available no later than 10, 25, 40 and 55 minutes past the hour, to be effective exactly
five minutes later, i.e., on the quarter-hour. Another possibility is to avoid the need
25 for the LECs or central offices to repeatedly access the IXCs' rate databases by having
the IXCs automatically transmit their rate information to the central offices either
periodically or whenever there is a change in the rates that apply to calls origin~fing
from that LEC or central office.
Alternatively, instead of each central office receiving the rate schedule
30 information from the service providers directly, that information could be obtained by
the LEC--either in response to a query or via automatic tr~n~mi.~.~ion from the service
providers. The LEC, in turn, could either a) distribute the rate schedule to all of the
central ofrlces which the LEC controls or b) provide a LEC database to which each
. CA 0220~308 1997-06-23
central of~lce which the LEC controls could launch a query. The latter approach may
be particularly advantageous in that the LEC database could precompare the ratesoffered by the various service providers and could determine and store information
indicating which carrier offered the lowest rate to, for example, each possible
5 destination central ofrlce in the overall network using, if desired, one or more of the
statistical call models discussed above. A central office could then determine which
provider a call is to be routed to by simply querying the central LEC database,
supplying in the query the destination area code and local exchange code.
Moreover, if a particular service provider chose not to m~int~in a rate
10 database, its fixed, published rates could nonetheless be stored locally and compared
with the ch~n~ing rates offered by providers who do.
Various of the possibilities mentioned above are illustrated in the flowcharts
of FIGS. 2-5.
FIG. 2, in particular, is the PBX example described above. A caller at one of
station sets 45-1 dials the telephone number of a called party (action block 201). PBX
40 thereupon determines whether this is a call for which the rate is to be checked. If it
is not--as would be the case, for example, if the call were being made within the local
calling area of the PBX--the call is completed normally (action block 204). If,
however, the rate is to be checked, PBX 40 launches queries, in parallel, to IXCs 10
and 20.
With respect, in particular, to IXC 10, PBX 40 launches (action block 206) an
ISDN set-up request with a Q.932 facility information element (FIE). This request
contains within it the information needed to determine what the applicable rate for the
call will be. Such information would include, for example, the calling and called
telephone number area code and local exchange. The request is forwarded to toll
switch 121 via D channels 49, CNI ring 122 and link 123. Switch 121 thereupon
converts the Q.932 FIE into an SS7 TCAP BEGIN message (action block 209), and
thereupon sends that message to rate database 16 using global title translation via link
123, CNI ring 122, SS7 link 127, STP 15 and SS7 link 161 (action block 213). Rate
database 16 performs a lookup and returns the rate (action block 213). Rate database
16 performs a lookup and, again using global title translation, returns the rate data to
switch 121 in a TCAP END message (action block 216). (As is well known, toll call
rates are typically defined by geographical distances between termination points and
CA 0220~308 1997-06-23
- 8 -
the aforementioned lookup may therefore include some simple computations to
determine the rate.) Switch 121 converts the TCAP END message to a Q.~32 FIE
which it sends to PBX 40 (action block 218).
At the same time as action blocks 206 through 218 are being carried out
within IXC 10, a similar set of action blocks--denoted generically at 220--is being
carried out within IXC 20. Ultimately, PBX 40 has available to it the rates to be
charged for the call in question by each of the two IXCs. It compares them, selects a
carrier based on the comparison and then places the call to the selected carrier via the
~ o~liate PRI link (action block 219). The steps of FIG. 3 illuskate the accessing of
10 the rate database by LEC 30 to provide a "lowest-cost calling" service to subscribers
who may wish to have this service. The subscriber (customer), such as a subscriber
using station set 35-1, places a call to central office 31 (action block 301). The latter
det~rmines from an internal database (not shown) whether the subscriber in question
has subscribed to the lowest-cost calling service (action block 304). If not, the call is
15 routed to the subscriber's pre-selected primary interexchange carrier (action block 305).
If yes, the central office l~llnchcs queries, in parallel, to IXCs 10 and 20, as was the
case for PBX 40 described above. Since central office 31 has direct SS7 links to the
IXCs' rate databases, ISDN ~i~n:~linp is not involved in this case. Rather, the central
office launches an ~l~lopliate SS7 TCAP BEGIN message to rate database 16 (in the
20 case of IXC 10) via SS7 link 32, STP 35, SS7 link 34, STP 15, and SS7 link 161.
The rate database performs the operations described earlier in conjunction with FIG. 2
and provides the desired data to central office 31 in a TCAP END message.
At the same time as action blocks 306 and 309 are being carried out within
IXC 10, a similar set of action blocks--denoted generically at 330--is being carried out
25 within IXC 20. Ultimately, central office 31 has available to it the rates to be charged
for the call in question by each of the two IXCs. As before, it compares them, selects
a carrier based on the comparison and then places the call to the selected carrier
(action block 311).
As noted earlier, an alternative to making a rate database query for each call is
30 to periodically--for example, every quarter-hour--access a carrier's entire schedule of
long-distance rates and store them locally. This approach is illustrated in FIGS. 4 and
5, again in the context of a lowest-cost calling service offered by a LEC.
. CA 0220~308 1997-06-23
Action blocks 401 and 402 in FIG. 4 represent a process whereby central
office 31 periodically receives from IXCs--via any of the mech~ni.~ms described
above--the entire rate schedule applicable to calls routed from that central office via
those IXCs. It initiates the process with a TCAP BEGIN message. Because the return
5 information is fairly lengthy, it cannot be contained in a single TCAP END message.
Rather, an IXC returns the rate schedule in a sequence of TCAP CONTINUE messagest~rmin~t~-l by a TCAP END message.
FIG. 5 shows the implementation of the lowest-cost calling service using this
approach. In particular, action blocks 504, 506 and 508 are the same as action blocks
301, 304 and 305, respectively, of FIG. 3. At action block 511, however, a further
service is offered to the subscriber. Specifically, it is postulated that an IXC may be
willing to specify the rates that will be effective throughout some future time period,
such as half an hour. Having retrieved those rates from the IXC's rate database, the
central office can thereupon scan the rates that will be in effect throughout that future
time period (action block 511). If there would be no benef1t in waiting, because none
of the IXCs will be offering a lower rate than the lowest rate ~ t;;nlly available, then
the call is routed to the lowest-cost carrier (action block 516). If there would be a
benefit, then an announcement is presented to the caller (action block 514) informing
him/her of the relevant facts, such as when the rate change will become effective and
what the monetary benefit in waiting will be. The caller is prompted to indicatewhether the call should be placed now or not (decision block 517). If yes, the call is
placed (action block 516). If no, the call is disconnected (action block 51~). In the
event that the caller wishes to wait until a lower rate is available, the LEC can provide
the further service of offering to automatically place the call when the new, lower rate
becomes effective. Specifically, at the point in time that the new rate becomes
effective, the central office would ring the ori~in~ting telephone line. Upon the station
set being taken off hook, it would proceed to connect it to the called party with,
perhaps, an announcement being first provided to the orip;in~tillg station indicating that
this was the call that had been re-scheduled pending the lower rate becoming effective.
We turn, now, to a discussion of how the rate schedules in rate database 16
are illustratively updated.
. CA 0220~308 1997-06-23
.
- 10 -
As noted earlier, IXC network 10 includes network monitor and conkol
system 18. System 18 may comprise one or a plurality of so-called operations support
systems. As is well known, such systems communicate with, for example, toll switch
complexes, STPs, SCPs, tr~n~mi~ion facilities and other network elements in ordcr to
5 monitor such factors as levels of traf~lc within various portions of the network
and--based on the data thus obtained--to control, for example, the routing of traffic
within the network and the issuing of alarms to network management personnel.
System 18 communicates with the various network elements that it monitors and
conkols using BX.25 and OSI protocols. The communication is carried out by way of
10 a switched digital network and/or direct (point-to-point) connections. For example,
direct connections may be used to interconnect system 18 with the toll switches, with
the digital network connection being used as a backup. With the exception of rate
database 16, the connections between system 18 and the other network elements are
illustratively via the digital network only, with no backup. In FIG. 1, path 181 is
15 representative of the links interconnecting system 18 with the switched digital network.
Signaling paths 182 are representative of the aforementioned direct connections. As
just alluded to, there does exist a direct connection between system 18 and ratedatabase 16, that being via a specific one of paths 182--namely path 1821.
Network monitoring and control system 18 is programmed to report to rate
20 database 16 certain predetermined rate-controlling data. In preferred embo~liment~7 that
data includes, at a minimum, the level of traffic at various points in the network as
well as the status (active/inactive) of various particular network elements. Therate-conkolling data is then used by rate database 16 to update the rate schedules.
In accordance with a feature of the invention, rate database 16 is illustratively
25 an active database of the type described, for example, in Dayal et al., "The HiPAC
Project: Combining Active Databases and Timing Conskaints," ACM-SIGMOD
Record, Vol. 17, No. 1, March 1988, pp. 51-70, McCarthy et al., "The Architecture of
An Active Database Management System," Proc. ACM-SIGMOD 1989 Int'l Conf.
Management of Data, Portland, Oregon, May-June 1989, pp. 215-224; Gehani et al.,30 ~'Ode as an Active Database: Constraints and Triggers," Proc. 17th Int'l Conf. VerY
Data Bases, Barcelona, Spain 1991, pp. 327-336; C~ehani et al., "Event
Specirlcation in an Active Object-Oriented Database," Proc. ACM-SIGMOD 1992 Int'l
Clonf. on Mana~ement of Data, San Diego, California 1992; and Gehani et al.,
, CA 0220~308 1997-06-23
- 11 -
"Composite Event Specification in Active Databases: Model & Implementation," Proc.
of the 18th Int'l Conf. on Verv ~g~ D~qt~h~es~ Vancouver, BC, Canada,
August 1992.
If a conventional database were used in this application, a software application5 executing independently of the database manager would have to be provided to a)
repetitively access the rate-controlling data stored in the database, b) examine it and, c)
based on a predetermined toll rate-ch~nging algorithm, change the toll rates stored
therein. The large volume of data that would typically be stored in the database,
however, could well result in the need for an exkemely powerful, and therefore
10 expensive, processor on which to execute such an application. In an active database,
by contrast, the database manager both a) stores data and b) generates an "alerter" or
"trigger"--thereby initiating the taking of some action-when particular data meets
particular pre-programmed criteria. (Indeed, a trigger can be used to decide whether
particular rate-controlling data, such as the level of traf~lc through a switch at any
15 particular time--is sufficiently "of interest" at this time to W~lld~ll storing it.) Because
the data is being examined and acted upon as it is received, a much less powerful
processor is required. In this case, that action is the updating of the toll rates.
As an example, rate database 16 can be programmed to reduce, by a
predetermined percentage, the toll rate for all calls carried between a particular pair of
20 toll switches if some criterion is met. Such rate reductions would be expected to have
the effect of stimulating traffic along the route in question because, at least for some
calls which include that route as one of their legs, the toll rate can be made less than
that offered by other service providers. The progr~mmin~ within rate database 16 is
such that at a later time, when some other criterion is met, the toll rate in question is
25 returned to its original level. Indeed, it is possible that a rate may be increased above
its typical level should conditions w~llan~ it.
The criterion can be a very simple one, such as the crossing of a kaffic level
threshold (measured, for example, in calls-per-hour or percentage capacity) bet~,veen the
two switches. Or it can be quite complex, such as a criterion which takes into account
30 traffic level trends involving quite a number of toll switches over some period of time.
Other factors that could be used include the percentage of capacity to which a
particular network element is loaded; the operational status (active/inactive) of various
CA 0220~308 1997-06-23
- 12 -
network elements; the extent to which a level of traffic differs from some predicted
value, or combinations of these.
It will thus be appreciated that rate database 16 is really two databases. One
stores rate controlling information used to generate the triggers. The other stores the
5 rate schedules themselves.
Criteria other than those which relate to data provided from system 18 could
also be used by rate database 16 to change the rates. For example, triggers generated
by database 16 may take into account toll rates offered by IXC network 20, that data
being obtained via an SS7 query made to a rate database within IXC network 20. As
10 another possibility, triggers may be generated as a function of the level of demand at a
particular element of the network for a network-based service, such as a network-based
interactive game. Such data may be gotten, again via an SS7 query, from an SCP
through which entry to the game is controlled.
An illustrative process by which the rates stored in rate database 16 are
updated is shown in FIG. 6. As indicated at action block 601, system 18 and/or other
sources of rate-controlling data provide that data to rate database 16. The latter, at
action block 602, updates rates based on active database triggers generated in response
to that data. The updated rates are thereupon communicated to the network's billing
systems, as indicated at action block 604, illustratively in response to those same
20 triggers.
Considering this last function in more detail, it will be appreciated that the
changes in toll rates within rate database 16 must be coordinated with the operation of
the billing systems (not shown) within the network. Typically, such billing systems
receive billing records that are created by the toll switches at the completion of
25 telephone calls. Ultimately each call is "rated" by the billing system, me~nin~ simply
that the toll charge for the call is computed based on the rates in effect when the call
was made, and the computed charge is then added to the billing record for the call.
Here, each toll rate change made in rate database 16 would have to be made known to
those components of the overall billing infrastructure which rate the telephone calls.
30 This is done straightforwardly by having rate database 16 communicate such changes
into the billing system, via ~plo~liate .si~n~ling links, and again, in response to those
same triggers, sufficiently in advance of the time that they would become effective to
be sure that the updated rate schedules would be available for the rating of calls made
CA 02205308 1997-06-23
- 13 -
when those rates are effective. Each update would be accompanied with data
indicating the time at which it is to become effective.
The foregoing merely illustrates the principles of the present invention. It will
thus be appreciated that those skilled in the art will be able to devise numerous
5 arrangements which, although not explicitly shown or described herein, embody those
principles and are within their spirit and scope.
