The invention relates generally to the field of transporting and managing data over a wide area network, and more specifically to processing, managing, delivering, transporting, compressing, authorizing, authenticating and billing voice data.

A collect call (also known as a called party billed call) is a telephone call in which the called person pays for the call. Typically, the calling party calls a number and asks that the call be made"collect."In a collect call, the phone company must get authorization from the person receiving the call that the called party will pay for the call. The called party responds to a collect call request by saying"yes"or hitting a button on a touch-tone phone. Sometimes, the calling party has previously signed up for the service to allow the calling party to bill calls to the registered phone number.

Third party billing allows the calling party to bill a third party phone number.

The person calls a number and asks that the call be billed to a third party number.

Typically, the phone company must obtain authorization from the person being billed for the call, along with an assurance that the third party will accept the call charges.

However, such authorization is not necessarily required for each new call.

Until recently, collect call billing and third party billing methods and services have been carried out over circuit switched telephone networks. In order to use such available methods, a dedicated circuit must first be established between the"calling party"and the"called party". This method is inefficient and results in substantial service costs, plus substantial mark-up profits for the entity controlling the circuit-based switching system.

There is therefore a need in the art to provide a circuit-independent system for establishing and tracking collect and third party billed calls across a packet-based data network.

SUMMARY OF THE INVENTION To address the shortcomings of the available art, the invention provides a method and system for called and third party billing over a data network. After a customer receives an access phone number to initiate a free call to the United States, the customer makes a local call in his home country to a gateway computer (a computer

server that connects a telephone or telephone network to the Internet). The gateway answers the call and requests a destination number from the caller, then stores the number and records the customer's name. A message is then played to remind the customer to wait while the called party is contacted.

The recorded name and destination number are then packetized or encoded (digitized and reformatted into data packets for transmission across the Internet). This data is sent to a second, remote gateway, decoded, and the call destination is verified through a Line Identification Database (LIDB). The LIDB tells the system, preferably through an X. 25, SS7 or IP network solution, whether the destination number is valid and billable.

Once approved, the destination number is dialed. The called party at the destination number then answers the phone and hears the playback of the caller's pre- recorded name. The called party is asked to perform a function, e. g., pressing a key on the touch-tone keypad or staying on the line, to accept the call. If the called party performs the required function, the caller and the called party are connected and their phone call proceeds. At the end of the call a Call Detail Record ("CDR") is generated and stored for billing purposes.

Alternative embodiments for third party billing and pre-paid calling are also disclosed and claimed herein.

It is therefore a first advantage of the present invention to provide a method, and means for implementing the method, of telephone communication connection and billing across a wide area network, the method comprising the steps of accepting at a first gateway a first user-initiated call from a calling number to a called number, confirming the availability of a credit unit associated with the called number to accept a debit cost associated with the call, initiating a telephone communication between the first user and a second user across the wide area network, and forwarding billing information regarding the telephone communication and applying the debit cost to an account associated with a billed number other than the calling number. In an alternative embodiment, the method further comprises the steps of recording data identifying the first user, forwarding the recorded data across the wide area network to a second gateway, transferring the recorded data to a second user at the called number, and

confirming the second user will accept the call. The billed number may also be the called number, and the wide area network may be the Internet or another data network.

It is a second advantage of the invention to provide a method, and means for implementing the method, of telephone communication connection and billing across a wide area network, the method comprising the steps of accepting at a first gateway a first user-initiated call to a called number, recording data identifying the first user, confirming the availability of a credit unit associated with the called number to accept a debit cost associated with the call, forwarding the recorded data across the wide area network to a second gateway, transferring the recorded data to a second user at the called number, confirming the second user will accept the call, initiating a telephone communication between the first and second users, and forwarding billing information regarding the telephone communication to a database associated with the called number.

The wide area network may be the Internet or another data network.

It is another advantage of the invention to provide a wide area network-enabled call completion and billing system, compatible with the Internet and the Public System Telephone Network (PSTN), the system comprising a first gateway connected to a first handset across the PSTN, the first gateway being programmed to gather caller data and called number data via the first handset, and a second gateway connected to the first gateway across the wide area network, the second gateway being programmed to receive the caller data from the first gateway and forward the caller data to a called party at a second handset, and programmed to receive the called number data from the first gateway and direct billing according to whether the called party accepts the caller's call.

BRIEF DESCRIPTION OF THE DRAWINGS The aforementioned advantages of the present invention as well as additional advantages thereof will be more clearly understood hereinafter as a result of a detailed description of a preferred embodiment of the invention when taken in conjunction with the following drawings.

FIG. 1 illustrates a first embodiment of an inventive system enabling collect call and third party billing according to the invention.

FIG. 2 illustrates a second embodiment of an inventive system enabling collect call and third party billing according to the invention.

FIG. 3 illustrates the software and protocol requirements provided as part of the inventive method and system.

FIG. 4 illustrates a third embodiment, including a call agent, of an inventive system enabling collect call and third party billing according to the invention.

FIG. 5 is a flow chart illustrating the method of the invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the detailed description is not intended to limit the invention to the particular forms disclosed. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

DESCRIPTION OF PREFERRED AND ALTERNATIVE EMBODIMENTS Turning first to Figure 1, a call connection and billing system 10 is illustrated in accordance with the present invention. An international collect calling scenario will be used to describe the invention, although any collect or third party billing scenario is equally applicable to the inventive system. Initially, a user calls gateway 1 from telephone handset 2 to initiate the collect call. Handset 2 can comprise a typical telephone connected to a plain old telephone service ("POTS") line, a specially configured IP telephone set, an IP terminal adapter, a personal computer, a wireless handset, or any of myriad other telephony-enabling devices. The handset user is typically greeted by gateway 1 with an automated message requesting the destination number of the person the user is trying to call. Gateway 1 then requests that the user enter identification, typically the user's name, although another identification technique can be used. The user then speaks his or her name into handset 2. Gateway 1 records the user's identification. The user is then placed on hold while gateway 1 encodes and packetizes the users name for transmission to remote gateway 3, as described below and understood by those skilled in the art. Gateway 3 checks the LIDB 5, preferably through the X. 25 protocol or SS7, for payphone numbers and known fraudulent ("black") numbers to prevent fraud through use of the present invention. After the LIDB query, the destination number is compared against a billing server database (not

shown) to check whether the number has been called before, and, if so, the available credit balance is checked. Available products for accomplishing this step include NetManagert brand callflow and billing management and Skywaretm brand application interface software available from the assignee of the invention and described in U. S.

Patent Application Serial No. 09/404,109, filed September 23,1999 and entitled Communication System, Transmission Apparatus, Controller and Communication Method, which is incorporated herein by reference. If the balance exceeds or will exceed the allowable level for that customer, then the call is not allowed. Gateway 3 then stores the accessed data, or some representation of the data, in an internal database and decodes the recorded user identification information.

If the call is authorized, gateway 3 then places a call through the switch network 7 to a user's destination number. When the destination handset is answered, gateway 3 initiates a recorded message (or connects the called party to a live operator) informing the called party at the destination number that there is a call from the user, and identifies the user by playing recorded identification information. Gateway 3 then gives the called party the option to accept or refuse the call. If the called party accepts, gateway 3 sends an"accepted"message to gateway 1, and the call is connected between gateways 1 and 3. Once the conversation ends, billing data is routed from switch 7 to a billing office for gateway 3. If the call was refused, gateway 3 sends a"refused"message to gateway 1, which informs the user that the call was refused. At that point, control is returned to the call initiator to determine next steps. The call initiator can then choose to select an alternative method for paying for the call, e. g., credit card, calling card, alternative third party to bill, or other acceptable payment method. Alternatively, the call initiator can choose to hang up and end the call attempt.

Turning next to FIG. 2, we describe the connection details embedded within the gateways of FIG 1, in the form of a hierarchical protocol stack structure moving from the components in the physical realm, near the bottom, to the user interface at the top.

To connect to the Public Switched Telephone Network ("PSTN"), each gateway preferably uses high-speed interface cards (e. g., American T1 or European El) to interface to digital trunk lines or analog cards to interface to PBX and analog lines. The analog line card transports and, if necessary, digitizes the data through a PSTN physical interface, preferably to a commonly known Multi Vendor Integration Protocol

("MVIP") based Pulse Code Modulated ("PCM") bus. At this point, the data is in companded G. 711-1 format (either A-law or mu-law, typically 64 kbps voice data per channel).

From the MVIP bus, the data is routed to one or more digital signal processing ("DSP") boards, the boards providing a multi-point cross bar switch that routes any of the 256 channels on the MVIP bus to any of the plurality of DSPs on the board. The DSP receives and transmits this data on a buffered serial port ("BSP"), the BSP thereby off-loading from the DSP the processing required to access the data, leaving more instruction cycles for data compression tasks. Once inside the DSP, voice data streams are encoded (or decoded, for data traveling in the opposite direction) to compress each voice channel to 5.3 kbps (for the G. 723.1 standard) from 64 kbps. Touch tone (DTMF) detection, echo cancellation, and silence compression are performed as well. Available Voice Over Internet Protocol ("VoIP") gateway systems offer G. 723 or G. 729 (a) voice compression options as well as G3 Fax options.

Using the host port interface on a DSP, the host computer accesses compressed data through a programming interface. Since each DSP board can process up to 60 channels of voice data, the data rate to the handset's network host computer is less than 60 kbytes/second/board. Once received by the network host, the data is"packetized" for transport, appropriate headers (e. g., H. 323 or IP) are added to the voice packets, and the data is routed to a network interface card ('NIC") for transmission to the Internet.

On the receiving end, gateway 3 receives H. 323 packet data from the Internet and performs the process outlined above in reverse: the packets are reassembled by a host PC, decoded by the DSP board, and routed to the PSTN by the analog line cards. To suppress jitter, receiving gateway 3 places received packets in their correct order, discarding packets that arrive too late, and inserts error-correcting filler data (also known in the art as"fly wheels") as necessary to ensure a continuous data stream to the PSTN.

The host PC also provides a gateway programming interface, referred to herein as the Gateway Control Interface ("GCI") that extends the capabilities of the gateway, providing remote gateway management. An available GCI embodiment can be obtained from Xybridge, Inc. of Richardson, Texas, and is described at that company's web site

and in its publication entitled"Telephony ASP-Emerging Out of Convergence"by Payam Maveddat, published April 2000, which is incorporated herein by reference.

FIG. 3 illustrates an inventive called party billing scenario over a leased circuit in accordance with the present invention. The user calls gateway 1 to make a collect call. The user is typically greeted by gateway 1 with a message that requests the destination number of the intended party to call. Gateway 1 then requests that the user enter identification, typically the user's name, although another identification technique can be used. The user then speaks his or her name into handset 2. Gateway 1 records the user's identification information and the user is placed on hold while the gateway 1 encodes and packetizes the user's name for transmission to gateway 3. Gateway 3 checks the LIDB, preferably through the X. 25 protocol, for payphones and black numbers to prevent fraud. Gateway 3 stores the data in an internal database, and decodes the recorded user identification information. After the LIDB query, the destination number is checked against the billing server database to see if the number is known and the billing balance acceptable.

Next, gateway 3 places the call through trunk 8 and switch 7 to outbound trunk 9, leading to the user's destination number/handset. When the destination number is answered, gateway 3 informs the called party at the destination number that there is a call from the user, and identifies the user by using the recorded identification information. Gateway 3 then gives the called party the option to accept or refuse the call. If the called party accepts, gateway 3 sends an"accepted"message to gateway 1, and the IP call is connected between gateway 1 and gateway 3 through gateway 2 on direct circuit trunk 11. Gateway 3 then signals switch 7 to connect trunk 9 to trunk 11, and gateway 3 disconnects from trunk 8. Once the conversation ends, billing data is routed from the switch to the billing office for gateway 3. If the call was refused, gateway 3 sends a"refused"message to gateway 1, which informs the user that the call was refused, whereupon control is returned to the call initiator to determine the next steps, such as redirecting the billing or hanging up and ending the call attempt.

FIG. 4 illustrates the use of a call agent 15 within the context of the system of the present invention. Initially, a user calls gateway 1 to make a collect call. Gateway 1 sends a message to the call agent 15 that there is an incoming call. Call agent 16 signals Interactive Voice Response (IVR) server 17 to prompt the user, preferably with a

message requesting the destination number of the called party. IVR server 17 then requests that the user enter identification, typically the user's name, although another identification technique can be used. The user then speaks his or her name into the handset. IVR server 17 then records the user's identification and the user is placed on hold while the gateway 1 encodes and packetizes the user's name for transmission to gateway 3. It should be noted that there may be a direct connection between gateway 1 and the IVR server or call agent, but a network connection, as shown, is preferred.

Gateway 3 then checks the LIDB for fraud, and billing information is checked and compiled, as discussed above. Gateway 3 then stores the data in an internal database and decodes the recorded user identification information.

Gateway 3 then places a call through the switch network to user's destination number. When the destination number answers, Gateway 3 informs the called party there is a call from the user, and identifies the user by using the recorded identification information. Gateway 3 then gives the called party the option to accept or refuse the call. If the called party accepts, Gateway 3 sends an"accepted"message to Gateway, and the IP call is connected between Gateway and Gateway 3. Once the conversation ends, billing data is routed from the switch to the billing office for Gateway 3. If the call was refused, Gateway 3 sends a"refused"message to Gateway, which informs the user that the call was refused. At that point, the present invention returns control to the call initiator to determine what the initiator wants to do. The call initiator can choose to select an alternative method for paying for the call, e. g., credit card, calling card, alternative third party to bill, or other acceptable payment method. Alternatively, the call initiator can choose to hang up and end the call attempt. Although described with respect to a touch-tone type of telephone, the present invention can also be used with a rotary or other type of telephone. Where a rotary phone is to be used to determine the destination number to complete the call, the user can be assisted by a live operator over a data voice connection, or use voice recognition to indicate the destination number.

Further, the user can use other means, such as electronic mail, to set up the call, or use a call agent-based management scheme as described above.

Referring next to FIG. 5, there is provided a flow chart illustrating the above- described method of the invention, particularly the above-described international collect calling scenario. At step 100, a user calls gateway 1 from telephone handset 2 to initiate

the collect call. At step 105, the user is greeted by gateway 1 with an automated message requesting the destination number the user is calling and the user's name or other identification for recordation and recognition. Gateway 1 thereby establishes the called number and records the user's identification information at step 110. The user is then placed on hold at step 115 while gateway 1 encodes and packetizes the user's name for transmission to remote gateway 3. At step 120. gateway 3 checks a known number database for numbers to which a collect call may not be billed, thereby preventing fraud.

At step 125, the destination number is compared against a billing server database (not shown) to check whether the number has been called before, and, if so, the available credit balance is checked. If the balance exceeds or will exceed the allowable level for that customer, then the call is not allowed. Otherwise, at step 130 gateway 3 stores the accessed data, or some representation of the data, in an internal database and decodes the recorded user identification information.

At step 135, gateway 3 then places a call through the switch network 7 to the called number. At step 140, when the destination handset is answered, gateway 3 initiates a recorded message (or connects the called party to a live operator) informing the called party at the destination number that there is a call from the user, and identifies the user by playing the recorded identification information forwarded from gateway 1.

Gateway 3 then gives the called party the option to accept or refuse the call at step 145.

If the called party accepts, gateway 3 sends an"accepted"message to gateway 1, and the call is connected between gateways 1 and 3 at step 150. Once the conversation ends, at step 155 billing data is routed from switch 7 to a billing office for gateway 3. If the call was refused, gateway 3 sends a"refused"message to gateway 1 at step 160, which informs the user that the call was refused. At that point, control is returned to the call initiator, who can then choose to select an alternative method for paying for the call, e. g., credit card, calling card, alternative third party to bill, or other acceptable payment method. Alternatively, the call initiator can choose to hang up and end the call attempt.

A toll-free calling embodiment (equivalent to collect call billing not requiring called party authorization for each call) is also enabled by the inventive system and method. The party to be called toll free preferably pays a service fee, making a designated phone number a toll free number, and is given a personal identification number ("PIN") for distribution to desired callers. The customer will then give desired

callers the PIN and a local access number for the country or area a caller might be calling from. For example, the caller dials a local number in Mexico City, which is designated for toll free services. The caller will be prompted to enter the number she wants to call and the toll free PIN. After the PIN is authorized, the call is connected. A call record is then created and sent to the LEC for billing on the called party's home phone bill. Of course, pre-paid accounts can also be used for the benefit of either the caller or a third party, and a transferred billing arrangement is easily adapted for third party billing of local calls, thereby enabling an emigrant overseas to help family members at home by paying for the family's phone costs through his own local phone bill.

It should be noted that a number of additional alternative embodiments can be practiced without deviating from the spirit and scope of the invention. For example, the user may purchase a prepaid or credit-enabled calling card associated with a PIN enabling access to dedicated points of presence ("POPs") throughout the world. By entering the PIN, the user is able to place calls to any destination around the world using the above-described system. This service allows the user to roam from country to country using the same prepaid card, the described scenario being similar to a third party billing scenario, wherein the third"party"is actually the account tied to the PIN.

Moreover, calling cards issued by local exchange carriers ("LECs") may use the above- described service and bill it through the LEC account to a local phone bill.

For business-to-business toll free applications, the above-described service may be modified to allow international toll free access to and from multiple international destinations. Users simply call what appears to be a normal phone number, but all billing for that number is routed to the called party rather than the calling party.

Similarly, any third party can arrange to cover the cost of another beneficiary's call charges according to the above-described system, as a gift, promotional campaign, or customer service feature. In a promotional example, the user might call a third party- billed number, hear a music sample across the telephone handset, and order a copy of the sampled music through the call, the charge to be billed to the user's credit card or a pre-paid account. Myriad other electronic data transfer transactions can be accomplished using the method and system of the invention, as will be understood by those skilled in the art to which the present invention pertains.

Although the present invention has been shown and described with respect to preferred embodiments, various changes and modifications lie within the spirit and scope of the claimed invention. Thus, the corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims are intended to include any structure, material, or acts for performing the functions in combination with other elements as specifically claimed.