WO1998032272A1 - Procede et appareil de messagerie - Google Patents

Procede et appareil de messagerie Download PDF

Info

Publication number
WO1998032272A1
WO1998032272A1 PCT/GB1998/000126 GB9800126W WO9832272A1 WO 1998032272 A1 WO1998032272 A1 WO 1998032272A1 GB 9800126 W GB9800126 W GB 9800126W WO 9832272 A1 WO9832272 A1 WO 9832272A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
message
map
data
service request
Prior art date
Application number
PCT/GB1998/000126
Other languages
English (en)
Inventor
Jon Stewart Leggatt
Matthew William Capp
Paul Astiz
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Priority to AU56709/98A priority Critical patent/AU5670998A/en
Publication of WO1998032272A1 publication Critical patent/WO1998032272A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53—Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/5307—Centralised arrangements for recording incoming messages, i.e. mailbox systems for recording messages comprising any combination of audio and non-audio components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53—Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/533—Voice mail systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2201/00—Electronic components, circuits, software, systems or apparatus used in telephone systems
    • H04M2201/60—Medium conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13534—Internet - WWW, HTML, browsers etc.

Definitions

  • the present invention relates to method and apparatus for messaging in a communications network and finds particular application in an integrated communications environment providing different service types, such as voice telephony and messaging.
  • the MAP essentially provides a bridge between different communication types. It can for instance receive service requests as SMTP inputs, or inputs over a telephone line, and respond by providing a facsimile or electronic mail (e/mail) service as an output.
  • a messaging system for use in providing a messaging service, which system comprises: i) an input for receiving a messaging service request, the service request comprising destination information and message content information; n) a user data interface and store for receiving and storing user input data; in) request processing means for processing a received service request; and iv) an output for outputting a processed service request in a format for use by communications connection set-up means in transmitting the message content information, or information identified thereby, as an output message to at least one destination identified by the destination information.
  • Embodiments of the present invention will need to have access to a communications connection set-up means capable of receiving and responding appropriately to processed service requests and this can advantageously be provided by a MAP, as abovementioned.
  • a communications connection set-up means capable of receiving and responding appropriately to processed service requests and this can advantageously be provided by a MAP, as abovementioned.
  • a system might be as described above, but further comprising the connection set-up means, said connection set-up means comprising:
  • a voice network interface for providing access to a network for carrying voice signals
  • a resource interface for access to resources for use in providing communications services, including at least one speech-related resource from the group comprising voice recognition, recordal of incoming sound signals and transmission of outgoing sound signals;
  • interpretation means for use in relating a processed service request to a computer-based application for use in provision of that service
  • connection set-up means could be used however.
  • the basic requirement will be for platform, which may incorporate a combination of hardware and software, which is provided with an appropriate interface for receiving the processed service requests, and the means to respond appropriately by establishing a connection to a location in a communications network and sending the message content information, or information identified thereby.
  • a flexible messaging service can be provided which can make considerable management information and control functions available to the user.
  • the access to data storage for storing customer-related data gives considerable flexibility to the user. This is because the request processing means can use customer-related data to interpret a received service request.
  • the destination information in a received service request need not then be in a form directly usable by the connection set-up means, instead being interpreted by the request processing means.
  • the user could create a personal directory of destinations for output messages, listed under peoples' names and groups of names. The user could then use names in a service request. The names are interpreted by the request processing means into location identifiers for use by the connection set-up means, using the customer-related data.
  • the user could create address groups and use simply a group name in the initial service request, this group name then being interpreted into multiple location identifiers by the request processing means.
  • a location identifier in this context which could be used directly by the connection set-up means, could be for instance a telephone number, an electronic mail address or a Universal Resource Locator (URL) . That is, it generally will address a network location to which a communications connection can be established.
  • URL Universal Resource Locator
  • the request processing means could be provided with access to control data, in addition to or as part of the customer-related data. It could then be used as a mechanism for instance for screening or limiting destinations for the output messages. As well as interpreting destination information to obtain location identifiers, the request processing means could also interpret the message content information by reference to the data storage. Hence a user could prepare stock messages, or a particularly long message, in advance and simply identify the message to be sent by referencing a message in a message directory.
  • the system can be installed on an existing platform, for instance on a computer which provides Web server capability and which is connected to the Internet.
  • the system itself may optionally be made only accessible from a corporate Intranet, or to another closed user group.
  • a MAP which is connected for instance to both the Internet and a PSTN
  • messages can be sent to a very broad spectrum of destinations.
  • the output could be limited in the same manner as user access, for instance by use of data in the data storage, to only predesignated destinations.
  • Embodiments of the present invention can be particularly efficient in terms of network traffic since the received service request comprises a single message to a single destination.
  • the service request can potentially contain destination information to multiple locations for the same message content information ("multimessaging") . It need only be transformed into the multiple messages, the output messages, after it has reached the communications connection set-up means.
  • a convenient means by which a user may create a messaging service request is by means of a computing terminal provided with a forms facility, such as a Web browser.
  • This can elicit the necessary data from the user which the request processing means converts to a message suitable for use by the communications connection set-up means.
  • the system may be preferable that the system has access to text-to- speech conversion means such that the message content information can be delivered as output voice messages.
  • the service requests are received in text or data format, they can then be delivered to any person having access to a telephone and do not require the use of more expensive forms of equipment for reception.
  • the message content information could be delivered by a different means, such as in a textual format of the e/mail type.
  • a message output which can provide appropriate real-time communication from the messaging system to a MAP is by use of the UNIX-based development known as a "socket" connection.
  • a direct, point-to-point connection messages in e/mail format can be sent in real time to the MAP. This is further discussed below. It avoids delays experienced in normal e/mail transmissions while allowing user-friendly textual inputs to be simply formatted into a processed service request which the MAP is easily adapted to receive and act on.
  • messages should not be taken to have a specific meaning in the context of the present specification, unless specifically stated as having such a meaning.
  • the word “message” should not be taken to imply for instance any particular means of transmission, routing or queuing, as might be implied for instance by e/mail (i.e. electronic mail) messages. It is intended only to mean a set of information which can be transferred between network entities. A message could thus be embodied as speech, text or data signal.
  • a service request could be automatically generated by a metering device when a metered parameter goes below or above a predetermined threshold.
  • a messaging system and service using a MAP for text to speech conversion and for delivering the output messages to their destinations, will now be described as a specific embodiment of the invention, by way of example only, with reference to the accompanying drawings in which:
  • Figure 1 shows a block diagram of the hardware context of the messaging system
  • Figure 2 shows a block diagram of components of the system
  • Figure 3 shows a flow diagram of a registration process for a user of the messaging system of Figure 2
  • Figure 4 shows a flow diagram for a directory creation and modification process for a user of the messaging system of Figure2;
  • Figure 5 shows a flow diagram for a password process for a user of the messaging system of Figure2;
  • Figure 6 shows a flow diagram for a service request process available to a user of the messaging system of Figure 2;
  • Figure 7 shows shows a flow diagram for a call records process available to a user of the messaging system of Figure 2;
  • Figure 8 shows a schematic block diagram of components of a MAP for use with the messaging system of Figure 2;
  • Figure 9 shows a block diagram of the contents of a speech card for use in the
  • Figure 10 shows a schematic block diagram of two MAPs according to Figure 8, having some shared platform
  • Figure 1 1 shows a functional block diagram of a MAP management system for managing overall process flow in the MAP of Figure 8;
  • Figure 1 2 shows a schematic representation of an example of data provision at startup for the MAP shown in Figure 8;
  • Figure 1 3 shows a flow diagram of events occurring in the MAP of Figure 8, at launch of an application in response to a service request; and Figure 14 shows a schematic overview of service and resource queues in the MAP of Figure 8.
  • PABXs has core capabilities and manufacturer - specific extensions
  • the messaging system is provided on a computing platform 1000 provided with a Web server 1010 and connected via a data connection 1005 to a MAP 1 50.
  • Web browsers 31 5 for multiple users are connected to the Web server 1 010 and the MAP 1 50 is connected to a PSTN 1 60.
  • Multiple users are provided with telephone connections 320 to the PSTN 1 60, in the normal way.
  • the Web browsers 31 5 are standard browsers, for instance as offered by Netscape, modified to conform to CGI capabilities by the use of the C + + programming language.
  • a suitable Web server is for instance the Netscape "Commerce Server, Version 1 .1 ".
  • the data connection 1005 between the Web Server 1010 and the MAP 1 50 carries TCP/IP data and is preferably provided by a real-time, point to point connection such as provided by the UNIX capability known as a "socket" connection. This allows fast communication with the MAP 1 50 rather than the performance of an ordinary electronic mail connection.
  • Socket connections are known and information can be obtained by reference to "The design of the UNIX Operating system", by Maurice J. Bach, Prentice Hall International, 1 986.
  • a further reference for information is the Unix Programmers Manual 4.2, Berkeley Software Distribution, Virtual Vax-1 1 version, obtainable from or published by the Computer Science Division, Dept of Electrical Engineering and Computer Science, University of California at Berkeley, August 1 983.
  • the relationship between the computing platform 1000 which supports the messaging system and the MAP 1 50 is that the platform 1000 supports most of the processing capacity for the service and in particular provides user-related aspects of the service. That is, the platform 1000 provides the means for inputting data from the user, formatting output messages to the MAP 1 50 based on user input, creating and updating a user directory, creating and maintaining user account data and secure user access and maintaining user-specific call records and status data.
  • the MAP 1 50 provides the functionality for converting a text message received from the messaging platform 1000 to speech, scheduling and making telephone calls using that speech, making retries and updating the call records and the status data available to the Web server 1010.
  • the computing platform 1000 supports the Web server 1010, an HTML page store 2045, data storage 2030, 2035 and a set of gateway processes 2000, 2005, 2010, 201 5, 2020.
  • the computing platform 1000 can be accessed by means of a user's terminal 31 5 and can access the MAP 1 50 in any of several different ways. For instance, it could have a socket connection to the MAP, a LAN connection, or it could be connected via the Internet 1 55.
  • the messaging service software may be installed on computing platform 1 000 which comprises one or more personal computers (PCs) running WINDOWS '95, or an NT workstation. In addition it may be possible for the software to run on WINDOWS 3.1 or with Windows for Workgroups V3.1 1 where the WIN32S extensions from Microsoft will be required.
  • the data storage 2030, 2035 could be located elsewhere and merely be accessible via the platform 1000. Further, although shown in separate units the data storage could be provided as a single entity.
  • a user of the messaging system has access from a Web browser 31 5 which communicates with the Web server 1 010 in known manner.
  • the Web server 1010 provides Web pages to the browser 31 5 from the HTML page store 2045. More frequently however, the Web server 101 0 will send pages generated by the gateway processes, using a common gateway interface (CGI) 2040.
  • CGI common gateway interface
  • gateway processes do not normally maintain context once they have been run. There is a requirement in embodiments of the present invention for maintaining context between one instance of running a gateway process and another. This is done by embedding context data in the relevant URLs, using the known "GET” and “POST” techniques which pass data in the query string or message body of a URL.
  • This URL identifies the home page for a multimessaging service, with embedded context information in the form of a user account number. It has the following sections:
  • gateway processes such as a login process, but these are of known type and functionality and are not shown or described herein.
  • the registration process 2000 is seen separately from the other processes since it is only necessary to register for the messaging service once. Thereafter, the information provided/generated at registration usually remains unchanged.
  • the other processes are offered as alternatives from a common Web page for the user to select from, since the user will normally use each of them many times.
  • STEP 3000 It is triggered after the user inputs a URL at the Web browser for the messaging service home page.
  • STEP 3005 In known manner, the Web server downloads the relevant home page to the Web browser.
  • STEP 3010 The home page is provided with a selection of HTML links, for instance as "Hotlinks", and the user selects registration.
  • STEP 301 5 The CGI 2040 initiates the registration process and downloads a form to the user.
  • STEP 3020 The user completes the form, including provision of a password, and returns it to the server.
  • STEP 3025 The registration process performs a check on the completed form and either offers the user a retry (for a limited number of times) if the completed form fails to meet requirements (STEP 3035), or allocates an account number, which it notifies to the user, and stores the user data in association with the account number in the user data store 2035 with password only access (STEP 3030).
  • the user data required at this stage is of course optional but might include the user's name and telephone number.
  • the login procedure for a user will usually require both the account number and the password to be provided. This provides security and allows one user to run different accounts.
  • the user directory process 2005 is as follows:
  • STEPS 3000, 3005 As described with reference to Figure 3. (It is of course not necessary that the "Hotlinks" for all the processes from which a user can select are presented together on one Web page. There may be an intervening page or pages to be selected by the user before the page with a required "Hotlink” appears. This is simply standard HTML technology.)
  • STEP 4000 The user selects an HTML link identifying the user directory process 2005. (In practice, there are two separate "Hotlinks", one for adding to a personal directory and one for removing entries from a personal directory. The two processes are complementary and only the process of adding entries to a user directory is described here.)
  • STEP 4005 The CGI 2040 initiates the requested User Directory Process 2005 and returns a form to the user, requesting information concerning a new entry to the user directory.
  • the information will usually comprise a name and telephone number (or other network location identifier) for the new entry.
  • the form also requires a user password.
  • STEP 3025 The process checks whether the completed form meets requirements, including particularly the provision of a valid password, and if not notifies the user and offers a limited number of retries (STEP 3035), as in the process of Figure 3.
  • STEP 4010 When the completed form is found to meet requirements, the process enters the data in a directory allocated to the user account number in the gateway data store 2035. The process will also notify the user that the entry has been added, using a Web Page which offers a Hotlink to return to the service home page.
  • the password process 2010 is as follows:
  • STEPS 3000, 3005 As described with reference to Figure 3.
  • STEP 5000 The user selects an HTML link identifying the password process
  • STEP 5005 The CGI 2040 initiates the requested password process 2010 and returns a form to the user, requesting information concerning old and new passwords.
  • STEP 501 0 The user returns a completed form.
  • STEP 3025 The process checks whether the completed form meets requirements and, if not, notifies the user and offers a limited number of retries (STEP 3035), as in the process of Figure 3.
  • STEP 501 5 When the completed form is found to meet requirements, the process substitutes the new password for the old password in all relevant locations, including in a directory allocated to the user account number in the gateway data store 2035. The process will also notify the user that the password change has been accepted, using a Web Page which offers a Hotlink to return to the service home page.
  • the messaging service process 201 5 is as follows:
  • STEPS 3000, 3005 As described with reference to Figure 3.
  • STEP 6000 The user selects an HTML link identifying the messaging service process 201 5.
  • STEP 6005 The CGI 2040 initiates the requested Messaging Service Process 201 0 and returns a form to the user.
  • STEP 6010 The user returns a completed form.
  • STEP 3025 The process checks whether the completed form meets requirements and, if not, notifies the user and offers a limited number of retries (STEP 3035), as in the process of Figure 3.
  • STEP 601 5 When the completed form is found to meet requirements, the process uses the information supplied to generate an SMTP message for transmission to the MAP 1 50. The process will also notify the user that the message has been sent, identifying the message, for instance by its title, and giving time and date information. Notification is done by means of a Web Page which offers a Hotlink to return to the service home page.
  • the SMTP message generated at STEP 601 5 is required to contain specific fields for data in order that the MAP can receive and respond to the message.
  • the following gives a specification of each of the variables in the MAP service messages so as to clarify the protocol between a client application and the MAP.
  • the ⁇ user > field may contain the telephone number of the person requesting the service.
  • the ⁇ service > field contains the name of the service being requested. Some examples are given below: ttsm text to speech - male voice ttsf text to speech - female voice tel telephony page to send a page message (may need to split according to swatch, data pagers etc) sms sends an SMS (Sort Message Service) to a GSM phone fax fax message conf telephone conferencing
  • Embodiments of the present invention which require a voice output message from the MAP 1 50 will generally use the name “ttsm” or “ttsf”. Redundant fields will be assigned the string NULL. This makes it easier to code the client and server as well as making it easier to manage the interface.
  • the structure of messages incoming to the MAP is generally as set out below. However, it would be relatively simple to modify applications at the MAP 1 50 so that other message elements could be incorporated and acted on.
  • startjiow - set to YES if the servicejnstance is to be started as soon as possible
  • Servicejnstancejdentify is an identifier assigned by the MAP on first receipt of a processed service request. It can be used thereafter wherever information will be relevant to that particular service instance. Hence it will be used by the messaging system to identify status data in the raw call records data store 2030 for downloading to the user so that the user can check whether their message has been sent or has failed.
  • Start _d ate : ⁇ me and "stop_date_t ⁇ me” allow the user to schedule when a message should be sent.
  • the MAP will only start to try to deliver a message after the start date and time given and will terminate attempts after the stop date and time given.
  • the user can specify a time and date at which each message is to be delivered and this can be used for arranging meetings, scheduling events, providing public information and raising alarms.
  • the "number_of_receivers" field could be completed by the service request process 201 5 by processing data entered by the user. It could alternatively be filled in by the user. Either way, it can be used by the system to make a simple check that network location information, such as an e/mail address, has been supplied for the correct number of intended recipients of a message. If the check fails, the system will issue a prompt to the user for missing information.
  • receivers' data will generally not all be used in the same message since usually the intention will be that messages are to be delivered by a selected one only of a set of possible modes of transmission.
  • Confirmation email address is a field which could potentially be used in embodiments of the present invention.
  • this functionality of the MAP is not used, instead the messaging system uses its own processing power to access raw call record data so as to monitor progress of a service instance.
  • Startjiow will be set to NO in the event that the "start _atej;ime” field has an entry. Otherwise it will be set to YES.
  • Delete service instance is unlikely to be completed in a processed service request. However, it could clearly be completed by the messaging service in other circumstances, for instance in the event that a user had the option to cancel a service request before the MAP had acted on it.
  • "Message start” and "message 3top” identify the information content that should be incorporated in a message output to a receiver by the MAP.
  • the MAP may set up a telephone connection to a receiving party. If the receiving party answers, the MAP will play a recorded message to ask for confirmation that the receiving party wishes to receive the message.
  • the MAP will play a recorded introduction and then, using a text to speech resource, will send the information content as a speech signal.
  • "Message start” and “messagejstop” delineate the material which should be sent to the text to speech resource for conversion to a speech signal.
  • “Status” is another field which may be redundant in embodiments of the present invention. It is a field which the MAP completes for messages being returned to computing applications running services from non-MAP platform. In the primary embodiment of the present invention described herein, instead of obtaining dedicated status information in messages returned to the system from the MAP, the messaging system accesses the raw call records in the call record data store 2030. The MAP sends call record files here and enters status flags in the event of any change in status.
  • the call records process 2020 is as follows:
  • STEP 7000 The user selects an HTML link identifying the call records process 2020.
  • STEP 7005 The CGI 2040 initiates the requested Call Records Process 2020 and returns a form to the user.
  • STEP 7010 The user returns a completed form.
  • STEP 3025 The process checks whether the completed form meets requirements and, if not, notifies the user and offers a limited number of retries (STEP 3035), as in the process of Figure 3.
  • STEP 701 5 When the completed form is found to meet requirements, the process uses the information supplied to identify the user's call record data in the sorted call records area of the call record database 2030. It then uses the data to send a page to the user showing a record of all the service instances they have generated, together with status information regarding whether a message has been successfully sent, has failed or is still being attempted.
  • the MAP creates files of raw data on service instances it handles. These are each identified by the "servicejnstancejdentify" field and stored in a raw call record data area (an FTP directory) of a database. It could be on the same computing platform 1000 as the Web server 1010, as shown in Figure 2, or it could be elsewhere.
  • the messaging system of the present invention has access to the same directory. It sorts the raw call data according to user account number. It is these sorted records that the Call Records Process 2020 makes available to a user.
  • the MAP When the MAP is in the process of setting up a connection and transmitting a message to a recipient, it will output an update status message to the raw call records data directory, that is the FTP directory, whenever there is a change in status for a service instance. It uses the "servicejnstancejdentify" to identify the relevant file.
  • the Web server 1010 will similarly update files in the FTP directory when there has been a user input in respect of a service instance.
  • the server 1010 also has access to this directory for the purpose of displaying call record data sorted by account number, in particular including status information, to the user.
  • the messaging system updates the sorted call records for display to a user by accessing the raw data whenever a logged in user selects a link and therefore moves between pages displayed at the Web browser 31 5.
  • the information presented to the user to indicate connection status for all their messaging might be a table showing the name of each intended recipient, the title of each message, the date on which it was requested and a status flag having three conditions to show whether the message has been sent, has failed, or is still in the process of being set up.
  • the status flag could be a coloured marker showing green for sent, red for failed, and amber for still in process of being set up, in the manner of traffic lights.
  • the MAP 1 50 sits between a data network 1 55, such as the Internet, and a telecommunications network 1 60 such as the PSTN. It comprises primarily one or more speech cards 1 10 and one or more digital line interface cards 1 05, managed by applications running on a PC 1 20.
  • a network interface card (NIC) 1 30 provides connection to the data network 1 55, for instance by means of TCP/IP, and the DLICS 105 provide connection to a network switch or exchange 250, in this case a PABX, via an ISDN link 210.
  • NIC network interface card
  • the MAP 1 50 is capable of supporting many additional services and the following should be taken as a description of a platform capable of supporting embodiments of the present invention but also having functionality which may be unnecessary as far as embodiments of the present invention are concerned.
  • the speech cards 1 10 carry a set of algorithms for detecting, recognising, recording and generating speech signals and tones.
  • the speech cards can also deal with modem signals.
  • the PC 1 20 also carries some of the more sophisticated algorithms, such as the speech recognition and text to speech conversion algorithms. These are the resources which allow the MAP to recognise and convert between different signal media, such as between spoken messages, recorded voice messages, electronic mail messages and the like. Additionally, there are one or more FAX cards 1 65 for providing the capability of sending and receiving by facsimile.
  • the network interface card(s) 1 30 may of course support different communication protocols. As shown, the network interface card 1 30 supports TCP/IP and provides an interface to the Internet 1 55. This can give access to services provided by the MAP to any user having a connection to the Internet 1 55.
  • the digital line interface cards 105, the speech cards 1 10 and the FAX cards 1 65 are connected to each other by a (known) multi-vendor interface protocol link 100 and to one or more personal computers 1 20 by ISA links 1 1 5.
  • General control of operation of the MAP 1 50 is provided by a computer application running on the PC 1 20.
  • this application controls flow of processing in the MAP 1 50.
  • Actual process execution to provide services is primarily (but not exclusively) carried out by processors of the speech cards 1 10.
  • each speech card 1 10 carries seven speech processors.
  • the first of these, a Motorola 68,000 speech processor 205 (referred to as “68K” in the Figures) , provides processing power and gives overall control of what is happening on the speech card 1 10.
  • the other six speech processors are Motorola 56,000 speech processors 200 which provide DSP capability.
  • the 56,000 processors 200 (referred to as "56K” in the Figures) provide some of the resources, particularly algorithms, used in running services on the MAP 1 50. These algorithms provide functions such as MF4 detection, playing out messages at 8 kbits/sec, recording messages at 64 or 8kb ⁇ ts/sec, and speech recognition.
  • the MAP Manager This is software which generally will reside on the PC 1 20.
  • the MAP Manager has knowledge of the resources available, in terms of ISDN channels and the processors 200, 205, and it determines where resources will be made available to meet demand by applications.
  • the MAP Manager has control over time switches 21 5 in the processors of the speech card 1 10 and allocates streams for processing by means of the MVIP 100.
  • the basic architecture of a MAP 1 50 can be multiplied up so that there are at least two PCs 1 20, connected to their respective MAP speech cards 1 1 0.
  • the DLICs 105 may share a common platform, as shown.
  • Each PC 1 20 is connected via the ISA bus 1 1 5 to a network interface card 1 30 and thus to the Internet 1 55 via a network link 1 25. Further processing power can be provided by a UNIX processor 300, also connected to the ISA bus 1 1 5 and hard disk storage 305 is provided. Further memory 310 is associated with the PCs 1 20. In this arrangement, one MAP 1 50 can communicate with, and exploit resources of, another MAP 1 50.
  • the Minor Applications Platform (MAP) 1 50 described below is a PC-based speech platform capable of providing multiple speech applications on multiple telephone lines.
  • the heart of the system is the speechcard SC2 1 1 0 which provides speech and signal processing based on algorithms.
  • the MAP 1 50 supports multiple digital links to public and private telephone exchanges using its Digital Line Interface Card (DLIC) 1 05.
  • DLIC Digital Line Interface Card
  • the MAP 1 50 supports resource sharing and is dynamically reconfigurable to run different applications on the same hardware.
  • DLIC 105 and SC2 1 10 cards are interconnected using an industry standard speech bus 100 called Multi Vendor Interface Protocol (MVIP) and this capability may be used to build MAP systems using other commercially available cards.
  • MVIP Multi Vendor Interface Protocol
  • MAP systems may also be built in shelves with passive backplanes and use plug-in processor cards. Such backplanes may be split in which case MAP hardware and software resources may be shared between processors.
  • the MAP system has a single manager and can provide traffic statistics. Its operating system is UNIX. It has an archival facility which has direct links to DOS, WINDOWS and Netware. THE MAP NETWORK SERVER
  • the MAP system 1 50 provides a 30 channel digital connection 210 to a public or private telephone switch 250, such as a PABX, using a variety of protocols.
  • the MAP 1 50 allows connection to be made to a public exchange using signalling systems such as the DASS2 or A1 B1 signalling systems, or to a private exchange using the DPNSS protocol.
  • the MAP 1 50 is connected to a private PABX using DPNSS which allows service provision based on TLI (and possibly SIC) codes. These codes have analogues in the PSTN where the known C7 signalling system is used, and thus services provided on the MAP as described herein can be implemented over the PSTN.
  • PCs 1 20, 300 are used to provide the MAP system.
  • One PC 1 20A provides system management and connection to the PABX 250, whilst the other two PCs 1 20B, 300 provide advanced speech recognition and text to speech conversion services.
  • a fourth PC (not shown) provides connectivity to the Internet 1 55 through an SMTP gateway, thereby enabling messages to be sent to and received from the LAN.
  • the MAP manager provides control software for starting and terminating applications and co-ordinating their requests for services on line cards 105 and speechcards 1 10.
  • the MAP manager resides on one of the PCs 1 20A and provides a screen-based user interface. From the manager screen the MAP system can be started, parked or shutdown and the state of resources examined. The manager uses a small number of tables which may be examined to control allocation of resources and application selection.
  • a MAP "Traffic Statistics" screen can be invoked from the manager and provides basic information on platform use by applications, notably number of calls/application, average call holding time and busy hour.
  • the MAP Manager 400 comprises control software 440 and a set of agents 405, 410, 41 5, 420, 425. Each agent is generally allocated to a functional entity, which may be hardware and/or software, and provides a control link thereto. Hence there is a DLIC agent 405, a speech card agent 410, a fax agent 41 5, a text to speech agent 420 and a speech technology applications processor agent 425.
  • the DLIC, speech card and fax agents 405, 410, 41 5 are provided with Applications Programming Interfaces (APIs) 430 and with plural drivers 435 for driving the relevant pieces of hardware (cards). Each API is provided by the suppliers of the relevant hardware cards.
  • the MAP Manager control software 440 provides overall control of the agents and acts as a sophisticated message switch in that substantially all messages go via the MAP Manager control software 440.
  • the drivers 435 receive incoming data and control outgoing communications for example by controlling interrupts on the relevant bus.
  • the MAP Manager 400 provides overall resource allocation To do this, at start up, it constructs a world view. This is checked and updated at intervals. It obtains the world view through its resource agents. For instance, referring to Figure 1 2 which shows a representation of a small part of the MAP Manager's world view, the speech card agent 410 may have reported that two digital signal processors 500, 505 are loaded respectively with a multi-frequency detection algorithm 510 and an 8K coding scheme 51 5. These two digital speech processors 500, 505 will therefore deal with signals on the MVIP 100 which are incoming and outgoing respectively.
  • MAP can be potentially hosted on most standard PCs with a 33 Mhz 486 PC or better and having a minimum of 8 Mbyte of memory.
  • the standard processor used within the BT network is the Compaq 51 33, a Pentium based machine having 5 full length ISA slots for MAP and other hardware cards.
  • a processor card manufactured by Aculab pic can be used. This is intended for use in a shelf unit where the need is to provide a multi-processor MAP system in a single enclosure with minimal non-MAP components.
  • Outline features include
  • Speech algorithms for use on the speech cards 1 1 0 and processors 1 20, 300 include:
  • the Speechcard is manufactured by Aculab pic and provides a UNIX-based environment for algorithm execution, with a VXWorks real-time kernel. It contains six Motorola 56001 A DSPs clocked at 27MHz for digital signalling processing each of which connects to the MVIP bus. The on-board 40 MHz Motorola 68000 coordinates communication between the DSPs and the MAP host processor over the ISA bus. It is also used in some instances for further algorithmic processing.
  • the card is EMC approved and also provides a single analogue port for local speech recording/playback facilities.
  • the MAP operating system is System 5 release 4.4 UNIX. This is commercially available as Consensys, or UnixWare V1 .0.
  • the MAP system could of course be ported to other systems such as UnixWare V2.0 or LINUX.
  • the MAP system must also interwork with the speechcard host operating system, VxWORKS, a UNIX system with a real-time kernel. One copy is required per speechcard.
  • Processor sections may be interconnected to make larger processing units. It is primarily used to contain multi-processor MAP systems and archival systems and contains
  • E1 Primary Rate ISDN connection is provided using Aculab's "E1 " card.
  • E1 card There are 30 and 60 channel versions available on an ISA PC bus.
  • This E1 card supports different types of speech bus 100, including MVIP. It is EMC approved and is widely used and approved for host-independent connection in many countries worldwide.
  • DLICs 105 are controlled by a DLIC Agent 405.
  • a DLIC Agent 405 Under the control of the Manager 440, speech from a timeslot on an ISDN link 210 is switched by the DLIC 105 onto an MVIP timeslot and stream and, using a similar switch on the SC2 1 10, the manager directs the speech to a given DSP 200.
  • DLICs 105 in MAP systems 1 50 can also be "daisy chained", allowing one MAP system to pass calls to another, only the first MAP system 1 50A being connected to the host exchange. This avoids a situation as shown in Figure 9 where, in order to get sufficient MAP service capacity, a customer is supporting direct ISDN connections to three different MAPs 1 50. This might otherwise be the result where a customer has an ISDN connection for 30 channels on one link but one MAP system 1 50 cannot provide all the required resource.
  • MAPs 1 50 To "daisy chain" MAPs 1 50, it is simply necessary to substitute a sixty channel DLIC 105 for the thirty channel DLIC 105 used normally in a MAP, in the first and second MAPs 1 50A, 1 50B, and to use the second and third MAPs 1 50B, 1 50C for overflow connections via the DLIC agents 405 of the first and second MAPs 1 50A, 1 50B.
  • requests for services using the MAP may be received either on one of the ISDN links 210 or, via a network interface card 1 30 and an SMTP gateway process 725, from a computer-based link such as a UNIX socket connection, a LAN, an Intranet or the Internet 1 55.
  • a computer-based link such as a UNIX socket connection, a LAN, an Intranet or the Internet 1 55.
  • the computer platform 1000 outputs an SMTP message to the MAP, it could equally use a different format and could be delivered to the MAP 1 50 for instance by means of an ISDN connection.
  • the following description includes the functionality of the MAP in the scenario that a service request message is received by ISDN connection.
  • the MAP 1 50 will need to run a computer- based application 730,735 to manage the service, and it will need to allocate the resources necessary to run the service.
  • These resources may include at least one ISDN time slot 720.
  • Service requests coming in on an ISDN link 210 will necessarily already have an ISDN time slot 720 and the MAP allocates these directly to the relevant applications 730, 735.
  • Service requests coming in from the computer-based link on the other hand are placed in a Generic Service Queue 71 0 and the various applications 730, 735 which are relevant to these services read out their own service requests from the Generic Service Queue 710.
  • This mode is used, for example, as the basis for provision of speech services requested via a computer-based link. If a speech service request is received via a computer-based link, there is no speech channel 720 directly involved. One needs to be provided as quickly as possible. A minimum of channels 720 are therefore permanently dedicated to each service, though an application can acquire further lines from a free pool. Such applications 730,735 are normally outgoing only e.g. notification and voicemail delivery services, or booked services such as conferencing.
  • MAP system On receipt of incoming call. In this case, there is necessarily a speech channel 720 associated with the service request.
  • the MAP system allows the application to be selected by channel of entry or DDI number, both in conjunction with the SIC. In the present embodiment, the DDI method has been adopted as this allows line plant to be used according to demand with consequent higher line utilisation. This facility would be used for services such as telephone access to e-mail.
  • the Generic Service Queue 71 0 can be divided into application types so that there are multiple service queues 71 0.
  • a number of service channels 710 can be pre- allocated to each service queue 71 0 and the number of service channels for a particular service queue can be determined from observed traffic levels.
  • An Internet address can be associated with each generic service queue. Requests can then be added to the queue by sending messages to this address. These messages need to contain all the information required for the MAP application to subsequently enact the request, and are thus best computer generated. Client software to originate such messages is described above, and is the basis on which 'point and click' telephony and messaging services can be provided. However, it should be noted the MAP applications can themselves request such backbone services. For example, if a user of the message collection service wants to receive a copy of an e-mail message by FAX this can be achieved by the voicemail application making a FAX request This is the basis of the collection services.
  • Line Allocation is specified in configuration files which may be dynamically updated while the system is running. Lines may be classed as reserved for outgoing (free pool), fixed for incoming, or available for either. Lines may be allocated either statically or dynamically.
  • Application Allocation is either by point of entry (ordered) or by DDI digits for service requests incoming by ISDN channel. For incoming SMTP messages, it is simply done by interpreting the service requested and directing the request to an "IMMEDIATE" application. Applications are normally run by the manager but, like hardware resources, may be distributed between MAP systems sharing a common MVIP.
  • Algorithm Allocation may be either static, dynamic or a combination of both.
  • a user initiates a dialled connection to the MAP 1 5 1 50, using a telephone 320 connected to the PSTN 1 60.
  • the call will be received at a DLIC 105 and a driver 435 for the relevant DLIC agent 405 will receive an event on a timeslot "X".
  • the DLIC agent 405 has its own processing capability and will instruct the driver to acknowledge the event on timeslot "X”.
  • the DLIC agent 405 will have also instructed the relevant DLIC 105 as to what protocol is 20 being used.
  • the DLIC agent 405 then tells the MAP Manager control software 440 that there was an incoming event.
  • the MAP Manager control software 440 recognises that it will have to raise a computer-based application to provide the requested service. To do that it needs 25 to obtain the DDI digits which will identify the service requested by the user. The MAP Manager 400 will therefore tell the DLIC agent 405 that it needs the DDI digits.
  • the MAP Manager 400 Once the MAP Manager 400 has the DDI digits, it will access an interpretation 30 table stored on disc 305.
  • the disk 305 will store any frequently accessed data in local memory, for read access only. (Nowadays this is a standard feature of many disk storage systems. It is controlled by a disc controller provided by the disc supplier.)
  • the DDI digits once interpreted by use of the table, will identify to the MAP Manager the service required.
  • the MAP Manager 400 needs to translate this into the application(s) needed to provide the service, and thus into resources, including algorithms, required. It therefore looks up another interpretation table, in the same manner as before, in order to find out what resources and algorithms are going to be needed to run the applications necessary to provide the service. (In practice, one interpretation table may provide both service and resource data.)
  • the MAP Manager 400 Knowing the resources, including algorithms, it will need, the MAP Manager will now look at its own world view, constructed on start-up, to find a functional and available digital signal processor 200 and spare ISDN channels 21 0, with which to run the relevant application. Having found the relevant resources, the MAP Manager 400 books the resources by entering a flag in the internal table which is the world view and sends messages back to the relevant agents 405, 410 to allocate switch settings 21 5 and to launch the relevant application.
  • the first task of the application is usually to answer the incoming call.
  • the application 600 using the relevant API 605, now tells the MAP Manager that the call should be answered.
  • the MAP Manager 400 tells the DLIC agent 405 to answer the call and the DLIC agent 405 passes the message on to the application via the MAP Manager 400.
  • the MAP Manager 400 now reports back to the application 600 that the call has been answered or that there has been a failure. At this point, the user who has initiated the call hears the ring tone leave the line.
  • the application next instructs the MAP Manager 400 to play a file.
  • the MAP Manager 400 does this by means of the speech card 1 1 0 and by passing a request to the SC2 agent 435. Once notified that the file has been played, the MAP Manager 400 sends notification back to the application 600.
  • the above describes the first steps in the running of an application 600 to provide a service using the MAP 1 50.
  • the application 600 will continue to control provision of the service until it has concluded.
  • the MAP Manager 400 will send an acknowledgement back to the DLIC agent 405 and the DLIC agent 405 will clear the line. This means the switches 21 5 will be opened and the resources will be "torn down", for instance by marking the digital speech processors 200 as available again in the internal table of the MAP Manager 400.
  • the DLIC 105 carries relatively little data. There is significantly more data on the speech cards 1 10.
  • the 68,000 processor on a speech card 205 runs the VXWorks UNIX kernel 1 70 in real time, by means of which it can run VX Works. If the speech card 1 10 receives a play request from the MAP Manager 400, it is VX Works which handles it. That is, it runs a file off disk without involving the main processor. (This is a known use of UNIX.)
  • service request messages enter the system through the SMTP gateway 725 from the computing platform 1000.
  • the service request is physically transferred to the system and (usually) placed on the relevant generic service queue 705, 710.
  • This gateway 725 relates SMTP addresses to generic service queues 705, 710.
  • the addresses of the available generic service queues 705, 710 are of the form
  • ⁇ service > is the name of the generic service queue. It should be noted that the ⁇ user > field may not be used or may have different interpretations in different services. Messages to non-existent services are discarded. Messages to services which require immediate delivery will be sent directly to the relevant service channel queue 730, 735.
  • the process is the same where a service request has been received at the SMTP gateway 725 as described above for the "Incoming PSTN Call Process". That is, the MAP manager 440 will use its various agents as described above with reference to Figure 1 1 .
  • the above describes service provision which runs to its normal end. It may be that the user rings off while a file is still being played. In this event, the DLIC agent 405 will notify the MAP Manager 400 which in turn notifies the speech card agent 410 that the file should be stopped. The speech card agent 410 will tell the relevant speech card 1 10 to stop the file and report back to the MAP Manager 400 which in turn sends an acknowledgement back to the DLIC agent 405, and notifies the application that the line has cleared, once any house-keeping activites are completed, such as billing. Once complete, the application terminates which results in tearing down the resources, as before.
  • the MAP Manager 400 may find that it does not have sufficient resource, such as "play”. In these circumstances, the MAP Manager 400 will seek to change the available resources and therefore to change its world view. It may do this by deleting "recognition” from a processor, as long as it is not in use, and substituting "play" resource.
  • a digital signal processor 200 In a different problem scenario, there may be functional difficulties, for instance with a digital signal processor 200.
  • a speech card 1 10 was providing a play file. This is done in discreet amounts.
  • the digital signal processor 200 should respond in a given time (to VX Works) to say it has played a required section of a file. If a digital signal processor 200 has "died", VX Works will never receive an answer. In these circumstances, the speech card agent 410 will reload the code to the digital signal processor 200. It will, in practice, try this reload three times. If the speech card agent 410 has not received any response from the digital signal processor 200 after three reloads, it will report the digital signal processor 200 to the MAP Manager 400 as being of doubtful integrity. The MAP Manager 400 will select another DSP 1 10 and load the relevant algorithm. The MAP Manager 400 will subsequently only use the digital signal processor 200 marked as of doubtful integrity in emergencies.
  • the text to speech (TTS) agent 420 accesses resources in a dedicated processor via a network interface card 1 30. The TTS agent 420 will send a sentence to the dedicated processor. It receives back a 64K speech file which the TTS agent 420 runs and plays through a digital signal processor 200
  • Running the digital line interface card 105 is relatively easy in view of the lower data quantities. More of the management effort tends to he with the speech cards 1 10.
  • the processor on the MAP host running UNIX, is usually underutilised. This processor can be used to host text to speech or STAP algorithms.
  • the TTS agent 420 is not controlling hardware in the manner of the other agents 405, 410, 41 5, 425 but is controlling processor resource. The TTS agent 420 therefore has to allocate resource in a different way.
  • the speech card agent 410 measures resource in terms of channels on the digital signal processors 200 and how much 68K processors hire an application will take. For instance, for multi-frequency tone recognition, ten channels would need to be allocated and 2% of a UNIX controlling process.
  • TTS agent 420 it is necessary to look at processing resource and it will be measured in megabytes and channels, for instance 32 megabytes and seven channels.
  • the TTS agent 420 is directly connected to the speech card 1 10 by socket, this providing a real time connection.
  • the MAP Manager will therefore instruct the speech card agent 410 that it needs 64K play capacity and a socket interface.
  • TCP/IP runs on the Ethernet at about 2 megabits per sec which is the equivalent of about 27 channels.
  • the socket arrangement avoids a bottleneck at the PC bus point which would only be able to provide about 1 2-18 channels off disk.
  • the STAP agent 45 provides the inverse process to the TTS agent 420. Speech is received through the speech card agent 410 which does some pre-processing. It then sends speech to the STAP agent 425. The STAP agent 425 returns a recognition result and the speech card agent 410 notifies the MAP Manager 400 accordingly. OUTGOING FILE PROCESS FROM MAP TO MESSAGING SYSTEM
  • Some backbone services potentially require an element of communication with the requesting user. This might be to provide a booking reference number, to advise of problems in being able to contact some parties, or perhaps to advise of an inbound communication.
  • the MAP SMTP gateway 725 must be able to create/forward outbound messages from the MAP platform 1 50 and some client software is also desirable to receive and act upon such messages This client software would normally be iconised until activated by message arrival when it should interrupt the user to request what action should then be taken.
  • the MAP primarily needs to output files via an FTP link to the call records database 2030 for use by the call records process 2020 associated with the user's Web server 1010.
  • backbone services are important in enabling more sophisticated services to be provided, incorporating within them one or more backbone services These can be addressed by client software.
  • backbone services may also be provided to enable facilities such as user registration and call accounting). For the purpose of the present specification only one of these backbone services is described below This is the E-Mail Delivery Service
  • the queue for this service takes as its input a service request message de in text) delivered from the user's computing platform 1000 It attempts to deliver this message by speech to one or more specified telephone numbers.
  • the message may be delivered by the voice determined by the service address chosen according to the following table:
  • the service comes in two forms. If the user field is present in the address and is all digit, it is interpreted as the telephone number which should be dialled from the United Kingdom (UK) to contact the (single) receiving party, with the body of the message being taken as the unstructured whole of the communication. If the user field is absent, the message body is taken as being structured potentially to enable distribution to many parties.
  • UK United Kingdom
  • the MAP 1 50 can make a number of attempts at delivery of a message to a given party and, if the message cannot be delivered, a notification message can be dispatched to the originator giving the reason for non-delivery. If the target telephone line is answered, there is a simple service announcement followed by a query as to whether the message can be delivered. Once delivered, the customer can have the option to hear the message again or to receive a FAX copy. If delivery was turned down, a simple message can be sent to the originator detailing the non-delivery.
  • the MAP platform receives the request message and processes it, using the text of the message to synthesise a voice message. It then attempts to call each of the telephone numbers it has been passed in the request message.
  • the receiver is requested to press a DTMF (Dual Tone Multi Frequency) button and the synthesised message is delivered. If no DTMF button is pressed, or the call was not answered in the predetermined time, no message is delivered and the MAP will attempt to redeliver it a number of times, after specified intervals.
  • DTMF Dual Tone Multi Frequency
  • the status of all these messages can be recorded by the MAP platform 400 and used as the basis for charging the customer.
  • records at the WWW server can also be updated from the MAP platform 400. These records can be used to build WWW pages for use when a user requests information about the state of her request.
  • WWW browser It is not necessary to use a WWW browser. It could be replaced with with a specialist client for instance, which may offer the user greater versatility. Similarly, the WWW server could be replaced with a specialist server.
  • the client server could make use of portable code such as JAVA applets or Microsoft ActiveX.
  • the client could be replaced with an automated device such as a monitor, this would then send the request to the server when a monitored device reached a specified state.
  • the MAP platform 400 could be replaced by other software/hardware capable of text to speech conversion and call set up.
  • the PSTN may also be replaced by another form of network which can carry voice, including the Internet.
  • the MAP platform 400 could be replicated and located at goegraphically separate locations. Request messages can then be routed to an appropriate instance of the MAP platform (or its equivalent) according to a routing algorithm located at the WWW server or at another location, for instance a computer located between the WWW server and the MAP platform 400. This would enable network loading, cost and value to be adjusted to the benefit of the service providers and the customer.
  • MAP applications can generate log files which describe actions taken by the platform for a particular call. Additional information may be held in these log files to provide information for billing purposes. For example, the 'servicename' and user account number can be included; this information could be included as part of the structured messages so that layered services such as 'PhonE-mail' which call upon other, more basic services can pass the essential billing information forward in a way which is compatible with GUI originated messages.
  • the log files once created would normally be dispatched to a specified mail address where they would be analysed to extract information for billing purposes. If this is to be handled on-platform the receiving process may take the form of a service queue. Potentially, billing information can be made available to the user via WWW or other network connection.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne un serveur web (1000) et un navigateur web (315), lesquels sont utilisés pour structurer les demandes de message destinées à une plateforme (150) fonctionnant comme passerelle entre l'Internet (155) et un réseau de télécommunications. Les demandes de message structurées comprennent des informations de contenu de message et des informations de destination de message. Les informations de destination peuvent facultativement comprendre plusieurs identificateurs de destination. Une seule demande de message peut alors être envoyée à la plateforme (150) où elle sera utilisée pour envoyer un contenu de message commun vers plusieurs destinations. Les demandes de message peuvent être envoyées dans un format SMTP compatible et la plateforme peut être pourvue d'une capacité de traduction de texte en sons vocaux de façon à pouvoir transmettre le contenu du message à des utilisateurs connectés à un réseau de télécommunications. Le serveur web peut accéder à une mémoire de données associée au client de façon que le client peut générer un répertoire de destinations et composer les messages à l'avance. Le serveur web peut en outre accéder à des données d'enregistrement d'appels et peut télécharger pratiquement en temps réel des informations d'état d'appel mémorisées sous forme de données d'enregistrement d'appels par la plateforme (150).
PCT/GB1998/000126 1997-01-15 1998-01-15 Procede et appareil de messagerie WO1998032272A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU56709/98A AU5670998A (en) 1997-01-15 1998-01-15 Method and apparatus for messaging

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US78413197A 1997-01-15 1997-01-15
US08/784,131 1997-01-15

Publications (1)

Publication Number Publication Date
WO1998032272A1 true WO1998032272A1 (fr) 1998-07-23

Family

ID=25131443

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB1998/000126 WO1998032272A1 (fr) 1997-01-15 1998-01-15 Procede et appareil de messagerie

Country Status (2)

Country Link
AU (1) AU5670998A (fr)
WO (1) WO1998032272A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2809565A1 (fr) * 2000-05-26 2001-11-30 Jacques Pozzetto Systeme de diffusion de messages
WO2001093560A2 (fr) * 2000-05-26 2001-12-06 The Dot Phone Company Limited Systeme d'envoi de messages
EP1355455A1 (fr) * 2002-04-15 2003-10-22 Siemens Aktiengesellschaft Procédé de distribution de message
EP1367784A1 (fr) * 2002-05-27 2003-12-03 Siemens Aktiengesellschaft Service de messagerie sur la base de déclenchement d'évènement
EP1546970A1 (fr) * 2002-07-29 2005-06-29 Trade Wind Communications Ltd. Procede de communications a grande capacite faisant intervenir des supports de distribution multiples
US7093025B1 (en) 2000-10-04 2006-08-15 International Business Machines Corporation SMTP extension for email delivery failure
US10992615B2 (en) * 2017-12-01 2021-04-27 Trusted Voices, Inc. Dynamic open graph module for posting content one or more platforms

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1993007566A1 (fr) * 1991-10-04 1993-04-15 Motorola, Inc. Acheminement temporaire de messages et selection de destination
WO1994006230A2 (fr) * 1992-09-02 1994-03-17 Octus, Inc. Emetteur de messages multimode
EP0631419A1 (fr) * 1993-06-22 1994-12-28 Vmx Inc. Système de courrier électronique ayant des messages vocaux intégrés
WO1995026092A1 (fr) * 1994-03-22 1995-09-28 Ericsson Messaging Systems Inc. Systeme de traitement d'appels
WO1996009710A1 (fr) * 1994-09-16 1996-03-28 Octel Communications Corporation Systeme d'annuaire et de communications multimedias par reseau, et son procede d'exploitation
GB2301260A (en) * 1995-05-26 1996-11-27 Ibm Voice mail system
US5610910A (en) * 1995-08-17 1997-03-11 Northern Telecom Limited Access to telecommunications networks in multi-service environment
WO1997013352A1 (fr) * 1995-09-29 1997-04-10 Northern Telecom Limited Procedes et appareils permettant d'emettre des communications vocales
US5633916A (en) * 1994-12-30 1997-05-27 Unisys Corporation Universal messaging service using single voice grade telephone line within a client/server architecture

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1993007566A1 (fr) * 1991-10-04 1993-04-15 Motorola, Inc. Acheminement temporaire de messages et selection de destination
WO1994006230A2 (fr) * 1992-09-02 1994-03-17 Octus, Inc. Emetteur de messages multimode
EP0631419A1 (fr) * 1993-06-22 1994-12-28 Vmx Inc. Système de courrier électronique ayant des messages vocaux intégrés
WO1995026092A1 (fr) * 1994-03-22 1995-09-28 Ericsson Messaging Systems Inc. Systeme de traitement d'appels
WO1996009710A1 (fr) * 1994-09-16 1996-03-28 Octel Communications Corporation Systeme d'annuaire et de communications multimedias par reseau, et son procede d'exploitation
US5633916A (en) * 1994-12-30 1997-05-27 Unisys Corporation Universal messaging service using single voice grade telephone line within a client/server architecture
GB2301260A (en) * 1995-05-26 1996-11-27 Ibm Voice mail system
US5610910A (en) * 1995-08-17 1997-03-11 Northern Telecom Limited Access to telecommunications networks in multi-service environment
WO1997013352A1 (fr) * 1995-09-29 1997-04-10 Northern Telecom Limited Procedes et appareils permettant d'emettre des communications vocales

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LOW C.: "Internet telephony red herring", HP LABORATORIES TECHNICAL REPORT, no. 96-98, June 1996 (1996-06-01), PALO ALTO, CA, USA, pages 1 - 15, XP002043669 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2809565A1 (fr) * 2000-05-26 2001-11-30 Jacques Pozzetto Systeme de diffusion de messages
WO2001093560A2 (fr) * 2000-05-26 2001-12-06 The Dot Phone Company Limited Systeme d'envoi de messages
WO2001093560A3 (fr) * 2000-05-26 2002-06-06 Dot Phone Company Ltd Systeme d'envoi de messages
US7093025B1 (en) 2000-10-04 2006-08-15 International Business Machines Corporation SMTP extension for email delivery failure
EP1355455A1 (fr) * 2002-04-15 2003-10-22 Siemens Aktiengesellschaft Procédé de distribution de message
EP1367784A1 (fr) * 2002-05-27 2003-12-03 Siemens Aktiengesellschaft Service de messagerie sur la base de déclenchement d'évènement
WO2003101056A1 (fr) * 2002-05-27 2003-12-04 Siemens Aktiengesellschaft Interface de programmation d'application pour services de messagerie commandes par des evenements dans des reseaux longues distances
EP1546970A1 (fr) * 2002-07-29 2005-06-29 Trade Wind Communications Ltd. Procede de communications a grande capacite faisant intervenir des supports de distribution multiples
EP1546970A4 (fr) * 2002-07-29 2008-01-23 Connxion Ltd Procede de communications a grande capacite faisant intervenir des supports de distribution multiples
US7715032B2 (en) 2002-07-29 2010-05-11 Connxion Ventures Limited Bulk communications process using multiple delivery media
US10992615B2 (en) * 2017-12-01 2021-04-27 Trusted Voices, Inc. Dynamic open graph module for posting content one or more platforms

Also Published As

Publication number Publication date
AU5670998A (en) 1998-08-07

Similar Documents

Publication Publication Date Title
US6438215B1 (en) Method and system for filter based message processing in a unified messaging system
US6233317B1 (en) Multiple language electronic mail notification of received voice and/or fax messages
US5740230A (en) Directory management system and method
US6498835B1 (en) Method and system for providing visual notification in a unified messaging system
US5179585A (en) Integrated voice messaging/voice response system
US6868144B2 (en) Method and system for interfacing systems unified messaging with legacy systems located behind corporate firewalls
US6014711A (en) Apparatus and method for providing electronic mail relay translation services
CA2114561C (fr) Dispositif integration les salutations a un agenda
US5475738A (en) Interface between text and voice messaging systems
CN1146214C (zh) 用于识别和应答呼叫者的方法和装置
US5995596A (en) System and method for coordination of multimedia messages across multiple systems
US9571445B2 (en) Unified messaging system and method with integrated communication applications and interactive voice recognition
US6219413B1 (en) Apparatus and method for called-party telephone messaging while interconnected to a data network
WO1998013993A1 (fr) Dispositif pour fournir des services de communication
JPH08251292A (ja) ソフトウェア・プロセスのための音声メール・メッセージの自動配信の配置構成
JPH1070612A (ja) 音声処理システム
CA2220317A1 (fr) Systeme permettant l'acces a des boites aux lettres electroniques et a des messages multimedia au moyen de l'internet et du telephone
JP2000504515A (ja) ワイヤレス・メッセージ送達システム
EP0985297A2 (fr) Systeme de gestion integree de messagerie et de communications
WO2001065871A1 (fr) Procede et systeme de constitution d'interface entre des systemes de messagerie unifiee comportant des dispositifs existants situes derriere des gardes-barrieres communs
WO1998032272A1 (fr) Procede et appareil de messagerie
US20030043973A1 (en) Voice mail apparatus and method of processing voice mail
US7327832B1 (en) Adjunct processing of multi-media functions in a messaging system
US6771745B2 (en) Method and apparatus for telephone dialling using a network device
JP3609593B2 (ja) 契約業務サポートシステム、契約業務サポート方法

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 09091917

Country of ref document: US

AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 1998533941

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase