throbber
Integrating Communication Services
`
`Colin Low
`Hewlett Packard Laboratories,
`Filton Road,
`Bristol BS12 6QZ
`cal@hplb.hpl.hp.com
`
`Abstract
`The need for communication services which span multiple communication technologies is
`growing. Communication services are being developed in three areas: in the public switched
`telephony networks (Intelligent Networking), on the Internet in the form of integrated multi-
`media, including Voice-over-Internet, and in private switched telephony networks (enterprise
`CTI applications). This paper shows that is plausible to create unified services which span the
`Internet and public switched networks and goes on to describe Nexus, an architecture and pro-
`totype for integrated communication services.
`
`1. Introduction
`Communication services are intended to facilitate personal communication. The communica-
`tion services discussed in this paper are centred around voice telephony, the current mainstay
`of personal communications. Communication services add value to the basic communication
`act by dealing with many of the exceptions - the person to be contacted is unavailable, or they
`are talking to someone else, or they can be contacted by some other means - on another tele-
`phone, or via a pager or GSM Short Message Service, or via email. There may be services to
`screen outgoing and incoming calls, and services to simplify charging for the call. Taken
`together, they simplify the task of communicating with another party or parties.
`There is a paradox in the fact that too many methods of communication and too many disjoint
`communication services make communication more difficult. The ‘voicemail syndrome’ is an
`example, where a person receives messages on a corporate voicemail system, and some on an
`answering machine at home, and even some voice messages via email. His GSM mobile tele-
`phone, to which he forwards calls while on the move, also has a separate voicemail system. If
`his employer discourages the use of corporate facilities for personal communication, he might
`have a subscription with a local Internet Service Provider, and an additional email account for
`personal mail and voice messages, and an Internet telephone application capable of receiving
`.... more voicemail. For further entertainment we can assume that the mobile phone he uses on
`business is for business use only and there is a family mobile phone which receives some calls
`from relatives and close friends and this also comes ... with a voicemail system.
`Internet communication technologies have had a significant impact on personal communica-
`tions, firstly through text-based communications such as email, newsgroups and interactive
`chat groups, and now through developing Voice Over Internet (VOI) technology. Communica-
`tion is becoming more accessible and cheaper, and at the same time more complex. Section 2.
`of this paper looks at three major and partly disjoint areas where communication services are
`being developed and discusses the problems caused by this. Section 3. argues that the centre of
`gravity for communication services should be biased towards the Internet, with the WWW act-
`
`1
`
`Internal Accession Date Only
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 1
`
`

`
`ing as a model (or inspiration) for a communication service architecture. Section 4. discusses
`WebIN, a hybridisation of Internet technologies and Intelligent Networking which indicates
`that a unification of communication services from currently disjoint domains is plausible. Sec-
`tion 5. introduces Nexus, an architecture and working prototype for integrated communication
`services.
`
`2. Communication Services
`Communication services oriented around voice telephony are emerging in three areas: in the
`PSTN (and for convenience we include mobile telephony), in private switched voice networks,
`and on the Internet, as shown in Figure 1.
`
`Internet
`(WWW, VOI)
`
`Public
`Switched
`Networks
`(IN)
`
`Private
`Switched
`Networks
`(CTI)
`
`Figure 1: Communication Service Evolution
`
`Communication services in the PSTN are provided by the technology of IN [1][2]. Services
`such as Freephone (800 number), Credit Card Calling, Automatic Alternate Billing, Voicemail,
`Virtual Private Networks and a variety of personal call redirection and call management serv-
`ices are widely deployed in the public networks. Continued development and standardisation
`of IN is proceeding through the Capability Set standards (CS01, CS02, CS03) [3] adding more
`powerful interfaces for switch control. In anticipation of switched broadband networks, an
`architecture is being developed for full multi-party, multi-media services such as distance
`learning, Video Dialtone, Video-on-Demand, WWW-style content provision and Home Shop-
`ping [4].
`Communication services in private switched networks have centred around call centre and cus-
`tomer contact management applications. There are a number of proprietary variations of the
`ECMA CSTA standard for switch control [5], such as AT&T and Novell’s Telephony Services
`API (TSAPI), and industry groupings such as the ECTF and Versit are continuing to refine CTI
`standards. CTI applications are becoming increasingly prevalent with the ubiquity of MS Win-
`dows and the availability of the Microsoft/Intel Telephony API (TAPI) interface. CTI applica-
`tions are typically task-specific (e.g. personal call manager, automatic call distribution) and can
`have excellent integration with customer databases, screen pops, voicemail and voice messag-
`ing, email/voicemail integration, FAX and increasingly, Internet communications.
`Until recently communication services on the Internet were text-based - email, Usenet news-
`groups, Internet Relay Chat and form-based communication on the WWW using the Common
`Gateway Interface (CGI). The recent emergence of a large number of mutually incompatible
`Voice-over-Internet (VOI) applications has lead to the creation of industry groups (four at the
`time of writing) looking at interoperability issues, and it is clear from industry white papers
`
`2
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 2
`
`

`
`(e.g. [6] [7]) that VOI technology is being positioned as the first step in the evolution of sophis-
`ticated workgroup applications combining voice, video and data.
`While evolution of communication services in each of the three areas shown in Figure 1. is rel-
`atively unencumbered by evolution in the other areas, the overlaps are increasingly important
`and will become critical as the three technologies reach an equivalent level of maturity. For
`example, while is technically straightforward to bridge VOI calls through to the PSTN (and a
`number of commercial services exist to provide this facility) there is no corresponding unifica-
`tion of the service frameworks, so that a VOI contact service and an IN contact service will be
`disjoint. The impact on the end-user will be one of unnecessary complexity and increasing dif-
`ficulty in maintaining effective communications - the ‘voicemail syndrome’ writ large, and
`covering not just voicemail but most contact services. Each technology provides useful serv-
`ices taken by itself, but the areas of overlap are large and when there is no integration the effect
`is to undermine the value of any communication service.
`The thesis of this paper is that for communication services to be effective they must apply uni-
`formly regardless of whether the user is working within a corporate switched network, or mak-
`ing use of IN services on the wireless and wireline public networks, or using VOI workgroup
`applications on the Internet. The goal of communication services is to facilitate communica-
`tion. They cannot be oriented around a specific type of network or a specific communication
`technology as if no other methods of communication existed.
`We1 believe a unified communication service architecture has to take into account the follow-
`ing requirements:
`• communication technology neutrality.
`•
`terminal neutrality, in recognition of the integration of functions within personal appliances
`and an increasing diversity of appliances, so that it becomes difficult to say whether a device
`is a telephone, a personal assistant, a pager, a portable Internet terminal, a FAX terminal, or
`an offline mail reader.
`• policy-driven communication negotiation - negotiating communication method, quality of
`service, cost and personal preferences to find a highest common factor between communi-
`cating parties.
`terminal mediation, providing adaptation between different terminal types.
`•
`• a demand for powerful and configurable single-point-of-contact services which integrate
`multiple communication methods - wireless and wireline telephony, VOI, email, pagers,
`content (WWW), document sharing etc.
`• a demand for multi-party and workgroup communication services, including role-based
`communications.
`integration with emerging workgroup applications, and in particular Internet VOI and multi-
`media applications.
`• emerging switched multimedia services.
`•
`increased personal mobility and location-based services.
`•
`the growth of novel applications as a result of an increasingly instrumented environment,
`such as domestic and vehicle control and security - communication with an intelligent envi-
`ronment is rapidly becoming as important as interpersonal communication.
`A large measure of pragmatism will be needed in trying to satisfy these requirements, for the
`simple reason that each of the three areas in Figure 1. is well established and cannot be abol-
`ished by fiat - for example, there are 600 million wireline telephones in the world, and IN serv-
`
`•
`
`1.
`
`I write on behalf of the Nexus project team.
`
`3
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 3
`
`

`
`ices will remain popular for many years to come. This suggests hybridisation as a possible way
`forward, and later in this paper I describe WebIN, a hybrid of the WWW and IN which pro-
`vides control over telephony services from within a WWW-like service environment. WebIN
`an indication that unified WWW/IN services are plausible and this is a useful step forward.
`There are many points of correspondence between switch control in the public networks and
`switch control in private networks, and so the concepts in WebIN can be applied (although we
`do not discuss this here) to CTI applications in private switched networks.
`This leaves unresolved the question of where the centre of gravity for communication services
`should lie. This is a contentious issue, as each of the three technical communities has a stake in
`extending and exploiting an existing base of commercial applications. It is our belief, which
`we attempt to substantiate below, that WWW content services provide an excellent model for
`developing an architecture for integrated communication services. This architecture we have
`called Nexus because it represents the intersection of the three circles of Figure 1, and a
`description of a prototype implementation of Nexus concludes this paper.
`
`3. The World Wide Web
`The WWW is an architecture for providing information content services. The following char-
`acteristics of the architecture have played a part in its success:
`• an open service architecture - anyone can contribute new content services.
`• uniform resource location - service resources can be accessed from anywhere.
`• an hierarchical, scalable name translation service (the Domain Name Service).
`•
`scalable resource location ( currently > 30 million Uniform Resource Locators (URL)).
`• client/server protocols based on the Hypertext Transfer Protocol (HTTP) and Common
`Gateway Interface (CGI).
`• uniform and ubiquitous access via TCP/IP.
`• an evolving homogeneous application programming environment layered over inhomoge-
`neous physical platforms (for example, the JAVA language and class libraries combined
`with client browser integration).
`• an evolving Distributed Programming Environment (DPE) based on CORBA and the
`CORBA Internet Inter-Operability Protocol (IIOP), combined with widely endorsed propri-
`etary protocols such as SUN’s Remote Method Invocation (RMI) libraries for JAVA and
`Microsoft’s Common Object Model (COM).
`service compositionality - anyone can compose new services based on existing services
`(such as directory services, search engines, digests, topic-based information services).
`The openness has been critical in fostering service competition and a rapid pace of evolution.
`Survival of the fittest ensures that poor services are quickly ignored when superseded by better
`services. Excellent services (judged by level of use) can be created with a low level of capitali-
`sation.
`Service creation in IN is the dual of the WWW in that it is closed and the cost of entry is high
`and limited to a relatively small number of highly capitalised corporations. The SS7 signalling
`network has a global span but its use in the routine operation of the PSTN means that new
`applications have to be carefully resourced and closely vetted - IN is not open. There is often a
`low level of integration between different services; for example, the GSM standard for mobile
`telephony has a closed set of services which do not integrate with wireline IN services, a lead-
`ing cause of the ‘voicemail syndrome’ in the UK.
`The TINA-C consortium is reworking IN for the next generation of multi-media services, but a
`technical reworking in terms of object orientation, distributed programming and open switch-
`
`•
`
`4
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 4
`
`

`
`ing may not alter the business model - anecdotal evidence suggests that while the TINA archi-
`tecture represents a large increase in potential openness, the model for service provision is that
`of a small number of highly capitalised partner organisations providing network and communi-
`cation services rather than the devolved model of the WWW, where private individuals are able
`to create their own personal content services at low cost.
`The situation in the CTI marketplace is more promising than that in IN because there is more
`competition in the marketplace and more scope for rapid innovation. A personal computer
`application which interacts with a corporate PBX over a private LAN is a safer and simpler
`proposition than a similar application running in the SS7 network. Integration with the Internet
`is well advanced, and VOI integration is beginning to appear. The question mark in this area is
`whether CTI applications will present an open and extensible service framework, where the
`user can readily extend services and incorporate new services, or whether each application is
`sold as a closed (but steadily expanding) set of services. If the latter, then there will continue to
`be problems in providing a consistent and coherent set of services when IN services and VOI
`services are taken into account.
`Service openness and compositionality is one of the most powerful aspects of the WWW, and
`although CTI applications evolve more rapidly than IN services, a closed application cannot
`match the evolutionary pace we now observe on the WWW.
`
`4. WebIN
`The concept of WebIN was introduced in [9] and [10] and refers to the service architecture of
`the WWW taken together with the public telephony control architecture of IN. The aim is to
`make it possible to create personal communication services involving the PSTN in the same
`lightweight, low cost way as content services are created on the WWW.
`Many individuals and enterprises are using WWW sites as contact services; it is common to
`find that an organisational URL such as www.anenterprise.com is an indirection pointing to
`several kinds of contact information, such as a telephone number, a FAX number, an email
`address, and an HTML form interface. In an informal sense the organisational URL has
`become a medium-independent contact address and provides a useful contact service. Some of
`the information presented is operational in that a suitable browser can use it to perform com-
`munication acts (e.g. email, HTTP forms) and some information is non-operational - clicking
`on a telephone number does not normally initiate a PSTN telephone call.
`The WebIN physical architecture, shown in Figure 2, retains the conceptual structure of IN’s
`Distributed Functional Plane [8] but locates much of the key functionality outside of the SS7
`signalling network. The Service Data Function (SDF), the repository of communication serv-
`ice subscriber and subscription information, is removed from the closed SS7 network and relo-
`cated and physically distributed on the open WWW, where it becomes identical with a WWW
`site. In practice, a person can be identified both within the telephone network and on the
`WWW by a URL or URN. A kernel part of the Service Control Function (SCF) remains inside
`the SS7 network and interfaces with Service Switching Points (SSPs) in the normal way (e.g.
`via the IN Application Protocol). The partitioning of the control function between the (closed)
`SS7 network and the (open) public network or service provider intranet is an engineering and
`business issue, and several possibilities have emerged.
`A conservative position is to permit SDF provisioning via an Internet-enabled Service Man-
`agement Function which permits IN subscribers to configure service parameters using the
`WWW. This does not expose the SCF and associated service logic. The Nexus prototype
`(described below) moves most of the service logic out of the SS7 network and leaves a kernel
`of service independent interface functions (Service Independent Building Blocks in IN termi-
`
`5
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 5
`
`

`
`SCE/SMS
`Internet
`
`SDF
`
`SDF
`
`SDF
`
`Service Data
`Function
`
`SCF
`
`DPE
`(e.g. HTTP/CGI, CORBA)
`
`SCF
`
`SCF
`
`address
`translation
`database
`
`address
`translation
`database
`
`Service Control
`Function
`
`SSP
`
`SSP
`
`Service Switching
`Function
`
`Figure 2. WebIN Physical Architecture
`
`nology) inside the network.
`The WebIN SDF can be structured as shown in Figure 3. A Uniform Resource Locator speci-
`fies an individual’s communication service resources, and the resources themselves are distrib-
`uted in the same way as an HTML page can link geographically dispersed documents.
`
`Service Data
`Service Data
`Service Data
`
`URLs
`
`“Virtual Presence”
`
`Subscriber Profile
`Subscription Profile
`
`Service Logic
`(mobile telephony)
`Service Logic
`(wireline telephony)
`Service Logic
`(content service)
`Service Logic
`(electronic mail)
`Service Logic
`(active badge)
`
`Translation
`
`Personal Identifier
`(e.g. 700 number)
`
`Figure 3 The Service Data Function
`
`A personal identifier in the telephony world (e.g. a 700 number [11]) is associated with a URL
`in the WWW world. The key to the scaling, resilience, location transparency and ubiquitous
`access properties of the WebIN SDF is a fast, resilient, federated translation database associ-
`ated with the SCF to carry out this mapping. An example of such a technology is the Internet’s
`Domain Name Service (DNS) [12] [13], and we have used an unmodified, public domain
`implementation of DNS (BIND) to host a scalable telephone number-to-URL translation serv-
`ice.
`The ability of the SCF to carry out a personal number to subscriber resource translation means
`that subscriber resources are disassociated from a specific SCF and a specific service, and it
`becomes possible to amalgamate personal service resources for several services (even across
`several service providers) by using URLs, either in their current WWW instantiation or in
`some evolutionary form. Service composition is not limited to wireline or mobile telephony -
`content services, email services and location services (e.g. via an active badge) can become the
`
`6
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 6
`
`

`
`basis for integrated services. It is possible to integrate services across several service providers.
`Although we do not address the security and billing issues posed by WebIN, we believe that
`progress in practical algorithms for WWW electronic commerce addresses these concerns.
`
`5. Nexus
`Nexus1 is both a developing architecture for integrated communication services and a working
`research prototype based in Hewlett Packard Laboratories. It attempts to solve the problems
`and meet the requirements discussed in Section 2. of this paper, in the belief that as we use an
`increasing number of different methods of communication, intelligent communication services
`will become the nexus around which we build personal communications. These services will
`employ a wide range of information about the communicating parties to select and initiate an
`appropriate method of communication. The closest analogy is the way in which WWW home
`sites already provide a static view of multiple communication options.
`Nexus is inspired by the belief that powerful communication services should be created in a
`lightweight, open and extensible way, and that it should be possible for individuals to combine
`several existing services to create new services - in essence, that the power to create individual
`communication services should be moved out of closed networks and applications and vested
`in individuals, liberating communication services in the same way as the WWW has liberated
`content services.
`A primary concern for Nexus was that it should provide an implementation framework for
`WebIN, and that it should be capable of subsuming IN services, and referring to CTI, switched
`telephony services in general. It should also (following the reasoning presented earlier in this
`paper) be closely integrated with the Internet and WWW.
`We observed that control of switched telephony is based on event-based triggering of service
`logic; that is, at certain points in a call it is possible to associate service logic so that when the
`point-in-call is achieved, an event is generated which triggers the execution of service logic.
`This is the basis for IN services, and it is a very general and useful model for building commu-
`nication services.
`The set of Nexus events is completely open, so that anyone can create and export a new event
`type at any time. Events are represented using a structured but unencoded text-based transfer
`syntax that eliminates the need for a receiver to share state with a sender in order to unmarshall
`the information in an event. Events are propagated as undirected messages of type string, mak-
`ing it straightforward to transport Nexus events via many communication methods including
`TCP, email, CORBA, and just about any remote procedure call mechanism. The rationale for a
`text-based transfer syntax is that events are as important and intrinsic to communication serv-
`ices as WWW pages are to content services, and we wanted to encourage a transparent, intui-
`tively appealing and human-readable syntax. This has been a very liberating notion in practice
`- it is very easy to integrate communication applications into a Nexus system.
`The model for event processing is titled event refinement. In relation to a communication act,
`events are non-directed meta-information. A service subscribes to a set of events, adds a level
`of interpretation and synthesis to these events when they occur, and generates new events
`which can be regarded as a refinement of the original events, in that the semantic content of the
`newly generated events is considerably richer. An analogy is the commercial idea of value-
`added, defined as the difference in value between raw materials and finished product. Services
`in an event economy add value to events, and the output of a service is a set of events which in
`
`1. nexus [L., f. nectare, nex-bind] 1. A bond or link; a means of connection 2. A connected group or series. -
`Shorter OED.
`
`7
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 7
`
`

`
`some sense are richer in meaning. The model for event refinement is shown in Figure 4.
`
`Event
`Source
`
`Event
`Source
`
`Event
`Source
`
`Event
`Sink
`
`Event
`Source
`
`Event Cloud
`
`Side Effects
`(e.g. Telephony)
`
`Service
`Logic
`
`Service
`Logic
`
`Service
`Logic
`
`Service
`Logic
`
`Figure 4. Event Refinement
`
`Events in potentia are imagined as a cloud - that is, there is an extensible and potentially infi-
`nite set of events which can occur. Each instance of service logic subscribes to small part of the
`event set, and likewise each service exports its own events to the cloud. The system is
`grounded by primary sources for events - events which originate because of changes occurring
`in the world at large. Primary events “just happen” and trigger waiting service logic, which can
`refine these events into new synthetic events, or cause a side effect such as modifying persist-
`ent state, or control a device.
`Service logic is triggered by subscribing to an event using the event content as a guard. This
`mechanism is very general and leads to an ‘event plumbing’ physical architecture for federa-
`tion of the event space and a scalable filtering of events. For example, the call events associated
`with a campus PBX can be filtered so that my own service logic is triggered only by events of
`a specific type which refer to my specific telephone.
`The current Nexus prototype is a scalable, physical realisation of the distributed event cloud.
`All events, whether primary or synthetic, can, within the limitations of security, be subscribed
`to. Any piece of service logic can subscribe to any event no matter where it is generated.
`The physical basis for this is the Nexus Service Logic Execution Environment (SLEE), which
`hides the physical distribution of events and provides an execution environment for collections
`of service logic for different services. There can be any number of SLEEs, which correspond to
`HTTP servers on the WWW. Events are propagated to SLEEs on the basis of event subscrip-
`tions, represented as subscription events. Some SLEEs are closely associated with particular
`physical subsystems (e.g. a PBX, the IN SCF, an active badge system, a WWW browser).
`Some SLEEs exist purely to refine events. Other SLEEs (Event Blasters) have policies to
`implement event subscriptions and use content-based routing to act as event concentrators and
`multiplexors. This is shown below in Figure 5.
`There is a great deal of flexibility in the way SLEEs can be configured. For devices which pro-
`duce a large number of low-level events (e.g. a switch), it is useful to perform some level of
`synthesis in co-located service logic. This does not mask the low-level events from anyone
`wishing to subscribe to them, but for many services a smaller number of higher-level events are
`
`8
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 8
`
`

`
`SLEE
`(Interaction
`Policy)
`
`WWW
`Browser
`
`SLEE
`(Contact
`Policy)
`
`HTTP
`Server
`
`Event Blaster
`
`Event Blaster
`
`SLEE
`(Call Policy)
`
`SCP/SSP
`
`SLEE
`(email
`Policy)
`
`email
`
`SLEE
`(Badge
`Policy)
`
`Active
`Badges
`
`Smart
`Seat
`
`Figure 5. Nexus Physical Architecture (example)
`adequate. For example, the SLEE which interfaces to our PBX exports called-party-alerting,
`called-party-connected and calling-party-connected (among others) as high-level events as
`part of a third-party call service.
`The use of Event Blasters to concentrate and multiplex events is a convenience and provides a
`degree of isolation from the physical subsystems which originate events - Event Blasters act as
`‘well-known places’ with well-known URLs, and it is useful to point services at Event Blasters
`rather than physical subsystems. For example, in HP Labs originate proximity detection (Smart
`Seat) events from several sources, and it is convenient to direct these events from many sources
`at a single Event Blaster. A judicious use of Event Blasters is a way of achieving scaling by
`decomposing the event cloud, and resilience, by directing each event to multiple Event Blast-
`ers. The Event Blaster is a useful point for management, testing and diagnosis.
`The Nexus prototype is written in several languages, including VisualWorks (Smalltalk), Java,
`Scheme, C and Perl. The core of the system is written in JAVA and is closely integrated with
`the WWW - a combined Nexus SLEE/HTTP server provides WWW browser integration. The
`current prototype provides a variety of services contributed by individuals in HP Labs includ-
`ing:
`• a variety of telephony services via CTI control of a PBX.
`• personal location services based on Olivetti active badges.
`• presence monitoring using passive infrared sensors and pressure mats on chairs (“Smart-
`Seat”).
`• open, individually-created personal contact services integrated with personal WWW pages,
`which integrate telephony and location-based services.
`• a group contact service which builds on individual contact services and combines switched
`telephony with an Internet videoconferencing application.
`• a combined visualisation/telephony service which combines a fly-through 3D model of our
`laboratory with personal avatars whose position in the model is updated through active
`badge events. It is possible to call a person on the nearest telephone by clicking on their ava-
`tar.
`Most of these services use WWW pages with embedded applets to provide real-time user inter-
`action with service logic.
`
`9
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 9
`
`

`
`6. Other Work
`The event model of Nexus was inspired directly by IN, in particular the Basic Call State Model
`and its Detection Points [8]. Events (notifications) are intrinsic to network management sys-
`tems and there is a very large body of work on reactive event-driven systems. We believe our
`work differs to the extent that the event set is open and extensible, and new event types can be
`introduced at any time without rebuilding or reinitialising. Nexus SLEEs and Event Blasters
`are event-tolerant in that they can perform useful content-based routing and filtering on previ-
`ously unseen event types. The schema for an existing event can be extended without impacting
`existing applications.
`The Nexus event cloud and the model of event refinement does have some similarities to the
`LINDA tuple-space model of distributed computation [14].
`Nexus design was not influenced by the DARPA Knowledge Sharing Initiative and in particu-
`lar the Knowledge Query and Manipulation Language (KQML) [15], and the overall goals are
`different, but we observe many points of similarity. Our decision to use a textual transfer syn-
`tax and undirected messaging is one similarity, and the semi-declarative, content-based ‘unifi-
`cation’ of Nexus events and service logic is another. Other characteristics, such as content-
`based routing and filtering [16] can also be found. We regard this overlap as a happy accident
`and are continuing to study this work and its applicability to practical communication service
`applications.
`Another overlap with work in the AI community is in reactive control systems, for example the
`Procedural Reasoning System (PRS) [17] [18]. Although we have not done this, it would be
`straightforward to use an available PRS implementation (e.g. [19]) as a Nexus SLEE. For the
`kinds of communication service we have been authoring, it is unclear that the power of goal-
`directed reasoning is an advantage, but it is an interesting avenue for further research.
`
`7. Conclusion
`The Internet is becoming a powerful medium for many forms of communication, and the inte-
`gration of text, voice and video into powerful multimedia applications is proceeding rapidly.
`The number of personal communication alternatives taken across all networks is becoming
`very large, and we argue that communication services are the means to create order out of a
`potential chaos. WebIN is an example of how a hybrid of Internet technologies and the IN serv-
`ice architecture can be used to create unified services which span both the Internet and the
`PSTN.
`Our experience of using Nexus to build services which span the worlds of the Internet, the
`PSTN, and private switched networks via CTI, is that very powerful and novel services are
`possible, and that providing an open service framework to groups and individuals in practice
`results in the same kind of originality, inventiveness and individuality that has become the hall-
`mark of the WWW. People like it. Within HP Laboratories Nexus is evolving as a soft real-
`time event monitoring and control addendum to the WWW, and this makes possible a new kind
`of programming in much the same way as the WWW has transformed access to information.
`We believe that an open communication service framework of this type can and will evolve to
`replace existing closed frameworks for communication services.
`
`8. Acknowledgements
`The work described here has had substantial contributions from a large number of people in
`Hewlett Packard Laboratories, Hewlett Packard’s Telecommunication Systems Business Unit,
`and Hewlett Packard’s Telecommunication Networks Division.
`
`10
`
`CISCO SYSTEMS, INC. Ex. 1136 Page 10
`
`

`
`9. References
`[1] The Intelligent Network, Ambrosch W. D., Maher A., & Sasscer B. (Eds), Springer Verlag
`1989
`[2] Intelligent Network Overview, James J. Garrahan, Peter A. Russo, Kenichi Kitami, & Rob-
`erto Kung, IEEE Communications Magazine, March 1993
`[3] International Standards for

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket