Audio conference system, gateway, main device, program, and audio conference control method

Abstract

To prevent a participant of a next audio conference from speaking during an ongoing audio conference when a plurality of audio conferences are successively held for the same audio conference special number.SOLUTION: A main device 3 transmits conference audio data for each call path based on audio data received from a call path with a sender of a connection request that arrived at its audio conference special number and a call path with a telephone 2 accommodated by itself. This allows an audio conference to be held between the sender of the connection request that arrived at its audio conference special number and the telephone 2 accommodated by itself. In addition, if a GW4 relays a connection request with the audio conference special number of the main unit 3 as the destination to this main unit 3 after a predetermined time has elapsed since the start of an audio conference by the main unit 3 at the same location, the GW blocks the transmission and reception of audio data between the sender of the connection request and this main device 3, and if the end of the audio conference is confirmed, the GW releases the blockage of the transmission and reception of audio data.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a control technology for voice conferences.

Background Art

[0002] Patent Document 1 discloses a speech control device that can prevent overlapping of speeches among participants in a voice conference.

[0003] This speech control device calculates the speech priority for a plurality of participants who have spoken within a predetermined time based on the meeting-related email text and keywords sequentially obtained from the meeting voice in a voice conference. Then, based on the calculated speech priority, the speeches of those other than a specific person among these participants are muted.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] According to the speech control device described in Patent Document 1, it is possible to prevent overlapping of speeches among a plurality of participants who have spoken within a predetermined time. However, when a participant who joins a voice conference midway speaks alone without overlapping with the speeches of other participants, this cannot be muted. For example, when a plurality of voice conferences are successively held for the same voice conference special number, there may be a situation where a participant in the next voice conference accesses this voice conference special number earlier than the start time of this voice conference and accidentally joins the ongoing voice conference midway. The speech of a person who is not a participant in such an ongoing voice conference may interfere with the smooth operation of the voice conference. However, the speech control device described in Patent Document 1 cannot handle this.

[0006] The present invention has been made in view of the above circumstances, and an object thereof is to prevent the speech of participants in a voice conference to be held next in an ongoing voice conference when a plurality of voice conferences are successively held for the same special number for voice conferences.

Means for Solving the Problems

[0007] In order to solve the above problems, the present invention includes a main device that houses a telephone and a gateway that connects the main device to a network. The main device transmits conference voice data for each communication path based on the voice data received from the communication path between the source of the connection request received for its own special number for voice conferences and the communication path between the telephone. Further, the gateway monitors the implementation status of the voice conference and controls the relay of voice data between the source of the connection request whose destination is the special number for voice conferences and the main device based on the monitoring result. Specifically, when the gateway relays a connection request whose destination is the special number for voice conferences from the network to the main device in a state where no communication path is established between the source of the connection request whose destination is the special number for voice conferences and the main device, it determines that the voice conference has started. Also, when all the communication paths between the source of the connection request whose destination is the special number for voice conferences, excluding the source of the connection request whose transmission and reception of voice data are blocked, and the main device are released, it determines that the voice conference has ended and the next voice conference has started. Then, when the start of the voice conference is confirmed, if a connection request whose destination is the special number for voice conferences is relayed from the network to the main device after a predetermined time has elapsed since the start of this voice conference, the transmission and reception of voice data between the source of this connection request and the main device are blocked, and when the end of the voice conference is confirmed, the blocking of the transmission and reception of voice data between the source of this connection request and the main device is released.

[0008] For example, the present invention is a voice conference system including a main device that houses a telephone and a gateway that connects the main device to a network, wherein the main device Based on the voice data received from the call path between the source of the connection request received for the dedicated number for voice conferencing assigned to itself and the telephone, and the call path between the telephone and the main device, it has voice conferencing control means for transmitting conference voice data to each of the source of the connection request and the main device. The gateway has conference status monitoring means for monitoring the status of the voice conference of the main device, and relay control means for controlling the relay of voice data between the source of the connection request with the dedicated number for voice conferencing as the destination and the main device. The relay control means when it is confirmed by the conference status monitoring means that the voice conference has started, after a predetermined time has elapsed since the start of the voice conference, if it has relayed a connection request with the dedicated number for voice conferencing as the destination from the network to the main device, it cuts off the transmission and reception of voice data between the source of the connection request and the main device, and when it is confirmed by the conference status monitoring means that the voice conference has ended, it releases the cut-off of the transmission and reception of the voice data. The conference status monitoring means when a connection request with the dedicated number for voice conferencing as the destination is relayed from the network to the main device in a state where no call path has been established between the source of the connection request and the main device, determines that the voice conference has started. When all the call paths between the source of the connection request with the dedicated number for voice conferencing as the destination and the main device, excluding the source of the connection request for which the transmission and reception of voice data has been cut off by the relay control means, are released, it determines that the voice conference has ended and the next voice conference has started.

Advantages of the Invention

[0009] In the present invention, when a connection request with a special number for a voice conference as the destination arrives at the master device after a predetermined time has elapsed since the start of the voice conference, the gateway cuts off the transmission and reception of voice data via the communication path established between the source of this connection request and the master device. Therefore, according to the present invention, in the case where a plurality of voice conferences are successively held for the same special number for a voice conference, it is possible to prevent the participants in the next voice conference, who join the ongoing voice conference midway, from speaking in this ongoing voice conference.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Embodiments for Carrying Out the Invention

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0012] FIG. 1 is a schematic configuration diagram of a telephone system according to the present embodiment.

[0013] As shown in the figure, the telephone system according to the present embodiment includes voice conference systems 1a to 1d (hereinafter also simply referred to as voice conference system 1) installed at each of bases A to D. The voice conference systems 1a to 1d conduct voice conferences between bases A to D via a VPN (Virtual Private Network) constructed on a WAN (Wide Area Network) 5. The voice conference systems 1a to 1d each include a telephone 2a to 2d (hereinafter also simply referred to as telephone 2), a main device 3a to 3d (hereinafter also simply referred to as main device 3) that houses the telephone 2, and GWs (gateways) 4a to 4d (hereinafter also simply referred to as GW4) that connect the main device 3 to the WAN 5.

[0014] FIGS. 2 to 6 are sequence diagrams for explaining a first operation example of the telephone system according to the present embodiment.

[0015] At base B, it is assumed that the telephone 2b has received a call operation accompanied by the designation of a special number a for a voice conference assigned to the main device 3a at base A from the user (S100). The telephone 2b makes a call to the main device 3b using the special number a for the voice conference (S101). In response to this, the main device 3b transmits a connection request with the special number a for the voice conference as the destination to the GW4b (S102). Then, the GW4b performs a VPN connection process with the GW4a at base A via the WAN 5 to establish a VPN (hereinafter referred to as VPNab) that connects the GWs 4a and 4b at bases A and B on the WAN 5 (S103). Then, the GW4b transmits the connection request received from the main device 3b to the GW4a at base A via the VPNab (S104).

[0016] Next, at base A, when GW4a receives a connection request from GW4b at base B via VPNab, it relays this connection request to the main device 3a (S105). In response to this, the main device 3a sends a call notification to inform the telephone 2a of an incoming call to the special number a for the voice conference, which is the destination of this connection request (S106). Then, when the telephone 2a receives a response operation from the user (S107), it returns a response signal to the main device 3a (S108). In response to this, the main device 3a sends a connection response to GW4a (S109) and establishes a call path between the main device 3a and the telephone 2a (S110). Next, when GW4a receives the connection response from the main device 3a, it determines that a voice conference using the special number a for the voice conference has started, generates a conference table, registers the current date and time as the start time of the voice conference in this conference table, and registers the main device 3a and the main device 3b at base B, which is the source of the connection request, as the host and participant of the voice conference, respectively (S111). Then, GW4a sends the connection response received from the main device 3a to GW4b at base B via VPNab (S112).

[0017] Next, at base B, when GW4b receives the connection response from GW4a at base A via VPNab, it relays this connection response to the main device 3b (S113). In response to this, the main device 3b establishes a call path between the main device 3b and the telephone 2b (S114), establishes a call path between the main device 3b at base B and the main device 3a at base A via VPNab (S115), and relays both call paths (S116).

[0018] On the other hand, at base A, the main device 3a uses the voice data sent from the call path between the main device 3a and the telephone 2a and the voice data sent from the call path between the main device 3a and the main device 3b at base B to generate conference voice data for each call path and send it to the corresponding call path (S117). Specifically, the voice data sent from the call path between the main device 3a and the telephone 2a is sent as conference voice data to the call path between the main device 3a and the main device 3b at base B, and the voice data sent from the call path between the main device 3a and the main device 3b at base B is sent as conference voice data to the call path between the main device 3a and the telephone 2a.

[0019] Thereafter, at site C, it is assumed that the telephone 2c has received a call operation from the user accompanied by the designation of the special number a for the voice conference (S118). The telephone 2c makes a call to the main device 3c with the special number a for the voice conference (S119). In response to this, the main device 3c sends a connection request with the destination being the special number a for the voice conference to the GW4c (S120). Then, the GW4c performs a VPN connection process with the GW4a at site A via the WAN5 to establish a VPN (hereinafter referred to as VPNac) that connects the GW4a and 4c at sites A and C on the WAN5 (S121). Then, the GW4c sends the connection request received from the main device 3c to the GW4a at site A via the VPNac (S122).

[0020] Next, at site A, when the GW4a receives, via the VPNac, a connection request with the special number a for the voice conference during the voice conference from the GW4c at site C as the destination, it refers to the conference table and checks whether it is within a predetermined time (for example, 15 minutes) from the start time of the voice conference. Here, it is assumed that it is within the predetermined time. In this case, the GW4a adds a participation notice notifying the participation in the voice conference of the source of this connection request to the connection request and relays it to the main device 3a (S123). In response to this, the main device 3a sends the participation notice added to this connection request to the telephone 2a (S124) and sends a connection response to the GW4a (S125). Next, when the GW4a receives the connection response from the main device 3a, it registers the main device 3c at site C, which is the source of the connection request, as a participant in the voice conference in the conference table (S126). Then, the GW4a sends the connection response received from the main device 3a to the GW4c at site C via the VPNac (S127).

[0021] Next, at site C, when the GW4c receives the connection response from the GW4a at site A via the VPNac, it relays this connection response to the main device 3c (S128). In response to this, the main device 3c establishes a call path between itself and the telephone 2c (S129), establishes a call path between itself and the main device 3a at site A via the VPNac (S130), and relays both call paths (S131).

[0022] On one hand, at site A, the main device 3a uses the voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3b at site B, and the voice data sent from the communication path with the main device 3c at site C to generate conference voice data for each communication path and send it to the corresponding communication path (S132). Specifically, it mixes the voice data sent from the communication path with the main device 3b at site B and the voice data sent from the communication path with the main device 3c at site C to generate conference voice data, and sends this to the communication path with the telephone 2a. It mixes the voice data sent from the communication path with the telephone 2a and the voice data sent from the communication path with the main device 3c at site C to generate conference voice data, and sends this to the communication path with the main device 3b at site B. Then, it mixes the voice data sent from the communication path with the telephone 2a and the voice data sent from the communication path with the main device 3b at site B to generate conference voice data, and sends this to the communication path with the main device 3c at site C.

[0023] After that, at site D, assume that the telephone 2d has received an outgoing call operation accompanied by the designation of the special number a for the voice conference (S133). The telephone 2d makes an outgoing call to the main device 3d with the special number a for the voice conference (S134). In response to this, the main device 3d sends a connection request with the destination being the special number a for the voice conference to the GW4d (S135). Then, the GW4d performs VPN connection processing with the GW4a at site A via the WAN5 to establish a VPN (hereinafter referred to as VPNad) that connects the GW4a and 4d at sites A and D on the WAN5 (S136). Then, the GW4d sends the connection request received from the main device 3d to the GW4a at site A via the VPNad (S137).

[0024] Next, at base A, when GW4a receives a connection request from GW4d at base D via VPNad with the dedicated number a for the voice conference during the voice conference as the destination, it refers to the conference table and checks whether it is within a predetermined time from the start time of the voice conference. Here, it is assumed that the predetermined time has passed. In this case, GW4a adds a standby notice notifying the standby of the source of this connection request to the connection request and relays it to the main device 3a (S138). In response to this, the main device 3a transmits the standby notice added to this connection request to the telephone 2a (S139) and transmits a connection response to GW4a (S140). Next, when GW4a receives the connection response from the main device 3a, it registers the main device 3d at base D, which is the source of the connection request, as a standby person for the voice conference in the conference table (S141). Then, GW4a adds a standby notice to the connection response received from the main device 3a and transmits it to GW4d at base D via VPNad (S142), and starts blocking the voice data transmitted and received between GW4d at base D and the main device 3a via VPNad (S143).

[0025] Next, at base D, when GW4d receives a connection response with a standby notice added from GW4a at base A via VPNad, it relays it to the main device 3d (S144). In response to this, the main device 3d transmits the standby notice to the telephone 2d (S145). Also, the main device 3d establishes a call path between itself and the telephone 2d (S146), establishes a call path between itself and the main device 3a at base A via VPNad (S147), and relays both call paths (S148).

[0026] On one hand, at base A, the main device 3a uses the voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3b at base B, the voice data sent from the communication path with the main device 3c at base C, and the voice data sent from the communication path with the main device 3d at base D to generate conference voice data for each communication path and send it to the corresponding communication path (S149). Specifically, the voice data sent from the communication path with the main device 3b at base B, the voice data sent from the communication path with the main device 3c at base C, and the voice data sent from the communication path with the main device 3d at base D are mixed to generate conference voice data, which is sent to the communication path with the telephone 2a. The voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3c at base C, and the voice data sent from the communication path with the main device 3d at base D are mixed to generate conference voice data, which is sent to the communication path with the main device 3b at base B. The voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3b at base B, and the voice data sent from the communication path with the main device 3d at base D are mixed to generate conference voice data, which is sent to the communication path with the main device 3c at base C. Then, the voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3b at base B, and the voice data sent from the communication path with the main device 3c at base C are mixed to generate conference voice data, which is sent to the communication path with the main device 3d at base D. However, the transmission and reception of voice data between the main device 3a and the main device 3d are blocked by the GW4a (S150). Therefore, the voice conference is carried out between the telephones 2a to 2c at bases A to C, and the telephone 2d at base D is in a standby state.

[0027] After that, at base B, assume that the telephone 2b receives an end call operation from the user (S151). The telephone 2b sends an end call signal to the main device 3b (S152). In response to this, the main device 3b sends a disconnection request to the GW4b (S153). Then, the GW4b sends the disconnection request received from the main device 3b to the GW4a at base A via the VPNab (S154).

[0028] Next, at base A, when GW4a receives a disconnection request from GW4b at base B via VPNab, it relays this to the main device 3a (S155). In response to this, the main device 3a sends a withdrawal notice to the telephone 2a notifying that the sender of this disconnection request has withdrawn from the voice conference (S156), and also sends a disconnection response to GW4a (S157). Next, when GW4a receives the disconnection response from the main device 3a, it changes the attribute of the main device 3b at base B, which is the sender of the disconnection request registered in the conference table, from participant to absentee (S158). Then, GW4a sends the disconnection response received from the main device 3a to GW4b at base B via VPNab (S159).

[0029] Next, at base B, when GW4b receives the disconnection response from GW4a at base A via VPNab, it relays this disconnection response to the main device 3b (S160). In response to this, the main device 3b releases the communication path with the main device 3a at base A (S161), releases the communication path with the telephone 2b (S162), and ends the relay between the two communication paths (S163). Then, GW4b disconnects VPNab (S164).

[0030] As a result, the main device 3a generates conference voice data for each communication path using the voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3c at site C, and the voice data sent from the communication path with the main device 3d at site D, and sends it to the corresponding communication path (S165). Specifically, the voice data sent from the communication path with the main device 3c at site C and the voice data sent from the communication path with the main device 3d at site D are mixed to generate conference voice data, which is sent to the communication path with the telephone 2a. The voice data sent from the communication path with the telephone 2a and the voice data sent from the communication path with the main device 3d at site D are mixed to generate conference voice data, which is sent to the communication path with the main device 3c at site C. Then, the voice data sent from the communication path with the telephone 2a and the voice data sent from the communication path with the main device 3c at site C are mixed to generate conference voice data, which is sent to the communication path with the main device 3d at site D. However, as described above, the transmission and reception of voice data between the main device 3a and the main device 3d are blocked by the GW4a. Therefore, the voice conference is carried out between the telephones 2a and 2c at sites A and C, and the telephone 2d at site D remains in the standby state.

[0031] Thereafter, at site C, it is assumed that the telephone 2c has received an end call operation from the user (S166). The telephone 2c sends an end call signal to the main device 3c (S167). In response to this, the main device 3c sends a disconnection request to the GW4c (S168). Then, the GW4c sends the disconnection request received from the main device 3c to the GW4a at site A via the VPNac (S169).

[0032] Next, at base A, when GW4a receives a disconnection request from GW4c at base C via VPNac, it relays this to the main device 3a (S170). In response to this, the main device 3a sends a withdrawal notice notifying the telephone 2a that the sender of this disconnection request has left the audio conference (S171), and also sends a disconnection response to GW4a (S172). Next, when GW4a receives the disconnection response from the main device 3a, it changes the attribute of the main device 3c at base C, which is the sender of the disconnection request and is registered in the conference table, from participant to absentee (S173). Then, GW4a sends the disconnection response received from the main device 3a to GW4c at base C via VPNac (S174).

[0033] Next, at base C, when GW4c receives a disconnection response from GW4a at base A via VPNac, it relays this disconnection response to the main device 3c (S175). In response to this, the main device 3c releases the communication path with the main device 3a at base A (S176), releases the communication path with the telephone 2c (S177), and ends the relay between both communication paths (S178). Then, when GW4c confirms that the communication path between the main devices 3a and 3c has been released, it disconnects VPNac (S179).

[0034] After that, at base A, when GW4a confirms at the conference table that all participants have been changed to attendees who have left (all except the host and standby attendees are attendees who have left), it determines that the ongoing voice conference has ended and a new voice conference has started, and updates the conference table (S180). Specifically, it registers the current time as the voice conference end time in the conference table and creates a new conference table. Then, it registers the current time as the voice conference start time in this new conference table, and registers the main device 3d that is registered as a standby attendee in the telephone 2a and the conference table of the ended voice conference as the host and a participant of the new voice conference, respectively. Then, GW4a sends a conference start notification to inform the main device 3a that a new voice conference has started (S181). Upon receiving this, the main device 3a sends a conference start notification to the telephone 2a (S182). Also, GW4a sends a conference start notification to GW4d at base D via VPNad (S183), and ends the blocking of voice data transmitted and received between GW4d at base D and the main device 3a via VPNad (S184).

[0035] Next, at base D, when GW4d receives a conference start notification from GW4a at base A via VPNad, it sends this to the main device 3d (S185). Upon receiving this, the main device 3d sends a conference start notification to the telephone 2d (S186).

[0036] As a result, the main device 3a generates conference voice data for each communication path using the voice data sent from the communication path with the telephone 2a and the voice data sent from the communication path with the main device 3d at the base D, and sends it to the corresponding communication path (S187). Specifically, the voice data sent from the communication path with the main device 3d at the base D is sent as conference voice data to the communication path with the telephone 2a, and the voice data sent from the communication path with the telephone 2a is sent as conference voice data to the communication path with the main device 3d at the base D. Here, as described above, the blocking of the transmission and reception of voice data between the main device 3a and the main device 3d by the GW4a has ended, so voice data is transmitted and received between the main device 3a and the main device 3d via the GW4a (S188), and a voice conference is started between the telephones 2a and 2d at the bases A and D.

[0037] FIG. 7 is a sequence diagram for explaining a second operation example of the telephone system according to the present embodiment.

[0038] S100 to S150 shown in FIGS. 2 to 4 are executed, whereby a voice conference is carried out between the telephones 2a to 2c at the bases A to C, and it is assumed that the telephone 2d at the base D is in a standby state (S200).

[0039] At the base A, it is assumed that the telephone 2a has received a participation permission operation from the user to permit participation in the voice conference of the main device 3d at the standby base D (S201). In response to this, the telephone 2a transmits a participation permission notification with the designation of the main device 3d at the base D to the main device 3a (S202), and the main device 3a transmits the participation permission notification received from this telephone 2a to the GW4a (S203). Then, when the GW4a receives the participation permission notification, it changes the attribute of the main device 3d at the base D designated in the participation permission notification registered in the conference table from a standby person to a participant (S204), and ends the blocking of the voice data transmitted and received between the GW4d at the base D and the main device 3a via the VPNad (S205). Then, the GW4a transmits a participation notification notifying the participation in the voice conference of the main device 3d at the base D designated in this participation permission notification to the GW4d via the VPNad (S206).

[0040] Then, at base D, GW4d relays the participation notice received from GW4a via VPNad to the master device 3d (S207), and the master device 3d transmits the participation notice received from GW4d to the telephone 2d (S208).

[0041] By implementing S200 (S100 to S150 shown in FIGS. 2 to 4), at base A, the master device 3a uses the voice data sent from the call path with the telephone 2a, the voice data sent from the call path with the master device 3b at base B, the voice data sent from the call path with the master device 3c at base C, and the voice data sent from the call path with the master device 3d at base D to generate conference voice data for each call path and send it to the corresponding call path (S209). Here, as described above, the blocking of the transmission and reception of voice data between the master device 3a and the master device 3d by GW4d has ended, so voice data is transmitted and received between the master device 3a and the master device 3d via GW4a (S210), and a voice conference is held between the telephones 2a to 2d at bases A to D.

[0042] FIG. 8 is a sequence diagram for explaining a third operation example of the telephone system according to an embodiment of the present invention.

[0043] S100 to S165 shown in FIGS. 2 to 5 are implemented, the telephone 2b at base B withdraws from the voice conference, a voice conference is held between the telephones 2a and 2c at bases A and C, and the telephone 2d at base D is in a standby state (S220).

[0044] At site A, it is assumed that the telephone 2a has received a meeting end operation from the user to end the ongoing meeting (S221). In response to this, the telephone 2a sends a meeting end notification to the main device 3a (S222), and the main device 3a sends the meeting end notification received from this telephone 2a to the GW4a (S223). Then, when the GW4a receives the meeting end notification from the main device 3a, it determines that the ongoing voice conference has ended and a new voice conference has started, and updates the meeting table (S224). Specifically, the current time is registered in the meeting table as the voice conference end time, and a new meeting table is created. Then, in this new meeting table, the current time is registered as the voice conference start time, the telephone 2a is registered as the host of the new voice conference, and further, the main devices 3c and 3d respectively registered as participants and standbyers in the meeting table of the ended voice conference are registered as participants in the new voice conference. Also, the GW4a ends the blocking of the voice data transmitted and received between the GW4d at site D and the main device 3a via the VPNad (S225). Then, the GW4a sends a meeting start notification notifying the start of the new voice conference to the GW4c and 4d via the VPNac and VPNad respectively (S226, S229).

[0045] Then, at site C, the GW4c relays the meeting start notification received from the GW4a via the VPNac to the main device 3c (S227). In response to this, the main device 3c relays this meeting start notification to the telephone 2c (S228).

[0046] Similarly, at site D, the GW4d relays the meeting start notification received from the GW4a via the VPNad to the main device 3d (S230). In response to this, the main device 3d relays this meeting start notification to the telephone 2d (S231).

[0047] By implementing S220 (S100 to S165 shown in FIGS. 2 to 5), at base A, the main device 3a uses the voice data sent from the call path with the telephone 2a, the voice data sent from the call path with the main device 3c at base C, and the voice data sent from the call path with the main device 3d at base D to generate conference voice data for each call path and send it to the corresponding call path (S232). Here, as described above, since the cutoff of the transmission and reception of voice data between the main device 3a and the main device 3d by GW4a has ended, voice data is transmitted and received between the main device 3a and the main device 3d via GW4a (S233), and thus, a new voice conference is implemented between the telephones 2a to 2d at bases A to D.

[0048] FIGS. 9 and 10 are sequence diagrams for explaining a fourth operation example of a telephone system according to an embodiment of the present invention.

[0049] S100 to S165 shown in FIGS. 2 to 5 are implemented, the telephone 2b at base B withdraws from the voice conference, a voice conference is implemented between the telephones 2a and 2c at bases A and C, and the telephone 2d at base D is in a standby state (S240).

[0050] At base B, assume that the telephone 2b has received again a call operation accompanied by the designation of the special number a for voice conference assigned to the main device 3a at base A from the user. The telephone 2b makes a call to the main device 3b using the special number a for voice conference (S242). In response to this, the main device 3b transmits a connection request with the destination being the special number a for voice conference to GW4b (S243). Then, GW4b performs a VPN connection process with GW4a at base A via WAN5 to re - establish the VPNab connecting GW4a and 4b at bases A and B on WAN5 (S244). Then, GW4b transmits the connection request received from the main device 3b to GW4a at base A via VPNab (S245).

[0051] Next, at base A, when GW4a receives a connection request from GW4b at base B via VPNab, it refers to the conference table and further checks whether the source of the connection request is registered as an attendee in the conference table. When it is confirmed that the main device 3b at base B, which is the source of the connection request, is registered as an attendee in the conference table (S246), GW4a permits the source of the connection request to participate in the voice conference regardless of whether it is within a predetermined time from the start time of the voice conference, adds a participation notice notifying the source of this connection request of its participation in the voice conference to the connection request, and relays it to the main device 3a (S247). In response to this, the main device 3a transmits the participation notice added to this connection request to the telephone 2a (S248) and transmits a connection response to GW4a (S249). Next, when GW4a receives the connection response from the main device 3a, it changes the attribute of the main device 3b at base B, which is the source of the connection request registered in the conference table, from an attendee to a participant (S250). Then, GW4a transmits the connection response received from the main device 3a via VPNab to GW4b at base B (S251).

[0052] Next, at base B, when GW4b receives a connection response from GW4a at base A via VPNab, it relays this connection response to the main device 3b (S252). In response to this, the main device 3b establishes a communication path with the telephone 2b (S253), establishes a communication path with the main device 3a at base A via VPNab (S254), and relays both communication paths (S255).

[0053] As a result, at base A, the main device 3a generates conference voice data for each communication path using the voice data sent from the communication path with the telephone 2a, the voice data sent from the communication path with the main device 3b at base B, the voice data sent from the communication path with the main device 3c at base C, and the voice data sent from the communication path with the main device 3d at base D, and sends it to the corresponding communication path (S256). However, since the transmission and reception of voice data between the main device 3a and the main device 3d are blocked by GW4a, the voice conference is carried out between the telephones 2a to 2c at bases A to C, and the telephone 2d at base D remains in a standby state.

[0054] Figs. 11 to 14 are sequence diagrams for explaining a fifth operation example of the telephone system according to the present embodiment.

[0055] It is assumed that S100 to S150 shown in Figs. 2 to 4 are executed, a voice conference is carried out between the telephones 2a to 2c at bases A to C, and the telephone 2d at base D is in a standby state (S260).

[0056] At base A, it is assumed that the telephone 2a has received an end call operation from the user (S261). In response to this, the telephone 2a sends an end call signal to the main device 3a (S262). Then, the main device 3a sends an end call notification to GW4a to notify the departure from the host's voice conference (S263). When GW4a receives the end call notification from the main device 3a, it changes the attribute of the main device 3a registered in the conference table from the host to the attendee who has left (S264). Then, GW4a determines a new host from among the main devices 3b and 3c of bases B and C registered as participants in the conference table according to a predetermined rule (S265). Here, it is assumed that the main device 3b of base B that participated in the voice conference earlier is determined as the new host. GW4a sends a host appointment request including the registration content of the conference table to GW4b of base B via VPNab (S266).

[0057] Next, at base B, GW4b returns an acceptance response to the organizer appointment request received from GW4a at base A via VPNab (S267), and creates a conference table. Then, the registration content of the conference table included in the organizer appointment request is registered in this conference table, with the attribute of the main device 3b included in this registration content changed from participant to organizer (S268). Then, GW4b sends an organizer appointment notice to the main device 3b (S269). In response to this, the main device 3b terminates the relay between the communication path with the telephone 2b and the communication path with the main device 3a at base A, and puts the communication path with the telephone 2b on hold (S270).

[0058] Also, at base A, when GW4a receives an acceptance response from GW4b at base B via VPNab, it sends a host change notice notifying that the host has been changed from the main device 3a at base A to the main device 3b at base B to GW4c at base C via VPNac (S271), and also sends it to GW4d at base D via VPNad (S293).

[0059] Next, at base C, when GW4c receives a host change notice from GW4a at base A via VPNac, it relays this to the main device 3c (S272). In response to this, the main device 3c terminates the relay between the communication path with the telephone 2c and the communication path with the main device 3a at base A, and puts the communication path with the telephone 2c on hold (S273). Then, the main device 3c sends a disconnection request to GW4c (S274). And GW4c sends the disconnection request received from the main device 3c to GW4a at base A via VPNac (S275).

[0060] Next, at base A, when GW4a receives a disconnection request from GW4c at base C via VPNac, it relays this to the main device 3a (S276). In response to this, the main device 3a sends a disconnection response to GW4a (S277). And GW4a sends the disconnection response received from the main device 3a to GW4c at base C via VPNac (S278).

[0061] Next, at site C, when GW4c receives a disconnection response from GW4a at site A via VPNac, it relays this disconnection response to the master device 3c (S279). In response to this, the master device 3c releases the communication path with the master device 3a at site A (S280). Then, GW4c disconnects VPNac (S281). After that, the master device 3c sends a connection request destined for the special voice conference number b assigned to the master 3b at site B, which is specified as the new host in the host change notification, to GW4c (S282). Then, GW4c performs a VPN connection process with GW4b at site B via WAN5 and establishes a VPN (hereinafter referred to as VPNbc) that connects GW4b and 4c between sites B and C on WAN5 (S283). Then, GW4c sends the connection request received from the master device 3c via VPNbc to GW4b at site B (S284).

[0062] Next, at site B, when GW4b receives a connection request from GW4c at site C via VPNbc, it relays this connection request to the master device 3b (S285). In response to this, the master device 3b sends a connection response to GW4b (S286). When GW4b receives the connection response from the master device 3b, it checks the attributes of the master device 3c at site C, which is the source of the connection request and is registered in the conference table (S287). Here, the attributes of the master device 3c at site C registered in the conference table indicate that it is a participant. In this case, GW4b sends the connection response received from the master device 3b via VPNbc to GW4c at site C (S288).

[0063] Next, at site C, when GW4c receives a connection response from GW4b at site B via VPNbc, it relays this connection response to the master device 3c (S289). In response to this, the master device 3c establishes a communication path with the master device 3b at site B via VPNbc (S290). Then, it cancels the hold of the communication path with the telephone 2c and relays between the communication path with the telephone 2c and the communication path with the master device 3b at site B (S291).

[0064] On one hand, at base B, the main device 3b releases the hold on the call path with the telephone 2b. Then, using the voice data sent from the call path with the telephone 2b and the voice data sent from the call path with the main device 3c at base C, it generates conference voice data for each call path and sends it to the corresponding call path (S292). Specifically, it sends the voice data sent from the call path with the telephone 2b as conference voice data to the call path with the main device 3c at base C, and sends the voice data sent from the call path with the main device 3c at base C as conference voice data to the call path with the telephone 2b.

[0065] Also, at base D, when the GW4d receives a host change notification from the GW4a at base A via the VPNad, it relays this to the main device 3d (S294). In response to this, the main device 3d ends the relay between the call path with the telephone 2d and the call path with the main device 3a at base A, and puts the call path with the telephone 2d on hold (S295). Then, the main device 3d sends a disconnection request to the GW4d (S296). And the GW4d sends the disconnection request received from the main device 3d via the VPNad to the GW4a at base A (S297).

[0066] Next, at base A, when the GW4a receives a disconnection request from the GW4d at base D via the VPNad, it relays this to the main device 3a (S298). In response to this, the main device 3a sends a disconnection response to the GW4a (S299). And the GW4a sends the disconnection response received from the main device 3a via the VPNad to the GW4d at base D (S300).

[0067] Next, at base D, when the GW4d receives a disconnection response from the GW4a at base A via the VPNad, it relays this disconnection response to the main device 3d (S301). In response to this, the main device 3d releases the call path with the main device 3a at base A (S302).

[0068] On one hand, at base A, when the communication path between the main device 3a and the main device 3b at base B is released, the main device 3a releases the communication path with the telephone 2a (S303) and ends the voice conference using the special number a for voice conferencing (S304).

[0069] After that, at base D, the GW4d disconnects the VPNad (S305). Then, the main device 3d sends a connection request to the GW4d with the special number b for voice conferencing assigned to the host 3b at base B, which is specified as the new host in the host change notification (S306). Then, the GW4d performs a VPN connection process with the GW4b at base B via the WAN5 to establish a VPN (hereinafter referred to as VPNbd) that connects the GW4b and 4d at bases B and D on the WAN5 (S307). Then, the GW4d sends the connection request received from the main device 3d via the VPNbd to the GW4b at base B (S308).

[0070] Next, at base B, when the GW4b receives a connection request from the GW4d at base D via the VPNbd, the GW4b relays this connection request to the main device 3b (S309). In response to this, the main device 3b sends a connection response to the GW4b (S310). When the GW4b receives the connection response from the main device 3b, the GW4b checks the attribute of the main device 3d at base D, which is the source of the connection request, registered in the conference table (S311). Here, the attribute of the main device 3d at base D registered in the conference table is a standby participant. In this case, the GW4b sends the connection response received from the main device 3b via the VPNbd to the GW4d at base D (S312) and starts blocking the voice data transmitted and received between the GW4d at base D and the main device 3b via the VPNbd (S313).

[0071] Next, at base D, when GW4d receives a connection response from GW4b at base B via VPNbd, it relays this connection response to main device 3d (S314). In response to this, main device 3d establishes a call path with main device 3b at base B via VPNbd (S315). Then, it cancels the hold of the call path with telephone 2d and relays between the call path with telephone 2d and the call path with main device 3b at base B (S316).

[0072] On the other hand, at base B, main device 3b uses the voice data sent from the call path with telephone 2b, the voice data sent from the call path with main device 3c at base C, and the voice data sent from the call path with main device 3d at base D to generate conference voice data for each call path and send it to the corresponding call path (S317). Specifically, it mixes the voice data sent from the call path with main device 3c at base C and the voice data sent from the call path with main device 3d at base D to generate conference voice data and sends this to the call path with telephone 2b. It mixes the voice data sent from the call path with telephone 2b and the voice data sent from the call path with main device 3d at base D to generate conference voice data and sends this to the call path with main device 3c at base C. Then, it mixes the voice data sent from the call path with telephone 2a and the voice data sent from the call path with main device 3c at base C to generate conference voice data and sends this to the call path with main device 3d at base D. However, the transmission and reception of voice data between main device 3b and main device 3d are blocked by GW4b (S318). For this reason, the voice conference is carried out between telephones 2a and 2b at bases B and C, and telephone 2d at base D remains in a standby state.

[0073] Next, the details of GW4 and main device 3 that make up the telephone system according to this embodiment will be described.

[0074] Note that for telephone 2, an existing telephone such as a button telephone equipped with a display function for various notifications related to the voice conference received from main device 3 and a reception function for various operations related to the voice conference can be used, so a detailed description thereof is omitted.

[0075] First, the details of GW4 will be described.

[0076] FIG. 15 is a schematic functional configuration diagram of GW4.

[0077] As shown in the figure, GW4 includes a WAN interface unit 40, a main device interface unit 41, a VPN processing unit 42, a relay control unit 43, a conference table storage unit 44, a conference status monitoring unit 45, a notification receiving unit 46, a host change request unit 47, a host appointment notification unit 48, and a host change notification unit 49.

[0078] The WAN interface unit 40 is an interface for connecting to the WAN 5. Also, the main device interface unit 41 is an interface for connecting to the main device 3.

[0079] The VPN processing unit 42 cooperates with another GW4 that is the communication partner (hereinafter referred to as the partner GW4) to establish and release a VPN that connects between the own GW4 and the partner GW4 on the WAN 5.

[0080] The relay control unit 43 relays the exchange of communication data between the partner GW4 and the main device 3 at the same base as the own GW4 (hereinafter referred to as the same-base main device 3) via the VPN established by the VPN processing unit 42. Also, the relay control unit 43 controls the blocking and unblocking of the transmission and reception of voice data via the VPN between the partner GW4 and the same-base main device 3.

[0081] In the conference table storage unit 44, a conference table is stored for each voice conference hosted by the same-base main device 3.

[0082] FIG. 16 is a diagram schematically showing an example of the registered content in the conference table storage unit 44.

[0083] As shown in the figure, in the conference table storage unit 44, for each voice conference hosted by the same-site host device 3, a conference table 440 is stored, associated with a special number for voice conferences, the start date and time of the voice conference, and the end date and time of the voice conference (however, it is blank during the voice conference). In the conference table 440, for each accessor to the special number for voice conferences associated with this conference table 440, an accessor's record 441 is stored. The accessor's record 441 has a field 442 in which information (such as number information) of the accessor, which is the host device 3 (or the telephone 2 accommodated in the host device 3), is registered, a field 443 in which the status of the accessor (either the host, a participant, a standbyer, or a leaver) is registered, and a field 444 in which the registration or update date and time of this record 441 is registered.

[0084] Based on the call control messages for the dedicated special number for voice conferences of the same-site host device 3, which are exchanged between the partner GW4 and the same-site host device 3 via the relay control unit 43, the conference status monitoring unit 45 monitors the implementation status of the voice conference in the same-site host device 3.

[0085] The notification receiving unit 46 receives various notifications (participation permission notification, conference end notification, call end notification) from the same-site host device 3.

[0086] When receiving a call end notification from the same-site host device 3 during a voice conference with the same-site host device 3 as the host, the host change request unit 47 refers to the conference table 440 of the ongoing voice conference stored in the conference table storage unit 44, and determines a host successor from among the participants according to a predetermined rule (for example, in ascending order of the date and time registered in the field 444 of the accessor's record 441). Then, a host change request including the accessor's record 441 registered in this conference table 440 is transmitted to the host successor, and a host change notification accompanied by the designation of the host successor is transmitted to each of the participants and standbyers other than the host successor.

[0087] When the host appointment notification unit 48 receives a host change request from the partner GW4 via the VPN, it transmits a host appointment notification including the record 441 of the accessor included in this host change request to the same-site main device 3.

[0088] When the host change notification unit 49 receives a host change notification from the partner GW4 via the VPN, it transmits this host change notification to the same-site main device 3.

[0089] Note that the functional configuration of GW4 shown in FIG. 15 is realized either hard by an integrated logic IC such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array), or realized soft by a computer such as a DSP (Digital Signal Processor). Alternatively, in a general-purpose computer such as a PC equipped with a CPU, a memory, an auxiliary storage device such as a hard disk and a flash memory, and a communication interface such as a NIC (Network Interface Card) and a wireless adapter, the CPU loads a predetermined program from the auxiliary storage device onto the memory and executes it to be realized as a process.

[0090] FIG. 17 is a flowchart for explaining the first voice conference master process of GW4.

[0091] This flow is started when the VPN processing unit 42 receives a VPN request from the partner GW4 via the WAN interface unit 40 (however, excluding the execution of the fourth voice conference slave process shown in FIGS. 28 and 29 described later).

[0092] First, the VPN processing unit 42 performs a VPN connection process with the peer GW4 via the WAN interface unit 40 to establish a VPN that connects the local GW4 and the peer GW4 on the WAN5 (S400). Then, if the VPN processing unit 42 receives a connection request accompanied by the designation of a special number for the voice conference of the same-site main device 3 from the peer GW4 via the VPN (YES in S401), it passes this connection request to the relay control unit 43. In response to this, the relay control unit 43 refers to the conference table storage unit 44 to check whether a conference table 440 in which the voice conference start date and time are registered and the voice conference end date and time are not registered is stored, thereby determining whether it is during a voice conference (S402).

[0093] And if the relay control unit 43 determines that it is not during a voice conference (NO in S402), it performs the voice conference start process described later (S404). On the other hand, if it is during a voice conference (YES in S402), it refers to the conference table 440 during this voice conference to determine whether it is within a predetermined time (for example, within 15 minutes) from the start of the voice conference, and also determines whether a record 441 of the accessor who designates the main device 3 of the connection request source as a leaving participant is registered in this conference table 440 (S403). If it is within a predetermined time from the start of the voice conference, or if a record 441 of the accessor who designates the main device 3 of the connection request source as a leaving participant is registered in the conference table 440 (YES in S403), it performs the participant addition process described later (S406). If it is after the elapse of a predetermined time from the start of the voice conference and a record 441 of the accessor who designates the main device 3 of the connection request source as a leaving participant is not registered in the conference table 440 (NO in S403), it performs the standby addition process described later (S408).

[0094] FIG. 18 is a flowchart for explaining the voice conference start process S404 shown in FIG. 17.

[0095] First, the relay control unit 43 relays the connection request accompanied by the designation of the special number for the voice conference of the same-site main device 3 received from the VPN processing unit 42 to the same-site main device 3 via the main device interface unit 41 (S4040).

[0096] After that, when the relay control unit 43 receives a connection response from the same-site master device 3 in response to this connection request (YES in S4041), the conference status monitoring unit 45 creates a conference table 440, stores it in the conference table storage unit 44, and registers the current date and time as the voice conference start date and time of this conference table 440 (S4042). Then, the conference status monitoring unit 45 registers a record 441 of the accessor with the same-site master device 3 as the host and a record 441 of the accessor with the master device 3 that is the source of the connection request as a participant in this conference table 440 (S4043).

[0097] Next, the relay control unit 43 passes the connection response received from the same-site master device 3 to the VPN processing unit 42. In response to this, the VPN processing unit 42 relays the connection response to the partner GW4 via the VPN (S4044). After that, the relay control unit 43 starts relaying the voice data exchanged between the same-site master device 3 as the host and the master device 3 that is the source of the connection request as a participant via the VPN established by the VPN processing unit 42 (S4045).

[0098] FIG. 19 is a flowchart for explaining the participant addition process S406 shown in FIG. 17.

[0099] First, the relay control unit 43 adds a participation notice notifying that the master device 3 that is the source of the connection request has participated in the voice conference to the connection request accompanied by the designation of the special number for the voice conference of the same-site master device 3 received from the VPN processing unit 42. Then, the connection request with this participation notice added is relayed to the same-site master device 3 via the master device interface unit 41 (S4060).

[0100] After that, when the relay control unit 43 receives a connection response from the same-site master device 3 in response to this connection request (YES in S4061), the conference status monitoring unit 45 identifies the conference table 440 for the special number for the voice conference (the conference table 440 during the voice conference) specified by the connection request, in which only the start date and time of the voice conference are registered and the end date and time are not registered, from the conference table storage unit 44. If a record 441 of the access person with the master device 3 of the connection request source as a leaving participant is registered in this conference table 440, the attribute of this record 441 is changed from a leaving participant to a participating participant. On the other hand, if a record 441 of the access person with the master device 3 of the connection request source as a leaving participant is not registered, a record 441 of the access person with the master device 3 of the connection request source as a participating participant is added (S4062).

[0101] Next, the relay control unit 43 passes the connection response received from the same-site master device 3 to the VPN processing unit 42. In response to this, the VPN processing unit 42 relays the connection response to the partner GW4 via the VPN (S4063). After that, the relay control unit 43 starts relaying the voice data exchanged between the same-site master device 3 as the organizer and the master device 3 of the connection request source as the participant via the VPN established by the VPN processing unit 42 (S4064).

[0102] FIG. 20 is a flowchart for explaining the standby person addition process S408 shown in FIG. 17.

[0103] First, the relay control unit 43 adds a standby notification informing that the master device 3 of the connection request source is waiting for the next voice conference to the connection request accompanied by the designation of the special number for the voice conference of the same-site master device 3 received from the VPN processing unit 42. Then, the connection request with this standby notification added is relayed to the same-site master device 3 via the master device interface unit 41 (S4080).

[0104] After that, when the relay control unit 43 receives a connection response from the same-site master device 3 in response to this connection request (YES in S4081), the conference status monitoring unit 45 identifies the conference table 440 during the voice conference from the conference table storage unit 44. Then, a record 441 of the accesser with the master device 3 that is the connection request source as the standby person is added to this conference table 440 (S4082).

[0105] Next, the relay control unit 43 adds a standby notification to the connection response received from the same-site master device 3 and passes it to the VPN processing unit 42. In response to this, the VPN processing unit 42 relays the connection response with the standby notification added to the partner GW4 via the VPN (S4083). After that, the relay control unit 43 starts blocking the voice data exchanged between the same-site master device 3 that is the host and the master device 3 that is the connection request source and the standby person via the VPN established by the VPN processing unit 42 (S4084).

[0106] FIG. 21 is a flowchart for explaining the second voice conference master process of GW4.

[0107] This flow starts when the VPN processing unit 42 receives a disconnection request from the partner GW4, which is the transmission source of the connection request accompanied by the designation of the special number for the voice conference of the same-site master device 3, via the VPN.

[0108] First, the VPN processing unit 42 passes the disconnection request received from the partner GW4 to the relay control unit 43. In response to this, the relay control unit 43 relays the disconnection request received from the VPN processing unit 42 to the same-site master device 3 via the master device interface unit 41 (S410).

[0109] After that, if the relay control unit 43 receives a disconnection response from the same-site main device 3 (YES in S411), the conference status monitoring unit 45 identifies the record 441 of the accessor who uses the main device 3 that is the source of the disconnection request as the accessor from the conference table 440 during the voice conference stored in the conference table storage unit 44. If the attribute registered in this accessor's record 441 is a participant, this attribute is changed from a participant to an absentee. If the attribute registered in this accessor's record 441 is a standby person, this record 441 is deleted (S412). Then, the relay control unit 43 passes the disconnection response to the VPN processing unit 42. In response to this, the VPN processing unit 42 relays this disconnection response to the partner GW4 that is the source of the disconnection request via the VPN (S413).

[0110] Next, the VPN processing unit 42 disconnects the VPN established with the partner GW4 that is the source of the disconnection request (S414).

[0111] After that, the conference status monitoring unit 45 refers to the conference table 440 during the voice conference registered in the conference table storage unit 44, and checks whether or not a record 441 of an accessor with the attribute of a participant is registered in this conference table 440, thereby determining whether or not there is a participant in the ongoing voice conference (S415). If there is a participant in the ongoing voice conference (YES in S415), this flow ends.

[0112] On the other hand, when there is no participant in the ongoing voice conference (NO in S415), the conference status monitoring unit 45 determines that the voice conference has ended, and registers the current date and time as the voice conference end date and time in the conference table 440 during the voice conference (S416).

[0113] Next, the conference status monitoring unit 45 determines whether there is a standby participant in the terminated voice conference by checking whether a record 441 of an accesser with the attribute of standby participant is registered in the conference table 440 in which the end date and time of this voice conference is registered (S417). If there is no standby participant in the terminated voice conference (NO in S417), this flow ends. On the other hand, if there is a standby participant in the terminated voice conference (YES in S417), the conference status monitoring unit 45 newly creates a conference table 440, stores it in the conference table storage unit 44, and registers the current date and time as the start date and time of the voice conference in this conference table 440 (S418). Then, the conference status monitoring unit 45 registers in this conference table 440 a record 441 of an accesser with the same-site main device 3 as the host and a record 441 of an accesser with the main device 3, which is the standby participant of the terminated voice conference, as a participant (S419).

[0114] Then, the relay control unit 43 sends a conference start notification notifying that the voice conference has ended at the same-site main device 3 and the next voice conference has started, and passes this conference start notification to the VPN processing unit 42 together with the designation of the participant (former standby participant) who is the transmission destination. In response to this, the VPN processing unit 42 sends this conference start notification to the partner GW4 under the main device 3 of the participant via the VPN (S420). After that, the relay control unit 43 ends the blocking of the voice data exchanged between the same-site main device 3 as the host and the main device 3 as the participant (former standby participant) via the VPN, and starts relaying the voice data exchanged between the two (S421).

[0115] Figure 22 is a flowchart for explaining the third voice conference master process of GW4.

[0116] This flow starts when the notification receiving unit 46 receives a participation permission notification with the designation of the main device 3 as a standby participant from the same-site main device 3 via the main device interface unit 41.

[0117] First, the relay control unit 43 instructs the conference status monitoring unit 45 to change the attributes of the participants of the host device 3 specified in the participation permission notice received by the notification receiving unit 46 from the same-site host device 3. In response to this, the conference status monitoring unit 45 searches the accessor's record 441 with the specified host device 3 as the accessor from the conference table 440 during the voice conference stored in the conference table storage unit 44, and changes the attribute of this accessor's record 441 from standby to participant (S430).

[0118] Next, the relay control unit 43 terminates the blocking of the voice data exchanged between the host device 3 as the host and the host device 3 as the participant (former standby) via the VPN, and starts relaying the voice data exchanged between the two (S431). Then, the relay control unit 43 passes the participation notice with this participant designation to the VPN processing unit 42. In response to this, the VPN processing unit 42 transmits the participation notice to the partner GW4 under the host device 3 of this participant via the VPN (S432).

[0119] Figure 23 is a flowchart for explaining the fourth voice conference master process of GW4.

[0120] This flow starts when the notification receiving unit 46 receives a conference end notification from the same-site host device 3 via the host device interface unit 41.

[0121] First, the conference status monitoring unit 45 determines that the voice conference has ended, and registers the current date and time as the voice conference end date and time in the conference table 440 during the voice conference stored in the conference table storage unit 44 (S440). Then, the conference status monitoring unit 45 checks whether a record 441 of an accessor with the attribute of participant is registered in this conference table 440 (S441). And if a record 441 of an accessor with the attribute of participant is not registered (NO in S441), it further checks whether a record 441 of an accessor with the attribute of standby is registered in this conference table 440 (S442).

[0122] And when a record 441 of an accessor with the attribute of a standby person is registered (YES in S442), the conference status monitoring unit 45 newly creates a conference table 440, stores it in the conference table storage unit 44, and registers the current date and time as the voice conference start date and time of this conference table 440 (S443). Then, the conference status monitoring unit 45 registers in this conference table 440 a record 441 of an accessor with the same base station master device 3 as the host, and a record 441 of an accessor with the main device 3 (old standby person) specified by the record 441 of an accessor with the attribute of a standby person registered in the conference table 440 where the voice conference end date and time was registered in S440 as a participant (S444). After that, it proceeds to S449.

[0123] On the other hand, in S441, when a record 441 of an accessor with the attribute of a participant is registered (YES in S441), the conference status monitoring unit 45 newly creates a conference table 440, stores it in the conference table storage unit 44, and registers the current date and time as the voice conference start date and time of this conference table 440 (S445). Then, the conference status monitoring unit 45 registers in this conference table 440 a record 441 of an accessor with the same base station master device 3 as the host, and a record 441 of an accessor with the main device 3 (old participant) specified by the record 441 of an accessor with the attribute of a participant registered in the conference table 440 where the voice conference has ended as a participant (S446).

[0124] Then, the conference status monitoring unit 45 checks whether a record 441 of an accessor with the attribute of a standby person is registered in the conference table 440 where the voice conference has ended (S447). If a record 441 of an accessor with the attribute of a standby person is registered (YES in S447), the conference status monitoring unit 45 adds a record 441 of an accessor with the main device 3 (old standby person) specified by the record 441 of an accessor with the attribute of a standby person registered in the conference table 440 where the voice conference has ended as a participant to the newly created conference table 440 (S448). After that, it proceeds to S449.

[0125] In S449, the relay control unit 43 starts relaying voice data exchanged between the same-site main device 3 as the organizer and the main devices 3 as participants via the VPN established by the VPN processing unit 42 (S449). Then, the relay control unit 43 transmits a meeting start notification to the partner GW4 via the VPN, respectively, notifying that the voice conference has ended and a new voice conference has started (S450).

[0126] FIG. 24 is a flowchart for explaining the fifth voice conference master process of GW4.

[0127] This flow is started when the notification receiving unit 46 receives an end call notification from the same-site main device 3 via the main device interface unit 41 during a voice conference.

[0128] First, the notification receiving unit 46 passes the end call notification received from the same-site main device 3 to the organizer change request unit 47. In response to this, the organizer change request unit 47 identifies the conference table 440 during the voice conference from the conference table storage unit 44. Then, it changes the attribute of the record 441 of the accessor with the same-site main device 3 as the organizer registered in this conference table 440 from the organizer to the absentee, and registers the current date and time as the voice conference end date and time in this conference table 440 (S460). Then, the organizer change request unit 47 determines the record 441 of the organizer successor from among the records 441 of the accessors registered as participants in this conference table 440 according to a predetermined rule (S461). For example, it determines the record 441 of the accessor with the oldest date and time registered in the field 444 as the record 441 of the organizer successor.

[0129] Next, the organizer change request unit 47 transmits an organizer change request including this conference table 440 to the partner GW4 under the main device 3 specified by the record 441 of the organizer successor via the VPN established by the VPN processing unit 42 (S462). Then, the organizer change request unit 47 extracts all the records 441 of the accessors other than the record 441 of the organizer successor registered as participants or standbyers from this conference table 440. Then, to the partner GW4 under the main device 3 specified by the extracted record 441 of the accessor, a notification of organizer change accompanied by the designation of the main device 3 specified by the record 441 of the organizer successor is transmitted via the VPN established by the VPN processing unit 42 respectively (S463).

[0130] After that, when all the VPNs with all the partner GW4s under the main device 3 specified by the record 441 of the accessor registered as participants or standbyers in this conference table 440 are disconnected by the VPN processing unit 42 (YES in S464), this flow ends.

[0131] Figure 25 is a flowchart for explaining the first voice conference slave process of GW4.

[0132] This flow starts when the relay control unit 43 receives a connection request accompanied by the designation of a special number for the voice conference from the same-site main device 3 via the main device interface unit 41.

[0133] First, the relay control unit 43 passes the connection request received from the same-site main device 3 to the VPN processing unit 42. In response to this, the VPN processing unit 42 transmits a VPN request to the partner GW4 under the main device 3 to which the special number for the voice conference specified in the connection request is assigned via the WAN interface unit 40, performs VPN connection processing with this partner GW4, and establishes a VPN connecting its own GW4 and the partner GW4 on the WAN5 (S500). Then, the VPN processing unit 42 relays the connection request received from the relay control unit 43 to the partner GW4 via the VPN (S501).

[0134] Next, when the VPN processing unit 42 receives a connection response from the partner GW4 via the VPN (YES in S502), it determines whether a waiting notification is added to this connection response (S503). If no waiting notification is added (NO in S503), it passes the connection response to the relay control unit 43. Upon receiving this, the relay control unit 43 relays the connection response to the same-site master device 3 via the main device interface unit 41 (S504). On the other hand, if a waiting notification is added (YES in S503), it passes the connection response together with the waiting notification to the relay control unit 43. Upon receiving this, the relay control unit 43 transmits the connection response and the waiting notification to the same-site master device 3 via the main device interface unit 41 (S505).

[0135] FIG. 26 is a flowchart for explaining the second voice conference slave process of GW4.

[0136] This flow starts when the relay control unit 43 relays a connection request accompanied by the designation of a special number for a voice conference received from the same-site master device 3 to the VPN processing unit 42 and then receives a disconnection request from the same-site master device 3 via the main device interface unit 41.

[0137] First, the relay control unit 43 passes the disconnection request received from the same-site master device 3 to the VPN processing unit 42. Upon receiving this, the VPN processing unit 42 relays the disconnection request received from the relay control unit 43 to the partner GW4 via the VPN (S510).

[0138] Next, when the VPN processing unit 42 receives a disconnection response from the partner GW4 via the VPN (YES in S511), it passes this disconnection response to the relay control unit 43. Then, the relay control unit 43 relays the disconnection response received from the VPN processing unit 42 to the same-site master device 3 via the main device interface unit 41 (S512).

[0139] After that, if the communication via the VPN with the partner GW4 has been interrupted for a predetermined time or longer, the VPN processing unit 42 determines that the call path between the same-site main device 3 and the main device 3 to which the disconnection request is sent has been released (YES in S513), and disconnects the VPN with this partner GW4 (S514).

[0140] FIG. 27 is a flowchart for explaining the third voice conference slave process of GW4.

[0141] This process starts when the VPN processing unit 42 receives various notifications from the partner GW4 via the VPN.

[0142] First, the VPN processing unit 42 checks whether the notification received from the partner GW4 is a host change notification (S520). If it is a host change notification (YES in S520), the VPN processing unit 42 passes this host change notification to the host change notification unit 49. If it is not a host change notification (NO in S520), the VPN processing unit 42 passes this notification (either a conference start notification or a participation notification) to the relay control unit 43.

[0143] When the host change notification unit 49 receives a host change notification from the VPN processing unit 42, the host change notification unit 49 relays this host change notification to the same-site main device 3 via the main device interface unit 41 (S521). Also, when the relay control unit 43 receives a conference start notification or a participation notification from the VPN processing unit 42, the relay control unit 43 relays this conference start notification or participation notification to the same-site main device 3 via the main device interface unit 41 (S522).

[0144] FIGS. 28 and 29 are flowcharts for explaining the fourth voice conference slave process of GW4.

[0145] This process starts when the VPN processing unit 42 receives a host appointment request from the partner GW4 via the VPN.

[0146] First, the VPN processing unit 42 passes the organizer appointment request received from the partner GW4 to the organizer appointment notification unit 48. In response to this, the organizer appointment notification unit 48 passes the organizer appointment response to the VPN processing unit 42 as a reply to the organizer appointment request. The VPN processing unit 42 transmits the organizer appointment response received from the organizer appointment notification unit 48 to the partner GW4, which is the source of the organizer appointment request, via the VPN (S530).

[0147] Next, the organizer appointment notification unit 48 passes the organizer appointment request to the conference status monitoring unit 45. In response to this, the conference status monitoring unit 45 stores the conference table 440 included in the organizer appointment request in the conference table storage unit 44. Then, it changes the special number for the voice conference associated with this conference table 440 to the special number for the voice conference of the same-site main device 3, and changes the attribute registered in the record 441 of the accessor with the same-site main device 3 as the accessor from participant to organizer (S531). Also, the organizer appointment notification unit 48 transmits an organizer appointment notification to the same-site main device 3 via the main device interface unit 41 (S532).

[0148] After that, when the VPN processing unit 42 receives a VPN request from the partner GW4 via the WAN interface unit 40 (YES in S533), it performs VPN connection processing with this partner GW4 and establishes a VPN that connects its own GW4 and the partner GW4 on the WAN5 (S534).

[0149] Then, if the VPN processing unit 42 receives a connection request accompanied by the designation of the special number for the voice conference of the same-site main device 3 from the partner GW4 via the VPN (YES in S535), it passes this connection request to the relay control unit 43. In response to this, the relay control unit 43 identifies the conference table 440 during the voice conference stored in the conference table storage unit 44, identifies the record 441 of the accessor with the main device 3 as the accessor of the connection request source in this conference table 440, and checks the attribute registered in this accessor's record 441 (S536). If this attribute is a participant (participant in S536), it proceeds to S537; if it is a standby person (standby person in S536), it proceeds to S541.

[0150] Next, in S537, the relay control unit 43 adds a participation notice notifying that the connection request source has joined the voice conference to the connection request accompanied by the designation of the special number for the voice conference of the same-site main device 3 received from the VPN processing unit 42. Then, the connection request with this participation notice added is relayed to the same-site main device 3 via the main device interface unit 41.

[0151] Thereafter, when the relay control unit 43 receives a connection response from the same-site main device 3 for this connection request (YES in S538), it passes this connection response to the VPN processing unit 42. In response to this, the VPN processing unit 42 relays the connection response to the partner GW4 via the VPN (S539). Then, the relay control unit 43 starts relaying the voice data exchanged between the same-site main device 3 as the organizer and the main device 3 of the connection request source as the participant via the VPN established by the VPN processing unit 42 (S540). Then, it proceeds to S545.

[0152] Also, in S541, the relay control unit 43 adds a standby notice notifying that the connection request source is waiting for the next upcoming voice conference to the connection request accompanied by the designation of the special number for the voice conference of the same-site main device 3 received from the VPN processing unit 42. Then, the connection request with this standby notice added is relayed to the same-site main device 3 via the main device interface unit 41.

[0153] Thereafter, when the relay control unit 43 receives a connection response from the same-site main device 3 for this connection request (YES in S542), it adds a standby notice to this connection response and passes it to the VPN processing unit 42. In response to this, the VPN processing unit 42 relays the connection response with the standby notice added to the partner GW4 via the VPN (S543). Thereafter, the relay control unit 43 starts blocking the voice data exchanged between the same-site main device 3 as the organizer and the main device 3 of the connection request source as the standby via the VPN established by the VPN processing unit 42 (S544). Then, it proceeds to S545.

[0154] In S545, the relay control unit 43 checks, in the conference table 440 during the voice conference stored in the conference table storage unit 44, whether connection requests have been received from all the master devices 3 specified by the record 441 of the accessor whose attribute is a participant or a standby. If connection requests have not been received from all the master devices 3 specified by the record 441 of the accessor whose attribute is a participant or a standby (NO in S545), it returns to S533. If connection requests have been received (YES in S545), this flow ends.

[0155] Next, the details of the master device 3 will be described.

[0156] FIG. 30 is a schematic functional configuration diagram of the master device 3.

[0157] As shown in the figure, the master device 1 includes a telephone interface unit 30, a GW interface unit 31, a call control unit 32, a relay unit 33, a voice conference control unit 34, a notification processing unit 35, and a call end notification unit 36.

[0158] The telephone interface unit 30 is an interface for connecting to the telephone 2. The GW interface unit 31 is an interface for connecting to the GW 4.

[0159] The call control unit 32 performs call control processing in cooperation with the telephone 2 (hereinafter referred to as the accommodated telephone 2) accommodated by itself and another master device 3 (hereinafter referred to as the partner master device 3) which is the communication partner according to a call control protocol such as SIP (Session Initiation Protocol), and establishes and releases a call path with the accommodated telephone 2 and the partner master device 3.

[0160] The relay unit 33 relays between the call paths established by the call control unit 32 according to a transmission protocol such as RTP (Real-time Transport Protocol). Thereby, a call between the accommodated telephone 2 and the telephone 2 accommodated in the partner master device 3 becomes possible.

[0161] The voice conference control unit 34 cooperates with the relay unit 33, and for each of the call paths with the housed telephone 2 and the call path with the host device 3 that has called the special number for voice conference of the autonomous device 3, generates conference voice data using the voice data received via each call path other than the target call path, and transmits this conference voice data to the target call path. Thereby, a voice conference is conducted.

[0162] The notification processing unit 35 transmits the notifications (participation permission notification, conference end notification) received from the housed telephone 2 to the GW 4 at the same site as the autonomous device 3 (hereinafter referred to as the same-site GW 4), and also transmits various notifications (participation permission notification, conference start notification) received from the same-site GW 4 to the housed telephone 2.

[0163] When the call end notification unit 36 receives a disconnection request from the housed telephone 2 during the voice conference by the voice conference control unit 34, it transmits a call end notification to the same-site GW 4.

[0164] Note that the functional configuration of the host device 3 shown in FIG. 30 is realized either hard by an integrated logic IC such as an ASIC or FPGA, or soft by a computer such as a DSP, similar to the functional configuration of the GW 4 shown in FIG. 15. Alternatively, in a general-purpose computer such as a PC equipped with a CPU, a memory, an auxiliary storage device such as a hard disk and a flash memory, and a communication interface such as a NIC and a wireless adapter, the CPU loads a predetermined program from the auxiliary storage device onto the memory and executes it, thereby realizing it as a process.

[0165] FIG. 31 is a flowchart for explaining the first voice conference master process of the host device 3.

[0166] This flow starts when the call control unit 32 receives a connection request accompanied by the designation of the special number for voice conference of the autonomous device 3 from the same-site GW 4 via the GW interface unit 31 (however, excluding the execution of the host appointment process S673 shown in FIG. 37).

[0167] First, the call control unit 32 checks whether it is in a voice conference by the voice conference control unit 34 (S600). If it is in a voice conference (YES in S600), it proceeds to S606. If it is not in a voice conference (NO in S600), it proceeds to S601.

[0168] In S601, the call control unit 32 transmits an incoming call notification to the housed telephone 2 via the telephone interface unit 30 to notify it of an incoming call to the special number for the voice conference of the self - device 3 (S601). Then, if a response signal is received from the housed telephone 2 (YES in S602), it transmits a connection response to the same - site GW4 via the GW interface unit 31 with the partner main device 3, which is the connection request source, as the destination (S603). Thereby, a communication path is established between each of the housed telephone 2 and the partner main device 3 (S604).

[0169] Thereafter, the voice conference control unit 34, in cooperation with the relay unit 33, starts a voice conference for the housed telephone 2 and the partner main device 3, which is the connection request source (S605). Specifically, the relay unit 33 connects each of the communication paths with the housed telephone 2 and the communication path with the partner main device to the voice conference control unit 34. The voice conference control unit 34 transmits the voice data received from the communication path with the housed telephone 2 as conference voice data to the communication path with the partner main device 3, and transmits the voice data received from the communication path with the partner main device 3 as conference voice data to the communication path with the housed telephone 2.

[0170] Also, in S606, the call control unit 32 determines whether a notification (either a participation notification or a standby notification) is added to the connection request (S606). If a notification is added to the connection request (YES in S606), the notification added to this connection request is transmitted to the accommodated telephone 2 via the telephone interface unit 30 (S607). Then, a connection response addressed to the counterpart master device 3 which is the connection request source is transmitted to the same-site GW4 via the GW interface unit 31 (S608). On the other hand, if no notification is added to the connection request (NO in S606), a connection response addressed to the counterpart master device 3 which is the connection request source is immediately transmitted to the same-site GW4 via the GW interface unit 31 (S608). Thereby, a call path is established with the counterpart master device 3 (S609).

[0171] Thereafter, the voice conference control unit 34, in cooperation with the relay unit 33, adds the counterpart master device 3 for which a new call path has been established to the voice conference (S610). Specifically, the relay unit 33 connects the call path with the newly established counterpart master device to the voice conference control unit 34. For each of the call paths connected to itself, the voice conference control unit 34 mixes the voice data received from each call path other than the target call path to generate conference voice data, and transmits this conference voice data to the target call path.

[0172] FIG. 32 is a flowchart for explaining the second voice conference master process of the master device 3.

[0173] This flow is started when the call control unit 32 receives a disconnection request from the counterpart master device 3 participating in the voice conference via the GW interface unit 31 during the voice conference by the voice conference control unit 34.

[0174] First, the call control unit 32 transmits a withdrawal notice to the housed telephone 2 via the telephone interface unit 30 to notify the withdrawal of the source of the disconnection request from the voice conference of the counterpart main device 3 (S620), and transmits a disconnection response addressed to the counterpart main device 3, which is the source of the disconnection request, to the same-site GW 4 via the GW interface unit 31 (S621). Thereby, the communication path with the counterpart main device 3, which is the source of the disconnection request, is released (S622), and the counterpart main device 3, which is the source of the disconnection request, is removed from the voice conference (S623).

[0175] FIG. 33 is a flowchart for explaining the third voice conference master process of the main device 3.

[0176] This flow is executed during the voice conference by the voice conference control unit 34.

[0177] When the notification processing unit 35 receives a participation permission notice from the housed telephone 2 via the telephone interface unit 30 (YES in S630), it relays this participation permission notice to the same-site GW 4 via the GW interface unit 31 (S631).

[0178] Also, when the notification processing unit 35 receives a conference end notice from the housed telephone 2 via the telephone interface unit 30 (YES in S632), it relays this conference end notice to the same-site GW 4 via the GW interface unit 31 (S633).

[0179] FIG. 34 is a flowchart for explaining the fourth voice conference master process of the main device 3.

[0180] This flow is started when the call control unit 32 receives an end call signal from the housed telephone 2 via the telephone interface unit 30 during the voice conference by the voice conference control unit 34.

[0181] First, the call control unit 32 instructs the end call notification unit 36 to transmit an end call notification. In response to this, the end call notification unit 36 transmits an end call notification to the same-site GW 4 via the GW interface unit 31 (S640).

[0182] Then, the call control unit 32 waits until the call path connected to the voice conference control unit 34 via the relay unit 33 becomes only the call path with the housed telephone 2 (YES in S641), and then releases the call path with the housed telephone 2 (S642).

[0183] FIG. 35 is a flowchart for explaining the first voice conference slave process of the main device 3.

[0184] This flow starts when the call control unit 32 receives a call for a special number for voice conference assigned to another main device 3 from the housed telephone 2 via the telephone interface unit 30.

[0185] First, the call control unit 32 transmits a connection request with the designation of this special number for voice conference to the same-site GW4 via the GW interface unit 31 (S650). Then, when the call control unit 32 receives a connection response to this connection request from the same-site GW4 (YES in S651), it checks whether a standby notification is added to this connection request (S652). If a standby notification is added (YES in S652), it transmits this standby notification to the housed telephone 2 via the telephone interface unit 30 (S653). Then, a call path is established between each of the housed telephone 2 and the main device 3 (the main device 3 hosting the voice conference) that is the connection request destination (S654). On the other hand, if a standby notification is not added (NO in S652), a call path is immediately established between each of the housed telephone 2 and the main device 3 that is the connection request destination (S654).

[0186] Next, the relay unit 33 starts relaying the voice data exchanged between the call path with the housed telephone 2 and the call path with the main device 3 that is the connection request destination (S655).

[0187] After that, when the call control unit 32 receives an end call signal from the accommodated telephone 2 via the telephone interface unit 30 (YES in S656), it transmits a disconnection request for the call path to the main device 3 of the connection destination to the same-site GW4 via the GW interface unit 31 (S657). Then, when it receives a disconnection response from the same-site GW4 via the GW interface unit 31 (YES in S658), it releases the call path to the main device 3 of the connection destination (S659). As a result, the relay unit 33 ends the relay of the voice data exchanged between the call path with the accommodated telephone 2 and the call path with the main device 3 of the connection destination (S660).

[0188] FIG. 36 is a flowchart for explaining the second voice conference slave process of the main device 3.

[0189] This flow is started when the notification processing unit 35 receives a notification from the same-site GW4 via the GW interface unit 31 during the relay of the voice data exchanged between the call path with the accommodated telephone 2 and the call path with the main device 3 (the main device 3 that hosts the voice conference) by the relay unit 33.

[0190] First, the notification processing unit 35 analyzes the notification received from the same-site GW4 (S670). If this notification is a conference start notification (conference start notification in S670), it relays this conference start notification to the accommodated telephone 2 via the telephone interface unit 30 (S671). If this notification is a participation notification (participation notification in S670), it relays this participation notification to the accommodated telephone 2 via the telephone interface unit 30 (S672). If this notification is a host appointment notification (host appointment notification in S670), it performs the host appointment process described later (S673), and if it is a host change notification (host change notification in S670), it performs the host change process described later (S674).

[0191] FIG. 37 is a flowchart for explaining the host appointment process S673 shown in FIG. 36.

[0192] First, the call control unit 32 releases the relay between the communication path with the housed telephone 2 by the relay unit 33 and the communication path with the host device 3 (the host device 3 that hosts the voice conference) of the connection request destination, and holds the communication path with the housed telephone 2 (S6730). Then, it transmits a disconnection request for the communication path with the host device 3 of the connection request destination to the same-site GW4 via the GW interface unit 31 (S6731).

[0193] Next, if the call control unit 32 receives a disconnection response from the same-site GW4 via the GW interface unit 31 (YES in S6732), it releases the communication path with the host device 3 of the connection request destination (S6733).

[0194] After that, when the call control unit 32 receives a connection request accompanied by the designation of the special number for the voice conference of the host device 3 from the same-site GW4 via the GW interface unit 31 (YES in S6734), it transmits a connection response addressed to the partner host device 3, which is the connection request source, to the same-site GW4 via the GW interface unit 31 (S6735). Thereby, a communication path is established with the partner host device 3 (S6736).

[0195] Next, the call control unit 32 releases the hold of the communication path with the housed telephone 2. Then, the voice conference control unit 34 starts a voice conference with the housed telephone 2 and the partner host device 3, which is the connection request source, in cooperation with the relay unit 33 (S6737).

[0196] FIG. 38 is a flowchart for explaining the host change process S674 shown in FIG. 36.

[0197] First, the call control unit 32 releases the relay between the communication path with the housed telephone 2 by the relay unit 33 and the communication path with the host device 3 (the host device 3 that hosts the voice conference) of the connection request destination, and holds the communication path with the housed telephone 2 (S6740). Then, it transmits a disconnection request for the communication path with the host device 3 of the connection request destination to the same-site GW4 via the GW interface unit 31 (S6741).

[0198] Next, if the call control unit 32 receives a disconnection response from the same-site GW 4 via the GW interface unit 31 (YES in S6742), it releases the call path with the host device 3 of the connection request destination (S6743). Then, the call control unit 32 transmits a connection request with the designation of the special number for the voice conference of the host device 3, which is the host successor designated in the host change notification, to the same-site GW 4 via the GW interface unit 31 (S6744).

[0199] After that, if the call control unit 32 receives a connection response to the connection request from the same-site GW 4 via the GW interface unit 31 (YES in S6745), it establishes a call path with the host device 3 of the connection request destination (S6746).

[0200] Next, the call control unit 32 releases the hold of the call path with the housed telephone 2. Then, the relay unit 33 starts relaying the voice data exchanged between the call path with the housed telephone 2 and the call path with the host device 3 of the connection request destination (S6747).

[0201] The above describes one embodiment of the present invention.

[0202] In this embodiment, when a connection request with the special number for the voice conference as the call destination arrives at the host device 3 after a predetermined time has elapsed since the start of the voice conference, the same-site GW 4 cuts off the transmission and reception of voice data via the call path established between this host device 3 and the partner host device 3 which is the connection request source. Therefore, according to this embodiment, in the case where a plurality of voice conferences are successively carried out for the same special number for the voice conference, it is possible to prevent the participants in the next voice conference from speaking in the ongoing voice conference.

[0203] Also, in the present embodiment, when the transmission and reception of voice data between the same-site main device 3, which is the host of the voice conference, and the other-party main device 3 are blocked, GW4 transmits a standby notification with the designation of the other-party main device 3 to the same-site main device 3. The main device 3 relays the standby notification received from the same-site GW4 to the accommodation telephone 2, and when a participation permission notification is received from the accommodation telephone 2 in response to this standby notification, it transmits this participation permission notification to the same-site GW4. Then, if GW4 receives the participation permission notification from the same-site main device 3, it releases the block on the transmission and reception of voice data between the same-site main device 3 and the other-party main device 3. Therefore, according to the present embodiment, even a standby person whose speech in the voice conference is prevented can be changed to a participant whose speech in the voice conference is permitted in accordance with an instruction from the accommodation telephone 2 of the main device 3, which is the host.

[0204] Also, in the present embodiment, when the main device 3 receives a conference end notification from the accommodation telephone 2, it transmits this conference end notification to the same-site GW4. When GW4 receives the conference end notification from the same-site main device 3 during the voice conference, even if not all the call paths between the same-site main device 3 and the main devices 3 other than the connection requester whose transmission and reception of voice data are blocked are released, it determines that the voice conference has ended and the next voice conference has started. Thereby, according to the present embodiment, in accordance with an instruction from the accommodation telephone 2 of the main device 3, which is the host, the end of the voice conference and the start of the subsequent voice conference can be adjusted.

[0205] Also, in the present embodiment, even when GW4 relays a connection request to the dedicated number for the voice conference of the main device 3 at the same site via the VPN after a predetermined time has elapsed since the start of the voice conference, if the connection request source is registered in the conference table 440 as an absentee, that is, if the communication path with the connection request source has been released after the start of this voice conference, it relays the voice data transmission and reception between the connection request source and the main device 3 at the same site without interruption. Therefore, according to the present embodiment, for example, when a participant who has left the voice conference rejoins the voice conference, even if it is after a predetermined time has elapsed since the start of the voice conference, the participant can join the voice conference without being prevented from speaking.

[0206] Also, in the present embodiment, when the main device 3 receives an end call signal from the housed telephone 2 during the voice conference, it transmits an end call notification to the GW4 at the same site. Further, when the main device 3 receives a host appointment notification from the GW4 at the same site while participating in a voice conference hosted by the main device 3 that is the connection request destination, it releases the communication path with this connection request destination main device 3, and when it receives a host change notification from the GW4 at the same site, it releases the communication path with this connection request destination main device 3 and transmits a connection request to the dedicated number for the voice conference of the main device 3 of the host successor designated in this host change notification as the call destination to establish a communication path. Also, when GW4 receives an end call notification from the main device 3 at the same site, it determines a host successor from among the participants in the voice conference, transmits a host change request to the GW4 at the same site of this host successor, and transmits a host change notification to each of the GW4s at the same site of the participants and standby persons other than the host successor in the voice conference. Further, when GW4 receives a host change request from the other GW4, it transmits a host appointment notification to the main device 3 at the same site, and when it receives a host change notification from the other GW4, it relays this host change notification to the main device 3 at the same site. Thereby, the change of the host of the voice conference can be smoothly performed.

[0207] Note that the present invention is not limited to the above-described embodiment, and numerous modifications are possible within the scope of the gist thereof.

[0208] For example, in the above embodiment, the telephone 2 may be a wireless telephone terminal such as a smartphone or a mobile phone. Further, the main device 3 and the gateway 4 may be constructed on the same computer system.

Explanation of Signs

[0209] 1a~1d: Voice conference system 2a~2d: Telephone 3, 3a~3d: Main device 4, 4a~4d: GW 5: WAN 30: Telephone interface section 31: GW interface section 32: Call control section 33: Relay section 34: Voice conference control section 35: Notification processing section 36: Call end notification section 40: WAN interface section 41: Main device interface section 42: VPN processing section 43: Relay control section 44: Conference table storage section 45: Conference status monitoring section 46: Notification receiving section 47: Organizer change request section 48: Organizer appointment notification section 49: Organizer change notification section

Claims

1. An audio conferencing system comprising a main device for accommodating a telephone set and a gateway for connecting the main device to a network, wherein the main device, has audio conferencing control means for transmitting conference audio data to each of the transmission source of the connection request received for the special number for audio conferencing assigned to itself and the telephone set based on the audio data received from the communication path with the transmission source of the connection request and the communication path with the telephone set, wherein the gateway, has conference status monitoring means for monitoring the status of the audio conference of the main device, and relay control means for controlling the relay of audio data between the transmission source of the connection request destined for the special number for audio conferencing and the main device, wherein the relay control means, when it is confirmed by the conference status monitoring means that the audio conference has started, if it relays a connection request destined for the special number for audio conferencing from the network to the main device after a predetermined time has elapsed since the start of the audio conference, it cuts off the transmission and reception of audio data between the transmission source of the connection request and the main device, and if it is confirmed by the conference status monitoring means that the audio conference has ended, it releases the cut-off of the transmission and reception of the audio data, wherein the conference status monitoring means, when a connection request destined for the special number for audio conferencing is relayed from the network to the main device in a state where no communication path is established between the transmission source of the connection request and the main device, determines that the audio conference has started, when all the communication paths between the transmission source of the connection request destined for the special number for audio conferencing and the main device, excluding the transmission source of the connection request for which the transmission and reception of audio data have been cut off by the relay control means, are released, determines that the audio conference has ended and the next audio conference has started An audio conferencing system characterized by the above.

2. The audio conferencing system according to claim 1, wherein the relay control means, when the transmission and reception of audio data between the transmission source of the connection request destined for the special number for audio conferencing and the main device are cut off, transmits a standby notification with the designation of the transmission source of the connection request to the main device, wherein the main device, further has participation permission notification means for transmitting the standby notification received from the gateway to the telephone set and, when a participation permission notification is received from the telephone set for the standby notification, transmitting the participation permission notification to the gateway, wherein the relay control means, When the transmission and reception of audio data between the source of a connection request targeting the special number for the audio conference and the master device are blocked, if the master device receives the participation permission notification, the blocking of the transmission and reception of the audio data is released. An audio conference system characterized by this.

3. The audio conference system according to claim 1, wherein the master device further has a conference end notification means for transmitting the conference end notification received from the telephone to the gateway, and the conference status monitoring means when receiving the conference end notification from the master device during the implementation of the audio conference, even if not all the communication paths between the source of the connection request targeting the special number for the audio conference (excluding the source of the connection request whose transmission and reception of audio data are blocked by the relay control means) and the master device are released, determines that the audio conference has ended and the next audio conference has started. An audio conference system characterized by this.

4. The audio conference system according to claim 1, wherein the relay control means even when relaying a connection request targeting the special number for the audio conference from the network to the master device after a predetermined time has elapsed since the start of the audio conference, if the communication path between the source of the connection request and the master device has been released after the start of the audio conference, relays without blocking the transmission and reception of audio data between the source of the connection request and the master device. An audio conference system characterized by this.

5. The audio conference system according to any one of claims 1 to 4, wherein the master device has a call end notification means for transmitting a call end notification to the gateway when receiving a call end signal from the telephone while transmitting conference audio data to each of the source of the connection request that has received the connection request destined for the special number for the audio conference by the audio conference control means and the telephone, and a call control means for releasing the communication path when receiving a host appointment notification from the gateway during the establishment of a communication path for the special number for the audio conference of another master device, and for releasing the communication path and transmitting a connection request targeting the special number for the audio conference of another master device specified in the host change notification as the destination to establish a communication path when receiving a host change notification from the gateway. The gateway is When receiving the end call notification from the main device, it determines a host successor from among the participants in the voice conference, transmits a host change request to the gateway of the host successor, and transmits the host change notification to the gateway of each of the participants in the voice conference other than the host successor; a host change request means; When receiving the host change request from another gateway, a host appointment notification means for transmitting the host appointment notification to the main device; When receiving the host change notification from another gateway, it further has a host change notification means for relaying the host change notification to the main device. A voice conference system characterized by the above.

6. A gateway connecting a main device having voice conference control means for transmitting conference voice data to each of the transmission source of a connection request received for a special number for voice conference assigned to itself and a telephone accommodated by itself based on voice data received from a call path with the transmission source of the connection request and a call path with the telephone accommodated by itself to a network, Conference status monitoring means for monitoring the implementation status of the voice conference of the main device; Relay control means for controlling the relay of voice data between the transmission source of a connection request having the special number for voice conference as the destination and the main device, and having The relay control means, When it is confirmed by the conference status monitoring means that the voice conference has started, if it relays a connection request having the special number for voice conference as the destination from the network to the main device after a predetermined time has elapsed since the start of the voice conference, it cuts off the transmission and reception of voice data between the transmission source of the connection request and the main device, and if it is confirmed by the conference status monitoring means that the voice conference has ended, it releases the cut-off of the transmission and reception of the voice data. The conference status monitoring means, In a state where no call path is established between the transmission source of a connection request having the special number for voice conference as the destination and the main device, when it relays a connection request having the special number for voice conference as the destination from the network to the main device, it determines that the voice conference has started. When all the call paths between the transmission source of a connection request having the special number for voice conference as the destination and the main device, excluding the transmission source of a connection request for which the transmission and reception of voice data have been cut off by the relay control means, are released, it determines that the voice conference has ended and the next voice conference has started. A gateway characterized by the above.

7. A main device connected to a network via a gateway, Based on the voice data received from the call path with the sender of the connection request received for the dedicated number for voice conferencing assigned to itself and the call path with the telephone accommodated in itself, voice conferencing control means for transmitting conference voice data to each of the sender of the connection request and the telephone; End call notification means for transmitting an end call notification to the gateway when an end call signal is received from the telephone while conference voice data is being transmitted to each of the sender of the connection request received for the dedicated number for voice conferencing by the voice conferencing control means and the telephone; When receiving a host appointment notification from the gateway during establishing a call path for the dedicated number for voice conferencing of another main device, releasing the call path, and when receiving a host change notification from the gateway, releasing the call path and transmitting a connection request targeting the dedicated number for voice conferencing of the other main device specified in the host change notification to establish a call path, a call control means having A main device characterized by the above.

8. A program for causing a computer to function as a gateway for connecting to a network a main device having voice conferencing control means for transmitting conference voice data to each of the sender of the connection request and the telephone based on the voice data received from the call path with the sender of the connection request received for the dedicated number for voice conferencing assigned to itself and the call path with the telephone accommodated in itself, Conference status monitoring means for monitoring the implementation status of the voice conference of the main device, and Causing the computer to function as relay control means for controlling the relay of voice data between the sender of the connection request targeting the dedicated number for voice conferencing and the main device, The relay control means When it is confirmed by the conference status monitoring means that the voice conference has started, if a connection request targeting the dedicated number for voice conferencing is relayed from the network to the main device after a predetermined time has elapsed since the start of the voice conference, blocking the transmission and reception of voice data between the sender of the connection request and the main device, and if it is confirmed by the conference status monitoring means that the voice conference has ended, releasing the blocking of the transmission and reception of the voice data, The conference status monitoring means When a connection request with the special number for the voice conference as the destination is relayed from the network to the master device in a state where no call path is established between the source of the connection request with the special number for the voice conference as the destination and the master device, it is determined that the voice conference has started. When all the call paths between the source of the connection request with the special number for the voice conference as the destination, excluding the source of the connection request for which the transmission and reception of voice data is blocked by the relay control means, and the master device are released, it is determined that the voice conference has ended and the next voice conference has started. A program characterized by the above.

9. A program that causes a computer to function as a master device connected to a network via a gateway, Voice conference control means for transmitting conference voice data to each of the source of the connection request and the telephone based on the voice data received from the call path between the source of the connection request received for the special number for the voice conference assigned to the master device and the master device and the call path between the master device and the telephone accommodated in the master device, End call notification means for transmitting an end call notification to the gateway when an end call signal is received from the telephone while the conference voice data is being transmitted to each of the source of the connection request received for the special number for the voice conference and the telephone by the voice conference control means, and When a host appointment notification is received from the gateway while establishing a call path for the special number for the voice conference of another master device, the call path is released, and when a host change notification is received from the gateway, the call path is released and a connection request with the special number for the voice conference of the other master device specified in the host change notification as the destination is transmitted to establish a call path. The computer is made to function as call control means. A program characterized by the above.

10. A method for controlling a telephone conference in a voice conference system including a master device that houses a telephone and a gateway that connects the master device to a network, The master device: Transmits conference voice data to each of the source of the connection request and the telephone based on the voice data received from the call path between the source of the connection request received for the special number for the voice conference assigned to itself and the master device and the call path between the master device and the telephone. The gateway: When a call path has not been established between the transmission source of a connection request destined for the special number for the voice conference and the master device, and the network relays a connection request destined for the special number for the voice conference from the network to the master device, it is determined that the voice conference has started. When all the call paths between the transmission source of the connection request destined for the special number for the voice conference, excluding the transmission source of the connection request for which voice data transmission / reception is blocked, and the master device are released, it is determined that the voice conference has ended and the next voice conference has started. When it is confirmed that the voice conference has started, if a connection request destined for the special number for the voice conference is relayed from the network to the master device after a predetermined time has elapsed since the start of the voice conference, the transmission / reception of voice data between the transmission source of the connection request and the master device is blocked. When it is confirmed that the voice conference has ended, the blocking of the transmission / reception of the voice data is released. A method for controlling a telephone conference, characterized by the above.

Images