HK1074724B - Method and system for global communications network management and display of market-price information - Google Patents
Method and system for global communications network management and display of market-price information Download PDFInfo
- Publication number
- HK1074724B HK1074724B HK05106766.4A HK05106766A HK1074724B HK 1074724 B HK1074724 B HK 1074724B HK 05106766 A HK05106766 A HK 05106766A HK 1074724 B HK1074724 B HK 1074724B
- Authority
- HK
- Hong Kong
- Prior art keywords
- service
- connection time
- node
- route
- call
- Prior art date
Links
Description
This application is a continuation of U.S. serial No.08/927,443 filed on 11/9/1997 and U.S. serial No. 08/920,567 filed on 29/8/1997, all of which are incorporated herein by reference.
Background
Toll charges are typically paid by the calling party rather than the called party. Call charges are typically collected from the calling party by the carrier initiating the service, either directly or through an agent of the caller's local telephone service provider. Thus, when a call is made from a first location served by an originating carrier to a second location served by a different terminating carrier, it must be specified that the terminating carrier share the revenue collected from the calling party by some originating carriers.
For international telephone calls, this revenue sharing is typically accomplished through the use of clearing agreements. Clearing agreements generally establish billing rates between countries that are related to the cost of connecting calls, and specify how the billing rates are divided between two carriers. This division is typically 50-50.
For example, assume that the U.S. carrier and an overseas carrier have negotiated a clearing agreement, a billing rate of 1 US dollar per minute, and a 50-50 revenue split. Under this agreement, U.S. carriers must pay 50 cents per minute for the connection time per minute for the called location served by the overseas carrier. Overseas carriers, in turn, must pay 50 cents per minute for the connection time per minute for calls terminated by U.S. carriers.
But as we have appreciated, the negotiated billing rate is typically much higher than the actual cost of completing an international call. For example, looking at the Frieden billing rate: the Business of International Telecommunications and The inclusive to chemical, 43 Federal Communications Law Journal 111, 117, incorporated herein by reference. For this reason, and because the volume of outbound calls from the united states is much greater than the volume of calls inbound from many foreign countries, united states carriers pay significant outbound fees to overseas carriers. Most of these costs are ultimately borne by the taxpayer.
This imbalance of payments is exacerbated when overseas carriers route traffic entering the united states over dedicated telephone lines entering the united states under their control. Thus, overseas carriers can avoid paying high-rate liquidations for calls from their countries to the united states, while receiving high-rate liquidations from U.S. carriers, who are forced to route traffic out of the united states through overseas carriers because they are monopolized in their home country. Furthermore, overseas carriers often use these alternative inexpensive routing options for inbound U.S. traffic despite the explicit agreement in the clearing agreement to prohibit such behavior.
To date, U.S. carriers have been forced to tolerate this imbalance of payments and have not been a straightforward way to deal with the disruption of protocols by overseas carriers, as it takes a significant amount of time and expense to reconfigure the global network to reroute call traffic. The cumbersome reconfiguration process gives foreign carriers the opportunity to route traffic into the united states over dedicated lines or to increase clearing margins without fear of replies from the united states carriers.
More generally, this inflexible routing architecture prevents telephone service providers from enjoying the benefits of worldwide fluctuations in telephone rates. It is desirable to provide a way to dynamically route based on rate changes in order to ultimately benefit the consumer. There is also a need for a method of providing dynamic payment to telephone companies and selling chunks of telephone connection bandwidth.
Thus, the need for flexible allocation of connection routes and trading connection bandwidth capabilities exists not only in the international arena, but also in any domestic market that allows competition in the field of communications.
Summary of The Invention
According to one aspect of the invention there is provided a method for displaying market prices from telecommunications transactions, comprising the steps of: receiving, by a server node, service offerings from one or more telecommunication service vendors, each service offering a connection time block for sale, each service offering further specifying a plurality of parameters including price information for the offered connection time block; identifying, by the server node, one or more routes for routing calls between a pair of locations according to parameters specified in one or more of the service offerings, each identified route including one or more legs, the service for each leg being provided by a telecommunications service provider; receiving, by said server node, service requests from a plurality of telecommunication service buyers, each service request requesting the purchase of a block of connection time, each service request further specifying a plurality of parameters including a termination location of the requested block of connection time; matching, by the ticker node, one or more of the service requests with one or more of the service offerings according to a plurality of parameters specified by the buyer and the vendor; brokering, by the server node, a transaction to transfer ownership of at least a portion of the connection time blocks specified in the matched service offerings from one or more of the one or more vendors to one or more of the plurality of buyers providing corresponding matched service requests; determining, by a market price monitoring system coupled to the server node, a market price for at least one identified route; and displaying the market price on a display device.
According to another aspect of the present invention there is provided a system for displaying market prices from telecommunications transactions, comprising: means for receiving service offerings from one or more telecommunications service vendors, each service offering a connection time block for sale, each service offering further specifying a plurality of parameters including price information for the provided connection time block; means for identifying one or more routes for routing calls between a pair of locations based on parameters specified in one or more of the service offerings, each identified route including one or more legs, the service for each leg being provided by a telecommunications service provider;
means for receiving service requests from a plurality of buyers of telecommunications service, each service request requesting the purchase of a block of connection time, each service request further specifying a plurality of parameters including a termination location of the requested block of connection time; means for matching one or more of said service requests with one or more of said service offerings in accordance with a plurality of parameters specified by the buyer and the vendor; means for brokering transactions to transfer ownership of at least a portion of the connection time blocks specified in the matched service offerings from one or more of the one or more vendors to one or more of the plurality of buyers providing corresponding matched service requests; means for determining a market price for the at least one identified route; and means for displaying the market stage.
In a preferred embodiment, the system is capable of displaying market price information about supported communication routes to prospective sellers and buyers of connection time. This display is preferably in the form of a streaming logo generated by a Java applet running on the client PC.
Although the preferred embodiments are described in terms of calling and called telephones, it should be understood that the invention may be practiced with all manner of telephone user equipment. By way of example, but not limitation, such telephone subscriber equipment may include answering machines, facsimile machines, video conferencing equipment, local exchanges (e.g., in hotels or offices), voice analysis/recognition equipment, dialing devices, answering services, and computers.
Furthermore, although some preferred embodiments are described primarily in terms of voice telephone calls from a calling telephone to a called telephone, it should be understood that the global network of the present invention may include all types of connections, including, but not limited to, data transmission, voice over IP, ATM, FR and virtual networks, for example. Furthermore, the transmission may be routed through a path consisting of call legs using different transmission techniques.
Brief description of the drawings
The foregoing summary of the invention will be better understood in conjunction with the following detailed description and the accompanying drawings, in which:
FIG. 1A is a block diagram of a global network of telephone systems suitable for implementing the present invention;
FIG. 1B is a block diagram of a telecommunications node and its associated database;
FIG. 2 is a flow chart depicting steps performed in a tariff table for determining routing paths having cost-to-performance ratios;
FIG. 3A is a schematic representation of a template for entering rate information;
FIG. 3B is a schematic representation of a template for making a service request;
FIG. 4 is a schematic representation of a tariff database;
FIG. 5 is a flow chart depicting steps performed in a telephone connection time agent sales;
FIGS. 6A-C schematically show illustrative states of the tariff table database 400 at various points in the telephone connection time process;
FIG. 7 is a flow diagram illustrating the call routing operation in the global network of the present invention;
FIG. 8 is a flow diagram illustrating in greater detail a first portion of the call routing operation depicted in FIG. 7;
FIG. 9 is a flow diagram illustrating in greater detail a second portion of the call routing operation depicted in FIG. 7;
FIG. 10 is a flow diagram illustrating in greater detail a third portion of the call routing operation depicted in FIG. 7;
11A-B are flow diagrams of a business-by-business purchase connection time protocol;
fig. 12 is a flow diagram depicting a telecommunications node dynamically controlling available communication capacity;
FIG. 13 is a block diagram of a telephone system architecture including a market price monitoring subsystem;
FIG. 14 is a block diagram of a preferred embodiment of a market price monitoring subsystem;
FIG. 15 is a schematic representation of a preferred embodiment of a market price database;
FIG. 16 is a schematic representation of a preferred embodiment of a customer database;
17A-B are flow diagrams depicting one aspect of the operation of the market price monitoring subsystem; and
FIG. 18 is an example of a web page suitable for displaying market price information to a customer.
Description of The Preferred Embodiment
Figure 1A illustrates a global network communications system architecture, such as a telephone system architecture, suitable for implementing the present invention. As shown in fig. 1A, the architecture preferably includes a calling telephone 2 from which a calling party may make a telephone call to a called telephone 4. The calling telephone 2 is connected to a local telephone network 6 by a local loop or other connection (e.g., an ISDN line), represented schematically by line 8. Both the local telephone network 6 and the line 8 are typically owned and maintained by the caller's local telephone service provider. Called telephone 4 is similarly connected to local telephone network 10 by a local loop or other connection, represented schematically by line 12. Both the local telephone network 10 and the line 12 are typically owned and maintained by the local telephone service provider of the called party.
Also shown in fig. 1A is an originating toll switch 14, typically maintained by a long distance carrier. Originating toll switch 14 is preferably connected to local telephone network 6 by signaling and transmission lines, represented schematically and collectively by line 16. For example, the signaling lines may form part of an SS7 network. The transmission line carries voice and data transmissions between the local telephone network 6 and the originating toll switch 14.
Fig. 1A also shows terminating long distance switch 18, typically maintained by the called party's long distance provider. The terminating long distance switch 18 is connected to the local telephone network 10 by signaling and transmission lines, represented schematically and collectively by lines 20. For example, the signaling lines may form part of an SS7 network. The transmission lines carry voice and data transmissions between local telephone network 10 and originating toll switch 18.
The system architecture also includes an originating international gateway exchange 22 that routes and transmits overseas calls made from calling telephone 2. The originating international gateway switch 22 forms part of a global network of international gateway switches that includes a terminating international gateway switch 24 and transit international gateway switches 26, 28. Each pair of gateways in the international gateway network are preferably linked by signaling and transmission lines schematically represented by lines 30-38.
As will be appreciated, the international gateway switch, toll switch (terminated or originated), and local network in a particular location may be owned and maintained by the same or different business entities, depending on the specification environment of the location.
Originating international gateway switch 22 is preferably connected to originating toll switch 14 by signaling and transmission lines, represented schematically by line 40. Similarly, terminating international gateway switch 18 is preferably connected to terminating toll switch 18 by signaling and transmission lines, represented schematically by line 42. For example, the signaling lines may form part of an SS7 network. The transmission lines carry voice and data transmissions between the two international gateway switches and their respective toll switches.
Although fig. 1A shows only four international gateway switches (22-28), those skilled in the art will appreciate that the architecture provided herein may be generalized to any number of such gateways. Moreover, those skilled in the art will appreciate that the status of the gateway as originating, terminating, or transit is determined by the SS7 signaling network or other data messages, such as data messages transmitted according to a dedicated signaling protocol. Further, those skilled in the art will appreciate that similar network architectures on the domestic market are constructed with different communication providers.
The system architecture also includes a network of telecommunications nodes 44-48. Each node in the network may be associated with one international gateway switch 22-28 and may be connected to the respective international gateway switch by data lines 50-54. Alternatively, the telecommunications node may incorporate an international gateway switch, such as node 49. As described in more detail below, the nodes 44-49 comprise an overlay network that co-exists with a gateway network and manages routing of certain calls passing through the gateway network.
As shown in FIG. 1B, each node 44-49 preferably provides:
a carrier's own cost database 99 (one for each carrier associated with the node) storing information relating to the internal cost of the carrier to connect calls from possible origination locations to possible termination locations;
an outbound price database 98 (one for each carrier associated with the node) that stores prices published by carriers to connect possible origination locations to possible termination locations;
a global cost database 97 stores various routing cost information for connecting possible origination locations with possible termination locations. As will be described in more detail below, this information is received from the server node 56 of fig. 1A.
Furthermore, the nodes 44-49 preferably provide:
a cross-connect database 96 (one for each carrier associated with the node) stores the following information: the physical transport facilities maintained by the carrier, the technologies supported by the facilities (e.g., voice, ATM, internet, etc.), and the names and locations of other carriers to which the carrier's facilities are interconnected. This information is used by the system to map the physical interconnections available on the world wide web.
The nodes 44-49 also preferably provide a business rules database 95 (one for each carrier associated with the node) that stores business rules for purposes described below.
The network of telecommunications nodes also includes a server node 56. Although shown as a single node in FIG. 1A, the server node 56 may also be implemented as a distributed network of servers. The constituent elements in the distributed network may be incorporated into nodes 44-48. Each node 44-48 in the network of telecommunications nodes is connected to a server node 56 by a data line 58-62, respectively. Each data line preferably has a bandwidth of at least 64 kb/s. As described in more detail below, the server node 56 stores cost and possibly routing information and determines a cost-effective routing path for calls sent over the network. The server node 56 also clears traffic and coordinates the routing of all calls managed by the overlay telecommunications node network. Call routing is determined based on parameters specified in a service request submitted by the requesting carrier.
As shown in fig. 2, the server node 56 determines a cost-effective routing path for a call connected through the international gateway network in three steps: (1) collecting cost information; (2) evaluating the collected information; and (3) generating a cost table from the collected information and the network topology map, including cost-to-performance routes for each pair of switches in the international gateway network.
In step (1), the system collects cost information from international carriers throughout the world. Each record of cost information includes the price that the carrier will ask for a call to be routed from a first location to a second location, as well as the call volume capacity and service-related details such as quality, reliability and security of transmission, legal restrictions (e.g., termination restrictions), post-dial delay-PDD, type of service (e.g., voice, fax, data, video) and technology used on the link (e.g., ISDN, ATM).
Preferably, the carrier enters the cost information through a template 300 that is accessible at a web site maintained by the server node 56. Alternatively, a carrier that owns and maintains international gateway switches (e.g., switches 22, 26, and 28) or nodes 44-48 may send cost information to server node 56 through telecommunications nodes 44-48. Figure 3A illustrates a suitable arrangement of such templates. As shown in fig. 3A, the template includes a plurality of fields for inputting information about providing a service. These domains illustratively include:
name of communication companyA domain 302;
carrier identification numberA domain 304;
cipher codeA domain 306;
date of submissionA domain 308;
quality ofField 310 (storing quality level of connection);
fromDomain 312 (storing origination locations of services provided);
arrive atA field 314 (storing the destination location of the provided service; in the form of a country code if the service is available anywhere in the country; country and area codes if the service is available only to specific areas within the country; the entire destination number if the service is available only to specific called telephones);
available timeA field 318 (store available time in minutes per month for a certain price);
number of linesA field 320 (storing the maximum number of simultaneous calls that the carrier can handle);
priceA domain 322;
time of operationA field 324 (storing operating time that may use the purchased connection time);
furthermore, the template preferably comprises the following fields:
type of serviceDomain (storing the type of service provided, e.g., voice, fax, data, video);
post-dial delay(post-dial-delay, PDD) domain;
to when it is effectiveDomain (store to which day to start providing);
legal restrictionsDomain (storage related may affect connection time usageInformation of legal restrictions of (1);
periodic paymentsDomain (store any special periodic payments required by the provider);
compression levelDomain (maximum compression level that can be used in storage transfer);
type of deviceDomain (store the type of device used by the service provider);
signaling compatibilityDomain (signaling protocol that storage providers can handle, e.g., SS7, IN); and
maximum waiting timeDomain (latency in this case refers to delay due to router blocking);
moreover, the template may also preferably include:
provide local termination?A domain;
offer settlement?A domain;
by dedicated line?A domain;
length of contractA domain;
by satellite?A domain; and
termination options?The domain(s) is (are),
their use is described below.
As will be appreciated by those skilled in the art, the fields listed above are merely illustrative of the fields that the template 300 may comprise. The template 300 may include more or different information that facilitates the server node 56 making routing decisions and brokering transactions between the provider carrier and the requester carrier.
In the preferred embodiment, the server issues three levels of passwords. The first level password allows the password holder access to published fees, but does not allow the password holder to purchase or sell time through the server. The second level password allows the password holder to purchase but not sell connection time through the server. The third level password authorizes the password holder to be able to purchase or sell connection time through the server. Thus, the communicating public submitting the template 300 may be required to have a third level password.
In the preferred embodiment, all routes listed on a single template are of the same quality. Thus, as shown by way of example in FIG. 3A, preferably only a single quality domain is provided for each template. A carrier that wishes to provide other routes of different quality does so on a different template. Furthermore, all routes listed on a single template preferably have the same traffic type.
Similarly, in the preferred embodiment, all routes listed on a single template are from the same origination location. Thus, as shown by way of example in FIG. 3A, each template preferably provides a single origination location field 312. A carrier wishing to provide a connection from another origination location does so on a different template.
As shown in fig. 3A, the template 300 may include two or more available time fields, number of lines field, price field, and operating time field for each route listed by the carrier. This allows the carrier to offer different service prices at different times of the week and day. The possibility is also provided for many carriers to use a tiered pricing scale. In a tiered pricing scale, connection time up to a certain capacity (e.g., 300k minutes/month) costs are different than connection time costs above that capacity.
As schematically represented in fig. 3A, a carrier may list more than one price for traffic from the united states to Korce (city code 824) in albania (country code 355). For example, to purchase 300k minutes or less per month, the carrier may charge 62.5 cents per minute for calls from 10p.m. to 8a.m. on monday to friday, and from 12 to 6p.m. on saturday and sunday noon. Instead, a carrier may charge 59.8 cents per minute for calls from monday to friday 8p.m. to midnight 12 and saturday and sunday from 5a.m. to 6p.m. for over 300k minutes per month.
Also shown in fig. 3A is an initial transaction date field 326, which is filled in by the server node 56 prior to sending the template 300 to the carrier. This date reflects the first day that the connection time entered on the template was offered for sale by the web. As may be noted on the template 300, the seller is required to submit fee information a predetermined time (e.g., three days) before the date of the initial transaction. This allows the server node 56 time to process the received cost information and thereby generate a cost table, as described in more detail below.
Note that the template may include other fields not shown in fig. 3A. For example, the template 300 may include "provide local termination? "Domain, stores a Boolean value indicating whether the carrier can provide local termination for calls in the location stored by domain 314. Local termination may become impossible for several reasons. For example, the termination may be prohibited by local regulations or the carrier may not have the equipment necessary to terminate the call at a particular location.
The template 300 may also include boolean "offer settlement? "Domain". Some carriers are legally required to route calls in a manner that invokes a settlement agreement with the terminating country. A settlement protocol is invoked when a call is routed through a Public Switched Telephone Network (PSTN) but via a private or data line. Therefore, it is important that the server determine whether a particular route offered by the service provider incurs a settlement.
The template 300 may also include a boolean "through dedicated lines? "Domain". As described in more detail below, this domain allows the server node 56 to accommodate carriers that do not wish to purchase connection time on routes that use dedicated lines.
The template 300 may also include a boolean "through satellite? "Domain". As noted below, the server node 56 may combine services provided by more than one carrier to create a call route from a first location to a second location. As is well known in the art, the connection quality and post-dialing delay of using two satellite links in routing is often unacceptable. This domain allows the server node 56 to identify traffic that relies on the satellite links and to avoid using more than one routing path that connects the calling location and the called location.
The template 300 may also include a "termination options" field. By way of illustration, the carrier may provide a fax bypass function as a termination option. Fax bypass provides a means to substantially reduce the cost of fax transmission. Typically, facsimile transmissions are sent over telephone lines that are settled at high rates. In fax bypass, a node in the route identifies the fax tone of the fax transmission and reroutes the call over the data line. In this way, faxes can be sent at very low cost. In addition, other termination options may be listed, such as voice over IP, as will be appreciated by those skilled in the art.
It is noted that the price charged by a carrier may depend on the communication service provided. For example, a carrier may provide connection time at a first rate for voice calls and at other rates for services that provide, for example, voice mail, teleconferencing, paging, email access, internet access, retrieving fax, facsimile transmissions, PPP access, personal assistants (ring mailboxes), etc. In addition, various grades of voice services, such as dedicated lines and ISDN lines, can be provided.
After the system collects cost information from carriers around the world regarding call routing costs and traffic parameters at various levels from a first location to a second location, it proceeds to step (2) of fig. 2. In step (2), the system evaluates the received information, in particular information relating to the service, such as transmission quality and reliability, and determines the accuracy of the provided parameters. Because the server node 56 acts as a clearing house for telecommunications transactions, it is important that the carrier purchasing time from the server node 56 trusts the accuracy of the service parameters published by the server node 56. The server node 56 therefore independently evaluates the traffic parameter information received from the carrier and assigns a rating, e.g., "a", "B", "C", etc., to each parameter (e.g., quality). The evaluation is based on information about the carrier traffic previously stored at the server node 56. The server may upgrade or downgrade specified parameters based on various considerations, such as historical reliability of a particular carrier. Thus, for example, if the server typically designates a satellite connection as a "B" level of reliability, it may designate a particular satellite connection as a "A" level if the connection historically exhibits a higher level of reliability.
In step (3), the server node 56 derives a cost table from the collected cost information, listing the costs of connecting any two locations within the telecommunications node network via various routes, and any traffic parameters associated with each route. Preferably, the server node 56 obtains a separate cost table for each level of service (e.g., voice, data, video conferencing, etc.) that the global network may provide. This information is then stored in a cost table database located at the server node 56. Fig. 4 illustratively shows one possible arrangement of some of the data in the tariff database 400 representing the fees charged by different carriers for various routes.
As noted in my co-pending application serial No. 08/811,071 (incorporated herein by reference in its entirety), it is recognized that a call from an origination location to a termination location may be connected via a call routing path that includes several call legs, each leg bridging two locations in the call routing path. Further, as referred to herein, each branch may be done in either the forward or reverse direction. Thus, the routing paths determined and stored in the cost table database 400 are often formed by merging services provided by carriers throughout the world.
For example, if a first carrier submits a template to the server node 56 for providing service from the united states to the united kingdom at a first price, and a second carrier provides a template to the server node 56 for providing service from the united kingdom to germany at a second price, the server node 56 may consolidate the two and provide the consolidation as a route from the united states to germany at a price equal to the sum of the first price and the second price.
Traffic parameter information relating to a route takes into account both the assessed submission cost information parameter and other factors that may affect the parameters assigned to a route. For example, although a route may be formed by two "a" quality legs, the two legs in the merge may not be able to form an "a" quality connection because there is some delay in setting up a two-leg call.
Furthermore, it should be noted that the latency of the application determines for the most part the parameters important for the call. Thus, for example, the parameters important for a voice call are different from the parameters of an incoming (e.g.) fax.
As may also be noted in my co-pending patent application serial No. 08/811,071, the total number of possible routing paths between any two nodes in the network increases steeply as the number of nodes increases. Therefore, unless the number of telecommunications nodes in a network of telecommunications nodes is small, it is impractical to determine and store routing information for each possible route connecting any two nodes in the network. However, as will be appreciated by those skilled in the art, the number of routes required to calculate and store a cost entry will remain an easily manageable number for several reasons.
First, although the number of theoretically possible routes can be very large, due to legitimacy or other limitations, many routes can be immediately excluded from the cost table calculation. For example, local regulations may prohibit certain transactions such as terminating traffic originating over a dedicated line or terminating traffic except through a local gateway switch. Such cost entries for call routing need not be calculated or stored.
Furthermore, as those skilled in the art will recognize, there are heuristics that identify cost-effective routes connecting two nodes in a network with reasonable accuracy. Using this known heuristic technique, the system may select a reasonable number of cost-effective routing paths, and calculate and store cost and traffic parameters associated with each of these routing paths.
Furthermore, it is known in the art that these heuristics can be used to approximately find the best route for one parameter, while imposing limitations on other parameters. Thus, for example, such heuristics may identify the most cost effective route for each of several quality or security levels.
Illustratively, the system may calculate, for each defined quality and traffic level, a cost-effective routing cost of five (or more, depending on the desired traffic flow) connections to each pair of nodes. These five routes may be sorted by price and stored in cost table database 400 of server node 56. Moreover, as the transaction progresses and the routes fill up, the system may determine additional routes, resulting in new network states.
Further, the routing path may be formed of several call legs, each using a different technology, according to the concepts in my co-pending application serial No. 08/727,681 (incorporated herein by reference in its entirety). For example, the routing path may include a first branch sent over a Public Switched Telephone Network (PSTN), a second branch sent over the internet, and a third branch sent over an ATM. As with the concept of my application serial No. 08/727,681, call legs of different technologies may be transparently linked to provide an end-to-end connection between a calling party and a called party, even though some intermediate legs in the routing path include technologies that are incompatible with both the calling party and the called party.
Once the cost table has been calculated and stored in the cost table database 400, a copy of the database may be sent to each node 44-49 in the network of telecommunications nodes. Alternatively, each node may receive only a subset of the cost table computed by the server node 56 by request. For example, a node in the United states may only receive a cost table associated with routes originating from the United states.
The updated cost table is preferably generated periodically by the system, for example, once every two weeks. Alternatively, cost table generation may be performed more frequently if the speed and capabilities of the system computer hardware and software permit. Indeed, with sufficient computing power, the system can update its tariff every time a charge or service parameter in the network changes.
The server node 56 allows the carrier to purchase connection time to a remote location in blocks, or to purchase connection time in successive transmissions. With this capability, the server node 56 can act as a clearing house for settling transactions between a provider carrier desiring to sell the connection service and a requesting carrier desiring to purchase the connection service. This aspect of the invention facilitates an open market for connection charges, allowing carriers to purchase bandwidth at the lowest available price. The transaction settlement aspect of the present invention will be described in connection with two illustrative examples. The first example illustrates a carrier purchasing a whole block of connection time and connecting the call using a fraction of the connection time purchased. A first illustrative example will be described in connection with fig. 5 and 6A-C. The second example illustrates purchasing connection time on a call-by-call basis.
Starting with the first illustrative example, assume that the U.S. carrier wishes to purchase a connection time of class "A" quality and class "B" reliability in Germany at a price of no more than 23 cents per minute in the month of 9. At step 502, the relevant country carrier makes a purchase request to the server node 56, in which case it requests the purchase of 1 million minutes of connection time to germany.
Preferably, the carrier enters the purchase request through a template 350 accessible at a web site maintained by the server node 56. Alternatively, a carrier owning and maintaining an international gateway switch (e.g., switches 22, 26, and 28) may send a purchase request to server node 56 through telecommunications nodes 44-48.
Figure 3B illustrates a suitable arrangement of such templates. As shown in fig. 3B, the template includes a plurality of fields for entering information regarding the purchase request. In a preferred embodiment, template 350 may include the following fields:
customer identification numberA field 352;
cipher codeA field 354;
origination locationA field 356;
termination locationA field 358;
require local termination?A domain 360;
require settlement?A domain 362;
time of operationA domain 364;
number of minutesA domain 366;
quality ofA domain 368;
maximum Post Dial Delay (PDD)A domain 370;
allowed private line?A domain 372;
sortingA domain 374;
length of contractA domain 376; and
acceptable carriersDomain 378.
As will be appreciated by those skilled in the art, the fields listed above are merely illustrative of the fields that template 350 may include. The template 350 may include any information field that facilitates the server node 56 in making routing decisions and brokering transactions between the provider carrier and the requester carrier.
As noted above, some provider carriers may not be able to provide local termination for certain calls. "require local termination? "Domain 360 allows the requester carrier to indicate that it can provide its own local termination at the terminating location and thus can use a carrier without termination capability to send calls to the called location.
As noted above, some providers may require that calls be terminated in a manner that references a settlement agreement. "require settlement? "field 362 allows the carrier to provide this information.
The "minutes" field 366 stores the number of minutes that the carrier wishes to purchase.
The "max PDD" field 370 stores the maximum number of seconds that the carrier is willing to accept to connect the calling party to the called party. This can affect the routes assigned to calls because some routes, particularly those with many call legs or satellite links, can take longer to connect than others.
As noted above, some carriers may not wish calls to be sent over a dedicated line. "allowed private line? "field 372 allows the requesting carrier to enter this information.
In the "sort" field 374, the carrier queues the fields in the template for the relevant business parameters in order of importance. For example, a carrier may rank quality as the most important domain, maximum PDD as the next most important, and so on. As described below, the server node 56 uses this information when the service request from the requesting carrier cannot be matched exactly.
In the "contract Length" field 376, the carrier may enter the number of months it wishes to purchase the connection time.
In the "acceptable carriers" field 378, the requesting carrier may restrict the flow of traffic through the carrier selected for transit. For example, the requesting carrier may request that only the top 5 carriers ordered by the server node 56 for some parameter (e.g., quality) send traffic streams. In another example, if a carrier wishes to purchase connection time to transport overflow traffic, it may request that time not be resell on its own network previously sold to a third party.
When the server node 56 receives the purchase order, the system proceeds to step 504 where the server node 56 searches the cost table database 400 in order of increasing price for routes that meet the request carrier's requirements and have connection times available for sale. When the server node 56 determines a route having available capacity, it allocates the capacity to satisfy the purchase request of the requesting carrier, as depicted in step 506. Step 504 and 506 are repeated until either the purchase request is satisfied or all available routes satisfying the request carrier's requirements have been traversed, as depicted in steps 508 and 510, respectively.
For example, assume that FIG. 6A represents a portion of the state of the cost table database 400 when a purchase request of 1 million voice minutes is received from the requesting carrier. In this case, the server node 56 would complete the loop described in step 504-510 three times to satisfy the request of the requesting carrier for 1 million minutes. At the end of the third cycle, 2 million minutes of capacity from the cheapest route, 4 million minutes of capacity from the next cheapest route, and 4 million minutes of capacity from the third cheapest route may be allocated to satisfy the purchase request of the requesting carrier. FIG. 6B represents the state of the expense table database 400 at the end of this illustrative example.
At step 512a, the server node 56 sends a data message to each carrier joining the routing path informing the carrier that the allocated block of connection time has found the purchaser. At step 512b, the provider carrier sends an authorization message to the server node 56 authorizing the transaction. Alternatively, the server node 56 may be pre-authorized to sell any time that the carrier submits to the world wide web.
At step 512c, server node 56 sends the service offering to originating node 44, submitting the allocated connection time block for sale. In step 512d, the originating node 44 sends an accept message to the server node 56. At step 512e, the server node 56 settles the transaction by adjusting the account balance for each carrier in the transaction to reflect the assigned connection time to the requesting carrier and the assigned connection time cost to the provider carrier, as described in more detail below, and sends a confirmation message to all parties.
Instead, assume that the cost table database 400 is as shown in FIG. 6 c. At this point, the server node 56 completes the loop described in steps 504-510 twice, during which 2 million minutes from the cheapest route and 4 million minutes from the less-expensive route are allocated to satisfy the requesting carrier's request. However, in the example of fig. 6C, all other routes connecting the united states and germany are more than 23 cents per minute. Thus, after the second loop traversal, step 510 fails and the system proceeds to step 514.
In step 514, the server node 56 sends a data message to the requesting carrier informing that its request cannot be fully satisfied at 23 cents per minute or less. The message also provides the requesting carrier with the next best price (e.g., 28 cents per minute) that can be used to ensure connection time between the united states and germany. The requesting carrier may respond to the message from the server node 56 in three ways, as depicted in step 516. First, the requesting carrier may issue an acceptance, in which case the server node 56 allocates a connection time (including a connection time of 28 cents per minute) to satisfy the requesting carrier's purchase request (step 518). At step 520, the server node 56 settles the transaction in a manner similar to that described in steps 512 a-e.
Second, the requesting carrier may issue a denial, in which case the server node 56 cancels the transaction, as depicted at step 522.
Third, the requesting carrier may accept the available minutes in connection time that meet the price requirements, even though the amount of connection time is less than originally requested. At this point, the server node 56 assigns a connection time to the requesting carrier that satisfies the conditions of the requesting carrier, as depicted in step 524. In step 526, the server node 56 settles the transaction in a manner similar to that described in steps 512 a-e.
The server node 56 maintains an operating account number relating to the time each carrier purchases or sells connections via the global network of the present invention. Thus, once authorization for the transaction has been given to the requesting carrier by the server node 56, the server node 56 adjusts the difference between the requesting carrier and the providing carrier to reflect the requesting carrier's purchase of the service from the providing carrier. The server node 56 periodically (e.g., monthly) sends a bill to the negatively poor carriers and forwards payment to the positively poor carriers. The server node 56 manages the settlement of all accounts in this manner. The server node also manages credit risk associated with the transaction. This may be done in collaboration with the financial services company.
If a carrier that purchased a block of connection time finds it unable to use the purchased capacity, it may resell the connection time (either in blocks or one connection transaction at a time) at a higher or lower price than originally purchased, depending on the market conditions at the time of the resell. The server may also support future and derivative connection time markets. The carrier may also use buy-sell time techniques to protect itself from large price fluctuations.
As will be appreciated by those skilled in the art, the above-described protocol for purchasing airtime blocks is illustrative, and other protocols may be used instead. For example, a carrier may request a block of connection time that meets the requirements of a particular service parameter, without specifying a price. In that case, the server node 56 may determine a block of airtime across one or more routes with the best available price that most closely matches the requested service parameters and provide the block to the carrier.
An overview of the global network call routing operation of the present invention will now be described in conjunction with figure 7. Each stage shown in fig. 7 will then be explained in more detail in connection with fig. 8-10.
As shown in fig. 7, the preferred embodiment uses three steps to handle the routing of any call from the calling phone to the called phone. In step (1), the connection is connected between the calling telephone 2 and the originating international gateway exchange 22. In step (2), the system assigns a routing path to connect the call to the called location. In step (3), a routing path is established and the calling party is connected to the called party.
The three-step process will be described using an illustrative example showing the routing of an exemplary call from an origination location to a termination location. As will be appreciated by those skilled in the art, this example provides a relatively simple set of possible call routing options. However, as noted in my co-pending application serial No. 08/811,071, a call from an originating location to a terminating location may be connected via a call routing path that includes a number of call legs, each of which bridges two locations in the call routing path. Further, as described herein, each leg may be completed in either the forward or reverse direction based on the connection time and availability of the type of requested traffic.
While this application incorporates my co-pending application 08/811,071, those skilled in the art will recognize that the concepts of the present invention may be applied to desired call routing including those with many call legs in the forward and reverse directions.
The illustrated call routing example will now be described in conjunction with fig. 1A. Turning to fig. 1A, assuming that the origination location of the call from calling telephone 2 to called telephone 4 is in the united states, originating toll switch 14 and originating international gateway switch 22 are owned and maintained by AT & t (tm). Further assume that the terminating location of the call is germany and that terminating long distance switch 18 and terminating international gateway switch 24 are owned and maintained by monopolized german telephone companies. It is further assumed that international gateway switch 28 is in the uk (u.k.) and is operated by british Telecommunications (TM) (BT). Finally, assume that international gateway switch 26 is in Belgium and is operated by Belgacom (TM), a Belgium carrier.
Further assume that the purchased 1 million minutes connection time described above in connection with fig. 5 is divided between three connection paths connecting the AT & T's international gateway switch 22 to the german telephone company's international gateway switch 24. Referring to fig. 1A, a first routing path connects the call directly to the international gateway switch 24 in germany via line 32. A second routing path connects the call through the u.k. international gateway switch 28 and lines 34, 38 to the international gateway switch 24. The third routing path connects the call to international gateway switch 24 through international gateway switch 26 and lines 30, 36 in belgium.
Step (1) of the process shown in fig. 7 will now be described in more detail in conjunction with the flow diagram shown in fig. 8. Turning to fig. 8, in step 802, the caller dials the telephone number of called telephone 4 from calling telephone 2. The dialed number typically includes a prefix (e.g., 011) indicating that the call is an international telephone call. The dialed number also includes a country code (e.g., 49 in germany) and an area code (e.g., 89 in munich) representing the foreign location of the dialed call. The local telephone network 6 is programmed to recognize foreign calls and route such calls to the caller's long distance carrier.
Thus, at step 804, the local telephone network 6 sends the appropriate SS7 signaling information regarding the call to originating toll switch 14 via line 16. The monitoring is thus passed to the originating toll switch 14. At the same time, the local telephone network 6 creates a path through the local telephone network transmission line to establish a connection between the calling telephone 2 and the originating toll switch 14, step 806.
From the signaling information, originating toll switch 14 identifies the call as a foreign call and routes the call to originating international gateway switch 22. Specifically, originating toll switch 14 sends the appropriate SS7 signaling information to originating international gateway switch 22 at step 808, thereby communicating the monitoring to switch 22. At the same time, the long distance network creates a path through its transmission line, establishing a connection between calling telephone 2 and originating international gateway exchange 22, step 810.
Thus, as described above, a transmission connection is established between the calling telephone 2 and the originating international gateway exchange 22 in step (1), and monitoring of the call is passed to the originating international gateway exchange 22.
In step (2), the system assigns a route for the call from calling telephone 2 to called telephone 4. Step (2) is described in more detail in connection with the flow diagram of fig. 9.
Turning to fig. 9, in step 902, the originating international gateway exchange 22 determines whether the called location can be reached by routing the call through the global network. If decision 902 fails, the international gateway switch 22 uses another approach for the connection to the called location, as shown at step 904. Otherwise, if decision step 902 is successful, international gateway switch 22 passes the monitoring to originating telecommunications node 44, as depicted at step 906, to route the call to the terminating location.
In step 90g, the node 44 retrieves from memory the routing path for which the originating carrier has purchased connection time. As noted above in connection with fig. 1B, node 44 provides several databases 99-97 for storing network pricing, publication pricing, and global pricing information for connecting calls to called locations. Thus, in decision step 909, node 44 compares the various prices obtained from databases 99-97 and determines whether to route the call through its own network connection or through a route purchased over the global network.
Decision step 909 may incorporate a process that applies complex business rules to determine which route should be selected to transport the traffic flow. For example, node 44 may be programmed to route a call through a global network route unless the price of that route is greater than 90% of the network price for connecting the call.
If decision step 909 fails, the system proceeds to connect the call via another route. If, however, decision step 909 is successful, the system proceeds to step 910 where the node 44 identifies the first routing path purchased through the global network and determines whether connection time is available to connect the call from the calling telephone 2 to the called telephone 4 through the routing path. This determination is made by sending a routing request to the server node 56. The server node 56 queries each node in the path for port availability for the transport call. If connection time is available, the server node sends a message to this end to node 44 and the system proceeds to step (3) to connect the call via the routing path, as described below. Otherwise, node 44 returns to step 910 to identify a second routing path and determine if connection time is available to connect the call from calling telephone 2 to called telephone 4. Step 910 is repeated until either a routing path with available connection time is found or all paths for which the carrier purchased time are traversed (step 912). If step 912 fails (i.e., there is no routing path for the connection time available), the system proceeds to step 914 and monitoring is passed back to gateway 22, which gateway 22 may route the call, typically via an alternate route, such as a regular settlement route or other overflow route. If no other route is available, a message may be sent to calling telephone 2 informing the caller that all lines are busy and requesting the caller to make a new call later.
Once the route with the available connection time is found, the system proceeds to step (3) of fig. 7, establishing the found route and connecting the caller to the called party. Step (3) of fig. 7 will be described in detail in conjunction with fig. 10.
As noted in the background of the invention above, it is not possible to agree on cost-effective and dynamic routing of calls through international gateway networks because of the lengthy agreed-upon protocol and physical reconfiguration required to establish new call routing. Without reconfiguration, the international gateway switch cannot distinguish the incoming terminating traffic flow from the incoming transit traffic flow or has no manual intervention for free-volume steering. As a result, all incoming traffic is handled as terminated traffic, charged at a high settlement agreement billing rate or based on existing pre-negotiated contracts and links that cannot be easily modified. As described in more detail below, the present invention overcomes this deficiency of the prior art, allowing for dynamic routing of transit and terminating traffic flows to a gateway switch in a gateway network or any other network.
For the purposes of this example, it is assumed that the routing decision made in step (2) of fig. 7 above is that the call from calling telephone 2 to called telephone 4 should be routed through the u.k. international gateway exchange 28.
The system then proceeds to step 1002 of the flow diagram depicted in fig. 10. In step 1002, the AT & T international gateway switch 22 establishes a transmission path for the call to the international gateway switch 28 based on instructions from the node 44 regarding routing, signaling, and appropriate connection ports and destination numbers to use. Meanwhile, at step 1004, node 44 sends an SS7 (or C7 or other suitable protocol) message to international gateway switch 28 over line 34.
The C7 message includes a code that informs the international gateway switch 28 that the call is not terminated at the u.k. call (i.e., the call is a transit call) and instructs the switch 28 to pass monitoring of the call to the telecommunications node 48.
The particular C7 code used to inform the international gateway switch 28 that the call is a transit call is not important as long as the gateway switch is configured to recognize that the C7 code is the initiation of a transit call. But at least two possible codes are currently contemplated to accomplish this task. First, the system may use a false area code that does not exist within the u.k. as a prefix to the dialed number sent in part of the C7 message. And a special country code may be used for this purpose. When the international gateway switch 28 sees a false area code, it immediately recognizes that the call is a transit call and passes the monitoring to the node 48. Alternatively, a new class of service codes may be defined and sent as part of the C7 message. The gateway switch recognizes the service code and recognizes the call as a transit call.
Also some telecommunications nodes may learn a point code, thus allowing the gateway to direct traffic to the node without using one of the above codes.
In any event, the system proceeds to step 1006, where international gateway switch 28 passes monitoring of the call to node 48. At step 1008, node 48 initiates a call through international gateway exchange 28 to the telephone number of german called telephone 4. Node 48 may be informed to route the call to germany through the SS7 network or through line 62.
In step 1010, the international gateway switch 28 establishes a transmission path to transmit the call to the international gateway switch 24 in germany. Also at step 1012, the international gateway switch 28 sends a C7 signaling message to the international gateway switch 24 informing the switch 24 that the incoming call is terminated in germany. International gateway switch 24 routes the call to called telephone 4 through terminating toll switch 18 and local network 10 at step 1014, thereby establishing a connection between the calling party and the called party.
When a call is terminated, each node joining the routing path sends a data message to server node 56 informing node 56 of the details of the call, including the length of the call. The server node 56 uses this information to update the account balance for each carrier participating in the routing path.
As noted in my co-pending application 08/811,071, the speed of the system may be increased by synchronizing the simultaneous establishment of two or more call legs in a routing path. Thus, in the illustrative example given above, several steps may be performed in parallel, for example establishing transmission paths from the united states to the united kingdom and from the united kingdom to germany, in order to increase the speed of the system. For example, upon receiving a request or indication for call routing, the uk node may verify that the trunk that sent the call to germany is available and that the destination (e.g., called telephone 4) is available.
It should be noted that when the gateway switch described above is IN compatible, the server node 56 recognizes this fact and informs the node 44. The node 44 may interact directly with the uk gateway using IN signaling instead of SS7 or C7. In this case the node 44 does not have to interact with the uk node 48. IN addition, node 44 may communicate directly with gateway 24 using IN signaling to determine, for example, whether called telephone 4 is off-hook.
More generally, while the present disclosure is incorporated in my co-pending application serial No. 08/728,670 (incorporated herein by reference in its entirety), it will be recognized that the present invention provides data signaling outside of a communication network using data lines in order to facilitate efficient call routing. As will be appreciated, the extent to which external data signaling is required will depend on the ability of the network signaling function to deliver the data messages necessary to operate the overlay network of the present invention.
In the first illustrative example described above, the carrier is requested to purchase a whole block of connection time. Alternatively, the purchase of connection time may be made on a call-by-call basis. A second example illustrating such a transaction will now be described in conjunction with fig. 11A-B.
As shown in fig. 11A-B, the system settles the successive call connection transaction using a 14-step protocol. When a call is received at gateway 22, the monitoring of the call is passed to node 44 in step 1101. At step 1102, the node 44 sends a service request to at least one server node 56. For purposes of this illustrative example, assume that node 44 sends a request to only one server node 56. However, as explained in more detail below, the node 44 may send service requests to multiple server nodes 56, each of which may be optimized for different parameters, such as price or network utilization.
At step 1103, the server node 56 processes the request and identifies the routing path that best meets the requirements of the requesting node, provided the server node 56 has optimized priority. For example, assume that the server node 56 finds the cheapest routing path that satisfies the traffic parameter requirements of the node 44.
At step 1104, server node 56 provides services to node 44, including details of the found route.
In decision step 1105, node 44 compares the provided other possible routes available for connecting the call from calling telephone 2 to called telephone 4. This determination may be based on complex business rules that the requesting carrier provides to the node 44. For example, as noted above in connection with fig. 1B, node 44 provides a network cost database that stores the carrier internal costs of connecting a call from gateway 22 to a called location. Node 44 may be programmed to accept offers from server node 56 only if the offers provided by server node 56 are less than 10% of the call's own internal cost of the network.
If decision step 1105 fails, node 44 sends a denial message to server node 56. This concludes the protocol.
Otherwise, if decision step 1105 is successful, the system proceeds to step 1106 where node 44 sends an acceptance to server node 56.
At step 1107, the server node 56 sends a data message to each node on the routing path requesting connection to the call service. The nodes along the path agree to provide the service and to do so send a data message to the server node 56, step 1108.
At step 1109, the server node 56 proxies the financial transaction resulting from the establishment of the routing path. As part of step 1109, the server node 56 reserves a portion of the credit limit of the requesting carrier in order to pay the call charge. The dollar amount retained is selected based on an estimate of how long the call will last. This estimation is based on historical call lengths.
At step 1110, server node 56 sends a confirmation message to node 44 confirming that the connection time on the found routing path was purchased. The message also preferably includes information regarding which port of gateway 22 the call is routed through, as well as the destination number and other service data necessary to complete the call to the called location.
Upon completion of the call at step 1111, each node on the routing path sends a transaction complete message, preferably including the length of the call, to the server node 56.
At step 1112, the server node 56 adjusts account balances of all carriers and node operators involved in the routing to reflect the cost of the call. The server node 56 sends a payment to the positive difference party and a bill to the negative difference party to settle all the carrier and node operator accounts at step 1113. Step 1113 may be performed periodically, such as once per month.
At step 1114, the server node 56 updates the capacity to reflect that the port just used to transmit the call is now clear and records the number of network time minutes used to transmit the call.
The node may also provide routing decisions based on complex business factors that the requesting carrier provides to its local node. For example if the cost is less than 20% of its own cost, assume that the carrier only wishes to purchase connection time over the world wide web unless it needs to overflow the connection time of the traffic flow. Such business factors may be transmitted to its local node, which evaluates the route suggested by the server node 56 based on the transmitted business factors. But the server node 56 typically cannot access these private business factors unless the system is a closed network, the node 56 being used to optimize capacity rather than price, as in the following example.
As noted, in the above embodiment, the originating node 44 is shown in communication with the server node 56, which is a single source of cost information and a single switch of communication capacity. In other embodiments, however, several servers may be used to communicate with node 44 in the same or similar manner as described above. In these further embodiments, each node 44-49 is connected to one or more servers.
In a multi-server embodiment, each server node 56 may order the possible routing paths according to a particular parameter or set of parameters. For example, some servers may rank routes according to price. The other servers order the routes in a manner that maximizes network utilization. A given carrier may provide its communication capacity on a server or servers. Since each server may rank the routes according to different priorities, a particular service query from an originating node may get a different proposed route from each server node 56.
Therefore, an originating node, such as node 44, connected to multiple server nodes 56 must store selection rules to determine which of several routes suggested by the different server nodes 56 to select. The decision to select a server may depend on various business factors and conditions specific to the carrier. For example, some carriers may first trade business with servers having a lower surcharge, while others may prefer servers that are known to provide a large amount of connection time for sale.
Those skilled in the art will appreciate that the particular choice may be programmed according to the particular business needs of the carrier. For example, some commercial companies may have a relationship or a particular degree of discount with a company that provides communication capacity, and the company may only provide on a particular server. In this case, the carrier may first attempt to purchase communication capacity from a particular server that provides a connection to the involved company before purchasing capacity on other servers. In another example, a carrier may prefer to purchase connection time from a server to which it has a relationship unless that server provides a price that is 10% (for example) higher than the price provided by a second server node 56 to which the carrier does not have a relationship. The node 44 is programmed to implement these business rules that the carrier provides to it.
The present invention also allows a carrier that owns or is associated with a node 44-49 to control its capacity according to a set of business rules. According to this aspect of the invention, if a node receives an amount of calls that exceeds or is close to the connection capacity it previously purchased to reach a given destination, the node may request that the server purchase additional minutes of connection time to accommodate such unforeseen demand. Additional capacity may be requested automatically when the call volume reaches a specified threshold, or by a system operator monitoring the conditions of the traffic flow.
Further, the node may include functionality to adjust resources based on actual and expected traffic flow conditions. It is known to track call traffic flow to a given destination and periodically store call volume measurements in a resource utilization database. Such data, which represents network utilization, in conjunction with other variables (e.g., time of day or day of week) may provide a basis for reasonably predicting capacity utilization within the next time interval (e.g., the next hour).
Subsequently, if the expected utilization exceeds the desired utilization level, the node may purchase additional capacity for the next time interval, such as connection time to the destination. Conversely, if the predicted utilization is less than desired, the node will provide additional minutes for sale at the next time interval.
For example, if the desired utilization is 80% of the purchase capacity, the node will purchase or sell capacity to adjust the expected utilization to 80%.
Fig. 12 illustrates a flow diagram of this functionality. At 1201, the system determines the current utilization by querying a utilization database and predicts an expected utilization for a next period of time (e.g., one hour) based on the current utilization and other factors (e.g., time of day and day of week) at 1202. At 1203, if the expected utilization over a period of time is approximately equal to the desired utilization, the execution terminates until a next period of time. (of course, as discussed previously, if traffic rises unexpectedly, the node should cope with this situation, purchasing additional capacity either automatically or at the direction of the operator).
If the expected utilization deviates significantly from the desired utilization (test 1024), the node therefore makes a next time to buy or sell capacity. If the predicted utilization will exceed the desired utilization, the node purchases additional capacity to bring the expected utilization to the desired level 1205. Similarly, if the predicted utilization is to be lower than desired, at 1206, the system sells excess capacity to restore the expected utilization to a desired level.
The desired utilization may be in the form of a formula that incorporates business factors. As a simple example, a node may be instructed to maintain a utilization of 80% capacity unless the purchase of additional connection time is above a certain price, or the sale of excess connection time is below a certain price. The business rules used by the nodes are much more complex than the simple example described above and take into account any factors desired by the carrier.
In a preferred embodiment, the system is capable of displaying market price information to prospective sellers and buyers of connection time. As described below, the display of market price information may preferably take the form of a streaming logo generated by a Java applet running on the client PC. In other embodiments, the information to be displayed may be in another form and/or displayed on another display device known in the art.
As shown in FIG. 13, in this preferred embodiment, the system architecture shown in FIG. 1A preferably further provides a market price monitoring subsystem 1300. The structure and operation of the market price monitoring subsystem 1300 is described in conjunction with fig. 14-18.
As shown in FIG. 14, the market price monitoring subsystem 1300 preferably includes a processor 1310 coupled to the server node 56 by a communication link 1320. In addition, the market price monitoring subsystem 1300 also includes a market price database 1330 and a customer database 1340. As explained in more detail below, the market price database 1330 stores market price information about communication routes managed by the server node 56. Customer database 1340 maintains a routing table that is meaningful to a particular customer so that the display of market price information can be customized for each customer. The subsystem 1300 is connected to a web server 1350 by a communication link 1360. Web server 1350 is connected to server node 56 by communication link 1325. Communication links 1320, 1325 and 1360 may be implemented over the internet.
A preferred embodiment of a portion of the market price database 1330 is shown in fig. 15. As shown in fig. 15, the market price database 1330 preferably includes an entry 1510 for each communication route through which the server node 56 is providing service. In a preferred embodiment, a route may be defined by the geographic location to which it is connected, the provisioned quality and level of service it guarantees, and the time of day that the connection time may be used. Alternatively, routes may be defined by additional, fewer, or other sets of parameters. Illustratively, the table may include a field for which the day of the week may use connection time, and a time period for which connection time may be used (e.g., 9/1 to 11/30 of 1998). In addition, the table may include an additional field that stores the amount of connection time for the specified route that is available for purchase. Thus, for example, as shown in fig. 15, the market price database 1330 may include separate entries 1510 for different routes connecting the united states and germany, including, for example, a first route providing a level "a" quality and a level "a" security between greenwich times 1PM and 7PM, and a second route providing a level "a" quality and a level "B" security between greenwich times 7PM and 1 AM. For each such item, the market price database 1330 stores a unique identification code 1520 and a price 1530 that the processor 1310 calculates as the market prices that make up the route. As described below, the processor 1310 may determine the market price using one of several techniques.
A preferred embodiment of a portion of customer database 1340 is shown in fig. 16. As shown in FIG. 16, customer database 1340 includes items 1610 for each system customer that purchases or sells airtime via server node 56. Customer database 1340 stores, for each customer having an item, one or more routes of interest to the customer. The routes stored for each customer may be determined by the customer's historical purchase patterns. Alternatively, the customer may be allowed to select a route of interest to the customer when logging onto Web server 1350. Thus, for example, the customer "austria telecommunications" may be of particular interest for voice quality, high security routing between france and austria and between germany and austria. In that case, customer database 1340 would store identifications 6435 and 6908 representing those routes of interest as part of the austrian telecommunications items of customer database 1340.
In addition, database 1340 preferably includes one or more default entries 1620, the stored identifications representing routes to be displayed to customers or system potential customers that do not have entries in customer database 1340. In a preferred embodiment, each default item may be associated with a particular location, such that a default route displayed to a customer having no items in customer database 1340 may be selected based on the customer's location, as described below. In another preferred embodiment, the default display may focus (at the customer's option) on trends in trade activities of interest to the customer, such as routes in which prices have undergone large variations and/or large trade amounts.
In operation, the processor 1310 monitors all transactions proxied by the server node 56 and, based on these monitored transactions, determines a market price for each defined route stored in the market price database 1330. As noted, the processor 1310 may determine the market price using one of several methods. In a preferred embodiment, the market price for a route may be determined as the price paid for the most recent transaction that includes parameters defining the route (e.g., geographic route, quality, security, etc.). The processor 1310 updates the market price stored for the route in the market price database 1330 each time it detects a transaction proxied by the server node 56. Alternatively, the market price for a route may be calculated as the average trading price for routes that the server node 56 has traded within the past hour or other time period.
When a client or potential client logs onto the web server 1350, the web server 1350 and the market price monitoring subsystem 1300 cooperate to display to the client the most up-to-date market information regarding the routes maintained by the selected server node 56, as now described in connection with FIGS. 17-18.
As shown in FIG. 17, when the client logs onto the Web server 1350, the Web server sends a data message to the processor 1310, preferably including the client's identification and/or the client's location, at step 1705. At step 1710, processor 1310 searches customer database 1340 to determine if the customer has an entry in the database. If the customer has an entry, the processor 1310 obtains from memory the route identification of the route of interest to the customer (step 1715). Otherwise, the processor 1310 obtains from memory the route identification of the default item associated with the customer location or other default items based on, for example, the particular trade propensity in which the customer is interested, as described above (step 1720). Alternatively, information about the routes that are of interest to the client may be stored on a cookie placed on the client's client PC browser by the Web server.
Processor 1310 obtains market prices for the identified routes and routing parameters (e.g., geographical route, quality level, security level, and time of day) from market price database 1330 at step 1725, and sends those information to web server 1350 over the communication link at step 1730. Web server 1350 causes the received information regarding the route of interest to the client to be displayed on the client PC, at step 1735. Alternatively, a portion of the received information may be displayed with respect to a subset of parameters defining the route. The subset of parameters to be displayed may be defined by the customer.
In a preferred embodiment, market price information is displayed to the customer in the form of a streaming banner generated by a Java applet or other software (for example) running on the customer PC or directly on Web server 1350. An example of an illustrative web page that includes such flow marks is shown in FIG. 18. The flow logo can be two or more rows high, if desired, to increase the amount of information displayed to the customer simultaneously.
In a preferred embodiment, if the price of the display route changes while the client is still online, processor 1310 sends updated market price information to web server 1350, server 1350 communicates with the Java applet on the client PC, updating the appropriate entries in the flow label, as shown in step 1740.
In a preferred embodiment, the customer can conveniently click on the displayed information to purchase the connection time on a display route. In that case, the system provides a template or other graphical interface directly to the customer, allowing the user to enter the amount of time to be purchased or sold, the asking price, etc. The system then proceeds to attempt the connection time required for the proxy transaction, purchase or sale, as described above.
While the invention has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description.
For example, although the description is primarily in connection with international telephone calls, the invention may also be used to improve network efficiency within a country.
Furthermore, although the description is primarily directed to a public network consisting of a plurality of carriers, the invention may also be used to efficiently manage a private network, or a network consisting of facilities maintained by a concerned carrier. In this case, the server node 56 is typically programmed to order the routing paths according to parameters rather than simple prices. For example, the network may order and allocate routes in a manner designed to maximize network infrastructure utilization.
Claims (13)
1. A method for displaying market prices from telecommunications transactions, comprising the steps of:
receiving, by a server node, service offerings from one or more telecommunication service vendors, each service offering a connection time block for sale, each service offering further specifying a plurality of parameters including price information for the offered connection time block;
identifying, by the server node, one or more routes for routing calls between a pair of locations according to parameters specified in one or more of the service offerings, each identified route including one or more legs, the service for each leg being provided by a telecommunications service provider;
receiving, by said server node, service requests from a plurality of telecommunication service buyers, each service request requesting the purchase of a block of connection time, each service request further specifying a plurality of parameters including a termination location of the requested block of connection time;
matching, by the server node, one or more of the service requests with one or more of the service offerings based on a plurality of parameters specified by the buyer and the vendor;
brokering, by the server node, a transaction to transfer ownership of at least a portion of the connection time blocks specified in the matched service offerings from one or more of the one or more vendors to one or more of the plurality of buyers providing corresponding matched service requests;
determining, by a market price monitoring system coupled to the server node, a market price for at least one identified route; and
the market price is displayed on a display device.
2. The method of claim 1, further comprising the step of displaying the market price as a flow mark on a display device.
3. The method of claim 2, wherein the height of the flow marks is two or more rows.
4. The method of claim 2, wherein the flow mark is applicable to a transaction, and the trade transaction for the at least one route is initiated by clicking on the displayed market price.
5. The method of claim 1, wherein the at least one route is defined by a plurality of parameters.
6. The method of claim 5, wherein the parameter comprises a geographical route.
7. The method of claim 6, wherein the parameters further comprise at least one of connection quality, connection security, time of day when the connection time is valid, day of week when the connection time is valid, and calendar time period when the connection time is valid.
8. The method of claim 5, wherein the market price is determined as the price paid to the most recent transaction that includes parameters defining the at least one route.
9. The method of claim 5, wherein the market price is determined as an average price for transactions including parameters defining the at least one route over a predetermined period of time.
10. A system for displaying market prices from telecommunications transactions, comprising:
means for receiving service offerings from one or more telecommunications service vendors, each service offering a connection time block for sale, each service offering further specifying a plurality of parameters including price information for the provided connection time block;
means for identifying one or more routes for routing calls between a pair of locations based on parameters specified in one or more of the service offerings, each identified route including one or more legs, the service for each leg being provided by a telecommunications service provider;
means for receiving service requests from a plurality of buyers of telecommunications service, each service request requesting the purchase of a block of connection time, each service request further specifying a plurality of parameters including a termination location of the requested block of connection time;
means for matching one or more of said service requests with one or more of said service offerings in accordance with a plurality of parameters specified by the buyer and the vendor;
means for brokering transactions to transfer ownership of at least a portion of the connection time blocks specified in the matched service offerings from one or more of the one or more vendors to one or more of the plurality of buyers providing corresponding matched service requests;
means for determining a market price for the at least one identified route; and
means for displaying the market price.
11. The system of claim 10, further comprising a memory for storing an account number for the vendor.
12. The system of claim 11, wherein the memory stores an account number of the purchaser.
13. The system of claim 12, further comprising means for updating the balance of the account number for each of the vendor and purchaser of the telecommunications service after the proxy transaction.
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US92056797A | 1997-08-29 | 1997-08-29 | |
US08/920567 | 1997-08-29 | ||
US08/927443 | 1997-09-11 | ||
US08/927,443 US6005926A (en) | 1997-08-29 | 1997-09-11 | Method and system for global communications network management |
US09/129,413 US6226365B1 (en) | 1997-08-29 | 1998-08-05 | Method and system for global communications network management and display of market-price information |
US09/129413 | 1998-08-05 |
Publications (2)
Publication Number | Publication Date |
---|---|
HK1074724A1 HK1074724A1 (en) | 2005-11-18 |
HK1074724B true HK1074724B (en) | 2011-01-14 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6226365B1 (en) | Method and system for global communications network management and display of market-price information | |
US6005926A (en) | Method and system for global communications network management | |
US6144727A (en) | Method and system for global telecommunications network management and display of market-price information | |
US6731729B2 (en) | Method and a system for settlement of trading accounts | |
US7515697B2 (en) | Method and a system for settlement of trading accounts | |
US6487283B2 (en) | Pricing center for internet protocol routed transactions | |
US6205211B1 (en) | Internet telephony call pricing center | |
JP3032157B2 (en) | How to route long distance calls | |
US6269157B1 (en) | Bidding for telecommunications traffic with request for service | |
US6996093B2 (en) | Architectures for clearing and settlement services between internet telephony clearinghouses | |
US6931109B1 (en) | Link selection parameter modification for network access selection | |
JP3083948B2 (en) | How to provide long distance telephone charge information | |
US9088628B2 (en) | Architectures for clearing and settlement services between internet telephony clearinghouses | |
HK1074724B (en) | Method and system for global communications network management and display of market-price information | |
WO2001052133A1 (en) | Apparatus and method for selling license of electrical communication facility and apparatus and method for distributing capacity of electrical communication facility | |
HK1038123B (en) | Method for global communications network management and display of market-price information | |
MXPA97003664A (en) | System and method for assigning route to calls, based on information of fixing prices of the call in time r | |
CA2327614A1 (en) | Toll telephone carrier selection system and method | |
JP2001036672A (en) | Method for connecting between operators, connection point selecting device using the same, and recording medium recording connection point selection program | |
MXPA97003668A (en) | System and method for fixing prices of telecommunication transactions |