Using concurrently operating routines in telephony applications

Details Using concurrently operating routines in telephony applications Using concurrently operating routines in telephony applications

2000-11-01

2004-09-21

Hoosain, Allan (Department: 2645)

Telephonic communications

Audio message storage, retrieval, or synthesis

Interacting voice message systems

C379S088170, C379S088220, C379S201020, C379S219000, C379S220010, C379S221080

Reexamination Certificate

active

06795535

ABSTRACT:

TECHNICAL FIELD
This invention relates generally to the field of call processing and more particularly to providing service node/intelligent peripheral (SN/IP) telephony applications.
BACKGROUND
Computer-based telecommunications systems have grown exponentially over the last several years due, in part, to the ever-advancing and increasing availability of high-speed personal computers and low-cost equipment. The delivery and advancement of calling services has followed this trend of overwhelming growth. Because of rapid technological advancements, telephone service providers are now generally able to offer more complex calling services to a wider population and at a lower cost than previously possible. With this rapid advancement of technology and increasing consumer demand, telephone service providers realize the profitable potential to design, develop, and implement more sophisticated calling services.
During the current evolution of telephone network design, the industry developed a design architecture called Advanced Intelligent Network (AIN). AIN allowed calling service programming to finally be removed from the telephone switches. Prior to AIN, because of the complexity of telephone switches, every time a new calling service was developed, the switch vendors typically had to reprogram the switches to perform the service. This process normally delayed the introduction of new services and generally prohibited smaller telephone service providers from introducing their own calling services thereby reducing the possibility for competitive advantage.
AIN architecture generally works by grouping “intelligent” operations into peripheral computer systems, thereby freeing the switches to perform their core functions of call connection and call routing. AIN architecture also generally allows relatively inexpensive computer systems to provide flexible and efficient call processing. Because the intelligent peripheral computer systems are easier to update, reprogram, and maintain than switches, telephone service providers can generally offer a wider variety of calling services.
Calling services are typically delivered by AIN architecture through service control points (SCP). A switch sends a data package to the SCP which then manages the call processing. SCP's usually delegate many of the tasks associated with the data package to intelligent peripherals (IPs). IPs generally provide a number of processing resources such as voice prompting and data collection. The SCP will normally defer a small part of the call processing to an IP, but will regain control immediately after the IP completes the task. In this prior art system model, the IP receives and executes only primitive commands such as Play Message or Collect Digits.
A typical contemporary AIN architecture system includes service nodes (SN). SNs are usually stand-alone platforms which independently deliver calling services. An SN is typically connected directly to a switch and is dedicated to deliver a particular calling service such as voice mail. After receiving a call, the switch directly routes it to the SN which then processes the call without much direction from the switch or SCP. SNs also may use IPs to provide primitive resources for call processing. Communication systems or calling service applications which use SNs and IPs together are commonly referred to as SN/IP applications.
A recent technological advance to the AIN architecture derives from a family of patents issued to Sattar et al., U.S. Pat. Nos. 5,469,500, 5,572,581, and 5,644,631. Sattar advanced the AIN architecture by establishing more coupling routines between SNs and IPs. The Sattar IP now typically performs more of the decision-making tasks previously handled by the SN. The SN is then left to perform the general call processing and the more complex decision-making tasks. In the context of calling service processing, this generally allows the SN/IP application to lessen fragmentation of the call flow. Call flow refers to the actual call connection between the user and the calling service and the control thereof.
The prior art in SN/IP applications, both before and after Sattar, uses a central program located on the SN which incorporates the call flow control, data access control, and asynchronous event handler. Data access control refers to the function of obtaining data from a source other than a user in response to a user input or call signal such as automatic number identification (ANI) or dialed number identification service (DNIS). The level of data access required depends on the particular calling service being provided. In a voice mail service, the data required would typically consist of a list of valid voice mailbox addresses to check against the user's entry, a list of the user's password or personal identification number (PIN) to check against the user's entry, and the actual message(s) stored in the mailbox.
The asynchronous event handler refers to the call processing/decision-making functions. When a user initiates a call, the asynchronous event handler generally receives the call “event code” and transfers it to the IP for interfacing with the telephony network. If an SN performs a certain function which requires data, the asynchronous event handler usually receives the “get data” command and then either forwards control to the IP if the data is required from the caller or forwards control to the data access control to get data from another source. When the data returns, an event code is typically transferred back to the asynchronous event handler to determine which piece of call flow to execute next.
FIG. 1
shows a typical SN/IP model of the prior art. The system will typically include multiple SNs
100
-
103
, each of which is dedicated to perform a different function. SNs of the same system will normally not be interconnected unless they are overlapped for redundancy. SNs
100
-
103
will generally be connected to multiple IPs
104
-
108
which interface with the telephone lines and, thus, also the voice path of the caller. A single SN
100
may be connected to several IPs
106
-
108
, or may just be connected to one, depending on the system configuration and calling function. SNs
100
-
103
may also be connected to data access routine
109
to perform any data collection other than from the caller.
In an example of pre-Sattar operation, a caller places a call to check the balance in his/her checking account. SN
100
receives the call and forwards it to IP
108
to set up the interface between the calling service and the caller. Because this SN does balance checking, SN
100
begins call flow and sends the initial instruction, Play Message, to IP
108
. When IP
108
plays the message, an event code is generated and control is forwarded back to SN
100
. SN
100
stops the call flow and then sends the instruction, Get Account Number, to IP
108
. Call flow begins again and the caller is prompted by IP
108
to enter the account number. When IP
108
gets the number entered by the caller, an event code is generated and sent back to SN
100
. Call flow stops. SN
100
sends an instruction to the data access routine
109
to return a list of valid account numbers. Data access routine
109
returns the list for SN
100
to check against the entered account number. If the number is valid, SN
100
begins call flow again and sends IP
108
the instruction, Get PIN. The process continues until the service has been completed. With all control processing elements located in the SN, the call flow is fragmented because the application must always stop the call flow to return to the SN to perform a particular task or make a particular decision. This start/stop, back and forth methodology makes control of the call flow much more complicated from the programming aspect.
After Sattar, because IP
108
is now able to handle more complex tasks, SN
100
is able to send a string of commands, thereby increasing the length of call flow segments. When the caller places the call, SN
100
begins call flow and sends IP
108
the instruction

Affiliated with

Also associated with

Rating

Using concurrently operating routines in telephony applications does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Using concurrently operating routines in telephony applications, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Using concurrently operating routines in telephony applications will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3206135