JP2005026952A - Distributed communication system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To obtain a distributed communication system in which the destination side can acquire information on the source side when a peer to peer platform is applied to a real time service request. <P>SOLUTION: The distributed communication system comprises a destination terminal including a means for releasing information for accepting a communication request on a network, and a means for requesting information concerning another terminal upon accepting a communication request therefrom before starting service if that information is not held, and a source terminal including a means for requesting communication to another terminal based on information for accepting a communication request released on the network, and an information request response means for transmitting information concerning the request upon accepting request of information concerning its own terminal from the terminal requested communication. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a distributed communication system, and more particularly to a terminal device that performs a peer-to-peer real-time call.
[0002]
[Prior art]
With the spread of broadband networks in recent years, high-speed data communication from each home is possible. Conventionally, desktop PCs have been mainstream as terminal devices used for data communication, but portable notebook PCs, PDAs, and mobile phones have come to be widely used. In addition to the conventional wired network using public networks, wireless networks are spreading rapidly, and services that can use wireless networks in public places such as stations and coffee shops are also available. Has begun.
[0003]
Against this background, various technologies have been developed with keywords such as “ubiquitous” and “PtoP (Peer to Peer, hereinafter also referred to as“ P2P ”)”.
[0004]
The advantage of P2P that forms a community-type network is that a target can be dynamically searched without prior knowledge at the time of execution without knowing a fixed service in advance. For example, it is possible to search whether there is a desired file on the network and to receive data directly from the terminal device that owns the target file based on information obtained from any terminal device on the network. Actually, music distribution services, file exchange services, and the like using such a mechanism are used on the Internet.
[0005]
Non-Patent Document 1 and Non-Patent Document 2 describe “JXTA” as a P2P platform. JXTA has formed an open source community and is expanding each function.
[0006]
JXTA is configured with a core layer that performs communication partner search, data transfer, P2P group formation processing, etc., a middle layer that handles information retrieval, sharing, and security, and an application layer that handles file sharing, resource sharing, payment functions, etc. The
[0007]
In JXTA, information that the user wants to publish is broadcasted and waits for access from other terminal devices that want to use the information. Here, the concept of “pipe” is used for exchanging information, and a “pipe” is established with an accessing terminal device, and information is exchanged through the “pipe”. A terminal device that tries to access certain information can reach a terminal device that discloses the target information by designating a “pipe” name associated with the information disclosed by other terminal devices. At this time, the user using the terminal device does not need to be aware of the IP address or the like of the communication partner terminal device.
[0008]
[Non-Patent Document 1]
Bernard Traversat et al., "JXTA in a Nutshell", O'Reilly, September 2002
[Non-Patent Document 2]
Sun Microsystems, Inc., “Project JXTA (ProjectJXTA)”, [online], [February 20, 2003 search], Internet <URL: http: // www. jxta. org>
[0009]
[Problems to be solved by the invention]
The P2P platform described above was originally developed for the purpose of acquiring a file existing somewhere on the network. In other words, the “question file” information with the file attributes is advertised (broadcasted) on the network, and the information from the terminal device having information about the file is relied on to approach the target file. ing. In JXTA, the target is not limited to a file, but operates with a “pipe” name such as “service name” as key information.
[0010]
It is considered to apply the above technique to a real-time “call” by voice between people. A typical telephone service using a network is a so-called VoIP telephone service, in which a specific terminal device of a specific person is designated by an IP address or the like as a communication partner. If the IP address or the like of the partner terminal device is not known, the TP address of the partner terminal device may be acquired via a server device that manages the terminal device address.
[0011]
On the other hand, when the P2P platform is applied to a call, it is necessary to search for a communication partner based on the broadcast public information. The search for the communication partner can be realized using the above-mentioned conventional technology, but from the side of the incoming call, etc., the information on the other party who made the call is scarce, and it is a material for determining whether to respond Will be lacking.
[0012]
For this reason, when the P2P platform is applied to a call, it is desirable that the receiving side can acquire information on the calling side when a call request is received. Therefore, an object of the present invention is to make it possible for a called party to acquire information on a calling party when a peer-to-peer platform is mainly applied to a real-time call request.
[0013]
[Means for Solving the Problems]
In order to solve the above problems, according to the present invention,
A distributed communication system comprising a plurality of terminal devices capable of peer-to-peer calls,
A means for publishing information for accepting communication requests on the network;
When a communication request is received from another terminal device and information regarding the terminal device is not held, a request for information regarding the terminal device is made to the terminal device prior to the start of the call. A receiving terminal device comprising information requesting means to perform;
Communication request means for making a communication request to another terminal device based on information for accepting a communication request published on the network;
A distributed communication system comprising: an information request response means for transmitting information related to a request when a request for information on the terminal device is received from another terminal that has made a communication request; A system is provided.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described in detail with reference to the drawings.
[0015]
FIG. 1 is a diagram illustrating a network configuration example to which a distributed communication system according to an embodiment of the present invention is applied.
[0016]
As shown in FIG. 1, a network to which a distributed communication system is applied includes a packet network 1 and a public telephone network 6 that are connected to each other via a gateway 5 that is a protocol converter. The packet network 1 is connected to a plurality of client terminal devices (hereinafter referred to as terminal devices) 2 a to 2 i that perform communication for a call, and the telephone 3 is connected to the public telephone network 6. The call includes communication by text (so-called instant message) in addition to communication by voice (telephone). The public telephone network 6 includes a mobile telephone network.
[0017]
The packet network 1 is a network that performs packet communication according to the IP protocol, for example, and can include a public wireless LAN 1a, the Internet 1b, an ad hoc network 1c, and the like. In the example of this figure, the public wireless LAN 1a is connected to the Internet 1b, which is a wired packet network, via the wireless base station 4.
[0018]
FIG. 2 is a block diagram showing the internal configuration of the terminal device 2.
[0019]
As shown in the figure, the terminal device 2 includes a memory 10, a CPU 11 that performs processing based on a program stored in the memory 10, an accumulation device 12, and inputs such as a keyboard, a mouse, a pen, and a microphone (handset). A device 13, an output device 14 such as a speaker and a display, a packet network interface 15 for performing communication in the packet network 1, an A / D converter 16 for converting analog data into digital data, and digital data into analog data And a D / A conversion device 29 for converting the data to each other, and each is connected by an internal bus. When connecting to the ad hoc network 1c, a routing function unit is further provided.
[0020]
In this embodiment, a communication program, a user interface (UI) program, and the like are stored on the memory 10.
[0021]
The communication program stored on the memory 10 is executed by the CPU 11 so that a processing unit for performing the following reception processing and a processing unit for performing the transmission processing are virtually provided on the terminal device 2. Generate.
[0022]
That is, as a processing unit for performing reception processing, a network packet disassembly processing unit 23 that takes header information from a packet received via the packet network interface 15 and voice data / command / data from the contents of the packet that takes the header information A data distribution processing unit 24 that distributes data to each other, a plurality of output data queues 25 for temporarily buffering audio data for each transmission terminal device 2 when the received data is audio data, and an output data queue for each unit time The audio data is removed from the audio data 25, the audio data header removal processing unit 26 that decomposes the information added to the audio data and the audio data, and the first audio data among the audio data buffered in each output data queue 25 The mixing processing unit 27 for taking out the mixture and performing the mixing processing , A DECODER 28 that performs a decoding process when mixing audio data is encoded, a command analysis processing unit 30 that analyzes a command type when the received data distributed by the data distribution processing unit 24 is a command, and a data When the received data distributed by the distribution processing unit 24 is data, the data analysis processing unit 31 that analyzes the data type, and the data for outputting to the output device 14 the commands and data that need to be notified to the user Is generated.
[0023]
Further, as processing units for performing transmission processing, a coder 17 that encodes digitized voice data, a voice data packetization processing unit 18 that sends the coded voice data by the coder 17 to the packet network 1, and a packet. Network packetization processing unit 19 for adding header information including address information of the communication partner, packet sequence number, sender identifier, etc. to the received voice data, event analysis processing unit 20 for analyzing an event input by the user, When the event is a command related to voice call session control, the command packetization processing unit 21 that creates a command, and when the event is data by other messaging processing, the data packetization processing unit 22 creates this data. And generate
[0024]
However, CODER 17, voice data packetization processing unit 18, network packetization processing unit 19, network packet decomposition processing unit 23, data distribution processing unit 24, output data queue 25, voice data header removal processing unit 26, mixing processing unit 27, The DECODER 28 and the like may be configured by hardware.
[0025]
The user interface program stored on the memory 10 is executed by the CPU 11 to virtually generate the user interface unit 35 on the terminal device 2. The user interface unit 35 displays a screen provided by the system on the terminal device 2 and performs various processes described later based on instructions from the user received on the screen or the like.
[0026]
FIG. 13 is a diagram illustrating an example of a main screen of the present system displayed by the user interface unit 35 of the terminal device 2.
[0027]
As shown in the figure, the main screen includes a “public service” menu 230 for customizing services and information to be disclosed to the network, a “setting” menu for customizing address information used for communication, voice and text. “Call” menu 232 for processing real-time communication by the user, area 234 for displaying a list of information and services disclosed by other terminal devices, and “Search” requesting acquisition of public services of other terminal devices A button 235, a “CALL” button 236 for requesting real-time voice communication processing, a “Message” button 237 for requesting IM (Instant Messaging) processing, and a “CLOSE” button 238 for closing this screen and requesting system termination are arranged. Has been. Processing when each button is clicked will be described later.
[0028]
FIG. 14 is a diagram showing an example of a public service screen displayed when the “public service” menu 230 is selected on the main screen. The public service screen is a screen for setting information, services, etc. that the user of the terminal device 2 discloses on the network.
[0029]
As shown in this figure, on the public service screen, an area for selecting whether to disclose only the ID of the terminal device (check box 240) or whether to disclose information other than the ID of the terminal device (check box 241); An area for specifying information to be disclosed is arranged. In the area for specifying the information to be disclosed, a check box 242 for specifying the disclosure of the name, a check box 243 for specifying the opening of the hobby input in the adjacent hobby input field, and the adjacent occupation input field Specify the disclosure of the country of residence entered in the adjacent country entry field, check box 244 for designating disclosure of the entered profession, check box 245 for designating age disclosure entered in the adjacent age entry field Check box 246 for specifying gender disclosure, check box 247 for specifying gender disclosure, check box 248 for specifying disclosure of the telephone number input in the adjacent telephone number input field, input in the adjacent individual information input field Check box 249 for specifying the disclosure of individual information, and the field set in the adjacent service content input field. Check box 250 for specifying the public service yl Disclosure is disposed.
[0030]
Also, on the public service screen, a “PUBLIC” button 251 for publishing the specified information, an “OK” button 252 for storing the setting content, and closing the public service setting process and closing the screen The “Cancel” button 253 is arranged. Processing when each button is clicked will be described later.
[0031]
FIG. 15 is a diagram illustrating an example of a setting screen displayed by the user interface unit 35 when the “setting” menu 231 is selected on the main screen. The setting screen is a screen for setting information regarding the terminal device 2 and the user of the terminal device 2.
[0032]
As shown in the figure, the setting screen includes an area 260 for inputting a user's name and gender, an area 261 for inputting a nickname to be displayed on the screen, an area 262 for inputting an IP telephone number, and a session (pipe) for publishing a service. ) An area 263 for inputting a standby port number, an area 264 for inputting a media standby port number, an “OK” button 265 for registering display contents, and a “Cancel” button 266 for canceling processing are arranged. Yes. Processing when each button is clicked will be described later. In addition, when displaying this screen, the user interface unit 35 displays a value registered in advance or a recently registered value.
[0033]
FIG. 16 is a diagram illustrating an example of a call screen displayed by the user interface unit 35 when the “call” menu 232 is selected on the main screen. The call screen is a screen for actually making a call (including IM).
[0034]
As shown in this figure, the call screen displays an area 270 for displaying a list of nicknames registered in a buddy list, which will be described later, an area 274 for displaying the nickname of the other party in the call, and the other party selected in area 270 in real time. "CALL" button 271 for requesting voice communication, "Message" button 272 for requesting text message communication to the other party selected from area 270, "BYE" for ending voice communication or text message communication processing A button 273 is arranged. The call screen is also displayed when the “CALL” button 236 is clicked on the main screen.
[0035]
Other screens displayed by the user interface unit 35 will be described in accordance with related processing contents.
[0036]
While the internal configuration of the terminal device 2 has been described above, the gateway 5 can basically have the same internal configuration. However, the gateway 5 further has an interface with the public telephone network 6. The interface with the public telephone network 6 converts the data from the packet network 1b into analog data and outputs it to the public telephone network 6, and converts the analog data from the public telephone network 6 into digital data and sends it to the packet network 1b. To do.
[0037]
Further, the gateway 5 receives from the telephone 3 of the public telephone network 6 an instruction regarding the public information that the terminal device 2 has received the setting on the public service screen from the user of the telephone 3 and stores it in the storage device 12. This information is returned in response to an inquiry about detailed information from the terminal device 2, as will be described later.
[0038]
The terminal device 2 and the storage device 12 of the gateway 5 store a buddy list for managing information on the communication partner. FIG. 5 is a diagram illustrating an example of the data structure of the buddy list.
[0039]
As shown in the figure, the buddy list in the present embodiment includes a nickname 70 used for screen display and the like as communication partner information, an ID 71 that is a unique identifier for identifying a terminal device of the communication partner, and a communication partner. The detailed information 72, which is personal information, is managed. The detailed information 72 includes, for example, a name 72a, a telephone number (tel-no) 72b such as a public telephone network or an IP telephone, an occupation 72c, and a hobby 72d. Registration to the buddy list can be automatically acquired from the call destination by the terminal device 2 at the time of the first call, or can be registered based on an instruction from the user.
[0040]
Next, an example of the processing flow of the present invention will be described with reference to the sequence diagrams of FIGS. In this example, a case will be described in which the terminal device 2a connected to the public wireless LAN 1a places an IP phone call to the terminal device 2i connected to the ad hoc network 1c. That is, it is a call within the packet network 1.
[0041]
First, the terminal device 2a connects to the public wireless LAN 1a (step 40). When the call menu 232 is selected or the “CALL” button 236 is clicked on the main screen of the system shown in FIG. 13, the call screen shown in FIG. 16 is displayed.
[0042]
As a request for voice communication (VoIP) from the user to the terminal device 2i, when a click on the “CALL” button 271 is received in a state where the user's nickname of the terminal device 2i as the communication partner is selected on the main screen ( In step 41), the terminal device 2a refers to the buddy list, issues a VoP2P request command (CALL command) including information such as the ID and nickname of the terminal device 2i, and broadcasts it to the packet network 1 (step 42).
[0043]
FIG. 6A is a diagram illustrating an example of the format of the CALL command. As shown in the figure, the CALL command includes an IP header 80, a TCP header 81, a command type 82, a transmission source nickname 83, a transmission source IP address 84, a destination nickname 84, a buddy list registration status (whether a call has been made once or not) ) 85, a communication means type 86 such as audio / data / video, a CODEC type 87 of communication media, a reception port number 89, and the like. Each item other than the header can be described in accordance with, for example, text format XML. The same applies to each command format described below.
[0044]
When the terminal device 2d connected to the ad hoc network 1c receives the broadcast CALL command, the terminal device 2d refers to the routing table provided in the routing function unit and searches for information on the terminal device 2i (step 43). .
[0045]
If it is determined from the routing table that the terminal device 2i is connected to the ad hoc network 1c to which it is connected, the CALL command is transferred to the next terminal device in the ad hoc network 1c (step 44).
[0046]
The terminal device 2h that has received the transferred CALL command performs the processing of steps 43 and 44, so that the CALL command issued by the terminal device 2a reaches the target terminal device 2i.
[0047]
Whether the terminal device 2i that has received the CALL command from the terminal device 2a has registered in the buddy list in the terminal device 2i information (for example, a nickname or ID) of the terminal device 2a included in the received CALL command. (Step 45).
[0048]
If registered in the buddy list, the user is notified that the CALL command, that is, the call request has been received from the terminal device 2a (step 46).
[0049]
FIG. 17 is a diagram illustrating an example of a screen for receiving a CALL command, that is, notifying the user that an incoming call has been received. FIG. 17A shows that there is an incoming call from the partner registered in the buddy list, and FIG. 17B shows that there is an incoming call from a partner who is not registered in the buddy list.
[0050]
As shown in FIG. 17A, the screen for notifying the user that there has been an incoming call displays an area 280 for displaying the caller's nickname and the like, and that the caller has been registered in the buddy list. Area 281, if not responding to a call request, area 282 for inputting the reason if necessary, “Off-look” button 283 for responding to the call, and “Info” button 284 for requesting detailed information , A “Not Answer” button 285 for rejecting the incoming call and a “BYE” button for ending the call. If the caller is not registered in the buddy list, as shown in FIG. 17B, the caller is not registered in place of the area 281 for displaying that the caller has been registered in the buddy list. An area 287 to be displayed and a “Memory” button 287 for registering the caller in the buddy list are arranged.
[0051]
When the user of the terminal device 2i clicks the “Off-Fook” button 283 on this screen or issues an off-hook event such as off-hooking the handset provided in the terminal device 2i (step 47), the terminal device 2i (CALL_OK command) is generated and returned to the terminal device 2a that is the CALL command transmission source (step 48).
[0052]
FIG. 6B is a diagram illustrating an example of the format of the CALL_OK command. As shown in the figure, the CALL_OK command includes an IP header 80, a TCP header 81, a command type 82, a receiving terminal, that is, a nickname 90 of the calling terminal of the CALL_OK command, an IP address 91 of the receiving terminal, a communication means type 92, a CODEC 93, It includes a receiving port number 94 and the like.
[0053]
When the terminal device 2a receives the CALL_OK command, the terminal device 2a notifies the user that a session with the terminal device 2i has been established (step 49), and transmits / receives audio data to / from the terminal device 2i (step 50). ).
[0054]
On the other hand, as a result of checking whether the nickname of the terminal device 2a included in the received CALL command is registered in the buddy list in step 45, if it is not registered, or if the terminal device 2i receives an incoming notification in step 46 On the other hand, when the user clicks the “Info” button 284 shown in FIG. 17 and issues an event requesting detailed information of the terminal device 2a, the terminal device 2i displays an example in FIG. The “call: request detailed information” screen is displayed.
[0055]
As shown in this figure, the “call: detailed information request” screen has an area 290 for displaying a caller's nickname and the like, an area 291 for specifying an item for requesting detailed information, and “Send” for transmitting detailed information. A button 292 and a “Cancel” button 293 for closing this screen are arranged.
[0056]
When the terminal device 2i receives a click on the “Send” button 292, the terminal device 2i generates a detailed information request command (REQUIRE_INFO command) based on the setting contents of the area 291 for designating an item for requesting detailed information, and sends it to the terminal device 2a. Then, the data is transmitted (step 51).
[0057]
FIG. 7A is a diagram illustrating an example of the format of the REQUIRE_INFO command. As shown in the figure, the REQUIRE_INFO command includes an IP header 80, a TCP header 81, a command type 82, a receiving terminal device, that is, a nickname 95 of a source of the REQUIRE_INFO command, a receiving terminal ID 100, and a receiving terminal device user name 101. , Including the items corresponding to the request information from the user such as the receiving terminal device telephone number 102 and the receiving terminal device using user occupation 103.
[0058]
The terminal devices 2h and 2d, which are terminal devices on the path between the terminal devices 2i and 2a, respectively transfer a REQUIRE_INFO command to the terminal device 2a (step 52). When the terminal device 2i is connected to the Internet 1a or the wireless public LAN 1b instead of the ad hoc network 1c, the REQUIRE_INFO command can be transmitted directly to the terminal device 2a.
[0059]
The terminal device 2a that has received the REQUIRE_INFO command notifies the user that there has been a detailed information request from the terminal device 2i, and accepts whether or not to respond to the requested information.
[0060]
FIG. 19A is a diagram illustrating an example of a screen displayed on the terminal device 2a at this time. In the example of this figure, on the screen for notifying that there is a detailed information request, the area 300 for displaying the user's nickname of the terminal device 2i of the REQUIRE_INFO command is displayed, and the name is entered among the items related to the detailed information request An area 301 for inputting a telephone number, an area 302 for inputting a telephone number, an area 303 for inputting an occupation, a “Send” button 304 for returning detailed information, and a “BYE” button 305 for canceling the call are arranged. In addition, in the areas 301 to 303 for inputting items relating to the detailed information request, information registered on the public service screen or setting screen of this system may be displayed in advance.
[0061]
FIG. 19B is a diagram illustrating an example of a screen displayed on the terminal device 2a when the terminal device 2i that is the destination of the CALL command is busy. In this screen, an area 300 for displaying the user's nickname and the like of the terminal device 2i and “BYE” for canceling the call are arranged.
[0062]
FIG. 19C is a diagram illustrating an example of a screen displayed on the terminal device 2a when the terminal device 2i that is the destination of the CALL command refuses communication. In this screen, an area 300 for displaying a user's nickname and the like of the terminal device 2i and an “OK” button 307 for accepting a non-response are arranged on this screen.
[0063]
When the “Send” button 304 is clicked on the screen shown in FIG. 19A and an instruction to respond is received from the user, the detailed information set on the public service screen shown in FIG. A detailed information response command (REQUIRE_INFO_ACK command) including the organization and telephone number is generated and transmitted to the terminal device 2i (step 53).
[0064]
FIG. 7B is a diagram illustrating an example of the format of the REQUIRE_INFO_ACK command. As shown in this figure, the REQUIRE_INFO_ACK command includes an IP header 80, a TCP header 81, and a command type 82, as well as a REQUIRE_INFO_ACK command source terminal side nickname 104, a destination terminal side nickname 105, a command source terminal side ID 106, a name 107, It includes information requested by the REQUIRE_INFO command such as the telephone number 108, occupation 109, and hobby 110. However, it is possible to exclude information that the user did not designate as the disclosure target on the disclosure service screen.
[0065]
The REQUIRE_INFO_ACK command is transferred to the terminal device 2i via the terminal devices 2d and 2h (step 54).
[0066]
The terminal device 2i notifies the user of detailed information included in the REQUIRE_INFO_ACK command (step 55).
[0067]
FIG. 18B is a diagram showing an example of a “call: detailed information request response” screen for notifying the user of detailed information included in the REQUIRE_INFO_ACK command.
[0068]
As shown in this figure, the “call: detailed information request response” screen has an area 290 for displaying the user's nickname of the calling terminal device, an area 294 for displaying the name of the user of the calling terminal device, and the user of the user of the calling terminal device. An area 295 for displaying the telephone number, an area 296 for displaying the occupation of the user of the calling terminal device, an area 287 for inputting the reason for not responding as necessary, and an “Off-Fook” button 298 for responding to the call request In addition, a “Not Answer” button 299 for rejecting the reception is arranged. If other detailed information is included in the REQUIRE_INFO_ACK command, these are also displayed.
[0069]
When the user of the terminal device 2i confirms the information of the other party who made the call request and issues an off-hook event such as clicking the “OFF-look” button 298 or off-hooking the handset provided in the terminal device 2i (step) 56), a CALL_OK command is transmitted to the terminal device 2a (step 57). At this time, the acquired information of the terminal device 2a is registered in the buddy list (step 58).
[0070]
By notifying the user that the terminal device 2a has received the CALL_OK command (step 59), transmission / reception of voice data is started between the terminal devices 2a and 2i, and real-time voice communication is realized (step 60).
[0071]
FIG. 10 is a diagram illustrating an example of a data format used for a real-time voice call. As shown in the figure, the data used for the real-time voice call includes an IP header 80, a UDP header 120, a sequence number 160, voice data 161, and the like. When the real-time call data is a text message such as XML data, it includes an IP header 80, a TCP header 81, a message 162, and the like.
[0072]
If any user issues an event corresponding to on-hook during a real-time voice call (step 61), the real-time voice call is terminated.
[0073]
FIG. 4 shows a case in which the terminal device 2a is notified of an incoming call from the terminal device 2a or the user of the terminal device 2i who has received the detailed information request response rejects the reception by clicking the “Not Answer” button 299 or the like. The flow of processing is shown.
[0074]
In this case, the terminal device 2i generates a rejection response command (CALL_REJECT command) (step 61) and transmits it to the terminal device 2a (step 62).
[0075]
FIG. 6C is a diagram illustrating an example of the format of the CALL_REJECT command. As shown in the figure, the CALL_REJECT command includes an IP header 80, a TCP header 81, a command type 82, a nickname 90 of the CALL_REJECT command transmission terminal, a non-response reason flag 95 indicating whether there is a non-response reason, The reason 96 is configured to be included.
[0076]
The terminal device 2a that has received the CALL_REJECT command from the terminal device 2i notifies the user of that fact (step 63). When the reason for non-response is included in the CALL_REJECT command, the contents are also notified.
[0077]
Next, another example of the processing flow of the present invention will be described with reference to the sequence diagrams of FIGS. In this example, a case where a real-time VoP2P request is generated between the terminal device 2a connected to the public wireless LAN 1a and the telephone 3 will be described. That is, it is a call through the gateway 5. In addition, the part common to the above-mentioned Example is demonstrated simply.
[0078]
First, the terminal device 2a connects to the public wireless LAN 1a (step 170). At this time, if the terminal device 2a has set a service to be disclosed on the screen shown in FIG. 14, it broadcasts an information disclosure command (PUBLIC command) (step 171).
[0079]
FIG. 8A shows an example of the format of the PUBLIC command. As shown in the figure, the PUBLIC command includes an IP header 80, a UDP header 120, a command type 82, a public service name 121, a protocol type 122 used in a public service, a public source IP address 123, a public source reception port number 124, and the like. Consists of including. As described above, the PUBLIC command includes an IP address, a port number, a path name, and the like, which are path (pipe) information used for P2P connection.
[0080]
FIG. 8B is a diagram illustrating an example of a format of a public information search command (SEARCH_PUBLIC_INFO command). As shown in the figure, the SEARCH_PUBLIC_INFO command includes the IP header 80, the UCP header 120, the command type 82, the source terminal device nickname 125 of the SEARCH_PUBLIC_INFO command, the command source terminal device IP address 126, the keyword flag 127, the keyword 128, and the like. It is comprised including.
[0081]
FIG. 8C is a diagram illustrating an example of a format of a public information search response command (SEARCH_PUBLIC_INFO_ACK command). As shown in the figure, the SEARCH_PUBLIC_INFO_ACK command includes an IP header 80, a UDP header 120, a command type 82, a public service name 121, a protocol 122, a service public source IP address 123, a service public source reception port number 124, and the like. Consists of.
[0082]
When the terminal device 2d receives the broadcast PUBLIC command, the terminal device 2d temporarily stores information relating to the public service included in the command (step 172).
[0083]
Assuming that the IP telephone number of the terminal device 2a is “050-123-4567”, when the telephone 3 makes a call to the terminal apparatus 2a, the telephone 3 is called via the telephone to the gateway 5 (step 173). ). This can be done by a method of inputting the IP telephone number of the terminal device 2a after the telephone number of the gateway 5, or by temporarily calling the gateway 5 and following the voice response from the gateway 5, the IP telephone of the terminal device 2a. There are methods such as numbering.
[0084]
The gateway 5 that has received a call from the telephone 3 searches for the IP address of the terminal device 2a from the input telephone number. In the search, first, information on a terminal device currently connected to the packet network and registered in itself is searched. For example, in SIP (Session Initiation Protocol) created by IETF, a SIP terminal registers its current address by registering with a SIP proxy or SIP server. The gateway 5 searches the registration information as to whether there is a terminal corresponding to the IP telephone number “050-123-4567”.
[0085]
If not registered, the gateway 5 broadcasts a terminal search command (SEARCH_CLIENT command) (step 174).
[0086]
FIG. 9A is a diagram illustrating an example of the format of the SEARCH_CLIENT command. As shown in the figure, the SEARCH_CLIENT command includes an IP header 80, a UDP header 120, and a command type 82, a source nickname 140 of the SEARCH_CLIENT command, a source IP address 141, a source reception port number 142, a keyword type 143, Search terminal user (search partner) user name 144, which is one of the keywords, search partner ID 145, which is one of the keywords, search partner telephone number 146, which is one of the keywords, keyword 147 designated by another user, etc. It is comprised including.
[0087]
The terminal device 2d that has received the broadcast SEARCH_CLIENT command searches the public information of the terminal device stored so far (step 175), and if there is information on the public service of the corresponding terminal device, the terminal search response command (SEARCH_CLIENT_ACK) Command) is returned to the gateway 5 (step 176).
[0088]
FIG. 9B is a diagram illustrating an example of the format of the SEARCH_CLIENT_ACK command. As shown in the figure, the SEARCH_CLIENT_ACK command includes an IP header 80, a UDP header 120, a command type 82, a search target terminal nickname 148, a search target terminal IP address 149, a SEARCH_CLIENT_ACK command source name 150, an ID 151, a telephone number 152, and the like. It is comprised including.
[0089]
The gateway 5 that has received the SEARCH_CLIENT_ACK command acquires pipe information used in VoP2P communication from the public information of the terminal device 2a included in the command, and generates a pipe for communication with the terminal device 2a (step 177).
[0090]
Then, using this pipe, a CALL command is issued to the terminal device 2a (step 178).
[0091]
The terminal device 2a that has received the CALL command from the gateway 5 through the pipe (step 179) sends the caller information included in the CALL command (information relating to the telephone 3, such as the telephone number, the user name of the telephone 3, etc. From the buddy list.
[0092]
If not registered in the buddy list, or if there is a request for detailed information from the user of the terminal device 2a, a detailed information request command (REQUIRE_INFO command) is transmitted to the gateway 5 through the pipe (step 180).
[0093]
The gateway 5 that has received the REQUIRE_INFO command has received registration from the user of the telephone 3 in advance and stores information corresponding to the request information included in the command, and includes information corresponding to the request information when stored. A detailed information response command (REQUIRE_INFO_ACK command) is returned (step 181).
[0094]
Here, in the case of a P2P communication request between terminal devices instead of communication between the terminal device 2 and the gateway 5, the request information included in the REQUIRE_INFO command is notified to the user and prompted for input. Data may be included in the REQUIRE_INFO_ACK command.
[0095]
The terminal apparatus 2a that has received the REQUIRE_INFO_ACK command notifies the user of detailed information included in the command (step 182).
[0096]
When an event corresponding to off-hook is detected from the user (step 183), a response command (CALL_ACK command) is transmitted to the gateway 5 (step 184).
[0097]
When the gateway 5 receives the CALL_ACK command from the terminal device 2a (step 185), the gateway 5 converts it into analog voice with the telephone 3 and converts it into digital voice data with the terminal device 2a, and transmits / receives it. And real-time voice communication between the telephone 3 (step 186).
[0098]
Thereafter, when the user of the telephone 3 goes on-hook (step 187), a disconnect command (CALL_BYE command) is transmitted through the pipe to the terminal device 2a (step 188).
[0099]
Similarly, when the terminal device 2a detects an event equivalent to an on-hook from the user (step 189), a disconnect command (CALL_BYE command) is transmitted to the gateway 5 (step 190).
[0100]
FIG. 6D is a diagram illustrating an example of the format of the CALL_BYE command. As shown in the figure, the CALL_BYE command includes an IP header 80, a TCP header 81, a command type 82, a receiving terminal nickname 90, and the like. After completing the connection between the terminal device 2a and the telephone 3, the gateway 5 terminates the pipe between the terminal device 2a (step 191). The terminal device 2a also terminates the reception standby pipe when the information disclosure is terminated (step 191).
[0101]
FIG. 12 shows a case where the terminal device 2d that has received the terminal search command (SEARCH_CLIENT command) broadcast by the gateway 5 searches the public information of the terminal device stored so far (step 175), and there is no corresponding information. It is a figure which shows the flow of a process.
[0102]
In this case, the terminal device 2d transfers the SEARCH_CLIENT command received from the gateway 5 to the terminal device 2a connected via the public wireless LAN 1a (step 200).
[0103]
The terminal device 2a checks whether or not the telephone number of the calling telephone 3 included in the transferred SEARCH_CLIENT command is registered in the buddy list stored in itself (step 201).
[0104]
As a result, if it is already registered in the buddy list or the like, a terminal search response command (SEARCH_CLIENT_ACK) is transmitted to the gateway 5 (step 202). Thereafter, the processing after step 178 shown in FIG. 11 is performed.
[0105]
Next, the flow of processing when the terminal device 2 of this system receives an instruction from the user on the screen or when a command from another terminal device 2 or the like is received will be described.
[0106]
First, the flow of processing when an instruction is received from the user on the main screen shown in FIG. 13 will be described with reference to FIG.
[0107]
When this system is activated, a main screen (P2P communication tool) is displayed (step 350).
[0108]
When a click on the “Search” button 235 is accepted on this screen (step 351: Y), the “search” screen shown in FIG. 21 is displayed, and a search keyword input from the user is awaited.
[0109]
As shown in FIG. 21, the “search” screen is an area 331 for inputting a keyword of a service or information to be searched when a check button 330 to be selected when the information to be searched is a public service and the check button 330 is selected. A check button 332 to be selected when the information to be searched specifies a specific partner, an area 333 for inputting a name as a keyword for specifying the partner, an area 334 for inputting an ID, an area 335 for inputting a telephone number, An area 336 for inputting other individual information, a “Search” button 337 for executing a search, and a “Cancel” button 338 for canceling the processing are arranged.
[0110]
The user can input a known keyword in the keyword input area of this screen. When the terminal device 2 receives a click on the “Search” button 337, the terminal device 2 broadcasts a SEARCH_INFO command when the check button 330 is selected, and broadcasts a SEARCH_CLIENT command when the check button 332 is selected. To do.
[0111]
When a SEARCH_INFO_ACK command or a SEARCH_CLIENT_ACK command is received from another terminal device 2 (step 354: Y), a “search result” screen is displayed based on the received data (step 355). Note that a response waiting time for a search may be set in advance, and a response received within the time limit may be handled.
[0112]
FIG. 22 is a diagram illustrating an example of a “search result” screen. This example is a screen displayed when a SEARCH_CLIENT_ACK command is received.
[0113]
As shown in the figure, the “search result” screen includes an area 340 for displaying the number of received response commands, an item number 341 for a search result corresponding to the received response command, an area 342 for displaying a name included in the SEARCH_CLIENT_ACK command, An area 343 for displaying an ID, an area 344 for displaying a telephone number, a “Call” button 345 for making a VoP2P call request to a partner corresponding to the selected item number, and a “Cancel” button for canceling this processing 345 is arranged.
[0114]
When a click on the “CLOSE” 238 button is accepted on the main screen (step 356: Y), the present system is terminated, the screen is erased, and resources are released.
[0115]
When a click on the “Call” button 236 is accepted on the main screen (step 357: Y), address information is acquired from the data selected in the public service list area 234 (step 358), and a call transmission described later is performed. Processing (see FIG. 27) is performed (step 359).
[0116]
When a click on the “Message” button 237 is accepted on the main screen (step 360: Y), address information is acquired from the data selected in the public service list area 234 (step 361), and a message process described later is performed. (See FIG. 29) is performed (step 362).
[0117]
FIG. 24 is a diagram showing an example of a processing sequence when the “setting” menu 231 is selected on the main screen.
[0118]
First, the “setting” screen shown in FIG. 15 is displayed (step 370) to prompt the user to input. When a click on the “OK” button 265 is accepted on the “setting” screen (step 371: Y), the input data is stored in the storage device 12 and the screen is closed (step 372).
[0119]
FIG. 25 is a diagram illustrating an example of a processing sequence when the “public service” menu 230 is selected on the main screen.
[0120]
First, the “public service” screen shown in FIG. 14 is displayed (step 380), and the user is prompted to input.
[0121]
When a click on the “PUBLIC” button 251 is received on the “public service” screen (step 381: Y), the data designated in the area (240 to 250) for designating information to be published is collected and the screen is closed. (Step 382). Then, a PUBLIC command is generated and broadcast (step 383). At the same time, a TCP socket is generated and waited for pipe reception waiting for the disclosed information and services (step 384).
[0122]
When a click on the “OK” button 252 is accepted on the “public service” screen (step 385: Y), the data designated in the area (240 to 250) for designating information to be published is collected and the screen is closed. (Step 386).
[0123]
When the user clicks on the “Cancel” button 253 on the “Public Service” screen (step 387: Y), the data specified in the area (240 to 250) for specifying information to be disclosed is collected and the screen is closed. If the pipe reception standby TCP socket is open (step 389: Y), a public information end command (PUBLIC_CLOSE command) is broadcast (step 390), and the TCP socket is closed (step 390). Step 391).
[0124]
FIG. 8B is a diagram illustrating an example of the format of the PUBLIC_CLOSE command. As shown in the figure, the PUBLIC_CLOSE command includes an IP header 80, a UDP header 120, a command type 82, a public service name 121, a public source IP address 123, a public source port number 124, and the like.
[0125]
FIG. 26 is a diagram showing an example of a processing sequence when the “call” menu 232 is selected on the main screen.
[0126]
First, the “call” screen shown in FIG. 16 is displayed (step 400), and the user is prompted to select a call destination from the buddy list 270 (step 401).
[0127]
When a click on the “CALL” button 271 is accepted on the “call” screen (step 402: Y), a search is made as to whether or not the current public information or address information of the communication partner selected in the buddy list 270 is known ( Step 403: Y).
[0128]
As a result, if the address information is known, the call transmission process shown in FIG. 27 is performed (step 404). On the other hand, if the current address information is not known, the terminal search process shown in FIG. 30 is performed (step 405).
[0129]
When a click on the “Message” button 271 is accepted on the “call” screen (step 406: Y), a search is made as to whether or not the current public information or address information of the communication partner selected in the buddy list 270 is known ( Step 406: Y).
[0130]
As a result, if the address information is known, the Message process shown in FIG. 29 is performed (step 408). On the other hand, if the current address information is not known, the terminal search process shown in FIG. 30 is performed (step 405).
[0131]
When a click on the “BYE” button 272 is accepted on the “call” screen during a call, a CALL_BYE command is transmitted to the communication partner (step 410), and the call process is terminated.
[0132]
FIG. 27 is a diagram illustrating an example of a sequence of a call transmission process (step 404).
[0133]
In the call origination process, a CALL command including address information of data selected from the public service list area 234 on the main screen is transmitted by designating the address of the terminal device 2 that discloses the selected service (step). 420).
[0134]
When a CALL_ACK command is returned from the communication partner (step 421), a series of audio data transmission / reception processes of audio data input, A / D conversion, packetization, transmission / reception, packet decomposition, D / A conversion, and audio output are performed. Perform (step 422).
[0135]
When the CALL_BYE command is transmitted upon accepting the click of the “BYE” button 273, or when the CALL_BYE command is received from the communication partner (step 423: Y), the pipe used for communication is disconnected (step 424). ), The call transmission process is terminated.
[0136]
When the CALL_REJECT command is received from the communication partner (step 425: Y), the “non-response” screen shown in FIG. 19C is displayed (step 426), and the pipe used for communication is disconnected (step 426). Step 424), the call outgoing call processing is terminated.
[0137]
When a REQUIRE_INFO command is received from the communication partner (step 427: Y), the “detailed information request response” screen shown in FIG. 19A is displayed (step 428). However, if the request information of the REQUIRE_INFO command is an item for which disclosure is specified in the public service information shown in FIG. 14, the REQUIRE_INFO_ACK command is returned without displaying the “detailed information request response” screen. May be.
[0138]
When a click on the “SEND” button 304 is accepted on the “detailed information request response” screen (step 429: Y), a REQUIRE_INFO_ACK command storing information input by the user is transmitted to the communication partner (step 430).
[0139]
FIG. 28 is a diagram showing an exemplary sequence of incoming call processing when a CALL command is received.
[0140]
When a CALL command is received from another terminal device 2 (step 440), caller information of the calling terminal device 2 included in the CALL command is acquired (step 441). Then, the “VoIP: incoming call” screen shown in FIG. 17 is displayed (step 442).
[0141]
When a click on the “Off-look” button 283 is accepted on the “VoIP: incoming” screen (step 443: Y), a pipe used for transmission / reception of voice data is generated (step 444), and a CALL_OK command is sent to the CALL command transmission terminal. It transmits with respect to the apparatus 2 (step 445).
[0142]
Thereafter, a series of audio data transmission / reception processes of audio data input, A / D conversion, packetization, transmission / reception, packet decomposition, D / A conversion, and audio output are performed (step 446).
[0143]
When the CALL_BYE command is transmitted upon accepting the click of the “BYE” button 286, or when the CALL_BYE command is received from the communication partner (step 447: Y), the pipe used for communication is disconnected (step 448). ), Terminating the incoming call process.
[0144]
When a click on the “Info” button 284 is accepted on the “VoIP: incoming” screen (step 449: Y), the “request detailed information” screen shown in FIG. 18A is displayed (step 450).
[0145]
When a click on the “Send” button 292 is received on the “request detailed information” screen, a REQUIRE_INFO command including the request information specified in the request information specifying area 291 is generated and returned to the CALL command transmission terminal device 2 (Step 451).
[0146]
When the REQUIRE_INFO_ACK command is received from the calling terminal device 2 (step 452: Y), the “call: detailed information request response” screen shown in FIG. 18B is displayed based on the detailed information included in the command. (Step 453).
[0147]
When a click on the “NOT ANSWER” button 285 is accepted on the “call: detailed information request response” screen (step 454: Y), a CALL_REJECT command is generated and returned to the CALL command transmission terminal device (step 455). . Here, when data is input to the response rejection reason input area 282, this information can be included in the CALL_REJECT command.
[0148]
FIG. 29 is a diagram showing an example of a message processing sequence when the “Message” buttons 237 and 271 are clicked on the main screen or the call screen shown in FIG.
[0149]
In the Message process, a “call: Message” screen shown in FIG. 20 is displayed (step 460). As shown in the figure, the “call: Message” screen includes an area 310 for displaying a nickname of a communication partner, an area 311 for displaying a message transmitted and received between the user of the terminal device and the user of the communication terminal device, An area 312 in which a user of the apparatus inputs a message, a “Send” button 313 for transmitting a text message input in the input area 312 to the communication partner, and a “CLOSE” button 314 for ending the Message call processing are arranged. ing.
[0150]
When a click on the “Send” button 313 is accepted on the “call: Message” screen (step 461: Y), the data input in the input area 312 is acquired and a Message command is generated and displayed in the destination display area 310. Is transmitted to the communication partner terminal device 2 (step 462).
[0151]
When a click on the “Close” button 314 is accepted on the “call: Message” screen (step 463: Y), a Message_END command is generated and transmitted to the communication partner terminal device 2 (step 464). “Message” screen is closed.
[0152]
When the Message command is received from the communication partner terminal device 2 during the Message process (step 465: Y), the message included in the command is displayed in the message display area 311 after the nickname prompt of the partner terminal 2. (Step 466).
[0153]
FIG. 30 is a diagram showing an exemplary sequence of terminal search processing (step 405).
[0154]
When an event from a user using the terminal device is a trigger (step 470: Y), a SEARCH_CLIENT command is broadcast (step 471). This command includes information input in the keyword input areas 333 to 336 on the “search” screen shown in FIG.
[0155]
When a SEARCH_CLIENT_ACK command is received from another terminal device 2 (step 472: Y), the search result included in the SEARCH_CLIENT_ACK command is displayed (step 473).
[0156]
When a SEARCH_CLIENT command is received from another terminal device 2 (step 474: Y), search terminal information (keyword) included in the SEARCH_CLIENT command is acquired (step 475), and it is searched whether information including the keyword is stored. (Step 475). As a result, if there is corresponding information, a SEARCH_CLIENT_ACK command is generated and transmitted to the originating terminal device 2 of the SEARCH_CLIENT command (step 477). On the other hand, if there is no corresponding information, if there is a transfer destination of the broadcast data (step 478: Y), a SEARCH_CLIENT command is transmitted to the transfer destination terminal device 2 (step 479).
[0157]
Although the above embodiment has been described by taking as an example a so-called PtoP JXTA network in which a terminal device serving as a communication partner is searched between terminal devices, the present invention manages a plurality of terminal devices 2 connected to the packet network 1. The present invention can also be applied to a conventional client-server network in which a server device that searches for a terminal device that is a communication partner is searched. In this case, for example, the detailed information request processing when a call request is received is relayed through the server device.
[0158]
【The invention's effect】
As described above, according to the present invention, when a peer-to-peer platform is applied to a real-time call request, a receiving side can acquire information on a calling side.
[Brief description of the drawings]
FIG. 1 is a diagram showing a network configuration example of a distributed communication system to which the present invention is applied.
FIG. 2 is a diagram illustrating an internal configuration example of a terminal device 2 and a gateway 5;
FIG. 3 is a sequence diagram showing an example of a processing flow of the present invention.
FIG. 4 is a sequence diagram showing an example of a processing flow of the present invention.
FIG. 5 is a diagram illustrating an example of a buddy list.
FIG. 6 is a diagram illustrating a format example of a CALL command, a CALL_OK command, and a CALL_BYE command.
FIG. 7 is a diagram illustrating a format example of a REQUIRE_INFO command and a REQUIRE_INFO_ACK command.
FIG. 8 is a diagram illustrating a format example of a PUBLIC command, a PUBLIC_CLOSE command, a SEARCH_PUBLIC_INFO command, and a SEARCH_PUBLIC_INFO_ACK command.
FIG. 9 is a diagram illustrating a format example of a SEARCH_CLIENT command and a SEARCH_CLIENT_ACK command.
FIG. 10 is a diagram illustrating an example of a data format.
FIG. 11 is a sequence diagram showing another example of the processing flow of the present invention.
FIG. 12 is a sequence diagram showing another example of the processing flow of the present invention.
FIG. 13 is a diagram illustrating an example of a main screen.
FIG. 14 is a diagram illustrating an example of a “public service setting” screen.
FIG. 15 is a diagram illustrating an example of a “setting” screen example;
FIG. 16 is a diagram illustrating an example of a “call” screen example;
FIG. 17 is a diagram illustrating an example of an incoming call screen when a CALL command is received.
FIG. 18 is a diagram showing an example of a “call: detailed information request” screen example;
FIG. 19 is a diagram illustrating an example of a “call: detailed information request response” screen, a “calling” screen, and a “call: non-response” screen.
FIG. 20 is a diagram illustrating an example of a “call: Message” screen.
FIG. 21 is a diagram illustrating an example of a “search” screen.
FIG. 22 is a diagram illustrating an example of a screen when a command related to a search request is received.
FIG. 23 is a diagram showing an example of a user event processing sequence for the main screen.
FIG. 24 is a diagram showing an example of a user event processing sequence for a “setting” screen.
FIG. 25 is a diagram showing an example of a processing sequence when a “public service” menu screen is selected.
FIG. 26 is a diagram illustrating a sequence example of call processing.
FIG. 27 is a diagram illustrating a sequence example of a call transmission process.
FIG. 28 is a diagram illustrating a sequence example of incoming call processing.
FIG. 29 is a diagram illustrating a sequence example of Message processing.
FIG. 30 is a diagram illustrating a sequence example of terminal search processing.
[Explanation of symbols]
1 ... Packet network
2 ... Terminal device
3 ... Telephone
4 ... Radio base station
5 ... Gateway
6. Public telephone network
10 ... Memory
12 ... Storage device
13 ... Input device
14 ... Output device
15 ... Packet network interface
16 ... A / D converter
18 ... Voice data packetization processing unit
19 ... Network packetization processing unit
20 ... Event analysis processing section
21 ... Command packetization processing unit
22: Data packetization processing unit
23 ... Network packet decomposition processing unit
24 ... Data distribution processing unit processing unit
25 ... Output data queue
26: Audio data header removal processing unit
27. Mixing processing unit
29 ... D / A converter
30 ... Command analysis processing unit
31 ... Data analysis processing unit
32. Output data generation processing unit
35 ... User interface section

Claims (10)

A distributed communication system comprising a plurality of terminal devices capable of peer-to-peer calls,
A means for publishing information for accepting communication requests on the network;
When a communication request is received from another terminal device and information regarding the terminal device is not held, a request for information regarding the terminal device is made to the terminal device prior to the start of the call. A receiving terminal device comprising information requesting means to perform;
Communication request means for making a communication request to another terminal device based on information for accepting a communication request published on the network;
A distributed communication system comprising: an information request response means for transmitting information related to a request when a request for information on the terminal device is received from another terminal that has made a communication request; system. A terminal device that performs communication for communication with other terminal devices via a network,
A means for publishing information for accepting communication requests on the network;
When a communication request is received from another terminal device and information regarding the terminal device is not held, a request for information regarding the terminal device is made to the terminal device prior to the start of the call. An information requesting means for performing the terminal device. The terminal device according to claim 2,
The information request means includes
A terminal device characterized in that when a communication request is received from another terminal device and an instruction from an operator is received, a request for information on the terminal device is made to the terminal device. . The terminal device according to claim 2 or 3,
The terminal device according to claim 1, wherein the information requesting unit determines information on the terminal device to be requested from another terminal device based on an instruction from an operator. The terminal device according to any one of claims 2 to 4,
A terminal device further comprising storage means for storing information related to the terminal device when communication for communication with another terminal device is performed. The terminal device according to claim 5,
The information requesting means determines that the information requesting means does not hold information related to the terminal device when the information related to the other terminal device related to the communication request is not stored in the storage device. The terminal device according to any one of claims 2 to 6,
A terminal device further comprising request information display means for displaying information on another terminal device requested by the information request means when the information is received. The terminal device according to claim 7,
The request information display means prompts an operator to select either acceptance of a call or rejection of a call when displaying information related to another terminal device. The terminal device according to any one of claims 2 to 8,
Communication request means for making a communication request to another terminal device based on information for accepting a communication request published on the network;
A terminal device characterized by further comprising an information request response means for transmitting information related to a request when a request for information related to the terminal device is received from another terminal that has made a communication request. The terminal device according to claim 9,
The information request response means transmits information related to a request based on an instruction from an operator.

Images