English:
[0001] The use of the Internet has grown substantially over the last decade, and an important use of the Internet is electronic commerce, or e-commerce for short. One way in which e- commerce is conducted is through the provision of websites with web pages that contain information about products and services being offered for sale by a merchant. Such websites often provide for contact with a human being. For example, some websites allow a customer who may be reluctant to provide a credit card number online the option to purchase products and services via a PSTN (public switched telephone network) phone call to the merchant. Also, whether or not a web page offers the opportunity to make purchases, users of web pages often find themselves in situations in which human assistance is desirable. For example, a user may not be able to locate a desired product or service on a website, or may need information about such a product or service that is not available on the website even if the user has located a product or service on the website. A user may also encounter difficulty in navigating the website or in performing some action such as completing an on-line purchase. There are numerous other reasons why a user of a website may require human assistance. [0002] There are many ways in which human assistance may be rendered to a web page user.
[0003] When a user contacts a call center, it is desirable for the call center to have as much information about the user as possible. For example, when a known user calls a call center, the user's ANI (automatic number identification) or CallerID may be used to provide a "screen pop" of information about the known user on the computer display of the agent to whom the call is directed. This of course requires the call center to have a record of the user's phone number, and further requires the user to be calling from the particular phone line associated with that number. The ability to do a screen pop in the context of a call back is also desirable, and methods for accomplishing this are discussed in U.S. Pat. App. Ser. No. 11/863,175, entitled "Method and Apparatus for Cross Channel Data Processing," the contents of which are hereby incorporated by reference herein.
[0004] It is also often desirable for an agent at a call center to be able to view a web page being viewed by a user when the need or desire for the human contact arose. Even more advantageous is the ability for a call center agent to be able to "push" web pages to the user's computer. This ability is sometimes referred to in the art as "co-browsing." The aforementioned application as well as U.S. Pat. App. Ser. No. 11/737,729, entitled "Method and Apparatus for JavaScript Co-Browsing," the entire contents of which are hereby incorporated by reference herein, disclose systems and methods for enabling co-browsing in the context of a callback.
[0005] The methods for providing context data (including data identifying the user, the user's computer and/or the web page being viewed by the user) discussed above do not work in all scenarios. For example, when a new user simply calls a telephone number associated with the website, or when an existing customer who has not logged on to a website calls from a telephone whose ANI/CallerID is not known to the call center or is blocked, there is no way for the call center to retrieve any context data for display to the agent.
[0007] Fig. 2 is message flow diagram according to an embodiment of the invention.
[0008] Fig. 3 is a message flow diagram according to another embodiment of the invention.
[0009] Fig. 4 is a message flow diagram according to still another embodiment of the invention.
[0010] In the following detailed description, a plurality of specific details, such as types of context information and particular JavaScript commands for implementing various functions, are set forth in order to provide a thorough understanding of the preferred embodiments discussed below. The details discussed in connection with the preferred embodiments should not be understood to limit the present invention. Furthermore, for ease of understanding, certain method steps are delineated as separate steps; however, these steps should not be construed as necessarily distinct nor order dependent in their performance.
[0011] The issues discussed above are addressed through the use of a dynamically allocated pool of PSTN telephone numbers (or dynamically allocated extensions or invite codes in combination with fixed or dynamically allocated phone numbers) that are displayed in web pages shown to the user and that are associated with web session identifiers or URL identifiers through which context information can be made available to agents in a call center. A PSTN phone number (and an extension or invite code in some embodiments) selected from the pool is assigned to a web session (or a particular web page) and is displayed to a user on a web page. When a user dials a telephone number displayed on the web page, the DID (direct inward dial) or DNIS (dialed number information service) (along with an extension or invite code entered by the user in some embodiments) associated with the incoming call is used to retrieve the associated web session or URL identifier. The web session or URL identifier is then used to retrieve context information from the web server such as the web page being viewed by the user or, for session based web pages, any user entered information (e.g., user name, user address, customer identifier associated with the user) or other information (e.g., mouse movements by the user, shopping cart contents, or browse history). The context information may be displayed on the screen of a call center agent's computer. Provisions for a co-browsing session may also be made. The aforementioned techniques can be used by a call center itself and in the context of a third party service provider. In the case of the latter, the dynamically allocated phone numbers may be associated with call center phone numbers or the phone numbers associated with the third party service provider or any other phone numbers.
[0012] In some embodiments, such as in the context of a service provider distinct from a host of a merchant website, a system and method performed by the service provider for providing context data to a call center for a PSTN phone call from a user having a user computer for viewing a website includes the steps of: receiving a request for a PSTN phone number and a web session identifier (the request and the web session identifier may be in the same or different messages); dynamically allocating a phone number from a pool of phone numbers (which may be associated with call center or the service provider or the website host) for the web session (the allocating step may be performed before or after the request and/or the web session identifier is/are received); receiving a request for a web session identifier and an phone number identifier (e.g., a DID or DNIS) of a PSTN telephone number associated with an incoming phone call; correlating the phone number identifier with the web session identifier; and transmitting the web session identifier in response to the request.
[0014] There are several ways in which the phone numbers may be dynamically allocated, and the choice of a particular allocation scheme involves a tradeoff in cost versus specificity. In one embodiment, a phone number is dynamically allocated to a web session and is returned to the pool of unallocated telephone numbers after a predetermined period of time since the end of the web session. In other embodiments, the phone numbers are simply reused in sequence regardless of any time. Those of skill in the art will recognize that there are yet other ways in which the phone numbers may be dynamically allocated.
[0015] Figure 1 illustrates a system 100 according to an embodiment of the present invention. The system 100 includes a merchant web server 110 to which an end user PC 120 equipped with a browser (e.g., Internet Explorer, Firefox, etc.) can connect via Internet 130 in order to locate information. Merchant web server 110 provides one or more web pages including at least one PSTN (public switched telephone network) telephone number that the end user may call to obtain additional information about the products and services described on the website associated with merchant web server 110. The end user may choose to call the phone number provided on merchant web server 110 over the PSTN 160 using end user phone 170 to contact a customer service agent in order to obtain the desired additional information and/or place an order for the products or services. The customer service agent may also have a phone 180 (it should be understood that the call center agent phone 180 can include a sophisticated phone call handling system including automatic call distributors, private branch exchanges, interactive voice response systems, and other devices which are well known in the art and will not be discussed in further detail herein) connectable to the PSTN 160.
[0016] Also connected to the Internet 130 are a call server 141 and a tracking server 142 (it should be understood that these two devices, which may be physical or logical, can be combined into a single integrated server 140 which performs the functions of both as described further herein; and that different allocations of functions between the call server and the tracking server are possible in alternative embodiments). In this embodiment, the tracking server 142 is responsible for maintaining the association between web session or URL identifiers and, in cobrowsing enabled embodiments, maintaining context information that will ultimately be provided to a call center agent's PC, while the call server 140 is primarily responsible for controlling a first VOIP (voice over internet protocol) gateway 150 and a second VOIP gateway 151 (two VOIP gateways are shown in Figure 1, but additional VOIP gateways are present in other embodiments) to connect incoming calls from end users to a call center. The VOIP gateways, which are available from a variety of sources such as CISCOTM, have the ability to convert a call from the PSTN (public switched telephone network) 160 to a VOIP (voice over Internet protocol) phone call. In some embodiments, the second leg of the call from the VOIP gateway to a call center will be made via the PSTN. In other embodiments, the second leg of the call will be made from a VOIP gateway 150, 151 directly to VOIP software application residing on the customer service agent PC 190 (in which case the call server 142 may determine the particular customer service agent PC 190 to which the call is routed, or the call server 142 may be instructed as to which particular customer service agent PC 190 to route the call). In still other embodiments, the second leg of the call will be made from a VOIP gateway 150, 151 to a centralized VOIP infrastructure at the call center, where it may remain in VOIP form when directed to a VOIP software application residing on the customer service agent PC 190 or directed to a VOIP-enabled telephone (not shown in Fig. 1) associated with the customer service agent, or may be converted to a standard telephone format by an internal device (e.g., a VOIP gateway) at the call center.
[0017] In those embodiments in which the call to the call center is to be a PSTN call, the call server 140 controls the VOIP gateways 150, 151 such that when an incoming PSTN call is received via the first VOIP gateway 150, the call server 140 determines the DID (direct inward dialing) number representing the phone number dialed by the calling party (which is dynamically allocated by the call serve 140 as discussed in further detail below), determines a PSTN telephone number of a call center to which the incoming call should be directed, controls the second VOIP gateway 150 to place an outbound PSTN call to the PSTN telephone number determined in the previous step (which may include an ANI or CallerID that can be used by the call center to request context information about the call), and bridges the outbound call to the inbound call by connecting the VOIP input of one gateway to the VOIP output of the other gateway and vice versa as illustrated symbolically in Fig. 1 by the dashed line between gateways 150, 151. Although VOIP gateways 150, 151 are illustrated in the embodiment of Fig. 1, it should be understood that any PSTN call switching equipment that is capable of receiving an incoming PSTN call on one telephone number and redirecting the call to a second PSTN telephone number may be used in place of the VOIP gateways 150, 151 (e.g., a personal branch exchange with remote call forwarding capability), and that the destination could go directly to the desired location skipping remote call forwarding entirely.
[0018] Operation of the system 100 of Fig. 1 in one embodiment will now be discussed with reference to the message flow diagram of Fig. 2 that illustrates the flow of messages and data between various entities in Fig. 1. The embodiment of Fig. 2 is a relatively simpler version of a cross channel technique applicable in the context of a third party service provider that manages the associations of the dynamically allocated PSTN phone numbers with web session IDs and/or web page identifiers such as URLs or IP addresses.
[0019] The process begins when an end user at end user PC 120 clicks on a link or enters a URL associated with web page, either session or non-session based. The browser on the end user PC 120 sends a download request message 202 for the web page to the merchant web server 110. This request message 202 includes a web session ID, a web page from which the user has viewed a phone number to contact the merchant, or other information as discussed above that can be used to provide context information to a call center agent. The merchant sever 110 sends a message 204 requesting a phone number to the tracking server 141. The tracking server 141 dynamically allocates a phone number from among the pool of phone numbers, records the dynamically allocated phone number and the corresponding web session ID or web page identifier (e.g., URL or IP address), and sends a reply message 206 to the web merchant server 110 with the dynamically allocated phone number (as discussed above, this phone number can include an extension to be dialed by the end user).
[0020] The merchant web server 100 inserts the phone number from the message 206 into a web page or other document or file and serves the web page to the end user PC 120 in a message 208. The browser at the end user PC 120 then renders the web page or other document/file to the user. The user then initiates a phone call from his end user phone 170 to the dynamically allocated number. The phone call is received at the call center and is routed to an agent telephone 180. The call center phone system provides the DID (or DNIS and/or extension dialed by the end user) to the customer service agent PC 190 in a message 212. The customer service agent PC 190 then sends a message 214 including the DID (or DNIS and/or extension dialed by the end user) to the tracking server 141 requesting the web session ID or web page identifier. The tracking server 141 responds with a message 216 including the web session ID or web page identifier associated with the previously allocated DID (or DNIS and/or extension dialed by the end user) from the previous message 214. The customer service agent PC 190 then sends a message 218, including the web session ID or the web page identifier, to the merchant web server 110 to request context information. The merchant web server 110 replies with a message 220 that includes the desired context information. The context information can be any of the context information discussed above.
[0021] As previously mentioned, the foregoing embodiment illustrates a third party service provider scenario. Those of skill in the art will recognize that the same techniques may be employed by the web merchant server with minor modification. For example, the merchant web server 110 may perform the functions performed by the tracking server 141, in which case messages 204 and 206 would be eliminated and messages 214 and 216 would be received by and transmitted from the merchant web server 110 rather than the tracking server 141. Furthermore, the process above involves end user calls directly to call center telephone lines, but the end user calls may also be directed initially to third party phone lines as discussed below in connection with Fig. 3. Other variations and functional allocations are also possible.
[0022] Operation of the system 100 according to a second embodiment is illustrated in the message flow diagram 300 of Fig. 3. This embodiment is illustrative of a third party service provider scenario in which the third party service provider provides a cobrowse capability and on which phone calls are received on the third party service provider's phone lines and forwarded to a merchant call center. The cobrowse capability discussed below is of a type employing hidden I-frames as described in co-pending and commonly owned U.S. patent app. no. 11/737,729 entitled "Method and Apparatus for Web Page Co-Browsing." Those of skill in the art will recognize that other techniques for enabling co-browsing or simply passing context information are also available, such as XML HTTP requests (XHR). This method of Fig. 3 will be discussed in the context of a session-based web page but is also applicable to a non-session based or static web page.
[0023] The process begins with a download request message 302 from the end user PC 120 to the merchant web server 110 at the start of a web session. In response to the message 302, the merchant web sever 110 sends a message 304 to tracking server 141 in order to obtain a phone number to be used with the web session. The tracking server 141 responds with a message 306 including the phone number. The merchant web server 110 then sends a message 308 (which may be multiple messages) with the web page, a phone number and a single (preferably JavaScript) command that will initiate a request 309 that will initiate a download 310 of additional JavaScript code from the tracking server 141 to facilitate the collection of web session tracking information as described in the aforementioned U.S. patent application. As the end user's web session continues, one or more tracking messages 311 are sent to the tracking server 141. The tracking server 141 may assign a web session identifier to identify the web session, and this web session identifier may be the same as or different from the web session identifier assigned by the merchant web server 110.
[0024] At a point in which the user desires to place a phone call to the phone number supplied in the message 308 and displayed in the web session, the end user places a phone call 312 from the end user phone 170 to the VOIP gateway 150, 151 (the VOIP gateways 150, 151 are illustrated in Fig. 3 as a single entity but may be logically and/or physically separate devices as discussed above in connection with Fig. 1). The VOIP gateway 150, 151 sends a report 314 with the DID and the ANI (if available and valid) of the end user phone 170 from the phone call 312 to the call server 142.
[0025] The call server 142 then determines the content of the ANI to be signaled for the outbound call 320 to the call center. If the ANI from the incoming call 312 is available and valid, the call server 142 will select that ANI as the ANI to be signaled for the outbound call 320 to the call center. The selection of the inbound call ANI for the outbound call 320 to the call center provides the call center with the ability to retrieve any information associated with the ANI from the inbound call 312 that the call center may have. If the ANI from the inbound call 312 is not available or invalid, the call server 142 selects a different ANI for the outbound call. This different ANI may be the ANI associated with the actual line on which the outbound call to the call center will be placed, or may be a special code that signals to the call center that the ANI associated with the inbound call 312 is unavailable. An example of such a special code is an ANI associated with an invalid phone number (e.g., a phone number in which the exchange digits [digits 4-6 in a 10 digit U.S. telephone number including an area code] are 555). In still other embodiments, the different ANI corresponds to the DID of the incoming call 312.
[0026] Once the ANI has been selected, the call server 142 then sends a message 316 to the tracking server 141 reporting the DID along with the selected ANI for the outgoing phone call to the call center on which the incoming call 312 from the end user will be bridged. The call server 142 then sends a command 318 to the VOIP gateway 150, 151 to place an outbound call with the ANI from message 318 to the call center phone system 180 associated with the merchant. Those of skill in the art will recognize that the outgoing call may be placed on the actual phone line associated with the ANI or that the outgoing call may be placed on a different line with the ANI assigned by the call server "spoofed." The VOIP gateway 150, 151 places the outgoing phone call 320 to the call center phone system 180 and bridges it to the incoming phone call 312 from the end user.
[0027] When the call center phone system 180 receives the call 320, it routes it to a customer agent phone at the call center and sends a message 322 to the customer service agent PC 190 with the ANI of the incoming call. The customer service agent PC 190 then retrieves any available information associated with the ANI and sends a request 324 including the ANI to the tracking server 141. (In some embodiments, the call 320 from the VOIP gateway 150, 151 is made to a special number assigned by the call center to handle only calls from the VOIP gateways 150, 151, which indicates to the call center that context information may be available for the call 320). The tracking server 141 uses the ANI to determine the DID associated with it (as reported in message 316), and in turn uses the DID (which identifies the phone number assigned to the web session) as in index to retrieve the associated web session identifier, uses the web session identifier to retrieve context information and sends one or more messages 326 including context information back to the customer service agent PC 190. Those of skill in the art will recognize that tracking server 141 may have previously associated the ANI with the DID upon receipt of message 316 from the call server 142 such that the ANI may be used to directly determine web session identifier upon receipt of the request 424. This context information can include full co-browse session or any of the other information discussed above.
[0028] Many modifications to the technique discussed above in connection with Fig. 3 are possible. For example, XHRs rather than hidden I-frames could be used to provide for a co- browsing capability. As another example, rather than the request for a phone number being made by the merchant web server 110 to the tracking server 141 in message 304 and the phone number being placed in the web page by the merchant server 110, the tracking code placed into the web page for download to the end user PC 120 by the merchant server 110 causes the end user PC 120 to send a message to the tracking server 141 (or the call server 142) requesting a telephone number (this may be the same message 309 that requests the download of the additional tracking software) and then causes the browser at end user PC 120 to render the telephone number received from the tracking server 141 (or the call server 142) to the user along with the other portions of the web page upon receipt of the phone number from the tracking server 141 (or call server 142)(those of skill in the art will recognize that there are many different ways in which a web page from a merchant server may include a place holder for display of a phone number received from a third party server). Such an embodiment is shown in Fig. 4, which eliminates steps 304 and 306 from Fig. 3, modifies message 309 to further include a request for a phone number along with the request for additional tracking software and modifies the download 310 to include a phone number along with the tracking software (again, the request 309 and download 310 may actually occur in a series of messages; for example, the phone number may be downloaded several times when different web pages are downloaded from the merchant web server 110 and rendered to the user, or the tracking software may make a separate request for the phone number from the tracker server 141 (or call server 142)). In embodiments in which the end user PC 120 requests the phone number from the call server 142, the call server 142 may automatically notify the tracking server of the web session identifier or IP address from which the request was received so that tracking server 141 can maintain the associated between the end user PC 120 and the corresponding DID.
[0029] Still other modifications to the embodiment of Fig. 3 are possible. In some alternative embodiments, the outbound PSTN phone call 320 is replaced by a VOIP phone call. In such embodiments, a single VOIP gateway 150 may be configured to transition the incoming phone call 312 to a VOIP phone call directed toward a VOIP software application on the customer service agent PC 190, or to a central VOIP infrastructure in the call center or to a VOIP-enabled phone associated with the customer service agent. In such embodiments, the DID and ANI associated with the incoming call 312 are included in one or more packets sent from the VOIP gateway 150.

中文:
[0001]在最近十年内,因特网的使用已显著增长,因特网的一个重要应用是电子商务。进行电子商务的一种方式是通过开通具有网页的网站,所述网页包含关于商家为销售而提供的各种产品和服务的信息。这样的网站通常提供与人的联系。例如,一些网站向不愿意在线提供信用卡号的客户提供通过对商家的PSTN(公共交换电话网)电话呼叫来购买产品和服务的选择权。另外,无论网页是否提供购物的机会,网页的用户通常都会发现自己处于期望人工帮助的状态。例如,用户可能不能在网站上找到期望的产品或服务,或者即使用户在网站上找到了产品或服务,不过仍然需要不能在网站上获得的关于所述产品或服务的信息。另外,在浏览网站时,或者在进行某种操作,比如完成在线购物时,用户也可能遇到困难。还有许多网站用户需要人工帮助的其它原因。
[0003]当用户联系呼叫中心时,对呼叫中心来说,理想的是具有尽可能多的用户有关信息。例如,当已知用户呼叫呼叫中心时,用户的ANI(自动号码识别)或者CallerID可被用于在呼叫被导引到的代理的计算机显示器上,提供该已知用户的有关信息的“屏幕弹出”。这当然要求呼叫中心具有用户的电话号码的记录,还要求用户呼叫自与该号码相关的特定电话线路。在回叫情况下进行屏幕弹出的能力也是所希望的,在美国专利申请序列号11/863175,“Method and Apparatus for Cross Channel Data Processing”中讨论了实现这种屏幕弹出的方法,该专利申请的内容在此引为参考。
[0004]另外,对呼叫中心的代理来说,通常理想的是当现出对人工联系的需要或要求时,能够查看用户正在查看的网页。更为有利的是呼叫中心代理能够向用户的计算机“推送”网页的能力。在现有技术中,这种能力有时被称为“协同浏览”。上述申请以及美国专利申请序列号11/737729,“Method and Apparatus for JavaScript Co-Browsing”公开了在回叫情况下,实现协同浏览的系统和方法,这些专利申请的内容在此引为参考。
[0005]上面讨论的提供上下文数据(包括识别用户、用户的计算机和/或用户查看的网页的数据)的方法并不是在所有情形下都起作用。例如,当新用户仅仅呼叫与网站相关的电话号码时,或者当一直未登录过网站的现有客户从其ANI/CallerID不为呼叫中心所知或者被屏蔽的电话机呼叫时,呼叫中心没有办法取回供向代理显示的任何上下文数据。
[0007]图2是按照本发明的一个实施例的消息流程图。
[0008]图3是按照本发明的另一个实施例的消息流程图。
[0009]图4是按照本发明的又一个实施例的消息流程图。
[0010]在下面的详细说明中,陈述了多个具体细节,比如上下文信息的种类,和用于实现各种功能的特定JavaScript命令,以便透彻理解下面讨论的优选实施例。结合优选实施例讨论的细节不应被理解成对本发明的限制。此外,为了易于理解,某些方法步骤被描述成独立的步骤;不过,这些步骤不应被理解成必然截然不同,也不应被理解成其执行与顺序相关。
[0011]通过利用显示在呈现给用户的网页中并且与web会话标识符或URL标识符相关的动态分配的PSTN电话号码池(或者与固定或动态分配的电话号码结合的动态分配的分机或邀请码),解决了上述问题,通过所述web会话标识符或URL标识符,使呼叫中心的代理能够获得上下文信息。从所述池中选择的PSTN电话号码(和在一些实施例中的分机或邀请码)被分配给web会话(或者特定网页),并在网页上显示给用户。当用户拨打显示在网页上的电话号码时,与呼入相关的DID(直接向内拨号)或者DNIS(被拨号码信息服务)(以及在一些实施例中,用户输入的分机或邀请码)被用于取回相关的web会话或URL标识符。web会话或URL标识符随后被用于从web服务器取回上下文信息,比如用户正在查看的网页,或者对基于会话的网页来说,任何用户输入的信息(例如,用户名,用户地址,与用户相关的客户标识符)或者其它信息(例如,用户进行的鼠标移动,购物车内容或者浏览历史)。上下文信息可显示在呼叫中心代理的计算机的屏幕上。也可实现协同浏览会话的提供。上述技术可由呼叫中心本身使用,和在第三方服务提供商的情况下使用。在后一情况下,动态分配的电话号码可以与呼叫中心电话号码或者涉及第三方服务提供者的电话号码或者任何其它电话号码相关。
[0012]在一些实施例中,比如在不同于商家网站的主机的服务提供者的情况下,服务提供者执行的为来自具有查看网站的用户计算机的用户的PSTN电话呼叫,向呼叫中心提供上下文数据的系统和方法包括下述步骤:接收对PSTN电话号码的请求和web会话标识符(所述请求和web会话标识符可以在相同或不同的消息中);为web会话动态分配电话号码池中的电话号码(所述电话号码可以与呼叫中心或者服务提供者或者网站主机相关)(可在收到所述请求和/或web会话标识符之前或之后进行所述分配步骤);接收对web会话标识符的请求和与来电相关的PSTN电话号码的电话号码标识符(例如,DID或DNIS);使电话号码标识符与web会话标识符相互关联;和响应该请求,传送web会话标识符。
[0014]动态分配电话号码的方式有几种,特定分配方式的选择涉及成本与特殊性的折衷。在一个实施例中,电话号码被动态分配给web会话,并在从web会话结束起预定一段时间之后,被返回给未分配电话号码池。在其它实施例中,只是不管任何时间地顺序重复使用电话号码。本领域的技术人员会认识到还存在可动态分配电话号码的其它方式。
[0015]图1图解说明按照本发明的一个实施例的系统100。系统100包括商家web服务器110,配有浏览器(例如,Internet Explorer,Firefox等)的最终用户PC 120能够经因特网130连接到商家web服务器110,以便查找信息。商家web服务器110提供包括至少一个PSTN(公共交换电话网)电话号码的一个或多个网页,最终用户可呼叫所述至少一个PSTN电话号码,以获得在与商家web服务器110相关的网站上描述的产品和服务相关的附加信息。最终用户可选择利用最终用户电话机170,通过PSTN 160呼叫在商家web服务器110提供的电话号码,以联系客服代理,以便获得需要的附加信息,和/或定购产品或服务。客服代理也可具有可连接到PSTN 160的电话机180(应明白呼叫中心代理电话机180可包括复杂的电话呼叫处理系统,所述系统包括自动呼叫分配器,专用小交换机,交互式话音响应系统,和本领域中公知,从而这里不再更详细讨论的其它设备)。
[0016]另外连接到因特网130的是呼叫服务器141和跟踪服务器142(应明白这两个设备(可以是物理的,或者逻辑的)可被结合成单个综合服务器140,所述综合服务器140实现如这里进一步所述的呼叫服务器141和跟踪服务器142两者的功能;并且在备选实施例中,呼叫服务器和跟踪服务器之间的功能的不同分配是可能的)。在这个实施例中,跟踪服务器142负责维持web会话或URL标识符之间的关联,在允许协同浏览的实施例中,负责维持最终将被提供给呼叫中心代理的PC的上下文信息,而呼叫服务器140主要负责控制第一VOIP(网际协议话音)网关150和第二VOIP网关151(图1中表示了两个VOIP网关,不过在其它实施例中存在另外的VOIP网关),以把来自最终用户的来电连接到呼叫中心。可从各种来源,比如CISCOTM获得的VOIP网关具有把来自PSTN(公共交换电话网)的呼叫转换成VOIP(网际协议话音)电话呼叫的能力。在一些实施例中,借助PSTN实现从VOIP网关到呼叫中心的呼叫的第二支路。在其它实施例中,可从VOIP网关150,151直接到驻留在客服代理PC 190上的VOIP应用软件,实现呼叫的第二支路(这种情况下,呼叫服务器142可确定呼叫应被路由到的特定客服代理PC 190,或者可关于哪个特定客服代理PC 190将路由该呼叫,指示呼叫服务器142)。在另一些其它实施例中,将从VOIP网关150,151到在呼叫中心的集中VOIP基础设施进行呼叫的第二支路,在呼叫中心,所述呼叫在被导引到驻留在客服代理PC 190上的VOIP应用软件,或者被导引到与客服代理相关的允许VOIP的电话机(图1中未示出)时,可以保持VOIP形式,或者可被在呼叫中心的内部设备(例如,VOIP网关)转换成标准电话格式。
[0017]在其中对呼叫中心的呼叫是PSTN呼叫的那些实施例中,呼叫服务器140控制VOIP网关150,151,以致当经第一VOIP网关150收到PSTN来电时,呼叫服务器140确定代表呼叫方拨打的电话号码(如下进一步详细所述,该电话号码由呼叫服务器140动态分配)的DID(直接向内拨号)号码,确定来电应被导引到的呼叫中心的PSTN电话号码,控制第二VOIP网关150发出对在前一步骤中确定的PSTN电话号码的PSTN去电(它可包括可被呼叫中心用于请求关于呼叫的上下文信息的ANI或CallerID),并通过如图1中用网关150,151之间的虚线示意所示,把一个网关的VOIP输入连接到另一个网关的VOIP输出(反之亦然),桥接(bridge)去电和来电。虽然在图1的实施例中图解说明了VOIP网关150,151,不过应明白代替VOIP网关150,151,可以使用能够接收对一个电话号码的PSTN来电,并把呼叫重定向到第二个PSTN电话号码的任何PSTN呼叫交换设备(例如,具有远程呼叫转发能力的专用小交换机),并且目的地可完全跳过远程呼叫转发,直接转到期望的位置。
[0018]现在参考图2的消息流程图,讨论一个实施例中的图1的系统100的操作,图2图解说明图1中的各个实体之间的消息和数据的流动。图2是可在管理动态分配的PSTN电话号码与web会话ID和/或网页标识符(比如URL或IP地址)的关联的第三方服务提供者的情况下应用的跨通道技术的较简单形式。
[0019]当在最终用户PC 120的最终用户点击链接或者输入与基于会话的或者不基于会话的网页相关的URL时,开始该处理。最终用户PC120上的浏览器把关于该网页的下载请求消息202发给商家web服务器110。请求消息202包括web会话ID,用户从其看到联系商家的电话号码的网页,或者如上所述的可用于向呼叫中心代理提供上下文信息的其它信息。商家服务器110把请求电话号码的消息204发给跟踪服务器141。跟踪服务器141动态分配电话号码池中的电话号码,记录动态分配的电话号码和对应的web会话ID或网页标识符(例如,URL或IP地址),并把答复消息206连同动态分配的电话号码一起发送给web商家服务器110(如上所述,该电话号码可包括最终用户将拨打的分机)。
[0020]商家web服务器100把出自消息206的电话号码插入网页或者其它文档或文件中,并用消息208把网页提供给最终用户PC 120。在最终用户PC 120的浏览器随后向用户呈现所述网页或其它文档/文件。用户随后发起从他的最终用户电话机170到动态分配的号码的电话呼叫。电话呼叫在呼叫中心被接收,并路由给代理电话机180。呼叫中心电话系统用消息212,把DID(或者DNIS和/或最终用户拨打的分机)提供给客服代理PC 190。客服代理PC 190随后把包括DID(或者DNIS和/或最终用户拨打的分机)的消息214发给请求web会话ID或网页标识符的跟踪服务器141。跟踪服务器141答复以消息216,消息216包括与前一消息214的先前分配的DID(或者DNIS和/或最终用户拨打的分机)相关的web会话ID或网页标识符。客服代理PC 190随后把包括web会话ID或网页标识符的消息218发给商家web服务器110,以请求上下文信息。商家web服务器110答复以包括需要的上下文信息的消息220。上下文信息可以是上面讨论的任意上下文信息。
[0021]如前所述,上述实施例举例说明第三方服务提供商情形。本领域的技术人员会认识到通过进行轻微修改,web商家服务器可以采用相同的技术。例如,商家web服务器110可完成由跟踪服务器141完成的功能,这种情况下,会消除消息204和206,消息214和216会被商家web服务器110接收和传送,而不是被跟踪服务器141接收和传送。此外,上面的处理涉及直接到呼叫中心电话线路的最终用户呼叫,不过,最终用户呼叫也可初始被导引到第三方电话线路,如下关于图3所述。其它变化和功能分配也是可能的。
[0022]在图3的消息流程图300中,图解说明了按照第二实施例的系统100的操作。第二实施例说明其中第三方服务提供者提供协同浏览能力,并且借助该能力在第三方服务提供者的电话线路接收电话呼叫并转发给商家呼叫中心的第三方服务提供者情形。下面讨论的协同浏览能力是如在同时待审和共同拥有的美国专利申请11/737729,“Method and Apparatus for Web Page Co-Browsing”中所述的采用隐藏式I帧的一种协同浏览能力。本领域的技术人员会认识到也可采用能够实现协同浏览或者只是传递上下文信息的其它技术,比如XML HTTP请求(XHR)。将在基于会话的网页的情况下说明图3的这种方法,不过该方法也适用于不基于会话的网页或者静态网页。
[0023]该处理始于web会话开始时,从最终用户PC 120到商家web服务器110的下载请求消息302。响应消息302,商家web服务器110向跟踪服务器141发送消息304,以便获得将与web会话一起使用的电话号码。跟踪服务器141答复以包括该电话号码的消息306。商家web服务器110随后发送带有网页,电话号码和单一(最好是JavaScript)命令的消息308(可以是多个消息),所述单一命令将发起请求309,请求309将启动从跟踪服务器141的附加JavaScript码的下载310,以使web会话跟踪信息的收集更容易,如在上述美国专利申请中所述。当最终用户的web会话继续时,一个或多个跟踪消息311被发送给跟踪服务器141。跟踪服务器141可分配识别web会话的web会话标识符,该web会话标识符可以与商家web服务器110分配的web会话标识符相同或不同。
[0024]在用户期望对在消息308中供给的并在web会话中显示的电话号码发出电话呼叫时,最终用户从最终用户电话机170向VOIP网关150,151发出电话呼叫312(在图3中,VOIP网关150,151被图解表示成单一实体,不过如上关于图1中所示,VOIP网关150,151可以是逻辑和/或物理分离的设备)。VOIP网关150,151把具有来自电话呼叫312的最终用户电话机170的DID和ANI(如果存在并且有效)的报告314发给呼叫服务器142。
[0025]呼叫服务器142随后确定对于给呼叫中心的去电320,将用信号通知的ANI的内容。如果来自来电312的ANI存在并且有效,那么呼叫服务器142将选择所述ANI作为对于给客服中心的去电320,将用信号通知的ANI。为给呼叫中心的去电320选择来电ANI将向呼叫中心提供从呼叫中心可能得到的来电312,取回与ANI相关的任意信息的能力。如果来电312中的ANI不可获得或者无效,那么呼叫服务器142为去电选择不同的ANI。所述不同的ANI可以是与将在其上发出对客服中心的去电的实际线路相关的ANI,或者可以是用信号通知呼叫中心、与来电312相关的ANI不可获得的特殊代码。这种特殊代码的一个例子是与无效电话号码(例如,其中交换机数位[包括区号的10位美国电话号码中的4-6位]为555的电话号码)相关的ANI。在另外一些其它实施例中,所述不同的ANI对应于来电312的DID。
[0026]一旦选择了ANI,呼叫服务器142随后向跟踪服务器141发出消息316,以报告DID以及为来自最终用户的、来电312将被桥接到的对呼叫中心的去电选择的ANI。呼叫服务器142随后向VOIP网关150,151发出命令318,以向与商家相关的呼叫中心电话系统180发出具有来自消息318的ANI的去电。本领域的技术人员会认识到可在与ANI相关的实际电话线路上发出所述去电,或者可在呼叫服务器分配的ANI被冒充的情况下在不同的线路上发出所述去电。VOIP网关150,151发出对呼叫中心电话系统180的去电320,并将其桥接到来自最终用户的来电312。
[0027]当呼叫中心电话系统180收到呼叫320时,它把呼叫320路由到在呼叫中心的客服代理电话机,并向客服代理PC 190发送具有来电的ANI的消息322。客服代理PC 190随后取回与ANI相关的任何可用信息,并向跟踪服务器141发送包括所述ANI的请求324(在一些实施例中,使来自VOIP网关150,151的呼叫320到达呼叫中心分配的只处理来自VOIP网关150,151的呼叫的特殊号码,这向呼叫中心指出上下文信息可供呼叫中心320利用)。跟踪服务器141利用ANI确定与之相关的DID(在消息316中报告的那样),又利用所述DID(它识别分配给web会话的电话号码)作为索引取回相关的web会话标识符,利用所述web会话标识符取回上下文信息,并把包括上下文信息的一个或多个消息326回送给客服代理PC 190。本领域的技术人员会认识到当从呼叫服务器141收到消息316时,跟踪服务器141可能已预先使ANI与DID相联系,以致当收到请求424时,ANI可被用于直接确定web会话标识符。上下文信息可包括完整的协同浏览会话,或者上面讨论的任何其它信息。
[0028]上面结合图3讨论的技术的多种修改都是可能的。例如,可以使用XHR而不是隐藏式I帧来提供协同浏览能力。作为另一个例子,替代在消息304中,商家web服务器110向跟踪服务器141发出电话号码请求并且商家服务器110把电话号码放置在网页中,商家服务器110把跟踪码放置在供下载到最终用户PC 120的网页中可使最终用户PC 120向跟踪服务器141(或者呼叫服务器142)发送请求电话号码的消息(所述消息可以是请求附加跟踪软件的下载的相同消息309),随后当从跟踪服务器141(或呼叫服务器142)收到电话号码时,使最终用户PC 120的浏览器向用户呈现从跟踪服务器141(或呼叫服务器142)接收的电话号码,以及网页的其它部分(本领域的技术人员会认识到,存在多种来自商家服务器的网页可包括供显示从第三方服务器接收的电话号码的占位符的不同方式)。这样的实施例示于图4中,图4消除了图3中的步骤304和306,修改了消息309,以便还包括对电话号码的请求,以及对附加跟踪软件的请求,并且修改了下载310,以包括电话号码,以及跟踪软件(同样地,请求309和下载310实际上可出现在一系列的消息中;例如,当从商家web服务器110下载并向用户呈现不同的网页时,电话号码可能被下载数次,或者跟踪软件可从跟踪服务器141(或者呼叫服务器142)产生对电话号码的独立请求)。在最终用户PC 120向呼叫服务器142请求电话号码的实施例中,呼叫服务器142可自动把从其收到所述请求的web会话标识符或IP地址通知跟踪服务器,以致跟踪服务器141能够维持最终用户PC 120和对应DID之间的关联。
[0029]图3的实施例的更多其它实施例也是可能的。在一些备选实施例中,用VOIP电话呼叫代替PSTN去电呼叫320。在这样的实施例中,单一VOIP网关150可被配置成使来电呼叫312转变成以客服代理PC190上的VOIP软件应用为目标,或者被导引到呼叫中心的中央VOIP基础设施或者被导引到与客服代理相关的允许VOIP的电话机的VOIP电话呼叫。在这样的实施例中,与来电呼叫312相关的DID和ANI被包括在从VOIP网关150发送的一个或多个分组中。