WO2007024061A2

WO2007024061A2 - Billing and telecom portal service

Info

Publication number: WO2007024061A2
Application number: PCT/KR2006/002739
Authority: WO
Inventors: Yang-Soon Cha; Ki-Cheon Kim
Original assignee: Yang-Soon Cha; Ki-Cheon Kim
Priority date: 2005-08-25
Filing date: 2006-07-12
Publication date: 2007-03-01
Also published as: KR20050094363A; WO2007024061A3

Abstract

The purpose of the disclosure is to add billing and telecommunication functions to Internet portals. Without modifying the user interface of the current portals, they become the representative of telecommunication in the Internet. Dynamic address change and billing at the portal is the main part of the disclosure with a call establishment procedure centered by the portal. The portal is able to make profit from free and pay calls by showing advertisement and billing.

Description

BILLING AND TELECOM PORTAL SERVICE

Technical Field

[1] The present invention is generally related to the Internet telephony and billing.

More particularly, the present invention is related to Internet servers holding the current address of each registered user, telecommunication signaling using a telephone number or an IP address under a unified user interface, and credit card information not shown but used for billing.

[2]

Background Art

[3] At the present time, as the Internet portals provide communication services such as an email using a commonly used interface, the users of the portals are already familiar to the portal interfaces. However, the current Internet portals do not provide telecommunication services, but can make profits by showing advertisements to the users. Thus, if the portals provide telecommunication services, more users will visit the portals, and this will produce more profits.

[4] Even though VoIP technologies are widely tested, there is no systematic method and user interface to manage each user's address and call processing procedure in the Internet. Because the user can change terminal equipment very often (a PC at home and a PC at an office, for instance), the user's address should be dynamically managed. In addition to the frequent change of the address, there are two different major address formats: a telephone number and an IP address. Conventional telephones and mobile phones are still very important telecommunication terminal equipments and needed to be included in the Internet telephony paradigm.

[5]

Disclosure of Invention Technical Problem

[6] For the time being, various telecommunication devices and systems including conventional telephones, mobile phones, and Internet terminal equipments are widely used in a mixed network environment, but the Internet is expected to accommodate all media in the future. However, there is no technology managing voice communication over various networks with a dynamic user address in a different format and no business model to get profit from the Internet telephony. The present technical problem is that the above technology and business model must be invented from nothing.

[7] It seems clear that servers in the Internet for managing dynamic addresses of users are needed and the dynamic addresses must be prepared in different formats. In addition, a business model based on free and pay calls is needed. The Internet portals seem suitable for the dynamic address management and their business model based on free information provisioning also seem suitable for business model based on free calls.

[8]

Technical Solution

[9] At present time, various telecommunication methods such as a telephone, mobile phone and the Internet are being used in a mixed environment, and they are expected to be integrated into the Internet. It seems that portals will be centered for the integration. The present invention extends the services of portals to include telecommunication and billing and provides the users with capability of telecommunication over various networks and billing pursuing convenience and security. By this invention, the portals have chances to make good profit.

[10] The present invention is based on the advent of the Internet telecommunication technology such as VoIP, and the purpose of the present invention is to provide existing portals with a convenient interface to such technology and a convenient payment method. The purpose of the present invention also covers management of different types of telephone numbers by use of a familiar interface of the present portals. The present invention can be achieved by extending an existing portal service, and the overhead of the extended service is not significant. The extension of the portal service includes addition of a new interface, modification of a database, addition of a call processing procedure, and addition of an electronic payment method.

[H]

Advantageous Effects

[12] When the Internet telephony is based on the telecom portal of the present invention, the users can use an existing user interface familiar to them and enjoy the freedom of dynamic address change. With the present invention, even free calls attract more users, and pay calls provide good profits to the portals.

[13]

Brief Description of the Drawings

[14] Figure 1 is a telephone number input interface of the present invention, in which the unified interface of the present invention makes it possible to manage different types of addresses by inputting both a telephone number and a type of the telephone number;

[15] Figure 2 is a network configuration the present invention is applied to, in which a communication call can be setup through an IP network and a telephone network;

[16] Figure 3 is a telephone number management user interface of the present invention which combines a telephone number with the type of the telephone number as a set of a contact address;

[17] Figure 4 is a procedure of requesting the other user's address to a portal, in which a user can request the other user's address registered in another portal different from the user's portal;

[18] Figure 5 is a call request procedure to an access point managing pay calls;and

[19] Figure 6 is an entire network configuration including a VoIP network with QoS guarantee.

[20]

Mode for the Invention

[21] The present invention can have many different embodiments, but only an embodiment with essential ideas will be provided below by use of the figures. According to this embodiment, the present invention can be well understood.

[22] At the present time, we have the telephone network and the Internet for telecommunication. The most remarkable difference between them is the way the user is identified: a telephone number or an IP address. The user ID of each network is devised independently. Thus, they are not compatible and not expected to be integrated into one side in the foreseeable future. However, most users want an integrated interface for both networks.

[23] Figure 1 shows the basic idea of the present invention keeping the type of a telephone number 1 and the telephone number 2 as a set. Various types of telephone numbers or IP addresses can be managed by the interface. It looks simple, but it is very practical and can be utilized in many ways.

[24] In Figure 2, the network configuration of the present invention is presented. A user terminal 3 is connected to an IP network 7 and can access a portal 4 through the network. Because the other telephone 6 is attached to a telephone network 8, a communication equipment interconnecting two different networks is required to make a call from the user terminal 3 to the other telephone 6. This equipment is called an access point 5 in this application document. The user terminal 3 has an IP address, and the other telephone 6 has a telephone number. The present invention makes two different address systems interoperable using a unified interface without address change at any side.

[25] Figure 3 is a user interface for telephone number registration and management. By use of this interface, a user can register, keep, and use an address type and an address of the current terminal. The type of a current terminal 9 is an IP terminal, and an address 10 of the current terminal 9 is 129.254.23.12. The present invention provides a user interface to register a new address by use of a pull-down menu 11 showing the current telephone number. There are many different ways to show the pull-down menu 11. Clicking or double clicking the current address 10 can show the pull-down menu. Once the pull-down menu 11 is shown, by clicking on the new telephone number, the user can register an address type and a new telephone number. After registration, the current telephone number can be changed to the new telephone number by selecting it from the menu 11. This interface is stored in the telecom portal 4 as shown in Figure 2, and many telephone numbers of a user can also be stored in the portal 4. A user of the portal 4 already uses an email service, and an email ID identifies the user. This email user can have many telephone numbers, and they are registered in the portal4. Only one telephone number among many telephone numbers registered for a user is selected as the current telephone number (also called a current address). From this embodiment, it can be understood that the email ID is the best identifier for the user. However, it is also very easy to assign a telephone number to the email user of the portal. Then, the user can be identified by the email ID and at the same time by the telephone number. By use of this type of the Internet telephone number, the conventional telephone user can make a call to the portal user of the present invention. The address resolution method involved with the Internet telephone number is similar to ENUM(electronic numbering) of IETF. For the call from the conventional telephone, the access point should ask a telephone number resolution server for the other user's current address, and the resolution server requests the current address to the resolved portal on behalf of the access point. A portal of the present invention can also work as the telephone number resolution server at the same time. The telephone number resolution server searches the portal address from the database using the called telephone number as the key. When it finds the portal address, it sends the request message to the portal. The resolved portal could be itself.

[26] There is an entirely different call establishment procedure based on signaling by forwarding. The procedure mentioned above is more likely to be standardized, and it is called signaling by replying. Signaling by forwarding is sending a call establishment (initiation) message to the portal without requesting the other telephone number. Instead, the portal finds the current address and forwards the call initiation message to the current address or the portal to which the other user belongs. When the other user's terminal receives the forwarded call initiation message, the response can traverse the forwarding path or be directly delivered to the calling user's terminal. The telecom portal of the present invention can support both signaling by replying and signaling by forwarding.

[27] The current telephone number can be automatically changed into an IP address.

When a user logins into a portal, the IP address of the terminal can be registered as the current telephone number. In addition, at logout, the user can readily change the current telephone number to his/her mobile phone number. There is a very important point involved with port number. Actually, a port number is required to make a connection as well as IP address. Normally we use well-known port, for example, 81, next to HTTP port of 80. However, in a certain environment well-known port cannot be used. For this situation, we can save the port number as well as the IP address for automatic change. In this case, the address can be like 129.254.34.23:82.

[28] In order to make a call, a user can request the current IP address or a telephone number of the called user to the portal. A user can ask for the type of the telephone number 1 and the current telephone number 2 using a called user's email ID as the key. This query can be sent to the portal through the network and utilize an existing HTTP message format. Even in the case in which the telephone number and the address type of a user change frequently, they are retrieved by use of the email ID of the user. This makes a unified telecommunication interface for a portal.

[29] Figure 4 shows a call request procedure to the other user who belongs to a different portal and teaches how to retrieve a current telephone number of the other user of the different portal. It is assumed that a calling user 14 is a member of a portal, yahoo.com 13, and the other user 15 is a member of the different portal, paran.com 12. The problem is that the user 14 can not retrieve the other user's telephone number from the user's portal 13. In this case, there are two different solutions. One solution is that the user 14 directly asks the other portal 12 for the other user's current telephone number. This is a possible embodiment of the present invention. The other solution is requesting the other user's telephone number to the user's own portal 13. Of course, the key is an email ID of the other user. On receiving the query, the portal 13 requests the other user's telephone number to the other user's portal 12 shown in the email ID of the other user. This two-stage query procedure can degrade the performance, but provides better interface localization and security. After all, each portal can have freedom to provide its own interface. Of course, the protocol between portals should be standardized. The request message can be in the text form of "search current_address for kim@paran.com". Once the other user's telephone number is delivered, the user can make a call to the other user 15. This method has a strong point in that a user can have many telephone numbers and change them whenever necessary.

[30] If the telecommunication service should be paid, billing mechanism is required.

Because telecommunication according to the present invention is carried out based on a portal, the responsibility for billing resides at the portal. Once the fare is known to the portal, it can be charged to a credit card, which is the most widely used electronic payment method. Question is how to know the credit card information of a user. Solution to this question is unexpectedly simple: letting the user register credit card information in the portal in advance. We call this mechanism "credit card embedding". Of course, it is an essential prerequisite that the portal and the user trust each other. There is still a problem related to security. Once a user leaves his/her credit card information at a portal, others may use this information for other purposes. The most important part of the credit card embedding is that nobody can recognize the credit card information of the user registered in the portal. The communication fare can be paid using the embedded credit card, but the credit card information is not retrieved. Thus, if the login procedure to the portal is secured, the embedded credit card cannot be used for other purposes.

[31] At the present time, the portal provides security at the login level by password and free services like an email. For the time being, Internet banking provides a higher level of security using the certificate of authentication. A problem is whether every user requires a high level of security for the Internet banking. It is also expected that the users requiring a higher level of the security want to use existing services using the existing user interfaces.

[32] As a solution to this problem, the present invention proposes two-stage login procedure. The user executes the first login procedure using the existing user interface and uses existing basic services. The user can use paid services after the second login procedure. At the second login, the certificate of authentication can be utilized for better security. Without the certificate of authentication, the basic services are still available after the first login. Thus, we can use the existing interface and extend the services of a portal. Users, without the credit card embedding, cannot proceed to the second login and use paid services. The portal may be an issuer of credit cards and any credit card from other companies can be used for the credit card embedding without any problem. The purpose of the credit card embedding is the prevention of the drain of credit card information by hackers and improved security by the second login for paid services.

[33] Figure 5 shows the call request procedure for a pay call. Figure 4 shows a procedure of requesting a call with a free IP address which does not require billing, but a part through the telephone network requires billing. This billing is achieved with the telephone network. Thus, with the billing capability at the portal, the entire billing procedure is completed.

[34] When the user terminal 16 requesting the other telephone number becomes to know that the other telephone is connected to a toll-based telecommunication network, the user terminal 16 additionally waits for an admission message. Meanwhile, a portal 17 follows the procedures for a pay call. The type of the other telephone is used as an important parameter. Because the portal service of the present invention is assuming an IP network, a free IP is the basic telephone type. When the type of the other telephone is a telephone or a mobile phone, the portal does not only reply with the telephone number, but does an extra procedure. The portal 17 sends a prepare message to an access point 18 to inform the access point that the user terminal will soon request a pay call. The user terminal 16 does not request a pay call service directly to the access point, because the access point does not trust each user terminal. Because the access point 18 receiving the prepare message from the registered portal 17 can ensure payment for the call, the intervention of the portal 17 is justified. For this purpose, the information about the portal 17 should be registered in the access point 18 in advance. The prepare message is in an ASCII text form of "prepare 156.200.20.2 kim@yahoo.com" informing the access point of the IP address of the user terminal 16 and the email ID of the user.

[35] The access point receiving the prepare message maintains the call information keyed by the user terminal address 156.200.20.2 for 30 seconds and informs the portal that it is prepared to accept a call by sending a ready message to the portal. The ready message is in the form of "ready 156.200.20.2 kim@yahoo.com via 129.254.34.2". The portal 17 receiving the ready message approves the call by sending the admission message to the user terminal 16. The admission message is in the form of "admit kim@yahoo.com via 129.254.34.2". The user terminal 16 requests a communication call by sending a call request message. This call request message should arrive at the access point, while the call information is maintained for 30 seconds. Otherwise, the call information at the access point is deleted. Once the access point receives the call request message, it searches the call information maintained in the access point and then initiates a call to the other telephone 6 by making a telephone call. The number of the other telephone is included in the call request message. The call request message is in the form of "invite 042-481-5786 from kim@yahoo.com via 129.254.34.2". When the call establishment is successful, the access point sends an ok message back to the user terminal 3. On receiving the ok message, the user terminal transmits voice packets. The voice packets to the other telephone 6 are sent to the access point 5 first, and then the voice information extracted from the voice packets is sent to the other telephone 6 through the telephone network. The voice information coming from the other telephone 6 to the access point is stored to packets and periodically transmitted to the user terminal 3.

[36] Billing procedure is explained similarly. First of all, a network element initiating billing is an access point. Reaching a charge time, the access point 18 requests payment by sending a charge message to the portal. The charge message is in the form of "charge 200 to kim@yahoo.com for 042-481-5786". The portal 17 receiving the charge message requests confirm by sending the charge message to the user terminal 16. This is to prevent improper payment when the user terminal cannot communicate due to a technical problem. While the user terminal communicates normally, it approves the payment by sending an acknowledgement message to the portal. On receiving this acknowledgement message, the portal charges the fare and sends the acknowledgement message back to the access point informing the call paid and requesting the call to be continued. The access point waits for the acknowledgement message for 30 seconds after sending the charge message. If the acknowledgement message is not received within the time, the call is finished. The time limit of 30 seconds was determined by experiments and can be modified suitable for the environment. By this procedure, the billing is carried out safely by the intervention of the portal.

[37] Figure 6 shows an entire network configuration including a quality guaranteed VoIP network. The service of the present invention operates well in this kind of a network. In this case, the user terminals connected to different access networks can communicate through different routes according to payment policy. An existing IP network 20 is free, but the service quality is not guaranteed. In the future, VoIP will be serviced generally through a quality guaranteed network 22 and a toll-based network. The access router classifies packets into free packets and paid packets, and only the paid packets should be transmitted through the quality guaranteed network 22. Thus, the access router plays the same role in billing as the access point. Only the difference is that an IP address is used instead of a telephone number. For the quality guaranteed service, it is possible to use fair queuing technology like WFQ of IntServ. In this case, the route of the free and paid packets can be the same, but they are serviced by different queuing discipline.

[38] The user terminal according to the present invention is not restricted to, but expected to the use of the Internet messenger for telecommunication. Most portal users are already familiar to the messenger interface, and the program comes with useful features such as chatting and file transfer features. It is possible to easily add a voice communication feature as well. The messenger program has to interact with web browser program so that clicking on a web page gives control to the messenger to initiate the call request procedure to the portal of the present invention. There may be many IPC methods for the interfaction between the web browser and the messenger, and a socket is one of the best known method. The messenger is expected to use the extended HTTP protocol defined here.

[39]

Claims

[1] A call setup method of a portal user, comprising: requesting a called user's current address via a calling user's portal, or directly to a called user's portal; and requesting a call using a replied address by sending a call initiation packet to a called user's terminal or an access point of the replied address. [2] A telephone number resolution server, which includes a database of telephone numbers and portals which the users of the telephone numbers belong to. [3] A portal including a database of portal user s current addresses and forwarding a call initiation message to a current address of a called user specified in the call initiation message when receiving the call initiation message, or replying back with the current address of the called user specified in a call request message when receiving an address request message. [4] A portal server, which retains user's credit card information not shown to anybody and enables payment without showing the credit card information. [5] An access point, which manages call information when receiving a call request from a portal and sends a charge message to the portal of a call when reaching a charge time. [6] A portal server, which sends a charge message to a corresponding terminal to check operation of the terminal when receiving the charge message from an access point.