WO2003047207A1

WO2003047207A1 - Method and arrangement for definition and control of message distribution

Info

Publication number: WO2003047207A1
Application number: PCT/NO2002/000447
Authority: WO
Inventors: Øyvind BREIVIK; Børge NILSEN
Original assignee: Beep Science
Priority date: 2001-11-27
Filing date: 2002-11-27
Publication date: 2003-06-05
Also published as: AU2002365334A1; NO20015791D0; NO20015791L

Abstract

The present invention discloses an arrangement and a method for defining and controlling, by an end-user, the distribution of messages in a messaging environment of a communication network. According to the invention, a user interface is provided on a user terminal for the user to create new or modify existing policies stored in a policy database. The policies may comprise lists of valid receivers being allowed to receive and/or forward messages to which the policies are bound. Messages sent from the end-user may then be assigned these new/modified policies by including the policy name in the address of the messages at publishing. The messaging infrastructure will then bind the respective policies to the messages so that any further sending will result in that the associated policies will be enforced.

Description

METHOD AND ARRANGEMENT FOR DEFINITION AND CONTROL OF MESSAGE DISTRIBUTION

Field of the invention

The present invention relates to an arrangement and a method in messaging environments where value added content can be sent from a mobile terminal. In particular, the invention relates to functions for defining and controlling how messages can be distributed. The invention relates to, but is not exclusive to, the messaging environment of mobile Multimedia Messaging Service.

Background of the invention

The mobile Multimedia Messaging Service (MMS) [1] will support transfer and delivery of value added content (e.g., sounds, video and images) to and from mobile terminals. The mobile terminals will over time evolve to become increasingly powerful and support new, rich formats and new forms of use.

With the opportunity of sending rich content from the mobile terminal, the need for controlling how the content is being distributed and sent will grow. To achieve this, solutions for Digital Rights Management (DRM) must be provided where these solutions enforce policies on how the MMSs are being distributed and used.

To enforce how the MMS is distributed and used, it must

- first be possible to define and modify distribution policies,

next, it must be possible to associate a policy with a message that is being sent, and finally, it must be possible to control that the policy is enforced whenever the message is being sent, i.e., it must integrate with a proper DRM system.

The following end-user scenarios illustrate the problem addressed:

An end-user has taken a digital picture with his MMS terminal. The picture is of a private or confidential nature. The end-user wants to send the picture to one specific end-user using his MMS terminal. The sender does not want the picture to be further distributed to any other end-user after it has been sent (e.g., by the other user forwarding it to others) . The sender needs to be able to specify that the MMS with the picture is to be sent to the specific user, but not being allowed to be distributed from the specific user to other users. Also, the restrictions must be enforced.

A community shares MMS messages they have created with their MMS terminals by sending MMSs to each other. No one outside the community must get access to these MMSs. This forms a closed user group. When an end-user wants to send an MMS with these restrictions to one or more other members of the group, the end-user must be able to specify the policy restrictions that should apply. Again, the restrictions must be enforced.

An enterprise wants to distribute business intelligence to its sales force. The sales force is equipped with MMS terminals. In no way should the information be sent from a member of the sales force to an end-user outside the sales force. When the enterprise sends a confidential MMS to the sales force, the enterprise representative must be able to specify the restrictions that should apply on the MMS.

The clearinghouse [2] DRM model is a model where the content is packaged in a container. When reading the content with a client that can interpret the specially packaged container, the container will authorize access to the content with a remote clearinghouse. Policies for content access are typically defined with the clearinghouse .

However, ^'the clearinghouse model is not a mobile centric solution, though it will support mobile terminals too. The main problems with the clearinghouse model are related to installation of special software on the mobile terminals in order to enforce DRM. This also means that distribution will be limited to clients that support the clearinghouse DRM model.

Platform for Internet Content Selection (PICS) [3] and Digital Signature (DSiG) [4] is a standard solution for defining and controlling meta-data for web content. This solution defines a language and a set of processing rules for controlling access to content. This allows, e.g., parents to control what content their kids can access. Note specifically that PICS addresses filtering of received content, not control of distribution as such.

A problem with the PICS/ DSiG solution is that the solution is intended for control and filtering of received information. The control functions are not sufficiently secure to be used for control of published information as it relies on the "good will" of the receiver to enforce the control functions.

None of the above mentioned solutions provides an end-user specific control of value added content. However, this will be even more important in environments like MMS because of the multimedia content that allows for a more detailed and illustrative way of expression (pictures, sounds, moving pictures) . Consequently, there is a need for a solution for defining and controlling the distribution of value added messages by the end-user.

Summary of the invention

The main object of the present invention is to provide an arrangement and a method providing the above-mentioned solution. The features defined in the claims enclosed characterize this arrangement and method.

The present invention relates to distribution control for MMS sent from a mobile terminal. The invention provides mechanisms for an end-user to define and use distribution policies for MMS sent from a mobile terminal. It provides an arrangement and methods for:

defining and managing distribution policies,

using the predefined policies, and

bridging the use of predefined policies to a solution that can enforce the policies.

The distribution policy may typically include rules on how content can be distributed, forwarded and charged for. This distribution policy can then e.g. be used to:

a. Control that the receiver of the message does not forward it at all,

b. Control that the message is not being forwarded outside a defined community,

c. Control that the message cannot be forwarded before or after a given time, d. Control the use of a community oriented publishing service, e.g., who can read the homepage/ service- page for a given community.

The method for defining a policy is a lightweight graphical user interface (GUI) that can be downloaded from a network server to a client terminal, either represented by a personal computer (PC) or a mobile terminal. The GUI is typically implemented by means of a Java applet (or Java midlet for the mobile terminal) . The tool is a lightweight and easy to use GUI that can be used for managing existing policies as well as defining new ones.

When sending an MMS message, the message is at the point of sending/ publishing tied to a policy known to the messaging infrastructure. This policy can either be defined by the policy service provider or by the end-user. Methods for tying the message to a policy are provided, as is the arrangement required for bridging this to a solution that can enforce the policy.

Brief description of the drawings

In order to make the invention more readily understandable, the discussion that follows will refer to the accompanying drawing.

Figure 1 illustrates the key components involved in the method according to the present invention and the relation between them.

Detailed description of preferred embodiments

The objective of the invention is to provide an arrangement for end-users to easily define and use distribution policies to be applied to MMS being sent from end-user terminals and to bridge these to a solution that can enforce the policies. The invention is implemented by means of the system architecture depicted in figure 1. A policy management client interfaces the user that defines and manages policies. The client works towards a server that validates the operations and stores the policies in a database. When MMS messages are being sent, the message control engine identifies policies tied to the message and binds this policy directly to the message, thus enabling the message and its content-elements to be controlled and enforced.

In more details, the key functions of the illustrated components are as follows:

Policy Management Client

The Policy Management Client (PMC) implements a graphical user interface (GUI) that is used to define new distribution policies and manage existing ones. The PMC communicates with the Policy Server in doing this.

Policy Server

The Policy Server implements the server side logic for defining and managing policies. It also implements a structured database of existing policies and provides interfaces where policies can be queried based on their owner and identity.

Message Control Engine

The message control engine performs control functions associated with sending of MMS messages. This includes functions for identifying messages being published/ sent with a policy, binding the policy to the message, identifying policies bound to forwarded messages and enforcing these message policies in order to execute distribution control. MMS-C

The MMS-C performs standard MMS-C functions as defined in standards from ETSI/ 3G.PP [1]. This includes functions for store-and-forward of multimedia messages. The MMS-C implementation is not within the scope of this invention.

This invention defines the network structure and components realising this solution and describes the services offered to the end-users and service providers. In brief, the process for defining and controlling message distribution is defined as:

1. Define or manage policy,

2. Publish/ send the message so that it is tied to the policy,

3. The Message Control Engine detects the tied policy and binds the policy to the message (relay process),

4. The Message Control Engine identifies and enforces the policies bound to the messages being sent (relay process) .

The present invention relates to the above steps 1-3. The process for identifying a bound policy and enforcing it is not part of this invention, but is presented for completeness of the invention disclosure.

Defining and Managing Policies

The main policies available to end-users will usually be set by the service provider, but it should also be possible to define user based policies within the main policies, thus allowing the user to restrict or otherwise tailor the ones provided by the service provider. Managing Existing Policies

Management of existing policies is typically related to limiting or extending the set of predefined policies made available from the policy service provider. With respect to managing or tailoring a policy, the user will get access to a simple graphical user interface (GUI) where he/ she can tailor their policy (i.e. service profile), upload the new policy, and use it.

The policy management tool, the GUI, is a Java applet/ midlet based client that downloads to the client terminal (PC or mobile) and allows the user to configure the policy within the framing conditions set by the policy service provider. After the user has finished managing the policy, he/ she can upload the policy settings to the network and start using it.

The work process thus becomes:

1. The user downloads the management interface by accessing a service (e.g. URL [5]),

2. The user logs in to the service and establishes a policy management session,

3. The user gets a set of available policies that can be managed,

4. The user selects one of the policies,

5. The user modifies, adds or removes policy statements such as,

add/ modify white-list, i.e. list of valid receivers,

add/ modify black-list, i.e. list of invalid receivers, add/ modify forwarding rules, e.g. forwarding not allowed,

add/ modify time-restrictions, e.g. valid for 6 hours

6. The user deploys the change (the policy is then uploaded)

Defining new Policies

Defining a new policy is typically something that is done by the policy service provider, to provide new predefined policies to be used by the end-users. However, it may also be delegated to end-users where the end-users are allowed to create new characteristics within the framing conditions of another high-level policy (e.g. an offline policy document/contract ) .

Defining a new policy uses the same tool and GUI as defined above, but typically requires the user to have more privileges and requires the user to enter more policy data, such as information on price structures, and information on who owns and provides the service.

The work process thus becomes:

1. The user downloads the management interface by accessing a service (e.g. URL),

2. The user logs in to the service and establishes a policy management session,

3. The user selects to create a new policy,

4. The user modifies, adds or removes policy statements such as,

- add/ modify white-list, i.e. list of valid receivers, add/ modify black-list, i.e. list of invalid receivers,

add/ modify forwarding rules, e.g. forwarding not allowed,

5 - add/ modify time-restrictions, e.g. valid for 6 hours .

5. The user deploys the change (the policy is then uploaded)

Publishing Messages with Defined Policies Tied to the o Messages

Sending or publishing an MMS with a defined policy gives the MMS policy-characteristics that must be enforced. By associating an MMS message with a given predefined policy, the message inherits the characteristics of that policy.

s Publishing messages with a predefined policy is as simple as sending a message in the usual fashion. The tying to the policy is obtained by the addressing format of the message, where an address structure of <receiver>@<policy> is used. This address structure is intuitive for the end-user and it o is supported by the MMS standards and all MMS related equipment. An example structure of the address is given by:

<phone-number>@<policyName> . <serviceProvider>

When a message is sent from a mobile via the MMS-MM1 [1] interface or from a PC via the MMS-MM7 [1] interface, there 5 is a network policy function that binds the policy directly to the message in such a way that given the message only (i.e. without the addressing information of <receiver>@<policy>) , the policy can still be identified and subsequently enforced. This binding process is placed between the publishing equipment (PC or mobile) and the MMS-C and is handled by the Message Control Engine.

Bridging to Enforcement System

When a message is sent/ published, a network policy function in the Message Control Engine filters the message address and identifies if this message is being published with a predefined policy.

Which policy to use is identified based on the sending phone number (ms-isdn) and the destination address of the message. Given a sender and receiver address

To : <ms-isdn>@<policyName> . <serviceProvider> From: <ms-isdn>

The policy function will look for a policy with the given name in the domain of the defined service provider. If there is a user specific variant of this main policy identified through the sender' s ms-isdn, then this will be used; otherwise the default main policy will be used.

Once the specific policy is found, the binding function (see the section of Policy Binding Techniques) will bind the policy to the message that is to be policy enforced. By binding the policy directly to the message, the policy of the message can later be identified by the Message Control Engine without the use of the policy addressing association used during the initial sending/ publishing of the message (see also the section of Publishing Messages with Defined Polices Tied to the Messages) . This forms a bridging to a solution that can enforce the message policy every time the message is sent/ forwarded again.

Next the receiver address is changed to remove the policy reference (e.g. only leaving the ms-isdn of the receiver) and the message is forwarded to the MMS-C. The policy is now activated on the MMS message in such a way that any further sending of this message or one of its content-elements will result in the policy being enforced by the Message Control Engine and thus implement message- sending control (see the section of Identifying and Enforcing Policies) .

Policy Binding Techniques

Several techniques can be used to bind a policy to a message or its content-elements. The techniques for doing this are not part of this invention and are therefore not described here. The techniques need to have the following characteristics :

a. Given the message/ content-element, it shall be possible to identify the policy bound to this message/ content-element.

b. The process of identifying a policy needs to be sufficiently fast to allow for identification and execution of policies in real time.

c. The techniques for binding a policy to a message/ content-element needs to be computationally secured. This means that the policy binding should withstand attacks from normal user communities using normal computer resources.

Identifying and Enforcing Policies

When a message is sent/ forwarded, the Message Control Engine will filter the message and identify all policies bound to this message and its content-elements. The identification process corresponds to the binding process defined in the last section and is not part of the invention as such. The characteristics of the identification process are: a. Given a message or a content-element, it shall be possible to identify all policies bound to this message/ content-element.

b. The process of identifying a policy shall be sufficiently fast to allow for identification and execution of policies in real time.

When one or more policies have been identified for a given message, the Message Control Engine will ensure that the policies are enforced. This typically involves requesting a Policy Enforcement Agency to enforce the policies for the given service context. The service context typically defines the sender, receiver and service domain (MMSE/ operator domain) , but may also include information on the geographic location of the user if that is available. Given this information, the Policy Enforcement Agency will execute the policies and grant or deny access to the message or content-element. The policy enforcement process is not part of the invention.

The present invention provides:

a. Service enablers for MMS by enhancing the MMS architecture with policy handling that can be deployed by service providers to offer new and innovative MMS services to end-users,

b. Easy-to-use means for end-users to control the mobile distribution of their originated MMS, paramount to privacy handling,

c. An efficient method to set policies from a client, by providing downloadable and self-installation software components, for PC and mobile devices, and by providing limited communication requirements with the policy server, d. An easy to use publishing interface by using well known addressing mechanisms available both for PC and mobile devices,

e. An efficient policy identification solution by utilizing the addressing mechanism as an implicit policy identity that can later be bound to the message itself.

Extension-1: Use of MIME headers for addressing policy

The protocol used for sending MMS messages is based on Http and mime-headers. This means that routing information is defined as mime-headers at the transport level, as represented by the <To: > and <From: > mime-headers.

Mime-headers could also be used for defining the policy associated with a message, e.g. using a <x-policy: > mi e- header. This would require special MMS client (user-agent) with menu options for selecting policy and functions for encoding mime-headers in the message send request.

Extension-2 : Tool for creating phonebook aliases

As an extension to the function of publishing messages within ^Λpolicy defined service channels' , a tool is provided to assist the user in binding ^policy defined service channels' to phone-numbers. The tool provides a means to automatically get address-aliases for the binding of phone-numbers with the channels simplifying the publishing process.

The tool is a Java applet based client that downloads to the client terminal (PC or mobile) and allows the end-user to bind one or more policies to the entries in the phonebook and update the phonebook with the new data. When the tool is invoked on the client it will: 1. Retrieve available phone-numbers and aliases on the client .

2. Show the available service channels.

3. Allow for selection of service channel and phone- number list.

4. Generate corresponding aliases.

5. Store the aliases within the phone-book/address-book of the client.

An example of how it could look like is depicted below:

Old phonebook: alias-name number

"Mary P" 98832626 "Harry C" 92354344

New phonebook: alias-name number "Mary P (friends)" 98832626@friends.operator.com

"Mary P" 98832626 "Harry C (corp) "

92354344@corp. operator. com

Abbreviations and references

[1] MMS 3GPP TS 23.140 v .2.0 (2001-03), 3rd Generation Partnership Project; Technical Speci ication Group Terminals; Multimedia Messaging Service (MMS) ; Functional description; Stage 2 (Release 4)

[2] Clearinghouse "Digital Rights for all media types", Internetcontent.net, 2/20/2001

[3] PICS Rating Services and Rating Systems (and Their Machine Readable Descriptions) , REC-PICS-services- 961031, version 1.1, World Wide Web Consortium

(W3C) , Recommendation 31-October-1996

[4] DSig PICS Signed Labels (DSig) 1.0 Specification, REC-DSig-label-19980527, World Wide Web Consortium (W3C) , Recommendation 27-May-1998.

[5] URL/VRI, Uniform Resource Identifiers (URI) :

Generic Syntax, Internet Engineering Task Force (IETF), Request For Comment (RFC) 2396, August 1998

Claims

P a t e n t c l a i m s

1. An arrangement of defining and controlling policies for data objects being transferred in a communication network to and/or from terminals connected thereto, the communication network including a Message Control Engine (MCE) adapted to bind and enforce the policies to/on the data objects so that given one of the data objects, a policy bound to that data object will be identified and enforced, c h a r a c t e r i z e d i n that a Policy Management Client (PMC) provides a user interface on the terminals adapted to enable a user to create a new policy or to modify an existing policy associated with a policy name to a tailored policy intended for a data object, said tailored policy being stored in a Policy Database (PdB) in which also said new or existing policy is stored, the user publishes the data object by including at least the policy name and an address of the user and an intended receiver in an address field of the data object in a format known to the MCE and by transmitting the data object to the MCE, when the MCE recognizes the format, the MCE binds the tailored policy to the data object in that a Policy Server (PS) , connected to said PdB, PMC and MCE, provides the tailored policy associated with the policy name in combination with the address of the user, or with the policy name only, to the MCE for the MCE to execute the binding.

2. Arrangement according to claim 1, c h a r a c t e r i z e d i n that said data objects are, or are elements of, Multimedia Message Service (MMS) messages, and that said MCE is integrated in an MMS architecture connected to said communication network.

3. Arrangement according to claim 1 or 2, c h a r a c t e r i z e d i n that the policy defines valid receivers being allowed to receive and/or forward the data object.

4. Arrangement according to any of the preceding claims, c h a r a c t e r i z e d i n that said policy name and

5 address of intended receiver are attached to the data object in the format of <address of intended receiver>@<policy name>.

5. Arrangement according to any of the claims 3 or 4, c h a r a c t e r i z e d i n that the user modifies an o existing policy by editing a list of valid receivers and/or a list of invalid receivers and/or forwarding rules and/or time-restrictions .

6. Arrangement according to any of the preceding claims, c h a r a c t e r i z e d i n that the PMC is a Java s applet/midlet client.

7. Arrangement according to any of the preceding claims, c h a r a c t e r i z e d i n that the user creates a new policy or modifies an existing policy by:

accessing a service on the terminal initiating the PMC o to download the user interface to the terminal,

establishing a policy management session,

creating a new policy or modifying an existing one,

modifying, adding and/or removing policy statements,

uploading the new policy or changes to an existing 5 policy to the database.

8. A method for defining and controlling policies for data objects being transferred in a communication network to and/or from terminals connected thereto, the communication network including a Message Control Engine (MCE) adapted to bind and enforce the policies to/on the data objects so that, given one of the data objects, a policy bound to that data object will be identified and enforced, c h a r a c t e r i z e d i n

providing a user interface on the terminals adapted to enable a user to create a new policy or to modify an existing policy associated with a policy name to a tailored policy for a certain data object, said tailored policy being stored in a Policy Database (PdB) in which also said new or existing policy is stored,

including at least the policy name and an address of the user and an intended receiver in an address field of the data object,

transmitting the data object to the MCE, and

requesting the MCE to bind the tailored policy to the data object, the MCE identifies the tailored data object by comparing the address of the user and the policy name or by the policy name only.