U.S. patent application number 11/455319 was filed with the patent office on 2007-01-04 for method and system for providing external and internal services through an application intermediation gateway.
This patent application is currently assigned to JULY SYSTEMS, INC.. Invention is credited to Sunil Arvindam, Jyotirmoy Chakravorty, Vishal Lal, Rajesh TS Reddy, Umesh Singhal.
Application Number | 20070005766 11/455319 |
Document ID | / |
Family ID | 33029668 |
Filed Date | 2007-01-04 |
United States Patent
Application |
20070005766 |
Kind Code |
A1 |
Singhal; Umesh ; et
al. |
January 4, 2007 |
Method and system for providing external and internal services
through an application intermediation gateway
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.
Inventors: |
Singhal; Umesh; (Bangalore,
IN) ; Lal; Vishal; (Bangalore, IN) ; Reddy;
Rajesh TS; (Bangolore, IN) ; Chakravorty;
Jyotirmoy; (Bangalore, IN) ; Arvindam; Sunil;
(Bangalore, IN) |
Correspondence
Address: |
William L, Botjer
PO Box 478
Center Moriches
NY
11934
US
|
Assignee: |
JULY SYSTEMS, INC.
SANTA CLARA
CA
|
Family ID: |
33029668 |
Appl. No.: |
11/455319 |
Filed: |
June 19, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10389783 |
Mar 17, 2003 |
7076562 |
|
|
11455319 |
Jun 19, 2006 |
|
|
|
Current U.S.
Class: |
709/225 |
Current CPC
Class: |
H04L 67/20 20130101;
H04L 67/327 20130101; H04L 67/2814 20130101; H04L 67/2842 20130101;
H04L 69/329 20130101 |
Class at
Publication: |
709/225 |
International
Class: |
G06F 15/173 20060101
G06F015/173 |
Claims
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 of claim 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 of claim 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 of claim 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 of claim 1, wherein the application intermediation
gateway coordinates the one or more external services and internal
services.
6. The system of claim 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 of claim 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 of claim 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 of claim 7, wherein the charging model is one of
non-operator based payment mechanisms.
10. The system of claim 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 of claim 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 of claim 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 of claim 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 of claim 11, wherein the method is carried out by
one or more computer programs.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent
application Ser. No. 10/389,783 filed Mar. 17, 2003
BACKGROUND
[0002] The present invention relates to telecommunication networks.
In particular, the invention relates to an infrastructure element
that intermediates between users and service providers.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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
[0014] 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.
[0015] 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.
[0016] 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.
[0017] Yet another object of the invention is to provide a system
and method for provisioning data services over a network.
[0018] 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.
[0019] 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.
[0020] 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
[0021] 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:
[0022] FIG. 1 is a block diagram representing the general
environment in which an embodiment of the present invention
functions;
[0023] 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;
[0024] FIG. 3 is a flowchart illustrating the functioning of the
present invention, in accordance with an embodiment of the present
invention;
[0025] 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;
[0026] 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;
[0027] FIGS. 6A, 6B, and 6C are a flow chart illustrating the
implementation of an exemplary external service, in accordance with
an embodiment of the present invention; and
[0028] 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
[0029] 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).
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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 of core
network elements 104 to a plurality of content providers 106, third
party application providers 108 and partner portals 110. The Core
network elements are the basic infrastructure elements of the
network provided by a network operator. Exemplary core network
elements 104 are Gateway GPRS Support Node (GGSN) and Packet Data
Serving Node (PDSN). The data packets may originate from a user or
a service provider. AIG 102 is deployed in the path between user
and the service provider and transfers the data packets from one to
another.
[0039] Core network elements 104 receive a user request from the
user and pass it on to AIG 102. The user request is in form of data
packets. AIG 102 implements the application level policies on the
data packets. The decisions on application level policies are
provided to AIG 102 by a Policy Decision Point (PDP) 112. PDP 112
may act as a policy controller for both core network elements 104
and AIG 102. AIG 102 also interacts with content providers 106,
third party application providers 108 and partner portal 110. AIG
102 forwards the user request to the desired content provider 106,
third party application provider 108 or partner portal 110,
receives response to the request and forwards the response back to
user.
[0040] In accordance with a preferred embodiment of the present
invention, AIG 102 is deployed in an operator's network. However,
it would be evident to a person skilled in the art that AIG 102 can
be deployed in an enterprise local network as well.
[0041] FIG. 2 is a block diagram of application intermediation
gateway along with a policy decision point and a context server.
AIG 102 receives a user request from a user through a system kernel
202. The user request is in form of data packets. System kernel 202
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.
[0042] Depending on the application type determined from TCP
header, system kernel 202 redirects the data packets to the
corresponding application handler of application handlers 204
through an I/O control interface 206 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.
[0043] Application handlers 204 receive the data from system kernel
202 through an I/O control interface 206. Application handlers 204
comprise a set of application handlers for handling different types
of applications. I/O control interface 206 also communicates the
data from application handlers 208 to system kernel 202.
[0044] 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.
[0045] For an HTTP request, the data packets are passed to an HTTP
application handler 208. HTTP application handler 208 performs
application level access control to the user's requests. HTTP
application handler 208 provides functionalities for inline prompts
and allows users to make decisions while accessing the
applications. HTTP application handler 208 also allows redirection
of users. The redirection of users helps integrating the users with
content download sites and payment gateways.
[0046] Access control is performed by HTTP application handler 208
based on the context information. The access is controlled by
policy defined by the network operator.
[0047] 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.
[0048] 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.
[0049] The data is parsed by a data parser 210. Data parser 210 is
a generic parser that parses all text based protocol data.
Exemplary protocols can be HTTP, SIP and POP. Data parser 210
examines the header portion of the data packet and enables HTTP
application handler 208 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.
[0050] To provide content providers 106, third party application
providers 108 and partner portals 110 with more information about
the user and network capabilities to enable provision of better
services, inline context injection is done in the HTTP header by
HTTP application handler 208. This eliminates the need for content
providers 106, third party service provider 108 and partner portals
110 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.
[0051] 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 to AIG 102
is:
[0052] GET http://www.julysystems.com HTTP/1.1
[0053] Accept: */*
[0054] UA-OS: Windows CE (POCKET PC)--Version 3.0
[0055] UA-color: color16
[0056] UA-pixels: 240.times.320
[0057] UA-CPU: ARM PXA250
[0058] UA-Voice: FALSE
[0059] UA-Language: JavaScript
[0060] Accept-Encoding: gzip, deflate
[0061] User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows CE;
PPC; 240.times.320)
[0062] Host: 192.168.100.58
[0063] Connection: Keep-Alive
[0064] Location: Bangalore
[0065] In the above example, "Location: Bangalore" is the context
that is injected in the header of the data packet.
[0066] 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:
TABLE-US-00001 <?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.times.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>
[0067] A context engine 212 collects the context details for the
user. Context engine 212 interacts with a context server 214 to
update or query the relevant context. Context engine 212 extracts
the context from HTTP header of data packets. The context that is
queried from context server 214 comprises details about the network
and user profile. Exemplary context that is collected from context
server 214 is network type, network identifier, location
information and user identification. Context engine 212 also
provides the context to HTTP application handler 208 for inline
context injection and updates context on context server 214.
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
engine 212 comprises a local context store 216. Local context store
216 caches the context details locally on AIG 102 so that the
context need not be obtained from context server 214 each time.
[0068] The context is used for enforcement of policy decisions on
the data packets. The policy decisions are enforced by an
enforcement engine 218. 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.
[0069] The policy decisions are provided for enforcement by a
policy component 220. Policy component 220 interacts with PDP 112.
The decisions for all the policies to be implemented are taken at
PDP 112. Policy component interacts with PDP 112 using Common Open
Policy Service Protocol (COPS) and Policy Communication Protocol
(PCOMP) for policy decisions. COPS and PCOMP are protocols for
policy exchange.
[0070] The policy decision can be made in two ways. When AIG 102
needs a policy decision, it requests PDP 112 for the decision on
the policy. PDP 112 may provide the policy decision to policy
component 220 of AIG 102 for implementation when AIG 102 requests.
Also, some policy decisions of AIG 102 may be provisioned
beforehand by PDP 112. The provisioned policy decisions are stored
in a local policy decision store 222 and are used for
implementation when required. Each policy decision is locally
cached in local policy decision store 222 to avoid requesting for
policy decision every time from PDP 112.
[0071] Also as the service is being delivered to the user, a
metering record is generated by a metering record generator 224.
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.
[0072] FIG. 3 is a flowchart illustrating the functioning of a
preferred embodiment of the present invention.
[0073] At step 302, the system kernel 202 receives a user request.
The request is in form of data packets. At step 304, 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. At step 306, 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. At step 308, the
user request is transferred to an application handler that handles
the type of application detected from the header of data
packets.
[0074] At step 310, the context relating to the data packets is
checked by context engine 212. The context is used for taking
policy decisions on the user request. At step 312, it is determined
which policy decisions are to be applied on the data packets. The
policy decisions are taken by PDP 112. Also, PDP 112 may provision
AIG 102 for the policy decisions. In case PDP 112 provisions AIG
102 for policy decisions, the decision is provided by local policy
decision store 222.
[0075] At step 314, the policy decisions are implemented on the
user request by enforcement engine 218. 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.
[0076] At step 316, the user request is forwarded to content
provider 106, third party application provider 108 or partner
portal 110. At step 318, the response from content provider 106,
third party application provider 108 or partner portal 110 is
received. At step 320, 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. At step 322, the response is
forwarded back to the user.
[0077] FIG. 4 is a block diagram including an application
intermediation gateway 102 and external services 402. Application
intermediation gateway 102 includes context engine 212 and
enforcement engine 218. Application intermediation gateway 102
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.
[0078] AIG 102 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 more external services 402 and the
service providers.
[0079] AIG 102 interfaces with one or more external services 402
and facilitates simultaneous external and internal services to the
users in the mobile network. Further, AIG 102 provides one or more
external services 402 to participate in the overall service
delivery of the network in a contextual manner. As a result, one or
more external services 402 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 by context engine 212. Subsequently, enforcement
engine 218 enforces one or more external services 402 based on the
context details of the user and the requirements of the overall
service delivery. The functioning of context engine 212 and
enforcement engine 218 has been discussed in FIG. 2.
[0080] AIG 102 allows one or more external services 402 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. AIG 102 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 more external services 402.
[0081] In accordance with an embodiment of the present invention,
AIG 102 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, AIG 102 provides
transcoding service along with video content to the user. In such a
case, PDP 112 responds with policy decision of transcoding to AIG
102 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 that AIG 102 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 more external services 402.
[0082] In accordance with an embodiment of the present invention,
AIG 102 intermediates on behalf of service providers for sourcing
and delivering key information, which is required for delivering
one or more external services 402. Further, AIG 102 provides one or
more external services 402 other than internal services to the
users. Various examples for one or more external services 402 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 with FIG. 5.
[0083] In accordance with an embodiment of the present invention,
when the user's request arrives at AIG 102, 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 more external services 402 and
one or more internal services.
[0084] FIG. 5 is a diagram representing the relation between
internal services 504 and one or more external services 402 in
network 500, in accordance with an embodiment of the present
invention. Network 500 includes network operator's assets 502.
Network operator's assets 502 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.
[0085] As mentioned earlier, requirements for one or more external
services 402 and internal services 504 are provided by AIG 102. The
context details are collected by context engine 212. Subsequently,
enforcement engine 218 enforces one or more external services 402
based on the context details of the user and the requirements of
the overall service delivery. Internal services 504 include a
metering server 508, a charging enabler 510, AIG 102, context
server 214, and policy component 220. Internal services 504
generate and capture the metering records at metering server 508
for reporting and reconciliation purposes. As mentioned in FIG. 4,
one or more external services 402 includes the requirements for
making one or more external services 402 participate in the overall
service delivery in a contextual manner. For example, one or more
external services 402 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. AIG 102 and policy component 220 interact with
one or more external services 402 for making one or more external
services 402 participate in the overall service delivery in a
contextual manner. External services 402 are provided on the basis
of the context details and the requirements of the overall end to
end service. Policy component 220 provides various policies that
need to be enforced. The enforcement of the policies and one or
more external services 402 is performed by enforcement engine
218.
[0086] AIG 102 enhances the capabilities of the charging gateway
and the corresponding policies in PDP 112. As a result, AIG 102
coordinates the flow of the internal services 504. For example, AIG
102 enables charging enabler 510 to interface with the network
operator's charging gateways directly.
[0087] In accordance with another embodiment of the present
invention, AIG 102 enables charging enabler 510 to interface with
the network operator's charging gateways through billing
aggregators.
[0088] In accordance with an embodiment of the present invention,
charging enabler 510 provides a simple and a common interface
between AIG 102 and PDP 112. Charging enabler 510 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.
[0089] In accordance with an embodiment of the present invention,
AIG 102 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. AIG 102 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 with FIGS. 6A, 6B, and 6C.
[0090] FIGS. 6A, 6B, and 6C 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. At step 602, AIG 102
receives the user's request and identifies the service to be
invoked. At step 604, AIG 102 retrieves the user's context details
from context server 214. At step 606, AIG 102 sends a policy
request to PDP 112. At step 608, PDP 112 receives the recommended
price for the requested service from a dynamic pricing external
service. The recommended price is calculated based on the context
details. PDP 112 returns to AIG 102 with a decision to forward the
context details including the recommended price inline to service
provider 506.
[0091] Subsequently at step 610, AIG 102 forwards the context
details to service provider 506. At step 612, service provider 506
communicates the recommended price to the user. The user then gives
a purchase request. At step 614, AIG 102 receives the purchase
request from the user. Further, AIG 102 retrieves the user's
context details from context server 214. At step 616, AIG sends the
policy request to PDP 112. At step 618, PDP 112 reserves the charge
in the charging gateway through charging enabler 510. Subsequently,
PDP 112 responds to AIG 102 with a policy decision of prompting the
user to AIG 102.
[0092] At step 620, AIG 102 prompts the user with the recommended
price. At step 622, 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 step 624. At step 624, AIG 102 again
sends the policy request to PDP 112. At step 626, PDP 112 responds
with policy decision of transcoding to AIG 102 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.
[0093] Subsequently, at step 628, AIG 102 retrieves the context
from context server 212. Context server 212 can be hosted either
with the network operator or with service provider 506. At step
630, AIG 102 sends a transcoding request to the transcoding service
along with the transcoding parameters. At step 632, AIG 102,
receives the transcoded context back from transcoding service and
fulfills it to the user.
[0094] At step 634, AIG 102 sends the policy request to PDP 112
when the fulfillment is complete. At step 636, PDP 112 commits the
charge in the charging gateway through charging enabler 510 and
responds to AIG 102 with a policy decision of metering and
recommendation. At step 638, a metering record is generated and is
sent to metering server 508 for its display. At step 640, AIG 102
sends a request for recommendation to the recommended service and
passes the required parameters from the user's context details. At
step 642, recommendation service returns with the recommendations
for the user. At step 644, AIG 102 returns with recommended
products list to the user.
[0095] 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.
[0096] 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 with
AIG 102 and a transcoding service 702 and a recommendation service
704.
[0097] AIG 102 receives a request from a user and accordingly,
sends or redirects the request to transcoding service 702.
Subsequently, the response returns to the user. AIG 102 then send a
request to another service, say recommendation service 704, which
then returns some response to the user.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
* * * * *
References