Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
4878240
Lin , ; et al.
October 31, 1989
Title
Multi-service telephone switching system
Abstract
Enhanced telephone services are provided through a multi-service telephone switching system that contains a programmable adjunct connected to a telephone switching system. Specifically, this system includes a telephone switch that serves at least one subscriber and an adjunct connected both through one or more distinct paths, such as a number of hunt group lines, and through a datalink, such as a simplified message desk datalink, to the telephone switch. The telephone switch routes a telephone call involving this subscriber to the adjunct through an available hunt group line and provides a message to the adjunct over the datalink specifying a condition under which the call was routed. In response to this message, the adjunct takes complete control of the call substantially throughout the remainder of its duration and provides a desired enhanced service that has been pre-defined by a service script stored within the adjunct. Different service scripts can be invoked to provide correspondingly different enhanced services to the subscriber depending upon the specific condition for which the call was routed to the adjunct and/or a specific event occurring during the call.
Inventors:
Lin; Steve M.
(East Brunswick,
NJ
)
, Rizzo; Joseph F.
(Lincroft,
NJ
)
Assignee:
Bell Communications Research, Inc.
(Livingston,
NJ
)
Appl. No.:
148331
Filed:
January 25, 1988
Current U.S. Class:
379/88.22
379/198
379/201.02
379/201.05
379/207.02
379/269
Field of Search:
379/67,88,201,211,334,269,89 370/58,62
U.S. Patent Documents
3668317
June 1972
Vitalo
3920908
November 1975
Kraus
4232199
November 1980
Boatwright et al.
4376875
March 1983
Beirne
4540850
September 1985
Herr et al.
4611094
September 1986
Asmuth et al.
4612416
September 1986
Emerson et al.
4653085
March 1987
Chan et al.
4747127
May 1988
Hansen et al.
Other References
"The Software Architecture for a Large Telephone Switch", B. K. Penny et al., IEEE Trans. on Communications, vol. COM-30, Jun. 1982, pp. 1369-1378. .
"Functional Programming Language for Switching Description and its Hardware Architecture", M. Imase et al., Proc. of ISS 84, Florence, Italy, 7-11 May 1984, Sec. 13C, Paper 2, pp. 1-7. .
"Using Artificial Intelligence Technique in the Design of Software for Digital Switching System (DSS)", S. Bourgault et al. Proc. of ISS 84, Florence, Italy, 7-11 May 1984, Sec. 13C, paper 4, pp. 1-6. .
"Evolution of High Level Programming Languages used in the Development of Large Telephone Systems", D. R. Anderson et al., Proc. of ISS 84, Florence, Italy, 7-11 May 1984, Sec. 13C, Paper 3, pp. 1-7. .
"Intelligent Network/2: A Flexible Framework for Exchange Services", P. Miller, Bell Communications Research Exchange, vol. 3, Issue 3, May/June 1987, pp. 9-13. .
J. T. Boatwright, "Access Electromechanical Switching Enhancements", Conference Record of IEEE International Conference on communications: Integrating Communication for World Progress, Boston, MA, Jun. 19-22, 1983, vol. 1, pp. 250-257..~
Primary Examiner:
Brown; Thomas W.
Attorney, Agent or Firm:
Falk; James W.
Claims
We claim:
1. A switching system adjunct for use in conjunction with a telephone switch to provide enhanced telephone services to at least one telephone subscriber served by said telephone switch and comprising:
a programmable switch providing first and second sets of interfaces, wherein one of said interfaces within said first set is for connection to at least one path in a plurality of paths emanating from a telephone switch;
at least one peripheral device connected to an interface within said second set;
means for storing a sequence of functional components which form a service script and which collectively define an enhanced service; and
a host processor connected to said storing means, said peripheral device and said programmable switch and for connection through a datalink to said telephone switch for controlling said peripheral device and said programmable switch in a manner defined by said service script in order to provide the enhanced service to a telephone subscriber; wherein the adjunct, in response to a message received over said datalink regarding a corresponding telephone call that is routed by said telephone switch over said one path to said adjunct, is able to take control over said telephone call substantially throughout the remainder of its duration in order to provide said enhanced service to said one subscriber.
2. The adjunct of claim 1 further comprising means for controllably terminating the routed call within said adjunct or directing the routed call through said programmable switch to a second one of said paths substantially throughout the remainder of the duration of said routed call.
3. The adjunct of claim 2 wherein said host processor includes service control means operative in conjunction with said storing means for executing the service script to provide said enhanced service, wherein said service control means comprises:
means responsive to a trigger for accessing the service script from said storing means in order to provide an accessed service script; and
means responsive to a returned result and a state of said accessed service script for selecting one of said functional components in said accessed service script for current execution; and
said host processor further includes switching control means operative in conjunction with said storing means for appropriately controlling said programmable switch to selectively perform telephone switching operations involving individual ones of said paths, wherein said switching control means comprises:
means responsive to said one functional component for invoking said programmable switch to perform a desired switching operation involving said routed telephone call appearing on a first one of said paths and for producing, when appropriate, said returned result;
means responsive to said programmable switch for detecting an event associated with a corresponding condition of said telephone call; and
means responsive to said detected event for generating said trigger.
4. The adjunct of claim 3 wherein said switch invoking means further comprises means for decoding said one functional component into a corresponding sequence of instructions for appropriately controlling said programmable switch.
5. The adjunct of claim 4 wherein said host processor further comprises: means operative in conjunction with said storing means and responsive to a code existing within said message for invoking a pre-defined sequence of functional components so as to appropriately process said routed call.
6. The adjunct of claim 5 further comprising: means for receiving a telephone call appearing over one of said paths and placed to a logical number associated with a particular subscriber and for re-directing the received call over another one of said paths to a physical number associated with the particular subscriber.
7. The adjunct of claim 6 wherein the adjunct further comprises means for producing a different trigger for an incoming call, an outgoing call, a no-answer, a busy line, a remote access or an occurrence of a specified time and date.
8. The adjunct of claim 7 wherein said event detecting means further comprises means for detecting timer events.
9. The adjunct of claim 3 further comprising: means responsive to said one functional component for appropriately controlling the peripheral device.
10. The adjunct of claim 9 wherein the peripheral device controlling means further comprises: means responsive to said one functional component for generating, when appropriate, a request for service by said peripheral device.
11. The adjunct of claim 10 wherein said peripheral device controlling means further comprises: means for decoding said one functional component into a corresponding sequence of instructions for appropriately controlling said peripheral device.
12. The adjunct of claim 11 further comprising: means responsive to said service request for scheduling a task as requested by said one functional component for said peripheral device and, upon availability of said peripheral device to perform a task, instructing said peripheral to perform the scheduled task.
13. The adjunct of claim 12 wherein said peripheral device comprises: a voice messaging system for recording and playing back voice messages.
14. A telephone switching system for providing an enhanced telephone service comprising:
a telephone switch for serving at least one telephone subscriber connected thereto; and
a switching system adjunct connected to said telephone switch by a datalink and at least one path in a plurality of paths emanating from said telephone switch, wherein the adjunct stores a corresponding service script associated with the one subscriber and which defines an enhanced service for the subscriber such that the adjunct, in response to a message that is received over said datalink from said telephone switch regarding a corresponding telephone call that is routed by said telephone switch over said one path to said adjunct, executes said service script and takes control over said telephone call substantially throughout the remainder of the duration of the telephone call in order to provide the enhanced service to said one subscriber, wherein the adjunct comprises:
a programmable switch providing first and second sets of interfaces wherein an interface within said first set is connected to said one path;
at least one peripheral device connected to an interface within said second set;
means for storing a sequence of functional components which form the service script; and
a host processor connected to said storing means, said peripheral device and said programmable switch and connected through said datalink to said telephone switch for controlling said peripheral device and said programmable switch in a manner defined by said service script in order to provide the enhanced service to said one subscriber.
15. The telephone switching system of claim 14 further comprising: means for controllably terminating the routed call within said adjunct or directing the routed call through said programmable switch to a second one of said paths substantially throughout the remainder of the duration of said telephone call in order to provide said enhanced service.
16. The telephone switching system of claim 15 wherein the message comprises a telephone number for a calling party and a code indicative of a condition under which the telephone switch routed the telephone call to said one path.
17. The telephone switching system of claim 16 wherein said host processor includes service control means operative in conjunction with said storing means for executing the service script to provide said enhanced service, wherein said service control means comprises:
means responsive to a trigger for accessing said service script from said storing means in order to provide an accessed service script; and
means responsive to a returned result and a state of said accessed service script for selecting one of said functional components in said accessed service script for current execution; and
said host processor further includes switching control means operative in conjunction with said storing means for appropriately controlling said programmable switch to selectively perform telephone switching operations involving individual ones of said paths, wherein said switching control means comprises:
means responsive to said one functional component for invoking said programmable switch to perform a desired switching operation involving said routed telephone call appearing on a first one of said paths and for producing, when appropriate, said returned result;
means responsive to said programmable switch for detecting an event associated with a corresponding condition of said telephone call; and
means responsive to said detected event for generating said trigger.
18. The telephone switching system of claim 17 wherein said switch invoking means further comprises means for decoding said one functional component into a corresponding sequence of instructions for appropriately controlling said programmable switch.
19. The telephone switching system of claim 18 wherein said host processor further comprises: means operative in conjunction with said storage means and responsive to said code existing within said message for invoking a pre-defined sequence of functional components so as to appropriately process said routed call.
20. The telephone switching system of claim 19 further comprising: means for receiving a call appearing over one of said paths and placed to a logical number associated with a particular subscriber and for re-directing the received call over another one of said paths to a physical number associated with the particular subscriber.
21. The telephone switching system of claim 17 further comprising: means responsive to said one functional component for appropriately controlling the peripheral device.
22. The telephone switching system of claim 21 wherein the peripheral device controlling means further comprises: means responsive to said one functional component for generating, when appropriate, a request for service by said peripheral device.
23. The telephone switching system of claim 22 wherein said peripheral device controlling means further comprises: means for decoding said one functional component into a corresponding sequence of instructions for appropriately controlling said peripheral device.
24. The telephone switching system of claim 23 further comprising: means responsive to said service request for scheduling a task as requested by said one functional component for said peripheral device and, upon availability of said peripheral device to perform a task, instructing said peripheral device to perform the scheduled task.
25. In a telephone switching system, a method for providing enhanced telephone services to at least one telephone subscriber connected to a telephone switch comprising:
in said telephone switch routing a telephone call involving a subscriber from the telephone switch over a first path connecting said telephone switch to a switching system adjunct and generating a message, regarding said routed telephone call, over a datalink connecting said telephone switch to said switching system adjunct, wherein said message includes a telephone number for a calling party and a code indicative of a condition under which the telephone switch routed the telephone call to said first path; and
in said switching system adjunct and in response to said message executing a pre-defined corresponding service script which is associated with said subscriber and which defines an enhanced service for that subscriber, taking control of said routed telephone call substantially throughout the remainder of its duration so as to provide the enhanced service to said subscriber and controllably terminating the routed call within said adjunct or directing the routed call to a second path connecting said telephone switch to said adjunct substantially throughout the remainder of the duration of said telephone call in order to provide said enhanced service.
26. The method in claim 25 further comprising in said adjunct:
executing the service script within a host processor to provide said enhanced service, wherein said service script contains a sequence of functional components that collectively define said enhanced service and wherein said executing comprises:
accessing in response to a trigger said service script from a storage means connected to said host processor in order to provide an accessed service script; and
selecting in response to a returned result and a state of said accessed service script one of said functional components in said accessed service script for current execution; and
selectively performing telephone switching operations within said host processor, wherein said selective performing comprises:
invoking in response to said one functional component a programmable switch connected to said host processor and to said first and second paths to perform a desired switching operation involving said routed telephone call appearing on the first path and producing, when appropriate, said returned result;
detecting through said programmable switch an event associated with a corresponding condition of said routed telephone call; and
generating said trigger in response to said detected event.
27. The method in claim 26 wherein said switch invoking further comprises: appropriately decoding said one functional component into a corresponding sequence of instructions for controlling said programmable switch.
28. The method in claim 27 further comprising in the adjunct: invoking in response to said code existing within said message a pre-defined sequence of functional components so as to appropriately process said routed call.
29. The method in claim 28 further comprising in the adjunct: receiving a call appearing over one of said paths and placed to a logical number associated with a particular subscriber, and re-directing the received call over another one of said paths to a physical number associated with the particular subscriber.
30. The method in claim 26 wherein said selective performing further comprises: controlling, when appropriate and in response to said one functional component, a peripheral device that is connected to said programmable switch and to said host processor.
31. The method in claim 30 wherein said peripheral device controlling further comprises: generating in response to said one functional component a request for service by said peripheral device.
32. The method in claim 21 wherein said peripheral device controlling further comprises: decoding said one functional component into a corresponding sequence of instructions for appropriately controlling said peripheral device.
33. The method in claim 32 wherein said peripheral device controlling further comprises:
scheduling in response to said service request a task requested by said one functional component for said peripheral device; and
instructing said peripheral device to perform the scheduled task in response to availability of said peripheral to perform said task.
34. A telephone switching system for providing an enhanced telephone service comprising:
a telephone switch for serving at least one telephone subscriber connected thereto; and
a switching system adjunct connected to said telephone switch by a datalink and at least one path in a plurality of paths emanating from said telephone switch, wherein the adjunct stores a corresponding service script associated with the one subscriber and which defines an enhanced service for the subscriber such that the adjunct, in response to a message that is received over said datalink from said telephone switch regarding a corresponding telephone call that is routed by said telephone switch over said one path to said adjunct, executes said service script and takes control over said telephone call substantially throughout the remainder of the duration of the telephone call in order to provide the enhanced service to said one subscriber.
35. In a telephone switching system, a method for providing enhanced telephone services to at least one telephone subscriber connected to a telephone switch comprising:
in said telephone switch routing a telephone call involving a subscriber from the telephone switch over a path connecting said telephone switch to a switching system adjunct and generating a message, regarding said routed telephone call, over a datalink connecting said telephone switch to said switching system adjunct; and
in said switching system adjunct and in response to said message executing a pre-defined corresponding service script which is associated with said subscriber and which defines an enhanced service for that subscriber and taking control of said routed telephone call substantially throughout the remainder of its duration so as to provide the enhanced service to said subscriber.
Description
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to a multi-service telephone switching system which includes a programmable adjunct that is to be used in conjunction with a local switching system for providing enhanced telephone services.
2. Description of the Prior Art
A large expanding market exists for enhanced telephone services. Currently, enhanced telephone services, such as call waiting, speed calling and call forwarding, are provided through a local telephone switching system. Local switching systems that provide these services are generally large, handling upwards of 50,000 separate lines, and are typified by the 1AESS and 5AESS electronic switching systems manufactured by American Telephone and Telegraph (AT&T) Corporation. In general, telephone switches directly inter-connect local calling and called parties and, when required for long distance communication, route telephone calls from a calling party over a series of one or more trunk lines to a local switch situated some distance away from the calling party and located in the vicinity of the called party.
At present, these electronic switching systems are computer controlled with the specific switching functions implemented in a series of software routines which are commonly referred to as generics. These generics are developed by the switch manufacturer and then loaded into the switch for subsequent use at a customer's site, typically a local switching office. Through these generics, the switch is able to provide a pre-defined selection of enhanced services to any local customer that is connected to the switch.
As in any industry, customer needs frequently change over time. The telephone industry is no exception. For example, once a customer has utilized a particular enhanced service for a period of time sufficient for him or her to discover its limitations, the customer will demand an improved service that cures these limitations. For example, call waiting was offered, initially a few years ago, to provide a service through which customers would not automatically miss a telephone call if their line was busy. In essence, this service first provided a signal (typically a short tone) to a called party on a busy line that another party was attempting to reach him and then allowed the called party to switch between the two calling parties by flashing a switch hook on his telephone. At first, this service adequately met customer demand. However, after this service was used by a customer for a sufficient period of time, the customer quickly realized that every telephone call that occurred during the time his line was busy would generate a tone on his line regardless of who was calling him. This occurred simply because the local switch, which provided this service, was not programmed to discriminate between incoming calls to a customer. Yet many customers find that some calls are more important than others. Hence, call waiting customers felt that calls from certain parties could be interrupted while calls from other parties were simply too important and could not be interrupted. Therefore, a demand, yet unsatisfied, has arisen for selective call waiting in which the customer would define those telephone numbers to the local telephone operating company that are important to him. An incoming call from any of these numbers, that would occur during the time the customer's line was busy, would be allowed to generate a tone and interrupt any on-going call on that line. The customer could then switch back and forth between the two callers at will. Incoming telephone calls from other numbers would simply receive a busy signal. Similarly, new service demands constantly arise from customer experiences with other presently available enhanced services.
Therefore, enhanced services that are new, when first introduced, later become commonplace after being used for several years and spawn a demand for new services. Hence, to maximize revenue, local telephone operating companies must constantly change their available service mix to satisfy customer demand. Thus, the development of enhanced services should ideally become an ongoing rapid evolutionary process between a telephone company and its customers. Unfortunately, in practice, this is simply not the case, as will now be discussed.
As noted above, software generics that provide enhanced services reside within the local switch. Because these generics are developed by the switch manufacturer and not by the local telephone companies, the local telephone companies generally must rely on the switch manufacturer to develop and then disseminate an entirely new set (a so-called "release") of generics or alternatively supplement an existing release with various new generics before any new enhanced services could be offered to customers, even on a trial basis. This generally necessitated a complete or substantial re-programming of a switch. Specifically, these generics often vary widely among switches produced by different manufacturers. Inasmuch as a local telephone company frequently utilizes switches from a variety of different manufacturers, the local telephone company simply does not have the resources to expeditiously write generics for each different switch it uses and therefore must rely on the switch manufacturer to do so. Consequently, the local telephone companies are constrained to wait until the switch manufacturer completes a lengthy development effort to offer, what it believes to be, either a new release of generics or supplementary generics to an existing release. Now, even when either of these events occurs, the new release (or supplementary generics from an existing release) has yet to be loaded into an operational switch for field trials (actual market tests) in order to accurately assess customer demand for the newly available enhanced services. Frequently, during the course of such a trial, the local telephone company learns that certain services, just now provided by the switch manufacturers are not particularly useful or usable by customers while other services, not previously foreseen or implemented by the manufacturer, are highly in demand. These results are then fed back to the switch manufacturer which, in turn, appropriately modifies the current generics in the present release. As one can appreciate, this iterative development process results in both a great deal of delay and considerable expense to the switch manufacturers in developing each release and substantial business opportunities and concomitant revenues that are missed by the local telephone companies. Moreover, there is no guarantee that, when the modified release becomes available in a fully operational release, the marketplace demand for certain enhanced telephone services will still remain. In particular, as the capability of the telephone network increases, a customer who demands a particular enhanced service might well decide, over time, to utilize a readily available substitute, though non-identical service, for the service initially demanded. This, in turn, decreases the eventual sales for the initially demanded service once that service finally becomes available. Hence, as the delay lengthens between the time a demand for a particular enhanced service is first foreseen and the time that service is finally implemented in an operational release and then made available to customers on a wide scale, increasing uncertainty, as to the ultimate marketplace acceptance of this new service, will tend to corrupt any early prediction of revenue for this service.
Thus, as can be seen, the long lead times associated with developing fully functional generics has, in the past, and continues to significantly inhibit the ability of local telephone companies to expeditiously develop and field test new enhanced telephone services and then modify the services, if necessary, to quickly satisfy customer demand. As a result, local telephone companies often provided enhanced telephone services that were out of step with current customer demand and were thereby unable to tap significant business opportunities. Now, if new services could be very quickly developed and expeditiously trialed on a small scale, then the local telephone companies would be much more able to adequately define each new service to meet customer requirements and rapidly deploy that service with a markedly reduced chance of failure than that which presently occurs.
Thus, a need exists for a telephone switching system that can readily provide new enhanced telephone services without requiring that any of the generics utilized in a local telephone switch be re-programmed.
SUMMARY OF THE INVENTION
The above-described drawbacks in the provisioning of new enhanced telephone services are advantageously eliminated in accordance with the teachings of the present invention by a multi-service telephone switching system that utilizes a programmable adjunct in conjunction with a telephone switch. Specifically, this system includes a telephone switch that serves at least one subscriber and an adjunct that is connected to the telephone switch both through one or more distinct paths, such as a number of hunt group lines, and through a datalink, such as a simplified message desk datalink. The telephone switch routes a telephone call (e.g. forwards an incoming call and directly connects an outgoing call) involving this subscriber to the adjunct through an available hunt group line and provides a corresponding message to the adjunct over the datalink. This message typically specifies the calling number and a condition under which the call was routed to the available hunt group line. In response to this message, the adjunct takes complete control of the call substantially throughout the remainder of its duration and provides a desired enhanced service that has been pre-defined by a service script stored within the adjunct.
In particular, the telephone switch, typically a local switch, is connected to each one of a plurality of telephone subscribers through a separate corresponding one of a plurality of lines. The adjunct itself utilizes: a programmable switch providing first and second sets of interfaces, wherein various ones of the first set are connected to corresponding lines within the hunt group supplied by the telephone switch; at least one peripheral device connected to a particular interface within the second set; a storage device, typically a disk drive; and a host processor connected to the telephone switch, via the simplified message desk datalink, and also connected to the storage device, the peripheral device and the programmable switch.
In operation, the host processor controls the peripheral device and the programmable switch in accordance with a sequence of functional components which form a service script. The service script is stored within the storage device and collectively defines an enhanced service. To provide an enhanced service anytime during the call, the adjunct routes a call, that has been forwarded by the telephone switch, through the programmable switch throughout the remainder of the duration of the call in order for the adjunct to exercise substantial control over the call during this time. Since at this point and thereafter the adjunct has substantially complete control over the call, it is able to provide enhanced services to either the caller or called party on that call independently of any software, such as generics, executing within the local switch. This, in turn, eliminates any need to re-program the telephone (local) switch to provide the enhanced service.
Service scripts are sequences of functional components. Each functional component is a high level command that provides a certain function required to provide an enhanced service. An entire set of functional components provides all the necessary commands, in terms of high level telephone switching operations, to provide enhanced services. For example, some of these functional components, when executed, instruct the programmable switch to transmit a digit, collect a dialed number, establish a voice path through the switch between a caller and either a called party or a peripheral, and the like. Other functional components, when executed, instruct the peripheral device to provide a specific function, such as play a message, record a message, synthesize or recognize speech and the like.
Now, whenever an enhanced service is to be provided, specifically in response to a so-called trigger, an appropriate service script is read from a storage device. An interpretive process, illustratively called the SCP Process, determines, based upon an immediately prior state of the script and the value of a returned result, which functional component in the script is to be executed. The appropriate functional component is then sent to another process, illustratively referred to as the SSP Process. This process, similar to a run time compiler, decodes each functional component it receives into a pre-determined sequence of instructions. This sequence is used to appropriately instruct the programmable switch or a peripheral device used in the adjunct to perform the desired function specified by the functional component. Once the function has been performed, the SSP Process may provide a returned result. In addition, the SSP Process also detects events and sets appropriate triggers to invoke associated service scripts for separately processing each detected event. These events may originate within the programmable switch, such as illustratively an incoming call or a busy line, or may take the form of a software event occurring within the host processor, such as a time-out indication provided by a software timer.
By separating the software used to provide service logic functions (i.e. functional components) from the software used to implement actual switching and peripheral functions (decoding process), a programmer developing new telephone services is substantially, if not completely, relieved of the need to know any details of both the software which controls actual switching operations on the telephone switch and the software which controls actual switching and peripheral operation on the adjunct. Re-programming a short relatively simple high level service script becomes all that is required to provide a new enhanced service. Furthermore, the developed service script becomes independent of the actual hardware used in the adjunct. Consequently, the service logic (service scripts) becomes easily transportable; while, the switching logic (decoding process) is customized for a particular adjunct being controlled (e.g. much like a compiler is written for the instruction set of a particular machine; while the high level code to be compiled is usually machine independent, i.e. tansportable and executable on computers having significantly disparate instruction sets). Thus, use of the inventive adjunct advantageously permits enhanced telephone services to be quickly developed, trialed and modified, as needed, in order to expeditiously satisfy customer demand with a minimal expenditure of time and effort.
To easily provide enhanced services through existing telephone switches, each subscriber, in accordance with a preferred embodiment of the present invention, has two telephone numbers. One such number is a logical or published number. This is the number known to the telephone switch and is the one that others would dial to reach this subscriber. The other number is a physical number known only to the adjunct. Incoming calls to a subscriber's logical number are routed by the telephone switch (illustratively using a "call forwarding" feature) to a hunt group line. The call is then routed by the adjunct through the programmable switch for the duration of the call and, based upon the services desired by the called party and the condition (e.g. answered, busy or not answered) of his telephone line, routed to the physical number of the called party to ring his telephone or, for call forwarding, to the physical number of another party in order to ring the telephone there.
In accordance with a feature of the present invention, the adjunct can provide enhanced services based upon call screening. Since the adjunct, at least with respect to calls originating within a service area of the local switch, obtains the calling party's telephone number (so-called ANI information) from the local telephone switch for each incoming call, enhanced services can be provided which selectively prevent calls from reaching a subscriber or which selectively allow calls to be routed to the subscriber based upon the number of the calling party or information obtained through a database access using the number of the calling party.
BRIEF DESCRIPTION OF THE DRAWING
The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawing, in which:
FIG. 1 is a block diagram of a preferred embodiment of a system, that incorporates the teachings of the present invention, for providing enhanced telephone services;
FIG. 2 is a block diagram showing typical call flow through inventive system 100, depicted in FIG. 1, for processing an incoming telephone call;
FIG. 3 is a block diagram showing typical call flow through inventive system 100, depicted in FIG. 1, for processing an outgoing telephone call;
FIG. 4 shows the proper alignment of the drawing sheets for FIGS. 4A-4D;
FIGS. 4A-4D collectively depict a block diagram of Modular Switching Node (MSN) 400 that forms a portion of inventive system 100 shown in FIG. 1;
FIG. 5 is a block diagram of "#" sign detector 500 shown in FIGS. 4A-4D;
FIG. 6 diagrammatically shows an overview of the organization of and inter-process communication occurring within the software executing on host processor 490 shown in FIGS. 4A-4D;
FIG. 7 depicts a flowchart of SCP Process Routine 700 shown in FIG. 6;
FIG. 8 shows the proper alignment of the drawing sheets for FIGS. 8A-8C;
FIGS. 8A-8C collectively depict a flowchart of SSP Process Routine 800 shown in FIG. 6;
FIG. 9 shows the proper alignment of the drawing sheets for FIGS. 9A and 9B;
FIGS. 9A and 9B collectively depict a flowchart of Load Database Routine 900 that is executed as part of SSP Process Routine 800 shown in FIGS. 8A-8C;
FIG. 10 depicts a flowchart of SMD N - No Answer Routine 1000 that is also executed as part of SSP Routine 800 shown in FIGS. 8A-8C;
FIG. 11 depicts a flowchart of SMD B - Busy Routine 1100 that is also executed as part of SSP Routine 800 shown in FIGS. 8A-8C;
FIG. 12 depicts a flowchart of SMD D - Directly Dialed Routine 1200 that is also executed as part of SSP Routine 800 shown in FIGS. 8A-8C;
FIG. 13 shows the proper alignment of the drawing sheets for FIGS. 13A and 13B;
FIGS. 13A and 13B collectively depict a flowchart of SMD A - Forwarded Call Routine 1300 that is also executed as part of SSP Routine 800 shown in FIGS. 8A-8C;
FIG. 14 shows the proper alignment of the drawing sheets for FIGS. 14A and 14B;
FIGS. 14A and 14B collectively depict a flowchart of Software Event Routine 1400 that is also executed as part of SSP Process Routine 800 shown in FIGS. 8A-8C;
FIG. 15 shows the proper alignment of the drawing sheets for FIGS. 15A and 15B;
FIGS. 15A and 15B collectively depict a flowchart of Off Hook Routine 1500 that is also executed as part of SSP Process Routine 800 shown in FIGS. 8A-8C;
FIG. 16 depicts a flowchart of On Hook Routine that is also executed as part of SSP Process Routine shown in FIGS. 8A-8C;
FIG. 17 shows the proper alignment of the drawing sheets for FIGS. 17A-17C;
FIGS. 17A-17C collectively depict a flowchart of Digit Collection Routine 1700 that is also executed as part of SSP Process Routine 800 shown in FIGS. 8A-8C;
FIG. 18 depicts a flowchart of Answer Functional Component (FC) Routine 1800;
FIG. 19 depicts a flowchart of Call Forward FC Routine 1900;
FIG. 20 depicts a flowchart of Check ANI FC Routine 2000;
FIG. 21 shows the proper alignment of the drawing sheets for FIGS. 21A and 21B;
FIGS. 21A and 21B collectively depict a flowchart of Check Message FC Routine 2100;
FIG. 22 depicts a flowchart of Collect Digits FC Routine 2200;
FIG. 23 depicts a flowchart of Customer Answer FC Routine 2300;
FIG. 24 depicts a flowchart of Dialing FC Routine 2400;
FIG. 25 shows the proper alignment of the drawing sheets for FIGS. 25A-25B;
FIGS. 25A-25B collectively depict a flowchart of Give Path FC Routine 2500;
FIG. 26 depicts a flowchart of Go To FC Routine 2600;
FIG. 27 depicts a flowchart of Hang-Up FC Routine 2700;
FIG. 28 depicts a flowchart of Quit FC Routine 2800;
FIG. 29 depicts a flowchart of Page FC Routine 2900;
FIG. 30 depict a flowchart of Play Voice Message FC Routine 3000;
FIG. 31 shows the proper alignment of the drawing sheets for FIGS. 31A and 31B;
FIGS. 31A and 31B collectively depict a flowchart of Play Digit FC Routine 3100;
FIG. 32 depicts a flowchart of Record Message FC Routine 3200;
FIG. 33 depicts a flowchart of Record Telephone FC Routine 3300;
FIG. 34 depicts a flowchart of Release Line FC Routine 3400;
FIG. 35 depicts a flowchart of Return Result FC Routine 3500;
FIG. 36 shows the proper alignment of the drawing sheets for FIGS. 36A and 36B;
FIGS. 36A and 36B collectively depict a flowchart of Speech Synthesize FC Routine 3600;
FIG. 37 depicts a flowchart of Speech Recognition System Training FC Routine 3700;
FIG. 38 depicts a flowchart of Speech Recognize FC Routine 3800;
FIG. 39 depicts a flowchart of Stop Peripheral FC Routine 3900;
FIG. 40 shows the proper alignment of the drawing sheets for FIGS. 40A and 40B;
FIGS. 40A and 40B collectively depict a flowchart of Time and Date FC Routine 4000;
FIG. 41 depicts a flowchart of Wait FC Routine 4100;
FIG. 42 shows the proper alignment of the drawing sheets for FIGS. 42A-42C;
FIGS. 42A-42C collectively depict a flowchart of Call Re-direction *100 Service Routine 4200 that is executed within Digit Collection Routine 1700 shown in FIGS. 17A-17C;
FIG. 43 shows the proper alignment of the drawing sheets for FIGS. 43A-43D;
FIGS. 43A-43D collectively depict a flowchart of Review Voice Messages *200 Service Routine 4300 that is executed within Digit Collection Routine 1700 shown in FIGS. 17A-17C;
FIG. 44 shows the proper alignment of the drawing sheets for FIGS. 44A and 44B;
FIGS. 44A and 44B collectively depict a flowchart of Memory Dialing *300 Service Routine 4400 that is executed within Digit Collection Routine 1700 shown in FIGS. 17A-17C;
FIG. 45 shows the proper alignment of the drawing sheets for FIGS. 45A and 45B;
FIGS. 45A and 45B collectively depict a flowchart of Memory Dialing Call Routine 4500 that is executed as part of Memory Dialing *300 Service Routine 4400 shown in FIGS. 44A and 44B;
FIG. 46 shows the proper alignment of the drawing sheets for FIGS 46A-46E;
FIGS. 46A-46E collectively depict a flowchart of Memory Dialing Code Creation Routine 4600 that is also executed as part of Memory Dialing *300 Service Routine 4400 shown in FIGS. 44A and 44B;
FIG. 47 shows the proper alignment of the drawing sheets for FIGS. 47A-47C;
FIGS. 47A-47C collectively depict a flowchart of Memory Dialing Code Deletion Routine 4700 that is also executed as part of Memory Dialing *300 Service Routine 4400 shown in FIGS. 44A and 44B;
FIG. 48 depicts a flowchart of Ring Update *600 Service Routine 4800 that is executed within Digit Collection Routine 1700 shown in FIGS. 17A-17C;
FIG. 49 shows the proper alignment of the drawing sheets for FIGS. 49A-49C:
FIGS. 49A-49C collectively depict a flowchart of Voice Announcement Recording *700 Service Routine 4900 that is executed within Digit Collection Routine 1700 shown in FIGS. 17A-17C;
FIG. 50 shows the proper alignment of the drawing sheets for FIGS. 50A-50E;
FIGS. 50A-50E collectively depict a flowchart of Outgoing Announcement Routine 5000 that is executed as part of Voice Announcement Recording *700 Service Routine 4900 shown in FIGS. 49A-49C;
FIG. 51 shows the proper alignment of the drawing sheets for FIGS. 51A and 51B
FIGS. 51A and 51B collectively depict a flowchart of Personal Announcement Routine 5100 that is executed as part of Voice Announcement Recording *700 Service Routine 4900 shown in FIGS. 49A-49C;
FIG. 52 shows the proper alignment of the drawing sheets for FIGS. 52A-52C;
FIGS. 52A-52C collectively depict a flowchart of Group Announcement Routine 5200 that is executed as part of Voice Announcement Recording *700 Service Routine 4900 shown in FIGS. 49A-49C;
FIG. 53 shows the proper alignment of the drawing sheets for FIGS. 53A and 53B;
FIGS. 53A and 53B collectively depict a flowchart of Queued Call Back *800 Service Routine 5300 that is executed within Digit Collection Routine 1700 shown in FIGS. 7A-17C;
FIG. 54 shows the proper alignment of the drawing sheets for FIGS. 54A-54D;
FIGS. 54A-54D collectively depict a flowchart of Change PIN *950 Service Routine 5400 that is executed within Digit Collection Routine 1700 shown in FIGS. 17A-17C;
FIG. 55 depicts a flowchart of Intelligent Peripheral (IP) Process Routine 5500 shown in FIG. 6;
FIG. 56 depicts a flowchart of IP Request Routine 5600 that is executed as part of IP Process Routine 5500 shown in FIG. 55;
FIG. 57 shows the proper alignment of the drawing sheets for FIGS. 57A and 57B;
FIGS. 57A and 57B collectively depict a flowchart of IP Process Ready Message Routine 5700 that is executed as part of IP Process Routine 5500 shown in FIG. 55;
FIG. 58 shows the proper alignment of the drawing sheets for FIGS. 58A and 58B;
FIGS. 58A and 58B collectively depict a flowchart of IP Process Special Case Instructions Routine 5800 that is executed as part of IP Process Routine 5500 shown in FIG. 55;
FIG. 59 depicts a flowchart of Reserve Conference FC Routine 5900;
FIG. 60 depicts a flowchart of Add A Party FC Routine 6000; and
FIG. 61 depicts a flowchart of Delete A Party FC Routine 6100.
To facilitate understanding, identical reference numerals have been used to designate identical elements that are common to the figures.
DETAILED DESCRIPTION
After reading the following description, those skilled in that art will readily appreciate that the inventive system can service in a wide variety of telephone switching applications, some of which are discussed below. For purposes of illustration, the inventive system will be described in terms of an adjunct used in conjunction with a local telephone switching system for expeditiously providing enhanced telephone services without the need to modify any of the generics stored within the local switch.
Through the use of such an adjunct in conjunction with a local switch, a local telephone company can quickly develop and field trial an enhanced telephone service and then modify the service, if necessary, to expeditiously provide an enhanced service that satisfies customer demand with an minimal expenditure of time and effort. Advantageously, the service is fully developed by a local telephone company and not by a switch manufacturer and can be repetitively modified, if necessary, based upon actual customer feedback. Since the service is fully defined before it is incorporated into the switch generics, the service has a much higher probability of marketplace acceptance than that previously possible.
I. System Overview
A. Hardware Overview
A block diagram of a preferred embodiment of the inventive system is shown in FIG. 1. As shown, system 100 utilizes local electronic telephone switching system 200, which is preferably a 1AESS system manufactured by the American Telephone and Telegraph (AT&T) Corporation, modem 300 and modular services node (MSN) 400. MSN 400 is a relatively small self-contained computer controlled telephone switching system that functions as a switching adjunct to local switch 200. MSN 400 is connected to local switch 200 through a number of lines provided by the switch and through a simplified message desk (SMD) interface which contains an SMD datalink and various hunt group lines available on the switch.
To offer enhanced services through the inventive system to any one of enhanced service subscribers 150 (hereinafter referred to simply as subscribers 150), the local switch is programmed in a well known manner to directly forward an incoming call from anywhere, including but not limited to those subscribers appearing on a corresponding one of lines 220.sub.1, 220.sub.2, . . . , 220.sub.j that collectively form lines 220, to an available hunt group line 246.sub.1, 246.sub.2, . . . , or
246.sub.m, appearing within lines 246 that form a portion of hunt group lines 240. Coincident with the connection of such a call, a message is simultaneously transmitted over the SMD datalink. This message contains information regarding the manner in which the call was routed to the hunt group line, the directory number of the called party and, if the caller is within the local service area of local switch 200, the directory number of the calling station. This message, in its most expanded form, consists of:
where:
MD refers to a SMD message originating within local switch 200;
ggg=a pre-defined message desk number (within the range of 001-063);
mmm=specific hunt group line number (within a range of 0001-2047) on which the call appears;
c=SMD call routing code:
D for directly dialed calls to the hunt group;
A for calls forwarded to the hunt group;
B for calls forwarded to the hunt group resulting from a busy line at the called station; and
N for calls forwarded to the hunt group due to no answer at the called station;
xxx=directory number of called party; and
yyy=directory number of calling party (if available).
The SMD Datalink itself is a well known serial datalink. To connect this datalink through a dedicated telephone line, such as dataline 340, the datalink is connected, via lead 310, to 1200 baud modem 300. For an in-depth discussion of the SMD interface appearing on the 1AESS switch, the reader is referred to "Interface Description: Interface Between Customer Premise Equipment; Simplified Message Desk and Switching System: 1AESS", Bell Communications Research Technical Reference TR-TSY-000283, Issue 1, July 1985 (.COPYRGT.1985: Bell Communications Research, Inc.).
MSN 400 is also connected to a group of lines 241, consisting of lines 241.sub.1, 241.sub.2, . . . , 241.sub.n, for use in receiving directly dialed incoming ("remote") calls from local switch 200, and to a group of lines 260, consisting of lines 260.sub.1, 260.sub.2, . . . , 260.sub.p, for placing outgoing calls to the local switch. In general, the remote lines are used to permit a subscriber to access (dial into) the MSN from any telephone other than his own. To simplify implementation, lines 241 and 246 collectively form a single hunt group 240; however, this implementation is not critical. All the lines carrying calls connected to the local switch are preferably ground start lines wherein all ringing occurring on these lines is preceded by a momentary application of a ground level.
Through use of the SMD datalink and the hunt group lines available on the local switch, the MSN, in a manner to be described in detail below, processes incoming and outgoing calls from subscribers 150 without any direct appearance of the subscriber's loops on the MSN. Inasmuch as the MSN takes complete control of any call once that call has been routed to it by the local switch either through forwarding or a direct connection, the MSN provides enhanced services without any further involvement by the local switch other than to route traffic to and from the MSN and provide automatic number identification (ANI) information, if available, regarding the caller. This, in turn, advantageously allows a local telephone operating company to program the MSN to provide enhanced call services without modifying any of the generics stored on local switch 200. Moreover, the MSN is inventively structured and programmed in a manner, described in great detail below, that separates call processing from call switching. As a result, a user desiring to implement a new enhanced service does not need to re-program any switching function but rather utilizes these functions through pre-defined subroutines in order to implement a high level program that provides the desired service.
B. Operational Overview
Now, with this overall architecture in mind and to facilitate understanding, the discussion will now proceed to describe how calls are routed through the inventive system before discussing in detail the hardware and software which collectively form this system.
A block diagram showing typical call flow for an incoming telephone call through system 100, depicted in FIG. 1, is provided in FIG. 2. To allow the MSN to take complete control of a call and provide enhanced services, each subscriber has two telephone numbers within the local switch: a so-called "logical" number which is published in telephone directories and a so-called "physical" number which is the number of the actual line that is connected to the local switch and associated with his telephone. The subscriber is only aware of his logical number; the physical number is only known by the MSN. All calls to a subscriber's logical number are forwarded by the local switch to a hunt group line for subsequent connection to the MSN. All calls, originating from the MSN, to a physical number are routed by the local switch to the corresponding subscriber.
Specifically, to receive a call from, e.g. a caller connected to line 220.sub.1 as depicted in step A, the caller first picks up the receiver of his telephone and then dials a logical number of a called party. Thereafter, as shown in step B, the local switch forwards the call through any available line, illustratively line 246.sub.1, within the hunt group. The MSN then detects ringing in this hunt group line. Simultaneously therewith, the local switch, through the SMD datalink, provides a message, as described above, over serial dataline 340 to MSN 400 that contains the reason the call reached (was routed to) the hunt group (here it was forwarded), the directory ("logical") number of the called party and, if an intra-office call, the directory number of the caller. In response to this message, the MSN provides whatever enhanced services are desired, such as not dialing this call to the called party.
Where a connection is to be made between the caller and called parties, the MSN, once having received an incoming forwarded call, dials ("outpulses") the physical number associated with the called party, as shown in step C, using any available line, such as line 260.sub.2, located within outgoing lines 260. Thereafter, local switch 200, as shown in step D, completes the routing of the call to the called party.
Now, to gain an appreciation of the enhanced services available through inventive system 100, assume that a caller has just dialed a call. The MSN can then outpulse the physical number of the called party, as noted above, and, for an intra-office call, announce to the called party, using a voice synthesizer, the identity of the caller. The MSN will then prompt the called party to dial a given digit to either accept or reject the incoming call. In the event, the called party accepts the call, then the MSN connects the call to the called party. Alternatively, in the event the called party refuses to take the call, the MSN will then illustratively return a voice announcement to the caller indicating that the called party refuses to take the call and will then release the called party. If the called party utilizes a call forwarding service, as described below, the MSN could initiate a call to a forwarded telephone number instead of to the called party's physical number.
In addition, various enhanced services are provided to handle no answer situations. In this case, if the called party did not answer the telephone, further call processing would depend upon the services to which the called party subscribes. For example, if the called party subscribed to a queued call back service and an intra-office call occurred, then, after a specified number of rings have occurred, the name and number of the caller, and date and time at which the call occurred, in a manner to be described in detail below, would all be automatically recorded ("queued") within a database internal to the MSN for later retrieval by the called party. This would occur without any further action required by the caller. Later, whenever the called party picks up the receiver of his telephone, he or she would be informed of the existence of any queued calls by either a stutter dial tone, an announcement or some other indication depending upon how this service was defined. Alternatively, if the called party subscribed to a so-called anywhere call pick-up service, an announcement would typically be provided to the caller informing him that the called party is being paged. Concurrently, the MSN would instruct the local switch to page the called party using a standard radio paging system. Upon being paged, the called party could then respond to the call in real time by directly dialing into the MSN through a remote line. In this case, the called party would, after being prompted, provide a personal identification number to the MSN. The MSN would then connect the caller to the called party. Now, alternatively, if the called party subscribed to a voice messaging service, as described later, then the caller, in lieu of waiting for the called party to be paged, could leave a voice message for the called party.
The above call flow shown in FIG. 2 assumes that all calls to a called party are forwarded to the MSN by the local switch. Clearly, this procedure could be readily modified such that calls are only forwarded to the MSN in the event the called party is either busy or does not answer his telephone. Now, as before, if the called party's line was busy and depending upon what enhanced services the called party subscribes to, the MSN will either record calling party's name and number along with the date and time of the call, initiate a radio page to the called party or accept a voice message from the caller. Alternatively, if the called party's line does not answer within a specified number of rings, the MSN would determine if the called party desires to have his calls forwarded to a remote number and if so would re-dial the call accordingly.
A similar block diagram showing typical call flow for an outgoing telephone call through system 100, depicted in FIG. 1, is provided in FIG. 3. In general, a variety of new enhanced outgoing services can be provided that rely on a switch to perform call screening based upon calling and called numbers and to translate a dialed-number to a routing number. Many electronic switches in use today, such as the 1AESS, do not provide this capability. However, inventive system 100 does. Specifically, once a calling party goes off-hook as shown in step A, local switch 200 directly connects ("hotlines") him to an available hunt group line, such as line 246.sub.1 within lines 246. At the same time, the local switch transmits an SMD message over the SMD datalink to dataline 340. This message states that this caller went "off-hook", provides his number and indicates that this call was a direct connect to the hunt group. MSN 400, as shown in step B, provides dial tone to the caller or alternatively an announcement indicating that queued calls exist. If the caller desires to retrieve these calls, he dials a star followed by a pre-defined code (e.g. *800 as explained in detail below). Alternatively, if he desires to place an outgoing call, he simply dials the digits, as shown in step C, of the desired telephone number. Upon receipt of these digits, the MSN, as shown in step D, performs, through database look up operations, whatever screening or number translation is required. Thereafter, the MSN re-initiates the call by outpulsing the physical number associated with the call on any available line, e.g. line 260.sub.2, within outgoing lines 260. Upon receipt of all the digits, local switch 200 then, as shown in step E, connects the call, via illustratively line 220.sub.j, to the called party.
Call screening can arise in a variety of enhanced services. For example, in the event an individual called party does not wish to accept calls during a specified time period, such as for example between 10 PM and 7 AM, the MSN upon receipt of such a call will return an appropriate voice message or busy signal to the caller and not complete the call. Here, the MSN can be provided with a database of callers from which a called party will accept calls and corresponding times, if desired.
Screening based upon ANI or other caller identification information obtained through the MSN can be used to implement an automated pay-per-view cable system (not shown). Here, as in any cable system, a large number of cable television viewers are all connected to a common cable system fed by a transmitter located at a cable head end station. Each viewer has a separately addressable decoder connected between a cable termination and the viewer's video equipment. The decoder, upon receipt of a suitable address and an instruction, transmitted from the cable head end transmitter, would set itself to de-scramble a specified video signal subsequently transmitted down the cable to the viewer. To receive a specific pay program, a viewer would dial a logical access number associated for the cable service. The telephone call would be automatically routed by the local switch into the MSN. The MSN would sequentially query the viewer, using voice messaging and or speech synthesis, for his or her telephone number--in the event ANI information was not available, followed by his or her unique personal identification number, and finally followed by a number corresponding to a desired video program. The host processor located within the MSN could be connected by a serial datalink, through either a dedicated or dial-up line, with a remote processor (also not shown) situated at the cable head end station. After a caller had dialed into the MSN and provided the requested information, the host processor within the MSN would transmit the telephone number of the caller (or his or her name through use of number to name translation) along with the personal identification number and program number to the remote processor. The remote processor would access its internal databases, via a database look-up operation using the caller's telephone number (or name, if translation occurred) and his or her personal identification number, to verify whether the viewer, that is now requesting service, is authorized to receive it and, if so, to obtain the address of the decoder associated with that viewer. If the remote processor determines that this viewer can receive the desired program, then the remote processor would update its billing database to reflect a new charge to the viewer for the upcoming program. Thereafter, the remote processor would cause the transmitter located at the cable head end station to transmit, through the cable system, the decoder address for that viewer followed by a suitable de-scramble instruction for the particular program desired by the viewer. This information when received at the viewer's decoder would, in turn, instruct this decoder to de-scramble the desired program and apply it to the viewer's video equipment. Alternatively, a database of valid viewers, accessed by name and personal identification number, could be stored within the MSN itself. In this case, the MSN, after having received a valid request from a viewer, would simply provide both the name of the viewer (after being suitably translated from the caller's number) and the desired program number to the remote processor which, in turn, would perform a look-up operation to determine the address of the viewer's decoder. If, however, the viewer could not receive the program, due to for example a mismatch occurring between the viewer's name and those stored within the database at the MSN, then the MSN will first playback or synthesize a pre-defined message to the viewer stating that he or she can not receive the selected program and thereafter will terminate the incoming call from the viewer. Advantageously, use of such a system permits video signals to be selectively de-scrambled on a viewer-by-viewer basis to substantially reduce theft of cable services.
Enhanced outgoing services based upon number translation would also include traditional speed (memory) dialing. Here, a list is stored within the MSN of various subscriber specified telephone numbers and their associated speed dialing codes. Once the MSN provides dial tone, the subscriber can enter a service code, such as "*300", followed by the particular code for the number desired. As discussed in detail below the MSN would query its internal database, obtain the corresponding telephone number and initiate a call to this number. One variant of this service would permit a subscriber to record a speech pattern, e.g. the word "Mom", in lieu of a numeric dialing code. After the MSN connects to the subscriber and before dial tone is provided, a speech recognition circuit could be set to recognize one of a number of pre-defined words spoken by the calling party. Once recognition occurs, a database access occurs within the MSN to locate the corresponding telephone number, provide dial tone and then outpulse the desired call.
The above outgoing call flow shown in FIG. 3 assumes that all calls from a caller are hotlined to the MSN by the local switch. Clearly, this procedure could be readily modified such that dial tone would be provided by the local switch instead of by the MSN. In the event a voice message or queued call exists, the MSN, at the time either was first stored within the MSN, would provide a suitable instruction, through the SMD datalink, to the local switch instructing the switch to provide a short "stutter" dial tone signal to the caller whenever he next takes the receiver of his telephone off-hook. Upon hearing this dial tone, the caller would know to directly dial into the MSN through a hunt group line to retrieve queued calls and/or stored voice messages. Once these stored messages and queued calls have been completely deleted from the MSN, the MSN would appropriately instruct the local switch, again through the SMD datalink, to eliminate the stutter dial tone signal for this particular caller.
II. System Hardware
A. Modular Services Node 400
Now, with the foregoing concepts in mind, the discussion will progress to a detailed examination of the hardware used to implement MSN 400.
A block diagram of MSN 400 that forms a portion of inventive system 100 shown in FIG. 1 is depicted in FIGS. 4A-4D for which the correct alignment of the drawing sheets for these figures is given in FIG. 4.
The heart of MSN 400 is programmable switch 440, such as the Modular Switching Peripheral presently manufactured by and available from Redcom Laboratories, Inc. located in Victor, N.Y. This programmable switch is a relatively small telephone switching system that interfaces to and is controlled by a separate computer system, which includes host processor 490, associated terminals and disk storage devices. The programmable switch provides trunk interfaces on lines 413, 416 and 418 and line interfaces for lines 421-429. Events, such as on-hook/off-hook, answer detect, line/trunk seizure, ringing and digit detection, occurring on any line or trunk are detected by the programmable switch. This switch provides a corresponding response, in digital form, to each detected event, via serial port 419, to host processor 490. In response to the software controlling the MSN, as discussed in detail below in conjunction with FIGS. 6-58, the host processor provides appropriate instructions to programmable switch 440 to produce a desired switching function for each detected event. These instructions, which contain the appropriate trunk and/or line numbers, principally include: answer (supply answer supervision to a trunk), give path (set up a one or two way talk path), obtain digits from a trunk, release a line, ring a line, send digits to a line and seize a trunk.
As shown, programmable switch 440 contains time slot interchanger 420 that is controlled by host processor 490. This interchanger is connected, on its trunk side, via hunt group lines 240 and outgoing lines 260, to the local switch. As noted, hunt group lines 240 contain lines 241, consisting of lines 241.sub.1, 241.sub.2, . . . , 241.sub.n, used for directly dialed ("remote") calls to the MSN through the SMD interface and hunt group lines 246, consisting of lines 246.sub.1, 246.sub.2, . . . , 246.sub.m that are used for forwarding calls to the MSN through the SMD interface. Lines 241 are applied to well-known 2-wire repeaters 401 which provide a desired level of amplification for the signals appearing on each of these lines. The resulting outputs of the repeaters, appearing on leads 403, are fed into well-known answering service interface 411. This interface detects various incoming signals, such as ringing signals, appearing on each trunk and provides an appropriate interface to standard 48 volt trunk signaling levels used in a central office. For each trunk, answering service interface 411 provides a corresponding output on leads 413 which are, in turn, connected to corresponding trunk connections on time slot interchanger
420. Hunt group lines 246 are also connected through an answering service interface, specifically answering service interface 415, via leads 416, to corresponding trunk inputs of time slot interchanger 420. In addition, outgoing lines originate on leads 418 that are connected to corresponding trunk connections on time slot interchanger 420. These leads are connected to answering service interface 417 with the resultant trunk outputs appearing on leads 409. These leads are applied to well-known
2-wire repeaters 407 for appropriate amplification of the signals appearing thereon. The amplified signals are then applied to leads 260 for connection to the local switch.
Since a switch hook flash is unable to propagate through the 1AESS switch, depression of a pound sign ("#") pushbutton on a telephone keypad is used to replace a switch hook flash. Consequently, whenever a party (e.g. a caller or a called party) is in a stable call state, that party can access one or more pre-defined services by momentarily depressing the pound sign pushbutton to invoke a corresponding service script, as will be discussed in detail later. Such a service might illustratively include recording a subsequent portion of a call or adding a party to a conference call. Specifically, pound sign detector 500 detects a depression of a pound sign pushbutton occurring during any one of all the calls currently routed through MSN 400. By simultaneously monitoring all these calls, use of the pound sign detector eliminates the need to maintain a permanent connection, through programmable switch 440 and throughout the duration of a call, between any one of DTMF receivers 433 located within DTMF receiver/transmitters and any party to the call, thereby advantageously conserving system resources.
As shown, pound sign detector 500 is connected, via leads 501, containing corresponding leads 501.sub.1, 501.sub.2, . . . , 501.sub.p to corresponding leads within leads 409 to detect the depression of a pound sign pushbutton occurring during any telephone call routed through the MSN. In the event a caller depresses a pound sign pushbutton for more than 0.07 seconds, pound sign detector 550 (discussed in detail in FIG. 5) provides an indication, including the number of an associated trunk on which the pound sign depression was detected, to host processor 490, over serial leads 555. As explained in detail below, the host processor will then take appropriate action.
Each line connection provided by time slot interchanger 420 is connected to a particular peripheral. These peripherals include a radio paging system located at a central office; music source 443; DTMF (dual tone multi-frequency) receiver/transmitters 433; speech recognition system 460; speech synthesizers 471, 474 and 477; and voice messaging system 480. These peripherals are sequentially connected to a caller, via the time slot interchanger and in a manner defined by the software executed by host processor 490, to provide various functions associated with enhanced services.
Specifically, line circuit 431 connects a line on time slot interchanger 420 and associated with lead 421, via serial link 441, which is a standard dedicated telephone line, to a well-known paging system located at the central office. Upon instruction from host processor 490, time slot interchanger 420 will provide a serial four digit number associated with a desired pager (called party) over lead 421. This number is routed by serial link 441 to the paging system which, in response to this number, performs a database access to determine a paging frequency that has been assigned to the called party. The paging system then transmits a radio signal at this frequency to page the called party.
Line circuit 432 connects via lead 442 a line on time slot interchanger 420 and associated with lead 422 to music source 443. This source provides a constant supply of music and can be used to provide music to a caller, when so instructed by host processor 490. This music may be connected to a caller during those time intervals during which the caller is waiting for a called party to answer a page.
DTMF receiver/transmitters 433 consist of separate DTMF receiver/transmitters 433.sub.1, . . . , 433.sub.k (where k is typically eight). Each of these receiver/transmitters is connected, via a corresponding lead 423.sub.1, . . . , 423.sub.k of leads 423, to a corresponding line provided by time slot interchanger 420. Under control of host processor 490, time slot interchanger 420 can switch any of these receiver/transmitters to a trunk connection on an opposite side of the interchanger in order to detect the occurrence of any dialed DTMF digit and so signal the interchanger, or to produce such a digit.
Speech recognition system 460 provides the MSN with the capability to recognize human speech spoken by any caller. This system is connected, via line circuit 434, to lead 424 associated with a corresponding line provided by time slot interchanger 420. System 460 is illustratively formed of speech recognition circuit 461 that is connected to computer 467, via leads 465, and controlled by this computer. Speech recognition circuit 461 is preferably implemented using the IBM Voice Card currently available from the International Business Machines Corporation (which also owns the registered trademark IBM). This card is a single user device that is contained within and controlled by an IBM (or compatible) personal computer which forms computer 467. In conjunction with the processing power and disk storage provided by computer 467, this card performs speech training and recognition. To initiate either of these functions, host processor 490 provides an appropriate instruction, as explained in detail below, via a bi-directional control path, implemented using leads 469, to computer 467. The result of the recognition process is then provided by computer 467 and routed to leads 469 for subsequent use by host processor 490. To differentiate the control paths, running between the host processor and the peripherals and between the host processor and time slot interchanger 420, from the voice paths involving these peripherals, the control paths are shown in dot-dashed fashion.
Speech synthesizers 471, 474 and 477 each provide the capability to convert a pre-defined voice message into humanly recognizable speech. All of these synthesizers are identical and are each implemented using the DECtalk system currently available from Digital Equipment Corporation (which also owns the trademark DECtalk). Each synthesizer is connected through a separate line circuit to a corresponding line connection on time slot interchanger 420. Specifically, synthesizers 471, 474
and 477 are respectively connected, via leads 445, 446 and 447, to line circuits 435, 436 and 437 that provide corresponding interfaces, via leads 425, 426 and 427, to corresponding line inputs on time slot interchanger 420. Each synthesizer is a single user device that functions totally independently of the other synthesizers. These synthesizers are controlled by host processor 490 through separate bi-directional control paths appearing on leads 472, 475 and 478 that collectively form leads 479. To synthesize a pre-defined voice message, the host processor first determines which synthesizer is free. Thereafter, the host processor provides a specific instruction, over the appropriate control lead 472, 475 or 478, to that synthesizer to speak a message. This instruction typically includes an op code followed by the specific message given in ASCII form. Once the synthesizer receives the message, it changes its status from free to busy and so informs the host. After it has finished producing the message, it changes its status from busy to free to enable a software driver (discussed in detail below) on the host processor to provide the next queued message, if it exists, to the free speech synthesizer.
Voice messaging system 480 provides the capability to store multiple voice messages spoken by callers and then to play these messages back later upon request. These messages, as explained in detail later, can take the form of a voice message, i.e. a message from a caller to a called party requesting return of a telephone call, or an announcement from a caller to any one of a number of called parties. The voice messaging system is implemented using two separate digitizer groups 481 and 485, each of which contains four separate speech digitizers. Each digitizer group is implemented using a Dialog/40 board currently available from Dialogic Corporation. The Dialog/40 board provides voice storage and playback capability for four separate telephone lines. Each digitizer is connected, via a corresponding line circuit, to a corresponding line appearing on time slot interchanger 420. Specifically, speech digitizer group 481 is connected, via leads 448.sub.1, . . . , 448.sub.4 that collectively form leads 448, to line circuits 438.sub.1, . . . , 438.sub.4 that collectively form line circuits 438 which are, in turn, respectively connected, via leads 428.sub.1, . . . , 428.sub.4 that collectively form leads 428, to corresponding line connections appearing on time slot interchanger 420. Similarly, speech digitizer group 485 is connected, via leads 449.sub.1, . . . , 449.sub.4 that collectively form leads 449, to line circuits 439.sub.1, . . . , 439.sub.4 that collectively form line circuits 439 which are, in turn, respectively connected, via leads 429.sub.1, . . . , 429.sub.4 which collectively form leads 429, to corresponding line connections appearing on time slot interchanger 420. Both digitizer groups (Dialog/40 boards) are connected, via leads 482 and 486, to computer 489 which is preferably an IBM or compatible personal computer. This computer also contains hard disk 487 which contains a voice messaging file that stores a file of recorded voice messages for each service subscriber as well as a variety of pre-defined voice messages. Although the components that form voice messaging system 480 are depicted for illustrative purposes as being separate, they are, in fact, all mounted within the enclosure of the personal computer. Voice messaging system 480 is controlled by host processor 490 over a bi-directional path formed of lead 483. Computer 487 contains appropriate well-known software that keeps track of the status of each digitizer and queues messages for the synthesizers. To either record or play a voice message, host processor 490 provides an appropriate instruction over leads 483 to computer 489. This instruction includes a particular op code, a specific line (circuit) number onto which the message is to appear and a file name. This file name designates the file on disk 487 that is or will be used to store the message.
Host processor 490, as discussed above, controls all the peripherals and the time slot interchanger. This processor is typically a minicomputer manufactured by Plexus Corporation operating under the UNIX Version 5.0 operating system (UNIX is a registered trademark of AT&T). This processor is connected, via leads 495, to disk 496 which contains various customer and system databases, as will be fully described below. This processor is also connected, via leads 492 and 497, to terminals 491 and
498. The host processor together with terminals 491 and 498 and disk 496 forms host computer 499. Terminal 491 is used by a local programmer to create, develop and/or alter software (so
called "service scripts"--which will be discussed in detail below) that is stored within disk 496 and executed by host processor 490 and is used to define a subscriber's enhanced services. Terminal 498 is used to access the operating system and other administrative software executing within the host processor in order to monitor the status of the MSN and provide a port for instituting corrective action (such as re-booting the system, resetting a real time clock and the like), if necessary. Lastly, the SMD datalink appearing on serial dataline 340 is connected through well-known 1200 baud modem 450 and leads 455 to host processor 490.
B. Pound Sign Detector 500
A block diagram of pound sign ("#") detector 500 shown in FIGS. 4A-4D is depicted in FIG. 5. As noted above, this circuit detects the occurrence of a depression of a "#" sign pushbutton on the keypad of any telephone that is connected to any of the outgoing lines. Specifically, the outgoing answering service interface (ASI) trunks, produced by answering service interface 417 shown in FIG. 4, are connected, as shown in FIG. 5, through leads 501.sub.1, 501.sub.2, . . . , 501.sub.p that collectively form leads 501, to individual DTMF receivers 505.sub.1, 505.sub.2, . . . , 505.sub.p. Each of these receivers detects the specific combination of tones that form a "#" sign and, in response, produces a high level on its corresponding output lead, i.e. 515.sub.1, 515.sub.2, . . . , or 515.sub.p. All these output leads feed respective inputs of encoder 525 that produces a binary 8-bit code on its output leads 535 given the individual high levels present on its p separate input leads. Typically, eight separate receivers are used and the resulting code, although in 8-bit form, contains 3 varying binary digits. The binary code appearing on leads 535 is routed to an input/output (I/O) port of microcomputer system 545. This microcomputer system merely monitors the status of its I/O port on a continuous basis and, in the event of any non-zero signal appearing thereon, converts the code to serial form and then serially transmits the code over a serial datalink formed of leads
555 to host processor 490.
III. System Software
At this point, the discussion will now turn to a detailed examination of the software executed by host processor 490. This examination will first proceed with a descriptive overview, as shown in FIG. 6, of all the software processes executed within the host processor followed next by a detailed description of the software that implements each process, as shown in flowchart form in FIGS. 7-58.
A. Host Processor Software Processes and Inter-Process Communication
FIG. 6 provides a diagrammatic overview of the organization of and inter-process communication occurring within the software executing on host processor 490 shown in FIGS. 4A-4D.
The host software can basically be viewed as having an application layer 610 and an operating system layer 650. The application layer contains three separate event driven inter-communicating software processes: SCP Process 700 (see FIG. 7), SSP Process 800 (see FIGS. 8A-8C) and Intelligent Peripheral (IP) Process 5500 (see FIG. 55). The SCP process interprets high level routines, so-called service scripts which will be discussed in detail shortly, that provide a custom definition of the specific manner in which enhanced services are to be provided to each subscriber. Specifically, each statement in each service script instructs the MSN to produce a specific function. As will be seen shortly, each such statement is implemented using a so-called "functional component (FC)". SCP Process 700 selects the statement that is to be currently executed and passes the associated functional component and its accompanying arguments to SSP Process 800. This latter process executes the functional component. Certain functional components that form part of a service script, when executed by SSP Process 800, instruct the programmable switch to provide a specific switching function, such as transmit a digit, collect a dialed number, establish a voice path through the programmable switch between a caller and either a called party or a peripheral and the like. Other functional components that form part of the service script, when executed by the SSP Process, request the IP Process to cause a peripheral (e.g. voice messaging system, speech synthesizers, speech recognition system) to provide a specific function, such as message recording, message playback, speech synthesis and the like. The IP Process, as explained in detail below, assigns peripherals to separate specific tasks while co-ordinating the operation of all the peripherals and thereby preventing any conflicts from occurring therebetween.
Each of these three processes is in an active state within host processor 490; although only one such process is actually executing at any given instant of time. Within UNIX version 5.0 operating system 650, inter-process communication occurs through mailboxes. Specifically, each process has a mailbox assigned to it: mailbox 642 for SSP Process 800, mailbox 644 for IP Process 5500 and mailbox 646 for SCP Process 700. Whenever any process desires to communicate to any other process, the sending process places a message in the mailbox associated with the recipient process. For example, SSP Process 800 can send messages to IP Process 5500 or SCP Process 700, as symbolized by dashed lines 612 and 614, by placing messages within respective mailboxes 644 or 646. Similarly, IP Process 5500 can send a message to the SSP Process, as symbolized by dashed line 616, by placing a message in mailbox 642. Also, SCP process 700 can send a message to the SSP Process, as symbolized by dashed line
618, by placing a message in mailbox 642. The operating system (O/S) contains task scheduler 660 which constantly monitors the status (full/empty) of each mailbox and prioritizes the execution of the separate processes accordingly. Specifically, if no messages exist in any of the mailboxes and all the processes have finished their current tasks, then none of the processes will execute until the programmable switch detects an incoming event and so sends a message to the host processor. Upon receipt of such a message, an interrupt is generated within the host processor which, in turn, causes the scheduler to execute SSP Process 800 in order to provide messages based upon the detection of the incoming event by programmable switch 440 (see FIGS. 4A-4D), such as an incoming call, and then report the event to SCP Process 700. Alternatively, if a process, e.g. the SSP Process, is executing and a message exists for another process, e.g. the IP or SCP Process, scheduler 660 will transfer current execution to the latter process as soon as the former process completes its present task. In the event messages exist for any two or even all three processes, then the scheduler will prioritize these messages and transfer execution to the process having the highest priority as soon as the currently executing process completes its current task. Once execution is transferred to a given process, that process reads its mailbox to obtain the current message, as symbolized by line 652 running between mailbox 642
to SSP Process 800, line 654 running between mailbox 644 to IP Process 5500 and line 656 running between mailbox 646 to SCP Process 700. Although not specifically shown, the operating system includes typical well-known administrative routines to provide database management and other necessary functions, and a real time clock to provide a real time value of the system date and time.
Now, with this overview in mind, the discussion will turn to a detailed examination of each of the three processes.
B. Service Scripts, Personal Communication Services and SCP Process Routine 700
As noted above, the SCP Process first reads an appropriate service script. Thereafter, this process selects a statement in the script for current execution. Once such a statement has been selected, the SCP Process passes a message, formed of a functional component and its accompanying arguments that form the selected statement, to the SSP Process to execute this functional component and invoke a corresponding switching and/or peripheral operation.
To facilitate reader understanding, the discussion will now digress somewhat in order to explain service scripts and personal communication services before turning to a detailed discussion of SCP Process Routine 700.
1. Service Scripts and Personal Communication Services
Enhanced telephone services that can be provided through the MSN are divided into two categories: services that are controlled by services scripts and services that have been pre-defined (personal communication services). Service scripts are specific high level routines that are composed of functional components. Use of functional components effectively separates the software, and particularly the algorithms, used within each script to define a desired enhanced service from the software that implements switching and peripheral functions and initiates software triggers.
Various software triggers (specific inter-process software messages) are set by the SSP Process in response to pre-defined detected events. At present five, events are based on conditions detected by the programmable switch and the sixth concerns time and date. Specifically, these triggers are: (a) incoming call trigger, (b) no-answer trigger, (c) busy trigger, (d) outgoing call trigger, (e) remote access trigger, (f) scheduler trigger and (g) pound sign trigger. Each of these triggers can have an associated service script which defines the specific service that should be invoked once the trigger occurs. Triggers associated by other events also exist. A message associated with a trigger and conveyed between the SCP and SSP processes has the following general format: two letters signifying the functional component associated with the trigger, followed by the circuit (line) number on the programmable switch associated with the trigger, followed by a single letter defining the type of service script being executed, followed by the telephone number of the party causing the trigger and lastly followed by associated data related to the trigger. For example, a trigger message generated in response to a digit being detected by the programmable switch for a COLLECT.sub.-- DIGIT functional component executing within an outgoing script for caller 758-1234 presently connected to circuit 123 with four digits being returned will illustratively be: RD 123 t 7581234 4.
In particular, whenever an incoming call is detected by the programmable switch, the SSP Process sends an incoming call trigger message, along with the called telephone number obtained through the SMD datalink, to the SCP Process. In response to this message, the SCP Process will access the called party's incoming answer service script (illustratively named "o" followed by the called telephone number, e.g. o758-1234) from appropriate files on disk 496 within host computer 499 (see FIGS. 4A-4D) and begin interpreting this script. An illustrative example of an incoming service script is as follows:
______________________________________ PAGE 0 8520 CUSTOMER --ANSWER L0 WAIT L0 ANSWER GIVE --PATH 0 0 0 QUIT ______________________________________
Whenever an incoming call occurs for a subscriber, then execution of this script causes that subscriber to be paged. Specifically, his or her pager code (here number 8520) is sent to the paging system. The script then waits until the subscriber comes to his or her telephone and goes off-hook. When that occurs, the subscriber is immediately connected to the caller. This script advantageously provides an individual with mobility. Specifically, this script allows an individual to be paged and then return to his or her desk to receive an incoming call rather than being required to remain in his or her office to hear the telephone ring.
In the event a called party does not define an incoming service script, then the host processor will execute a default incoming script through which the SSP Process will instruct the programmable switch to connect the caller to the called party as soon as the called party picks up the telephone.
Now, whenever a call to a number is not answered within a specified number of rings, the SSP Process sends a no-answer trigger message, along with the called telephone number, to the SCP Process. In response to this message, the SCP Process will access the called party's no-answer service script (illustratively named "n" followed by the called telephone number, e.g. n758-1234) from appropriate files on disk 496 within host computer 499 (see FIGS. 4A-4D) and begin interpreting this script. A basic illustrative example of a no-answer service script for subscriber 758-1234 is as follows:
______________________________________ ANSWER PLAY --ANNOUNCEMENT 0 0 p7581234.4 0 0 RECORD --MESSAGE 0 TEL --NO QUIT ______________________________________
This script implements a telephone answering machine. Specifically, after a called party's telephone rings a specified number of times, the telephone is answered and a pre-recorded voice message existing in file p7581234.4 (as discussed below) is played back to the caller. Once this is completed, a voice message is recorded from the caller and stored within in a voice message file for subscriber 7581234.
In the event a called party does not define a no-answer service script, then the host processor will execute a default no-answer script through which the SSP Process will merely instruct the programmable switch to allow the telephone at the called party to ring until the caller hangs up.
If, alternatively, a call is made to a busy number, then the SSP Process sends a busy trigger message, along with the called telephone number, to the SCP Process. In response to this message, the SCP Process will access the called party's busy service script (illustratively named "b" followed by the called telephone number, e.g. b758-1234) from appropriate files on disk 496 within host computer 499 (see FIGS. 4A-4D) and begin interpreting this script. A basic illustrative example of a busy service script for subscriber 758-1234 is as follows:
______________________________________ GIVE --PATH 1 3 2 COLLECT --DIGIT L1 1 1 A 5 10 WAIT L1 RETURN --RESULT L3 1 X L3 ANSWER GIVE --PATH 1 1 1 GIVE --PATH 2 5 L6 COLLECT --DIGIT L7 1 1 A 0 0 WAIT L7 RETURN --RESULT L8 1 X GO --TO L6 L8 GIVE --PATH 1 0 1 GIVE --PATH 0 5 L10 COLLECT --DIGIT L81 1 1 A 0 0 WAIT L81 RETURN --RESULT L9 1 X GO --TO L10 L9 GIVE --PATH 1 1 1 GIVE --PATH 2 5 GO --TO L6 QUIT ______________________________________
In the event a subscriber's telephone line is busy and an another, i.e. second, incoming call occurs, then this script puts the second caller in a call waiting state and provides a tone to the called party. A call waiting state occurs where the called party is connected to one of two earlier callers and the other caller is waiting to be connected to the called party. Thereafter, the called party can depress the "1" pushbutton on his or her telephone to be connected to the second caller and to place the first caller is a call waiting state in which the first caller is connected to the music source. By repetitively depressing the "1" pushbutton, the called party can repetitively switch between the first and second callers with the other caller being connected to music.
Should a called party not define a busy service script, then the host processor will execute a default busy script through which the host processor will merely instruct the programmable switch to connect a busy signal to the caller.
Now, should a caller go off-hook, this condition will be detected by the programmable switch and reported to host processor 490. In response, the SSP Process sends a outgoing call trigger message, along with the called telephone number, to the SCP Process. In response to this message, the SCP Process will access the called party's outgoing service script (illustratively named "t" followed by the called telephone number, e.g. t758-1234) from appropriate files on disk 496 within host computer
499 (see FIGS. 4A-4D) and begin interpreting this script. A basic illustrative example of an outgoing service script for subscriber 758-1234 is as follows:
______________________________________ CHECK --MSG L000 WAIT L000 RETURN --RESULT L0 0 X RETURN --RESULT TEL 1 X RETURN --RESULT MSG 2 X WAIT MSG SPEECH --SYNTHER L0 0 1 0 "messages" WAIT TEL SPEECH --SYNTHER L0 0 1 0 "calls" WAIT L0
DIALING L1 1 0 4 # * 5 10 WAIT L1 RETURN --RESULT PER --MSG *200 X PER --MSG RETRIEVE --MESSAGE L0 0 TEL --NO QUIT ______________________________________
Now, when a caller goes off hook, this script first checks his or her messages for the existence of either stored voice messages or queued telephone calls. In the event only a stored message(s) exists, then execution is directed to statement MSG at which point a voice synthesizer will state the word "messages" to the caller. Thereafter, execution will proceed to statement L0 which will connect a dial tone to the caller. If the caller depresses a "*" pushbutton on the keypad of his or her telephone, then execution will proceed to statement L1 which detects whether the caller will sequentially depress the pushbuttons for "*200". If thereafter the caller enters "*200", then execution proceeds to the RETRIEVE.sub.-- MESSAGE functional component which invokes the Voice Message Retrieval *200 personal communication service for the caller. If the caller enters other digits, then this script will simply ignore them. Alternatively, if the caller has only queued telephone calls, then execution is directed to statement TEL at which the voice synthesizer will be instructed to state the word "calls". Dial tone will then be provided to the caller, through execution of statement L0, as set forth above. If the caller does not have any stored voice messages or queued telephone calls, then execution proceeds directly to statement L0 to provide dial tone to the caller.
In the event that a caller does not have an outgoing service script, then the host processor will execute a default outgoing script. This script, when executed through the SCP Process, will instruct a voice digitizer to generate a voice message to allow the caller to dial specific codes to retrieve voice messages or names/numbers in a callback queue or to receive dial tone from the programmable switch in order to place an outgoing call.
Now, if a caller directly dials through a remote line directly into a hunt group on the MSN, then this condition will be detected by the programmable switch and reported to host processor 490. In response, the SSP Process sends a remote access trigger message, along with the called telephone number, to the SCP Process. In response to this message, the SCP Process will access the called party's remote service script (illustratively named "r" followed by the called telephone number, e.g. r758-1234) from appropriate files on disk 496 within host computer 499 (see FIGS. 4A-4D) and begin interpreting this script. A basic illustrative example of an outgoing service script for subscriber 758-1234 is as follows:
______________________________________ SPEECH SYNTHER 0 0 0 0 "please enter your service code" COLLECT --DIGIT L1 0 4 A 5 30 WAlT L1 RETURN --RESULT L2 *200 X L2 RETRIEVE --MESSAGE 0 1 ANI QUIT ______________________________________
Once a caller has remotely dialed into the MSN, this script when executed, first synthesizes a message to the caller requesting entry of his or her service code, i.e. a "*" pushbutton followed by sequential depression of three numeric pushbuttons. Thereafter, through execution of the COLLECT.sub.-- DIGIT functional component, the MSN is instructed to collect values of four digits from the caller with the inter-digit and first digit timers being set to five seconds and thirty seconds, respectively. If the caller enters "*200" then execution is directed to statement L2 which permits the caller to obtain his stored voice messages using the Voice Message Retrieval *200 personal communication service.
Now, in the absence of a remote service script for any caller, the host processor, through the SCP Process, will execute a default remote script through which the caller will be prompted to enter digits to utilize any of the personal communication services, as explained below.
Furthermore, a caller can instruct the MSN to provide an enhanced service at a specific time and date by appropriately programming a software timer. Once the real time clock provided through the operating system reaches the programmed date add time, the SSP Process will send a scheduler trigger message, along with the called telephone number, to the SCP Process. In response to this message, the SCP Process will access the called party's time and date service script (illustratively named "s" followed by the called telephone number, e.g. s758-1234) from appropriate files on disk 496 within host computer 499 (see FIGS. 4A-4D) and begin interpreting this script. A basic illustrative example of a time and date service script for subscriber
758-1234 is as follows:
______________________________________ TlME --& --DATE HOME = XX XX XX 08 09 GO --TO BYE HOME CALL --FORWARD 7584567 1 WAIT CUSTOMER --ANSWER H0 WAIT GO --TO BYE H0 SPEECH --SYNTHER BYE 1 1 0 "good morning, it is now time to get out of bed" WAIT BYE QUIT ______________________________________
This script provides a "wake up" call everyday at 8:09 AM. Specifically, whenever the time reaches 8:09 AM on any day, execution passes to statement HOME; otherwise, execution merely exists from this script. Execution of statement HOME causes a call to be placed by the MSN to number 758-4567. If the subscriber at that number answers, within the number of rings he or she has specified, then control goes to statement H0. This statement causes a synthesized message to be produced for the called party, e.g. instructing that party to get on with the morning's activities. The script terminates once the message has been fully produced. There is no default time and date service script.
Lastly, a subscriber can instruct the MSN to provide one or more enhanced services (e.g. record a subsequent portion of a call using a voice digitizer or add a party to an existing or new conference call) by appropriately programming a pound sign detector. Then, whenever the subscriber depresses the pound sign on his telephone keypad during a stable call state, the SSP Process will send a pound sign trigger message, along with that subscriber's telephone number, to the SCP Process. In response to this message, the SCP Process will access the subscriber's pound sign service script (illustratively named "p" followed by the subscriber's telephone number, e.g. p758-1234) from appropriate files stored on disk 496 within host computer 490. A basic illustrative example of a pound sign service script for subscriber 758-1234 is as follows:
______________________________________ RESERVE --CONFERENCE WAIT RETURN --RESULT L0 0 X RETURN --RESULT L6 -1 X L0 DIALING L1 1 0 4 # * 5 40 WAIT ADD --A --PARTY L41 0 WAIT L1 COLLECT --DIGIT L2 1 1 # 0 0 WAIT L2 RETURN --RESULT L3 0 X RETURN --RESULT L4 1 X RETURN --RESULT L5 2 X L3 ADD --A --PARTY L41 1 WAIT GO --TO L1 L4 ADD --A --PARTY L41 2 WAIT L41 RETURN --RESULT L7 -1 X GO --TO L1 L5 DELETE --A --PARTY 2 GO --TO L1 L6 SPEECH --SYNTHER BYE 0 0 0 "a conference call can not be made now" L7 SPEECH --SYNTHER BYE 0 0 0 "a party can not be added to your conference call now" BYE QUIT ______________________________________
This script allows a subscriber to set up a conference call and then add and delete parties to and from that call. Specifically, upon entry into this script, a RESERVE.sub.-- CONFERENCE functional component executes to instruct programmable switch 440 to determine if an internal conference bridge is available. If all such bridges are currently in use, then execution passes to statement L6 which, when executed, causes an appropriate synthesized message to be produced that specifies that a conference call can not be made now. Alternatively, if a conference bridge is available, then that bridge is allocated for current use and execution proceeds to statement L0, which provides dial tone and sets up a special dialing plan, illustratively a
4 digit Centrex plan. Thereafter, the present subscriber is connected by the programmable switch to the conference bridge through execution of an ADD.sub.-- A.sub.-- PARTY functional component. Once this occurs, execution passes to statement L1 which instructs the MSN to obtain a single digit entry from the subscriber: "0" or "1" to add either the original caller or a successive party to the conference call, or "2" to remove the most recently added party from the conference call. If the subscriber enters either a "0" or "1", then execution proceeds to a ADD.sub.-- A.sub.-- PARTY functional component in statement L3 or L4, respectively to attempt to add the appropriate party to the current conference. If this conference bridge can not accommodate another party, then execution proceeds, via RETURN.sub.-- RESULT statement L41, to statement L7 which causes an appropriate message to be synthesized to the subscriber. If, however, the bridge can accommodate another party, then that party is connected to the bridge and thereby added to the current conference. Execution then returns to statement L1 to await the next digit entered by the subscriber. Now, should the subscriber enter a "2", then execution proceeds to statement L5 which, when executed, removes that party that was most recently added to the conference from the conference, i.e. this statement instructs the programmable switch to disconnect this party from the conference bridge.
The personal communication services are simply a collection of pre-defined routines which each implements a certain specific telecommunication service. Each of the personal communication services can be executed through use of a single functional component appearing within a service script, as will be explained below. Presently, these personal communication services include: call re-direction, message retrieval, memory dialing, ring updating, retrieval of queued call back numbers, announcement recording and changing a personal identification number. Incorporation of such single functional components into a service script advantageously permits service programmers at local operating companies to efficiently and easily program the MSN by eliminating the need to repetitively re-define certain frequently used telecommunication services in each subscriber's service scripts.
Hence, as one skilled in the art can now readily appreciate, the service scripts merely contain logic to define telephone services using a set of high level primitives (herein referred to as functional components). None of these functional components requires the service programmer at a local operating company to have any knowledge of how switching operations are actually implemented or how conditions are detected or how triggers are set within the MSN. By defining telephone services using functional components, the software that implements the service control logic becomes substantially independent of the software that controls the actual programmable switch used to fabricate the MSN. Advantageously then, the MSN can be implemented using any one of a variety of different programmable switches with no effect on the service programmer.
To increase the execution speed of the MSN software on the host processor, a compiler, for converting each SSP functional component into instructions appropriate for the switch then being used, could be provided on the host. This compiler would also enable the host to understand incoming communication from the switch to the host and thereby set appropriate triggers for each event that can be detected by the switch and communicated back to the host. The inner workings of the compiler would be completely transparent to the service programmer. The programmer would merely invoke the compiler to generate run time code for use by the host processor prior to trialing the service. In fact, once the compiler is loaded into the host, its execution can be automatically invoked at appropriate times, such as after a file containing a service script is closed, without any intervention by the service programmer. Since the service programmer is freed of any need to modify the software that controls the switch itself and only needs to concern himself with high level service logic, the programmer can develop, trial and modify new enhanced services in a significantly reduced period of time than that previously possible in the art.
2. SCP Process Routine 700
A flowchart of SCP Process Routine 700, depicted in FIG. 6, is shown in FIG. 7.
Upon entry into SCP Process routine 700, execution is first directed to block 701 which reads the current message appearing in SCP mailbox 646. Thereafter, execution proceeds to decision block 702 to decode this message. This message can either be an initialize command followed by a trigger type, a result returned from a functional component executed by the SSP Process, an on-hook condition or a terminate script ("te") request also returned from a functional component executed by the SSP Process.
Now, in the event the message consists of an initialize command with an accompanying trigger, then decision block 702 routes execution, via paths 703 and 705, to execution block 710. This block, when executed, reads the script appropriate for the trigger from disk 496 and loads that script into a table within memory on the host processor. Thereafter, execution proceeds to block 715 which sets a pointer (illustratively called FC.sub.-- POINT) to point to the first location in the table at which the script begins. Execution then passes to block 720 which reads the table and obtains the next (in this case first) functional component in this script. This functional component is then tested by decision blocks 725 and 735. Specifically, execution proceeds from block 720 to decision block 725 to determine whether the functional component is a Go.sub.-- To FC. Go.sub.-- To functional components merely route execution to other functional components. Therefore, if the present functional component is a Go.sub.-- To FC, then decision block 725 routes execution, via its YES path, to block 730. This latter block, when executed, invokes Go.sub.-- To Routine 2600 (see FIG. 26) which merely obtains the location of the next FC to be executed from the Go.sub.-- To FC and appropriately changes the value of pointer FC.sub.-- POINT. Execution then loops back, via paths 733 and 721, to block 720 to obtain the next FC from the current script. Alternatively, in the event the present FC is not a Go.sub.-- To FC, then decision block 725 routes execution, via its NO path, to decision block 735. This latter decision block determines whether the current FC is a Wait FC. If this FC is not a Wait FC, then execution passes, via NO path 739, to block
740 which when executed places the present functional component into SSP mailbox 642 for processing by the SSP Process. Once this has occurred, execution loops back, via paths 742 and 721, to block 720. In the event the current FC is a Wait FC, then decision block 735 routes execution, via YES path 736, to execution block 770. This block, when executed, invokes Wait FC Routine 4100. Inasmuch as the MSN software is event driven, execution of a Wait FC merely halts execution of the current script until the next event occurs. Such an event could be a response from a caller or an acknowledgement from a peripheral, e.g. a speech synthesizer, that it has finished its current task, e.g. playing an announcement. Once Wait FC Routine 4100 has executed, execution loops back, via paths 775, 762 and 780, to block 701. At this point the scheduler suspends execution of SCP Process 700 until the next message arrives in its mailbox.
Alternatively, if the message in the SCP mailbox is a result returned from the SSP process, then decision block 702 routes execution, via paths 703 and 706, to block 745. This latter block, when executed, reads a register which contains a saved state of the current script, i.e. the location of the current FC being processed. A RETURN.