Call connection system

The present invention relates to a call connection system.

A known customer telephone connection system is the click-to-call system, as shown in Figure 1. This system enables a customer 1 and a vendor 6 to speak to each other by telephone, for example to allow the customer 1 to purchase goods from the vendor 6. The telephone connection between the customer and vendor is arranged by an agent 8.

A shown in Figure 1, the customer 1 has a computer 2, which is connected to the internet 10. The customer 1 also has a telephone 3 which is connected to a telephone switch 5. The vendor 6 also has a telephone 7 connected to the telephone switch 5. The agent 8 has a web server 4 connected to the internet 10. The web server 4 is also connected to the telephone switch 5. The web server comprises a database 12, which contains the number of the vendor's telephone 7. The vendor will have previously supplied this information to the agent, for example when registering with the agent for the click-to-call system.

Figure 2 is a flow chart showing the operation of the system. The customer 1, using the computer 2 connected to the internet 10, views a web site provided by the web server 4 of the agent 8, which contains details of the vendor 6. The web site may for example be a directory of vendors maintained by the agent, which the customer is viewing as they wish to purchase a particular product. The web site contains links to web pages 20 (see Figure 3) , which the customer can follow (step 100) if they wish to contact particular vendors. Each web page 20 is for a particular vendor, and comprises an HTML form, with a text input field 21 in which the customer enters the phone number

of their telephone 3, and a submit button 22 labelled "Call me". When the customer clicks on the submit button 22 (step 101) their phone number is sent via the internet 10 to the agent's web server 4 (step 102) . This notifies the web server 4 that the customer wishes to contact the vendor. (The web server will be able to discern which form has been filled in by the customer, and will thus know which vendor the customer wishes to contact.)

The web server 4 then causes the telephone switch 5 to initiate a telephone call between the customer and the vendor. First the telephone switch telephones the telephone 3 of the customer 1 (step 103) . When the customer answers their telephone, the telephone switch 5 then connects the call to the telephone 7 of the vendor 6 (step 104), obtaining their telephone number from the database 12. This causes the vendor' s telephone 7 to ring, and when the vendor answers their telephone 7 the customer 1 is able to speak to them.

In an alternative form of this known system, the link to the form 20 for a particular vendor is provided on a web page on a web server belonging to the vendor (separate from the web server 4 ) .

There are a number of advantages to this system, for example that the agent's web server 4 can withhold the telephone number of the customer from the vendor and/or the telephone number of the vendor from the customer, which may be preferred for security reasons. The agent can also, if they wish, pay for the telephone call instead of the customer 1 and recharge the cost to the vendor 6. However, the present invention improves upon this known system.

The present invention provides a call connection system, computer program product and a method for facilitating a call between a caller and a potential callee as defined in the

appended claims 1, 27 and 28. Preferred features of the invention are defined in the claims dependent thereon.

There will now be described examples of the invention, with reference to the accompanying drawings of which:

Figure 1 is a diagram of a known customer telephone connection system;

Figure 2 is a flow chart showing the operation of the known customer telephone connection system; Figure 3 is a web page from the known customer telephone connection system;

Figure 4 is a diagram of a call connection system according to a preferred example of the present invention;

Figure 5 is a flow chart showing the first stage of operation of the preferred call connection system;

Figure 6 is a web page from the preferred call connection system;

Figure 7 is a pop-up form from the preferred call connection system; Figure 8 is a flow chart showing the second stage of operation of the preferred call connection system.

A preferred example of a call connection system according to the present invention is shown in Figure 4. As in the prior art, the system enables a potential caller, the customer 1, and a callee, the vendor 7, to speak to each other via call networking equipment, in the preferred example a telephone network, with the telephone connection being arranged by an agent 8. A shown in Figure 4, the customer 1 has equipment, namely a computer 2, which is connected to a computer network, the internet 10, and a telephone 3 which is connected to a telephone switch 5. The vendor 6 has a telephone 7 connected to the telephone switch 5, and also has

equipment, namely a computer 9, and a web server 15, both connected to the internet 10. The agent 8 has a call connection controller 4 connected to the internet 10 and to the telephone switch 5. In this preferred example the call connection controller is provided in the form of an application on a web server 4. The agent's web server 4 has an associated database 12, which contains the end-point ID of the vendor's telephone 7 (discussed later); again the vendor will have previously supplied this information to the agent, for example when registering with the agent for use of the system. The web server also has an associated a database 13 which is used to store information supplied by the customer.

Conveniently, the databases 12 and 13 are located on the same computer as web server 4, but, as is well known in the art, may be located on different computer (s) from that of the web server 4.

Figure 5 is a flow chart showing the first stage of the operation of the system. As before, the customer 1, using the computer 2 connected to the internet 10, views a web site; in the present example, however, the web site is provided by the web server 15 of the vendor 7. The web site may for example be a shopping web site provided by the vendor.

<! DOCTYPE HTML PUBLIC "-//W3C//Dtd HTML 4.0 transitional//EN">

<html>

<head>

<title>eComcall Demo</title>

<body>

<hl>eComcall Demo</hl>

<form name=forml action=NormalSubmit .php method=post>

<!-- ecomcall -->

<script type=text/javascript>

<! — e_id ="el000007";

//-->

</script>

<script src="http: //agent/ecomcall. js" type=text/javascript></script>

<! — ecomcall —>

<p>First Name : <INPUT name=FirstNameX/p>

<p>Surname : <INPUT name=Surname></p>

<p>Option 1 : <INPUT type=checkbox name=optionl></p>

</tbody>

</table>

</form>

</body>

</html>

Table 1

As before, the web site page from web server 15 being viewed contains a link to a web page 60 (see Figure 6) that the customer can use if they wish to contact the vendor. The web page 60 comprises an HTML form with text input fields "First Name" 62 and "Surname" 63, a tick box input field "Option 1" 64, and a "call" button 61. The HTML source of the web page is shown in Table 1, in which the form is given by the section of the code:

<form name=forml action=NormalSubmit . php method=post>

</form>

The form is named "forml" (given by the "name" attribute) and is set to call the page NormalSubmit .php (given by the "action" attribute) with the "post" method (given by the "method" attribute, which selects the way in which the data entered into the form is submitted to the called web page) . The input fields 62, 63 and 64 are provided by the three <INPUT> tags:

<INPUT name=FirstName> <INPUT name=Surname>

<INPUT type=checkbox name=optionl>

in the form (which are towards the end of Table 1) .

The form also contains two pieces of JavaScript, given by the <script> tags, both of which are executed by the customer's computer 2.

The first JavaScript consists simply of the instruction

"e_id = "el000007";", and assigns the variable e_id the value el000007. This value is provided by the agent 8 for the vendor 7, and is used by the web server 4 as an identifier for the vendor, or possibly as an identifier for a particular area of the web site provided by the vendor.

function popSubmit (form)

{ var popName = "formPopUp"; var popStyle =

"width=305, height=160, location=no, resizable=no, scrollbars=no, toolbar=no" ; form. action = "ecomcall .php" ; form. target = popName; window. open ( "eComcall Number" , popName, popStyle) ;

}

document .write ( ' <input type="iraage" src="click. jpg" name="ecoracall" onclick="popSubmit (this, form) ;">' ) ; document . write ( ' <input type="hidden" name=" spin" value= ' +e_id+ ' > ' ) ;

Table 2

The second piece of JavaScript is simply a reference to a JavaScript file ecomcall.js (the code ^λλ <script src="http: //agent/ecomcall . j s" ...") stored on the web server 4. The JavaScript file ecomcall.js is shown in Table 2. The JavaScript defines a function "popSubmit", the behaviour of which is described in more detail below. It also contains two document . write instructions, which when executed by the customer' s computer 2 add additional HTML code to the form (forml), which code is then displayed as part of the web page 60. Having the JavaScript file on the web server of the agent 8 allows the agent to make changes easily to the code without the vendor having to update their web site which holds the web page 60. ^' It would, however, be possible to have the code defined in the JavaScript file incorporated directly into the web page 60 instead.

The first document .write instruction is as follows:

document .write (' <input type="image" src="click. jpg" name="ecomcall" onclick="popSubmit (this . form) / "> ' ) ;

This adds an image field named "ecomcall", with the image being provided by the graphics file click.jpg. This provides the call button 61 displayed in the form. The image button 61 also has an associated "onclick" instruction, which calls the function popSubmit when the image is clicked by the user of the webpage .

The second document .write instruction is as follows:

document .write (' <input type="hidden" name="spin" value='+e_id+ ^r >' ) ;

This adds a hidden input field named "spin" to the form, which is assigned the value of e__id (as defined in the HTML for the form in Table 1) . The hidden input field is not visible to a user of the web page (it is not displayed by their internet browser) , but the value stored in the field is submitted with the other input data when the form is submitted.

When the customer fills their details into input boxes 62, 63 and 64 of the form and presses the button 61 (step 200 of Figure 5) , the onclick instruction calls the JavaScript function popSubmit, passing it the value this. form for its sole parameter, which is a reference to the form (forml) itself. Note that the HTML code for the web page does not include a submit button, and so this is the only way in which the customer can submit their details. The function popSubmit is defined as follows (extract from Table 2) :

function popSubmit (form)

{ var popName = "formPopUp"; var popStyle =

"width=305, height=160, location=no, resizable=no, scrollbars=no, toolbar=no"; form. action = "ecomcall .php" ; form. target = popName; window. open ("eComcall Number" , popName, popStyle) ;

}

The function assigns values to variables popName and popStyle, and then forces the form to call the web page

ecomcall .php (the page to call is set by the form. action instruction) . The page ecomcall. php is a PHP script, again stored on the web server 4 of the agent 8 (as opposed to being on the web server 15 of the customer 7) . The PHP script is interpreted by the web server 4, which executes the instructions therein and dynamically creates a web page to return to the customer's computer 2. The details entered by the customer into the form are thus sent via the internet 10 to the web server 4 belonging to the agent (step 201) , which server compiles the response. The entered details are stored in database 13 for the purpose of being viewed by the vendor when the customer calls them, as is done in the preferred form of the invention.

The option 1 button of the form 60 is a simple example of a control the customer can use to provide information that will be displayed to the vendor. Further controls can be provided allowing the customer to enter multiple items . The data might include for example the name of the product they are interested in buying, its intended use, and so on. Before the user requested form 60, they were of course in the example described viewing web pages from the vendor' s web server 15. In one example of the invention, information regarding the state of that interaction (e.g. the ID of the product being viewed on the vendor's web site) is passed to web server 4 in the request for form 60 made when the customer clicks the link on the relevant vendor's web page. This information is stored in database 13 (for display to the vendor) additionally or instead of the information volunteered by the customer on form 60. For transparency, the data obtained in the request for form 60 can be used to pre-populate controls such as the "option 1" button 64 so that they are visible to the customer on form 60.

Note that the form. action instruction overrides the action attribute given in the HTML code for the form, which

was set to call the page NormalSubmit .php, which would necessarily have to be present on the vendor's web server 15. (A pure HTML form is only able to submit details to the same server that provided the form itself.) By overriding the behaviour of the form in this way the JavaScript is able to send the customer' s information to the web server 4 belonging to the agent instead of the web server 15 belonging to the vendor.

(In the present example the page NormalSubmit .php does not exist, but a submit button could also be provided in the form to allow a customer to submit their details to the vendor in the normal way, if for example they wished to contact the vendor but did not wish to engage in a telephone conversation at that exact moment. The client would then use the information submitted in some way outside the present invention. )

The telephone switch 5 will have a range of telephone numbers associated with it, in the sense that when one those numbers is dialled the call is directed to that telephone switch. The telephone switch then routes the call to its destination, which is known as the "end point". As noted above, when the web server 4 has received the customer's details over the internet (following the clicking of the "call" button 60), it executes the PHP script ecomcall .php. First the PHP script loads a library of code that allows it to communicate with the telephone switch 5, and creates a connection to the database 13. It then assigns one of the numbers associated with the telephone switch to the customer's details (step 202), storing both in the database 13 as explained below. This number is known herein as the "connection number", or more generally "callee address". Many different methods for assigning connection numbers may be used, as described in more detail below.

(In a preferred example the PHP script will be arranged to perform a "flood control" check before assigning a connection number. A flood control check is a check to see if for example the button has been clicked multiple times or the page is being called repeatedly by some automated process. Such a check is usually done using the time of, for example, that the page is called and the IP address from which the call comes, and prevents the system being abused.) Once the connection number has been assigned, the PHP script on the web server 4 instructs the telephone switch 5 to set the end point for the connection number to be the telephone number of the vendor (step 205) . The PHP script is able to identify which vendor by looking up the hidden input box "spin" submitted by the form, which contains the identifier for the vendor, in this case "elOOOOO7" (as given by the variable e_id in the HTML code for the form) , and uses this to find the vendor' s telephone number in the database 12 on the web server 4.

It is not essential for there to be a dynamic allocation of the end point to the telephone number (or callee address); these can be in a fixed permanent relationship. The dynamic allocation allows the agent to have a set of possible numbers which can be allocated to different ones of the vendors to which they provide the service. This can make number allocation more efficient, reducing the size of the set required by the agent.

Next the PHP script creates an XML document from the customer' s information submitted by the form, and stores this in the database 13 on the web server 4 (step 203) . The XML document is indexed using the connection number.

Finally, the PHP script creates a web page 70, called "formPopUp", to be returned to the customer. This web page, as shown in Figure I ₁ asks the customer to ring the connection number. The page is passed back to the customer's

computer 2, and is displayed in a pop-up window (step 204) . This is achieved by the remaining code in the JavaScript function popSubmit of ecomcall.js (Table 2), which is as follows :

form. target = popName; window. open ("eComcall Number",popName,popStyle) ;

The instruction form. target sets the form target to the page "formPopUp", and then the instruction window. open opens that page on the customer's computer 2.

The first stage of the use of the system has now been described. Figure 8 is a flow chart showing the second stage of the use of the system. The second stage is initiated when the customer calls the connection number (step 300) , which need not be immediately after the page "formPopUp" is displayed. As the connection number is in the range of numbers associated to the telephone switch 5, the telephone network directs the call to the telephone switch 5. The call is therefore received by the telephone switch 5 (step 301). (In this example, the customer's telephone 3 is connected to the public switch telephone network (PSTN) which directs the call to the telephone switch 5. )

As the end-point for that number is set to that of the vendor's telephone (step 204 of Figure 5), the switch routes • the call from the customer to the vendor's telephone 6 (step 302) . This causes the vendor's telephone to ring, and when they answer the vendor and customer are connected.

As well as routing the customer's call, the telephone switch notifies the web server 4 that the call has been received (step 303). The web server then retrieves (step 304) the XML document containing the customer's details using the connection number, which details were stored in the database 13 on the web server (step 203 of Figure 5) . The

web server then sends those details via the internet 10 to the vendor's computer 9 (step 304), where they are displayed to the vendor. In this way, the vendor is able to see the customer's details when speaking to the customer. Note that the storing of information about the customer or their request for form 60 and passing it to the vendor are not essential to the process of allocating a telephone number for the customer to contact the vendor, but of course passing such information to the vendor greatly facilitates the conversation between the vendor and the customer.

In an alternative arrangement, when the vendor 6 receives the call from the customer 1, they send a request using their computer 9 to the web server 4 of the agent 8 for the information submitted by the customer. The vendor requests the information using the connection number used by the customer, and the agent is able to use this to retrieve the details of the customer from the database 13. The connection number may be preset in a program on the computer 9, or keyed in by the vendor 6. In another arrangement, the vendor's telephone 7 is part of the vendor's computer 9, and the computer 9 automatically requests the customer' s details on receipt of the call. (The vendor could also use the customer's telephone number to request the information, but that number will not always be available to the vendor, for example if the customer has withheld their number.)

The vendor 7 may have a number of operators, each with their own telephone 6 and computer 7. In that case each operator's telephone has, in one arrangement, a separate telephone end-point number, and the telephone switch 5 will direct the customer' s call to the telephone having that end- point number in accordance with the association to the connection number stored in database 13, and the web server 4 will either direct the customer' s information to the operator's computer associated with that telephone, or the

operator can request the information from the web server 4 as described above.

Alternatively the vendor may have telephone equipment (e.g. a PABX) that receives all the vendor's calls and allocates calls to operators dynamically. In that case the web server 4 will direct the customer' s information associated with a call to a central computer 11 belonging to the vendor, which then sends that information to the relevant operator based on the connection number used by the customer and information from the vendor's telephone equipment, or alternatively the operator will request the information from the web server 4. '

In another alternative, the operator would be sent all customer information stored on the database 13 that is related to the vendor, and would be able to identify the particular customer' s information by asking them for particular details during the telephone conversation.

According to a further feature of the preferred example of the invention, the system allows the vendor to see the same view as presented to the customer on their computer 2. That view may be the form 60 on which the customer is invited to provide various details (as minimally illustrated by the optionl box 64), but could also be the view generated for example by a web application running on the vendor's server, or by an application program running on the customer' s computer. This helps the vendor be of more assistance to the customer when they call.

Taking form 60 as an example, when the customer calls the vendor, the vendor' s computer receives the information given by the user on form 60, and that information is displayed on the vendor' s computer 9 using a similarly presented form. Further, when the call button 61 is clicked details identifying the customer's computer 2 (e.g. IP address) are also submitted to the web server 4. That

information is passed to the vendor' s computer, which is arranged to use that information to allow the vendor to change information in their version of the form, and to transmit those changes dynamically to the customer' s version of the form, for example by using Asynchronous JavaScript and XML (AJAX) technology.

In the case of a web application running on the vendor's server 15, the information identifying the customer's computer is used to identify the customer' s session for that application on the web server. The state information in that session is then used to recreate on the vendor' s computer 9 the web forms seen by the customer. For example on a shopping website the vendor could identify which items the customer had placed in their electronic "shopping basket". In the case of an application program running on the customer's computer 2 (for example one sold to them or supported by the vendor) , the form 60 is preferably incorporated into the interface of that program. Clicking the button 61 submits similar information to the web server as in the previous examples. However, protocols other than web protocols may be more appropriate for the data transfer. The form might for example be accessible from the "help" menu of an application developed by the vendor. The customer could for example use the form to contact the vendor if they have a problem with the use the application. The application could also send other details of its state and/or configuration to the vendor to help them identify any problems the customer might be having. Similarly to the previous examples, the vendor's computer could have an application which when it receives that information generates similar views to that seen by the customer. Also, if the data sent to the server 4 includes information identifying the customer' s computer 2 the application program on the customer's computer 2 and the program in the vendor's

computer are arranged to set up data transfers between them so that the similarity between the vies shown to the customer and vendor is maintained.

As mentioned above, many different connection number allocation methods can be used for the invention. An example method is to have a pool of unused numbers, and to allocate a new number from the pool each time a customer clicks the "call" button 60. The connection number would then be returned to the pool after the customer and vendor had completed their telephone conversation. A time limit is preferably set for the customer to dial the connection number (say one hour) , after which the connection number would be returned to the pool and the customer's details removed from the database 13. Otherwise numbers that customers choose not to dial are lost from use.

In a second method, the customer' s details are stored indefinitely on the server 4, and the vendor is sent, when a call is made to a particular connection number, all details related to the connection number. As the connection numbers remain in the pool there could potentially be more than one set of details related any one connection number. When a call is made, the vendor is presented at their computer 9 with a list of all the sets of customer details associated with the connection number, and the vendor can identify the particular customer's information by asking them for particular details during the telephone conversation. (Preferably if the same telephone number is allocated to two or more customers then they are ones who wish to speak with the same vendor, for reasons of privacy and so that the vendor is not confused by being presented with details of a customer of another vendor.) The set of details for a customer is preferably deleted at a certain time after they were created and/or the vendor selects them from the list

(for which relevant feedback is provided by the vendor's computer to the web server 4) .

In the preferred example of the invention, the vendor' s web application is located on a different server from the agent's web server that controls the customer call connection. In an alternative arrangement both those functions are provided on a single server, which may be located either for example at the agent's or the vendor's premises . In particular, the web page 60 containing the form that the customer fills in could be provided by the web server 4 of the agent 8. Once the form has been filled in and the customer clicks the "call" button 61, the details are simply submitted to the web server 4; as the customer's details do not need to be submitted to a different web server from that which supplied the original web page, a normal HTML submit button can be used in the form. In another example of the invention the vendor provides the telephone switch 5 and the web server 4 that stores the customer' s details - essentially, the vendor 6 is also the agent 8.

As well as using a hard-wired telephone system, the invention could instead use a "Voice Over IP" (VOIP) telephone system. The customer's and vendor's telephones could be provided by their computers (as softphones) or as standalone VOIP telephones. Also the PSTN telephone switch 5 could be replaced by an equivalent for internet telephony. Further, the telephone part of the invention could be replaced by an Instant Messaging (IM) system. In all those cases the web page on which the customer requests a connection number could be arranged to automatically copy the telephone number or instant messaging address to the telephone or instant messaging client, preferably leaving the customer to initiate the telephone conversation (or instant

messaging link) , but alternatively the call could be initiated automatically.

In the foregoing the user' s who are to be connected by telephone have been termed "vendor" and "customer". The invention is of course not limited to that particular business relationship, but will support any other relationship having similar technical requirements.