WO2001082021A2

WO2001082021A2 - System and method for facilitating the trading of bandwidth

Info

Publication number: WO2001082021A2
Application number: PCT/IB2001/000917
Authority: WO
Inventors: Alexander Mashinsky
Original assignee: Alexander Mashinsky
Priority date: 2000-04-26
Filing date: 2001-04-26
Publication date: 2001-11-01
Also published as: AU5660101A; WO2001082021A3

Abstract

A method of trading IP bandwidth using a global computer network-based platform. The method includes establishing a plurality of connections between a first router (222) and a plurality of additional routers (1406, 1412). The method further includes the step of specifying a plurality of parameters that are descriptive of IP bandwidth services. The platform receives from a seller (14004) an offer to provide a quantity of IP bandwidth and from a buyer (1402) an order to buy the quantity of IP bandwidth. The platform then creates a route plan defining a set of routes for transmitting data traffic between the buyer's and seller's networks.

Description

SYSTEM AND METHOD FOR FACILITATING THE TRADING OF BANDWIDTH

Field of the Invention The invention relates to a system and method for trading telecommunications services. More specifically, the invention relates to a system and method for matching buyers and sellers of Internet bandwidth services and for controlling the provision of such services to efficiently utilize network resources.

Background of the Invention The Internet is a global system of interconnected physical networks including local area networks (LANs), wide area network (WANs), and routers that ,. connect two or more such networks. A router is typically a special purpose computer that transmits and receives data packets, called, datagrams, that are formatted in accordance with a suite of internetworking'protocols including .the Transmission Control < • . Protocol/Internet Protocol or TCP/IP. These internetworking protocols allow computers; on different networks, called hosts, to communicate with each other even if the two networks use incompatible hardware and message formats. Each host comprises communications hardware and software^'that interfaces with the particular physical network or networks to which the host attaches. When a first host wishes to send a message to a second host connected to a different physical network, it divides the message into one or more datagrams. Each data packet comprises a header and a payload. The header comprises the Internet Protocol (IP) address of the first host, the IP address of the second host, and additional information necessary to provide proper routing of the datagram. The payload comprises a portion of the message to be sent.

Because the two hosts are connected to different physical networks, the first host cannot transmit the datagram directly to the second host named in the datagram header. Rather, each datagram must be routed via one or more routers or through other computers. Collectively, these routers or other computers define a route connecting the two hosts. Thus, for example, if two networks are connected by a single router, the first host may transmit the datagram to the router which then forwards the datagram to the second host.

In many cases, however, the route connecting the two hosts may comprise several "hops." As shown for example in Fig. 1, a first host 102 connected to a first physical network 104 and a second host 106 connected to a second physical network 108 may be connected via a first route (route A) that comprises four hops. To transmit a datagram from host 102 to host 106, host 102 creates the datagram and transmits it to router 110 which then forwards the datagram to the next router in the route, router 112. Router 112 forwards the datagram to router 114 which forwards the datagram to its ultimate destination, host 106, through network 108. Thus, as each router in the route receives the datagram, it forwards the datagram to the next router or other computer in the route until the datagram reaches its ultimate destination host 106.

As further shown in Fig. 1, several different routes are often available to transmit datagrams between any pair of hosts 102, 106. Thus, for example, datagrams transmitted by host 102 to host 106 in the internet shown in Fig. 1 may be routed via the route defined by routers 110, 112, 114 (route A), or by routers 110, 118, 116 (route B), or routers 110, 116 (route C):„ . •

, When more than one route for routing traffic is available, it is not necessary . to route all traffic between two points via a single^' route. Rather, traffic between the two points is typically distributed over the different available routes. For example, if the three routes shown in Fig. 1 are available, 30% of the traffic may be routed via route A, 30% via route B, and 40% via route C. Moreover, because packets may reach their destination via any one of the available routes, communication between two points is not disabled if one of the routes becomes unavailable. Indeed, as known in the art, traffic is automatically redistributed to available routes when one or more routes become unavailable. In contrast, other communications systems, such as traditional voice telephone systems dedicate a specific connection from the calling telephone to the called telephone. That dedicated connection carries 100% of the information transmitted between those two points. Consequently, if that connection is disabled, communication ceases completely and an entirely new route must be formed and assigned. As is the case in all communications systems, Internet communications are limited by available bandwidth. As Internet usage has grown, it has become more important for Internet service providers to ensure that they have access to adequate bandwidth resources to satisfy the needs of their customers. Accordingly, a number of large Internet service providers have grouped together into private peering arrangements forcing smaller Internet service providers to pay a high premium for bandwidth or be relegated to low bandwidth service. In addition, in the current state of the art, bandwidth purchasers must purchase bandwidth based on their best estimate of their future bandwidth needs. When those estimates are inaccurate, the purchaser may find itself unable to use some of the purchased bandwidth or facing a shortage of bandwidth to meet its demand.

Summary of the Invention

The disclosed system addresses these drawbacks of the prior art by providing a spot market for purchase, sale, and delivery of Internet bandwidth and by facilitating the efficient management of Internet bandwidth use so as to minimize cost and maximize other business objectives. According to one aspect of thr present invention bandwidth is traded via an

- exchange comprising a server and a router. Buyers and sellers submit buy and selLorders . ^■ for.bandwidth to the exchange server. The exchange server matches the buy and. sell* . . ' orders. and generates a route plan for the exchange router on the basis of these matched orders. The route plan causes the exchange router to route traffic from each buyer to the seller with whom it was matched.

Brief Description of the Drawings The present invention will be better understood when taken in conjunction with the following detailed description and drawings, in which: Fig. 1 is a block diagram illustrating a prior art architecture comprising a plurality of distinct physical networks connected by routers to create an internet; Fig. 2 is a block diagram illustrating an architecture of a preferred embodiment of the present system;

Fig. 3 is a block diagram illustrating in more detail a portion of the system shown in Fig. 2;

Fig. 4 is a flowchart depicting a preferred embodiment for establishing a customer base; Fig. 5 is a flowchart depicting a first preferred trading embodiment of the present invention;

Fig. 6 is a preferred embodiment of a seller's template for inputting a sell order; Fig. 7 is a preferred embodiment of a buyer's template for inputting a buy order;

Fig. 8 is a schematic diagram of a preferred embodiment of a market book created by the present system;

Fig. 9 is a flowchart depicting a preferred embodiment for matching buy orders and sell orders;

Fig. 10 is a schematic diagram of a preferred embodiment of the buy side of the market book of Fig. 8;

Fig. 11 is a schematic diagram of a preferred embodiment of the sell side of the market book of Fig. 8; Fig. 12 is a schematic diagram of a preferred embodiment of a list of sell

: .' orders identified by the system of the present invention as matching a buy order;

Fig. 13 is a- schematic diagram of a preferred embodiment of the match list of the market book of Fig. 8; ^■" .'■ \

Fig. 14 is a block diagram illustrating a first preferred embodiment of an aspect of the architecture of the present system;

Fig. 15 is a block diagram illustrating a second preferred embodiment of the aspect of the architecture of the present system;

Fig. 16 is a block diagram illustrating a third preferred embodiment of the aspect of the architecture of the present system; Fig. 17 is a flowchart depicting a second preferred trading embodiment of the present invention;

Fig. 18 is a chart depicting a preferred embodiment of class definitions employed by the present invention;

Fig. 19 is a preferred embodiment of a seller's input template; Fig. 20 is a preferred embodiment of a buyer's input template;

Fig. 21 is a flowchart depicting a third preferred trading embodiment of the present invention; Fig. 22 is a block diagram illustrating a preferred embodiment of a multiple-exchanges embodiment of the present invention;

Fig. 23 is a flowchart depicting a multiple-exchanges trading embodiment of the present invention; Fig. 24 is a block diagram of a preferred graphical user tool for use in the present system;

Fig. 25 is a flowchart depicting a preferred embodiment for using the graphical user tool; and

Fig. 26 is a series of views depicting a preferred embodiment of the graphical images that may be displayed to a user during use of the graphical user tool.

Detailed Description of the Preferred Embodiment Fig. 2 is a block diagram illustrating a preferred embodiment of the present system. As shown in Fig. 2, the present system preferably comprises a plurality of Internet users 202. Internet users 202 each connect to a respective Internet service provider 204 via respective communication links 206. Communication links 206 may, for example, comprise a telephone link provided by the user's Local Exchange Carrier 208 (LEC) or Competing Local Exchange Carrier (CLEC) 210. In the alternative, Internet users 202 may connect directly to the exchange 218 via communication line 220 without going through an Internet service provider 204.

As further shown in Fig. 2, the present system further comprises a plurality of portals 212_ΪSP owned, typically, by ISPs 204. ISPs 204 provide Internet access to their users 202 by transmitting and receiving information from and to users 202 via portals 212ιsp. Each portal 212₁₈p may have associated with it a web server 214K_P that hosts a web site comprising a home page that is displayed to the user when the user logs on to the

Internet.

The architecture shown in Fig. 2 further comprises additional portals 212OTH operated by entities that are not necessarily Internet service providers (e.g., Yahoo (TM)). Each such portal 212₀TH may also have associated with it a web server 214OTH that hosts a web site comprising a home page displayed to the user when the user "goes to" the website.

Also shown in Fig. 2 are an additional plurality of web servers 214R each of which may host a web site. Web servers 214_R may, for example, be operated by retailers or other entities that wish to provide information, products, or services to users 202 via the Internet. As known in the art, users 202 may "surf" the Internet and reach the home page of a desired web site by either clicking on a link to the site displayed on a page that they are viewing or by entering on a command line the universal resource locator (URL) of the desired web site's home page.

Each portal 212 preferably comprises one or more routers for receiving and routing Internet datagrams in accordance with a route plan. Portals 212 are linked to each other and web servers 214 via respective communications links 216. In a preferred embodiment, portals 212 and web servers 214 are further connected to an exchange 218 via respective communication links 220. Although shown for clarity as a single line, lines 220 in fact represent two distinct links: a first traffic- carrying link for transmitting IP datagrams to and from exchange 218, and a second signaling link for transmitting control and signaling information to and from exchange 218, as described in more detail below.

Fig.: 3 is a. block diagram illustrating a preferred embodiment of exchange 218. As shown in Fig. 3, exchange 218 preferably comprises a plurality of exchange routers 222 connected to portals.212,and web servers 214 via communication links 220(a). In addition, exchange 218 preferably comprises an exchange server 224 that is connected to routers 222 via communication links 226 and to portals 212 and web servers 214 via communication links 220(b). Exchange server 224 preferably comprises a timer 228 used in certain operating embodiments as described in more detail below.

The above-described architecture facilitates the trading and efficient usage of Internet bandwidth, as described below.

A. Operational Overview

In a preferred embodiment, system operation comprises several aspects: First, exchange 218 establishes a relationship with a plurality of entities that become its customers. Second, exchange 218 collects buy and sell orders for communications bandwidth from these entities and matches them.

Third, exchange 218 uses the matched orders to create route plans for exchange routers 222 that implement the matched trades.

Fourth, exchange 218 routes traffic from buyers to sellers via exchange routers 222. The first aspect of system operation is described in section B below. The second, third, and fourth aspects of system operation are described in section C below.

B. Establishing a Customer Base

A preferred embodiment of the first aspect of system operation is now described in connection with Fig. 4. As shown in Fig. 4, in step 402, exchange 218 enters into a contractual arrangement with each of a plurality of entities. These entities typically include suppliers and users of communications bandwidth, such as portals 212 and web servers 214. In addition, exchange 218 may also establish contractual relationships with commodities traders, market makers, and others who help maintain market liquidity by buying and selling bandwidth via exchange 218, but who do not themselves expect to provide or use the communications services they buy or sell. In a preferred embodiment, the contracts executed by exchange 218 and

., > each entity, that wishes to become a customer thereof include terms specifying the -rights ;. -• .and-responsibilities iθf each, party to the contract. Each customer' s contractual obligations ^• run only to the exchange itself and not to other exchange customers. -For example; if a ;^'■ ' . particular customer undertakes to pay for Internet traffic routed via exchange 218, that promise is preferably enforceable solely by the exchange, and not by a particular seller that carried some or all of the buyer's traffic. Similarly, if the exchange undertakes to pay a particular customer to carry traffic, that promise is preferably enforceable by the customer only against exchange 218, and not directly against another customer of exchange 218. One effect of this contractual architecture is that two transactions actually occur whenever , traffic is routed via the exchange: a first transaction between a buyer and exchange 218 in which the buyer promises to pay exchange 218 to carry its traffic, and a second transaction between a seller and exchange 218, in which exchange 218 promises to pay the seller to deliver traffic routed via an exchange router 222.

In step 404, each customer establishes one or more physical connections with exchange 218. As described above in connection with Figs. 2 and 3, this physical connection preferably comprises two components, a traffic-carrying component and a signaling component. The traffic carrying component preferably comprises one or more links 220(a) connecting one or more routers belonging to the customer to one or more of exchange routers 222. The signaling component preferably comprises a link 220(b) connecting the customer to exchange 218 for carrying information concerning market information and the customer's available resources and needs, as described in more detail below.

In a preferred embodiment, the traffic-carrying connection 220(a) may comprise any known type of communication link such as electrical, optical, wireless, etc. In addition, the protocol for transmitting packets from the customer to exchange routers 222 may be any known protocol such as TCP. As described in more detail below, exchange 218 is provided with means for recognizing the type of hardware connection and protocol connecting the customer to exchange 218 and translating these appropriately so that the customer's traffic may be carried by any other customer of exchange 218.

C. Preferred Trading Embodiments 1. Trading Cycles Embodiment

_" • .■ •< ,. A first preferred trading embodiment is now described in connection with Fig. 5-. As will be explained in* detail below; this. preferred embodiment employs timer 228 to define a plurality of trading cycles. At the conclusion of each trading cycle, exchange 218 matches pending buy and sell orders and uses the matched orders to create route plans for exchange routers 222.

As shown in Fig. 5, in step 502, exchange server 224 sets timer 228 to a time T. In step 504, timer 228 begins to count down from time T to zero. When timer 228 reaches zero, the trading cycle concludes.

Time T is preferably chosen as a function of the processing speed of exchange server 224, as well as the number of exchange routers 222 and current trading volume. In particular, time T is preferably greater than the amount of time required by exchange server 224 to match all pending buy and sell orders and update the route plans for exchange routers 222 so that these tasks may be completed before the end of the next trading cycle. For example, for a given trading volume, number of exchange routers 222, and exchange server 224, a trading cycle of approximately 5 minutes may be desirable. In contrast, different values may make a cycle time as short as approximately 10 seconds appropriate. During the trading cycle, each portal 212 that wishes to sell Internet bandwidth via exchange 218 (i.e., wishes to promise to carry another entity's traffic in return for some renumeration) transmits a sell order comprising a plurality of parameters to exchange server 224 via a communication link 220(b), as shown in step 506. In a preferred embodiment, the plurality of parameters may comprise: termination location(s); origination location(s); duration; time of day; day of week; minimum price; capacity; maximum latency; maximum packet loss; circuit availability; protocol; and hardware.

These parameters are described as follows.

The termination location(s) parameter specifies the location or locations at which traffic may be terminated under the terms of the sell order. In a preferred embodiment, this parameter may be specified either as a physical termination location (e.g., a specific portal 112), as a plurality of physical termination locations (e.g., any one of a set of 250,000 IP addresses), or as a virtual destination location (e.g., termination to some AOL router without specifying which): Moreover, this parameter may be specified as a virtual destination with some physical limitation. Thus, for example, the termination location(s) may specify that traffic must be delivered to an AOL router in the United States without specifying the specific physical router. In a further preferred embodiment, the seller may specify this parameter to be "any location." In this case, traffic may be terminated at any location under the terms of the sell order. The origination location(s) parameter specifies the location or locations from which traffic may originate under the terms of the sell order. As known in the art, the origination location of a data packet may be identified by examining, for example, the sender address in the data packet. In a preferred embodiment, this parameter may be specified either as a physical origination location (e.g., a specific portal 112), as a plurality of physical origination locations (e.g., any one of a set of 250,000 IP addresses), or as a virtual origination location (e.g., origination from some AOL router without specifying which). Moreover, the origination location may be specified as a virtual location with some physical limitation. Thus, for example, the origination location may specify that traffic must originate from an AOL router in the United States without specifying the specific physical router. In a further preferred embodiment, the seller may specify this parameter to be "any location." In this case, traffic may originate from any origination location under the terms of the sell order.

The duration parameter specifies the calendar period for which service is offered.

The time-of-day parameter specifies the time of day (typically in hours Universal time) for which service is offered. The day-of-week parameter specifies the days of the week for which service is offered. In a preferred embodiment, the sell order may specify the particular days of the week for which service is offered (e.g., the order may offer service for Sunday, Tuesday, and Wednesday only) or may offer service for business days, weekend days, holidays, etc. The minimum-price parameter specifies the minimum price at which service is offered.

The capacity parameter specifies the maximum capacity offered under the terms of the sell order.

The maximum-latency parameter specifies the maximum latency for packets transmitted under the terms of the sell order. The maximum-packet-loss parameter specifies the maximum packet loss rate for packets transmitted under the terms of the sell order.

The circuit-availability parameter specifies the minimum amount of time that a circuit will be available to deliver traffic (typically as a percentage of the entire period specified by the duration, time of day, and day of week specified in the sell order) under the terms of the sell order.

The protocol parameter specifies the protocol used to carry packets over the sellers connection 220(a) to exchange 218. The hardware parameter specifies the type of hardware connection that connects the seller to exchange 218.

In a further preferred embodiment, the sell order may also comprise additional parameters. These may include: preferred buyers; and my network status;

The preferred-buyers parameter specifies entities whose traffic the seller would prefer to carry. For example, the seller might prefer to carry the traffic of a particular entity if the seller's peering arrangement with the entity requires it to carry a certain amount of the entity's traffic.

The my-network-status parameter specifies conditions for the sell order relating to the operating condition of the seller's network. For example, the seller may specify a first price for carrying traffic if its network congestion is below a certain level, and a second price for carrying traffic if its network congestion is above that level. An example illustrating this aspect of the present system is described in more detail below.

• ; In a preferred embodiment,- sellers may submit sell orders via a template :• i ... 600 which may be accessedat.a secure web site, maintained by exchange' server 224.!.' Fig. > . 6 illustrates a suitable arrangement for such template. As shown in Fig. 6, template.600 ■ preferably comprises a plurality of fields for entering information concerning the parameters described above. In a preferred embodiment, some of the entries shown in Fig.

6 may be automatically filled in by the seller's computer. For example, when the seller has only a single traffic -carrying connection to exchange 218, the seller's computer may preferably fill in the hardware and protocol entries automatically since they do not change from order to order. In addition, the seller's computer may be adapted to automatically fill in default values for one or more entries based on past sell orders submitted by the seller. These default entries may then be adopted by the seller or changed if the seller wishes.

In a preferred embodiment, fields of the sell order that relate to the quality of the offered service (e.g., latency) may be populated or verified by the exchange on the basis of historical quality information collected by the exchange as described below.

In a preferred embodiment, in step 508, each portal 212 that submitted a sell order downloads information concerning its available communications resources and needs to exchange server 224. Thus, for example, if a particular portal has purchased or sold 10 Mb/s of bandwidth for the next three months at a flat rate from/to an alternative supplier/customer, this information is downloaded to exchange server 224. As described in more detail below, exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources.

Because, in this preferred embodiment, exchange server 224 is given access to portal 212's confidential communications information, additional confidentiality features may preferably be associated with the collection, storage, and usage of this data to ensure that the owner of portal 212 feels comfortable releasing the data to exchange 218 and to ensure that the data is not misused or obtained by entities that are not entitled to it. In particular, these additional safety features may include transmission via stronger encryption techniques than those that may be employed in connection with other system transmissions. In addition, these safety features may comprise storage of a portal 212's proprietary data in a secure location with limited access by specified personnel. The entity

• that owns exchange 218 may also obligate itself by contract to protect this sensitive' < ; i« information and may accept specific sanctions if the information is improperly used or « >^■ ■ otherwise disclosed to others. . ,.' ^■ "-

In step 510, each portal 212 or web server 214 that wishes to purchase IP bandwidth (i.e., wishes to pay another entity to route its traffic to a particular destination), transmits a buy order to exchange server 224 via a respective communication link 220(b). In a preferred embodiment, the buy orders may take the form of continuous limit orders. A continuous limit order is an order by a buyer to purchase, on a continuing basis, any IP bandwidth meeting the parameters specified in the buy order as long as such purchase does not conflict with some other business objective specified by the buyer to exchange server

224, as described in more detail below.

In a preferred embodiment, a buy order may comprise the following parameters: termination location(s); origination location(s); time of day; day of week; maximum price; minimum capacity; maximum latency; maximum packet loss; minimum circuit availability; protocol; and hardware.

A description of each of the above parameters is provided below. The termination location(s) parameter specifies the termination location or locations for service is requested. As noted, this parameter may be specified as one or more physical termination locations, a virtual termination location, a virtual destination with some physical limitation, or as "any location".

The origination location(s) parameter specifies the origination location or locations for which service is requested. As noted, this parameter may be specified either as one or more physical origination locations, a virtual origination location, a virtual location with some physical limitation; or as '-'any location."

The time-of-day parameter, specifies the time of day (typically in hours Universal time) for which service is requested.

The day-of-week parameter specifies the days of the week for which service is requested. As noted, this parameter may specify each day separately (e.g., Sunday,

Tuesday, and Wednesday only) or may seek service specifically for business days, weekend days, holidays, etc.

The maximum-price parameter specifies the maximum price that the seller is willing to pay for service. The minimum-capacity parameter specifies the minimum capacity acceptable to the buyer under the terms of the buy order.

The maximum-latency parameter specifies the maximum latency acceptable to the buyer.

The maximum-packet-loss parameter specifies the maximum packet loss rate acceptable to the buyer.

The minimum-circuit-availability parameter specifies the minimum amount of time that the circuit must be available to deliver traffic (typically as a percentage of the entire period specified by the duration, time of day, and day of week specified in the buy order) under the terms of the buy order.

The protocol parameter specifies the protocol used to carry packets over the buyer's connection 220(a) to exchange 218. The hardware parameter specifies the type of hardware connecting the buyer and exchange 218 (e.g., ATM, SDH, etc.).

In a further preferred embodiment, the buy order may also comprise additional parameters. These may include: preferred sellers; and my network status;

The preferred-sellers parameter specifies entities whose service the buyer would prefer to use. For example, the buyer might prefer to have its traffic carried by a particular entity if , under the buyer's peering arrangement with the entity, the entity is required to route a certain amount of the buyer's traffic. The my-network-status parameter specifies conditions for the buy order relating tosthe operating condition of the buyer' s network.. For example, the buyer may specify a first price that it is willing to pay for service if its network congestion's below a certain level, and a second price for carrying traffic if its network congestion is above that level. An example illustrating this aspect of the present system is described in more detail below.

In an alternative embodiment, rather than submitting continuous limit orders, buyers may submit buy orders that specify a duration during which service is desired. For ease of illustration, all buy orders discussed in the remainder of this specification will be assumed to be continuous limit orders unless otherwise noted. It will be understood, however, that the discussion below may be tailored to apply to buy orders that specify a duration.

In a preferred embodiment, buyers may submit buy orders via a template 700 which may be accessed at a secure web site maintained by exchange server 224. Fig. 7 illustrates a suitable arrangement for such a template. As shown in Fig. 7, template 700 preferably comprises a plurality of fields for entering information concerning the parameters described above. In a preferred embodiment, some of the entries shown in Fig. 7 may be automatically filled in by the buyer's computer. For example, when the buyer has only a single traffic-carrying connection to exchange 218, the buyer's computer may preferably fill in the hardware and protocol entries automatically since they do not change from order to order.

In addition, the buyer's computer may be adapted to automatically fill in default values for one or more entries based on past buy orders submitted by the buyer.

These default entries may then be adopted by the buyer or changed if the buyer wishes.

In a preferred embodiment, in step 512, each portal 212 and web server 214 that submitted a buy order downloads information concerning its available communications resources and needs to exchange server 224. Thus, for example, if a particular portal has purchased or sold 10 Mb/s of bandwidth for the next three months at a flat rate from/to an alternative supplier/customer, this information is downloaded to exchange server 224. As described in more detail below, exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources. Since, in this preferred embodiment, exchange server 224 is given access to portal 212's- confidential communications, information, additional confidentiality features may preferably be associated with the collection, storage, and usage of this data as described above.

In step 514, timer 228 expires. At that time, two events occur. First, the system branches back to step 502 to reset timer 228 and begin a new trading cycle.

Second, exchange server 224 begins a series of steps to match current sell orders and buy orders and update the route plans of exchange routers 222 (steps 516-522).

In step 516, exchange server 224 uses the received sell orders and buy orders to update a market "book" 800 that provides a snapshot of the market for Internet bandwidth services. A preferred embodiment of market book 800 is schematically illustrated in Fig. 8.

As shown in Fig. 8, market book 800 preferably comprises three sections: a sell side 802, a buy side 804, and a match list 806. Sell side 802 stores all pending unfilled sell orders received by exchange server 224 during this and previous trading cycles. Buy side 804 stores all pending unfilled buy orders received by exchange server 224 during this and previous trading cycles. Finally, match list 806 stores a list of matched buy and sell orders. Each entry in the list represents a set of market and network conditions under which the buyer and seller have agreed to route the buyer's traffic, as described in more detail below.

In step 518, exchange server 224 matches sell orders from sell side 802 to buy orders from buy side 804 to create match list 806. A preferred algorithm for matching sell orders and buy orders will now be described in connection with Fig. 9.

As shown in Fig. 9, in step 902, exchange server 224 determines whether the market is a buyer's market (i.e., supply exceeds demand) or a seller's market (i.e., demand exceeds supply). This determination may significantly affect the algorithm used to match buy orders and sell orders. In particular, it should be recognized that in a buyer's market it is typically not necessary to prioritize the buy orders before matching them, because sell side 802 contains adequate capacity to satisfy all of the demand represented by buy side 804. In a seller's market, by contrast, buy orders are preferably prioritized before matching because there is inadequate supply to fill every buy order.

Conversely, in a buyer's market, it is typically desirable to prioritize the sell orders in sell side 802, since a large number of sellers are chasing few buy orders, while such prioritization may be unnecessary in a seller' s market, since all sell orders will most likely be filled.

In a preferred embodiment, when prioritization of buy orders is necessary, they may be prioritized first on the basis of price, and then on the basis of other parameters such as minimum acceptable capacity and maximum acceptable latency. Buy orders specifying higher tolerance levels are preferably given higher priority since such orders will remain matchable despite fluctuations in latency, capacity, etc. in sell orders submitted by sellers. Alternatively, buy orders may be prioritized on a first-come first-served basis. Thus, the buyer who first submitted a bid matching one or more sell-orders may be allocated bandwidth specified in those orders before other buyers. Alternatively, exchange server 224 may identify all buy orders received within a specified period of time (e.g., one second, one minute, 10 minutes, etc.) and allocate available bandwidth to those buy orders in a manner designed to maximize the total amount of bandwidth sold. Also, exchange server 224 may employ an auction methodology, such as, for example, a Nickrey-style auction, for allocating available bandwidth between competing buy orders.

Returning to Fig. 9, if in step 902 exchange server 224 determines that there exists a buyer's market, the system proceeds to step 904 where exchange server 24 identifies every sell order that matches a buy order, as will be described below. In contrast, if in step 902 exchange server 224 determines that there exists a seller's market, the system proceeds to a processing branch (not shown) where buyer's orders would be prioritized. It should also be recognized that the above analysis may be applied on a submarket by submarket basis. For example, demand for a particular type or quality of service may outstrip supply (traffic for determination at APL), while demand for another type or quality of service may be inadequate to fill the available supply. Thus, in a preferred embodiment, the system may be designed to distinguish in step 902 between buyer's submarkets and seller's submarkets, and to treat each such submarket independently in accordance with the principles described above.

In the present state of the art, however, supply typically outstrips demand both in the market as a whole, and in most relevant submarkets. Consequently, for ease of illustration, the description below will concentrate on the most common case in which a buyer's market prevails. It will be recognized, however, that the principles described below may be _^applied in an analogous manner, to match buy orders and sell orders in a., seller' s market, or on a submarket by submarket basis, if desired. ^{■ '}:•

'. Thus; assuming that in step 902 exchange server 224 has determined that a ^■ buyer's market exists, the system proceeds to step 904, where exchange server 224 identifies, for each pending buy order, every sell order on sell side 802 that matches the buy order. An illustrative example of step 904 will now be described in connection with Figs. 10 and 11.

It will be understood that this example represents a simple set of buy orders and sell orders to illustrate the principles of operation of the present embodiment. These principles may, of course, be applied to more complicated examples, such as buy orders and sell orders that specify more or other parameters.

Fig. 10A is an illustrative example of buy side 804 before step 904 is performed. Exchange server 224 preferably sorts the received buy orders by, e.g., termination destination and develops a data structure comprising information concerning buy orders that it has received. As will be recognized, the data structure shown in Fig. 10A will typically constitute only a fraction of the total data structure created by exchange server 224 to categorize unfilled buy orders. Buy side 804 shown in Fig. 10A comprises five buy orders 1002-1010. As will be recognized, buy orders 1002-1010 comprise the preferred parameters specified above. It will be recognized, however, that the principles elucidated in this example may be applied to buy and sell orders containing additional or other parameters. Fig. 11 A is an illustrative example of sell side 804 before step 904 is performed. Exchange server 224 preferably sorts the received information by, e.g., termination destination and develops a data structure comprising information concerning the available bandwidth for sale specified in unfilled sell orders that it has received. As will be recognized, the data structure shown in Fig. 11A will typically constitute only a fraction of the total data structure created by exchange server 224 to categorize unfilled sell orders. Sell side 804 shown in Fig. 11A comprises seven sell orders 1102-1114. As will be recognized, sell orders 1102-1114 comprise the preferred parameters described above. It will be recognized, however, that the principles elucidated in this example may be applied to buy and sell orders containing additional or other parameters. As noted, in step 904, exchange server 224 identifies, for each buy order, every sell order that meets the buy order's criteria. Thus, for example,- for buy order 1002/ exchange server 224 identifies sell orders 1;104, 1106;: and 1-112 as satisfying buy order 1002 and sell orders 1102, 1108, and lllO as not satisfying buy order 1002. FigM2A illustrates the list of orders that exchange server 224 would create in performing step 904 for buy order 1002 in this illustrative example.

In step 906, exchange server 224 determines whether there are any buy orders that do not have matching sell orders. It should be noted that because, as described above, bandwidth oversupply is the typical case in the present state of the art, one would not expect a buy order to have no matching sell orders unless it specified a price below market price (e.g. buy order 1006). In any event, if no matching sell orders are identified for a particular buy order, the system proceeds to step 916 to inform the buyer that it must modify its buy order if it wishes to purchase bandwidth via the exchange, as described in more detail below.

In contrast, for buy orders that are satisfied by at least one sell order, exchange server 224 proceeds to step 908 where it prioritizes the sell orders identified as satisfying the buy order on the basis of one or more parameters. In a preferred embodiment, the identified sell orders may first be prioritized on the basis of price and then on the basis of other parameters. In a preferred embodiment, the other parameters may include specificity of address block offered, latency, packet type, stream type, specifics such as UDP, TCP, duration, day of week, and time of day.

In a further preferred embodiment, the order of parameters employed by exchange server 224 to prioritize the list of satisfying sell orders may be specified by the buyer. For example, if the buyer who submitted buy order 1002 specified that it wishes matching sell orders to be prioritized on the basis of price, latency, and capacity, in that order, then exchange server 224 will prioritize sell orders 1104, 1106, 1112, on this basis. Fig. 12B illustrates the prioritized list of sell orders that would be created for buy order 1002 by exchange server 224 in performing step 908 in this illustrative example.

In step 910, exchange server 224 matches buy order 1002 to the highest rated sell order in the prioritized list and enters the match on match list 806 of market book 800. When more than one buy order is matched to the same sell order and the capacity specified in the sell order is inadequate to satisfy all buy orders to which it has been matched, the system may allocate the sell order's capacity to one or more of the buy orders

- ^■ i on several bases. For. example, the system.may employ a protocol that allocates⁵ available ; bandwidth to buyers on a first-come first-served. basis..' Thus, the first buyer to submit a bid . matching one or more sell-orders may be allocated the available bandwidth specified, in ..- those orders. Alternatively, it may employ a protocol that identifies all buy orders received within a specified period of time (e.g., one second, one minute, 10 minutes, etc.) and allocates available bandwidth to those buy orders in a manner designed to maximize the total amount of bandwidth sold. Also, the protocol may employ an auction methodology such as, for example, a Nickrey-style auction, for allocating available bandwidth between competing buy orders. Fig. 13 represents the state of match list 806 after exchange server 224 performs step 910.

In step 912, exchange server 224 updates buy side 804 to reflect the fact that buy order 1002 has been matched. It should be noted that because buy order 1002 is, in this preferred embodiment, a continuous limit order, exchange server 224 does not delete or otherwise modify buy order 1002 other than to indicate that the order has been matched for this trading cycle. Fig. 10B represents the state of buy side 804 after exchange server 224 performs step 912 for buy order 1002 in this illustrative example.

In step 914, exchange server 224 updates sell side 802 to reflect the match. In particular, exchange server 224 updates the capacity field of sell order 1106 to indicate the decreased available capacity as a result of the commitment to carry the traffic specified in buy order 1002. It will be noted that in the particular illustrative example being discussed, buy order 1002 asked for 20 Mb/s of capacity, while sell order 1106 offered 100 Mb/s of capacity. Accordingly, in updating sell side 802, exchange server 224 decreases the offered capacity in sell order 1106 from 100 Mb/s to 80 Mb/s to indicate that 20% of the capacity offered in sell order 1106 has been allocated. Fig. 11B represents the state of sell side 802 after exchange server 224 performs step 914.

As noted above, if in step 906, exchange server 224 determines that there are no matching sell orders for a buy order, the system branches to step 916 where exchange server 224 transmits a message to the buyer that its order cannot be matched under current market conditions, and recommends that the buyer modify its buy order. In a preferred embodiment, the message may be transmitted by e-mail. In a further preferred embodiment, message may be transmitted as a pager message. In a further preferred embodiment, an employee of the buyer may be provided with a two-way pager that permits the buyer to immediately respond to the pager message with a modified order. ' - In a further preferred embodiment, the system may recommend a particular modification that would improve the buyer's likelihood of matching with a sell order. In a further preferred embodiment, exchange server 224 may accept a modification to the buyer' s buy order during the trading cycle and attempt to immediately match the modified buy order to ensure that the buyer does not need to go an entire trading cycle without receiving service.

Once exchange server finishes constructing match list 806, the system returns to step 520 of Fig. 5 where exchange server 224 uses matched list 806 to create a route plan for each exchange router 222. A preferred embodiment for creating these route plans is now described in connection with Fig. 14. This description will continue to employ the illustrative example described above in which buy order 1002 was matched to sell order 1106. It will be assumed that buy order 1002 was submitted by a buyer 1402 and sell order 1106 was submitted by a seller 1404, shown in Fig. 14. As shown in Fig. 14, buyer 1402 maintains a router 1406 under control of a server 1408. Router 1406 is connected to a first port 1410 of exchange router 222 via link 220(a). Server 1408 is connected to exchange server 224 via link 220(b). As further shown in Fig. 14, seller 1404 maintains a router 1412 under control of a server 1414. Router 1412 is connected to a second port 1416 of exchange router 222 via a link 220(a). Server 1414 is connected to exchange server 224 via a link 220(b). Because, in this illustrative example, buyer 1402 submitted a buy order that was matched with 20% of the capacity specified in seller 1404's sell order, exchange server 224 specifies in the route plan for exchange router 222 that traffic received on router port 1410 should be routed out via router port 1416 to seller 1404's router 1412. This process is repeated for each matched set of orders in matched list 806. In step 522, exchange server 224 loads the route plans created in step 520 into exchange routers 222. In a preferred embodiment, exchange routers 222 may issue Border Gateway Protocol (BGP) announcements regarding their routing plans. A description of BGP may be found in "A Border Gateway Protocol 4 (BGP-4)," RFC 1771 (Y. Rekhter & T. Li, Eds., March 1995), which is incorporated herein by reference. In step 524, each exchange router 222 begins to route traffic delivered to it as specified in its respective route plan. In a preferred embodiment, market book 800 and the route plans ^■. that are based on it are not disclosed to sellers or buyers so that buyers do not know.which' seller will carry its next data packet, and sellers do not know from which buyer the next packet routed to them will come, before the packets are routed via the exchange. Another example is described in connection with Fig. 15. Many of the components in Fig. 15 are the same as those depicted in Fig. 14, and similar elements in the two figures are designated by like reference numerals.

In the example illustrated in Fig. 15, however, an additional router 1502 belonging to seller 1404 is connected to exchange 218. It will be assumed for purposes of this additional example that the seller wishes to use router 1412 as the first hop in a route that carries traffic to a first network having IP address 128.211.0.0, while using router 1502 as the first hop in a route that carries traffic to a second network having IP address 114.206.0.0. Thus, in generating the route plan for exchange router 222, exchange server 224 specifies that traffic received by router 222 that is addressed to a host on the first network should be routed to router 1412, and traffic addressed to a host on the second network should be routed to router 1502.

It should be noted that in the examples given above, each of buyer router 1406 and seller routers 1412, 1502 are connected to the same exchange router 222. It will be recognized, however, as illustrated in Fig.16, that in some cases buyer router 1406 may be connected to a first exchange router 222a while seller routers 1412, 1502 may be connected to a different exchange router 222b. In that case, exchange server 224 instructs router 222a (via its route plan) to route traffic received from router 1406 to exchange router 222b via an internal exchange link 226, and instructs router 222b (via its route plan) to route that incoming traffic to an appropriate one of routers 1412, 1502.

It should further be noted that in the examples given above, it may be the case that the buyer connects to the exchange via a hardware and/or protocol that differs from that used by the seller to connect to the exchange. Accordingly, in a preferred embodiment, exchange 218 is preferably provided with conversion modules for translating incoming data packets from the buyer into a format that is compatible with the seller's equipment.

In a preferred embodiment, the system ensures that buyers actually receive the level of service or quality of service that they have purchased. To facilitate this object of the present system, in step 526, exchange 218.continuously .monitors the level- Of service provided by each, seller to ensure thatit does not fall below the level of service specified n the sell order. If the level of service provided falls below that specified in the sell order, ' . the system responds by causing the buyer's traffic to be rerouted via alternative routes, as described in more detail below.

In a preferred embodiment, service monitoring may be achieved using one or more of a plurality of monitoring tools. For example, exchange server 224 may run continuous ping and other quality measurement utilities that mimic actual data transfer in order to record each seller's performance. This data may also be used instead of data submitted by the seller in prioritizing sell orders as described in step 506 above.

In step 528, exchange server 224 determines whether a particular service has degraded beyond an acceptable level. In a preferred embodiment, the buyer may specify what constitutes an unacceptable level of degradation of service. In a further preferred embodiment, the buyer may specify unacceptable levels of service as a percentage difference between the actual level of service that it is receiving and the level of service specified in its buy order. Thus, for example, the buyer's buy order may specify a latency no greater than a specified amount, but the buyer may further specify that, during a trading cycle, it is willing to accept fluctuations in this value of 20% or less.

In a further preferred embodiment, the buyer may specify acceptable levels of service as a percentage change from the mean level available in the market. For example, rather than specify a particular maximum latency, the buyer may specify that it is willing to accept any latency within 20% of the mean latency in the market as a whole for the type of service that it has purchased.

In a further preferred embodiment, the buyer may specify acceptable levels of service as a percentage change from the mean of a group of parameters. For example, if the buyer's buy order specified a latency no greater than a first specified amount and packet loss no greater than a second specified amount, the buyer may specify that it is willing to accept any degradation in service during a trading cycle as long as the composite change in those two parameters is not greater than 20%.

If, in step 528, service has not degraded to a point requiring action by the system, the system returns to step 526 to continue monitoring service quality provided by each seller. If, however, an unacceptable degradation of service is detected, the system proceeds to step 530 where it is determined whether, given the current stage in the trading cycle, it is worthwhile to block the seller from continuing to provide service to the' buyer. For example, if only a few seconds remain before the conclusion of a five minute trading cycle, the system may determine not to take action, but simply to allow the cycle to conclude (step 531).

Otherwise, if action is deemed warranted in step 530, the system proceeds to step 532 where the buyer is notified of the change in conditions. Concurrently, in step 534, exchange server 224 instructs exchange router 222 to artificially congest port 1410 in order to decrease the amount of traffic transmitted to exchange router 222 by buyer 1402's router 1406.

Such artificial congestion may be effected in a variety of ways. For example, artificial congestion may be effected using the ICMP error reporting mechanism associated with the IP protocol. For example, exchange server 224 may instruct exchange router 222 to transmit an ICMP source quench message to router 1406. As known in the art, when router 1406 receives a source quench message it is required under the IP protocol to reduce the rate at which it transmits datagrams to exchange router 222. As further understood in the art, when this condition occurs, router 1406 automatically begins to route some of the traffic intended for the termination destination specified in the datagram via alternate routes available to router 1406, such as link 1418 to router 1420 (step 536).

In an alternative embodiment, the system may use TCP congestion control mechanisms to artificially congest port 1410. For example, exchange server 224 may instruct exchange router 222 to cease sending acknowledgment (ack) messages when it receives packets from router 1406. As known in the art, router 1406 will interpret its failure to receive an ack message from exchange router 222 as an indication of packet loss and will decrease its packet transmissions to exchange router 222.

Alternatively, exchange server 224 may instruct exchange router 222 to transmit an ack message specifying an input buffer window of zero. As known in the art, when router 1406 receives such a message it will cease transmitting packets to exchange router 222 until it receives a second ack message specifying a window greater than zero.

This technique may be especially useful when it is desired to completely halt traffic from router 1406 from being routed via the exchange. In a preferred embodiment, exchange server 224 may also transmit a data message via communication link 220(b) to server 1408 instructing it to redirect traffic from router 1406 via alternative routes that. are available to buyer 1402, such as via aτouter- •

1418, as shown in step 536.

2. Second embodiment: Assigning Buy and Sell Orders to Matchable Classes

Trading in an exchange model is typically conducted in accordance with contractual agreements between participating service sellers and buyers. Therefore, it is important that such agreements be standardized so that they have uniform meaning among all participants.

However, such contracts typically characterize services using a large variety of possible parameters, many of which may take on any one of a plurality of values. Examples of such parameters are origination and termination location(s), bandwidth quantity, type of service (e.g. SDN, ATM, DSL, frame), hardware, packet loss rate, latency, circuit availability, and the term of each agreement (beginning, ending).

When contracts are negotiated on a custom basis (as is the case with bilateral agreements), matching the characteristics of services required with those of services offered is the subject of negotiations between the parties and is addressed in the final agreement. In the exchange model, however, interconnection remains fixed while contracts may change in quick succession; this requires the automation of negotiations and resulting operational transitions. However, automated matching of required and offered services is often impractical when the number of specifiable parameters and the value assigned to them is large. The number of combinations possible when n parameters are specified and each may acquire m possible values is n to the power of m. The large number of potential combinations of features drastically reduces the probability of matching all the parameters of a service required by a buyer with all the parameters of a service offered by a seller.

The problem is exacerbated by the variability of parameters (such as those associated with quality) over time. Typically, the exchange operator is responsible for monitoring service quality to ensure that it continues to meet the requirements specified by the buyer. In practice, this monitoring may reveal significant deviations between the promised and delivered quality of service. In that event, the exchange may swap, in real time₅ service- meeting .'the contracted for parameters in place of a service that violatesthe ; . contract.. When the number of possible combinations -of parameters is large, the probability of finding a suitable substitute service in real time is small.

Because of the large number of factors specified in each sell and buy order in the first preferred embodiment and given the realities described above, it may at times be difficult to create a sufficiently liquid market to efficiently trade Internet bandwidth. Accordingly, in a second preferred embodiment, the system assigns each buy and sell order received from a buyer or seller to one of a plurality of defined matchable service classes.

This second preferred embodiment will now be described in connection with Fig. 17.

As shown in step 1702, exchange server 224 begins a trading cycle. One preferred method of initiating a trading cycle is described in the first preferred embodiment above. In step 1704, each portal 212, web server 214 or Internet user 202 that wishes to sell Internet bandwidth via exchange 218 submits a sell order to exchange server 224 via a communication link 220(b). A sell order may comprise a plurality of parameters. In a preferred embodiment, as shown in Fig. 6, the plurality of parameters may comprise: termination location; origination location; duration; day of week;, time of day; minimum price; capacity; maximum latency; maximum packet loss; ' circuit availability; protocol; and hardware. In a further preferred embodiment, the sell order may also comprise additional business parameters such as preferred buyers.

In step 1706, exchange server 224 evaluates each received sell order and assigns the sell order to a previously defined matchable service class defined by exchange 218. An illustrative set of class definitions that may be defined by exchange server 224 is now described in connection with Fig. 18A-D.

In the illustrative example shown in Fig. 18A-D, exchange 218 has divided Internet service into four matchable service classes: class A, class B, class C, and class D. For each class, exchange 218 specifies the values of one or more parameters that define the service class. In a preferred embodiment, the parameters included in the class definitions correspond to the parameters specified in sell orders submitted by sellers.

In an alternative embodiment, exchange 218 may publish its class definitions. In this alternative embodiment, an entity submitting a sell order may itself determine the class of service that it is proposing to sell by comparing its service parameters to parameter ranges specified in the class definitions. In this alternative embodiment, as illustrated in Fig. 19, a sell order may preferably comprise the following fields: termination location; origination location; duration; minimum price; capacity; class of service; and . specific factors.

In a further preferred embodiment, the class definitions specified by exchange 218 may.beiterrnination specific. In other words, each; termination location may

associated therewith a series of class definitions that specify the classes of service for carrying traffic to and from the termination location. As noted above, these termination locations may be physical locations, virtual locations, or combinations of the two.

Furthermore, exchange server 224 may also verify the seller's class designation by testing and evaluating the parameters of the offered service to see if the parameter values meet the class definition.

In step 1708, each portal 212, web server 214 or Internet user 202 that wishes to purchase IP bandwidth (i.e., wishes to pay another entity to route its traffic to a particular destination) transmits a buy order to exchange server 224 via communication link 220(b). In a preferred embodiment, the buy orders may take the form of continuous limit orders.

In a preferred embodiment, as shown in Fig. 7, a buy order may comprise the following parameters: termination location; origination location; duration; maximum price; minimum capacity; maximum latency; maximum packet loss; and minimum circuit availability.

In a further preferred embodiment, a buy order may comprise additional parameters such as preferred sellers.

In step 1710, exchange server 224 evaluates each received buy order and assigns the order to one of its previously defined matchable service classes on the basis of the desired parameters specified in the buy order.

As noted above, exchange 218 may, in an alternative embodiment, publish its class definitions. In that alternative embodiment, buyers may themselves determine the desired class of service and specify that class of service in their buy orders. In that alternative embodiment, as illustrated in Fig. 20, a buy order may preferably comprise the following fields: termination location; origination location; duration; day of week, time of day; maximum price; minimum capacity; class of service; and specific factors. In step 1712, the trading cycle ends as described, for example, in the first embodiment described above. After the trading cycle ends, two events follow. First, exchange server 224 goes back to step 1702, and a new trading cycle begins. Second, in step 1714, exchange server 224 updates market book 800 of Fig. 8 with received sell and buy orders. The market book operation may proceed in the same manner as previously described with respect to Fig. 8. In step 1716, exchange server 224 prioritizes and matches sell and buy orders as previously described in connection with Figs. 9, 10, 11 and 12.

Then, in step 1718, exchange server 224 creates a route plan according to the match list of market book 800. The process of creating a route plan may proceed in the same manner as described previously with respect to Fig. 13. In step 1720, exchange server 224 loads the route plans into exchange routers 222. Upon loading, in step 1722, exchange routers 222 route traffic according to the route plan. Because of the dynamic nature of Internet bandwidth services, exchange server 224 monitors service conditions to see that requirements of matched buy orders are met during trading cycles, as shown in step 1724. Further, in step 1726, if there is a condition change in a service being provided to the buyer and that change is enough to make the current route plan inadequate to meet the buy order, exchange server 224 may notify the buyer of the change in condition and cause the buyer's other resources to handle the traffic, as in step

1728. This may be accomplished in the manner explained previously with reference to Fig. 5. Also, in step 1730, exchange server 224 waits until the next trading cycle to implement a new route plan to meet the new condition. If the change (e.g. price changes beyond what buyer was willing to pay) requires a new order from the buyer, exchange server 224 may notify the buyer to submit a new order and waits for a new order before implementing a new route, plan for the buyer.

3. ,- Third Preferred Embodiment of System Operation: Continuous Updatin

Operation of a third preferred embodiment of the present system for trading Internet bandwidth will now be described in connection with Fig. 21. As shown in Fig. 21, in step 2102, each portal 212 that wishes to sell Internet bandwidth via exchange 218 (i.e., wishes to promise to carry another entity's traffic in return for some renumeration) transmits a sell order comprising a plurality of parameters to exchange server 224 via a communication link 220(b). In a preferred embodiment, the plurality of parameters may comprise: termination location; minimum price; and quantity available; maximum latency; maximum packet loss; and circuit availability.

In a further preferred embodiment, the sell order may also comprise additional business parameters such as preferred buyers. In a preferred embodiment, the termination location may be specified either as a physical termination location (e.g., a specific portal 112) or as a virtual destination location (e.g., termination to some AOL router without specifying which). Moreover, the destination location may be specified as a virtual destination with some physical limitation. Thus, for example, the termination destination may specify that the traffic will be delivered to an AOL router in the United States without specifying the specific physical router.

In step 2104, exchange server 224 evaluates each received sell order and assigns the order to a previously defined matchable service class defined by exchange 218, as described above. Alternatively as described above, exchange 218 may publish its class definitions. In this alternative embodiment, an entity submitting a sell order may itself determine the class of service that it is proposing to sell by comparing its service parameters to parameter ranges specified in the class definitions.

As further noted above, the class definitions specified by exchange 218 may be termination specific and may specify the termination location as a physical location, virtual location, or combination of the two.

As noted, sellers may submit sell orders via a template 500 which may be accessed at a secure web site maintained by exchange' server- 224.

In a preferred embodiment, in step 2105, exchange server 224 downloads from each portal 212 and web server 214 that submitted a sell order information concerning its available communications resources and needs to exchange server 224. Thus, for example, if a particular portal has purchased or sold 10 Mb/s of bandwidth for the next three months at a flat rate from/to an alternative supplier/customer, this information is downloaded to exchange server 224. As described in more detail below, exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources.

Since, in this preferred embodiment, exchange server 224 is given access to portal 212's confidential communications information, additional confidentiality features may preferably be associated with the collection, storage, and usage of this data to ensure that the owner of portal 212 feels comfortable releasing the data to exchange 218 and to ensure that the data is not misused or obtained by entities that are not entitled to it. In particular, these additional safety features may include transmission via stronger encryption techniques than those that may be employed in connection with other system transmissions. In addition, these safety features may comprise storage of a portal 212's proprietary data in a secure location with limited access by specified personnel. The entity that owns exchange 218 may also obligate itself by contract to protect this sensitive information and may undertake specific sanctions if the information is improperly used or otherwise disclosed to others.

In step 2106, exchange server 224 uses the received sell orders to populate sell side 802 of market book 800, as described above.

In step 2108, each portal 212 or web server 214 that wishes to purchase IP bandwidth (i.e., wishes to pay another entity to route its traffic to a particular destination), transmits a buy order to exchange server 224 via communication link 220(b). In a preferred embodiment, the buy orders take the form of continuous limit orders.

In a preferred embodiment, a buy order may comprise the following parameters: termination destination (physical, virtual, or mixed); maximum price; maximum acceptable latency; ' maximum acceptable packet loss; minimum circuit availability.

In a further preferred embodiment, a buy order may comprise additional parameters such as preferred seller;

In step 2110, exchange server 224 evaluates each received buy order and assigns the order to one of its previously defined matchable service classes as described above.

Alternatively, as described above, exchange 218 may publish its class definitions. In that alternative embodiment, buyers may themselves determine the desired class of service and specify that class of service in their buy orders.

As further noted above, buyers may submit buy orders via a template 700, 2000 shown in Figs. 7 and 20 respectively which may be accessed at a secure web site maintained by exchange server 224. In a preferred embodiment, in step 2112, exchange server 224 downloads from each portal 212 and web server 214 that submitted a buy order, information concerning its available communications resources and needs. Thus, for example, if a particular portal has purchased 10 Mb/s of bandwidth for the next three months at a flat rate from an alternative supplier, this information is downloaded to exchange server 224. As described in more detail below, exchange server 224 preferably utilizes this information to efficiently manage the portal's traffic via exchange routers 222 while avoiding inefficient underutilization of the portal's other communication resources.

Because, in this preferred embodiment, exchange server 224 is given access to confidential portal 212's communications information, additional confidentiality features may preferably be associated with the collection, storage, and usage of this data to ensure that the owner of portal 212 feels comfortable releasing the data to exchange 218 and to ensure that the data is not misused or obtained by entities that are not entitled to it. In particular, these additional safety features may include transmission via stronger encryption techniques than those that may be employed in connection with other system transmissions. In addition, these safety features may comprise storage of a portal's proprietary data in a secure location with limited access by specified personnel. The entity that owns exchange 218 may also obligate itself by contract to protect this sensitive information and may undertake specific sanctions if the information is improperly used or otherwise disclosed to others.

In step 2114, exchange server 224 utilizes the information collected from the buyers to create the second component 804 of market book 800, as described above.

In step 2116, exchange server 224 matches unfilled sell orders to unfilled buy orders to create matched buy-sell orders in accordance with a protocol such as the protocols described above.

In step 2118, exchange server 224 uses this list to create a route plan for each exchange router 222 as described above.

In step 2120, exchange server 224 loads the route plans created in step 2118 into exchange routers 222. In step 2122, each exchange router 222 begins to route traffic delivered to it as specified in its respective route plan.

In step 2124, exchange 218 continuously monitors the level of service provided by each seller to ensure that it does not fall below the level of service specified for the service class allegedly being provided. If the level of service provided falls below that specified for the service class, the system responds by rerouting the buyer's traffic via alternative routes, as described above.

In step 2126, exchange server 224 determines whether an event has occurred that requires a change in the manner that traffic is routed via one or more of exchange routers 222. As noted, one such event is a degradation in service provided by a seller. In a preferred embodiment, however, the system is preferably adapted to recognize and respond to a plurality of distinct events. These may include: 1. quality of service provided degrades below an acceptable level, as described above;

2. a seller submits a new sell order;

3. a seller modifies an existing sell order;

4. a buyer submits a new buy order; 5. a buyer modifies an existing buy order; and

6. a buyer's traffic patterns change including a significant decrease in usage of other communications resources available to buyer.

If, in step 2126, an event requiring a change in the routing plan is not identified, the system returns to step 2124 to continue monitoring service quality provided by each seller.. If, however, an event requiring a change in the routing plan is identified, the . system proceeds to step 212-8 where.it is determined whether, given the buyer's current buy order, the exchange can meet the buyer's service needs under the new conditions.

If the buyer's needs can still be met, the system proceeds to step 2130 where exchange server 224 generates a new route plan for exchange routers 222. In step 2132, this new route plan is loaded into exchange routers 222, and in step 2134, each exchange router

222 begins to route traffic in accordance with its newly loaded route plan.

In contrast, if in step 2128, the system determines that it can no longer meet the buyer's service requirements, the system branches to step 2136 where the buyer is notified of the change in conditions. In step 2138, exchange server 224 instructs exchange router 222 to artificially congest port 1410 using the techniques described above in order to decrease the amount of traffic transmitted to exchange router 222 by buyer's router 1406.

In a preferred embodiment, exchange server 224 may transmit a data message via communication link 220(b) to server 1408 instructing it to redirect traffic from router 1406 via alternative routes that are available to buyer 1402, such as via a router 1418, as shown in step 2140.

In step 2142, exchange server 224 transmits a message to the buyer suggesting that the buyer submit a new buy order if it wishes to continue to receive service from exchange 218. If the buyer wishes, it may submit a new order in step 2144. In that event, the system returns to step 2128 where exchange server 224 determines whether it can meet the buyer's service needs under present system conditions.

Thus, for example, if one or more sellers submit modified sell orders, exchange server 224 detects this in step 2126 and determines whether changes are needed in the route plans of exchange routers 222 in light of this change in conditions. If changes are necessary and exchange router 224 can meet a buyer's bandwidth needs given the buyer's current limit order (step 2128), it modifies the route plans of exchange routers 222 as necessary to minimize'the buyer's cost and maximize other business objectives (steps 2130- 2134). Otherwise, in steps 2138-2142, exchange server 224 causes exchange routers 222 to artificially congest their input ports and notifies the buyer that it needs to modify its buy order.

Although this preferred trading embodiment has been described as utilizing the matchable classes technique described in the second preferred trading embodiment above, it will be recognized that a continuous trading embodiment could similarly be implemented without utilizing such matchable classes techniques, as for example, in the first preferred trading embodiment above.

4. Multiple Exchanges Embodiment In a preferred embodiment, the system may comprise multiple exchanges 218 each of which is connected to a central server. The central server preferably maintains a market book 800 that comprises the information stored in the market books 800 of each exchange 218 as well as additional information. Fig. 22 is a block diagram of a preferred network architecture for this preferred embodiment of the present system and Fig. 23 is a flow diagram that depicts system operation in this preferred embodiment.

As shown in Fig. 22, network architecture 2202 preferably comprises a plurality of exchanges 218 each of which maintains a market book 800, as described above. Preferably, these exchanges 218 are distributed around the globe. Thus, for example, exchange 218ι may be located in New York, exchange 218 may be located in Los Angeles, exchange 218₃ may be located in Tokyo, and exchange 218₄ may be located in London. Each exchange 218 preferably has a plurality of customers 212, 214, as described above.

Network architecture 2202 further preferably comprises a central server 2204 that is connected to each exchange 218 by respective communication links 2206. Exchanges 218 are also linked to each other by traffic-carrying links 2208. In a preferred embodiment, traffic-carrying links 2208 are maintained by entities that wish to participate in the present system as bandwidth sellers who offer connectivity between exchanges 218. In an alternative embodiment, traffic-carrying links 2208 may be maintained by one or more of exchanges

218.

During system operation, as shown in Fig. 23, in a first step 2302, each exchange 218 creates a market book 800. This step may preferably be performed in accordance with any of the preferred operating embodiments described above. In step 2304, each exchange 218 transmits a copy of its market book to central server 2204.

In step 2306, each entity that maintains one or more of traffic-carrying links 2208 submits a sell order to central server 2204 that specifies the parameters and conditions under which the seller is willing to carry traffic between exchanges 218. By combining the information received in step 2304 with the information received in step 2306, central server 2204 is able to create a market book 800 that describes the overall state of the market for bandwidth.. Moreover, in a preferred embodiment, where exchanges 218 are distributed around the globe, this complete market book represents a snapshot of the world- wide bandwidth market.

In step 2308, central server 2204 uses one of the matching algorithms described above to match buy orders and sell orders and thus identify routes to carry each buyer's traffic to its desired destination.

As noted in my copending application, Serial No. 08/811,071, which is incorporated herein by reference in its entirety, it will be recognized that a communication from an originating location to a terminating location may be connected via a routing path comprising several legs, each leg bridging two locations in the routing path. Thus, the routing paths determined by central server 2204 may be formed by combining services provided by multiple service providers. Although many of the preferred embodiments described in that application related to circuit-switched connections for telephone connectivity, it should be recognized that a similar principle may be employed to construct a packet-switched route between an originating point and a terminating point.

For example, if a first service provider submits a sell order offering to carry traffic from a first exchange 218ι to a termination location (e.g., AOL), and a second service provider submits a sell order offering to carry traffic from a second exchange 218₂ to the first exchange 218₁ then central server may create a composite route combining the services offered in the two sell orders to provide connectivity to a buyer connected to second exchange 218₂ who wishes to transmit traffic to the termination location. This feature of the present preferred embodiment provides several benefits.

First, it permits price arbitrage between exchanges when prices at a particular exchange 218 rise above the world-wide market value for the services being offered. For example, when the cost of connecting to AOL at first exchange 218} rises above the sum of the costs of carrying the buyer's traffic from first exchange 218χ to second exchange 218₂ and from second exchange 218₂ to the termination location, then central server 2204 responds by matching buy orders from first exchange 218i to composite sell orders, as described above.

Second, this feature of the present embodiment increases the robustness of world-wide communications by permitting traffic to be rerouted via alternative exchanges when serious network events occur in a particular location. If, for example, a seller's network at a particular exchange goes down, traffic that it might have carried may be rerouted via other- exchanges to the desired termination location. Moreover, this rerouting is performed in an-econαmically efficient manner because central server 2204 will not begin to match buy orders to composite sell orders until the cost of the composite sell orders is below the cost of delivering the traffic directly via a seller connected to the affected exchange 218. In step 2310, central server 2204 transmits the match information to appropriate exchanges 218. Thus, for example, if a buy order has been matched with a sell order from a seller connected to the same exchange, then the matched buy and sell orders are transmitted only to that exchange 218. If, however, the buy order was matched with a composite sell order then the necessary match information is transmitted to each exchange in the route that will carry traffic from the buyer to the termination location.

In step 2312, each exchange 218 receives the match information from central server 2204 and creates a route plan for its exchange routers 222, as described above. The system then proceeds to route traffic and monitor service quality as described in the preferred operating embodiments above. In a preferred embodiment, the system may comprise a graphical tool for use by network managers to manage their network capacity. A first preferred embodiment of such a graphical tool is described in connection with Figs. 24-26. Fig. 24 shows a graphical tool 2402 comprising a PC 2404 running appropriate software (not shown) including software to implement the functionalities described below. PC 2404 comprises a processing unit 2406, a keypad 2408, a mouse 2410, and a monitor 2412. Fig. 25 is a flowchart depicting a preferred method of operation for graphical tool 2402. The steps in Fig. 25 are explained in conjunction with Figs. 26A-H, which are a series of figures that show the image displayed by monitor 2412 at various points during use of graphical tool 2402.

Turning to Fig. 25, in step 2502, the user, typically a network manager, initializes graphical tool 2402, by, for example, clicking on an icon displayed on monitor

2412. As shown in Fig. 26A, when graphical tool 2402 is first initialized by the user, it causes a graph 2602 depicting network usage (as a percentage of total network capacity) for a particular network and time period to be displayed on monitor 2412. The network and time period that are the subject of graph 2602 may preferably be identified for the user in a pair of windows 2604 and 2606, respectively. Predicted network usage may be based, for example, on historical data for this and other -networks, and may also be a function of additional factors ■ that are expected to affect network usage during the displayed period.

In step 2504, the user uses his or her mouse to graphically define bandwidth for which he or she wishes to submit a sell order. Fig. 26B illustratively shows how the display might appear after the user blocked an area of bandwidth available during a peak usage period.

In step 2506, graphical tool 2402 causes a sell-order window 2608 to pop open on monitor 2412. As shown in Fig. 26C, this window may preferably comprise a plurality of fields for entering and displaying sell-order parameters for the bandwidth that the user wishes to sell. As further shown in Fig. 26C, many of the parameters defining the sell order (e.g., latency, protocol) may be automatically filled in by graphical tool 2402 because they typically will not vary from order to order. Moreover, the capacity, duration, day of week, and time of day fields may also be automatically filled in by graphical tool 2402 when they are defined by the block of capacity selected by the user. In step 2508, the user fills in the remaining fields in window 2608. Fig. 26D shows window 2608 after completion of step 2508. In step 2510, the user clicks on the submit button in window 2608 to submit the order. Once the order is submitted, graphical tool 2402 preferably displays the portion of the graph that corresponds to the sell order in a different color from other portions of the screen, such as those corresponding to unsold bandwidth (see, e.g., Fig. 26E).

In a preferred embodiment, graphical tool 2402 may display all information concerning the order when, for example, the user moves the mouse over the identified area or, alternatively, when the user clicks on the identified area, as shown in Fig. 26F.

In a preferred embodiment, graphical tool 2402 permits the user to modify the order at any time by simply clicking on an area corresponding to a sell order. When the user clicks on such an area, window 2608 pops up and the user is permitted to modify one or more parameters of the sell order, and then click the submit button to submit the modified order. In a further preferred embodiment, the user may instead or additionally mark unused bandwidth for sale at a variable price depending on congestion levels of the user's network. As shown, for example, in Fig. 26G, the user may specify that he or she wishes to sell all unused capacity for 1 cent/Mb/s when network usage is at or below 40%, for 2 cents/Mb/s when network usage is below 50%, for 3 cents/Mb/s when network usage is at or below 60%', etc: In addition, as shown for example in Fig. 26H, the user may specify some range of network capacity (e.g., 5%) above predicted usage that it does not wish to sell in-¹ order to preserve an operating cushion in case actual usage exceeds predicted usage.

In a preferred embodiment, the user may call up an updated display showing all submitted sell orders for a particular day or other period by entering the desired time period at an appropriate prompt. In addition, monitor 2412 may display a series of views as nested windows (see, e.g., Fig. 26A), and the user may call up a desired view by clicking on the portion of the view visible on the screen. The user may then submit new sell orders for that time period or modify existing displayed sell orders, as described above. Although in the description above entities have been described as either buyers or sellers, it should be recognized that any given entity may act as both a buyer and a seller of bandwidth depending on its bandwidth needs and resources at a particular time for a particular class of service, origination location, etc., or for other business reasons.

In a particularly preferred embodiment, the exchange 218 maintains a running account with each buyer and seller. Thus, once a transaction has been authorized, the exchange 218 adjusts the balances of each buyer and seller to reflect the purchase and sale of bandwidth. Periodically (e.g. monthly), the exchange 218 sends bills to the buyers and/or sellers with negative balances and forwards payments to buyers and/or sellers with positive balances. In this way, the exchange 218 manages settlement of all accounts. The server node also manages credit risks associated with the transactions. This may be accomplished in combination with a financial services company. Preferably, in all of the aforementioned embodiments, the identity of the buyers and sellers are not revealed to each other, at least prior to the transfer of ownership of the transaction.

While the invention has been described in conjunction with specific embodiment, it is evident that numerous alternatives, modifications, and variation will be apparent to those skilled in the art in the light of forgoing descriptions.

Claims

What is claimed is:

1. A method of trading IP bandwidth routed via an exchange with a first router, comprising: establishing a plurality of connections between the first router and a plurality of additional routers, each additional router being maintained by an entity; specifying a plurality of parameters that are descriptive of IP bandwidth services; defining a commodity having a definition that specifies a range of values for each of the parameters; receiving from a seller an offer to provide a quantity of the commodity, the seller being one of the entities that maintains a router connected to the first router, the seller's router being connected to a first port of the first router; receiving from a buyer an order to buy the commodity, the buyer being one of the entities that maintains a router connected to the first router, the buyer's router being connected to a second port of the first router; creating a route plan for the router that is a function of the seller's offer and the buyer's order; and routing IP traffic from the second port to the first port in accordance with the route plan.

2. The method of claim 1, further comprising: receiving a modification to the offer from the seller; creating a new route plan for the router that is a function of the seller's modified offer and the buyer's order; and routing IP traffic from the second port to the first port in accordance with the route plan.

3. The method of claim 1, further comprising: receiving a modification to the order from the buyer; and creating a new route plan for the router that is a function of the seller's offer and the buyer's modified order; and routing IP traffic from the second port to the first port in accordance with the new route plan.

4. The method of claim 1, wherein the plurality of parameters include: destination location; price; packet loss; latency; circuit availability; and time of day.

5. The method of claim 4, wherein the destination location is a virtual destination location.

6. The method of claim 4, wherein the destination location is a physical destination location.

7. The method of claim 1, wherein the buy order includes: destination location; maximum price; minimum price; and preferred service providers.

8. The method of claim 1, further comprising: sensing a change in at least one quality parameter defining the commodity provided by the seller; generating a new route plan for the first router that is a function of the change in the quality parameter of the commodity provided by the seller; and routing IP traffic from the second port to the first port in accordance with the new route plan.

9. The method of claim 1, further comprising: notifying the buyer of a change in at least one parameter defining the commodity provided by the seller; notifying the buyer to submit a new buy order based on the change; receiving the new buy order from the buyer; and generating a new route plan for the first router that is function of the new order.

10. The method of claim 1, further comprising: an exchange server having access to the buyer's network resource information and router; planning a route plan that is a function of the buyer's network resource information and router; and an exchange server decreasing π° traffic routed via the first router when the buyer is underutilizing other network resources available to the buyer for which the buyer pays a flat rate.

11. The method of claim 1 , further comprising: displaying data of the seller and the buyer; and creating options and derivatives based on the commodity.

12. The method of claim 1, wherein the order is a continuous limit order.