JP4922660B2 - Voice communication method and voice communication program - Google Patents

Description

  The present invention relates to a communication method and a communication program for performing communication between terminal devices logged in to a network using a user ID uniquely determined for each user.

  In recent years, so-called P2P (Peer to Peer) telephones that perform voice communication between terminal devices logged in to a network using a user ID uniquely determined for each user have become widespread. Specifically, for example, Skype of Skype Technology Inc. can be cited.

  In addition, there is a call center as one business type using a telephone, and ACD (Automatic Call Distribution) is a function used in the call center. This is an operation for appropriately allocating a call received to a representative number to an operator who has a free hand.

  Further, in Patent Document 1, when a customer browses WEB, a browsing history is saved, and when a customer presses an inquiry button, contents displayed on an operator terminal are analyzed according to the browsing history of the customer. Then, an available number is selected from pre-registered contact telephone numbers, and the corresponding telephone number is displayed on the customer screen in association with the operator display contents. When a customer makes a call to the telephone number displayed on the customer screen, PBX (Private Branch Exchange) selects a vacant operator from a group of persons in charge who can process the corresponding telephone number and relays it. At that time, it is described that display contents are displayed on the operator terminal when the customer screen is created.

JP 2003-298724 A

  However, the P2P phone according to the above prior art is usually designed to communicate one-to-one or one-to-many, and does not have a function for distributing incoming calls using a representative number. ACD could not be realized. Therefore, there is a problem that the P2P telephone cannot be used at the call center.

  Further, in the above-mentioned Patent Document 1, it is assumed that the PBX is used in order to control which operator will respond to the incoming telephone number. For this reason, there is a problem in that the above system cannot be used in a P2P phone that does not have a PBX and cannot intervene between outgoing calls and incoming calls.

  In Patent Document 1, depending on the inquiry status to the call center, all operators may be responding. In such a case, in the system described above, the customer makes a call, but waits until the operator becomes available. That is, there is a problem that the expected waiting time or the like cannot be displayed on the displayed WEB screen or the user cannot be guided to the mail.

  Moreover, in the said patent document 1, the customer needs to input the telephone number displayed on the screen by hand. There is a problem that inputting a telephone number is time consuming and may cause an input error and the load on the customer cannot be reduced.

  The present invention realizes ACD in communication performed between terminal devices logged in to a network using a user ID uniquely determined for each user in order to solve the above-described problems caused by the prior art. An object of the present invention is to provide a communication method and a communication program capable of performing the above.

  In order to solve the above-described problems and achieve the object, a communication method according to the present invention performs communication between terminal devices logged in to a network using a user ID uniquely determined for each user. In the communication method, each terminal device in a predetermined terminal device group logs in to the network with its own user ID, and at least information on the connection availability status with respect to a server connected to the terminal device. And the server determines one of the terminal devices in the terminal device group based on the information on the connection availability status in response to a call request from the caller terminal device, and the determined terminal Instructing the source terminal device to automatically make a call to the user ID of the device.

  The communication method according to the present invention is characterized in that the communication is voice communication.

  The communication method according to the present invention is characterized in that the communication is text communication.

  Further, in the communication method according to the present invention, when there is no connectable terminal device in response to a transmission request from the transmission source terminal device, the server notifies the transmission source terminal device to that effect. When information about the source terminal device (hereinafter referred to as “customer information”) is registered and a connectable terminal device exists, the information is selected based on the customer information of the source terminal device. It is characterized by instructing the transmitted source terminal device to automatically make a call to the user ID of the terminal device.

  In the communication method according to the present invention, the call request includes information related to a desired connection destination (hereinafter referred to as “connection destination information”), and the server registers information related to the terminal device registered in advance ( (Hereinafter referred to as “operator information”) and the connection destination information, and any one of the terminal devices is determined.

  Further, the communication method according to the present invention is characterized in that the connection destination information and the operator information include information relating to a compatible language.

  Further, in the communication method according to the present invention, the server stores information related to a call request from the caller terminal device in association with a user ID of the determined terminal device, and the caller terminal device stores the information Based on an instruction from the server, automatic transmission is made to the determined user ID of the terminal device.

  Further, in the communication method according to the present invention, when the determined terminal device has made a call from the caller terminal device, information on the call request is sent to the server based on its user ID. It is characterized by making a search request.

  In the communication method according to the present invention, the server stores and stores a unique management ID in association with information related to a transmission request from the transmission source terminal device, and the management ID is stored in the transmission source terminal device. Transmitting the management ID received from the server when the transmission source terminal device automatically makes a call to the user ID of the determined terminal device based on an instruction from the server. Features.

  In the communication method according to the present invention, the determined terminal device searches the server for information on the call request based on the management ID when the call is transmitted from the caller terminal device. It is characterized by requiring.

  In the communication method according to the present invention, the server stores the user ID of the source terminal device in association with information related to the transmission request from the source terminal device, and the source terminal device When the automatic transmission is made to the user ID of the terminal device determined based on the instruction from the server, the user ID is transmitted.

  Further, in the communication method according to the present invention, when the determined terminal device makes a call from the caller terminal device, the information on the call request is transmitted based on a user ID of the caller terminal device. It is characterized by making a search request to the server.

  In the communication method according to the present invention, the server receives a predetermined ID transmitted from the source terminal device together with a transmission request from the source terminal device, and transmits from the source terminal device. The information relating to the request is stored in association with the predetermined ID, and when the transmission source terminal device automatically transmits to the user ID of the determined terminal device based on an instruction from the server The predetermined ID is transmitted.

  Further, in the communication method according to the present invention, when the determined terminal device makes a call from the caller terminal device, information on the call request is sent to the server based on the predetermined ID. It is characterized by making a search request.

  A communication program according to the present invention causes the terminal device to execute the communication method described above.

  According to the present invention, when communication is performed between terminal devices logged in to a network using a user ID uniquely determined for each user, for a terminal device group including a plurality of terminal devices, There is an effect that a communication method and a communication program capable of reliably and efficiently realizing the ACD function using the server are obtained.

  Exemplary embodiments of a communication method and a communication program according to the present invention will be explained below in detail with reference to the accompanying drawings.

(System configuration)
First, an overall configuration of a communication system for realizing a communication method according to an embodiment of the present invention will be described. FIG. 1 is an explanatory diagram showing a system configuration for realizing a communication method according to an embodiment of the present invention.

  In FIG. 1, in the communication system, 100 is a network, 101 is a calling user, 102 is a calling PC (personal computer) used by the calling user 101, and 103 is P2P telephone software installed in the calling PC 102. WWW browser software (ware) 104 transmits a request to a WWW server, which will be described later, and processes the returned content.

  Here, the communication system is a communication system performed between terminal devices logged in to the network using a user ID uniquely determined for each user. Specifically, for example, specifically, for example, As an example, there is a so-called P2P (Peer to Peer) telephone that performs voice communication such as Skype of Skype Technology Inc. (however, this embodiment is not limited to the one using Skype). .

  In addition, Skype includes not only voice communication but also character communication (for example, so-called so-called character communication) between terminal devices logged into the network using a user ID uniquely determined for each user. Chat etc.). Therefore, the communication system may be not only voice communication but also P2P character communication using Skype.

  Reference numeral 105 (105a, 105b, 105c) denotes an operator, and reference numeral 106 (106a, 106b, 106c) denotes an operator PC (personal computer) used by the operator 105. The same number as the number of operators 105 exists. Reference numeral 107 (107a, 107b, 107c) is operator software (ware) installed in the operator PC. The operator software 107 includes P2P telephone software (not shown) used by the operator 105 and monitor software (not shown) that monitors the P2P telephone software and notifies the ACD server of the status.

Reference numeral 108 denotes an ACD server machine on which the ACD server operates, reference numeral 109 denotes WWW server software (ware) that returns content in response to a request from a WWW browser, and reference numeral 110 denotes a WWW server that determines an arbitrary operator. ACD software (ware) that runs above. Hereinafter, for convenience of explanation, the WWW server software 109 and the ACD software 110 will be described together as ACD server software (ware).

  A customer DB 111 stores customer attribute information (final service operator ID, dedicated operator ID, priority, etc.). The customer DB 111 can be searched using the customer user ID and dedicated key information. . Further, usable language information for realizing a multilingual call center, which will be described later, may also be stored.

  An operator DB 112 stores operator attribute information (presence, operating rate, skill, etc.). Here, presence refers to “call (communication) possible, busy, taking in, away from seat, down”, etc., in the call state of the operator. Furthermore, usable language information for each operator for realizing a multilingual call center described later is also stored. Details of the usable language information will be described later.

  Reference numeral 113 denotes a waiting user list waiting for an operator to become available. Here, the user ID of the customer in the waiting state, the date and time when the waiting state is reached, the date and time when the waiting state is resolved (or the duration of the waiting state), and the like are stored.

  It should be noted that the storage locations of the databases (customer DB 111, operator DB 112, waiting user list 113) may be stored separately on a plurality of machines as long as they can be accessed from the ACD server.

(Processing procedure)
Next, a processing procedure of the communication method according to the embodiment of the present invention will be described. FIG. 2 is a flowchart showing the processing procedure of the WWW server in the communication method according to the embodiment of the present invention. FIGS. 3 to 5, FIGS. 7 to 13, FIG. 15 and FIG. FIG. 6 and FIG. 14 are diagrams illustrating an example of a screen image of a calling PC. “Browser” is WWW browser software 104 and “P2P” is P2P telephone software 103, respectively. “Operator” indicates the operator software 107, and “ACD server” indicates the WWW server software 109 and the ACD software 110, respectively.

  First, as shown in FIG. 3 (login), the calling user 101 logs in to the P2P telephone software 103 with the user ID of the calling user 101. Each operator 105 (105a, 105b, 105c) logs in to the operator software 107 with the user ID of the operator 105. “User0” is used as the user ID of the calling user 101, and “operator1, operator2, operator3,...” Are used as the user ID of the operator 105 (hereinafter, each processing flow (FIGS. 4 to 5, FIG. 7 to FIG. 13). The same applies to FIGS. 15 and 16).

  As shown in FIG. 4 (presence information update), each operator software 107 transmits presence information to the ACD server. The ACD server updates the presence information, the operation rate, etc. of the operator DB 112 based on the presence information transmitted from each operator software 107. Thereafter, when the presence is changed, the operator software 107 transmits the information to the ACD server as needed. In response to this, the ACD server updates the operator DB 112.

  In the flowchart of FIG. 2, first, the ACD server determines whether or not a request from the calling user 101 has been received (step S201). As shown in FIG. 5 (a request is transmitted from the WWW browser to the ACD server), the calling user 101 designates a specific URI using the WWW browser software 104 and transmits the request to the ACD server. At that time, information on the calling user 101 (user ID, key information of the customer DB 111, etc.) and information on requirements can be added to the parameters. However, it is not necessary to add such information.

  FIG. 6 shows a screen image of the calling PC. In the PC screen 600 of FIG. 6, 601 is an example of a display screen (window) of the WWW browser software 104, and 602 is an example of a display screen (window) of the P2P telephone software 103. On the display screen 601 of the WWW browser software 104, by clicking the “Call Me!” Part (button), a specific URI can be specified and a request can be transmitted to the ACD server.

In step S201, the ACD server waits to receive a request from the user who makes the call, and when receiving the request (step S201: Yes), next, determines whether there is an empty operator (step S201). S202). Here, when there is a vacant operator (step S202: Yes), the process proceeds to step S207, an arbitrary operator is determined from the vacant operators (step S207), and the process proceeds to step S208.

As shown in FIG. 7 (determined operator), ACD server, based on the attribute information and customer information of the operator 105, to determine any operator. The attribute information of the operator 105 is acquired from the operator DB 112, for example. Further, customer information is retrieved and acquired from the customer DB 111 using a user ID, for example. It can be added to the parameter when the calling user 101 sends a request to the ACD server . When information regarding the calling user 101 (user ID, key information of the customer DB 111, etc.) or information regarding requirements is not added, the customer information is not used for determination.

  If there is no vacant operator in step S202 (step S202: No), the process proceeds to step S203, and the ACD server, as shown in FIG. 8 (added to the waiting user list), shows customer information (user information and customer DB 111). Are registered in the waiting user list 113 (step S203).

  Thereafter, as shown in FIG. 9 (waiting message), the ACD server returns a message such as “Please wait for a while” to the WWW browser software 104 (step S204). In that case, the WWW browser software 104 displays the message. At this time, the ACD server may calculate the waiting time based on the contents of the waiting user list 113 or the information in the operator DB 112 and include the waiting time in the message. After displaying the message, the WWW browser software 104 transmits a request to the ACD server software again, and the ACD server software receives it.

  Next, the ACD server determines whether or not there is a vacancy in the operator (step S205). Here, after waiting for the operator to make a vacancy, if the vacancy is made (step S205: Yes), the process proceeds to step S206.

The ACD server, for example, in the waiting user list 113 based on the contents of the waiting user list 113, the customer information of the waiting user acquired from the customer DB 111, and the attribute information of the callable (communication) operator acquired from the operator DB 112. An arbitrary user is selected (determined) from (step S206), and then the process proceeds to step S208. It can be added to the parameter when the calling user 101 sends a request to the ACD server . When information regarding the calling user 101 (user ID, key information of the customer DB 111, etc.) or information regarding requirements is not added, the customer information is not used for determination.

In step S202, when there is a vacant operator (step S202: Yes), the ACD server determines an arbitrary operator (step S207), and then proceeds to step S208. The determination of any operator, specifically, for example, as shown in FIG. 10 (operator call (communication) possible), first, when the operator 105 becomes a call (communication) ready, the operator software 107 ACD Tell the server to that effect. The ACD server updates the presence information, the operation rate, etc. of the operator DB 112.

In step S208, the ACD server instructs the WWW browser software 104 of the calling user 101 to redirect as shown in FIG. 11 (step S208). For the redirect, for example, an HTTP status code can be used, and a method using a meta tag, Java (registered trademark) Script, or the like may be used. At this time, the redirect destination URI has the address scheme of P2P telephone software, and the host name, path, and the like are the user ID of the operator 105 determined as an arbitrary operator. Specifically, for example, in the case of a telephone call, “callto: // operator3” may be used. If the user wishes to make an inquiry via chat, the redirect destination URI may be the one corresponding to the chat software for the P2P phone.

  Next, as shown in FIG. 12 (linked to P2P telephone software), the WWW browser software 104 passes the URI to the P2P telephone software 103 in accordance with the URI address scheme given from the ACD server. Then, as shown in FIG. 13 (calling to the operator), the P2P telephone software 103 makes a call to an operator ID (“operator 3”) designated based on the given URI. FIG. 14 shows a screen image of the calling PC. In the PC screen 600 of FIG. 14, the display screen 602 of the P2P telephone software 103 is displayed in front of the display screen 601 of the WWW browser software 104 to notify the calling user 101 that a call is being made to the operator 3.

  Thereafter, in step S209, it is determined whether the user ID (“user0”) of the calling user 101 and the user ID (“operator3”) of the operator 105 are received from the operator software 107 (step S209). Here, after waiting for reception (step S209: Yes), the presence information, the operation rate, etc. of the operator DB 112 are updated (step S210), and predetermined information is transmitted to the operator software 107 ( Step S211) and return to Step S201.

  Specifically, as shown in FIG. 15 (information acquisition), the operator software 106 passes the user ID of the calling user 101 who received the call and the user ID of the operator 105 to the ACD server. The ACD server updates the presence information, operation rate, etc. of the operator DB 112. Then, the ACD server transmits, for example, the following information to the operator software 107 as the predetermined information.

(1) URI when the WWW browser software 104 accesses the ACD server in FIG.
(2) Information passed from the WWW browser software 104 to the ACD server in FIG.
(3) Information in the customer DB 111.
(4) Information of waiting user list 113 (for example, waiting time).

  Then, the operator 105 takes the incoming call and starts a call with the calling user 101. In the case of correspondence by chat, the operator 105 starts chatting with the user using a provided keyboard or the like after a predetermined operation.

  As described above, when communication is performed between the terminal devices logged in to the network 100 using the user ID uniquely determined for each user (the outgoing PC 102 and the operator PC 106), the predetermined terminal device. Each operator PC 106 in the group logs in to the network 100 with their own user ID, and transmits at least information (for example, presence information) on the connection availability status to the ACD server connected to the operator PC 106, and the ACD server However, in response to a call request from the calling PC 102, any one terminal device (for example, operator PC 106c) in the terminal device group is determined based on the information regarding the connection availability status, and the user ID of the determined operator PC is determined. ("Operator3") In the case where communication is performed between terminal devices logged in to the network 100 using a user ID uniquely determined for each user by instructing the calling PC 102 to automatically make a call. An ACD server can be used to reliably and efficiently distribute incoming calls to a terminal device group consisting of terminal devices, thereby realizing an ACD function.

  As shown in FIG. 8 to FIG. 10, when there is no connectable operator PC in response to a call request from the calling PC 102, the ACD server notifies the calling PC 102 to that effect and When information is registered and there is a connectable operator PC, the call is automatically sent to the caller PC 102 selected based on the customer information in the caller PC 102 to the user ID of the operator PC. It is possible to efficiently and reliably manage customers waiting for connection.

  In addition, information regarding the calling user can be included in the call request, and the ACD server determines any one operator PC in the terminal device group based on the operator information registered in advance and the information regarding the calling user. Thus, it is possible to connect to a desired operator 105, thereby realizing telephone support that meets customer needs.

(Association between request information and call information (part 1))
FIG. 17 is an explanatory diagram showing a processing flow for associating request information with call information. FIG. 18 is a sequence diagram showing the contents of the processing flow of FIG. In FIG. 17, a customer terminal 1701, an ACD server 1702, and an agent terminal 1703 are set in a state where they can be connected via a network 1700.

  A request is made from the (WWW) browser 1711 of the customer terminal 1701, which is the outgoing PC, to the ACD server 1702 (specifically, CTI (Computer Telephony Integration) middle (software) 1721) (step S1801). Here, the CTI middle 1721 controls the entire ACD server 1702 and manages the state of each agent terminal 1703. In addition, the request means that, for example, a customer clicks a button on a home page and requests agent assignment by ACD (see FIG. 6).

  Next, the ACD server 1702 (specifically, the CTI middle 1721) determines a call destination agent. The ACD server 1702 sets the P2PID of the call destination agent (terminal) 1703 together with the request information from the customer terminal 1701 in the DB 1722 (step S1802). FIG. 19 is an explanatory diagram of an example of a request information table. Thereafter, the ACD server 1702 notifies the determined P2PID of the call destination agent to the browser 1711 of the customer terminal 1701 (step S1803).

  The browser 1711 passes the P2PID of the call destination agent 1703 to the P2P 1712 (step S1804), and the P2P 1712 executes the call to the agent terminal 1703 (P2P1732 of the P2PID) (step S1805). The call is to make a call from the P2P 1712 of the customer terminal 1701 to the P2P 1732 of the agent terminal 1703 assigned by the ACD server 1702.

  When the P2P 1732 of the agent terminal 1703 receives the call from the customer terminal 1701 (P2P 1712), the P2P control software 1731 notifies the P2P control software 1731 (step S1806). The P2P control software 1731 notifies the ACD server 1703 of call information including a call from the customer terminal 1701 and the P2PID of the agent terminal 1703 (step S1807).

  The CTI middle 1721 identifies the latest record from the request information table set in the DB 1722 with the P2PID corresponding to the call destination (step S1808). Specifically, for example, the “calling agent P2PID” column of the request information table shown in FIG. 19 is searched with the P2PID corresponding to the call destination. Then, the latest record in the “request date” column is specified as the corresponding request.

  As a result, the association between the request from the browser 1711 of the customer terminal 1701 received in step S1801 and the call received by the agent terminal 1703 in step S1805 is executed. By associating in this way, request information (such as information on the operated WEB screen or terminal information included in the HTTP request) corresponding to the received call is transmitted from the ACD server 1702 to the agent terminal 1703. Can be displayed on a display screen (not shown).

(Association between request information and call information (part 2))
FIG. 20 is an explanatory diagram showing another processing flow for associating request information with call information. FIG. 21 is a sequence diagram showing the contents of the processing flow of FIG. In FIG. 20, similarly to FIG. 17, the customer terminal 1701, the ACD server 1702, and the agent terminal 1703 are set to be connectable via the network 1700. The difference between the request information and the call information “(Part 1)” is that “(Part 1)” uses the P2PID of the call destination agent terminal 1703, whereas “(Part 2)”. The ACD server 1702 assigns a request ID to each request and notifies the customer terminal 1701 of it. The customer terminal 1701 is to attach the notified request ID to the call.

  First, a request is made from the browser 1711 of the customer terminal 1701 to the ACD server 1702 (specifically, the CTI middle 1721) (step S2101). Then, the ACD server 1702 (specifically, the CTI middle 1721) determines the call destination agent in the same manner as the “(Part 1)”. Next, the ACD server 1702 assigns a request ID to the request from the customer terminal 1701 to the DB 1722 instead of the P2PID of the call destination agent (terminal) 1703, and sets it together with the request information (step S2102). ).

  FIG. 22 is an explanatory diagram of an example of the request information table. In FIG. 22, for example, “request management number” corresponds to the request ID. Therefore, the request information table “request management number” column is notified. For example, a simple serial number may be adopted as the request management number. The request management number is associated with the request date and time, the P2PID of the determined call destination agent, and the like. Thereafter, the ACD server 1702 notifies the P2PID of the determined call destination agent and the numbered request ID to the browser 1711 of the customer terminal 1701 (step S2103).

  The browser 1711 passes the P2PID and request ID of the call destination agent 1703 to the P2P 1712 (step S2104), and the P2P 1712 executes a call to the agent terminal 1703 (P2P1732) of the P2PID (step S2105). When executing a call, the request ID is attached.

  When the P2P 1732 of the agent terminal 1703 receives a call from the customer terminal 1701 (P2P 1712), the P2P 1732 notifies the P2P control software 1731 of the call (step S2106). The P2P control software 1731 notifies the ACD server 1703 of call information and request ID including a call from the customer terminal 1701 (step S2107).

  The CTI middle 1721 identifies the call using the request ID from the request information table set in the DB 1722 (step S2108). Specifically, for example, the request information table “request management number” column is searched with the request management number acquired by the agent terminal 1703 (only one case is necessarily applicable).

  As a result, the association between the request from the browser 1711 of the customer terminal 1701 received in step S2101 and the call received by the agent terminal 1703 in step S2105 is executed. By associating in this way, the request information corresponding to the call received (such as information on the operated WEB screen or terminal information included in the HTTP request), as in “(1)” above. Can be transmitted from the ACD server 1702 to the agent terminal 1703 and displayed on a display screen (not shown).

(Association between request information and call information (part 3))
FIG. 23 is an explanatory diagram showing still another processing flow for associating request information with call information. FIG. 24 is a sequence diagram showing the contents of the processing flow of FIG. In FIG. 23, as in FIGS. 17 and 20, the customer terminal 1701, the ACD server 1702, and the agent terminal 1703 are set to be connectable via the network 1700. The difference between the request information and the call information “(Part 1)” is that “(Part 1)” uses the P2PID of the call destination agent terminal 1703, whereas “(Part 3)” The P2PID of the customer terminal 1701 is used.

  First, the browser 1711 of the customer terminal 1701 receives the input of the P2PID of the customer terminal 1701, and makes a request to the ACD server 1702 (specifically, the CTI middle 1721) (step S2401). FIG. 25 shows a screen image of the customer terminal 1701 as in FIG. In the PC screen 600 of FIG. 25, reference numeral 2501 denotes a display screen (window) example of the browser (software) 1711. The display screen 2501 includes a P2PID input field 2502 and a click button “Call Me!” 2503. A customer can enter a P2PID in the P2PID input field 2502 and click a click button 2503 to specify a specific URI. , A request can be sent to the ACD server 1702.

  When making a request, the P2PID of the customer terminal 1701 that has been accepted is also notified to the ACD server 1702. Then, the ACD server 1702 (specifically, the CTI middle 1721) determines a call destination agent in the same manner as the above “(Part 1)” and “(Part 2)”. Then, the ACD server 1702 sets the P2PID of the customer terminal 1701 together with the request information in the DB 1722 (step S2402).

  FIG. 26 is an explanatory diagram of an example of the request information table. In FIG. 26, the P2PID of the customer terminal 1701 is set, for example, in the “customer P2PID” column, and is associated as “customer P2PID”. Thereafter, the ACD server 1702 notifies the P2PID of the determined call destination agent to the browser 1711 of the customer terminal 1701 (step S2403).

  The browser 1711 passes the P2PID of the call destination agent 1703 to the P2P 1712 (step S2404), and the P2P 1712 executes a call to the agent terminal 1703 (P2P1732 of the P2PID) (step S2405). When the call is executed, the P2PID of the customer terminal 1701 is attached.

  When the P2P 1732 of the agent terminal 1703 receives the call from the customer terminal 1701 (P2P 1712), the P2P control software 1731 notifies the P2P control software 1731 (step S2406). The P2P control software 1731 notifies the CTI middle 1721 of the ACD server 1702 of call information including a call from the customer terminal 1701 and the P2PID of the call source customer terminal 1701 (step S2407).

  The CTI middle 1721 identifies the call using the P2PID of the customer terminal 1701 from the request information table set in the DB 1722 (step S2408). The request information table “customer P2PID” column is searched with the acquired customer P2PID of the call source. When multiple hits are made, the latest record in the “request date” column is specified as the corresponding request.

  Accordingly, the request received from the browser 1711 of the customer terminal 1701 received in step S2401 is associated with the call received by the agent terminal 1703 in step S2405. By associating in this way, the request information corresponding to the call received (information on the operated WEB screen or HTTP request) as in “(Part 1)” and “(Part 2)” above. Terminal information included in the ACD server 1702 can be transmitted to the agent terminal 1703 and displayed on a display screen (not shown).

  27 and 28 show screen images of a customer terminal 1701 different from FIG. In FIG. 27, a member registration page is displayed on the display screen 2701, and the customer inputs a member number, name, phone number, and email address as well as P2PID from this member registration page, and a “Register” button 2702. Press. As a result, the request is executed. As shown in FIG. 28, on the assumption that the member registration is made in FIG. 27, instead of providing a customer P2PID input field, a member number input field 2801 for allowing a member to input a member number is provided. Also good.

  As described above, the request information and the call information can be associated (linked) by the above method (“(Part 1)” to “(Part 3)”), and the agent terminal 1703 receives the call. In this case, the request information associated with the call can be easily obtained from the ACD server 1702 and displayed on the display screen.

  It is also possible to realize ACD using a chat function realized by Skype. In this case, in the display screen (window) example of the WWW browser software 104 in FIG. 6, instead of displaying “Click here for inquiry” and “Call Me!” Part (button), or “Contact us here” In addition to the display of “click” and the “Call Me!” Portion (button), although not shown, it is preferable to provide a display of “click here for chat” and a “Chat!” Portion (button). Thus, if the user wishes to make an inquiry via chat, the redirect destination URI may be P2P phone chat software. Further, when both the telephone call and the chat are used, both the “Call Me!” Part (button) and the “Chat!” Part (button) are clicked. As a result, both calls and chats can be realized simultaneously.

(Outline of multilingual call center)
Next, an outline of a multilingual call center using the above embodiment will be described. If the calling user 101 sets a language that he / she can speak in the WWW browser software 104 in advance, the WWW server software 109 has a function of returning an HTML file described in the designated language. This function is called “Content Negotiation”. A plurality of languages can be set, and each priority can be specified. By using the above embodiment for this function, a call center corresponding to a plurality of languages can be constructed by returning the user ID of the operator who can speak the language specified from the WWW browser.

  FIG. 29 is an explanatory diagram showing an example of the contents of the operator DB 112. In FIG. 29, information related to a language that can be used by the operator is stored corresponding to the user ID. 29, it can be seen that “operator 1 can speak English and Japanese”, “operator 2 can speak only Japanese”, and “operator 3 can speak English and French”.

  In addition, the following information is sent from the WWW browser software 104.

  Accept-Language: fr; q = 1.0, en; q = 0.5 (French and English are OK, but French is better)

  The above numerical values indicate availability and priority. That is, it is possible to use a numerical value set, and a higher numerical value indicates a higher priority. Specifically, in the above example, it can be seen that French of 1.0 has a higher priority than English of 0.5.

  When the above-mentioned content sent is compared with the content of FIG. 29, the operator 2 is not connected to the calling user even if it is free. If both operator1 and operator3 are free, they are connected to operator3. It can be judged.

  In this way, by including information on languages that can be used as connection destination information and operator information, it is possible to construct a call center that supports a plurality of languages by applying ACD by a WWW server.

The communication method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer .

  As described above, the present invention is suitable for communication performed between terminal devices logged in to the network using a user ID uniquely determined for each user.

It is explanatory drawing which shows the outline | summary of the system for implement | achieving the communication method concerning embodiment of this invention. It is a flowchart which shows the procedure of the process of the WWW server in the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows an example of the screen image of transmission PC. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows an example of the screen image of transmission PC. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of the communication method concerning embodiment of this invention. It is explanatory drawing which shows the processing flow of correlation with request information and call information. It is a sequence diagram which shows the content of the processing flow of FIG. It is explanatory drawing which shows an example of a request information table. It is explanatory drawing which shows another processing flow of correlation with request information and call information. It is a sequence diagram which shows the content of the processing flow of FIG. It is explanatory drawing which shows an example of a request information table. It is explanatory drawing which shows another processing flow of correlation with request information and call information. It is a sequence diagram which shows the content of the processing flow of FIG. It is explanatory drawing which shows an example of the screen image of a customer terminal. It is explanatory drawing which shows an example of a request information table. It is explanatory drawing which shows another example of the screen image of a customer terminal. It is explanatory drawing which shows another example of the screen image of a customer terminal. It is explanatory drawing which shows an example of the content of operator DB.

Explanation of symbols

100, 1700 Network 101 Calling user 102 Calling PC (personal computer)
103 P2P telephone software (wear)
104 WWW browser software (ware)
105 (105a, 105b, 105c) Operator 106 (106a, 106b, 106c) Operator PC (personal computer)
107 (107a, 107b, 107c) Operator software (ware)
108 ACD server machine 109 WWW server software (ware)
110 ACD software (wear)
111 Customer Database (DB)
112 Operator database (DB)
113 Waiting user list

Claims (10)

In a voice communication method in which communication is performed between terminal devices logged in to a network using a user ID uniquely determined for each user,
Each terminal device of a predetermined terminal device group logs in to the network with its own user ID, and transmits at least information on the connection availability status to a server connected to the terminal device,
The server determines whether or not there is a vacancy in the terminal device group based on the information on the connection availability status in response to the transmission request from the source terminal device, If there is a vacancy in the terminal device, the terminal device is determined so that any one terminal device in the group of terminal devices is determined and automatically transmitted to the user ID of the determined terminal device. If there is no available terminal device in the terminal device group, if there is no available terminal device in the terminal device group, the originating terminal device is registered in the waiting user list, and the originating terminal sends a message waiting in the apparatus waits for the one of said terminal groups of the terminal device is empty, any source terminals correspond to the terminal apparatus became empty to the user list The selected source terminal device is selected from among the recorded source terminal devices, and is automatically transmitted to the selected source terminal device for the user ID of the terminal device that has become empty. A voice communication method characterized by instructing . The server stores information related to a call request from the caller terminal device in association with the determined user ID of the terminal device;
Said source terminal device, on the basis of the instruction from the server, the voice communication method according to claim 1, characterized in that the automatic transmission to the user ID of the determined terminal device. The determined terminal device makes a search request to the server for information on the call request based on its user ID when there is a call from the caller terminal device. 3. The voice communication method according to 2. The server stores a unique management ID in association with information related to a transmission request from the transmission source terminal device, and transmits the management ID to the transmission source terminal device,
The source terminal device transmits the management ID received from the server when making an automatic call to the determined user ID of the terminal device based on an instruction from the server. Item 6. The voice communication method according to Item 1 . The determined terminal device according to claim 4, characterized in that when said originating a call is originated from the source terminal device, search request to the server based on the information relating to the calling request to the management ID The voice communication method described in 1. The server stores the user ID of the source terminal device in association with the information related to the transmission request from the source terminal device,
Said source terminal device, on the basis of an instruction from the server, when the automatic transmission to the user ID of the determined terminal device according to claim 1, characterized in that to send their user ID Voice communication method. The determined terminal device, when there is a call from the caller terminal device, makes a search request to the server for information on the call request based on a user ID of the caller terminal device. The voice communication method according to claim 6 . The server receives a predetermined ID transmitted from the source terminal device together with a transmission request from the source terminal device, and receives the predetermined ID transmitted from the source terminal device for the predetermined request. Store the ID in association,
Said source terminal device, on the basis of an instruction from the server, when the automatic transmission to the user ID of the determined terminal device according to claim 1, characterized in that transmitting the predetermined ID Voice communication method. The determined terminal device makes a search request to the server for information on the call request based on the predetermined ID when there is a call from the caller terminal device. 9. The voice communication method according to 8 . A voice communication program that causes the terminal device to execute the voice communication method according to any one of claims 1 to 9 .

Images