US20070005766A1 - Method and system for providing external and internal services through an application intermediation gateway - Google Patents

Abstract

A system, method and computer program product for implementing application level policies in an operator network, while managing the exchange of data packets between users and service providers during the provisioning of premium data services. The system and method intermediates between a user and a service provider (who may be an enterprise, content provider, an application provider or a partner portal). The system and method enforces access control, prompting, redirection and inline context injection dynamically while the service is being delivered, and generates metering records for billing purposes. The system and method allows the service providers to provide various external services. Such external services include transcoding service, age verification service, streaming service, recommendation service, advertisement service, fulfillment aware charging, dynamic pricing, real time events, and messaging services.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This application is a continuation-in-part of U.S. patent application Ser. No. 10/389,783 filed Mar. 17, 2003
BACKGROUND
• The present invention relates to telecommunication networks. In particular, the invention relates to an infrastructure element that intermediates between users and service providers.
• Most of the traditional wireless networks, which support the provision of various services (also called applications) to users, include three basic entities: a service provider, a network operator, and one or more users. The service provider provides several services to the user using the network operator's infrastructure. The service provider can be a content provider, an application provider, or a partner portal (who has a business relationship with the network operator). The network operator provides and maintains the basic network infrastructure over which the service provider provides various data and voice services. The user avails the services, which may either be free services, or paid/subscribed services, provided by the service provider.
• Provision of services is an important means of revenue generation for operators as well as for service providers. Indeed, for increasing this revenue generation, services that manifest both value and convenience to consumers need to be provided using the network operator's infrastructure. Examples of some of the conventional services being provided include caller-line identification, call waiting, and call forwarding.
• There have been several advancements in content creation of content-rich services and applications, as well as in technologies of devices on which they can be used. For instance, in the wireless domain, there have been advancements in technology of mobile handsets. These devices are now enabled for handling “content-rich” services such as multi-media messaging (MMS). These advancements enable provision of “content-rich” services such as video streaming, downloadable music and online gaming. Provision of all these “content-rich” services lead to increased revenue generation, which is very much desirable for operators and for service providers.
• Besides provision of “content-rich” services, there is also a huge opportunity of direct revenue generation for the operator while providing content and services. The operator has the billing relation with subscriber, subscriber profiles, subscriber context and knowledge of device capabilities. The operator can use this information in several advantageous ways. First, the operator can share this information with the service providers to offer better services. Second, this information can also be used for managing payment and transactions for billing purposes.
• However, there are problems with the implementation of such services. To provide such services, the operator should be able to implement policies (primarily for enforcing service control) not only at the network level, but also at the application level. The service control needs to be enforced at various levels. Firstly, the operator needs to be able to exercise service awareness encompassing individual application and users. This means that the operator must be aware of what services or applications a particular user is availing. Second, the operator needs to be able to deploy services without requiring significant changes in the network infrastructure. Third, the services need to be interoperable with leading service providers. Application interfaces need to be open so as to enable integration with third party applications for billing, provisioning of services, etc. In addition, the operator needs to be able to provide conditional access to users for example, for payment sites.
• There are granted patents and products in the market which address a few of the issues discussed above. U.S. Pat. No. 6,466,984 titled “Method And Apparatus For Policy Based Management Of Quality Of Service Treatments Of Network Data Traffic Flows By Integrating Policies With Application Program” discloses a method and apparatus for integrating policies with application program to provide policy-based management of quality of service (QoS) treatments of network data traffic flows. The QoS policies are defined in context of the application programs. The network traffic is mapped to the corresponding policy. The relevant policy is then enforced on the network traffic at the network device. The policies are stored in a directory schema. This patent only relates to implementation of QoS based on application programs.
• The “Application Switch” from Sylantro Systems, CA, USA is designed to support the infrastructure requirements of service providers by providing new service capabilities. The software architecture incorporates the data structures that support multi-tenant deployments. This platform acts as both the delivery mechanism and the development engine for a wide range of existing and new applications. The combination of the applications-enabled architecture and the complete suite of application modules allow a plurality of service providers to deliver a variety of telephony services over broadband networks.
• The iVANi iServer Application Switch from NexTone Communications, MD, USA provides policy-based call routing and signaling mediation to deploy applications in an on-net IP environment. It also interoperates with softswitch and media gateway platforms for off-net calls to and from the public network. It also provides support for enhanced services and applications such as presence management, voice-data VPNs, unified messaging and multimedia conferencing. New services and applications can be added with the addition of a new application server to the network.
• Alteon Application Switch 2224 from Nortel Networks, Canada is a multi-application switching system that performs Layer 2/3 switching and high-performance Layer 4-7 intelligent traffic management for applications such as server and network device load balancing, application redirection, security, and bandwidth management. The Alteon Application Switch 2224 can be used in server farms, data centers, and networks, handling up to two million concurrent sessions.
• The prior art discussed above tries to implement policies at the application level. However, they are limited in their approach. The patent discusses policy implementation for QoS issues and not for other services that may be provided by an operator. The products also restrict themselves to being either a Voice over Internet Protocol (VoIP) switch or a telephony service switch. In addition, the prior art requires the service providers to interface with multiple internal and external services. This is required as the service providers lack information regarding the user and the device.
• Thus, there is a need for an invention that enables a service provider to deploy premium data services. Further, it should enable the service provider to implement policies at the application level for intermediation between the user and content provider, enterprise or a third-party application provider. Capability of billing and licensing for these enhanced services should also be provided to the operator. Furthermore, it should enable the service providers to function completely on their own, while seeking information from other services as needed.
SUMMARY
• The present invention is directed towards an infrastructure element that intermediates between the network operator's core packet data delivery network elements and the applications.
• An object of the invention is to provide a system, method and computer program product for an operator to implement application level policies on data packets in a network for intermediation between users and service providers.
• Another object of the invention is to prompt the user and redirect the user to a different destination address. The present invention also provides access control.
• Yet another object of the invention is to provide a system and method for provisioning data services over a network.
• Still another object of the invention is to provide a system and method that allows the service providers to provide various external and internal services simultaneously to the users.
• In order to attain the above-mentioned objectives, a system kernel receives data packets and inspects them. The system kernel determines the type of application by inspecting data packets. The data packets are forwarded to an application handler specific to the application identified by the system kernel. The context is injected in the header of data packets. A data parser parses the data and the application handler implements the application level policies on data packets. Data packets are then forwarded to the service provider. The service provider responds with necessary data to the application handler. The application handler forwards the response to the user.
• In order to attain the above-mentioned objective, the system providers include the context details of the users and use the context details for providing various external and internal services.
BRIEF DESCRIPTION OF THE DRAWINGS
• The preferred embodiments of the invention will hereinafter be described in conjunction with the appended drawings provided to illustrate and not to limit the invention, wherein like designations denote like elements, and in which:
• FIG. 1 is a block diagram representing the general environment in which an embodiment of the present invention functions;
• FIG. 2 is a block diagram of application intermediation gateway along with a policy decision point and a context server, in accordance with an embodiment of the present invention;
• FIG. 3 is a flowchart illustrating the functioning of the present invention, in accordance with an embodiment of the present invention;
• FIG. 4 is a block diagram including an application intermediation gateway along with various other components, in accordance with an embodiment of the present invention;
• FIG. 5 is a flow diagram representing the relation between various internal services and external services in a mobile network, in accordance with an embodiment of the present invention;
• FIGS. 6A, 6B, and6C are a flow chart illustrating the implementation of an exemplary external service, in accordance with an embodiment of the present invention; and
• FIG. 7 is a flow diagram representing the relation between a user and exemplary external services in a mobile network, in accordance with an embodiment of the present invention.
DESCRIPTION OF PREFERRED EMBODIMENTS
• The present invention is a system, method and computer program product for implementing policies at application level on data packets in a network for intermediation between users and service providers. The service provider may be a content provider, an application provider or a partner portal (who has a business relationship with the operator).
• The network operator provides infrastructure for connecting users to content providers, service or application providers and partner portals. The network operator is the connecting link between the users and the service providers and enables the delivery of services to the user. The present invention allows application level policies to be implemented on data packets at the network operator level. The application level policies are set of rules that determine the actions to be carried out for a particular type of application. The present invention enforces access control, prompting, redirection and inline context injection. The present invention may also generate metering records for billing purposes while the service is being delivered.
• The access control mechanism controls the access rights. It defines what source-destinations and the port numbers are to be allowed access. Some users are allowed to access some addresses but may be restricted from accessing other addresses. The present invention enables rejection of data packets from the sources that are blocked. Also, it enables the data packets to be directly passed to the opposite Ethernet interface, which connects to the service provider, without any modification.
• Prompting facilitates notification to users about certain terms and conditions, such as paying some associated charges, for accessing content and applications. Prompting also enables taking an input from the user. For instance, when a user downloads an MP3 song from a content provider, the user is prompted with some terms and conditions, such as paying the associated charge. The download is permitted only after the user agrees to pay the associated charges. A charging record is then generated for billing the user.
• Further, a user can be prompted while implementing various external services. For example, in case of a dynamic pricing service, Application Intermediation Gateway (AIG) prompts the recommended price to the user. The recommended price is calculated based on the context details of the user consisting of user's profile, device, network, and the corresponding service being delivered. Subsequently, the user has the discretion to either accept or reject to the recommended price.
• Redirection enables transferring a request from the user to another (appropriate) destination. This is done by routing the data packets from one destination to another (appropriate) destination. The redirection may be for a variety of reasons. The redirection may be for the purpose of payment of service charges to access an application, denial of service, signing up a license agreement before the application can be accessed, download of software required for the application and redirection of call.
• Further, the redirection can be made to implement various external services. For example, in case of a service discovery service, the request of the user can be redirected to an age verification service that determines the age of the user and the access to the discovery service is granted or disallowed based on the authorization as per the associated policies.
• Context comprises information about device characteristics, network capabilities and user profile. Examples of device characteristics information include information about Hypertext Transfer Protocol (HTTP) version supported, image types supported, languages supported, destination host URL, browser make and version, and operating system make and version. Examples of network capabilities information include network type and network identifier. Examples of user profile information include personal data, the class of subscriber, the services subscribed to and the billing information. The context enables the content or application provider to realize the abilities of the user and provide better services. For instance, based on the device type used by the user, the content provider can adapt the content to the device screen.
• When the user is accessing the content or the application, the present invention passes the context to the application inline. The context that is required to be passed may be decided by the service provider providing the content or the application. This may be done by selecting policies that the service provider wants to enforce. A policy is set of rules that govern the flow of data packets when a user requests for a service from a service provider.
• FIG. 1 is a block diagram representing the general environment in which the present invention works. An Application Intermediation Gateway (AIG)102 connects a plurality ofcore network elements104 to a plurality ofcontent providers106, thirdparty application providers108 andpartner portals110. The Core network elements are the basic infrastructure elements of the network provided by a network operator. Exemplarycore network elements104 are Gateway GPRS Support Node (GGSN) and Packet Data Serving Node (PDSN). The data packets may originate from a user or a service provider.AIG102 is deployed in the path between user and the service provider and transfers the data packets from one to another.
• Core network elements104 receive a user request from the user and pass it on toAIG102. The user request is in form of data packets.AIG102 implements the application level policies on the data packets. The decisions on application level policies are provided toAIG102 by a Policy Decision Point (PDP)112.PDP112 may act as a policy controller for bothcore network elements104 andAIG102.AIG102 also interacts withcontent providers106, thirdparty application providers108 andpartner portal110.AIG102 forwards the user request to the desiredcontent provider106, thirdparty application provider108 orpartner portal110, receives response to the request and forwards the response back to user.
• In accordance with a preferred embodiment of the present invention,AIG102 is deployed in an operator's network. However, it would be evident to a person skilled in the art thatAIG102 can be deployed in an enterprise local network as well.
• FIG. 2 is a block diagram of application intermediation gateway along with a policy decision point and a context server.AIG102 receives a user request from a user through asystem kernel202. The user request is in form of data packets.System kernel202 includes a kernel hook. The kernel hook is a stream driver that inspects the data packets to determine the source and type of data. Each data packet comprises a header portion and a body. The header portion has an IP header and a TCP header. The kernel hook unwraps the IP header of the data packets to determine the source and destination IP addresses and TCP header to determine the application type. The application type is determined by port number that is read from TCP header. The kernel hook also implements kernel rules. The kernel rules are rules that govern data packets at the network level. The kernel rules are controlled by the network operator through an administration interface.
• Depending on the application type determined from TCP header,system kernel202 redirects the data packets to the corresponding application handler ofapplication handlers204 through an I/O control interface206 or to the opposite Ethernet interface. Exemplary application handlers are HTTP application handler, Post Office Protocol (POP) application handler and streaming application handler. The application handler to which the data packets are redirected is decided by the kernel rules. For instance, if the application is a Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) request, the data is passed directly to the opposite Ethernet interface, but if it is HTTP request, it is passed to HTTP application handler. The kernel rules also determine which source and destination IP addresses are allowed to be accessed. The system kernel provides access only to those addresses.
• Application handlers204 receive the data fromsystem kernel202 through an I/O control interface206.Application handlers204 comprise a set of application handlers for handling different types of applications. I/O control interface206 also communicates the data fromapplication handlers208 tosystem kernel202.
• In accordance with one embodiment, the present invention is envisaged to be working on an HTTP request. However, it will be evident to a person skilled in the art that the present invention can work on any other application type as well.
• For an HTTP request, the data packets are passed to anHTTP application handler208.HTTP application handler208 performs application level access control to the user's requests.HTTP application handler208 provides functionalities for inline prompts and allows users to make decisions while accessing the applications.HTTP application handler208 also allows redirection of users. The redirection of users helps integrating the users with content download sites and payment gateways.
• Access control is performed byHTTP application handler208 based on the context information. The access is controlled by policy defined by the network operator.
• The user can be redirected to a URL different from the requested destination IP address. By way of an example, a user can be redirected to a relevant section of the website based on user's context or preferences. By way of another example, a user request to download software can be allowed only after the user makes a payment. For such a payment, the user can be transferred to a payment gateway.
• Prompts are dialogue boxes providing one or more options. The options can be presented in form of buttons or clickable logos. Exemplary buttons can be ‘OK’ and ‘CANCEL’. Prompts enable the user to make choices while they are accessing the application. The user is provided with prompts before the access is granted or a redirection is done. The prompt message and the destination URL are generated based on policy decisions in a markup language supported by client device. Exemplary markup languages can be Hyper Text Markup Language (HTML), Wireless Markup Language (WML) and Compact HTML (cHTML). The prompts are template based. An appropriate template is chosen for the prompt depending on the markup capability of the device. The prompt is then forwarded to the user.
• The data is parsed by adata parser210.Data parser210 is a generic parser that parses all text based protocol data. Exemplary protocols can be HTTP, SIP and POP.Data parser210 examines the header portion of the data packet and enablesHTTP application handler208 to decide the actions to be taken on the data packet. The parsing of data can be done by any known method in the art and would be evident to a person skilled in the art.
• To providecontent providers106, thirdparty application providers108 andpartner portals110 with more information about the user and network capabilities to enable provision of better services, inline context injection is done in the HTTP header byHTTP application handler208. This eliminates the need forcontent providers106, thirdparty service provider108 andpartner portals110 to initiate a separate query to get relevant context information. Exemplary context information in such a case can be location of a user, device capability, the network characteristics, presence and availability and current credit status of the user.
• In a preferred embodiment of the system, the context goes as a header field in the user request. By way of an example, HTTP header along with a context for a handheld device toAIG102 is:
• GET http://www.julysystems.com HTTP/1.1
• Accept: */*
• UA-OS: Windows CE (POCKET PC)—Version 3.0
• UA-color: color16
• UA-pixels: 240×320
• UA-CPU: ARM PXA250
• UA-Voice: FALSE
• UA-Language: JavaScript
• Accept-Encoding: gzip, deflate
• User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240×320)
• Host: 192.168.100.58
• Connection: Keep-Alive
• Location: Bangalore
• In the above example, “Location: Bangalore” is the context that is injected in the header of the data packet.
• In an alternate embodiment of the present invention, the context can also be sent as World Wide Web Consortium (W3C) Composite Capabilities/Preference Profiles (CC/PP) exchange protocol. By way of an example, a CC/PP device profile is:

  <?xml version=“1.0”?>
  <RDF xmlns=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”
  xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#”
  xmlns:prf=“http://www.wapforum.org/profiles/UAPROF/ccppschema-
  20010430#”>
  <rdf:Description ID=“MyDeviceProfile”>
  <prf:component>
  <rdf:Description ID=“HardwarePlatform”>
  <rdf:type resource=“http://www.wapforum.org/profiles/
  UAPROF/ccppschema-
  20010430#HardwarePlatform”/>
  <prf:ScreenSize>121×87</prf:ScreenSize>
  <prf:Model>PocketPC </prf:Model>
  <prf:InputCharSet>
  <rdf:Bag>
  <prf:ColorCapable>Yes</prf:ColorCapable>
  <prf:TextInputCapable>Yes</prf:TextInputCapable>
  <prf:ImageCapable>Yes</prf:ImageCapable>
  <prf:SoundOutputCapable>Yes</prf:SoundOutputCapable>
  </rdf:Description>
  </prf:component>
  <prf:component>
  <rdf:Description ID=“SoftwarePlatform”>
  <rdf:type resource=“http://www.wapforum.org/profiles/UAPROF/
  ccppschema-
  20010430#SoftwarePlatform”/>
  <prf:AcceptDownloadableSoftware>Yes</
  prf:AcceptDownloadableSoftware>
  <prf:MemoryFree>155870</prf:MemoryFree>
  </rdf:Description>
  </prf:component>

• Acontext engine212 collects the context details for the user.Context engine212 interacts with acontext server214 to update or query the relevant context.Context engine212 extracts the context from HTTP header of data packets. The context that is queried fromcontext server214 comprises details about the network and user profile. Exemplary context that is collected fromcontext server214 is network type, network identifier, location information and user identification.Context engine212 also provides the context toHTTP application handler208 for inline context injection and updates context oncontext server214. Context that is collected from the HTTP header contain the device profile and capabilities. Exemplary context that is collected from the device profile is the HTTP version supported, image capabilities, language supported, destination host URL, browser make and version and operating system make and version.Context engine212 comprises alocal context store216.Local context store216 caches the context details locally onAIG102 so that the context need not be obtained fromcontext server214 each time.
• The context is used for enforcement of policy decisions on the data packets. The policy decisions are enforced by anenforcement engine218. The policy decisions are enforced on both the application request and the application response. Exemplary policy decisions on an application request can be to allow a particular access, deny the access, redirect to another web site, provide a payment prompt, an alert and passing context information to the content provider, third party application provider or partner portal. Exemplary policy decisions on application response can be compressing the data and removing all image content from the data packets.
• The policy decisions are provided for enforcement by apolicy component220.Policy component220 interacts withPDP112. The decisions for all the policies to be implemented are taken atPDP112. Policy component interacts withPDP112 using Common Open Policy Service Protocol (COPS) and Policy Communication Protocol (PCOMP) for policy decisions. COPS and PCOMP are protocols for policy exchange.
• The policy decision can be made in two ways. WhenAIG102 needs a policy decision, it requestsPDP112 for the decision on the policy.PDP112 may provide the policy decision topolicy component220 ofAIG102 for implementation whenAIG102 requests. Also, some policy decisions ofAIG102 may be provisioned beforehand byPDP112. The provisioned policy decisions are stored in a localpolicy decision store222 and are used for implementation when required. Each policy decision is locally cached in localpolicy decision store222 to avoid requesting for policy decision every time fromPDP112.
• Also as the service is being delivered to the user, a metering record is generated by ametering record generator224. Metering record contains information about the user request, policies applied and the response to the user request. The metering record is sent to an accounting server for billing purpose. Also, the metering record can be used in future for analysis. Exemplary details that a metering record contains are user information such as MSISDN and IP Address, URL requested, time of connection, response size, context provided such as location, age and gender, device id such as IMEI and Mac Address and policy result such as prompt and redirection.
• FIG. 3 is a flowchart illustrating the functioning of a preferred embodiment of the present invention.
• Atstep302, thesystem kernel202 receives a user request. The request is in form of data packets. Atstep304, the kernel hook unwraps the headers of the data packets and checks the source and destination IP addresses and the type of application request as described earlier. Atstep306, the kernel hook implements the kernel rules on the data packets. An exemplary kernel rule can be to deny access of a particular source IP address. Atstep308, the user request is transferred to an application handler that handles the type of application detected from the header of data packets.
• Atstep310, the context relating to the data packets is checked bycontext engine212. The context is used for taking policy decisions on the user request. Atstep312, it is determined which policy decisions are to be applied on the data packets. The policy decisions are taken byPDP112. Also,PDP112 may provisionAIG102 for the policy decisions. Incase PDP112provisions AIG102 for policy decisions, the decision is provided by localpolicy decision store222.
• Atstep314, the policy decisions are implemented on the user request byenforcement engine218. Depending on the policy decisions the user may be sent a payment prompt and the user response is waited or the user may be redirected to another address.
• Atstep316, the user request is forwarded tocontent provider106, thirdparty application provider108 orpartner portal110. Atstep318, the response fromcontent provider106, thirdparty application provider108 orpartner portal110 is received. Atstep320, the policy decisions on the received response are applied. These decisions are also based on context. Exemplary policy decisions can be compressing the data to be sent and removing the images from the data. Atstep322, the response is forwarded back to the user.
• FIG. 4 is a block diagram including anapplication intermediation gateway102 andexternal services402.Application intermediation gateway102 includescontext engine212 andenforcement engine218.Application intermediation gateway102 intermediates between the users and service providers with certain policies. For example, the policies can be access control redirection, prompting, context sharing, and interfacing with other external services.
• AIG102 includes the context details of the users and information regarding the corresponding network device, and various applications running on the device and utilizes them to intermediate between one or moreexternal services402 and the service providers.
• AIG102 interfaces with one or moreexternal services402 and facilitates simultaneous external and internal services to the users in the mobile network. Further,AIG102 provides one or moreexternal services402 to participate in the overall service delivery of the network in a contextual manner. As a result, one or moreexternal services402 are provided based on the context details of the user, the corresponding device, network and the requirements of the overall service delivery. The context details are collected bycontext engine212. Subsequently,enforcement engine218 enforces one or moreexternal services402 based on the context details of the user and the requirements of the overall service delivery. The functioning ofcontext engine212 andenforcement engine218 has been discussed inFIG. 2.
• AIG102 allows one or moreexternal services402 to participate in the overall service delivery. For example, consider a service discovery service that needs to verify the age of a user before it displays adult services.AIG102 may interpose a flow where the user's age is determined by interfacing with an age verification service. Once the user's age is determined, access to the discovery service is allowed based on the authorization as per the associated policies. In the above-mentioned example, the age verification service is an external service and the age of the user is the requirement for its access. The requirements for this service can be obtained from one or moreexternal services402.
• In accordance with an embodiment of the present invention,AIG102 interfaces with different services present in the network. Such services can reside anywhere in the mobile network. This means that the services can reside either in the network operator, the enterprise, or the service provider. For example,AIG102 provides transcoding service along with video content to the user. In such a case,PDP112 responds with policy decision of transcoding toAIG102 with the optimal transcoding parameters. The transcoding parameters are derived on the user's context primarily based on, the device, the network, the service, or their combination. The device details enable the selection of appropriate format supported by the device. For example, the supported format can be MP4, or 3GPP. Similarly, the network details are used to determine the size of the video clip depending on the downloading capacity of the network. For example, a network with 100 KB download capacity would differ from another network with a download capacity of 1 MB. The services details are used to determine if a special treatment is required on the content. For example, a premium service may result in a higher resolution video compared to a non-premium service. In light of this example, it is quite clear thatAIG102 provides various value added services to the users. Further, it is to be noted that the service providers do not have to interact individually with one or moreexternal services402.
• In accordance with an embodiment of the present invention,AIG102 intermediates on behalf of service providers for sourcing and delivering key information, which is required for delivering one or moreexternal services402. Further,AIG102 provides one or moreexternal services402 other than internal services to the users. Various examples for one or moreexternal services402 can be transcoding service, age verification service, streaming service, recommendation service, advertisement service, fulfillment aware charging, dynamic pricing, real time events, and messaging services. Of course this invention is also applicable to other types of external services. The messaging services include services like SMS, MMS, and WAP push. The internal and external services have been explained in detail in conjunction withFIG. 5.
• In accordance with an embodiment of the present invention, when the user's request arrives atAIG102, the requests have information that identifies which service to be invoked. This service is essentially a high level service that consists of coordinating the execution of one or moreexternal services402 and one or more internal services.
• FIG. 5 is a diagram representing the relation betweeninternal services504 and one or moreexternal services402 innetwork500, in accordance with an embodiment of the present invention.Network500 includes network operator's assets502. Network operator's assets502 include but are not limited to Public Data Network (PDN), Authentication Authorization and Accounting (AAA), and a charging gateway. AAA is used to authenticate the users and then subsequently charge them through the charging gateway. PDN refers to core network elements like SGSN, GGSN, and WAP gateways.
• As mentioned earlier, requirements for one or moreexternal services402 andinternal services504 are provided byAIG102. The context details are collected bycontext engine212. Subsequently,enforcement engine218 enforces one or moreexternal services402 based on the context details of the user and the requirements of the overall service delivery.Internal services504 include a metering server508, a chargingenabler510,AIG102,context server214, andpolicy component220.Internal services504 generate and capture the metering records at metering server508 for reporting and reconciliation purposes. As mentioned inFIG. 4, one or moreexternal services402 includes the requirements for making one or moreexternal services402 participate in the overall service delivery in a contextual manner. For example, one or moreexternal services402 includes, by way of example, requirements of the users for transcoding service, age verification service, streaming service, recommendation service, advertisement service, fulfillment aware charging, dynamic pricing, real time events, and messaging services.AIG102 andpolicy component220 interact with one or moreexternal services402 for making one or moreexternal services402 participate in the overall service delivery in a contextual manner.External services402 are provided on the basis of the context details and the requirements of the overall end to end service.Policy component220 provides various policies that need to be enforced. The enforcement of the policies and one or moreexternal services402 is performed byenforcement engine218.
• AIG102 enhances the capabilities of the charging gateway and the corresponding policies inPDP112. As a result,AIG102 coordinates the flow of theinternal services504. For example,AIG102 enables chargingenabler510 to interface with the network operator's charging gateways directly.
• In accordance with another embodiment of the present invention,AIG102 enables chargingenabler510 to interface with the network operator's charging gateways through billing aggregators.
• In accordance with an embodiment of the present invention, chargingenabler510 provides a simple and a common interface betweenAIG102 andPDP112. Chargingenabler510 abstracts the complexities of the prevailing external service mechanism of charging into a charging model so that they can be rapidly used in the service delivery. The charging mechanism available in the mobile network can interface with a diverse charging environment that includes network operator's charging gateways and billing aggregators. For example, the charging mechanism can be Premium Short Message Service Mobile terminated (PSMS MT) based charging from a SMS billing provider, PSMS MT based charging with mandatory Mobile originated (MO) from SMS billing provider, network operator's backend secure web services based charging (direct operator backend integration), operator and third party WAP billing interfaces (redirection based), and web services based interfaces for alternate billing options such as eWallet and credit card.
• In accordance with an embodiment of the present invention,AIG102 provides policy based coordination of one or more services. For example, age verification service, charging, fulfillment awareness and recommendation can be executed as a part of one service.AIG102 provides some of the services to be executed simultaneously. For example, the transcoding and recommendation service can be executed simultaneously in parallel. The policy based orchestration of one or more services has been explained in detail in conjunction withFIGS. 6A, 6B, and6C.
• FIGS. 6A, 6B, and6C are a flow chart illustrating the implementation of an exemplary external service, in accordance with an embodiment of the present invention. The exemplary external service includes a combination of dynamic pricing, transcoding, fulfillment aware charging, and recommendation service. A user requests a service through his device. Atstep602,AIG102 receives the user's request and identifies the service to be invoked. Atstep604,AIG102 retrieves the user's context details fromcontext server214. Atstep606,AIG102 sends a policy request toPDP112. Atstep608,PDP112 receives the recommended price for the requested service from a dynamic pricing external service. The recommended price is calculated based on the context details.PDP112 returns toAIG102 with a decision to forward the context details including the recommended price inline toservice provider506.
• Subsequently atstep610,AIG102 forwards the context details toservice provider506. Atstep612,service provider506 communicates the recommended price to the user. The user then gives a purchase request. Atstep614,AIG102 receives the purchase request from the user. Further,AIG102 retrieves the user's context details fromcontext server214. Atstep616, AIG sends the policy request toPDP112. Atstep618,PDP112 reserves the charge in the charging gateway through chargingenabler510. Subsequently,PDP112 responds toAIG102 with a policy decision of prompting the user toAIG102.
• Atstep620,AIG102 prompts the user with the recommended price. Atstep622, if the user does not accept the prompt, then the process stops. However, if the user accepts the prompt, then the control is transferred to step624. Atstep624,AIG102 again sends the policy request toPDP112. Atstep626,PDP112 responds with policy decision of transcoding toAIG102 with the optimal transcoding parameters. The response is made on the basis of the context details of the user consisting of the corresponding device, network and the service being delivered.
• Subsequently, atstep628,AIG102 retrieves the context fromcontext server212.Context server212 can be hosted either with the network operator or withservice provider506. Atstep630,AIG102 sends a transcoding request to the transcoding service along with the transcoding parameters. Atstep632,AIG102, receives the transcoded context back from transcoding service and fulfills it to the user.
• Atstep634,AIG102 sends the policy request toPDP112 when the fulfillment is complete. Atstep636,PDP112 commits the charge in the charging gateway through chargingenabler510 and responds toAIG102 with a policy decision of metering and recommendation. Atstep638, a metering record is generated and is sent to metering server508 for its display. Atstep640,AIG102 sends a request for recommendation to the recommended service and passes the required parameters from the user's context details. Atstep642, recommendation service returns with the recommendations for the user. Atstep644,AIG102 returns with recommended products list to the user.
• In accordance with an embodiment of the present invention, during the above exemplary service delivery, various other events could have taken place depending on the overall service requirements. For example, a partner service provider could be sent a notification after the user was fulfilled or even after the charging was successful. This can aid the service providers to gather real time data about the way the service is being delivered. Service providers can not only use this data in user interaction but also use it for reconciliation purposes. Further, the delivery of context could have been made by MMS instead of inline delivery over HTTP. Furthermore, if the service required, the user's age could have been verified before displaying the payment prompt.
• FIG. 7 is a diagram representing the relation between a user and exemplary external services in a mobile network, in accordance with an embodiment of the present invention. As stated in the flowchart above, this figure shows the interaction of the user withAIG102 and a transcoding service702 and a recommendation service704.
• AIG102 receives a request from a user and accordingly, sends or redirects the request to transcoding service702. Subsequently, the response returns to the user.AIG102 then send a request to another service, say recommendation service704, which then returns some response to the user.
• The application intermediation gateway, as described in the present invention or any of its components may be embodied in the form of a processing machine. Typical examples of a processing machine include a general purpose computer, a programmed microprocessor, a micro-controller, a peripheral integrated circuit element, and other devices or arrangements of devices, which are capable of implementing the steps that constitute the method of the present invention. The application intermediation gateway can also be embodied on network elements like routers or gateways.
• The processing machine executes a set of instructions that are stored in one or more storage elements, in order to process input data. The storage elements may also hold data or other information as desired. The storage element may be in the form of a database or a physical memory element present in the processing machine.
• The set of instructions may include various instructions that instruct the processing machine to perform specific tasks such as the steps that constitute the method of the present invention. The set of instructions may be in the form of a program or software. The software may be in various forms such as system software or application software. Further, the software might be in the form of a collection of separate programs, a program module with a larger program or a portion of a program module. The software might also include modular programming in the form of object-oriented programming. The processing of input data by the processing machine may be in response to user commands, or in response to results of previous processing or in response to a request made by another processing machine.
• While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art without departing from the spirit and scope of the invention as described in the claims.

Claims (15)

1. A system for intermediating between one or more users and one or more service providers in a mobile network, the system comprising:

a. an application intermediation gateway, the application intermediation gateway comprising:

i. a context engine, the context engine collecting context details of the one or more users; and

ii. an enforcement engine, the enforcement engine enforcing one or more external services and internal services based on the context details and the requirements of the one or more external and internal services.

2. The system ofclaim 1, wherein the application intermediation gateway enables simultaneous access of the one or more external services and internal services to the user.

3. The system ofclaim 1, wherein the application intermediation gateway facilitates real time events to the one or more service providers during the enforcement of the one or more external services and internal services.

4. The system ofclaim 1, wherein the application intermediation gateway interfaces with the one or more external services and the internal services, the interfacing establishing participation of the one or more external services and the internal services in the overall service delivery in a contextual manner.

5. The system ofclaim 1, wherein the application intermediation gateway coordinates the one or more external services and internal services.

6. The system ofclaim 1, wherein the one or more of external services and internal services are present in at least one of: a network operator, an enterprise, and the one or more service providers.

7. The system ofclaim 1 further comprising a charging enabler, the charging enabler comprising a charging model to provide a common interface to the application intermediation gateway and a policy decision point, the policy decision being present in the mobile network.

8. The system ofclaim 7, wherein the charging model is selected from a group consisting of: direct operator backend integration, a redirection based charging, PSMS charging based on MO, and PSMS charging based on MT.

9. The system ofclaim 7, wherein the charging model is one of non-operator based payment mechanisms.

10. The system ofclaim 1, wherein the one or more external services comprises at least one of: transcoding service, age verification service, streaming service, recommendation service, advertisement service, fulfillment aware charging, dynamic pricing and messaging services.

11. A method for facilitating access to one or more external services and one or more internal services to a user in a mobile network through an application intermediation gateway, the mobile network comprising a plurality of users, the application intermediation gateway, a context server, a policy decision point, a plurality of service providers, and one or more external and internal services, the user requesting an application using a device, the request being in the form of a data packet, the method comprising the steps of:

a. providing the requirements for the one or more external services and internal services to the application intermediation gateway;

b. collecting context details of the user from the data packet and the context server, the context details being collected by the application intermediation gateway, the context details comprising information regarding the device characteristics, the network capabilities, and the user profile;

c. interfacing with one or more external and internal services by the application intermediation gateway; and

d. enforcing the one or more external services and internal services based on the collected context details and the requirements of the one or more external and internal services.

12. The method ofclaim 11 further comprising facilitating real time events to the plurality of service providers during the enforcement of the one or more external services and internal services, the real time events being facilitated by the application intermediation gateway.

13. The method ofclaim 11, wherein the one or more external services are at least one of: transcoding service, age verification service, streaming service, recommendation service, advertisement service, fulfillment aware charging, dynamic pricing, and messaging services.

14. The method ofclaim 11 further comprising the steps of:

a. establishing participation of the one or more external services and the internal services in the overall service delivery in a contextual manner; and

b. coordinating the one or more external services and internal services.

15. The method ofclaim 11, wherein the method is carried out by one or more computer programs.

Images