WO2001017182A1 - Systeme, methode et article fabrique permettant d'acheter, de vendre et de negocier une largeur de bande dans un marche libre - Google Patents

Systeme, methode et article fabrique permettant d'acheter, de vendre et de negocier une largeur de bande dans un marche libre Download PDF

Info

Publication number
WO2001017182A1
WO2001017182A1 PCT/US2000/024156 US0024156W WO0117182A1 WO 2001017182 A1 WO2001017182 A1 WO 2001017182A1 US 0024156 W US0024156 W US 0024156W WO 0117182 A1 WO0117182 A1 WO 0117182A1
Authority
WO
WIPO (PCT)
Prior art keywords
bandwidth
market
user
bwth
network
Prior art date
Application number
PCT/US2000/024156
Other languages
English (en)
Inventor
Larry Socher
Original Assignee
Andersen Consulting, Llp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Andersen Consulting, Llp filed Critical Andersen Consulting, Llp
Priority to AU71061/00A priority Critical patent/AU7106100A/en
Publication of WO2001017182A1 publication Critical patent/WO2001017182A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5061—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the interaction between service providers and their network customers, e.g. customer relationship management
    • H04L41/5064—Customer relationship management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1442—Charging, metering or billing arrangements for data wireline or wireless communications at network operator level
    • H04L12/145—Charging, metering or billing arrangements for data wireline or wireless communications at network operator level trading network capacity or selecting route based on tariff
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1457—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network using an account
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1485—Tariff-related aspects
    • H04L12/1492—Tariff-related aspects negotiation of tariff
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1485—Tariff-related aspects
    • H04L12/1496—Tariff-related aspects involving discounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/808—User-type aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5629—Admission control
    • H04L2012/5631—Resource management and allocation
    • H04L2012/5632—Bandwidth allocation
    • H04L2012/5634—In-call negotiation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5639—Tariffs or charging

Definitions

  • the present invention relates to product dissemination and more particularly to the reallocation of bandwidth between users in an open market.
  • ISPs Internet Service Providers
  • bandwidth pricing leading up to today's environment will now be set forth.
  • One of the major challenges of the communication industry is determining how to price wholesale bandwidth. As a substantial part of the business case will rest upon the pricing model, it is important that bandwidth is priced in such a manner that maximizes revenue over the life of the system.
  • communication system operators In order to establish a wholesale pricing model, communication system operators must first look at how bandwidth has been priced in the past. This will provide the background for analyzing how the industry has reached its current state. These past pricing models should then be compared to current vendor pricing to help determine industry best practices.
  • the first real data communications services were mainly dedicated leased lines. Conditioned analog and later Digital Data Services (DDS) were installed to support what was typically host terminated traffic. These circuits were usually used to access an IBM mainframe using BSC or SNA protocols.
  • DDS Digital Data Services
  • Dedicated leased lines can be considered analogous to "hotlines" in the telephony world.
  • a dedicated circuit remains open throughout the phone network so that if a person picks up the line on one end they could automatically talk to someone on the other end. No call needs to be placed to establish the circuit.
  • the network vendors treated these leased lines in much the same fashion as they would handle dedicated voice circuits, charging a fixed monthly fee based on the locations, distance between the end points, and the bandwidth of the circuit. Pricing for a circuit is established by looking at the NPA/NXX combinations of the end points, and determining the cost of different bandwidth connections between the endpoints.
  • Network providers started using packet switched networks in order to take advantage of the bursty nature of most data traffic. Based on the premise that not all users transmit at once, packet switch networks use statistical multiplexing techniques to interleave traffic from multiple users over shared network connections.
  • the CCITT introduced its X.25 network interface specifications to provide a standardized framework to take advantage of packet switched networks.
  • the X.25 specifications were designed to simulate dedicated leased lines using Permanent Virtual Circuits (PVCs) and dial-up connections using Switched Virtual Circuits (SVCs).
  • PVCs Permanent Virtual Circuits
  • SVCs Switched Virtual Circuits
  • the X.25 protocol implements a network layer function which provides routing and addressing (X.121) capabilities.
  • X.25 is capable of handling varying maximum packet sizes, which can be optimized based on the quality of the circuit and the type of traffic being transmitted (usually 128, 256, and 512 octet frames). Typical X.25 speeds range from 2.4 Kbps to 512 Kbps (with an occasional Tl or El).
  • Packet Assemblers/Disassemblers are often used to support legacy synchronous and asynchronous circuit based traffic. In addition, PADs also support asynchronous devices that dial into the PAD and establish a call across the network by providing an X.121 address.
  • X.25 has typically been priced by a combination of access costs and usage charges.
  • the customer pays a monthly charge for access to the X.25 port on the network. This charge is calculated based on the access speed of the port (e.g. 128 Kbps).
  • the cost of the local loop (either 64 Kbps or Tl) that the X.25 provider must pay the LEC will be passed through to the customer.
  • the total fixed monthly recurring cost is therefore the port cost plus the cost of the local loop.
  • PVC and SVC pricing is typically not distance based. For this reason, in most domestic X.25 networks, the vendor will not typically charge for PVCs or SVCs, although some vendors may charge nominal administration costs. However, when leaving the United States, one will often find that PVCs and SVCs are based on the distance between the two end points. In these cases, one may see high monthly surcharges for PVCs and call establishment costs for SVCs.
  • X.25 network providers typically include a variable monthly charge based on usage — usually measured in kilochars (or 1,024 octets). Some countries base their measurement on the number of packets, or kilopackets, assuming an average packet size for calculations. The more that one uses the network, the more one pays. As the user is charged for the amount of data transferred, they are more likely to avoid needless transmissions. If one user is idle, this means that additional bandwidth is available to other subscribers. This allows the provider to "oversubscribe" access to the network, as statistical multiplexing will allow multiple users to share the same backbone bandwidth. What results is a network in which bandwidth is efficiently allocated; where the economics provide an incentive to the customer not to use unnecessary bandwidth.
  • X.75 gateways between their X.25 network and other providers. These gateways usually provide PVC services and often offer SVC capabilities.
  • the X.121 domain structure ensures that addresses will be unique across networks.
  • X.25 network providers usually negotiate bilateral agreements to establish pricing between two networks.
  • BER Bit Error Rates
  • higher layer communications protocols such as TCP introduce sophisticated sequencing, error correction, and congestion control mechanisms, rapidly diminishing the need for the network to handle these functions.
  • the introduction of higher quality circuits and sophisticated upper layer protocols eliminates the usefulness of many of X.25' s capabilities.
  • frame relay provides a streamlined alternative to its packet switched predecessor.
  • Frame relay connections typically range from 56 Kbps to Tl (or El) speeds. Some vendors are currently evaluating T3 (45 Mbps) service. Like X.25, Frame Relay Access Devices (FRADs) allow legacy applications (e.g. BSC and SNA) to operate over frame relay connections by emulating dedicated leased lines. Some of these FRADs even support voice over frame relay.
  • FRADs Frame Relay Access Devices
  • CIR CIR is the amount of data that the network agrees to transfer between the ingress and egress points under normal conditions; or Be (committed burst size). This is a loose guarantee of transmission rate.
  • Frame relay also allows the user to burst beyond the Committed Information Rate up to an Excess Burst Size, or Be, at times when additional network capacity is available. Most network providers allow the user to burst up to the port speed. All data in excess of the committed burst size Be is marked Discard Eligible (DE) by the network. In the event that the network experiences congestion, switches will drop frames that are marked discard eligible first and give priority to committed traffic (Be).
  • QoS Quality of Service
  • Vendor pricing usually consists of a recurring access cost. The customer pays a monthly charge for access to a frame relay port on the network. This charge is calculated based on the access speed of the port (e.g. 128 Kbps). In addition, the cost of the local loop (either 64 Kbps or Tl) that the frame relay provider must pay the LEC will be passed through to the customer. The total fixed monthly recurring cost is therefore the port cost plus the cost of the local loop. In addition, the vendor will usually charge an additional monthly cost for each Permanent Virtual Circuit (PVC). The cost of this PVC increases with its Committed Information Rate. The higher the CIR, the greater the cost. PVC pricing is typically not distance based in the United States. However, once one leaves the United States, PVC pricing raises dramatically based on distance and location, particularly when crossing international boundaries.
  • PVC Permanent Virtual Circuit
  • All frame relay pricing is based on port access costs and PVC CIRs. There is typically no variable usage component to customer costs. This means that the customer pays a fixed monthly fee only. There are two possible explanations for this approach. First, in order to simplify their monthly billing, customers may have demanded flat monthly pricing. Second, by avoiding variable usage charges, carriers could follow a similar model to their leased line pricing allowing them to use the same billing systems.
  • Switched Virtual Circuits Another interesting item missing from most frame relay networks is Switched Virtual Circuits (SVCs).
  • SVCs Switched Virtual Circuits
  • SLAs Service Level Agreements
  • ISPs Internet Service Providers
  • a router at the customer's site will usually connect to the ISP's router using either dedicated leased lines or frame relay connections. Connections usually range from 64 Kbps to T3 speeds. The greater the port speed, the greater the fixed monthly cost that the ISP charges. In addition to the port costs, the ISP will pass through the charges for the leased line or frame relay connection. As ISPs typically have POPs in most major metropolitan areas, these circuits usually avoid IXC charges, and are therefore less expensive than typical WAN connections.
  • Vendors usually charge for connect time to their POPs for dial-up services. The greater the port speed, the more the user pays for connect time. In order to keep competitive, many vendors have started to offer flat monthly rates with unlimited connect time. Although it is rare, some international providers are starting to charge by the amount of data transmitted.
  • Asynchronous Transfer Mode was designed to meet this challenge.
  • CBR Constant Bit Rate
  • RT-VBR Real Time - Variable Bit Rate
  • NRT-VBR Non-Real Time Variable Bit Rate
  • UBR Unspecified Bit Rate
  • Vendors appear to be having a tough time figuring out how to price ATM services. Very few vendors actually publish their price lists and pricing models vary significantly across carriers. It appears that many vendors are reluctant to disclose detailed pricing information since vendors approach ATM pricing using very different cost components.
  • ISDN Integrated Services Digital Network
  • CO Central Offices
  • BRI Basic Rate ISDN
  • PRI Primary Rate ISDN
  • ISDN vendors price their offerings based on their telephony services. This suggests that ISDN prices will drop in conjunction with voice services. However, unlike standard telephony services, vendors typically add additional usage charges for ISDN data calls. This avoids a scenario in which users have no economic incentive to release a circuit.
  • High-speed Digital Subscriber Line technologies support high-speed data networking over standard copper wiring.
  • High-speed Digital Subscriber Line, or HDSL supports data rates from 384 Kbps to 2 Mbps up to 3 to 5 km. Three copper pairs are required to support 2 Mbps in both directions.
  • ADSL Subscriber Line
  • VDSL Very-high speed Digital Subscriber Line
  • Cable modems use the existing coaxial cable TV network infrastructure to provide data services to customers. Although cable modems are theoretically supposed to operate at speeds up to 10 Mbps, they more typically run at 64 Kbps upstream and 2 Mbps downstream.
  • LMDS Local Multipoint Distribution Services
  • LMDS is a form of cellular radio that operates at frequencies of 28 and 40 GHz. LMDS service runs up to 30 Mbps over a 3 km radius. Very few vendors have started offering LMDS and other broadband wireless services. However, companies are currently trying to launch LMDS services in the United States. The FCC is currently planning to auction off LMDS frequency ranges.
  • GSO satellite services typically offer dedicated bandwidth similar to leased lines and have pricing models based on flat rate monthly service. Most of the MEO and LEO satellite providers have either not yet determined or disclosed their pricing models.
  • bandwidth pricing will come down significantly, it will probably not reach the point where it is free.
  • bandwidth will someday be treated in a similar fashion to power, water, and sewer services.
  • bandwidth will be metered and commoditized.
  • deregulation is rapidly driving to an efficient market in the power industry in which megawatts are traded among suppliers, similar deregulation in the telecommunications industry suggests that we will start to see bandwidth bought and sold as a commodity.
  • Vendors will have a couple of alternatives to maintain profitability.
  • network providers could continue to offer their services with low, flat-rate pricing structures and cut back on their investment in infrastructure. Rather than increase the number of dial-up ports or the bandwidth in their backbone networks, vendors could continue to add users without adding capacity. What will result is more congested networks with lower service levels.
  • users may not be able to reliably connect to their service providers.
  • competition for bandwidth will be so high that performance will become intolerable. Eventually they will start to lose their customers to other providers.
  • other providers will be facing the same economic pressures as the original vendor, they too will be forced to curve the growth in their infrastructure. Eventually customers will become so discouraged that they will stop using networking services.
  • bandwidth pricing will drop significantly over the next few years, the upcoming generation of multimedia applications will have much greater bandwidth requirements. It is difficult to tell whether the price decreases in bandwidth will be enough to offset increased demand. However, one thing is certain. Customers will continue to have high monthly networking bills, and will continue to look for ways to decrease their costs.
  • the customer will be much better educated. While they will be willing to pay a premium for a higher quality of service, they will not want to pay for bandwidth that they do not use. As customers must connect to a network at a speed capable of supporting their peak traffic loads, the majority of time they are not using their full capacity. Although two customers may require similar bandwidth connections to a network to support peak loads, they may use the network very differently. If networks are priced on a flat rate structure based on port access speeds, a customer that needs OC3 access to an ATM network for five minutes a day for downloading sales information will pay the same amount as a customer who needs OC3 capacity for 8 hours a day to backup their mainframes. This pricing structure is not fair to the sales force customer who only uses a fraction of the bandwidth as the mainframe customer.
  • Internetworking is the joining of two networks to exchange information between users. As the popularity of the Internet suggests, the desire to communicate and exchange information beyond one's natural boundaries is ubiquitous. Although it started as a small packet switched network established by ARPA to connect research facilities, the Internet has grown into a giant network connecting millions of hosts in over 190 countries.
  • NAPs Internet Service Provider networks typically meet to exchange traffic
  • ISPs Internet Service Provider networks
  • ISPs are negotiating bilateral agreements with other ISPs to route traffic between their networks bypassing the NAPs.
  • ISPs are having a tough time upgrading their own network backbones and POPs to handle their growing customer base.
  • Another stated goal of communication system operators is to price and sell bandwidth at the wholesale level. Rather than selling directly to end users, communication system operators may rely on a network of value added resellers to package and resell its services to customers. These distributors will purchase bandwidth from various communication system operators, incorporate additional value added services, and resell these services to their customers. Communication system operators are trying to structure their networks so that each distributor views their purchased bandwidth as their own private resource, and will manage and control the allocation of access and bandwidth to its users through a Distributed Virtual Network Services (DVNS). Ideally, distributors will view their piece of the network as their own Virtual Private Network (VPN).
  • VPN Virtual Private Network
  • communication system operators were to price bandwidth at the same rate for customers in the first location as those in the second location, it has two options. It could either price the traffic for the customers in the second location at the lower rate of the first location, in which case communication system operators would be leaving money on the table. Alternatively, communication system operators could use the higher rate of the second location, in which case customers in the first location would select other options and communication system operators could forgo revenues in the first location. In order to maximize revenues, communication system operators would be better off pricing bandwidth at the highest rates that the markets will bear in both the first and second location. This means that even though it costs the same to deliver the service to the first and second locations, communication system operators should price services differently based on the market for bandwidth at each location. Location based pricing is the only way to maximize revenues.
  • the major pricing component in the new model is port access speeds.
  • the domestic market in the United States has already gone to an access based rather than distance based price structure for X.25, frame relay, and ATM services. It is very likely that the international market will follow as more and more fiber is run between countries. Although communication system operators may still see distance sensitive international pricing when it goes live in the future, the ability to offer its services based on access costs alone could prove a competitive advantage over other services.
  • communication system operators will also be concerned with other factors such as duration of call, priority of traffic, latency requirements, time of day, and bulk commitment levels. Although all may be important in determining the pricing model, duration of call and priority of traffic are discussed below.
  • Priority 1 refers to guaranteed bandwidth, typically used for CBR traffic reserved in advance
  • Priority 2 refers to purchased bandwidth, typically used for VBR and ABR traffic with a reserved level of guarantee
  • Priority 3 refers to excess shared bandwidth, typically UBR traffic with best effort delivery
  • P3 bandwidth is probably the easiest to understand. As P3 offers no guarantees and is based on best effort delivery, users could be charged solely for the amount that they use, based on cell or bit counts.
  • Priority 2 (P2) traffic is similar to frame relay.
  • communication system operators can oversubscribe Priority 2 bandwidth allocation knowing that users transfer data at different times. Certain levels of guarantees may be offered based on Peak
  • Priority 1 bandwidth As communication system operators must reserve Priority 1 bandwidth in order to guarantee transmission, calls using PI resources are analogous to dedicated leased lines or time division multiplexing. Like leased lines, these calls could be priced based on the amount of bandwidth reserved and the duration of the call. As the bandwidth must be reserved irrespective of whether or not it is actually used, cell or bit count is not relevant for pricing. Communication system operators are also examining whether or not to charge for access to DAMA channels, which are required for bandwidth allocation and maintenance. Connect time charges for access to DAMA channels would encourage users not to sit idly on DAMA channels, using up valuable resources of communication system operators.
  • Communication system operators may find it difficult to figure out how to price bandwidth in each of its LACs. Priority of traffic, latency requirements, time of day, duration of call, bulk commitment levels, and other factors may all influence the price. As a result, communication system operators will have a very difficult time determining its wholesale pricing. While trending may help marketing adjust its pricing across LACs, the combination of sporadic data usage patterns and a large number of pricing determinants will make this analysis very complex.
  • LAC Location Area Code
  • the distributors will have to estimate their bandwidth purchases for each LAC in which they have customers. Bandwidth purchased in one LAC is useless to customers in another area.
  • the purchasing of bandwidth with the current model could be an extremely difficult task for a distributor.
  • Some distributors may be more content focused, they may not have the skills necessary to estimate their overall network demand. The more difficult it is for distributors to determine demand, the less likely they will be willing to commit to large bandwidth purchases.
  • Discount pricing will have to be low enough that distributors can cover their risk of not selling the bandwidth.
  • CPE Customer Premise Equipment
  • SVCs makes demand fluctuations much more volatile. Applications that use SVCs are typically much more elastic to price, as usage patterns can easily be adjusted based on the cost of connection. A good example of this phenomenon is the increase in long-distance calls made by residential voice customers as a result of aggressive pricing discounts. As soon as long-distance rates go down, customers increase their use.
  • the Bandwidth Market would also remove the need for distributors to negotiate hundreds of bilateral agreements with one another and by introducing bandwidth contracts, simplifies the billing and settlement processes.
  • bandwidth is allocated on a network among a plurality of users.
  • An amount of unused bandwidth of a first user is identified and a request for bandwidth on the network is received from a second user.
  • the unused bandwidth of the first user is reallocated to the second user.
  • the unused bandwidth is reallocated to the second user in exchange for money paid by the second user to the first user. Further, a transaction fee may be charged for reallocating the unused bandwidth. In another aspect of the present invention, a notification of the amount of unused bandwidth may be provided to the users.
  • the unused bandwidth of the first user is packaged with unused bandwidth of another user and reallocated to the second user under the terms of a contract.
  • the request for unused bandwidth and reallocating the unused bandwidth may occur in real time.
  • Figure 1 is a schematic diagram of a hardware implementation of one embodiment of the present invention.
  • Figure 2 is a representation of a bandwidth market in accordance with one embodiment of the present invention.
  • Figure 3 is a flowchart illustrating a contract negotiation in accordance with one embodiment of the present invention.
  • Figure 4 is a flowchart depicting a method for automatically identifying an amount of unused bandwidth of a user
  • Figure 5 is a flowchart illustrating another method of identifying the amount of bandwidth of a user
  • Figure 6 is a flowchart illustrating a method for exchanging money for bandwidth
  • Figure 7 is an illustration a summary of a contract negotiation process
  • Figure 8 is an illustration of a more detailed contract negotiation process
  • Figure 9 is a flow chart illustrating a method of performing clearing and settlement functions in a bandwidth market environment
  • Figure 10 illustrates in overview a system arrangement for implementing the over the counter (or other) bandwidth market system of the instant invention
  • Figure 11 is a flow chart of data processing for qualifying for execution of an order communicated from a branch order entry clerk or account executive;
  • Figure 12 illustrates data processing for executing and accounting for orders that have been qualified for execution by the order qualifying data processing of Figure 11;
  • Figure 13 is the left portion of a flow chart for the data processing of block 1214 of Figure 12 for updating the inventory cost (average price per unit of bandwidth AVCST(BWTH)) of the bandwidth BWTH and the running profit PR(BWTH) realized from the execution of each trade;
  • Figure 14 is the right portion of a flow chart for the data processing of block 1214 of Figure 12 for updating the inventory cost (average price per unit of bandwidth AVCST(BWTH)) of the bandwidth BWTH and the running profit PR(BWTH) realized from the execution of each trade;
  • Figure 15 is a flow chart illustrating data processing upon receipt of a new market maker quotation from the bandwidth market system
  • Figure 16 is a block diagram of a bill pay system relying on postal mailed payments
  • Figure 17 is a block diagram of a bill pay system wherein consumers pay bills using a bill pay service bureau which has the consumers as customers;
  • Figure 18 is a block diagram of a bill pay system where billers initiate automatic debits from consumers' bank accounts
  • Figure 19 is a flow chart illustrating an open market environment for electronic content
  • Figure 20 illustrates one manner of performing operations 1902 through 1906 of Figure 19;
  • Figure 21 illustrates an encryption technique designed to ensure payment by the customer.
  • Figure 22 illustrates an alternative to operation 2114 of Figure 21.
  • a system for affording various features which support a bandwidth market that allows buyers of bandwidth to buy, sell, and/or trade excess bandwidth.
  • the market may be enabled using a hardware implementation such as that illustrated in Figure 1.
  • various functional and user interface features of one embodiment of the present invention may be enabled using software programming, i.e. object oriented programming (OOP).
  • OOP object oriented programming
  • FIG. 1 A representative hardware environment of a preferred embodiment of the present invention is depicted in Figure 1, which illustrates a typical hardware configuration of a workstation having a central processing unit 110, such as a microprocessor, and a number of other units interconnected via a system bus 112.
  • a central processing unit 110 such as a microprocessor
  • the workstation shown in Figure 1 includes Random Access Memory (RAM) 114, Read Only Memory (ROM) 116, an I/O adapter 118 for connecting peripheral devices such as disk storage units 120 to the bus 112, a user interface adapter 122 for connecting a keyboard 124, a mouse 126, a speaker 128, a microphone 132, and/or other user interface devices such as a touch screen (not shown) to the bus 112, communication adapter 134 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 136 for connecting the bus 112 to a display device 138.
  • the workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system.
  • OOP Object oriented programming
  • OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program.
  • An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task.
  • OOP therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.
  • OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture.
  • a component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each other's capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point.
  • An object is a single instance of the class of objects, which is often just called a class.
  • a class of objects can be viewed as a blueprint, from which many objects can be formed.
  • OOP allows the programmer to create an object that is a part of another object.
  • the object representing a piston engine is said to have a composition-relationship with the object representing a piston.
  • a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.
  • OOP also allows creation of an object that "depends from” another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition.
  • a ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic.
  • the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it.
  • the object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.
  • the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class.
  • the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons.
  • Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with them (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.).
  • a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.
  • composition-relationship With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, the logical perception of the reality is the only limit on determining the kinds of things that can become objects in object- oriented software. Some typical categories are as follows:
  • Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.
  • Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.
  • An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.
  • An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.
  • OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.
  • OOP enables software developers to build objects out of other, previously built objects.
  • C++ is an OOP language that offers a fast, machine-executable code.
  • C++ is suitable for both commercial-application and systems-programming projects.
  • C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.
  • Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them.
  • class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way.
  • Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way.
  • similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.
  • Class libraries are very flexible. As programs grow more complex, more programmers are forced to adopt basic solutions to basic problems over and over again.
  • a relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers. Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others.
  • event loop programs require programmers to write a lot of code that should not need to be written separately for every application.
  • the concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making all these things work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.
  • Application frameworks reduce the total amount of code that a programmer has to write from scratch.
  • the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit.
  • the framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).
  • a programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.
  • a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.
  • default behavior e.g., for menus and windows
  • Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program.
  • a framework provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.
  • • Call versus override With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework.
  • the framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together. • Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design.
  • a framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems. Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved.
  • a preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and a company.
  • HTTP or other protocols could be readily substituted for HTML without undue experimentation.
  • Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol - HTTP/1.1 : HTTP Working Group Internet Draft"
  • HTML is a simple data format used to create hypertext documents that are portable from one platform to another.
  • HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office
  • HTML has been the dominant technology used in development of Web-based solutions.
  • HTML has proven to be inadequate in the following areas:
  • UI User Interface
  • Custom “widgets” e.g., real-time stock tickers, animated icons, etc.
  • client-side performance is improved.
  • Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance.
  • Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.
  • Sun's Java language has emerged as an industry-recognized language for "programming the Internet.”
  • Sun defines Java as "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language.
  • Java supports programming for the Internet in the form of platform-independent Java applets.”
  • Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client.
  • Java's core feature set is based on C++.
  • Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution.”
  • ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content.
  • the tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies.
  • the group's building blocks are called ActiveX Controls, which are fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages.
  • ActiveX Controls work with a variety of programming languages including Microsoft Visual C++,
  • Borland Delphi Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta.”
  • ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications.
  • ActiveX could be substituted for JAVA without undue experimentation to practice the invention.
  • One objective of the instant bandwidth market is to provide a more efficient mechanism for buying and selling network bandwidth.
  • a bandwidth provider could also use the market to post excess wholesale capacity.
  • bandwidth market Another major benefit of a bandwidth market is its ability to efficiently price bandwidth. As distributors buy and sell capacity, the price of the bandwidth moves towards a market equilibrium where supply hits demand.
  • bandwidth is traded by service level guarantees and LAC, this eliminates some of the complex analysis that distributors need to perform in order to determine fair market prices.
  • a bandwidth provider is able to accurately gauge demand and price bandwidth in each location.
  • a bandwidth provider could post all of its bandwidth on a wholesale market instead of negotiating directly with each distributor. Distributors could then bid for this bandwidth, resulting in efficient wholesale pricing in which the bandwidth provider maximizes its revenues.
  • a market for trading bandwidth virtually eliminates the difficult pricing problems faced by a bandwidth provider's marketing department.
  • distributors have the ability to sell off excess bandwidth, reducing their risk significantly.
  • a futures market could be established allowing distributors to hedge bandwidth purchases. This would allow distributors who are mainly interested in selling value added service to their customers to avoid fluctuations in bandwidth prices.
  • a bandwidth provider may be to allow a customer to take their Subscriber Identifier Module, or SIM card, and plug it into another CPE when they are on the road. This would allow a business traveler to plug his or her SIM card into a hotel's CPE to access the bandwidth provider's network. However, if the hotel CPE does not have enough bandwidth available to support the business traveler's application, its DVNS could purchase the extra capacity on the bandwidth market.
  • SIM card Subscriber Identifier Module
  • distributors would have to negotiate with other distributors every time that they want to resell their excess capacity. This too could result in hundreds of bilateral agreements, and could be costly to negotiate and administer. Dispute resolution could also present a major problem.
  • the bandwidth market provides an efficient means of trading bandwidth among distributors. As distributors would enter into a contract with the market, they do not have to negotiate with each DVNS that they ultimately trade with.
  • the bandwidth market also serves as an equalizer, giving small distributors the same ability to purchase bandwidth as larger providers. By allowing a smaller DVNS to purchase bandwidth, it could provide its customers with the same access as larger distributors. A bandwidth provider could benefit by selling wholesale capacity on the bandwidth market, avoiding periodic negotiations with hundreds of distributors.
  • bandwidth Another benefit of the bandwidth market is its handling of contracts. To allow the market to operate efficiently, bandwidth could be packaged and traded as contracts. In order to package bandwidth, it may be necessary for the bandwidth market to define products. These products are based on a combination of bandwidth (or cell counts), location, service level guarantees, time of day, duration, and other factors. Although establishing these structures is a complex task, it is much easier for the bandwidth market to go through the steps of defining these packages once, rather than distributors worrying about them every time that they negotiate with other providers. This simplifies the sales process dramatically.
  • the DVNS issues a Contract ID to its customer's CPE during call setup.
  • the contract determines who pays for the call (e.g. calling party pays, collect call, etc.).
  • this price provides rating information that can be used for billing purposes.
  • the CPE reports usage data back to the DVNS.
  • This usage data includes the Contract ID, allowing the DVNS or a settlements process to correlate the call back to the original transaction.
  • this information could be forwarded to the distributors, the bandwidth provider, and a clearinghouse for processing. This simplifies the revenue allocation process, by providing clear information for rating, billing, and settling the call.
  • One advantage of having call setup based on contracts is that the CPE is given a well defined call duration and total cell or bit count. As the DVNS steps out of the picture after call setup, the CPE is responsible for making sure that it does not exceed these agreed upon thresholds. If the CPE reaches the maximum duration or cell count, it automatically terminates the call. While ATM does require the CPE to shape its traffic to conform with the Peak and Sustainable Cell
  • Rates and the transfer capabilities agreed upon during call setup it does not define the call duration or maximum traffic transfer.
  • the bandwidth contract does a nice job in filling this gap, and is ideal for supporting pre-paid calling structures (e.g. credit or debit card).
  • Another benefit of the bandwidth contract is that it specifies agreed upon service levels for call setup. After the call has been completed, usage data can be analyzed to see if these service levels have been met. This allows a bandwidth provider and its distributors to provide customers with Service Level Agreements that may have penalty clauses for violations.
  • trading alliances may exclude smaller or less political DVNSs, ending up with an "Old Boys Network" of distributors dominating the market. This could result in a small oligopoly dictating bandwidth pricing, potentially forcing other distributors out of business. As one would expect, losing control of pricing for a bandwidth provider's services could have dangerous consequences.
  • bandwidth provider could develop the bandwidth market itself. In addition to keeping control of bandwidth pricing, the bandwidth provider could earn additional revenue by charging trading transaction fees. When coupled with clearing functions, this market could prove an important selling point for attracting distributors. By offering a simple and controlled mechanism for reselling excess bandwidth, the bandwidth provider reduces the risk faced by distributors of purchasing too much bandwidth. A distributor may be more likely to offer the bandwidth provider's services if they know that a bandwidth market is available to buy and sell excess capacity, and it is managed and operated by the wholesale provider.
  • bandwidth providers may need to offer special rate structures and benefits to potential distributors. Once the bandwidth market is established, many of the benefits, such as bandwidth contracts and CPE traffic shaping, will be useful even for distributors who have large discount structures. Rather than create custom purchasing mechanisms for these customers, they could use the same processes and applications that the market uses for buying and selling bandwidth, even if they are dealing exclusively with only one bandwidth provider. Because of the standardized process for selling bandwidth, a bandwidth provider can avoid having to develop custom interfaces for each of its large distributors.
  • the bandwidth market may be segmented into multiple trading floors or markets. As shown in Figure 2, the top level segment would be a Pre-Sold bandwidth market
  • Figure 3 illustrates one method of providing an open market environment in accordance with the principles set forth hereinabove.
  • bandwidth is allocated on a network among a plurality of users, i.e., distributors.
  • bandwidth could be allocated based on an amount of bandwidth the users purchase.
  • bandwidth could be allocated based on a contract, such as an allotment of a predetermined amount of bandwidth per period, e.g., month, year, etc.
  • an amount of unused bandwidth of a first user is identified.
  • Figure 4 illustrates a method of automatically identifying the first user's unused bandwidth.
  • unused bandwidth is identified by monitoring bandwidth use of the first user to determine an amount of bandwidth used by the first user in operation 400.
  • the amount of bandwidth used by the first user is compared to the total amount of bandwidth the first user has been allocated.
  • the amount of unused bandwidth is determined in operation 404 by subtracting the amount of bandwidth used by the first user from the total amount of bandwidth allocated to the first user. The first user would then be notified of the amount of unused bandwidth in operation
  • Figure 5 illustrates another exemplary method of identifying the amount of bandwidth of the first user, as set forth in operation 302 of Figure 3.
  • the first user is sent a request asking whether the first user has any unused bandwidth that the first user would like to trade or sell.
  • a response from the first user indicating an amount of unused bandwidth that the first user would like to trade or sell is received in operation 502.
  • the availability of the amount of unused bandwidth that the first user would like to sell or trade is verified in operation 504.
  • a request for bandwidth on the network is received from a second user in operation 304.
  • the request may be received before or after the amount of unused bandwidth is identified in operation 302, above.
  • the request may be directly received from the second user or an agent of the second user.
  • the second user, or all of the users may be notified of the amount of unused bandwidth available.
  • the second user may be notified in any of a multitude of ways. For example, a listing of available unused bandwidth that is for sale or trade by any number of users may be compiled and displayed or sent to some or all of the users of bandwidth. The listing could be complex or as simple as a listing on a web site with the price and name and contact information of the first user. Once the user is notified, a response from the second user as to the amount of unused bandwidth the second user would like to purchase or trade for would be awaited and received.
  • the unused bandwidth of the first user is reallocated to the second user.
  • the second user is given control of the unused bandwidth to use, reserve, or trade or sell.
  • the bandwidth provider may be contacted and told to reallocate the bandwidth by terminating the first user's access to the unused bandwidth and giving the second user access to the bandwidth.
  • access codes that would have been used by the first user to access predetermined amounts of bandwidth co ⁇ esponding to the unused bandwidth being reallocated may be turned over to the second user to permit the second user to access the bandwidth.
  • the unused bandwidth that is reallocated to the second user in operation 306 of Figure 3 is done so in exchange for money paid by the second user to the first user.
  • a method of exchanging money for bandwidth is illustrated.
  • notification of an agreement to sell bandwidth for an amount of money is received.
  • Information concerning the manner of payment is received in operation 602. This information includes how the second user is going to pay for the bandwidth. For example, access information of a bank account or of a credit line could be received from the second user, which would be used to perform an electronic transaction of money from the second user's account to the first user.
  • the transfer of money is verified such as by receiving an electronic receipt from the bank of the first user which acknowledges a deposit of the money.
  • the unused bandwidth of the first user is reallocated to the second user.
  • a transaction fee may be charged for reallocating the unused bandwidth.
  • the transaction fee may be a percentage of the total value of the bandwidth traded or sold, a flat fee charged per transaction, or a flat fee charged per unit of bandwidth.
  • the unused bandwidth of the first user is packaged with unused bandwidth of another user and reallocated to the second user under the terms of a contract, as discussed above in the "Establish Bandwidth Contracts" section hereinabove. This would allow a second user who requires more unused bandwidth than the first user has available to satisfy the second user's requirements.
  • the remaining segments at the lowest level are the Closed Markets 204. These markets would be established to allow vendors who offer similar services (e.g. DSS TV, ISPs, etc.) to trade among themselves. In some instances, a bandwidth provider may be given the right to post excess bandwidth that fits predefined contract profiles to some of these markets.
  • the bandwidth market could be modeled on either an auction concept or as commodities markets.
  • a bandwidth provider requires distributors to purchase wholesale Priority 1 and 2 traffic at least 24 hours before the time that it is needed. This means that distributors may be forced to estimate their bandwidth requirements for the following day. As the Internet outage during the last US presidential elections suggests, bandwidth demand may fluctuate significantly for a number of external reasons. In certain instances, it may not be possible to the distributors to predict demand. While the bandwidth market may provide a good mechanism for determining price when the next day's demand is known, it does not help in situations of great uncertainty.
  • the 24 hour advanced bandwidth model could be problematic for the bandwidth provider. Just as distributors may not be able to predict the next day's demand, the bandwidth provider may not be able to determine the optimal price of the bandwidth. While a static bandwidth market based on contracts negotiated 24 hours in advance of their actual execution may certainly help determine pricing, the 24 hour requirement may result in some inefficiencies. On a similar note, although the bandwidth market reduces risk by providing a mechanism for reselling excess capacity, the 24 hour rule results in a one day liability to distributors. Another problem with the 24 hour requirement is that it does not allow a customer to transparently access i ⁇ egular services or locations.
  • a customer decides that they want to call an unusual location or access a service that has not been pre-negotiated by their DVNS, they may have to call up their distributor to have them acquire the appropriate service for the next day.
  • a customer in the United States may not be willing to contact its service provider 24 hours in advance to setup a video conference call to someone in Botswana.
  • Figure 7 illustrates a contract negotiation process.
  • bandwidth on a network is allocated, i.e., sold or traded in allotments, among a plurality of users.
  • an amount of unused bandwidth of a first user is identified.
  • a request for bandwidth on the network is received from a second user in operation 704.
  • operations 700 - 704 may be accomplished by any means including those specified hereinabove with respect to operations 300 - 304 of Figure 3.
  • a negotiation between the first and second users is allowed in operation 706 to determine transaction terms for reallocation of the unused bandwidth from the first user to the second user.
  • one embodiment of the present invention would simply receive pricing information from one user and send it to the other user, and vice versa, over and over until each user is satisfied with the terms for the transaction.
  • contract information relating to the transaction terms is sent to the first and second users in operation 708.
  • the terms may set forth in a contract format which the first and second users may agree to form a contract.
  • acceptance of the terms of the transaction may be an acceptance of a contract including the terms of the transaction, and the contract information is a recitation of the terms of the contract.
  • the contract information defines the amount of unused bandwidth, a duration of use of the unused bandwidth, a service level, and/or a price.
  • a transaction fee may be charged for allowing the negotiation between the first and second users.
  • the step of allowing the negotiation between the first and second users may occur in real time.
  • the contract information is sent to a third party after the third party requests bandwidth from the second user.
  • the contract information may include a contract identifier.
  • Step 8 outlines the exemplary contract negotiation of Figure 7 in more detail.
  • a DVNS 800 that has purchased too much bandwidth packages their excess capacity and posts it to one of the segments on the bandwidth market 802.
  • the distributor 804 does not have the bandwidth available (Step #2)
  • its DVNS 806 first determines the appropriate call parameters. It then bids on and purchases bandwidth from the bandwidth market 802 (Step #3).
  • the bandwidth market 802 completes and records the transaction (Step #4), and forwards the contract information, including bandwidth, location, service levels, and Contract ID, to each DVNS 800,806 involved in the transaction (Step #5).
  • the information is also forwarded to the rating, clearing, and settlements processes in the Network Business Center (CNBC) 808.
  • CNBC Network Business Center
  • the contract information is forwarded to the CPE 804 along with other call setup information (Step #6).
  • the CPE 804 periodically sends cumulative Raw Usage Data (RUD) information to its DVNS 806 (Step #7).
  • RUD Raw Usage Data
  • the DVNS 806 cuts an Event Data Record (EDR) and forwards it to the Network Business Center (CNBC) 808 (Step #8) for rating and settlements processing (Step #9).
  • EDR Event Data Record
  • CNBC Network Business Center
  • the CPE can use standard call setup signaling assuming that it is similar to the Q.2931 method used by ATM.
  • the call parameters and bandwidth requirements are assessed.
  • the customer is first validated by the DVNS, which also checks to see if they are allowed to request this service. If the request is valid and the DVNS has available resources as a result of other contracts (which may be from long-term bandwidth purchases made in the Pre-Sold bandwidth market), the DVNS may complete the call and pass the Contract ID back to the CPE in a User-Defined
  • IE Information Element
  • ATM is designed to allow the customer to renegotiate call parameters, such as Peak Cell Rate and Sustainable Cell Rate, even after the call is established. If a bandwidth provider plans to fully support ATM, a different contract may be required to satisfy an upgrade request. This may require that the DVNS has the ability to renegotiate in the middle of a call. As the call may have two or more Contract IDs, the DVNS could close out an EDR record and treat the remainder of the connection as a new call assigning a new EDR.
  • call parameters such as Peak Cell Rate and Sustainable Cell Rate
  • time required to complete a transaction In evaluating the real-time purchasing of bandwidth during call establishment, one pertinent area is the time required to complete a transaction. As many protocols such as ATM have timeout values for call setup, it may be necessary to stay within these specifications. These timeout values are typically high to accommodate network congestion. In addition, some of these values can be tuned by vendor equipment.
  • One of the advantages of the bandwidth market and bandwidth contracts is the ability to control CPE usage patterns. As a DVNS may need to assign a contract to complete all call setups, information in this contract can be passed to the CPE. Based on a variety of factors such as the customer's credit limit, the CPE can be instructed to terminate a call when it hits certain thresholds. These thresholds could be based on call duration or cell counts. This may be an excellent mechanism for supporting pre-paid billing.
  • the DVNS may be configured with certain cost thresholds for a particular customer.
  • the customer could instruct the DVNS not to allow video conference calls if the rate is greater than $1.00 a minute. If the DVNS is unable to satisfy a call request within certain pre-defined thresholds, the CPE may be instructed that the resources are not available, possibly notifying the customer the reason that the call could not be setup (e.g. rates too high). With little effort, this could be extended to allow the customer to configure the information directly into the CPE, which in turn would pass it to the DVNS in User Defined Information Elements during call setup.
  • bandwidth contracts are their ability to support hot billing.
  • the DVNS could take advantage of pricing information inherent in the agreement. If the DVNS forwards this pricing information along with the contract to the CPE, this would allow the CPE to notify the user on a real-time basis how much they have spent during the call.
  • the rating information accompanies the bandwidth contract, the DVNS can calculate the cost of the service and debit the user immediately.
  • taxation may need to be evaluated if the bandwidth provider supports this model.
  • the bandwidth provider may also provide a clearinghouse function.
  • the contracts generated in the bandwidth market may be excellent tools for rating calls and determining revenue allocation. These contracts may be forwarded to the rating and settlements engines, providing important information needed for each of these processes. Usage data may be correlated to the appropriate contract, which may provide rating information, service level guarantees, and revenue allocation information. This information may be used by the rating and net settlements processing.
  • Pre-Sold Bandwidth of a bandwidth provider could be cleared by a Pre-Sold Bandwidth Clearing function.
  • the Open and Closed markets could have their own clearing functions. Eventually these may feed into one larger clearing process, which provides net settlements functions between a bandwidth provider and its distributors.
  • One of the key functions of the clearinghouse is to offer a mechanism to bill back services between distributors. If a DVNS in Thailand purchases bandwidth from an American distributor in order to complete a video call to the United States, the American distributor needs some mechanism for receiving payment from the Thai DVNS. As all distributors must deal with a bandwidth provider at some level, it makes sense for the bandwidth provider to provide clearing functions between distributors.
  • the clearing function may allow the US DVNS to bill the Vietnamese DVNS for the bandwidth that it used. The Thai DVNS may then bill its customer for the call.
  • the bandwidth market when coupled with a clearinghouse function, provides a mechanism for one distributor to indirectly bill another distributor's customers.
  • Figure 9 illustrates a method of performing clearing and settlement functions in a bandwidth market environment.
  • terms regarding a reallocation of bandwidth from a seller to a buyer are received in operation 900. These terms may be received from input of the seller and buyer. Alternatively, the terms may be taken from a set of guidelines concerning the transaction. In any case, the terms may set forth, for example, the purchase price, time for transfer of the bandwidth, penalties, latency requirements, etc. See the discussion with reference to Figures 10 through 14 below for more detail.
  • an amount of money the buyer owes the seller for the reallocated bandwidth is determined based on the terms regarding the reallocation of bandwidth. Most often, this may be calculated as the price per unit of bandwidth times the number of units of bandwidth being sold and taking into account any penalties and discounts. If amounts of bandwidth of more than one seller are sold together such as under a contract as discussed above, the amount of money the buyer owes each seller is calculated. More detail is provided below in the discussion referencing Figures 10 through 14.
  • the buyer is notified of the amount of money the buyer owes the seller. Notification may be made in a variety of ways. One is through email. Another is via facsimile.
  • a printout with the amount on it may be sent to the buyer via a delivery service such as the United States Postal Service.
  • the present invention may verify that the terms regarding the reallocation of bandwidth have been complied with. This could include verifying the amount of bandwidth that the seller is offering for sale. This could also include verifying that the seller has relinquished control of the bandwidth. Further, the buyer's access to the newly purchased bandwidth could be verified.
  • usage data may be received from the buyer and used to determine the amount of money the buyer owes the seller for the reallocated bandwidth.
  • the buyer could be allowed to purchase bandwidth according to the buyer's requirements. The buyer would then only be liable for the amount of bandwidth actually used, plus incidental costs.
  • the usage data may also be used to determine the cost per unit of bandwidth. Bandwidth used during peak hours is most often more valuable than, say, bandwidth used in the middle of the night. Thus, the usage data could include times of use of the bandwidth as well as the particular amount of bandwidth used during peak hours.
  • the usage data may be co ⁇ elated with co ⁇ esponding terms via a contract identifier (Contract ID as discussed above) associated with the usage data.
  • the contract identifier would allow the DVNS or a settlements process to co ⁇ elate the use of bandwidth back to the original transaction to ensure that the proper party is being billed.
  • a transaction fee may be charged for performing the determination of the amount of money the buyer owes the seller for the reallocated bandwidth.
  • the transaction fee may be a percentage of the total value of the bandwidth traded or sold, or may be a flat fee charged per transaction. Additionally, as the present invention manages both the bandwidth market and Clearinghouse functions, it is also the natural choice for arbitrating disputes between distributors.
  • operations 900 and 902 of Figure 9 are handled by a data processing based apparatus which makes an automated trading market for one or more amounts of bandwidth.
  • the system retrieves the best obtaining bid and asked prices from a remote data base covering the ensemble of institutions or others making a market for the relevant amounts of bandwidth.
  • Data characterizing each bandwidth buy/sell order requested by a customer is supplied to the system.
  • the order is qualified for execution by comparing its specific content fields with predetermined stored parameters.
  • the stored parameters include items such as the operative bid and asked cu ⁇ ent market prices, the amount of bandwidth available for customer purchase or sale as appropriate, and the maximum acceptable single order size.
  • the market maker when a customer purchases an amount of bandwidth, the market maker sells the amount of bandwidth from its position, either reducing a long position, increasing a short position, or both where the amount of bandwidth sold to the customer exceeds the initial long position.
  • the market maker adds bandwidth to its position and/or reduces a short position in the bandwidth.
  • the system may be implemented by any digital data processing equipment per se well known to those skilled in the art, e.g., any common bus system interconnecting a digital processor, manual data entry terminal apparatus, one or more memories (one of which contains the controlling program), and output signaling apparatus such as a cathode ray tube and printer.
  • the system may be coded in any program language per se well known to those skilled in the art.
  • the process variables may be of any form which conform to the constraints of the particular language being used and the below listed variables are for purposes of illustration only.
  • BWTH An order field identifying a particular amount of bandwidth a customer wishes to buy or sell.
  • PR/M An order variable field containing a customer price for a limit order (minimum price for a sale of bandwidth or a maximum price he will pay for a purchase) - or a code designating a market order where the customer will accept the currently prevailing market price.
  • SP Special instructions field e.g., special commission structure or the like.
  • RIGID Identification of the originator of the transaction e.g., a branch office or account executive
  • BWTH Market Trade Criteria BSTB
  • BSTA(BWTH) Best asked price for the amount of bandwidth BWTH supplied by Bandwidth Market, i.e., the lowest price a market maker is willing to sell the bandwidth BWTH.
  • BWTH Bandwidth (BWTH) Buy size, which is the amount of bandwidth (the array index BWTH) available for customer purchase at a particular price from the system proprietor
  • BWTH bandwidth SSZ
  • O.RSZ(BWTH) The maximum acceptable order size which the system operator will accept for the bandwidth BWTH.
  • Profitability Variables AVCST Average cost of the amount of bandwidth BWTH .
  • P . O . S The amount of bandwidth ( current pos ition) of each type of bandwidth BWTH held by the market maker .
  • P . O . S (BWTH) i s pos itive for a long posit ion and nega tive for a short pos ition .
  • BWTH bandwidth
  • Figure 10 illustrates in overview a system a ⁇ angement for implementing the over the counter (or other) bandwidth market making system of one embodiment of the instant invention.
  • the market making institution system proprietor
  • the market making system includes composite digital computing apparatus 1000 which includes a processor and ancillary memory.
  • the memory constituents of processor 1000 store the system controlling program, and an appropriate scratch pad memory stores all necessary processing operands.
  • Digital computer 1000 is connected by an output line 1002 to a customer account processor 1004, for example the brokerage firm computer which handles all of the customer account records and files including customer balances, bandwidth positions, trade records, and the like. It should be understood that CPU 1000 and customer account processor 1004 could be combined in single, integrated computing equipment.
  • the processor 1000 communicates over a link 1006 with a trader terminal position 1008 containing an output signaling device such as a cathode ray tube display, and data input apparatus such as a keyboard.
  • Trader terminal 1008 has two portions.
  • a terminal position section Tl communicates with the processor 1000; and a section T2 is connected by link 1010 to a bandwidth market system 1014.
  • the trader terminal 1008 communicates its cu ⁇ ent bid and asked prices for bandwidth s in which it makes a market to bandwidth market via link 1010— as do other market makers bridged (1012) to link 1010.
  • the terminal portions Tl and T2 may be one integrated smart terminal (computer) assembly, or two separate devices available to the trader at the station 1008.
  • the processor 1000 receives and stores the best (highest) bid (processing variable BSTB(BWTH)) for each amount of bandwidth (BWTH) in which it makes a market, and the best (lowest) asked price BSTA(BWTH) from the bandwidth market system 1014 via a communications path 1016.
  • the best bid and best asked prices as reported by the bandwidth market form the so-called "insider market" for over the counter amounts of bandwidth.
  • Link 1018 communicates to the bandwidth market system 1014 via a link 1018 each reportable, executed trade for various informational and regulatory purposes.
  • Link 1018 may also report trades to the Consolidated Tape Authority (CTA) and the NASD National Market System (NMS) for subsequent reporting to the financial industry and general public.
  • Communications path 1018 also connects processor 1000 with the NASD small order execution system (SOES) and computer assisted execution system (CAES) which can participate in relatively small order execution.
  • SOES small order execution system
  • CAES computer assisted execution system
  • Input/output network 1020 provides data communication with the various branch offices 1024 of the brokerage house.
  • Line 1020 permits communication with either the branch order entry clerk or directly to the account executives at each branch. While only one branch 1024 is shown in Figure 10, it is to be understood that a multiplicity of branches 1024 are in data communication with processor 1000.
  • Computer 1000 also communicates with third party financial houses 1026 via a two-way data link 1022 (e.g., including INSTINET).
  • the operative (best bid, best asked inside market) prices for each amount of bandwidth in which the system proprietor makes a market are communicated over link 1016 from bandwidth market and repose in memory at processor 1000.
  • the market maker has a position in each amount of bandwidth in which he makes a market and the particulars of that position also repose in memory within the composite processor 1000.
  • Orders for trades in the relevant amounts of bandwidth are tunneled to the processor 1000 in real time as they occur. Orders can be received in several ways. For example and most typically, orders may be generated by the brokerage firm's account executives at the branches 1024 and communicated to the CPU 1000 via the communication path 1020. Orders are also supplied to the processor 1000 from third party financial sources 1026 (e.g., other brokerage firms, directly from computer equipped customers, banks or the like) over communication network 1022. Each of the orders includes appropriate data fields outlined above and more fully discussed below, such as an identification of the office and customer or other originator of order, bandwidth identification, price particulars and so forth. The processor 1000 first determines whether or not each received order can be executed, i.e., "qualifies" the order.
  • third party financial sources 1026 e.g., other brokerage firms, directly from computer equipped customers, banks or the like
  • Orders not executable are either stored in memory in the processor 1000 for later execution if they become qualified (such as by a favorable change in the market price for an amount of bandwidth which can then accommodate the customer's price limits) or are forwarded to other market makers for potential execution over communication links 1018 or 1022.
  • the processor 1000 "executes" the order, appropriately adjusting all balances.
  • Information characterizing the executed order is sent to computer 1004 for customers of that brokerage house or reported to the appropriate other institution via links 1018 or 1022.
  • the specifics of appropriate transactions may also be reported to the NASD for informational purposes and to the Consolidated Tape Authority and so forth and may become ticker entries.
  • the bandwidth market system 1014 is apprised of the cu ⁇ ent quotations from all traders making a market in the subject amounts of bandwidth via communication path 1010.
  • Figure 11 is a flow chart of data processing for qualifying for execution an order communicated from a branch order entry clerk or account executive. Proceeding from a start node 1100, the data fields comprising this next-recorded order is loaded (block 1102).
  • the order data fields include the name of the amount of bandwidth (BWTH); the total amount of bandwidth for the transaction (AMT); customer identification (CUSTID); a buy vis-a-vis sell bit (B/S); the customer's price limit if he wants one or, if not, a market order designator (PR/M); special instructions if any (SP); an order number (.O.RN); and an originator (e.g., office, account executive, or third party institution) identification (.O.RIGID).
  • the computer includes a number of stored variables characterizing the market for the bandwidth BWTH which the customer wishes to trade, and the market maker's own criteria for his participation in BWTH trading.
  • the computer stores the best bid BSTB(BWTH); the best asked price BSTA(BWTH); the buy size BSZ(BWTH), i.e., the total amount of bandwidth BWTH the market maker is willing to sell for customer purchase at the cu ⁇ ent price; the market maker's sell size SSZ(BWTH); the maximum single order size for bandwidth BWTH which the market maker will accept .O.RSZ(BWTH); the present amount of bandwidth BWTH long or short in the market maker's position P.0.S(BWTH) ⁇ long being positive and short being negative; the average cost per unit of bandwidth AVCST(BWTH) for the bandwidth BWTH long or short in the market maker's portfolio; and a running profit total PR(BWTH) of the market maker in the bandwidth BWTH.
  • Block 1104 functioning next determines if order processing is operative in the normal, automated market mode for the particular amount of bandwidth BWTH. If not (please see below with respect to Figure 14), program flow branches to block 1106 to store the order for later retrieval or manual execution. Program flow then returns to start node 1100 for retrieval of the next order. Assuming normal automated mode processing (YES output of test 1104), program flow continues to test 1108 to verify the incoming data (order) to assure correct reception and internal consistency. If an e ⁇ or occurred, an e ⁇ or message is produced (block 1110) and program flow returns to the start node 1100 for entry of the incoming next order. In the usual case, the order is verified at test 1108, and program flow continues to block 1112 to determine if the order is a market order or has a limit price (test of the PR/M variable).
  • block 1120 determines if the amount of bandwidth AMT in the trade is less than or equal to the amount of bandwidth available for purchase from the market maker, i.e., less than the buy size BSZ(BWTH). If so (YES branch of test 1120), the amount of bandwidth AMT in the transaction is compared to the maximum acceptable single order size .O.RSZ(BWTH)— step 1130. Assuming this final criteria is satisfied (N.O.
  • program flow branches to block 1126 to store the order for possible later execution if market conditions or market maker criteria change.
  • An appropriate report is generated at block 1128 via terminal 1008 ( Figure 10) to characterize non-executed order. Thereafter program flow returns to node 1100 to process the next received order.
  • the human market system controller receiving the report may of course over-ride and complete the trade by hand or manual entry—e.g., by authorizing more bandwidth (increasing BSZ(BWTH)) if that criterion inhibited order execution.
  • program flow for a customer sale will next be considered. If the buy/sell flag signals a sale, program flow branches to block 1122 where the PR/M limit price is compared to the best bid price (PRVM.ltoreq.BSTB(BWTH)). If so (YES branch), the amount of bandwidth AMT in the order is compared against the available sell size (AMT.ltoreq.SSZ(BWTH)). If there is sufficient bandwidth in the sell size (YES branch), block 1130 determines if the amount of bandwidth (AMT) is greater than the maximum permissible single order size (.O.RSZ(BWTH)).
  • Figure 12 illustrates data processing for executing and accounting for orders that have been qualified for execution by the order qualifying data processing of Figure 11.
  • a block 1200 determines whether the order is a customer purchase or sale. If the buy/sell digit signals indicate a customer buy, program flow branches to block 1202 for decrementing the amount of bandwidth remaining available for customer purchase (BSZ(BWTH)) from the market maker.
  • the market maker's position in the bandwidth is algebraically decremented by the amount of bandwidth purchased,
  • program flow continues to block 1210 where messages confirming execution of the trade are furnished to the customer account processor 1004 which sends out confirmations of the transaction and otherwise performs the necessary accounting functions for the customer account.
  • the branch clerk or account executive 1024 is also notified of order execution via link 1020.
  • the order variables CUS ⁇ D, SP, .O.RN and .0.RIGID are used to appropriately distribute trade reporting, proper commission computation and the like.
  • the transaction price is typically communicated to the bandwidth market system 1014 and the various tape services for reporting.
  • the updated internal market maker variables e.g., SSZ(BWTH), BSZ(BWTH),
  • LP.O.S(BWTH), P.O.S(BWTH)) are stored in memory for use in subsequent order transactions (step 1212).
  • Program flow proceeds to block 1214 to update the market maker's average per unit of bandwidth inventory cost AVCST(BWTH) and profit PR(BWTH) internal management variables for the bandwidth BWTH, the data processing for which is described below in conjunction with Figures 12 and 13. After inventory updating and profit accounting, data processing exits at node 1216 ready to process the next trade.
  • Figures 13 and 14 are the left and right portions of a flow chart for the data processing of block
  • PR(BWTH) PR(BWTH)+(LP.O.S(BWTH)*(BSTA(BWTH)-AVCST(BWTH))). Eq. 1.
  • the variable BSTA(BWTH)- AVCST(BWTH) is the profit (or loss) margin on the sale representing the difference between the cu ⁇ ent asked price BSTA(BWTH) at which the trade occu ⁇ ed and the average cost per unit of bandwidth AVCST(B WTH) of the bandwidth.
  • the right factor following the plus sign in the statement of Equation 1 is the profit (or loss) for the transaction.
  • the final result stored in PR(BWTH) is an updated running total of the profit of the market maker in the bandwidth BWTH since the PR(BWTH) storage a ⁇ ay element was last cleared.
  • program flow proceeds to block 1306 where the average cost per unit of bandwidth of the new short position in the bandwidth is calculated.
  • Figure 13 programming then exits at the PROCEED node.
  • program flow continues to test 1308 where the buy/sell digit determines whether the transaction is a customer purchase or sale. If the trade is a customer sale thus increasing the initially long LPOS(BWTH) position, it is an inventory transaction and program flow branches to block 1310 to update the average cost of the BWTH bandwidth position:
  • AVCST(BWTH) ((AMT*BSTB(BWTH))+(AVCST(BWTH)*LP.0.S(BWTH)))/P.0.S(BWTH). Eq. 2.
  • AMT*BSTB(BWTH) is the cost of the bandwidth just purchased from the customer and AVCST(BWTH)*LP.O.S(BWTH) is the cost of the previous LP.O.S(BWTH) inventory.
  • P.O.S(BWTH) the new average cost AVCST(BWTH) is determined.
  • a test 1400 of Figure 14 determines whether the present position P.O.S(BWTH) is short or long. If the present position is also short (P.0.S(BWTH) ⁇ 0), program flow proceeds to block 1402 where the buy/sell bit is read. If the buy/sell digit indicates a customer buy, the transaction represents an inventory accumulation (the previous short position in LP.O.S(BWTH) being increased in P.O.S(BWTH)) and program flow branches ("YES") to block 1404 where the average cost of the bandwidth is updated:
  • AVCST(BWTH) ((AMT*BSTA(BWTH))+(AVCST(BWTH)*LP.0.S(BWTH)))/P.0.S(BWTH).
  • block 1406 updates the profit total:
  • PR(BWTH) PR(BWTH)+(AMT*(BSTB(BWTH)-AVCST(BWTH))). Eq. 5.
  • FIG. 15 is a flow chart illustrating data processing upon receipt of a new market maker quotation from the bandwidth market system 1014. Beginning at an interrupt entry node 1500, the system is placed in non-automatic execution mode (step 1502) which prevents automatic execution of any orders in the particular amount of bandwidth (BWTH) until the market maker has had a chance to respond to the new market prices.
  • step 1502 non-automatic execution mode
  • program flow proceeds to block 1506 where the best bid BSTB(BWTH) and/or best asked price BSTA(BWTH) are updated to the new values received from bandwidth market.
  • the system then interactively communicates with the trader terminal 1008 in block 1508.
  • a prompt appears on trader Tl terminal 1008 requesting input regarding possible changes in the maximum acceptable order size (.O.RS(BWTH)), the amount of bandwidth available for customer purchase (BSZ(BWTH)), and the amount of bandwidth acceptable for customer sales (SSZ(BWTH)).
  • any orders previously stored in memory are reprocessed (block 1510) as these orders may now be qualified for execution due to the change in price or other parameters.
  • data processing is restored to automatic mode (block 1512)-- as by simply setting a variable AUT.0.
  • program flow branches directly to block 1512 to restore automatic mode and exit interrupt mode.
  • the market making system of the above-described invention has thus been shown to automatically accommodate a random, real time order flow for bandwidth purchases or sales.
  • Incoming orders are first examined to assure that they satisfy cu ⁇ ently operative criteria regarding bandwidth price, bandwidth availability and bandwidth order size. Those orders being qualified under the existing criteria are executed and profit and inventory price internal management storage elements are appropriately updated to reflect the several transactions experienced by the system. Orders not qualified for execution are stored and re-examined from time to time for possible later executability. The system proceeds automatically without human intervention, save to update operative market maker order qualification criteria.
  • payment of the amount of money that the buyer owes the seller is requested, such as through sending the user a bill.
  • the amount of money for the reallocated bandwidth can be received from the seller, where it will be processed and sent to the seller, placed in an account of the seller, and/or used to pay amounts of money the seller owes to a third party or for the transaction fee.
  • an operator captures consumer payment directives using a telephone with a small text display. These consumer payment directives are sent to a central computer operated by the system, which then uses an automated teller machine network to obtain funds in the amount of the payment from the consumer's automated teller machine-accessible bank account. Once the funds are obtained into an account of the system operator, the system determines how to pay the biller, either by wire transfer, debit network using the biller's bank account number, or by check and list.
  • exemplary embodiments of the present invention for performing clearing and settlement functions include bill pay or remittance processing systems as set forth below.
  • the consumer's account with the biller is refe ⁇ ed to herein as the C-B ("consumer-biller") account, thereby distinguishing that account from other accounts: the consumer's account with its bank, the biller's account with its bank, etc.
  • the biller uses the C-B account number to uniquely identify the consumer in its records.
  • Bill pay transactions have several common elements, which are either explicit or can be implied by the nature of the transaction.
  • the first is presentment: a biller presents the consumer with a bill showing the C-B account number and an amount due.
  • the second common element is payment authorization: the consumer performs some act (e.g., signs a check or other negotiable instrument) which authorizes the consumer's bank to transfer funds from the consumer's account to the biller; this element might occur after presentment or before (as in the case of pre-authorized withdrawals), and need not be explicit (delivery of a check is implicit authorization for the amount of the check).
  • some act e.g., signs a check or other negotiable instrument
  • This element is almost always accompanied by some action by the consumer bank to ensure payment to it from the consumer, such as withdrawing the funds from consumer's bank account, posting the amount to the consumer's credit card account or line of credit, etc.
  • the third common element is confirmation to the consumer of the funds withdrawal.
  • the fourth common element is the crediting of the payment to the C-B account. In some cases, the biller acknowledges the crediting with nothing more than refraining from sending a past due bill.
  • Figures 16 through 18 show block diagrams of bill pay systems which implement these four common elements in different ways.
  • the participants are shown in ovals, and the flow of material is shown by numbered arrows roughly indicating the chronological order in which the flows normally occur.
  • the a ⁇ ows embody a link, which is a physical link for paper flow, a data communications channel from one point to another, or other means for transferring material.
  • the alternatives might be shown with a common number and a letter appended thereto, such as "2" and "2A”.
  • "Material” refers to documents and/or information, whether paper-based ("postal mail"), electronic (e-mail, messages, packets, etc.), or other transfer medium. In most cases, the material which is flowing is shown near the arrow which links the material's source and destination.
  • FIG 16 is a block diagram of a paper bill pay system 1600, wherein billers send paper bills or coupon books to consumers and consumers return paper checks and payment coupons.
  • the proof and capture process for these remittances is highly automated, except for the aptly-named "exception items.”
  • the participants are a consumer C (1602), a biller B (1604), consumer C's bank (Bank C) 1606, biller B's bank (Bank B) 1608 and, optionally, a lockbox operator 1610.
  • Bank C maintains consumer C's bank account 1612 and a clearing account 1614, while Bank B maintains biller B's bank account 1616 and a clearing account 1618.
  • the material passing between the participants includes a bill 1620, a remittance 1622 comprising a check 1624 and a payment coupon 1626, an account statement 1628, an accounts receivable (“A/R”) data file 1630, an encoded check, which is check 1624 with MICR encoding, and possibly a non-sufficient funds (“NSF”) notice 1636.
  • a bill 1620 a remittance 1622 comprising a check 1624 and a payment coupon 1626
  • an account statement 1628 an accounts receivable (“A/R”) data file 1630
  • an encoded check which is check 1624 with MICR encoding
  • NSF non-sufficient funds
  • Bill 1620 indicates a C-B account number and an amount due, and is typically divided into an invoice portion to be retained by consumer C and a payment coupon portion to be returned, each of which shows the C-B account number and amount due.
  • Remittance 1622 contains check 1624 drawn on consumer C's account 1612 at Bank C and payment coupon 1626, preferably included in the return envelope provided by biller B.
  • Biller B then MICR encodes the amount of the remittance onto check 1624 to create encoded check 1634, and deposits check 1634 (arrow 3), and credits consumer C's account in biller B's customer general ledger (“G/L”) account database 1632.
  • G/L customer general ledger
  • remittance 1622 is mailed to lockbox operator 1610 (a ⁇ ow 2A), which opens remittance 1622, MICR encodes check 1624 to create encoded check 1634, captures the C-B account number and amount of the check electronically to create A/R data file 1630.
  • Lockbox operator 1610 then sends A/R data file 1630 to biller B, and sends encoded check 1634 to Bank B to be credited to biller B's account 1616 (a ⁇ ow 3A).
  • check 1634 Because check 1634 is signed by consumer C, it authorizes Bank C to pass the amount of the check to Bank B after Bank B presents the check to Bank C.
  • the signed check serves as the second common element of a bill pay transaction: authorization.
  • Bank C Of course, if biller B has sufficient credit rating with Bank B, Bank B could move the funds from clearing account 1618 to B's account 1616 when Bank B receives check 1634. At some time following the clearing of check 1634, biller B also updates its A/R records in G/L database 1632 to credit consumer C's C-B account, and Bank C confirms to consumer C the withdrawal of the amount of check 1634 by listing it on statement 1628 and/or by the return of cancelled check 1634. If the check doesn't clear, then biller B and other parties to the transaction unwind the payment.
  • bill pay system 1600 One benefit of bill pay system 1600 is that, for nearly all billers, there is no need for biller enrollment (any consumer can pay a biller without prior a ⁇ angements or a waiting period).
  • GIRO systems Similar to the above system is the GIRO systems used in several countries in Northern Europe.
  • the GIRO systems were set up there either by the government or the postal system, which is a traditional supplier of financial services.
  • each bill payer and each bill payee be assigned a GIRO number.
  • the biller sends bills with its biller GIRO number on the payment coupons.
  • the layout, shape, etc. of the GIRO payment coupons is also mandated, so a consumer will receive similar coupons with each bill. After reviewing the bill, the consumer simply adds their GIRO number to the payment coupon and signs it.
  • the payment coupon also serves as a banking instrument similar to a check.
  • the consumers in a GIRO system are comfortable with it because the payment coupons all look the same.
  • the consumer then mails the payment coupons to either a GIRO central processor or its own bank, which then sorts them by biller GIRO number and submits them to the biller. Since the payment coupons are all in a fixed format, they can be easily encoded in a machine readable format, including the payment amount, which the biller pre-prints onto the coupon. If the consumer gives their GIRO number to the biller, the biller can also pre-print that number on the payment coupon as well. Since all the coupons look the same, the banks can process them like a check and achieve economies of scale.
  • FIG 17 is a block diagram of an alternate bill pay system 1700, which reduces the effort required on the part of consumer C relative to bill pay system 1600, but which increases costs for billers.
  • the difference between bill pay system 1700 and bill pay system 1600 is that consumer C initiates payment electronically (or by other non-check means).
  • Bill pay system 1700 includes most of the same participants as bill pay system 1600: consumer C, Bank C, Bank B, possibly a lockbox operator (not shown in Figure 17), and biller B, who is typically not a proactive or willing participant in this system. Additionally, a service bureau S (1702) and a Bank S (1704) are participants, with service bureau S maintaining a service database 1706 which is used to match bill payment orders with billers. The material passing among the participants includes bill 1620, as in the prior example, as well as a bill payment order 1708 and related confirmation of receipt 1716 (both typically transmitted electronically), an enrollment package 1709, a biller confirmation 1710, a bill payment 1712 ("check and list”) which includes check 1714.
  • bill pay system 1700 consumer C enrolls in bill pay system 1700 by sending service bureau S (arrow 1) enrollment package 1709 comprising a voided check and list of billers to be paid by S on behalf of C. S subsequently sends biller B biller confirmation 1710 (arrow 2) to verify (a ⁇ ow 3) that C is indeed a customer of B.
  • bill pay system 1600 With bill pay system 1600 ( Figure 16), consumer C identifies the proper biller by the remittance envelope and the payment coupon, neither of which is available to service bureau S in bill pay system 1700.
  • service bureau S must identify the correct biller for each bill payment order some other way. Typically, service bureau S does this by asking consumer C for biller B's name, address, telephone number and consumer C's account number with biller B ("C-B account number"). Since neither Bank C nor service bureau S may have any account relationship with biller B, they must rely upon consumer C's accuracy in preparing enrollment package 1709 which is used to put biller B's information into service database 1706.
  • Service bureau S typically requires this information only once, during biller enrollment, storing it to service database 1706 for use with subsequent payments directed to the same billers. Of course, if this information changes, service database 1706 would be out of date. If this information is wrong to start with, or becomes wrong after a change, service bureau S might send funds to the wrong entity. What a service bureau will often do to reduce e ⁇ ors in biller identification is to not allow the consumer to make payments to a biller for a specified time period after enrolling the biller, to allow service bureau S to verify biller B and the C-B account structure with biller B in a biller confirmation message 1710.
  • consumer C receives bill 1620 (a ⁇ ow 4) and initiates bill payment order 1708
  • Bill payment order 1708 includes authorization for service bureau S to withdraw funds from C's account 1612 to pay bill 1620, the amount to pay (not necessarily the amount due on bill 1620), the date on which to pay, and some indication of biller B as the payee.
  • Service bureau S responds with confirmation of receipt 1716 indicating that bill pay order 1708 was received (arrow 6).
  • Consumer C can send bill pay order 1708 in any number of ways, such as using a personal computer and modem, directly or through a packet of other data network, via an automatic teller machine (ATM), video touch screen, a screen phone, or telephone Touch- ToneTM pad (TTP) interacting with a voice response unit (VRU). However this is done, service bureau S receives one or more bill pay orders from consumer C. These orders could be instructions to pay some amount for a bill or a set amount of money at periodic intervals.
  • ATM automatic teller machine
  • TTP telephone Touch- ToneTM pad
  • service bureau S Assuming that service bureau S has correctly identified and confirmed that biller B is a biller which consumer C desired to pay with bill pay order 1708, then service bureau S passes the funds to biller B as biller payment 1712 (a ⁇ ow 12) after securing funds to cover the remittance.
  • Bill payment can take several forms as discussed below.
  • a "check and list" is depicted, which is common in the art.
  • a check and list comprises a single payment, check 1714 drawn on service bureau S's account 1718, accompanied by a list of all consumers whose individual remittances are aggregated in the single check.
  • the list shows C-B account numbers and payment amounts for each consumer included on the list which should total to the amount of the single check 1714. This process brings some economies of scale to service bureau S, although at additional expense to biller B. In some cases, rather than endure the expense of checking over the list to ensure it matches the check amount, biller B will refuse to accept that form of payment.
  • service bureau S clears check 1634 through Bank S 1704 drawn on C's account 1612 at Bank C (a ⁇ ows 7-11). S then sends payment 1712 to biller B (arrow 12).
  • Biller B must treat payment 1712 as an exception item, posting G/L database 1632 from the list instead of payment coupons as in bill pay system 1600.
  • Biller B deposits check 1714 with Bank B (arrow 13) who clears it through Bank S and a settlement account 1720 to obtain good funds for B's account 1616 (arrows 14-17). If the bill pay transaction goes through, Bank C will confirm that it went through by sending a confirmation (typically statement 1628) to consumer C. The cycle is completed (a ⁇ ow 18) when consumer C receives notice that funds were withdrawn from C's account 1612 for the amount entered in bill pay order 1708.
  • S sends an individual check 1634 (unsigned— signature on file) drawn on C's account 1612 to biller B in response to bill pay order 1708.
  • biller B is less likely to refuse this form of payment over a check and list, and the biller is less likely to have problems of the list not balancing or having bad account numbers.
  • S instead of a check from Bank C cleared through Bank S to credit S's account 1718, S has Bank S submit a debit to C's account 1612 through the Automated Clearing House ("ACH") (see Figure 18 and accompanying text).
  • ACH Automated Clearing House
  • S may send A/R data and a credit to biller B through one path of: i) Bank S to ACH to Bank B to biller B or ii) MasterCard's RPS (Remittance Processing System) to Bank B to biller B.
  • the RPS is merely an alternative to the ACH.
  • S sends simultaneous ACH transactions (debit account 1612 and credit account 1616).
  • FIG 18 is a block diagram of yet another bill pay system 1800, which is usually used with billers who expect regular, periodic and small payments. Relative to the previously discussed bill payment systems, billers generally prefer bill pay system 1800 when they are set up to handle such transactions.
  • Bill pay system 1800 while providing more efficient remittance processing by biller B due to its increased control over the process, leaves consumer C with very little control over the bill pay transactions after the relationship is set up, since consumer C is typically required to give biller B an open ended authorization to withdraw funds. Furthermore, bill pay system 1800 is not appropriate for all types of billers, such as those who do not have an on-going and predictable relationship with consumers.
  • Figure 18 introduces several new items which flow among the participants including ACH 1802, such as a voided check 1806, a debit advice 1808, a pre-authorization message 1810, and a debit request message 1812.
  • ACH 1802 such as a voided check 1806, a debit advice 1808, a pre-authorization message 1810, and a debit request message 1812.
  • biller B is required to maintain an additional customer database 1804.
  • biller B optionally sends debit advice 1808 to consumer C, and sends debit request message 1812 to biller B's bank, Bank B, which then sends it through the ACH 1802 to Bank C, which debits C's account 1612 and transfers the funds to biller B's account 1616 via the ACH.
  • the transaction is confirmed to consumer C on bank statement 1628 sent to consumer C from Bank C.
  • debit request message 1812 might be rejected by Bank C for, among other reasons, non-sufficient funds, resulting in the flows along arrows 10-12.
  • centralized call setup opens up some interesting possibilities. As a single system will know the state of the network at all times, it could potentially increase prices in those areas where demand is greatest. Armed with real- time call information, a centralized management system could analyze the information and automatically raise the bandwidth providers' wholesale prices in high traffic areas. On a similar note, the bandwidth providers could also lower their prices in areas where the network is underutilized in order to stimulate demand. Assuming bandwidth demand is elastic, this would allow a bandwidth provider to price its wholesale services at the exact point where supply hits demand, optimizing its revenues. In order to maintain a sense of autonomy, a bandwidth provider could offer its distributors a series of APIs that allow them access to Operations Management functions at the central location. In addition, a graphical user interface could be developed to permit remote configuration and management. The central application could be designed in such a way that distributors would only have access to their managed partition.
  • the Service Manager will probably need to reside at the distributor's location. Any hooks between the Service Manager and Operations Manager that are required to map content to a bandwidth provider's services, will have to traverse the bandwidth provider's network.
  • Another downside to a centralized call setup mechanism is that it represents a single point of failure. However, this could be solved by providing a backup system located at another site.
  • bandwidth market will provide an efficient mechanism for pricing services.
  • the bandwidth market does not address the problem that distributors face in figuring out ways of billing content charges to customers who are not owned by their own DVNS.
  • a Content Market which is outlined in the next section, provides a potential solution for addressing this problem.
  • bandwidth provider While a bandwidth provider will focus on providing wholesale bandwidth to distributors, many of these distributors will be content providers. In order to attract distributors, a bandwidth provider must make sure that it offers them the ability to market and sell their services to customers over the bandwidth provider's network. A Content Market could provide an excellent avenue for distributors to sell their services.
  • bandwidth costs are considered to be a negligible component that a provider absorbs in favor of content charges. Based on this trend, it is desired for bandwidth providers to focus more on billing for content and less on bandwidth. Bandwidth will essentially be an element of their overall cost structure.
  • bandwidth costs to show a long movie will be greater than a shorter current release, it may not be economically desirable to show the long movie even though the distributor's rental cost of the movie is most likely less than the new release.
  • the problem of tying content to bandwidth can be solved by allowing the distributor to add a Content ID as a User Defined Information Element during call setup. This Content ID will flow through the usage collections and wholesale rating processes, and eventually be used by the DVNS to correlate a content event back to a call.
  • the content provider could require each customer that accesses its services to open an account. The customer could then be billed separately for the content that they use.
  • This approach has a number of flaws.
  • customers may not be willing to wait for service providers to open their accounts before accessing the distributor's content.
  • a more attractive alternative to content providers opening accounts for every customer is for the distributors to provide a billing channel for content charges incurred by their customers. Although this could be achieved through bilateral agreements between distributors, it may be more practical in the form of a Content Market.
  • a Content Market By providing a billing channel for value added service charges, a Content Market would allow content providers to sell their services to anyone who has access to the bandwidth provider's network. Unlike the bandwidth market, the Content Market would mainly provide billing functions.
  • the bill pay systems as set forth above may be used, as may any other suitable billing system or pay system.
  • a software publishing company in a first location could now sell its products to a customer in a second location, without worrying about how it will get paid.
  • a bill for the services would be sent by the content provider's DVNS to the customer's DVNS through the Content Market clearinghouse. The recipient DVNS would then bill its customer for the services they used.
  • the content charges would show up on the customers bill from the distributor.
  • the Content Market could be designed to allow descriptive messages for content services to flow through the system in order to help the customer understand the charges.
  • Figure 19 illustrates such method of providing an open market environment for electronic content.
  • a listing of the content available from the content provider may be displayed.
  • a request for content by a distributor is received. Such a request for content may be initiated by a customer, such as when a customer orders content from the distributor, or may come directly from the customer.
  • the request for content is preferably received electronically and should include an identification of the content requested.
  • the request for content is transmitted to a content provider.
  • the content and a content identifier are received from the content provider in operation 1904 in response to the request for content.
  • the content and the content identifier are sent to the distributor for delivery to the customer in operation 1906. More detail of operations 1902 through 1906 is provided below with reference to Figures 20 through 22.
  • a bill for the content and the content identifier are received from the content provider in operation 1908, which are then communicated to the distributor in operation 1910 which allows the distributor to bill the customer. Alternatively, payment may be received directly from the customer.
  • One of the bill pay systems set forth above may be used to send the bill to the distributor or customer.
  • descriptive messages relating to the bill are communicated between the content provider and the distributor to help the customer understand the bill. These messages are included with the bill. Examples of such messages may include an identification of the content sent, its price, an amount of a discount, etc.
  • Figure 20 illustrates another manner of performing operations 1902 through 1906 of Figure 19.
  • the digital good i.e., content
  • a purchase price for the digital good is negotiated in operation 2002.
  • a request for quotation or a bid is received from the customer in operation 2004 and forwarded to the content provider.
  • This material may include credentials identifying the customer for purposes of, for example, providing a discount.
  • a request for delivery of the goods is received from the customer in operation 2006.
  • the goods may be encrypted in operation 2008 and sent to the customer in operation 2010.
  • Figure 21 illustrates an optional encryption technique designed to ensure payment by the customer.
  • the digital good which the customer wishes to purchase is encrypted.
  • a first cryptographic checksum is calculated for the encrypted good in operation 2102.
  • the encrypted digital good and the first cryptographic checksum are then transmitted to the customer in operation 2104.
  • a timestamp is generated in operation 2106 at the end of goods transmission and sent to the customer in operation 2108.
  • the customer receives the encrypted digital good and the first cryptographic checksum.
  • the customer calculates a second cryptographic checksum for the received encrypted digital good.
  • the customer creates an electronic payment order containing information identifying the transaction, the second cryptographic checksum, credentials, for example, authorizing the customer to purchase the goods, and a timestamp. Thereafter, the electronic payment order is received in operation 2108.
  • the first and second cryptographic checksums are compared in operation 2110 to ensure that they match.
  • a match indicates that the digital good has been co ⁇ ectly received.
  • An electronic signature and a decryption key are added to the electronic payment order in operation 2112 which may be sent to the customer in operation 2114.
  • Figure 22 illustrates an alternative to sending the decryption key and the electronic payment order directly to the customer.
  • the merchant signed electronic payment order and the key are submitted to an account server for review.
  • the account server reviews the information in the electronic payment order and sends a message in response to the review, which is received in operation 2202.
  • the review may include verifying that the customer is authorized to make the requested purchase, verifying that the customer has the necessary funds, and ensuring that the timestamp is valid.
  • an error code is contained within the message which explains why the electronic payment order has not been approved. If the report is positive, the message so indicates and, in operation 2204, the key is included in the message.
  • the message is forwarded to the customer. If the message contains the key, the customer uses the key to decrypt the goods. If, for some reason, the customer does not obtain the key, the customer may contact the account server and obtain a copy of the key from the server.
  • the customer is required to open an account with the content provider before the content is sent to the distributor. This requirement helps ensure payment by the customer, in that the customer's identity may now become known to the content provider.
  • the content provider may be charged a transaction fee, which may be a percentage of an amount of money of the bill or may be a flat fee per transaction or per item.
  • the Content Market could also be used to solve the problem of call termination charges. If a CPE belonging to one distributor wants to call a video phone on a network that is connected to a bandwidth provider, some mechanism needs to be in place to handle call termination charges.
  • the gateway provider that owns the terminating or transit network would like to be able to bill the calling CPE for the cost of the service used on the external network.
  • the bandwidth provider could implement a custom interworking solution to handle this situation, it would have to develop a separate interface for each type of networking service. This could result in a lot of interfaces.
  • the bandwidth provider By treating the termination charge as content, the bandwidth provider would give the gateway distributor the ability to bill the calling CPE's DVNS through the Content Market. After correlating the external termination charge with the call using the Content IE provided by the
  • the gateway DVNS would send the charge for the call to the Content Market along with a message describing the event.
  • the Content Market would then bill the calling party's DVNS for the termination charge.
  • This DVNS could either bill its customer for the termination charge as a separate line item, or match the event with the call and calculate the total charge.
  • the Content Market could be used to provide a billing mechanism for all types of termination charges.
  • a bandwidth provider could offer directory services for content available on its network. These directory services could be extended to include price lists provided by vendors.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Cette invention a trait à un système, à une méthode et à un article fabriqué permettant de fournir un environnement de marché libre pour une largeur de bande. Une largeur de bande est, tout d'abord, attribuée sur un réseau à plusieurs utilisateurs. Le volume de largeur de bande non utilisé par un premier utilisateur est identifiée. Une demande de largeur de bande sur le réseau est reçue, émanant d'un second utilisateur. La largeur de bande non utilisée par le premier utilisateur est ré-attribuée au second utilisateur.
PCT/US2000/024156 1999-08-31 2000-08-31 Systeme, methode et article fabrique permettant d'acheter, de vendre et de negocier une largeur de bande dans un marche libre WO2001017182A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU71061/00A AU7106100A (en) 1999-08-31 2000-08-31 A system, method, and article of manufacture for buying, selling and trading bandwidth in an open market

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US38689699A 1999-08-31 1999-08-31
US09/386,896 1999-08-31

Publications (1)

Publication Number Publication Date
WO2001017182A1 true WO2001017182A1 (fr) 2001-03-08

Family

ID=23527523

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/024156 WO2001017182A1 (fr) 1999-08-31 2000-08-31 Systeme, methode et article fabrique permettant d'acheter, de vendre et de negocier une largeur de bande dans un marche libre

Country Status (2)

Country Link
AU (1) AU7106100A (fr)
WO (1) WO2001017182A1 (fr)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001091022A2 (fr) * 2000-05-19 2001-11-29 Enron Broadband Services, Inc. Negociation de largeur de bande comme des marchandises
EP1376946A1 (fr) * 2002-06-20 2004-01-02 Siemens Aktiengesellschaft Méthode pour fournir capacité de transport additionnelle dans un réseau de télécommunication
WO2008025298A1 (fr) 2006-08-31 2008-03-06 Huawei Technologies Co., Ltd. Système d'ajustement de bande passante dynamique et d'échange entre pairs
CN103888927A (zh) * 2012-12-21 2014-06-25 中国移动通信集团上海有限公司 一种带宽费用确定方法、装置、服务器及系统
WO2016141355A1 (fr) * 2015-03-04 2016-09-09 ShareG, Inc. Système et procédé de distribution de données mobiles
US9639875B1 (en) * 2013-12-17 2017-05-02 Amazon Technologies, Inc. Reconfiguring reserved instance marketplace offerings for requested reserved instance configurations
CN112492007A (zh) * 2020-11-19 2021-03-12 北京百度网讯科技有限公司 物品存/取的方法、装置、设备以及存储介质
US11157999B2 (en) 2002-06-05 2021-10-26 Nasdaq, Inc. Distributed data processing
US11295383B2 (en) 2012-04-16 2022-04-05 Nasdaq Technology Ab Methods, apparatus, and systems for processing data transactions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5596576A (en) * 1995-11-03 1997-01-21 At&T Systems and methods for sharing of resources
EP0881808A2 (fr) * 1997-05-30 1998-12-02 Sun Microsystems, Inc. Réduction du temps de latence en établissant des priorités de bande passante pour des serveurs et des clients

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5596576A (en) * 1995-11-03 1997-01-21 At&T Systems and methods for sharing of resources
EP0881808A2 (fr) * 1997-05-30 1998-12-02 Sun Microsystems, Inc. Réduction du temps de latence en établissant des priorités de bande passante pour des serveurs et des clients

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FULP E W ET AL: "Paying for QoS: an optimal distributed algorithm for pricing network resources", 1998 SIXTH INTERNATIONAL WORKSHOP ON QUALITY OF SERVICE (IWQOS'98) (CAT. NO.98EX136), 1998 SIXTH INTERNATIONAL WORKSHOP ON QUALITY OF SERVICE (IWQOS'98), NAPA, CA, USA, 18-20 MAY 1998, 1998, New York, NY, USA, IEEE, USA, pages 75 - 84, XP002154150, ISBN: 0-7803-4482-0 *
HOL K: "BIT BY BID BY BIT DEMAND AND SUPPLY OF BANDWIDTH THROUGH ELECTRONIC AUCTIONS", UTRECHT, NL, AUG. 24 - 28, 1999,LONDON: IBTE,GB, 24 August 1999 (1999-08-24), pages 143 - 147, XP000847185 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001091022A2 (fr) * 2000-05-19 2001-11-29 Enron Broadband Services, Inc. Negociation de largeur de bande comme des marchandises
WO2001091022A3 (fr) * 2000-05-19 2002-08-15 Enron Broadband Services Inc Negociation de largeur de bande comme des marchandises
US11157999B2 (en) 2002-06-05 2021-10-26 Nasdaq, Inc. Distributed data processing
EP1376946A1 (fr) * 2002-06-20 2004-01-02 Siemens Aktiengesellschaft Méthode pour fournir capacité de transport additionnelle dans un réseau de télécommunication
US8169912B2 (en) 2006-08-31 2012-05-01 Futurewei Technologies, Inc. System for dynamic bandwidth adjustment and trading among peers
EP1935161A4 (fr) * 2006-08-31 2009-06-03 Huawei Tech Co Ltd Système d'ajustement de bande passante dynamique et d'échange entre pairs
EP1935161A1 (fr) * 2006-08-31 2008-06-25 Huawei Technologies Co., Ltd. Système d'ajustement de bande passante dynamique et d'échange entre pairs
WO2008025298A1 (fr) 2006-08-31 2008-03-06 Huawei Technologies Co., Ltd. Système d'ajustement de bande passante dynamique et d'échange entre pairs
US11295383B2 (en) 2012-04-16 2022-04-05 Nasdaq Technology Ab Methods, apparatus, and systems for processing data transactions
US11908013B2 (en) 2012-04-16 2024-02-20 Nasdaq Technology Ab Methods, apparatus, and systems for processing data transactions
CN103888927A (zh) * 2012-12-21 2014-06-25 中国移动通信集团上海有限公司 一种带宽费用确定方法、装置、服务器及系统
US9639875B1 (en) * 2013-12-17 2017-05-02 Amazon Technologies, Inc. Reconfiguring reserved instance marketplace offerings for requested reserved instance configurations
WO2016141355A1 (fr) * 2015-03-04 2016-09-09 ShareG, Inc. Système et procédé de distribution de données mobiles
US10038610B2 (en) 2015-03-04 2018-07-31 ShareG, Inc. System and method for distributing mobile data
CN112492007A (zh) * 2020-11-19 2021-03-12 北京百度网讯科技有限公司 物品存/取的方法、装置、设备以及存储介质

Also Published As

Publication number Publication date
AU7106100A (en) 2001-03-26

Similar Documents

Publication Publication Date Title
Gupta et al. Priority pricing of integrated services networks
US7792745B2 (en) Method and system to facilitate financial settlement of service access transactions between multiple parties
US20080065520A1 (en) Host Exchange in Bill Paying Services
Songhurst Charging communication networks: from theory to practice
JP2004514305A (ja) エクストラネット上で情報を送信する方法およびシステム
EP1807792A2 (fr) Systeme et procede permettant de financer une chaine d'approvisionnement
WO2003048996A1 (fr) Systeme et procede de transactions de compte de garantie bloque numeriques et securisees
EP1269373A1 (fr) Procede et systeme de normalisation de donnees de transactions relatives a des acces a un service fourni par une pluralite de fournisseurs de services
US20010034693A1 (en) Method and system to broker a service access transaction
US20100198711A1 (en) Methods for adjusting a fee associated with a payments transaction
US20040024707A1 (en) Dynamic merchant pricing model
WO2001017182A1 (fr) Systeme, methode et article fabrique permettant d'acheter, de vendre et de negocier une largeur de bande dans un marche libre
WO2001017183A1 (fr) Systeme, procede et article de fabrication destines a la negociation automatique d'un contrat lors d'une transaction impliquant une certaine largeur de bande
US20080215506A1 (en) Systems and methods for a community-based e-consultant brokerage
Stiller et al. Management of differentiated services usage by the cumulus pricing scheme and a generic internet charging system
US20020069188A1 (en) On-line payment settlement for multi-party based services
Crémer et al. The pricing of critical applications in the Internet
WO2001037509A2 (fr) Parquet boursier virtuel et agents intelligents pour produits et services de telecommunications
US20030061142A1 (en) Apparatus and Method of trading right to use electric communications equipment and apparatus and method of assigning capacity of electric communications equipment
Stiller et al. Pre-study on “Customer Care, Accounting, Charging, Billing, and Pricing”
EP1275052A2 (fr) Gestion d'actifs durant le cycle de vie et en reseau dans un environnement de commerce electronique et procede associe
Lehr et al. Show me the money: Contracts and agents in service level agreement markets
US20030074438A1 (en) Techniques for enabling an internet services provider to perform office operations and functions
WO2003038562A2 (fr) Systeme et procede de fourniture de services de reseau
Ponprasit Network implement of thai farmers bank

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CU CZ DE DK DZ EE ES FI GB GE GH GM HR HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WA Withdrawal of international application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WA Withdrawal of international application