CN1669014B - Facilitate access to functional network systems available on one or more networks - Google Patents

Abstract

A system and method for providing network applications with access to service functionality available via one or more networks or network terminals is provided. The method includes logically providing at least one network service broker between one or more network infrastructures and a service provisioning infrastructure operating on top of the network infrastructures. The loosely coupled interface of the network service broker is exposed to the service provisioning infrastructure. Access by network applications to value added services within the network infrastructure is facilitated through the loosely coupled network service broker interface.

Description

Facilitate access to functional network systems available on one or more networks

Cross References to Related Applications

This is a continuation-in-part of Application Serial No. 09/996,406, entitled "WebServicesPushGateway," filed with the United States Patent Office on November 20, 2001, which is assigned to the assignee of the present application, the contents of which are hereby incorporated by reference .

technical field

The present invention relates generally to network communication systems, and more particularly, to a system and method for facilitating access to service functionality available over wired and/or wireless networks.

Background technique

The modern communication era has given rise to a tremendous growth in wired and wireless networks. Computer networks, television networks, and telephone communication networks are undergoing an unprecedented technological development driven by consumer demand. Wireless and mobile network technologies have addressed related consumer needs while providing more flexibility and speed of information transfer.

Present and future networking technologies continue to facilitate information transfer and make it more convenient for users. The rapid expansion of local, regional and global networks such as the Internet has provided society with an ocean of information. These network technologies have increasingly evolved to include wireless and mobile technologies. Via these networks, information can be downloaded to desktop systems, wireless systems, mobile systems, and the like. For example, information available via the Internet can now be downloaded onto mobile wireless units such as cellular telephones, personal digital assistants (PDAs), laptop computers, and the like. One such technology that facilitates the transfer of Internet content to and from wireless devices is the Wireless Application Protocol (WAP), which integrates the Internet and other networks with wireless networking platforms. In general, WAP is a set of protocols used to describe the features and functionality of both Internet standards and wireless service standards. It has nothing to do with wireless networking standards and was designed as an open standard. WAP bridges the gap between the wired Internet paradigm and the wireless domain to allow wireless device users to enjoy the benefits of the Internet across both platforms.

Second generation wireless service, often referred to as 2G wireless service, is a current wireless service based on circuit switched technology. 2G systems such as Global System for Mobile Communications (GSM) and Personal Communications Service (PCS) use digital radio technology for improved quality and wider service over first-generation mobile technologies. 3G or third generation refers to a set of digital technologies that anticipate improvements in capacity, speed and efficiency through the introduction of new packet-based transmission methods between terminals and networks. Users of 3G devices and networks will be able to access multimedia services such as video-on-demand, video conferencing, fast web access and file transfers. Existing and future services are and will continue to be delivered through network service operators, who deliver services and applications to mobile device users over the network.

These services/applications hosted by web servers often require certain specific information in order for users to use the applications correctly. For example, the user may need to be authorized to use the application, and/or the user may need to be charged for using the application. Further, applications may need to know where the end user is, especially in the case of wireless terminals capable of roaming from one location to another. These and other "value-added" functions are often performed through other services available collaboratively on the network.

However, there are inherent challenges in creating a service provisioning infrastructure technology solution that can access the added value available in the network infrastructure. Accessing the functionality of a wireless (or wired) network is cumbersome due to the large amount of standard, technology, and vendor-specific functionality in the network components. With "aggregation," the environment is further complicated. A Service Provisioning Infrastructure (SPI) may not be created specifically eg for cellular networks, but may be a technical solution in the web domain. In this case, considerable investment must be made in the SPI technical solution to ensure that it can interface with the various networks in order to access the added value from the network. This brings about a problem: vendors of SPI technical solutions (ie, application servers) need to consider differences in network systems, as well as differences in technical solutions from multiple network component vendors.

Accordingly, there exists a need in the network communications industry to simplify access to functionality available from a network, whether fixed or wireless, including mobile networks, wireless LANs, and the like. The present invention addresses these and other deficiencies in the prior art, and provides numerous benefits over prior art systems and methodologies.

Contents of the invention

The present invention relates to a system and method for facilitating access to service functionality available over wired and/or wireless networks.

According to one embodiment of the present invention, there is provided a network system that facilitates access to functionality available on one or more networks, comprising: one or more terminals operable in the network; comprising one or more network a network infrastructure of the system; at least one network-enabled application operating within the service provisioning infrastructure for use by one or more of said terminals; and at least one network service broker comprising A loosely coupled interface for intermediating value-added network services from one or more of said terminals and network systems to said service provisioning infrastructure.

Preferably, the loosely coupled interface is a loosely coupled standardized interface.

Preferably, the loosely coupled standardized interface is defined in Extensible Markup Language XML.

Preferably, the loosely coupled interface includes a Web service interface.

Advantageously, said loosely coupled interface comprises a single loosely coupled web service interface exposed to said service provisioning infrastructure.

Advantageously, said network service broker comprises at least one network-coupled broker for communicating with one or more network components in said network infrastructure.

Preferably, the network service broker includes at least one terminal-coupled broker for communicating with one or more terminals.

Preferably, the network service broker includes at least one hybrid network service broker for communicating with one or more network elements in the network infrastructure and with one or more terminals.

Advantageously, said network service broker is an authentication broker for accessing authentication services for use by said network enabled applications.

Advantageously, said network service broker is a charging broker for access charging/billing services in connection with usage of said network enabled applications.

Preferably, said network service broker is a location broker for accessing a terminal location service to allow the terminal's location to be provided to said network enabled applications.

Preferably, said network service broker is a content order broker for storing subscription information to a profile register and for verifying a subscription intention of an end user of said terminal.

Advantageously, said network service broker is a presence broker for accessing a presence service to provide user presence information to said network enabled application.

Preferably, said network service broker is a customer provisioning broker for provisioning brokers to mobile terminals.

Preferably, said network service broker is a notification broker for helping to push content to terminals.

Preferably, said network service broker is a privacy broker for accessing end user private information and for controlling what information other brokers will provide to said service provisioning infrastructure.

Advantageously, said privacy broker controls which information other brokers will provide to said service provisioning infrastructure based on parameters defined by an end user of said terminal, wherein said parameter may be determined by an end user when requesting end user privacy information. provided manually, or automatically if the parameters have been predefined by the end user.

According to another embodiment of the present invention, there is provided a method for providing network applications with access to service functionality available via one or more networks, comprising: at one or more network infrastructures and at said network infrastructures providing at least one web service broker logically between service provisioning infrastructures operating on top; exposing loosely coupled interfaces of said web service brokers to said service provisioning infrastructure; and via said loosely coupled web service brokers A broker interface facilitates the web application to access value-added services within the network infrastructure, wherein facilitating access via the loosely coupled web service broker interface includes using any of a variety of service provisioning infrastructure technologies to make the service available to the application via the loosely coupled web service broker interface.

Advantageously, the above method further comprises communicating between said network service broker and said network infrastructure regardless of technical differences in one or more different network components operating within said network infrastructure.

Advantageously, the above method further comprises communicating between said network service broker and said network infrastructure despite technical differences on one or more network infrastructures having different access methods.

Preferably, said one or more network infrastructures collectively implement a plurality of different network technologies, and wherein said network service broker accommodates technology changes between said network technologies and service provisioning infrastructure technologies.

Preferably, exposing the loosely coupled interface of the web service broker to the service provisioning infrastructure comprises: exposing a loosely coupled web service interface to the service provisioning infrastructure.

Preferably, the above method further includes defining the loosely coupled interface in Extensible Markup Language XML.

Preferably, providing at least one web service broker comprises: providing a plurality of web service brokers, and wherein each of said plurality of web service brokers includes a A loosely coupled interface for intercommunication.

Advantageously, at least some of said plurality of network service brokers communicate with each other.

Preferably, said network infrastructure comprises at least one fixed network.

Advantageously, said network infrastructure comprises at least one wireless network.

Preferably, the above method further includes the application using the value-added service as set by the network service broker.

According to another embodiment of the present invention, there is provided a method for providing a network application with access to service functionality available via one or more networks, comprising: an logically providing at least one web service broker between service provisioning infrastructures; exposing loosely coupled interfaces of said web service brokers to said service provisioning infrastructure; and facilitating all The web application to access value-added services provided at least in part by the terminal, wherein facilitating access via the loosely coupled web service broker interface includes using any of a variety of service provisioning infrastructure technologies to enable The service is available to the application via the loosely coupled web service broker interface.

Preferably, the above method further comprises: communicating one or more terminal types of said terminals to said network service broker, and providing said terminal types to said service via a loosely coupled interface of said network service broker Provisioning infrastructure.

Preferably, the above method further comprises: configuring one or more user terminals via cooperative communication between the user terminal and the network service broker under the direction of the network application, wherein the configuration is in use by the user terminal implemented without regard to the protocol.

According to another embodiment of the present invention, there is provided a method for providing network applications with access to service functionality available via one or more networks, comprising: at one or more network infrastructures and at said network infrastructures at least one hybrid network service broker is logically provided between service provisioning infrastructures operating on it, and between one or more terminals and said service provisioning infrastructure; loosely coupling interfaces of said hybrid network service brokers exposing to the service provisioning infrastructure; and facilitating, via the loosely coupled hybrid web service broker interface, the web application to access value-added services provided via either or both of the terminal and the web infrastructure, wherein Facilitating access via the loosely coupled hybrid web service broker interface includes using any of a variety of service provisioning infrastructure technologies to make the service available via the loosely coupled hybrid web service broker interface to the The above application is obtained.

According to another embodiment of the present invention, there is provided a method for providing a network application working within a service provisioning infrastructure with access to service functionality available via a visited network in which an end user has roamed, comprising: providing usage authorization credentials to a visited network service broker associated with the visited network; receiving, at the service provisioning infrastructure, the visited network service broker from the home network service broker associated with the home network where the home network service broker exposes a loosely coupled interface to the service provisioning infrastructure to facilitate communication between each other; the address of the visited network service broker is used by the service provisioning infrastructure to access the visited network service broker; and assist the service provisioning infrastructure to access service functionality available from the visited network via a loosely coupled interface of the visited network service broker, the loosely coupled Interfaces are exposed to the service provisioning infrastructure.

Advantageously, providing said usage authorization credential to said visited network service broker comprises: providing said usage authorization credential to said service provisioning infrastructure via a loosely coupled interface of said home network service broker, and then via said home network service broker. The loosely coupled interface of the visited network service broker provides the usage authorization credential to the visited network service broker.

Preferably, providing the use authorization credential to the visited network service broker comprises: providing the use authorization credential directly from the home network service broker to the visited network service broker.

Advantageously, providing usage authorization credentials to said visited network service broker comprises: providing said usage authorization credentials to said visited network if a roaming agreement between said home and visited network authorizes provision of said usage authorization credentials to said visited network. The accessed network provides said usage authorization credentials.

According to another embodiment of the present invention, there is provided a method for providing a network application working within a service provisioning infrastructure with access to service functionality available via a visited network in which an end user has roamed, wherein A roaming agreement is established between the visited network and the end user's home network, the method comprising: between the service provisioning infrastructure and a home network service broker associated with the home network, communicating via a loosely coupled interface of the home network service broker exposed to the service provisioning infrastructure; and, communicating between the home network service broker and a visited network service associated with the visited network Communication between brokers, wherein the home network service broker acts as a proxy in accessing service functionality available via the visited network.

According to another embodiment of the present invention there is provided a method for providing a network application working within a service provisioning infrastructure with access to service functionality available via an access network in which an end user has roamed, wherein A roaming agreement has been established between the visited network and the service provisioning infrastructure, the method comprising:

Provides a visited network service broker logically between the visited network and the service provisioning infrastructure operating on top of the network infrastructure; exposes a loosely coupled interface of the visited network service broker to the a service provisioning infrastructure; and facilitating said service provisioning infrastructure to access service functionality available from said visited network via said loosely coupled interface of said visited network service broker, wherein said loosely coupled Web service broker interface facilitating access includes using any of a variety of service provisioning infrastructure technologies to make the service available to the application via the loosely coupled web service broker interface.

According to another embodiment of the present invention, there is provided a network service broker for facilitating a service provisioning infrastructure to access service functionality available via one or more networks, the network service broker comprising: An interface for accessing the service functionality from a network infrastructure; and a loosely coupled interface exposed to the service provisioning infrastructure, wherein the loosely coupled interface comprises: XML with an extensible markup language built on top of a web services platform A schematized, Web services-based interface for exposing service functionality available via the network.

According to one embodiment of the present invention, a networking system is provided for facilitating access to functionality available on one or more networks. The network system includes one or more terminals operable in the network and a network infrastructure including the one or more network systems. Web applications work within a service provisioning infrastructure for end use. At least one network service broker is provided comprising loosely coupled interfaces exposed to the service provisioning infrastructure for brokering value added network services from terminals and/or network systems to the service provisioning infrastructure.

In a more specific embodiment, the loosely coupled interface is a standardized interface, such as an Extensible Markup Language (XML) interface, or more specifically, a Web service interface. A web service broker can be a network-coupled broker, a terminal-coupled broker, or possibly a hybrid. A Web Service Broker may take on various forms and functions, including but not limited to: an Authentication Broker for accessing an Authentication Service for use by a Web Application, a Billing Broker for accessing charging/billing services in connection with usage of a Web Application, Location Broker for accessing terminal location services to allow provision of terminal location to web applications, Content Ordering Broker for storing subscription information to profile registers and verifying subscription intent of the end user of the terminal, for accessing presence PresenceService to allow provisioning of user presence information to web applications, Customer Provisioning Broker to mediate provisioning for mobile terminals, Notification Broker to help push content to endpoints, and Access Broker for final Privacy mediator for user private information.

According to another embodiment of the present invention, there is provided a method of providing a network application with access to service functionality available via one or more networks. The method includes logically providing at least one network-coupled network service broker between one or more network infrastructures and a service provisioning infrastructure operating on said network infrastructure. A loosely coupled interface of the web service broker is exposed to the service provisioning infrastructure. Through the loosely coupled network service broker interface, it becomes more convenient for network applications to access value-added services inside the network infrastructure.

According to another embodiment of the present invention, there is provided a method for providing a network application with access to service functionality available via one or more networks, wherein a terminal-coupled network service broker is provided. The terminal-coupled network service broker is logically located between one or more terminals and a service provisioning infrastructure operating on top of the network infrastructure. The loosely coupled interface of the network service broker is exposed to the service provisioning infrastructure, and the access by the network application to at least part of the value-added services provided by the terminal is exposed via the loosely coupled network service broker interface to the The service provisioning infrastructure. According to another embodiment of the present invention, the network service broker is a mixture of network-coupled and terminal-coupled network service brokers, so that through the loosely coupled interface, the network application can communicate with the network infrastructure via the terminal Access to value-added services provided by either or both frameworks is facilitated.

The network service broker of the present invention is also beneficial in the context of mobile terminal roaming. According to another embodiment of the present invention, a method is provided for providing network applications operating within a service provisioning infrastructure with access to service functionality available via a visited network in which an end user has roamed . The method includes providing usage authorization credentials to a visited network service broker associated with the visited network. The service provisioning infrastructure receives the address of the visited network service broker from a home network service broker associated with the home network. The home network service brokers expose loosely coupled interfaces to the service provisioning infrastructure to facilitate communication between each other. The visited web service broker is accessed by the service provisioning infrastructure using the address of the visited web service broker. Access by the service provisioning infrastructure to service functionality available from the visited network varies through loosely coupled interfaces exposed to the visited network service broker of the service provisioning infrastructure more convenient. In accordance with another roaming embodiment of the present invention, a method is provided for providing network applications operating within a service provisioning infrastructure with access to service functionality available via a visited network in which an end user has roamed. access. In this case a roaming agreement has been established between said visited network and said end user's home network. The method includes performing between the service provisioning infrastructure and a home network service broker associated with the home network via a loosely coupled interface exposed to the home network service broker of the service provisioning infrastructure communication. The method further includes communicating between the home network service broker and a visited network service broker associated with the visited network, wherein the home network service broker is accessible via the visited network Network-obtained service functionality acts as a proxy for access. In yet another roaming embodiment, a method is provided for providing network applications operating within a service provisioning infrastructure with access to service functionality available via a visited network in which an end user has roamed, wherein A roaming agreement has been established between the visited network and the service provisioning infrastructure. The method includes providing a visited network service broker logically between the visited network and the service provisioning infrastructure operating on top of the network infrastructure, and loosely coupling the visited network service broker to Interfaces are exposed to the service provisioning infrastructure. Access by the service provisioning infrastructure to service functionality available from the visited network is facilitated through the loosely coupled interface of the visited network service broker.

According to another embodiment of the present invention, a network service broker is provided for facilitating a service provisioning infrastructure to access service functionality available via one or more networks. The network service broker includes an interface for accessing service functionality from a network infrastructure. The web service broker further includes a loosely coupled interface exposed to the service provisioning infrastructure, wherein the loosely coupled interface includes a Web-based A service's interface for exposing service functionality available via the network.

The above summary of the present invention is not intended to describe each example embodiment or implementation of the present invention. This is the purpose of the figures and related discussions that follow.

Description of drawings

The invention is illustrated in connection with the embodiments illustrated in the following figures.

FIG. 1 is a block diagram generally illustrating the composition of a network service broker according to one aspect of the present invention;

Figure 2 illustrates an example of how service applications in a service provisioning infrastructure (SPI) can benefit from such a loosely coupled interface, and how the resulting added value is exposed to the SPI by the Web Service Broker;

Figure 3 illustrates various representative network service brokers that may be implemented in accordance with the present invention;

Figure 4 illustrates the architecture of a generic web services broker in accordance with the principles of the present invention;

FIG. 5 is an exemplary embodiment of a network environment implementing an authentication broker according to the present invention;

FIG. 6 is an exemplary embodiment of a network environment implementing a charging intermediary according to the present invention;

FIG. 7 is an exemplary embodiment of a network environment implementing a location broker according to the present invention;

FIG. 8 is an exemplary embodiment of a network environment implementing a content order broker according to the present invention;

Figure 9 is an exemplary embodiment of a network environment implementing a content delivery broker according to the present invention;

FIG. 10 is an exemplary embodiment of a network environment implementing a presence broker according to the present invention;

Figure 11 is a diagram of a representative profile register;

12 is an exemplary embodiment of a network system providing a Web service notification broker according to the principles of the present invention;

Figure 13 is a block diagram illustrating an exemplary embodiment of a Web service push gateway architecture according to an embodiment of the present invention;

Figure 14 illustrates an exemplary implementation of the Mediator Domain/Web Service Logical Interface;

Figure 15 illustrates an exemplary embodiment of a Web service logic/API interface;

Figure 16 illustrates an exemplary embodiment of a terminal/broker domain interface;

Figure 17 illustrates an embodiment using multiple network service brokers for multiple network operators;

Figure 18 illustrates an exemplary implementation of an interface broker according to the principles of the invention; and

Figure 19 illustrates an exemplary manner in which roaming issues can be managed through the use of a network service broker according to the present invention.

detailed description

In the following description of various embodiments, reference is made to the accompanying drawings, which hereby form a part hereof, and in which are shown by way of illustration various embodiments in which the invention may be practiced . It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.

The present invention relates to a system and method for facilitating access to functionality available on wired and/or wireless networks. The present invention implements a network service broker that simplifies access to functionality available on various networks, whether fixed or wireless. The web service broker exposes loosely coupled standard web service interfaces (or other standardized interfaces) to the service provisioning infrastructure and implements well-defined allowed services.

Traditionally, communication between terminals and service provisioning infrastructure solutions occurs on top of a network infrastructure using standard connection methods. It is inherently difficult to create service provisioning infrastructure solutions that provide continuous access to the "value added" provided, such as location or presence information available in the network infrastructure. Accessing the functionality of a wireless or wired network is cumbersome due to the variety of standards, technologies, and vendor-specific functionality that is, and will be, associated with network components. Aggregation further complicates this issue. The service provisioning infrastructure may not be specially created for a specific network, such as a cellular network, but may be a technical solution in the web domain. In this case, considerable investment must be made in the service provisioning infrastructure (SPI) technology solution to ensure that it can interface with the respective network in order to access any added value available via the network. This issue is for developers hosting applications in SPI, who therefore need to account for differences in various network systems, network component vendors, and so on.

These challenges can be resolved by using one or more web service brokers according to the present invention. FIG. 1 is a block diagram generally illustrating the composition of a Web Services Broker according to an aspect of the present invention. The network environment 100 includes various network infrastructures 102, which generally include various network technologies and technical solutions provided by different vendors. The environment 100 in FIG. 1 also includes various service provisioning infrastructure technical solutions 104, which represent infrastructures that application servers can use to provide applications and services on a specific network. Terminals 106 represent various terminals that may be used on the network including, for example, desktop and portable computers and terminals, cellular and other wireless telephones, personal digital assistants (PDAs), or any other type of terminal capable of communicating via a network .

According to the present invention, one or more network service brokers 108 are provided in the network environment 100 . The web service broker 108 may provide various functions. One function of the web service broker 108 includes exposing loosely coupled interfaces (eg, Web service interfaces) to the SPI 104 , while another function is to implement or facade well-defined enabled services. The web service broker 108 is able to expose services through agreed upon interfaces without having to expose the underlying end-to-end implementation. The service broker helps operators open their services to external applications and provides value-added access to specific network domains (eg mobile domain). The service broker also enables the operator to bill the SPI for information provided to the SPI. If said information is provided from the intermediary to the terminal, the end user can eventually be charged for this service. Roaming-related charges can occur when Brokers provide services to Brokers in other networks. In one embodiment, the loosely coupled interface to SPI 104 is a "standardized" or otherwise agreed upon Web service interface, more fully described below.

The "added value" may originate from the network, from the terminal, or from functionality distributed between the network and the terminal. For example, the added value may be built into today's mobile network infrastructure, in fixed networks, in networks using unlicensed band wireless technology, etc. In a more specific example in the context of location services, location information within a corporate intranet and/or certain Internet hotspots using license-exempt band wireless technology, or within a fixed corporate intranet is important to the system. known, but not necessarily a way to access it. According to the invention, it is thus possible to create said intermediary for license-exempt frequency bands, or even for fixed Internet access.

As noted above, one embodiment of the web services broker includes a web services interface to SPI 104, which may be defined in Extensible Markup Language (XML). Web services are web-based (especially Internet-based) modular applications that accomplish specialized tasks and conform to specialized technical formats. Web services are represented by a number of emerging standards that describe service-oriented, component-based application architectures, which together provide a unique

A distributed computing paradigm focused on delivering services across the Internet. In general, Web services are self-contained modular applications that can be exposed in a ready-to-use format, located, and invoked across the World Wide Web. When a Web service is deployed, other applications and Web services can locate and invoke the deployed service. They can complete a variety of functions, from simple requests to complex business processing.

Beneficially, Web services are accessed via ubiquitous Web protocols and data formats, such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML). Therefore, currently, the platform for basic web services is XML plus HTTP, and in addition other protocols can be used, such as SOAP for RPC, WSDL for service interface description, UDDI for service discovery, etc. XML is a text-based markup language that is currently widely used for data exchange on the Web. As with HTML, data is identified using tags, which are collectively called "tags." XML tags identify data and act as field names in programs. XML is a language that enables complex interactions between clients and services and between components of composite services to be represented. HTTP is an application protocol, more specifically, a set of rules for exchanging files (text, graphic images, sound, video and other multimedia files) on a network such as the World Wide Web. While the examples set forth herein are generally described in connection with XML and HTTP, it should be appreciated that this is for illustration purposes and that present and future types of protocols and data formats may also be employed.

More specifically, Web services represent a collection of several related technologies and involve a connection between at least two applications, such as Remote Procedure Call (RPC), where queries and responses are exchanged in XML over HTTP. Web services technologies can be defined in terms of various technology layers. The core layer includes a transport layer, such as TCP/IP or the previously mentioned HTTP, in which XML messages can be transmitted. An XML messaging layer, such as Simple Object Access Protocol (SOAP), also represents the core layer of Web services. SOAP is a protocol specification that defines a unified way of passing XML-encoded data and defines a way of performing RPC using HTTP as the underlying communication protocol.

Higher layers of the Web services stack include a service discovery layer, which may include technologies such as Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). WSDL is an XML-based description that defines how to interface with a particular Web service, and thus instructs the service provider how to describe the basic format of Web service requests over different protocols or encodings. It is used to describe what a Web service can do, where it resides, and how to invoke it. UDDI provides a way that clients can dynamically locate other Web services. It represents a set of protocols and common directories for registration and real-time location of Web services and other business transactions. UDDI provides a way for Web service providers to register themselves, and a way for applications to find, connect to, and interact with a particular Web service. Other higher-level layers of the web services stack can include a workflow layer. The workflow layer can include technologies such as Web Services Flow Language (WSFL). WSFL is an XML language used to describe the composition of Web services and allows recursive composition of Web services within others in order to create more complex features built on top of existing Web services.

In employing Web services, the above and other technologies, protocols, data formats, etc. may be used. However, these known techniques are cited in order to provide exemplary techniques that are currently in use in the development and use of Web services. Thus, the present invention may use these known technologies, but is also applicable to other present and/or future technologies, as will be readily apparent to those skilled in the art from the description given herein.

Referring again to FIG. 1 , network service broker 108 may include a network-coupled broker that communicates with network elements in network infrastructure 102 , as indicated by line 110 . This allows complexities due to differences in network components from multiple vendors or sources, and due to differences between network infrastructures in general, to be hidden. One embodiment of the network-coupled mediator includes a web service interface to SPI 104, wherein the web service interface is defined in XML. Such an exemplary XML interface allows hiding network type and network component differences. For example, differences between various types of networks, such as fixed/wired and wireless (eg, WLAN, Bluetooth, mobile/cellular, etc.) networks can be hidden. In the case of mobile networks, there are various network subtypes such as Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), etc., and their differences can also be hidden. In the case of network components, specific protocols using network added value can be hidden. For example, Nokia's proprietary interface protocol to the Message Distribution Computer Interface (CIMD) of the Short Message Service Center (SMSC), which can be hidden from the SPI 104 in the case of a Notification Broker, an exemplary embodiment of which will be described more fully below.

The network service broker 108 may include a terminal-coupled broker that communicates with the device represented by terminal 106 , as indicated by line 112 . The terminal-coupled broker communicates with the terminal 106 and, when the broker and the terminal cooperate, exposes the available service (or services) or functionality (or functionality). In one embodiment, the interface is defined in XML. The XML interface makes it possible to identify the terminal type in a common or standard way, regardless of the protocol used for identification between the terminal and the mediator. It also allows the terminal to be configured in a common way, independent of the specific protocol used by the vendor of the terminal for configuring the terminal. The terminal-coupled mediator may also conceal differences in the set of protocols used by the terminal, for example concealing differences in the set of protocols used to communicate presence information using a network.

A mediator can act as a mediator for network coupling and terminal coupling at the same time. In this case, the functionality is distributed between the network and the terminal, and the intermediary provides added value as the sum of the functionality in both. Further, the terminal can communicate with the network service broker to access the added value of the network through the same interface as that used by the SPI 104 .

Various brokers associated with the network services broker according to the present invention also include management interfaces for one or more management systems or other operations support systems (OSS) (not shown). The management interface can provide various interfaces and services, including broker monitoring, broker statistics, broker configuration tools, and customer service and billing (CCB) or other billing/billing system interfaces. The mediator monitoring relates to the monitoring of mediator process status and operation. Broker statistics relate to statistics provided by brokers about their usage, transaction volume, response time, etc. The broker configuration tool may preferably be a web interface to said broker for use by a system administrator to implement configuration activities. With respect to the CCB system interface, it is desirable that all subscriber related information reside in the profile register. However, this type of architecture tightly links the release cycle of all mediators to that of such a profile register, which is extremely undesirable in practice. Therefore, there may be a broker-specific store of subscriber information in some brokers, and this information is often maintained through the CCB system. In this case, the mediator can comprise a CCB system interface for obtaining this information.

The network service broker can further hide the complexities surrounding roaming issues. When a wireless user is roaming in an area outside the home network, services in the visited network may need to be accessed. Typically, the user has no business relationship with the visited network in which the user has roamed. Instead, the home network operator has a business relationship (eg roaming agreement) with the visited network. According to the invention, the same approach can be extended to the services provided by the mediator of the home network. An example of such a roaming scenario is provided below.

Thus, a network service broker provides a network operator with a controlled way of exposing the functionality or information available in the network. The mediator enables the owner of the network to protect the privacy of the information or functionality associated with the end user based on the end user's preferences (eg, location information, identity, etc.). The intermediary further enables the owner of the network to charge service providers, end users, or other parties that receive this added value. Mediators allow complexities due to differences in network elements from multiple vendors or sources, as well as differences between network infrastructures in general, to be hidden.

In one embodiment, a network service broker according to the present invention provides value-added access to the mobile domain. The added value may originate from the network, from the terminal, or from functionality distributed between the network and the terminal. The web service brokers according to the invention do not disrupt the communication between the terminal and the SPI, since these brokers allow access to the added value of the mobile domain through open loosely coupled interfaces. Traditional application design depends on the tight interconnection of all auxiliary components. In this case, the developer must have complete knowledge and control over both ends of the connection. In a loosely coupled system, the implementation of either end of the connection can be changed and the application will continue to work. Current technical implementations of loosely coupled systems include the use of message-based asynchronous techniques for robustness, and further the use of ubiquitous protocols such as HTTP, SMTP, XML. Future technical solutions will also contribute to loosely coupled interfaces. Discovery of network resources/services is a problem in loosely coupled systems. One current way of locating such services is through UDDI operators, which is a list of public services. Figure 2 illustrates an example of how a service application in an SPI can benefit from such a loosely coupled interface, and how the resulting added value is exposed to the SPI by the Web Service Broker.

Terminals employing standard technologies 200 (eg, WAP, SyncML, MMS, Java, etc.) interface with services/applications 202 provided by SPI 204 as indicated by line 206 . Service 202 requests the identity associated with the terminal from SPI 204 as indicated by line segment 208, and SPI 204 then interfaces with authentication broker 210 in the intelligent edge of the network in which the terminal is located, as indicated by line segment 212. The authentication broker 210 provides a means for the service application 202 to uniquely identify the terminal for the current session.

The application 202 requests the location of the terminal by providing the location broker 214 with the unique identifier received from the authentication broker 210 . This request is shown by line 216 . As indicated by line segment 220 , location broker 214 communicates with privacy broker 218 requesting permission to provide the location of the terminal to service application 202 . Depending on the policy set by the end user, the privacy broker 218 can work in one of several possible ways, such as denying the request by default, accepting the request by default, if the application 202 can be uniquely identified and has been authorized to access the location information Accept if access is made, prompt the end user for permission to release the information, etc. In other words, the privacy broker 218 and/or associated privacy service provider can have the effect that information and functionality exposed by various other brokers from the network in question to the service provisioning infrastructure is automatically "private protected". ”, so that, for example, the location broker requests the privacy broker/privacy service provider associated with the user whether the user has agreed or needs to agree to release the private information.

Location broker 214 can obtain location information from location client 222 , as indicated by line 224 . The location information provided by location broker 214 may be based on capabilities in the network, such as enhanced observed time difference (E-OTD) positioning techniques. Alternatively, the location information may be based on capabilities provided in the terminal, such as global positioning system (GPS) positioning technology. Regardless of where the location information originated, location broker 214 may provide this information to service applications, provided that privacy broker 218 accepts such a transaction.

A service application 202 that has received location information via SPI 204 can now provide terminal aware/location-based services to terminals using standard technology 200, as indicated by line 226.

Another example includes the use of a payment broker 228, which may be invoked when an end user requests a billable service from a service application. In this case, the service application 202 already has a previously provided unique identifier for the terminal. By providing this identification to SPI 204 via line segment 230, SPI 204 further communicates with payment intermediary 228, as indicated by line segment 232, requesting creation of a billing record matching the requested payment. Communication using standard technique 200 can then continue, as indicated by line 234 .

As the example in FIG. 3 shows, a variety of different web service brokers can be implemented in accordance with the present invention. FIG. 3 illustrates a number of representative web service brokers 300 . Authentication Broker 302 provides authentication services, while Billing/Payment Broker 304 helps bill subscribers for services. The location broker 306 helps determine the subscriber's location. The notification 308 and content delivery 310 broker provides services for applications to push content, such as multimedia messages, to subscribers. Content Subscription Broker 312 provides a means for service providers to subscribe to digital content. Presence Broker 314 maintains subscriber dynamic status information and Customer Provisioning Broker 316 facilitates provisioning of mobile clients. The profile register 318 includes information about the subscriber's services, and the types of entitlements the subscriber has granted to the service provider. The context broker 320 is operable to provide context information to the service provisioning infrastructure for the purpose of creating applications aware of the end user's context, where the context relates to the context in which the end user is with his/her terminal. Other 322 mediators can also be used.

Figure 4 illustrates a generic web service broker architecture 400 in accordance with the principles of the present invention. In this architecture, the various network service brokers 402, 404, 406 become part of an intelligent edge 408 surrounding a general packet radio service (GPRS) 410 or other wireless communication network. The network service brokers 402, 404, 406 will allow services to be provided either to the operator's 412 own applications 414, or to external service/content providers' applications 416 via the Internet 418 or other public network. In either case, applications 414, 416 will run on top of SPIs 420, 422, respectively, as SPIs 420, 422 provide local services to applications and application programming interfaces (APIs) to web service brokers.

As described in conjunction with FIG. 3, various web service brokers can be implemented in accordance with the present invention. The architecture of various exemplary web service brokers is described below.

FIG. 5 is an exemplary embodiment of a network environment in which an authentication broker 500 is implemented. In one embodiment, the authentication broker solution involves client authentication based on the endpoint's Internet Protocol (IP) address. Client authentication can also be provided based on other technologies and protocols such as SSL/TSL (Secure Sockets Layer/Transport Sockets Layer). As is known in the art, SSL is a method of ensuring secure communication between two points on the Internet, such as a web browser and a web server. TSL also ensures secure communications and includes advanced methods of controlling privacy and security. For purposes of illustration, and not limitation, the description associated with Figure 5 assumes that client authentication is based on the endpoint IP address.

This example assumes that the terminal 502 works in conjunction with the GPRS 504 wireless communication service. The GPRS connection procedure is a mobility management function that establishes a connection between the terminal 502 and the network 504 . A Gateway GPRS Support Node (GGSN) 506 is a support node that acts as a gateway between the GPRS network 504 and a packet switched public network such as the Internet 508 . When the terminal 502 generates a GPRS connection, the IP address/MSISDN number pair is stored in the authentication intermediary 500 . MSISDN (Mobile Station ISDN/PSTN Number) is a mobile number used by GSM/DCS networks which contains things like country code, national destination number, Home Location Register (HLR) identifier and subscriber identifier (ID) Information. When a subscriber accesses a service, WAP Gateway 510 requests a Subscriber ID from Authentication Broker 500 using, for example, the source IP address as a key.

Authentication Broker 500 queries Profile Registry 512 to determine the appropriate form to use to provide the Subscriber ID to the particular service the Subscriber is attempting to access. Subscriber IDs can be provided in various formats, including MSISDN numbers, virtual subscriber IDs (VSIs), and the like. VSI formats may also include candidate formats, including VSIs that remain valid during several sessions, over a certain period of time, or during a particular WAP session. The subscriber ID returned from the profile register 512 is provided to the application server 514 via the WAP gateway 510 . In one embodiment, the subscriber ID may be provided in an HTTP header.

In one embodiment, application server 514 may request additional authentication-related information or services from authentication broker 500 , as shown via communication path 516 . To make this request, the application server 514 can use the VSI it obtains via HTTP headers. Such a request may be, for example, a request for an MSISDN number, a user name or an address, a request for obtaining a persistent VSI for subsequent push service use, a request for extending the validity period of a VSI, and the like. When an application server 514 makes such a request for additional information, authentication broker 500 queries profile register 512 to determine whether the application server 514 is authorized to request the particular information or service.

In the embodiment in Figure 5, client authentication may be based on source IP address. This provides sufficient security since user traffic between terminal 502 and GGSN 506 is carried via tunnels, ie secure communication paths. This enables filtering of IP packets not having an IP address assigned to the terminal 502 in the GGSN 506 . Furthermore, when there is a virtual private network (VPN) between the WAP gateway 510 and the application server 514, the subscriber ID remains unaffected.

FIG. 6 is an exemplary embodiment of a network environment in which charging broker 600 is implemented. A general charging and billing system may include a GPRS charging gateway 602 that collects charging records, such as call detail records (CDRs), from Gateway GPRS Support Nodes (GGSN) or other supporting nodes, and merges these CDRs and converts them into After proper formatting, they are forwarded to the billing system. In one embodiment, charge records may be provided to postage paid billing system 604 via mediation facility 606, which is used to interconnect such operational support systems (OSS).

According to the exemplary embodiment illustrated in FIG. 6 , an application server 608 makes a request for a billing service via a billing broker 600 . This request may be made from SPI 608 to Billing Broker 600 using the Virtual Subscriber ID received via Authentication Broker 610, as explained in connection with FIG. There are a number of services available via this interface, including "prepaid" functionality, where the application server 608 asks whether a specific charge amount can be debited from a prepaid subscriber account. Another available service is post-pay functionality, where a charge amount is added to the subscriber's bill.

Billing Broker 600 uses the virtual Subscriber ID included in the charging request to request the actual Subscriber ID from Authentication Broker 610 . Billing broker 600 then queries profile register 612 to determine if the application is authorized to bill the subscriber. If so, the charge is sent to the prepaid balance database 614 for debit. If the prepaid balance has been depleted, a message is sent to the Authorization Broker 610 indicating a denial of service. Alternatively, the charges may also be stored in the charges database 616 for later provision to the post-pay billing system 604 .

FIG. 7 is an exemplary embodiment of a network environment in which location broker 700 is implemented. The location solution may eg be based on the Location Services (LCS) standard, where the external interface to the positioned infrastructure is provided through a standard Gateway Mobile Location Center (GMLC) 702 . GMLC 702 is a gateway that receives requests from location-based applications, requests mobile location information, and forwards mobile location information to location-based applications. However, the GMLC 702 does not provide a conceptual model used by the Network Service Broker, and requires a separate Location Broker 700 in this embodiment. For example, in GMLC 702, subscribers are identified by MSISDN numbers, while location broker 700 may use a virtual subscriber ID as explained in connection with FIG. Further, the mediator can hide the differences of various network types that are not handled by the GMLC702. The mediator can process information extracted, for example, from a corporate intranet extended using license-exempt technologies such as wireless local area networks (LANs), Bluetooth wireless technology, and the like.

In the exemplary embodiment illustrated in FIG. 7, the application server 704 requests a subscriber location via the Internet 706 (or other network) using a virtual subscriber ID (VSI) as a key. Location Broker 700 queries Profile Registry 708 to determine if Application Server 704 is authorized to request location information for the subscriber. The location broker 700 requests the subscriber location from the GMLC 702 and returns the location information to the application server 704 . Optionally, Location Broker 700 may also send a charging slip to Billing Broker 710 to add to the subscriber's or application's mobile service bill.

FIG. 8 is an exemplary embodiment of a network environment in which a content order broker 800 is implemented. The role of the content subscription broker 800 includes providing an interface for the content/service provider to store subscription information into the profile register 802, and also to perform communication with the end user of the terminal 804 in order to verify that the end user is actually willing to subscribe of.

One way a subscriber may initiate the subscription process is for the subscriber to send a message using Short Message Service (SMS), eg via SMSC 806, with a key to a specific MSISDN number. Messages are routed from SMSC 806 to Application Server 808 so that the subscriber's MSISDN number is replaced by a virtual subscriber ID. Another representative way a subscriber may initiate a subscription process is for the subscriber to browse a WAP/Web site and issue a subscription to SPI 808 via WAP gateway 810. In this case, the content/service provider receives the subscriber's virtual subscriber ID in an HTTP (or other) header.

Once the subscription process is initiated, the application 808 sends the subscription information to the content order broker 800 . Content Subscription Broker 800 queries Profile Register 802 to determine if the subscriber is permitted to subscribe to such content. If so, the content order broker 800 requests the subscriber to verify whether the subscriber is actually willing to carry out the transaction. The content subscription broker 800 stores the subscription information in the profile register 802 and may send a charging slip to the charging broker 812 .

FIG. 9 is an exemplary embodiment of a network environment in which a content delivery broker 900 is implemented. Some network operators do not want to be digital content resellers, but merely provide delivery and billing mechanisms for resellers. The functionality of the content broker 900 includes at least blocking unwanted content, selecting a delivery mechanism (e.g., SMS via SMSC 902, MMS via MMSC 904, or other mechanisms depending on subscriber's terminal 906 capabilities), and sending billing To the charging intermediary 908.

The application server 910 sends the digital content to the content broker 900 . Before that, the application 910 may optionally query the capabilities of the terminal 906 and the current status of the subscriber from the profile register 912 and the presence broker (not shown), respectively. The content broker 900 queries the profile register 912 to determine at least: 1) whether the application server 910 is authorized to send the particular content to the subscriber; 2) whether the subscriber is allowed to receive the content (e.g., whether there is sufficient prepaid fee balance); and 3) what are the capabilities of the subscriber's terminal. The content broker then performs the required content adaptation and sends the content using the bearer corresponding to the preferred delivery mechanism 902,904.

FIG. 10 is an exemplary embodiment of a network environment in which presence broker 1000 is implemented. Like the location broker example described above, the presence broker solution includes an industry standard server (standard presence server 1002) that provides a standard external interface, but does not follow the conceptual model provided by the web service broker. Thus, the presence broker 1000 can be used even in situations where a standard presence server 1002 is available in a network environment.

In the example shown in the figure, the application server 1004 requests the subscriber's presence status, or current "context", from the presence broker 1000, using the virtual subscriber ID as a key. Presence Broker 1000 queries Profile Register 1006 to determine if Application Server 1004 is authorized to request the subscriber's presence information. If so, presence broker 1000 requests subscriber presence information from standard presence server 1002 and returns the presence information to application server 1004. Presence information includes information such as whether the subscriber is online, and information about the characteristics of the terminal being used by the subscriber at that time. Optionally, the presence broker 1000 may also send a bill of charge to the billing broker 1008 for addition to the subscriber's or application's bill.

It should be appreciated that the exemplary network service broker and associated exemplary architecture described above are not limited to the network environment in which they are described. Rather, the examples provided above illustrate specific embodiments of mediator implementations. Intermediaries can be used to simplify access to all functionality available on the network, whether fixed or wireless, including mobile networks as well as networks such as wireless local area networks (LANs).

FIG. 11 is a diagram of a representative profile register 1100 . The profile register 1100 stores information about the subscriber's services 1102, preferences 1104, terminal capabilities 1106, and other 1108 information. As noted in the previous examples, the profile register 1100 is normally accessed by different network service brokers, but it also provides an external interface for content/service providers. Such an interface is used, for example, to perform various operations such as querying the capabilities of the user's terminal, querying various other services to which the subscriber has subscribed, and authorizing the user to access specific services. Applications may use profile register 1100 information for various additional purposes.

Another example of a web service broker is a notification or "push" broker. In a typical client/server model, a client requests a service or information from a server, and the server responds by sending the information to the client. Push technology broadly refers to sending information to one or more devices without previous user action. Therefore, there is no explicit request from the client until the server sends its information, so push technology essentially involves server-initiated transactions. Push technology can be used in conjunction with various protocols and communication technologies, such as SMS, MMS, WAP, Session Initiation Protocol (SIP), and others. Each of these current (and future) push technologies has its own characteristics, so for each of these different push technologies, the generation and delivery of push messages conventionally needs to be applicable only to that expertise in the technology. Current web applications with the ability to push messages to recipient mobile devices are limited to technology-specific solutions. For example, HTTP-SMS gateways only allow messages to be sent from the Internet to SMS-compliant terminals. As the number of available push technologies continues to increase, these mandatory technical solutions become prohibitively unpopular and present significant barriers to application developers who prefer to focus on application development without determining how to push messages to An ever-increasing entity of push technologies.

The notification (ie push) mediator according to the present invention provides a technical solution to these problems. An exemplary Web service notification broker will be described below with reference to FIGS. 12-13 . Notification Broker acts as a Web Services Push Gateway in the following example, abstracting mobile technology in such a way that web (eg, Internet) application developers can build applications without expertise in the mobile domain. Many of the implementation details described below in connection with the notification broker can be similarly applied to the web service-based embodiments of the various brokers described above.

Figure 12 is an exemplary embodiment of a network system 1200 providing a Web Services Notification Broker 1202 (also referred to herein as a Web Services Push Gateway) in accordance with the principles of the present invention. The basic function of the notification broker 1202 is to convert from one set of protocols to another set of protocols. In the case of the Web Services Notification Broker of the present invention, the protocol translation is from Web Services Protocol 1204 (e.g., UDDI, WSDL, SOAP, etc.) to Mobile Domain Push Protocol 1206 (e.g., SMS, WAP Push, SIP, MMS etc).

Notification Broker 1202 provides a gateway between Web Services Domain 1208 and Mobile Push Technology Domain 1210 . Notification Broker 1202 abstracts mobile technologies in such a way that Internet application developers can still build applications without having expertise in the mobile domain. More specifically, the present invention distills the core push services behind a single Internet paradigm, ie, Web services in this illustrated embodiment. This advantageously removes the need for mobile technology expertise from Internet application developers. Further, this illustrated embodiment of the invention abstracts all mobile push technologies behind a single gateway. This frees Internet developers from having to evaluate the pros and cons of specific push technologies. Notification Broker 1202 takes responsibility for determining the most appropriate push technology for delivering messages to a particular user.

Notification Broker 1202 may be implemented as a network element in network 1200 . The precise location of the network component is not particularly important unless it is logically placed between the Web service application 1212 pushing the message and the endpoint 1214 to which the message will be pushed. While various environments can be employed to accommodate these technologies, exemplary environments include a Java(TM) 2 Enterprise Edition (J2EE) application server, or a .NET application environment.

FIG. 13 is a block diagram illustrating an exemplary embodiment of a Web Services Push Gateway (ie, Notification Broker) architecture 1300 according to one embodiment of the invention. A basic function of a Web service push gateway is to convert from one set of protocols to another set of protocols. For example, considering current web service protocols and mobile push protocols, this conversion may be from web service protocols (eg, UDDI, WSDL, SOAP, etc.) to mobile push protocols (eg, SMS, WAP, SIP, etc.). The Web Services Push Gateway Architecture 1300 shown in Figure 13 illustrates an exemplary architecture for accomplishing this functionality.

The Web service push gateway architecture 1300 includes a Web service endpoint module 1302 . This is the endpoint that terminates the web service protocol. One embodiment of the Web service endpoint 1302 includes at least one server, such as an HTTP server, for eg a transport layer. However, other transport layers may also be included, such as Simple Mail Transfer Protocol (SMTP), or other known or future transport layers. Additionally, Web service endpoint 1302 includes an XML messaging engine for parsing incoming requests and generating appropriate responses. The XML messaging engine can be implemented using, for example, a SOAP engine. The XML messaging engine parses various parameters from the data fields within the request. Web service endpoint 1302 can also interface with a service registry to advertise its notification/push services. This capability can be implemented using, for example, the UDDI protocol and WSDL definition language.

The exemplary Web services push gateway architecture 1300 also includes a push adaptation layer 1304 . Push adaptation layer 1304 provides a mobile technology independent layer for push router 1306 (described below). Push adaptation layer 1304 provides various functions, including two basic functions according to one embodiment of the present invention. The first of these basic functions is to provide capability registration for various mobile push bearers such as SMS bearer 130, WAP bearer 1310, and any other bearer specified by bearer "X" 1312 (described below). This registration allows carriers to advertise their push capabilities in various terms such as bandwidth, content capabilities, availability, latency, guaranteed delivery, quality of service, and the like. A second basic function of the push adaptation layer 1304 is to forward push messages delivered by the push router 1306 to the appropriate bearers 1308 , 1310 , 1312 .

In one embodiment of the invention, the mobile push carriers 1308, 1310, 1312 comprise a set of pluggable components. A "carrier" is the name for a virtual bitpipe that carries a specific end-user service, and generally refers to the technology used to broadcast, or "piggyback," a signal to user equipment. Each bearer has specialized functionality connected to specialized mobile push technologies. There are an indeterminate number of push technologies, especially considering future push technologies. For purposes of illustration, SMS bearer 1308 and WAP bearer 1310 are specifically identified, while bearer X 1312 represents any number and type of current and/or future push technologies.

The SMS bearer 1308 is used to connect to a Short Message Service Center (SMSC) to manage text messages. SMSC A network element by which short messages (eg via Short Messaging Service) can be transmitted and stored for later delivery without reaching the message recipient. For such a connection, various protocols exist, for example including Computer Interface for Channel Messaging (CIMD). Short Message Entities (SMEs), commonly referred to as applications, are interconnected via CIMD connections to a message center. The CIMD protocol is supported by various types of message centers, including SMSC. The main purpose of this interconnection is to transfer messages from the application (ie SME) to the mobile station, and from the mobile station to the application. The CIMD protocol is considered here only as representative of the protocol by which the SMS bearer 1308 can connect to the SMSC, however any suitable protocol could alternatively be implemented.

An exemplary embodiment of the WAP bearer 1310 complies with the WAP push specification. There are various possibilities for such a carrier. A first possibility is that the bearer can connect to an existing WAP Push Proxy Gateway (PPG) using the WAP Push Access Protocol (PAP). Pushing messages to mobile client devices becomes easier with PPG between wired and wireless networks. PAP is a protocol used to transfer content to be pushed to a client and related control information between a push initiator (eg, an application/service) and a PPG. The PPG then delivers this content to narrowband devices such as wireless phones, pagers, PDAs, laptops, and the like.

Another possibility for the WAP bearer 1310 is to communicate directly with the terminal using the WAP Push Over The Air (POTA) protocol. WAPPOTA is a wireless over-the-air protocol for delivering content from a WAP server such as PPG to a WAP terminal. In this case, the Web service push gateway of the present invention also acts as a WAPPPG. Other connection possibilities for the WAP carrier 1310 and the invention are not restricted to the representative examples described above.

Carrier X 1312 represents any other current and/or future pluggable components. Other examples include MMS bearers that can be used for multimedia content. MMS bearers can be based, for example, on the WAPMMS specification. Another example includes a SIP bearer, which is capable of sending push messages using the SIP protocol. Architecture 1300 supports any current or future pluggable components.

A presence proxy 1314 is a proxy that provides information to the push router 1306 . The presence agent 1314 informs the push router 1306 if and when a particular user is online. If the user is online, the presence agent 1314 also provides information about the characteristics of the terminal being used by the user at that time. For example, if a user is using a first type of mobile device, the only push messages that the user can receive may be text messages. On the other hand, users using a second, more advanced type of mobile device may be able to receive additional types of content, such as multimedia messages. Presence agent 1314 provides such information to push router 1306 in order to identify specific terminal characteristics. In one embodiment of the invention, the presence proxy 1314 may be accessed by another network service broker, ie, a presence broker such as described in connection with FIG. 10 .

The presence agent 1314 may also inform the push router 1306 of other details. For example, presence agent 1314 may inform push router 1306 of the capabilities of the underlying network within which the user is currently working. Such network capabilities may be in the form of network characteristics, such as second generation (2G) low bandwidth, third generation (3G) high bandwidth, and so on. The presence agent 1314 can provide many other types of details as well. For example, the presence agent 1314 can provide a status indicator, such as if the user is currently in a meeting and does not want to receive messages with audio content.

User preference agent 1316 is another agent that provides information to push router 1306 . The primary intent of the presence agent 1316 is to inform the push router 1306 of the user's specific preferences when receiving push messages. In this manner, the user can specify one or more user preferences that affect the delivery, presentation, or other characteristics associated with the push message.

In one embodiment of the invention, user preference agent 1316 includes a repository of preferences associated with each user. When a push message is being delivered, this content repository is accessed for the particular user to whom the push message is directed, and the user preferences can be adopted accordingly. Additionally, user preference agent 1316 may include an interface to allow a user to enter and/or edit those preferences. Such an interface could be implemented using a server, such as an HTTP server, that would allow users to edit their preferences via a browser. Other interface implementations can also be used according to the invention.

Any number of different types of user preferences identified by the user may be associated with the user preference agent 1316 . For example, a user may identify a terminal preference that identifies a range of terminals owned by the user. The user can also specify the type of content to be received on each of these various terminals.

Another example of user preferences includes network preferences. This type of preference specification relates to the type of network the user is connected to at a particular moment. For example, a user can specify that high-bandwidth messages are only sent when the user is connected to a 3G network, or that such messages are not allowed to be sent while roaming, and so on.

Yet another example of user preferences is presence preferences. These are preferences related to user activity at a particular time. For example, a user may specify that audio messages are not allowed to be sent during a meeting, while sleeping, or anytime an audio message would be interruptive or undesirable. Presence preferences can also be used to forward messages to another terminal, person, etc. when a particular terminal is offline. Further, unsolicited messages from certain sources can be ignored, messages with large attachments can be deferred, etc. The data and types of user preferences that can be implemented in this manner are virtually endless.

At the core of Web Services Push Gateway 1300 is Push Router 1306, which serves a variety of purposes. In general, push router 1306 receives push messages from web service endpoints 1302, processes information received from one or more push adaptation layers 1304, presence agent 1314, and user preference agent 1316, and forwards push messages based on the collected information to the appropriate carrier and provide a delivery report to the push message originator.

The implementation and benefits of a Notification Broker can be determined in the manner described here, or in co-pending U.S. Patent Serial No. 09/996,406, filed November 20, 2001, entitled "WebServicesPushGateway" determined in the manner described in the application, the contents of which are hereby incorporated by reference. The implementation and benefits of other mediator functionality can further be determined in the manner described herein, and in co-pending application Serial No. 09/854,628, filed May 15, 2001, entitled "ContextSensitiveWebServices" determined in the manner described in U.S. Patent Application, and in the manner described in co-pending U.S. Patent Application Serial No. 09/858,182, filed May 15, 2001, entitled "ASystemAndMethodForLocationBasedWebServices" , both of which are assigned to the assignee of the present application, the contents of which are hereby incorporated by reference.

Diagram 1416 provides a more general example of exemplary interfaces between various network elements in accordance with the principles of the invention. FIG. 14 illustrates an exemplary implementation of a Mediator Domain/Web Service Logic Interface 1400 . This represents the interface between each broker and the service provisioning infrastructure. This is based on a loosely coupled technique, since the Mediator Domain/Web Service Logical Interface is a set of loosely coupled interfaces, and each Mediator has its own settings in an independent manner. As shown in the embodiment illustrated in Figure 14, an XML Schema 1402 is provided at the Mediator domain/Web service interface. A separate interface (ie, the mode used to communicate between the broker and the SPI) is used for each broker. XML Schema is built on top of XML/SOAP/HTTP1404.

According to one embodiment of the present invention, XML Schema 1402 is a schema specification for XML documents, where a schema is a method for specifying constraints on an XML document using an XML-based language. Schemas are used to describe the structure, constrain the content of an XML document, and associate data types with XML element types and attributes. One advantage of using a protocol stacked on top of HTTP according to the present invention is to allow firewall traversal, so that communications via HTTP ports (eg port 80) can enter via a company's firewall. Another advantage is that Web services are independent of the platform on which they are used, which means that the existing base of servers in the Internet need not be neglected, enabling servers working on one operating system to communicate with Web services, There is no need to change the operating system to reap the benefits of interoperability through Web services. Although the embodiments illustrated in FIGS. 14-16 are described in terms of XML Schema, it will be appreciated by those skilled in the art that other alternative current or Future technologies may also be employed in accordance with the present invention.

An exemplary embodiment of a Web service logic/API interface 1500 is illustrated in FIG. 15 . This is the interface between each service application and the SPI. This is based on a loosely coupled technique, similar to the Mediator Domain/Web Service Logical Interface described in connection with Figure 14 . XML schema 1502 is provided at the Web service logic/API interface for interfacing with service applications 1504 . XML Schema 1502 is built on top of XML/SOAP/HTTP 1506 .

An exemplary embodiment of a terminal/broker domain interface 1600 is illustrated in FIG. 16 . This is the interface between the terminal and each mediator. The XML schema 1602 is designed independently of the underlying communication stack 1604 . Thus, the same XML Schema 1602 can be used for Web domain endpoints with capabilities supporting e.g. SOAP/XML/HTTP, and for SyncML/XML (extended RPC functionality) over WSP or HTTP over WAP stack nature) capabilities of the mobile domain terminal.

Service/content providers are generally willing to provide the same, consistent service to all their customers regardless of which network operator the customer is connected to. Therefore, the service/content provider will have to interface with several network operators' intermediaries. This is depicted in Figure 17, where SPI 1700 is coupled via the Internet 1702 to network service brokers associated with multiple operators. More specifically, SPI 1700 is coupled with one or more network service brokers 1704 associated with Carrier-A 1706 and further coupled with one or more network service brokers 1708 associated with Carrier-B 1710 . From a content provider's point of view, this creates a challenge, as operators' Web Service Broker interfaces may differ for a variety of reasons. For example, it's common for vendors to add some extensions to standard implementations, not to mention that standards often leave room for different interpretations. Further, options are typically provided in the standard, and certain vendors may implement certain options while others do not. Operators may also be implementing different versions of the Web Services Broker interface. Other reasons may also prevent true "standardization" of the Web Services Broker interface. If the application on the content provider site has to take into account all these differences, it will slow down the service/application development.

Therefore, the present invention also designs an interface mediator at the content provider site to unify operator-specific differences and relieve the application of this responsibility. Figure 18 illustrates an exemplary implementation of such an interface broker in accordance with the principles of the invention. In this embodiment, the service/content provider 1800 no longer has to understand operator-specific differences in the operator's network service broker interface. Instead, these differences are distilled into the interface broker 1802, which then interfaces with each of the various operators 1804, 1806, and so on. Further, the SPI is freed from the task of choosing where to connect to obtain eg location information, and the illustrated embodiment in Figure 18 simplifies how the SPI obtains services. For example, a large-scale location information company makes a business agreement with a carrier, calculates an appropriate sales profit, and sells the location service to SPI. SPI pays for this profit for the convenience of not having to make separate commercial agreements with all operators. The interface between interface broker 1802 and SPI 1800 can be standardized.

The benefits of a network service broker according to the invention extend to other network issues, such as roaming. The invention allows roaming problems to be hidden. When a user is roaming in a network other than the user's home network, the user may need to access services in the visited network. However, it is likely that the user has no business relationship with the network in which the user has roamed. Instead, the owner (eg, operator) of the home network has a business relationship with the visited network. A similar approach can be extended to services provided by an intermediary in a home network. Figure 19 illustrates an exemplary manner that can be used to manage roaming issues using a network service broker according to the present invention.

When the user is in the home network (eg, Network-B 1900 ), SPI 1902 can access specialized services related to functionality in Network Element (NE) 1904 in Home Network 1900 via Mediator 1906 , as indicated by arrow 1908 . When an end-user roams to Network-A1910, the question becomes: If a particular service in Network-A1910 can only be provided when a Network-A1910 resource (e.g., NE1912) is accessed, how can SPI1902 be accessed from this dedicated service? Services gain benefits.

In order to solve this specific roaming problem, there are at least two feasible technical solutions. The operator of the user's home network 1900 has a business relationship, such as a roaming agreement, with the operator of the visited network-A 1910 for broker service roaming. In this case, the SPI 1902 is typically connected to an intermediary 1906 in the home network 1900 . In a first embodiment, the Broker 1906 provides the SPI 1902 with the credentials the address of the corresponding Broker 1914 in Network-A 1910 . The credentials enable the SPI 1902 to use a broker roaming agreement between the operators of the Home Network-B 1900 and the Visited Network-A 1910 . According to this implementation, Mediator 1906 in Home Network-B 1900 sends credentials directly to Mediator 1914 in Network-A 1910 and hands the address of Mediator 1914 to SPI 1902 in order to allow SPI 1902 to communicate directly with Mediator 1914, as shown by the arrow Shown in 1916. In another embodiment, Broker 1906 communicates with Broker 1914 of Visited Network-A and acts as a proxy in accessing services of that network, as indicated by arrow 1918 .

When the end user roams from the home network-B1900 to the network-C1920, there is no business relationship between the operators of the network-B1900 and the network-C1920. Therefore, the SPI 1902 looks up the address of the Mediator 1922 in the Network-C 1920 from the Mediator 1906 in the Home Network-B 1900 (or from the Terminal 1924 itself). When the SPI 1902 has received the address of the broker 1922 associated with the visited network 1920, the SPI 1902 will communicate directly with the broker 1922 in the visited network-C 1920. For this to work, there may be a requirement that SPI 1902 has established a business relationship with the operator of Network-C 1920 whereby the operator of Network-C 1920 allows SPI 1902 to contact Specialized Intermediary 1922 as indicated by arrow 1926 .

Using the above specification, the present invention may be implemented as a machine, process, or article of manufacture resulting from the production of programmed software, firmware, hardware, or any combination thereof, using standard programming and/or engineering techniques.

Any resulting program having computer readable program code can be embodied within one or more computer usable media, such as storage devices or transmission devices, thereby producing a computer program product or article of manufacture according to the present invention. Thus, the terms "article of manufacture" and "computer program product" as used herein are intended to encompass any computer-usable medium that exists (permanently, temporarily, or transiently) on any storage device or in any transmission Computer program.

Executing program code directly from one medium, storing program code on a medium, copying the code from one medium to another, transmitting the code using a transmission device, or other equivalent acts, which may involve the use of memory or a transmission device, the memory Or the transmission device temporarily embodies the program code only as an initial or first step in making, using or selling the present invention.

Storage devices include, but are not limited to, hard drives, magnetic disks, optical disks, magnetic tape, semiconductor memories such as RAM, ROM, PROMS, and the like. Transmission equipment includes, but is not limited to, the Internet, intranets, telephone/modem-based network communications, hardwired/cable communications networks, cellular communications, radio wave communications, satellite communications, and other static or mobile network systems/ communication link.

A machine for implementing the present invention may involve one or more processing systems including, but not limited to: CPU, storage/storage device, communication link, communication/transmission device, server, I/O device, or one or more Subcomponents or separate parts of a processing system, including software, firmware, hardware, or any combination or subcombination thereof, embody the invention as set forth in the claims.

From the description provided herein, one skilled in the art can readily use appropriate general purpose or special purpose computer hardware to combine software created as described to create computer systems and/or computer subcomponents embodying the present invention , and create computer systems and/or computer subcomponents for implementing the methods of the present invention.

Of course, it will be appreciated that various modifications and additions can be made to the various embodiments discussed above without departing from the scope or spirit of the invention. For example, the present invention can be used in connection with any type of networking environment, from local area networks to rapidly expanding global area networks such as the Internet, and including collaborative wired and mobile networks. From the above description of the illustrated embodiments, those of ordinary skill in the art will readily appreciate the applicability of the present invention in any comparable network environment.

Accordingly, the scope of the present invention should not be limited by the specific embodiments discussed above, but should be defined only by the claims set forth below and their equivalents.

Claims (17)

1. one kind helps functional network that access can obtain on one or more networks to beSystem, comprising:

One or more terminals that can operate in the network system of the first kind;

Comprise the network infrastructure of one or more network systems;

For the service provision architecture being used by one or more described terminals, wherein networkBe applied in work in described service provision architecture, and be configured to and the network of Second TypeSystem docking; And

At least one network services broker, comprises and being appeared to described service provision architectureLoose couplings interface, for by value-added network service from one or more described terminals and described inThe network system intermediary of the network system of the first kind and described Second Type supplies to described serviceAnswer architecture.

2. network system according to claim 1, wherein said loose couplings interface is pineThe standard interface of loose coupling.

3. network system according to claim 2, wherein said loosely-coupled standardizationInterface defines with expandable mark language XML.

4. network system according to claim 1, wherein said loose couplings interface comprisesWeb service interface.

5. network system according to claim 1, wherein said loose couplings interface comprisesAppeared the single loosely-coupled Web service interface to described service provision architecture.

6. network system according to claim 1, wherein said network services broker bagDraw together the intermediary device of at least one network coupling, for one of described network infrastructure orMultiple network components communication.

7. network system according to claim 1, wherein said network services broker bagDraw together the intermediary device of at least one terminal coupling, for one or more terminal communications.

8. network system according to claim 1, wherein said network services broker bagDraw together at least one hybrid network service broker, for of described network infrastructureOr multiple network componentses and communicating with one or more terminals.

9. network system according to claim 1, wherein said network services broker isBe used for the checking intermediary device of the service for checking credentials of accessing the application allowing for described network.

10. network system according to claim 1, wherein said network services brokerIt is the charge of the use access charge/billing of services of the application for allowing in conjunction with described networkJie's device.

11. network systems according to claim 1, wherein said network services brokerBeing for access terminal location-based service permits to allow that the position of terminal is offered to described networkThe position intermediary device of the application of being permitted.

12. network systems according to claim 1, wherein said network services brokerFor subscription information being stored into profile register and for examining the final of described terminalThe content subscription intermediary device of user's reservation intention.

13. network systems according to claim 1, wherein said network services brokerFor accessing the service attended to user's presence information is offered to answering of described network permissionWith attend intermediary device.

14. network systems according to claim 1, wherein said network services brokerFor supplying intermediary device to the client of mobile terminal supply intermediary.

15. network systems according to claim 1, wherein said network services brokerIt is the notice intermediary device for helping content to be pushed to terminal.

16. network systems according to claim 1, wherein said network services brokerFor accessing end user's privacy information and for will be to described service to other intermediary devicesThe privacy intermediary device which information is supply architecture provide control.

17. network systems according to claim 16, wherein said privacy intermediary device based onOther intermediary devices of parameter control that defined by the end user of described terminal will supply to described serviceAnswer architecture which information is provided, wherein said parameter can required finally by end userWhen user privacy information, artificially provides, or is pre-defined by end user in parameterSituation under automatically provide.

Images