`
`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
`Policy)
`
`
`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