Telephonic communications – Special services – Provisioning
Reexamination Certificate
2001-06-18
2004-02-10
Hong, Harry S. (Department: 2151)
Telephonic communications
Special services
Provisioning
C370S469000, C379S221080, C709S250000, C709S241000
Reexamination Certificate
active
06690782
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates to the field of advanced intelligent networks and more particularly to service logic execution environments.
2. Description of the Related Art
The development of the open network application programming interface (API) represents an important departure from traditional methods for opening the architecture of the public switched telephone network (PSTN). One such open network API, the Advanced Intelligent Network (AIN) API and architecture, defines a call model which allows the creation of telecommunications service applications outside of the switch environment. Telecommunications service applications are a' la carte telecommunications applications which can perform enhanced services for a telecommunications session established among two or more parties. Exemplary services applications can include Call Waiting, Caller ID, Call Forwarding, Voice Activated Dialing, and Meet-me Conferencing.
When AIN first had been introduced, in terms of the service application creation process, the AIN architecture represented an important advance. AIN separated service development from switching, allowing service logic components to be developed more quickly and placed in specialized network elements attached to databases. Switches, in turn, being free from all service logic, could be optimized for speed and efficiency. Still, typical service applications developed to the AIN specification are written in specialized languages by specially trained programmers using specialized service creation environments.
Importantly, future telecommunications networks will be characterized by new and evolving network architectures where packet-switched, circuit-switched, and wireless networks are integrated to offer subscribers an array of innovative multimedia, multiparty applications. Equally important, it is expected that the process by which telecommunications applications are developed will change, and will no longer solely be the domain of the telecommunications network or service application provider. In fact, in order to provide a broad portfolio of novel, compelling applications rapidly, service application providers will increasingly turn to third-party applications developers and software vendors. Thus, application development in the telecommunications domain will become more similar to that in software and information technology in general, with customers reaping the benefits of increased competition, reduced time to market, and the rapid leveraging of new technology as it is developed.
To make this vision a reality, the principles of AIN have been discarded in favor of a new service application component development paradigm. Specifically, it has been recognized that future integrated networks must offer application developers a set of standard, open APIs so that applications written for compatibility with one vendor's system can execute in the system of another vendor. In consequence, the cost of applications development can be amortized, reducing the final cost to the customer. Java APIs for Integrated Networks (JAIN) fulfills the requirements of the new service application component development paradigm. Presently, JAIN includes standard, open, published Java APIs for next-generation systems consisting of integrated Internet Protocol (IP) or asynchronous transport mode (ATM) networks, PSTN, and wireless networks. The JAIN APIs include interfaces at the protocol level, for different protocols such as Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), and Transactional Capabilities Application Part (TCAP), as well as protocols residing in the higher layers of the telecommunications protocol stack.
JAIN includes a set of integrated network APls for the Java platform and an environment to build and integrate JAIN components into services or applications that work across PSTN, packet and wireless networks. The JAIN approach integrates wireline, wireless, and packet-based networks by separating service-based logic from network-based logic.
FIG. 1
illustrates a conventional JAIN implementation. As shown in
FIG. 1
, a conventional JAIN implementation can include a protocol layer
102
which can include interfaces to IP, wireline and wireless signaling protocols. Though only TCAP, JCC and H.323 protocols
110
are shown, the protocols supported by the JAIN specification are not limited to particular protocols and can include, for example, TCAP, ISUP, INAP, MAP, SIP, MGCP, and H.323. Moreover, the JAIN implementation can include an interface to a connectivity management and call control protocol such as JCC. The conventional JAIN implementation also can include an application layer
104
for handling secure network access and other external services. Finally, the conventional JAIN implementation can include a service layer
106
which can include a service creation and carrier grade service logic execution environment (SLEE)
108
.
Service components
112
are the core JAIN components and can execute in the SLEE
108
. More particularly, service components
112
can implement telephony and network services and can be constructed according to a standard component model. Instantiations of service component assemblies execute in coordination with the SLEE
108
. In operation, using information regarding the protocol layer
102
which can be incorporated into the SLEE
108
, service components
112
can interact with an underlying protocol stack
110
without having specific knowledge of the protocol stack
110
. More importantly, the SLEE
108
can relieve the service components
112
of conventional lifecycle responsibilities by providing portable support for transactions, persistence, load balancing, security, and object and connection instance pooling. In this way, the service components
112
can focus on providing telephony and/or network services.
Notably, the SLEE
110
can be communicatively linked directly to client components such as external applications
116
, protocol stacks
110
and service components
112
. For example, service components
112
executing at the service layer
106
in the SLEE
108
can communicate with protocol stacks
110
in the protocol layer through protocol adapters in the SLEE
108
. Protocol adapters typically can include class methods, callbacks, encapsulating interfaces, or event handlers. In many cases, an underlying protocol stack
110
can directly communicate with the SLEE
108
through an event table
114
in the SLEE
108
which can be configured to specifically handle events which are particular to the underlying protocol stack
110
. In consequence, the SLEE
108
can recognize those particular events, and upon receipt of such an event from the underlying protocol stack
110
, the SLEE
108
can pass the event to a subscribing service component
112
.
Despite the apparent advantages of the JAIN specification, however, conventional implementations of the JAIN specification include some drawbacks. In particular, in order to relieve service components of the complexities of communicating with client components, the SLEE requires specific knowledge of the client components. For instance, to communicate with the protocol stacks in the protocol layer, the SLEE requires specific knowledge of the underlying protocol stacks as will be apparent from corresponding event tables which can be used to facilitate communications between the SLEE and an underlying protocol stack.
Including specific client component information in the SLEE, however, can add unnecessary complexity to the SLEE. From a life-cycle maintenance perspective this can be problematic. Also, including client component information in the SLEE unnecessarily directly binds the SLEE to particular client components. Finally, directly binding the SLEE to particular client components can require the positioning of the application layer, protocol layer and the service layer in close computing proximity to one another. Hence, what is needed is a more flexible system and method for communicatively linking a
Creamer Thomas E.
Kallner Samuel
Moore Victor S.
Shachor Gal
Vortman Pnina
Akerman & Senterfitt
Hong Harry S.
LandOfFree
Service logic execution environment connector to client... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Service logic execution environment connector to client..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Service logic execution environment connector to client... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3294090