 |
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention pertains to a teleconference system featuring a call-up. It
can realize, without negatively affecting the efficiency of an existing
exchange, a function of registering the participants and the date and time
of a teleconference; a function of automatically notifying an invitation
to, a cancellation of, an absence from and a status confirmation of a
teleconference; and a function of automatically holding a teleconference
by calling up the participants for an online connection at a specified
time on a designated date.
2. Description of the Related Arts
With the advancement and furtherance of telephone services, a
teleconference service has currently been put into use. A conventional
teleconference service uses a teleconference starting system by which a
call originating user personally calls up the participants in sequence for
having them connected online.
However, such a system has a problem of functional complication, because it
requires the call originating user to call up all the participants one by
one at the specified time on the designated date.
To overcome this problem, a system has been invented for automatically
setting the communications paths of a teleconference, such that a call
originating user registers in a teleconference system in an exchange, the
participants and the date and time of a teleconference, so that the
teleconference system calls up the participants on the date and time of
the teleconference. (Refer to Japanese Patent Application Circulars (A)
No. 1988-244961 and No. 1989-264464.)
The invention described in Japanese Patent Application Circular (A) No.
1988-244961 purports to enable the participants to be automatically
connected online on the registered time of date, by having an automatic
private branch exchange realize a function of storing the date and time of
a teleconference run and automatically calling up the telephone sets of
the participants on the date and time of a teleconference run, a function
of automatically connecting the lines from the telephone sets of the
responding ones of the participants to the teleconference communications
paths, and a function of enabling the mutual communications among the
participants.
The invention described in Japanese Patent Application Circular (A) No.
1989-264464 comprises a teleconference sponsor's telephone set having a
monitor for displaying data from the exchange and a voice storer connected
to a main communications path switch of the exchange, in addition to
having the above functions. This connects the participants to be
automatically called up at the time and date of a teleconference run, the
message recorded by the teleconference sponsor in the voice storer to be
sent to the responding ones of the participants, and the status data of
the responding ones of the participants to be displayed on the telephone
set having a monitor.
As described above, the conventional systems cause the exchange to have the
function for storing the data on the participants and the date and time of
a teleconference run and the function for automatically connecting the
participants online on the date and time of the teleconference run.
Because an exchange must realize these functions in addition to its
indigenous functions, a potential problem exists that the exchange may
become less efficient in executing its basic jobs.
In addition, the conventional systems require a process for having a
subscriber who will be absent inform the teleconference sponsor of his
absence, thereby having the teleconference sponsor eliminate the name of
the nonparticipating subscriber from the participants' name list
registered in the exchange. Also, because his absence cannot be notified
in a batch to other participants, the subscriber who will be absent must
inform each of the attending participants of his absence either directly
in person or indirectly via the teleconference sponsor.
SUMMARY OF THE INVENTION
This invention aims at enabling an exchange to automatically hold a
teleconference at the specified time on the designated date by reserving a
teleconference run, realizing an efficient teleconference service by
issuing an absence notice in a batch to all other participants when a
scheduled participant cannot attend the teleconference, and developing a
system void of efficiency deterioration caused by a functional
complication of a conventional exchange by these services.
This invention is premised on an exchange comprising a switching matrix, a
VRE (Voice Response Equipment) unit having a recording function, and a
call processing unit, in addition to a SCP (Service Control Point) for
executing IN (Intelligent Network) services such as a teleconference
service provided outside of the exchange.
The SCP comprises a teleconference registerer for registering in its
internal database teleconference data (the participants' names and the
date and time of the teleconference run) dictated by a terminal (used by
the teleconference sponsor) connected to the exchange, for answering the
inquiry from a teleconference participant about the specifics of the
teleconference by reading the pertinent data from the database, and for
deleting from the database the name of a participant absenting the
teleconference after notifying the attending participants of his/her
absence.
The SCP also comprises a teleconference executor for running a
teleconference by connecting their lines after calling up each of the
attending participants on the date and time of the teleconference run
registered in the database.
The SCP further comprises a SCP controller for controlling the
teleconference registerer and the teleconference executor and for
interchanging instructions with the exchange as its interface.
On receipt of a request (a request for reserving a teleconference, a
request for confirming the teleconference status or a request for
notifying an absence from a teleconference) from any among the group of
terminals, sent via the exchange, the SCP controller invokes a
teleconference reservation notifier, a teleconference status confirmer and
a teleconference absence notifier (described later). Also, the SCP
controller invokes the teleconference executor on the date and time of the
teleconference registered in the database.
Finally, the exchange comprises an IN call processor for processing the
interface between the exchange and the SCP by performing a mutual
conversion between an instruction of the conventional exchange, and an IN
message of the SCP. Because the exchange is a conventional exchange, it
cannot process an IN message used by the SCP. Therefore, the IN call
processor replaces an IN message received from the SCP with an instruction
processable by the exchange and sends an instruction from the exchange to
the SCP by converting it to an IN message.
The teleconference registerer may be formed by three parts explained in the
above description of the configuration of this invention. More
specifically, the teleconference registerer comprises the teleconference
reservation notifier for registering the participants and the date and
time of a teleconference run, the teleconference status confirmer for
responding to a participant's request for teleconference data, and the
teleconference absence notifier for allowing the absence of an absenting
subscriber to be notified.
The teleconference reservation notifier registers the participants' names
and the date and time of a teleconference run in a database, notifies
respective participants of a teleconference run, records in the VRE unit a
teleconference sponsor's voice message, and then sends respective
participants the teleconference sponsor's voice message which has been
recorded in the VRE unit. In the event of a teleconference cancellation,
the teleconference reservation notifier notifies respective participants
of the teleconference cancellation on receiving a cancellation request
from the teleconference sponsor, and deletes the teleconference data from
the database.
The teleconference status confirmer notifies the teleconference sponsor or
a teleconference participant e.g. of the date and time of a teleconference
run, in response to an inquiry. A user can obtain the teleconference data
by specifying a teleconference ID.
The teleconference absence notifier notifies other teleconference
participants of a subscriber's absence from the teleconference and deletes
his name from the database, on receiving an absentee's request for an
absence notification.
The structure of this invention thus described enables a teleconference run
to be automatically notified to all participants by reserving in advance
the teleconference run. It also enables the exchange to automatically
connect the teleconference participants online at the specified time on
the designated date of the teleconference run, thereby actually holding a
teleconference.
Furthermore, it enables a teleconference cancellation to be automatically
notified to all teleconference participants by canceling the reservation
of a scheduled teleconference.
Additionally, it enables the teleconference participants to obtain the
pertinent teleconference data at their convenience. Moreover, it enables a
subscriber's absence to be automatically notified to the teleconference
sponsor and other teleconference participants, when the an absenting
subscriber notifies the system of his absense.
Lastly, it does not negatively effect a conventional exchange due to a
functional complication, because the SCP (Service Control Point) provided
outside of the exchange performs the processes.
BRIEF DESCRIPTION OF THE DRAWINGS
One of skill in the art can easily understand additional features and
objects of this invention from the description of the preferred
embodiments and some of the attached drawings. In the drawings:
FIG. 1 is a block diagram of this invention;
FIG. 2 shows the system configuration of a preferred embodiment of this
invention;
FIG. 3 is a flowchart showing the operations of a teleconference service;
FIGS. 4A, 4B and 4C illustrate a VRE (Voice Response Equipment) control
system;
FIG. 5 shows the sequence of a teleconference registration process;
FIG. 6 shows the sequence of a teleconference run notification process;
FIG. 7 shows the sequence of a teleconference absence notification process;
FIG. 8 shows the sequence of a teleconference cancellation process;
FIG. 9 shows the sequence of a teleconference status confirmation process;
and
FIG. 10 shows the sequence of a teleconference run process.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Explanation of the Underlying Principles
FIG. 1 is a block diagram of this invention.
This invention is premised on an exchange 1 comprising a switching matrix
2, a VRE (Voice Response Equipment) unit 3 having a recording function,
and a call processing unit 4, in addition to a SCP (Service Control Point)
6 for executing various kinds of services including a teleconference
service.
A teleconference registerer 7 provided in the SCP 6 comprises a
teleconference reservation notifier, a teleconference status confirmer and
a teleconference absence notifier.
The teleconference reservation notifier registers in a database, the
participants's names and the date and time of a teleconference run
dictated by a terminal (used by a teleconference sponsor) among the group
of terminals 5. It also notifies respective teleconference participants of
a teleconference run, has the VRE unit 3 record voice messages of the
teleconference sponsor, and sends the voice messages to other
participants. In addition, in the event of a teleconference cancellation,
on receiving a cancellation request from the teleconference sponsor, it
notifies all the teleconference participants of the teleconference
cancellation and deletes corresponding teleconference data from the
database.
The teleconference status confirmer notifies the teleconference sponsor or
a teleconference participant e.g. of the date and time of a teleconference
run, in response to an inquiry. A user can obtain the teleconference data
by specifying a teleconference ID.
The teleconference absence notifier notifies other teleconference
participants of a subscriber's absence from the teleconference and deletes
his name from the database, on receiving an absentee's request for an
absence notification.
A teleconference executor 8, also provided in the SCP 6, calls up
respective teleconference participants on the date and time of the
teleconference run registered in the database and connects their terminals
online, thereby holding the teleconference.
An SCP controller 9 also provided in the SCP 6 controls the teleconference
registerer 7 and the teleconference executor 8 and becomes an interface
for exchanging instructions with the exchange 1.
Lastly, an IN call processor. 10 provided in the exchange 1 performs a
mutual conversion between an instruction of the exchange 1 and an IN
message of the SCP 6. More specifically, the IN call processor 10 operates
as an interface between the exchange 1 and the SCP 6. Being a conventional
exchange, the exchange 1 cannot process an IN (Intelligent Network)
message used by the SCP (Service Control Point) 6. This is why the IN call
processor 10 replaces an IN message received from the SCP 6 by an
instruction processable by the exchange 1 and converts an instruction
issued by the exchange 1 for the SCP 6 into an IN message for its output.
The operations of the configuration under these principles are explained
below.
First, assume that a user, using a terminal among the group of terminal 5,
requests a teleconference run. In this case, the user (call originating
subscriber) issues a request for reserving a teleconference run from his
terminal to the exchange 1. The call processing unit 4 in the exchange 1
receives the request, and supplies the request to the IN call processor 10
on judging that the request is for the SCP 6. The IN call processor 10
converts this request into an IN (Intelligent Network) message for its
emission to the SCP 6. The SCP controller 9 in the SCP 6 receives the IN
message and analyzes its content. On judging that it is a request for
reserving a teleconference run, the SCP controller 9 invokes the
teleconference reservation notifier in the teleconference registerer 7
also provided in the SCP 6.
Getting invoked, the teleconference reservation notifier sends, via the SCP
controller 9 to the exchange 1, an instruction for obtaining data
necessary for reserving a teleconference run, i.e. data such as the names
of the teleconference participants and the date and time of the
teleconference run. At this time, the teleconference reservation notifier
has the instruction include the ID number of a voice message to be sent to
the call originating subscriber. The IN call processor 10 in the exchange
1 converts the received instruction into an instruction form processable
by the call processing unit 4. The IN call processor 10 converts the ID
number of a voice message into an input parameter for the VRE unit 3 for
its emission to the call processing unit 4. On receiving the input
parameter from the call processing unit 4, the VRE unit 3 sends a
pertinent voice message to the call originating subscriber. This allows
the call originating subscriber to receive a voice procedural explanation
e.g. "Please indicate the date and time of the teleconference."
The call originating subscriber sequentially inputs the data necessary for
reserving a teleconference run according to the voice message for its
emission via the call processing unit 4 to the IN call processor 10. The
IN call processor 10 then converts it to an IN message for its emission to
the SCP 6. The SCP 6 sends the received data via the SCP controller 9 to
teleconference reservation notifier in the teleconference registerer 7.
The teleconference reservation notifier registers, in the database, the
data (the names of the teleconference participants and the date and time
of the teleconference run) necessary for reserving the teleconference run
together with a teleconference ID.
Then, the teleconference reservation notifier notifies the teleconference
participants dictated by the call originating subscriber of a
teleconference run. More specifically, the teleconference reservation
notifier emits, via the SCP controller 9 to the exchange 1, a call
reception instruction for a teleconference participant, including a
message e.g. regarding the date and time of the teleconference run. The IN
call processor 10 in the exchange 1 converts the call reception
instruction into an instruction processable by the call processing unit 4
for its emission to the call processing unit 4, which calls up the
participant and notifies him of a teleconference run in a voice message by
using the VRE unit 3.
The above operations enable the process for reserving a teleconference run
by a call originating subscriber and the process for notifying the
teleconference participants of the teleconference run to be executed.
The teleconference reservation notifier in the teleconference registerer 7
may execute the process for canceling a scheduled teleconference run. In
this case, the call originating subscriber controlling the teleconference
issues to the exchange 1 a request for canceling the teleconference. The
call processing unit 4 in the exchange 1 receives the request and supplies
the request to the IN processor 10 on judging the request is for the SCP
6. The IN call processor 10 converts the request into an IN (Intelligent
Network) message for its emission to the SCP 6. The SCP controller 9 in
the SCP 6 receives the IN message and analyzes its content, and invokes
the teleconference reservation notifier in the teleconference registerer 7
on judging that the IN message is a request for canceling the
teleconference.
Getting invoked, the teleconference reservation notifier sends, via the SCP
controller 9 to the exchange 1, an instruction for obtaining an ID number
of the canceled teleconference. At this time, the teleconference
reservation notifier has the instruction include the ID number of a voice
message for inquiring the ID number of the canceled teleconference. On
receiving the instruction from the SCP controller 9, the IN call processor
10 converts the instruction to an instruction form processable by the call
processing unit 4, and converts the ID number of a voice message to an
input parameter for the VRE unit 3 for its emission to the call processing
unit 4. On receiving the input parameter from the call processing unit 4,
the VRE unit 3 sends a pertinent voice message for the call originating
subscriber. This allows the call originating subscriber to receive a voice
procedural explanation e.g. "Please indicate the teleconference ID."
The call originating subscriber inputs the ID number of the canceled
teleconference for its emission via the call processing unit 4 to the IN
call processor 10. The IN call processor 10 then converts it to an IN
message for its emission to the SCP 6. The SCP 6 sends the received data
via the SCP controller 9 to the teleconference reservation notifier in the
teleconference registerer 7. The teleconference reservation notifier
issues an instruction for sending a message for canceling the
teleconference run to respective teleconference participants stored in the
database together with the teleconference ID. The instruction is sent via
the SCP controller 9 to the IN call processor 10 in the exchange 1, which
converts the instruction to an instruction form processable by the call
processor 4 for its emission to the call processor 4. Then, the call
processor 4 calls up the participant and sends a notification for
canceling a teleconference in a voice message via the VRE unit 3.
The above operations enable the teleconference reservation notifier in the
teleconference registerer 7 to execute the process for reserving a
teleconference run and the process for notifying all the participants of
the teleconference run, as well as the process for canceling a scheduled
teleconference and the process for notifying all the teleconference
participants of the cancellation.
Each teleconference participant can confirm a teleconference status before
a teleconference run, by making a request for confirming a teleconference
status to an exchange 1 from any terminal among the group of terminals 5.
The call processing unit 4 in the exchange 1 receives the request, and
passes the request on to the IN call processor 10 on judging that the
request is for the SCP 6. The IN call processor 10 converts the request to
an IN (Intelligent Network) message for its emission to the SCP 6. The SCP
controller 9 in the SCP 6 receives the IN message and analyzes its
content, and invokes the teleconference status confirmer in the
teleconference registerer 7 on judging that the IN message is a request
for confirming the teleconference status.
Getting invoked, the teleconference status confirmer sends, via the SCP
controller 9 to the exchange 1, an instruction for obtaining an ID number
of the teleconference whose status is confirmed. At this time, the
teleconference status confirmer has the instruction include the ID number
of a voice message to be sent to the teleconference participant making the
request for status confirmation. On receiving the instruction from the SCP
controller 9, the IN call processor 10 converts the instruction to an
instruction form processable by the call processing unit 4, and converts
the ID number of a voice message to an input parameter for the VRE unit 3
for its emission to the call processing unit 4. On receiving the input
parameter from the call processing unit 4, the VRE unit 3 sends a
pertinent voice message for the teleconference participant making the
request for status confirmation. This allows the teleconference
participant to receive a voice procedural explanation e.g. "Please
indicate the teleconference ID."
The teleconference participant inputs the ID number of the teleconference
whose status confirmation he/she requests for its emission via the call
processing unit 4 to the IN call processor 10. The IN call processor 10
then converts it to an IN message for its emission to the SCP 6. The SCP 6
sends the received data via the SCP controller 9 to the teleconference
status confirmer in the teleconference registerer 7. The teleconference
status confirmer searches the teleconference data stored in the database
registered together with the teleconference ID. The teleconference
reservation notifier has registered in the database the teleconference ID
for use as a key in a search for pertinent teleconference data such as the
scheduled date and time.
The searched data are sent via the SCP controller 9 to the IN call
processor 10 in the exchange 1, which converts the IN message to an
instruction form processable by the call processor 4 for its emission to
the call processor 4. Then, the call processor 4 calls up the
teleconference participant and sends pertinent teleconference data e.g. on
the scheduled date and time in a voice message by invoking the VRE unit 3.
The above operations enable the teleconference status confirmer in the
teleconference registerer 7 to execute the process for allowing any of the
teleconference participants to obtain pertinent teleconference data for
its status confirmation.
An invited teleconference participant who is to be absent from a
teleconference can make a request to the exchange 1 for sending an absence
notice. The call processing unit 4 in the exchange 1 receives the request,
and passes the request on to the IN call processor 10 on judging that the
request is for the SCP 6. The IN call processor 10 converts the request to
an IN (Intelligent Network) message for its emission to the SCP 6. The SCP
controller 9 in the SCP 6 receives the IN message and analyzes it, and
invokes the teleconference absence notifier in the teleconference
registerer 7 on judging that the IN message is a request for sending an
absence notice.
Getting invoked, the teleconference absence notifier in the teleconference
registerer 7 sends, via the SCP controller 9 to the exchange 1, an
instruction for obtaining an ID number of the teleconference which a
teleconference participant cannot attend. At this time, the teleconference
absence notifier has the instruction include the ID number of a voice
message to be sent to the teleconference participant making the request
for making an absence notice. On receiving the instruction from the SCP
controller 9, the IN call processor 10 converts the instruction to an
instruction form processable by the call processing unit 4, and converts
the ID number of a voice message to an input parameter for the VRE unit 3
for its emission to the call processing unit 4. On receiving the input
parameter from the call processing unit 4, the VRE unit 3 sends a
pertinent voice message for the teleconference participant making the
request for making an absence notice. This allows the teleconference
participant to receive a voice procedural explanation e.g. "Please
indicate the ID number of a teleconference you cannot attend."
The call originating subscriber inputs the ID number of the teleconference
which he cannot attend for its emission via the call processing unit 4 to
the IN call processor 10. The IN call processor 10 then converts it to an
IN message for its emission to the SCP 6. The SCP 6 sends the received
data via the SCP controller 9 to the teleconference absence notifier in
the teleconference registerer 7. The teleconference absence notifier
searches the teleconference stored in the database registered together
with the teleconference ID. The teleconference reservation notifier has
registered the teleconference ID in the database for use as a key in a
search for pertinent teleconference data such as participants' names. The
teleconference absence notifier deletes the absenting subscriber's name
from the name list of teleconference participants.
An instruction for outputting a message that a subscriber is absenting to
all other teleconference participants is sent via the SCP controller 9 to
the IN call processor 10 in the exchange 1, which converts the IN message
to an instruction form processable by the call processor 4 for its
emission to the call processor 4. Then, the call processor 4 calls up all
the other teleconference participants and sends an absence notice in a
voice message by invoking the VRE unit 3. The above operations enable the
teleconference absence notifier in the teleconference registerer 7 to
execute the process for allowing the teleconference participants to obtain
pertinent teleconference data about an absentee.
On reaching the date and time of a teleconference run registered in the
database, the SCP controller 9 invokes the teleconference executor 8. The
teleconference executor 8 calls up respective teleconference participants
registered in the database for connecting their lines. That is, the
teleconference executor 8 sends instructions for connecting lines of
respective teleconference participants to the IN call processor 10 in the
exchange 1 via the SCP controller 9 in an IN message form, which converts
the instruction to an instruction form processable by the call processing
unit 4. Getting invoked, the call processing unit 4 establishes a line
connection between a teleconference participant and an exchange 1 on
receiving the instruction.
By repeating these processes, respective line connections are established
between all the teleconference participants and the exchange 1. Then, the
teleconference executor 8 sends, as an IN message, an instruction for
enabling all the teleconference participants to be put online for an
actual teleconference via the SCP controller 9 to the IN call processor 10
in the exchange 1. The IN call processor 10 converts the IN message to an
instruction executable by the call processing unit 4, which concatenates
lines for enabling a teleconference to be performed. This enables a
teleconference call to be formed for holding a teleconference.
Illustration of A Concrete Embodiment
The following is an illustration of a concrete embodiment of this
invention.
FIG. 2 shows the system configuration of a preferred embodiment of this
invention.
The system, which is a part of an IN (Intelligent Network), is realized as
a combination of an SSP (Service Switching Point) 20 and an SCP (Service
Control Point) 21.
The SSP 20 is an IN compatible exchange, and the SCP 21 is a computer for
controlling various IN services. That is, the SCP 21 performs all the
controls for teleconference services, and the SSP 20 controls a switching
matrix 23 according to the instruction from the SCP 21, thereby connecting
necessary terminals. A No. 7 common signal line (SS7) 28 connects the SSP
20 with the SCP 21.
The SSP 20 supports a terminal group 22 comprising a plurality of
terminals. The SSP 20 comprises the switching matrix 23, a call processing
unit 24 and a VRE (Voice Response Equipment) unit 25 having a voice
recording function. The VRE unit 25 sends a voice message to a subscriber
and records a voice message from a subscriber. A message ID number
controls a voice message. When the call processing unit 24 stipulates a
message ID number and a playing/recording instruction, the VRE unit 25
plays the voice message of the message ID number and records the voice
message in a memory space having the message ID number.
The call processing unit 24 comprising a conventional call processing unit
26 and a mapper 27 has a mechanism for receiving an instruction from the
SCP 21 attached to a conventional call processing unit.
The mapper 27 is software intermediating between an IN call processing and
a conventional call processing. That is, although a conventional call
processing performs a call connection by using a physical position of a
subscriber line, an ISDN B channel number, a call reference number and a
call memory number. However, an IN call processing does not distinguish
any of these internal parameters dependent on an exchange. Therefore, an
IN call processing uses a more abstract parameter. Hence, the mapper 27
performs a conversion between two [2] different call models, i.e. an IN
call processing and a conventional call processing, and an interface with
the SCP 21 pursuant to an IN call processing model. That is, a directive
instruction over the SS7 28 between the SCP 21 and the SSP 20 is an IN
message based on an IN call processing model.
The conventional call processor 26 has a trigger function attached, for
detecting an IN call processing startup point by accessing the SCP 21 via
the mapper 27 when a call is in a particular call state.
The SCP 21 for controlling the entirety of an IN service comprises an SLEE
(Service Logic Execution Environment) 29 and an SLP (Service Logic
Program) 30.
The SLP 30 is an application program for executing a teleconference service
and comprises the following six [6] submodules.
[1] A Teleconference Registration Process
This is a process for receiving a registration performed by the
teleconference sponsor.
[2] A Teleconference Run Notification Process
This is a process for notifying all teleconference participants of a
teleconference run.
[3] A Teleconference Absence Notification Process
This is a process for notifying all other teleconference participants of an
absentee on his request.
[4] A Teleconference Cancellation Process
This is a process for canceling a registered teleconference and notifying
the teleconference participants of the cancellation.
[5] A Teleconference Status Confirmation Process
This is a process for responding to an inquiry from a teleconference
participant about a scheduled teleconference run.
[6] A Teleconference Run Process
This is a process for holding a teleconference by connecting all the
teleconference participants online, on the registered date and time of the
teleconference run.
The SLP 30 comprises two [2] databases for storing necessary data in these
six [6] submodules.
[1] A Subscriber Management Database
This is for managing the dial number of a terminal subscribing to this
service and the corresponding subscriber's name and the teleconference ID
in which the subscriber having the dial number participates. This enables
a personal name to be inserted in a voice message by indicating the dial
number when a subscriber needs to be notified of something. This also
enables the ID number of the attending teleconference to be checked in the
teleconference status confirmation process. Example:
______________________________________
dial number name teleconference ID
______________________________________
7771234 Mr. Brown XXXXXXX
______________________________________
[2] A Teleconference Management Database
This is for managing teleconference data, such as a "teleconference ID", a
"controller", a "date and time of a teleconference run", and "attendees",
as registered by the teleconference sponsor. The "teleconference ID" is
attached by the teleconference registration in the SLP 30, and becomes a
reference number of the teleconference. The "controller" is a
teleconference participant sponsoring the teleconference. The "dial
number" of the sponsoring participant is registered as the control number.
The "date and time" is registered e.g. as "03301330" when the
teleconference is held from 1330 hours (i.e. 0130PM) on March 30. The
"attendees" register the dial numbers of all the teleconference
participants. Example:
______________________________________
teleconference ID
controller date and time
______________________________________
XXXXXXX dial number 1
03301330
attendees
dial number 2, dial number 3
______________________________________
The SLEE 29 performs an interface with the SSP 20 necessary for an IN call
control and execution of the SLP 30. That is, the SLEE 29 selects an
appropriate program submodule in the SLP 30 according to the data received
from the SSP 20, and runs the execution routine of the program submodule.
FIG. 3 is a flowchart showing the operations of a teleconference service.
More specifically, FIG. 3 shows the flow of a teleconference service
performed from the time when a teleconference sponsor (controller)
registers a teleconference to the time when a teleconference is held.
ST1: A teleconference registration process (program submodule [1]) is
executed on request of request by a controller for a teleconference
registration. The teleconference registration process is to receive, from
a controller, teleconference registration data on the names of
teleconference participants and the date and time of a teleconference run
and to store in the teleconference management database the teleconference
registration data with a teleconference ID attached.
ST2: A teleconference run notification process (program submodule [2]) is
invoked. That is, based on the data (comprising the teleconference ID, the
date and time of a teleconference run and the names of teleconference
participants) stored in the teleconference management database, a
notification is made to all teleconference participants of the data in a
voice message by a VRE unit 25.
A teleconference participant executes processes in ST3, ST4 and ST5,
respectively corresponding to program submodules [3], [4] and [5] for a
teleconference absence notification process, a teleconference cancellation
process and a teleconference status confirmation process, at any time
after the process in ST2 and before the process in ST6 (a teleconference
run process) on request from a controller.
ST3, An absence notification request from a teleconference participant
invokes a teleconference absence notification process (program submodule
[3]). On receipt from an absentee of the ID number of a teleconference
indicating that the absentee cannot attend, the absentee's name is deleted
from the name list of the teleconference participants for the
teleconference having the teleconference ID. Then, the fact that the
absentee cannot attend the teleconference is announced to all the other
teleconference participants in a voice message from the VRE unit 25.
ST4: A teleconference cancellation request from the controller invokes a
teleconference cancellation process (program submodule [4]). On receiving
from a controller an ID number of the teleconference that the controller
cancels, the teleconference data related to the teleconference ID is
deleted from the teleconference management database, and the cancellation
of the teleconference is announced to all the teleconference participants
in a voice message from the VRE unit 25.
ST5: A teleconference status confirmation request from any of the
teleconference participants invokes a teleconference status confirmation
process (program submodule [5]). On receiving from a teleconference
participant the ID number of a teleconference whose status confirmation
the teleconference participant requests, the teleconference participant
reads the teleconference data related to the teleconference ID from the
teleconference management database, the teleconference status is announced
to the teleconference participant in a voice message from the VRE unit 25.
ST6: On reaching the date and time of a teleconference run, the SLEE 29
recognizes the date and time and invokes a teleconference run process
(program submodule [6]). The teleconference run process enables a
teleconference to be held by connecting the terminals of all the
teleconference participants online on the date and time of a
teleconference run.
A teleconference service is executed according to the above described flow.
FIGS. 4A, 4B and 4C illustrate a VRE control system.
More specifically, FIGS. 4A, 4B and 4C illustrate the control system of the
VRE unit 25 shown in FIG. 2. As explained earlier, the VRE unit 25 is a
voice response equipment unit having a voice recording function. The
switching matrix 23 as an intermediary for exchanging parameters necessary
for processing connects the VRE 25 with the conventional call processing
unit 26.
FIG. 4A shows a case of sending an ordinary routine announcement having no
variable element, such as "Please input a dial number.". The conventional
call processing unit 26 alludes an ANM ID (announcement identifier) for a
cross-connection between subscribers and the VRE unit 25, thereby sending
an announcement of the ANM ID.
FIG. 4B shows a case of sending an announcement having parameters and
having a variable element. The conventional call processing unit 26 sends
such an announcement to the VRE unit 25 by adding the parameter showing
the content of a variable element to the ANM ID.
Assume for example, an announcement "XXX requests a teleconference run on
YYY. The teleconference ID is ZZZ. The teleconference participants are AAA
and BBB." alluded by the ANM ID. XXX is a parameter for the nam | | |
