Field of Invention
This invention relates to telecommunications network management and in particular to private automatic branch exchange (PBX) systems referred to as Automatic Call Distributors (ACDs) and processes that improve the granularity of the telephony communications switching.
Description of Prior Art
Private Automatic Branch Exchanges commonly referred to as PBX's are "switching" systems that establish and manage the interconnection of users across a transmission system. Early switches incorporated wiring logic to deliver and maintain a communications signal between two users. Current PBXs have evolved into electronically controlled switching systems based upon sets of instructions stored in the control unit of a PBX's memory referred to as Stored Program Controls (SPC), for the purpose of setting up and maintaining calls.
The PBX provides two critical functions in a company location; the control of the switch in the form of the Stored Program Controls, and the communications signal switching itself. The action of setting up or provisioning the "switching" of a signal between two points must precede the action of signal switching itself (see FIG. 1). A special purpose PBX called an Automatic CAll Distributor (ACD) is the evolution of the SPC portion of the PBX signal switch.
Automatic Call Distributors are special purpose PBX systems that setup, deliver, and manage analog and digital data transmissions based upon real-time circuit inventory of the switch. Fundamentally, the ACD is programmed for the number of circuits to a public switch and the number and identification of every client station (telephone extensions) in the company. An ACD typically supports a reporting capability that is sufficient for post analysis and planning, but not for real-time querying between Stored Program Control Applications for the purpose of determining if there is a circuit available to setup for communications transmission.
The ACD requires stored program control logic so it can act when presented with a signaling event from another switch. The limitation of current ACDs is that all program logic for call setup must be contained within the ACD's memory unit. In multiple ACD networks only one ACD can be signaled to setup a circuit between two endpoints (see FIG. 2). If that ACD does not have a circuit available to establish the call, it cannot tell the signaling public switch where to signal to establish a connection. This limitation is the result of stored program controls being based within each ACD.
Separating the Stored Program Control module from the ACD and moving it to a central signal point, makes possible the ability for circuit switching between an "offering" public switch and a provisioned "group" of ACDs (see FIG. 3). The feasibility of separating Stored Program Control physically creates need for circuit process control data at the Stored Program Control point whenever it is offered a call. Process control data in the telecommunications area is switch signal data, which the ACD generates but does not deliver back to a distributed Stored Program Control point in real-time. Primarily because switch design makes the ACD/PBX's event driven at best to signals being presented to them, and then through their Stored Program Control modules. When signals are being presented to a remote point, this does not even represent an event state to the ACD and the need for a Virtual Telephony Data Message system.
Summary of the Invention
The present telephony data message management system exposes event-driven telephony data to switch management applications for the purpose of delivering telecommunications transmissions. It overcomes the inability of the prior art to utilize telephony data in its Stored Program Control (SPC) module operations. It further increases the ability of the prior art to manage individuals because of event data for the individual station ID (telephone extension).
During processing, the message management system is passing telephony data between desktop clients and network based ACD applications in real-time. The process is one of accepting a data packet from either a computer telephony integration (CTI) device or a SPC supporting application and tagging the data for delivery to its counterpart. Every CTI message is destined for a SPC application and SPC applications can only send data to CTI clients through the virtual circuit management system.
All clients to the virtual circuit management system must identify themselves and be validated. Once validated the client is allowed to have data messages delivered to its application host. There is a specific message application programming interface (API) set utilized for the purpose of transmitting data. This message API set insures that unauthorized or invalid data will not potentially corrupt client systems integrity. Data messages are directional and the message set further insures that. Message IDs designate what direction they may travel, what processes need to be notified of their arrival, and what events the receiving process should initiate.
The Virtual Telephony Data Message System is a collection of like processes and data objects whose specific attributes are determined by when and where in the system the objects instances are created. These data objects and processes are implemented utilizing the principles of inheritance and persistence within the virtual circuit management system.
Brief Description of the Drawings
FIG. 1 is a representation of the components of Stored Program Control and switched signaling for an offered call in the prior art
FIG. 2 is a representation of multiple PBX/ACDs with separate Stored Program Control being served by a single Public Switch
FIG. 3 is a representation of multiple PBX/ACDs utilizing a distributed Stored Program Controls module accessed by a carrier Service Control Point accessing a Common Stored Program Control.
FIG. 4 is a representation of a conventional system without Computer Telephony Integration technology being combined with network based Stored Program Control modules.
FIG. 5 is a representation of a Computer Telephony system utilizing a departmental server for distributed Common Stored Program Control functionality.
FIG. 6a is a process flow block diagram of the Telephony Data Message process by Vector Objects.
FIG. 6b is an Object Definition Model for the Telephony Vector Object.
FIG. 6c is the Telephony Data Message API set portion generated by PBX/ACD Stored Program Control Applications. The message names begin with the word VAPI which stands for Virtual Application Programming Interface
FIG. 6d is the Telephony Message API set portion generated by Telephony Integrated Client Applications for Stored Program Control Server Applications. The message names begin with the word VAPI which stands for Virtual Application Programming Interface
FIG. 6e is the message API set portion generated by Virtual Message Management System's inter-process communication. The message names begin with the word VAPI which stands for Virtual Application Programming Interface.
Detailed Description of the Preferred Embodiment
A present preferred embodiment of my system is depicted in FIG. 5 through FIG. 6e. In the preferred system there is a Computer Telephony Integrated Network utilizing a Departmental Server as a distributed server for ACD Stored Program Controls.
Referring to FIG. 5, a public communication system includes a network/service control point 10 and a message source 16, such as a terminating public switch. The message source 16 communicates with switching systems, such as PBX/ACDs 14a,14b. Although two PBX/ACD units 14a,14b are shown in FIG. 5, it is to be understood that the system may contain additional PBX/ACD units 14. The PBX/ACD units 14 within the system may be at different physical locations.
Each PBX/ACD 14 includes a plurality of connection switches for electrically connecting the message source 16 with a communication station, such as a telephone station 22 or a work station 24. The workstations 24 may include personal computers or servers. Some of the workstations 24 and telephone stations 22 may be in a building or other physical location different from the building in which other workstations 24 and telephone stations 22 are located.
Each PBX/ACD 14 includes a local stored program control module 18. The local stored program control modules 18a,18b monitor the status of the connect switches within the respective PBX/ACD 14a,14b.
The local stored program control modules 18a,18b communicate with a common stored program control module 20. In particular, the local stored program control modules 18a,18b provide process control data to the common stored program control module 20 which may reside in server 26. The common stored program control module 20 may provide instructions to the network/service control point 10 for selectively connecting the message source 16 to at least one of the communication stations via a PBX/ACD 14.
The process of the present invention is shown in FIG. 6. In particular, a process flow block diagram of the Telephony Data Message process by Vector Objects is shown in FIG. 6a, and a Object Definition Model for the Vector Objects is shown in FIG. 6b, and the Message set application programming interface (API) is shown in FIG. 6c, FIG. 6d and FIG. 6e.
Both FIGS. 6a and 6b represent software modules in the preferred embodiment. The module of FIG. 6b is incorporated in the implementation of step 2 in FIG. 6a, the VECTOR Process, 2a, the VECTOR Object Array and step 4, the CLIENT and SERVER VECTOR INSTANCES. The implementation requires input data in the structures specified in the Message set application programming interface (API) of FIGS. 6c and 6d and 6e for step 1 of FIG. 6a and generates output data specified in the Message set application programming interface (API) for step 5 of FIG. 6a.
Those skilled in the art shall recognize that the values of all data elements in the Message set application programming interface (API) can be modified without affecting the basic concept behind the Virtual Telephony Data Messaging System in the present invention.
Referring to FIG. 6a step 1, reading data and performing validation is shown. The Operating System the Virtual Telephony Data Messaging program is running in will make data available for the program to read. Step 1 depicts a decision block, if the data read by the program structure matches the structure of data messages specified in the Message set application programming interface (API) that data will be moved by the program to Step 2 to create a Vector Object instance. If the data read does not match the structure specified in the Message set application programming interface (API) then discard the data and wait for the Operating System to notify the program with new data.
Referring to FIG. 6a step 2, Instantiate object for VECTOR process is shown. Data passed to this process is used to define the properties of an object instance. The process reads the data into a structure that defines what actions the resultant object can perform. An object instance once created can only perform based upon the attributes it contains. The VECTOR Object instance, once created is unique and is maintained by the program as a member of the Object array step 2a. All data read by the VECTOR Process has a logical identification number which is mapped to the VECTOR object array to determine if an instance already exists. New logical IDs generate VECTOR objects that perform the functions of writing output data. Data read for logical IDs that map to VECTOR object instances in the array generate VECTOR objects that are data containers only.
Referring to FIG. 6a step 3, a VECTOR object instance has been generated and it has to be validated to determine what delivery instructions the object contains. All data is in the form of object instances that contain origination IDs. The origination ID gives the object instance a source type attribute of either a CLIENT application or SERVER application. Each VECTOR object instance inherits a destination ID in this decision block. VECTOR object instances containing CLIENT origination IDs inherit a SERVER destination ID. VECTOR object instances containing SERVER origination IDs inherit a CLIENT destination ID. The destination ID inheritance moves the VECTOR object to the delivery process, step 4.
Referring to FIG. 6a step 4, both CLIENT VECTOR INSTANCE and SERVER VECTOR INSTANCE delivery process lookup up the VECTOR Object instance in the array with origination IDs that match the Destination IDs of the object instances in step 4. The VECTOR object instance inherits the action attributes of the instance that writes its data to the specific Destination ID. In the case that the Destination ID is no longer in the VECTOR Object array then the appropriate CLIENT or SERVER is no longer active.
Referring to FIG. 6a step 5, both CLIENT VECTOR INSTANCE and SERVER VECTOR INSTANCE processes write their data to an input/output process that notifies the operating system's Input Output layer to take delivery of the data.
The initiation and termination of the Virtual Telephony Data Messaging program is a matter of starting and stopping the process that reads the data from the operating system input/output layer. The operating system is responsible for the network layer, which insures both management and delivery of application data.
Them method described herein can be implemented in existing telecommunication systems having a computer and a PBX/ACD or similar telephone switching device that is or can be connected to the computer. To do this a computer program for implementing the method is provided on a disk or other computer readable medium and loaded into the computer. The program contains the instructions for applying vectors to the messages, creating object instances and otherwise enabling the computer to communicate with the telephone switching device to install and utilize the method.
The invention has been described in a preferred embodiment and complemented with supporting diagrams, but is not limited thereto. Those skilled in the art will recognize that a number of additional modifications and improvements can be made to the invention without departure from the essential spirit and scope. The scope of the invention should only be limited by the appended set of claims.