Token and a distributed service network which uses it

Field of the invention

The invention generally relates to distributed service networks and particularly to distributed service networks employing electronic tokens. The invention also relates to an electronic token.

Background of the invention

Spamming, which means bulk transmission of unsolicited messages (e-mail, text messaging), is one of the biggest challenges to conventional (e- mail) systems and the internet in general. Prior art e-mail service platforms provide limited means for controlling bulk transmission of messages ("spamming"), which is why filtering has been the predominant approach to control spamming. Filtering is very difficult to automate successfully, and known filtering approaches often result in accidental deletion of e-mail messages which might be of interest to the recipient. Some distributed service networks use certificates or tokens for verification of the service provider's identity and/or the authenticity of the service itself. Conventional certificates exhibit certain shortcomings as regards flexibility, for example. Furthermore, certificates have not been successfully used in spamming control, probably for the reason that no efficient mechanism has been invented for distributing the certificates or how the controlling mechanism would actually work, providing the various parties little incentive to start to use token-certified e-mail systems.

Brief description of the invention

An object of the invention is to alleviate one or more of the problems identified above. The object is achieved by tokens and network elements as defined in the attached independent claims. Specific embodiments are disclosed in the dependent claims and in the present patent specification and the attached drawings.

An aspect of the invention is a token for a distributed service network which implements a service involving a plurality of parties. The parties comprises: token manufacturer, which manufactures the token; service provider, which provides the service, distributes the token, verifies the token on request and manages state changes of the token; user which uses the service via a service client; buyer which buys the service and assigns a right to use the

service to the user. The buyer and user may be the same entity or different entities. The network is divided into a first plurality of manufacturer domains and a second plurality of service provider domains.

The token comprises multiple layers, such that a first layer comprises: a manufacturer domain ID which uniquely identifies the domain assigned to the token manufacturer; a manufacturer ID which uniquely identifies the token manufacturer; a token ID which uniquely identifies the token; a service ID which identifies the service associated with the token; and a token manufacturer's PKI signature. The token's second layer comprises a service provider domain ID which uniquely identifies the domain assigned to the service provider; a service provider ID which uniquely identifies the service provider; a buyer ID which uniquely identifies the buyer; and the service provider's first PKI signature.

The token's third layer comprises: a service client ID which uniquely identifies the service client which requests the service; a checksum of information related to the service; and the service provider's second PKI signature.

As used herein, the term "token" means an electronic data structure which enables its user to obtain one or more services from a distributed service network. When the token resides in a network element of the distributed service network, it is stored in a physical memory medium, which may be electronic, magnetic or optical or any combination thereof. When the token is being transferred from one network element to another, it is carried on an electronic carrier, such as a data message in the underlying telecommunication network.

The token is always on one of several well-defined states, wherein the set of possible states may depend on the token's type. For instance, e-mail stamps may have an unused state and a used state. Unused stamps may be stored, prior to use, in an electronic purse or wallet installed in the same computer as the service client software.

A service network means a network which implements one or more services to users. The service network may use the infrastructure of an underlying telecommunication network, which may be constructed in a conventional manner. A distributed service network means a service network which employs several nodes to provide services. A network element means a node of the distributed service network, including the node, such as terminal,

of the service user. Public Key Infrastructure (PKI) refers to cryptography techniques employing a private key for generating a signature and a public key for verifying it.

A token according to the invention has the following characteristics and provides the following advantages. Each token is unique. In other words, multiple usable copies of a token cannot exist. A token's ownership are verifiable at each processing stage. Each token, when manufactured, is associated with a specific domain and service provider. The service provider maintains a database of manufactured but unused (or active) tokens. An active token means a token whose use has started but not yet finished. Even if a fraudulent user attempts to use a copy of a token, the service provider deletes the token from its database. As a result, possible copies of the token become unusable.

A token according to the invention has a multi-layer structure. When a token is created by the token manufacturer, the token has a first layer which, among other things, indicates the token manufacturer and the manufacturer domain; a second layer which indicates the service provider and service provider domain, as well as the token's buyer; and a third layer which indicates the service client ID. All layers are signed by public key signatures. As a result, the token's characteristic information, such as its ownership, is verifiable at each processing stage.

The overall token structure supports many types of token, some of which are usable only once while some are re-usable. Single-use token are analogous to conventional postage stamps which are stamped and become unusable (for carrying mail) after use. Re-usable tokens are analogous to banknotes and coins which may be used and change ownership several times. Such analogies are only valid from the point of view of the user; in case of paper money, for example, counterfeit prevention is built into the banknotes themselves, but the present invention eliminates counterfeiting by means of the multi-party distributed service network and the multi-layer structure of the inventive token, which collectively permit verification of the tokens at each processing stage. It is worth noting that when tokens according to the invention are used as postage stamps, such stamps are rendered ineffective after use, but the stamps may have distinctive visual outlooks and may be used as collectibles. A distinctive visual outlook for the tokens, for example "stamps" for e-mail, can be implemented by storing a token according to the invention in a

metadata field of a digital image. A checksum computed over the digital image and stored in the token ensures that the token is only valid in connection with the original image. Or, to express the matter more precisely, the digital image which holds the token may be a copy of an original image but the token or the token-image combination is unique in the sense that as soon as a token is used, any copies of it will be rendered unusable.

The multi-layer structure of the token enables and supports delegation of token manufacturing, service provisioning, buying and using to separate entities. An illustrative but non-exhaustive list of application examples for the inventive token and service network includes:

1) Common e-mail service network system, wherein

^■ Each individual user registers into service network;

^■ The user downloads a service client (which may be implemented as a plug-in for an e-mail client program);

^■ The user can use a web interface to manage service:

• The user can register one or more e-mail addresses;

• The user can register one or more service clients; • The user can buy or otherwise obtain e-mail stamps

(tokens) from a selection of different kind of tokens; the stamps are stored in a wallet which is maintained by the service client; the stamps can be used as needed; different kind of tokens can be based on the type of the service offered to the end user.

• Type of the token (stamp) can impact to the functionality of the service, for example the validity of message, limitation of number of messages, sorting messages to different folders.

• The user may select a default visual outlook for e- mail stamps;

^■ Certain service limitations are managed by individual user.

2) Company e-mail service network ■ Companies can make a contract to have company e-mail solution.

• Token type indicates "company mail"

• Each company can have its own visual outlook for , token or a stamp.

• Company register all company mail users at once ■ Inbound Service client may be implemented as a proxy server into the company's e-mail service.

■ Outbound Service client may be implemented as a plug-in into the user's e-mail program.

3) Community e-mail service network ■ Community can make a contract to have company e-mail solution.

• Token type indicates "community e-mail"

• The end user must be also registered as a member of the community in the e-mail service network. 4) Authority e-mail service network

^■ Authorities can make a contract to have company e-mail solution.

• Token type indicates "authority e-mail"

• Users and addresses designated as senders of authority mail will obtain authority e-mail tokens.

5) Marketing e-mail service network

^■ Users can register to certain marketing interest groups and give explicit permission to allow marketing messages from these groups; ■ Marketing companies can deliver marketing material to specific marketing interest groups and marketing service will deliver messages to users, who have allowed marketing messages from these groups. Messages will be sent by using tokens, which are typed as marketing message tokens

^■ The end user's e-mail address is only known within the e- mail service network and it is not visible to the marketing companies.

6) SPAM preventing system in e-mail service network

■ Each registered user will get certain limitation, how many tokens they can get during certain time period; this prevents mass sending of SPAM e-mail.

^■ Each registered user has service client, which is uniquely signed and which can be blocked from service network in case of spamming.

^■ Each user can define rule for inbound service client, which block all e-mail messages, except messages, which are certified by service network. ■ User can define rule for inbound service client that it marks all non- mails for spam filter.

^■ User can block all signed marketing messages.

^■ The service client for inbound e-mail can deliver e-mail messages to different e-mail folders depending on whether the e-mail messages originate from a service network or non-service network. 7) Electronic money

■ The service network can be equipped to provide an electronic money system • Token type indicates "electronic money"

• Each token has value information in the innermost layer.

■ User registers itself as a customer similarly to the e-mail application. ■ User downloads service client and electronic wallet combination.

■ User can buy tokens with certain monetary value

■ The manufacturer register each unique token and current owner of the token ■ User can send ownership change request for the service network

• The service provider change the ownership of the token to new user.

• The service provider registers token, current user and new user during transaction.

• User transfers token to new owner

• New owner confirms transaction to the service provider, which further confirms transaction to the manufacturer. The manufacturer registers new ownership. • User can verify in any case validity of electronic money tokens from the service network.

Brief description of the drawings

In the following the invention will be described in greater detail by means of specific embodiments with reference to the attached drawings, in which:

Figure 1 schematically shows a general system architecture in which the invention can be used;

Figure 2 schematically illustrates a token according to an embodiment of the invention; Figure 3 is a signalling diagram which illustrates manufacturing and using a token according to the invention in a distributed service network;

Figure 4 is an overall view of a generic scenario involving a token according to the invention;

Figure 5 illustrates manufacturing and management of tokens according to the invention;

Figure 6 illustrates the operation of a service provider;

Figure 7 illustrates the operation of a service client;

Figure 8 illustrates an e-mail-related scenario with an individual user; Figure 9 illustrates an e-mail-related scenario wherein the user is an employee of a company which acts as the service buyer;

Figure 10 illustrates a web e-mail scenario; and

Figures 11 through 13 constitute a more detailed version of the signalling diagram shown in Figure 3. Detailed description of specific embodiments

Figure 1 schematically shows a general system architecture in which the invention can be used. The network elements and components shown in Figure 1 are described in the following table:

Figure 2 schematically illustrates a token according to an embodiment of the invention. As shown in Figure 2, the token comprises multiple layers such that the three leftmost layers are present already at token manufacturing stage, while further layers may be added when the token is being used or has been used.

A first layer comprises: a manufacturer domain ID which uniquely identifies the domain assigned to the token manufacturer; a manufacturer ID which uniquely identifies the token manufacturer; a token ID which uniquely identifies the token; a service ID which identifies the service associated with the token; and a token manufacturer PKI signature.

A second layer comprises: a service provider domain ID which uniquely identifies the domain assigned to the service provider; a service provider ID which uniquely identifies the service provider; a buyer ID which uniquely identifies the buyer; and a first PKI signature of the service provider. A third layer comprises: a service client ID which uniquely identifies the service client which requests the service; checksum of information related to the service; and a second PKI signature of the service provider.

When the token is being used or has been used, it further comprises a fourth layer which indicates a used state of the token and comprises: a

checksum of postmarked layout; and a third PKI signature of the service provider.

Tokens which have been used may have some value as collectibles, somewhat analogously to postage stamps or coins. For this purpose, the token may further comprise a fifth layer which, when it exists, indicates an owned state of the token and comprises a fourth PKI signature of the service provider.

The first layer may further comprise a visual outlook ID which identifies a visual outlook for the token; and a visual outlook checksum. Alternatively or additionally, the first layer may further comprise a value field which indicates a value for the token. Alternatively or additionally, the second layer may further comprise a maximal validity period for the token.

Figure 3 is a signalling diagram which illustrates manufacturing and using a token according to the invention in a distributed service network. Figure 3 shows signalling relates to common e-mail sending. The scenario shown in Figure 3 comprises the following events (top to bottom):

^■ In step 1-1 , the service client gets certain information (usage context (3.3)) about the e-mail content for checksum calculation. ■ In step 1-2, the service client orders a token from the service provider's (2.0) token service (2.3).

^■ In step 1 -3, Based on information on user and current service type, the service provider (2.0) requests the token from the token manufacturer's (1.0) (later abbreviated as "manufacturer") token factory (1.1 ).

^■ In step 1-4, the manufacturer (1.0) creates the data structure of the token and signs it for a service of a specific type (in this case: common e-mail). In step 1-5, the manufacturer (1.0) creates information for the first layer of the token and registers the created token in the database(1.2) for verification purposes.

■ In step 1 -6, the manufacturer^ .0) delivers the created token to the service provider(2.0)

^■ In step 1-7, the service provider (2.0) links the token to the user(3.0) (the user's identity) and to the usage context(3.3),

and creates the information for the token's second and third layers.

■ In step 1-8, the service provider (2.0) delivers the token for the service client(3.1), which delivers the token to the user(3.0) in step 1-9.

■ In step 1-10, the user (3.0) links the token with the content, such as e-mail, and in step 2-1 , sends the content and the token to recipient (3.0).

^■ In step 2-2, the recipient's side service client (3.1) verifies the content, checksum and the token using PKI signatures in the various layers of the token. The service client (3.1) may obtain the public keys currently used for signature verification via the service network. The public keys may be cached for future use. " In step 2-3, the service client (3.1 ) can locate the original service provider from the service locator (4.2), which is part of the world wide service (4.0).

^■ In step 2-4, the world wide service (4.0) resolves original provider of the token and in step 2-5 returns resolved information back to the service client (3.1 ).

■ In step 2-6, the service client (3.1) sends a verification request to the service provider (2.0) which originally sold the token in question. In case the service provider (2.0) accepts the token, the content and token are deemed valid. ■ In step 2-9 the service provider (2.0) return acceptance status back to recipient side service client (3.1).

■ The service client employs a set of rules which are used to classify messages as valid or invalid. Users may partially manage these sets of rules in services offered by the service provider.

Figure 4 is an overall view of a generic scenario involving a token according to the invention.

^■ The manufacturer, denoted by reference numeral (1.0), creates the structure of the token and information on the first layer of the token. The token is created for a certain service

type. The service network architecture supports multiple manufacturers around the world.

■ The service provider (2.0) offers services to the user; user interface to register and control services and service to obtain and verify tokens. The service provider uses the service of the manufacturer (1.0). The service network architecture supports multiple service providers.

^■ The service client (3.1) is the user interface, or an extension (eg plug-in) of a user interface, for obtaining and verifying tokens, and also for executing operations which the user has defined using the user interface offered by the service provider (2.0).

■ The world wide service (4.0) delegates management of subdomains to manufacturers (1.0) and service providers (2.0). The user (3.0) can use a web service to find a local service provider. The service client (3.1 ) uses location service to locate the token's original service provider for verification purposes.

Figure 5 illustrates manufacturing and management of tokens according to the invention. The manufacturer (1.0) provides three principal services. These are firstly a token factory (1.1), which creates token structures and information for the first layer; secondly a token database (1.2), which stores information on all tokens created by the present manufacturer, and also the token's current ownership; and thirdly a verification service (1.3), which verifies a token's validity on request. The service provider (2.0) is the only instance which can provide user services of the manufacturer (1.0). All services visible to the user are provided by the service provider (2.0).

Figure 6 illustrates the operation of a service provider (2.0). The service provider (2.0) is an actual entity which offers services to end users. The Web service (2.1) offers user registration, service registration and service management interface. The Customer Information database (2.2) manages user-specific information and settings. The token service (2.3) is a service used by the service client (3.1) for obtaining and verifying tokens.

An optional marketing service (2.5) publishes user interest groups which can be used to link classified marketing information to specific groups.

Users can register to the specific user interest groups and allow marketing

messages within proscribed limits which are published for this specific interest group. The marketing information publisher cannot see the end user's e-mail address in any point or get any information on the end user's identity. The publisher will only receive information on the number of users who are interested in this specific information. The marketing information database (2.6) (optional, relates to (2.5)) contains marketing information which is published for the interest groups.

Figure 7 illustrates the operation of a service client (3.1). The user (3.0) has an individual identity, which has been registered. The user uses service via the web interface or the service client (3.1). The service client (3.1) can be implemented as a stand-alone program, as a dedicated proxy service or as a plug-in enhancement to an existing program like an e-mail client program. In the example shown, there are separate software components for outbound and inbound e-mail messages, which collectively handle outgoing and incoming messages in case the service is e-mail, and one software component bound to a wallet component in case the service is electronic money. The wallet (3.2) is a component used to store long-living token entities, which are typically tokens having some value, monetary or otherwise. Examples of such long-living tokens include electronic money tokens or unused e-mail tokens ("e-mail stamps"). The usage context (3.3) is a context wherein the token is used. The usage context can indicate an e-mail message, a document or any other electronic entity from which a checksum can be calculated. The checksum can be used to link the usage context and token together as a unique entity which can exist only once. Figure 8 illustrates an e-mail-related scenario with an individual user. In other words, the user uses e-mail like an individual user does and not as an employee of a company or a member of a community. In case of individual users (eg 3.0a and 3.0b), who are unable to get any additional service (such as a company-, community- or ISP-related additional service) to use the e-mail service network, such users must install inbound and outbound message handling service clients (3.1) to their terminal. In the example shown, the user (3.0a), who is sending e-mail, uses a plug-in based service client (3.1) which can be integrated to existing e-mail software. This plug-in manages communication between the user (3.0a) and the service provider (2.0). The recipient user (3.0b) who is receiving e-mail uses a proxy service

implementation of the service client (3.1 ). In this case the service client(3.1 ) may be provided between the mail server (POP, IMAP) and the e-mail client.

Figure 9 illustrates an e-mail-related scenario wherein the user is an employee of a company which acts as the service buyer. In a case wherein individual users (3.0a) and (3.0b) can get company-, community- and/or ISP- related additional service to use the e-mail service network, these entities can install at least an inbound service client (3.1 b) within the e-mail server system. In the example shown, the user (3.0b), who is sending e-mail, uses a plug-in based service client (3.1 a) which can be integrated to existing e-mail software. This plug-in manages communication between the user (3.0a) and the service provider (2.0). The recipient user (3.0b) who is receiving e-mail does not need a service client component. This basically means that message handling set of rules are defined by the company or community.

Figure 10 illustrates a web e-mail scenario. In case the individual users (3.0a) and/or (3.0b) are using web mail, then both outbound and inbound service client(3.1 ) components are installed within the e-mail service. In case the web-based solution supports enhancements into the web interface, outbound service client can be implemented there.

Figure 11 is a signalling diagram illustrating sending of an e-mail message. In step 1 -1 the service client (3.1) gets e-mail message information from an e-mail client. In step 1 -2 the service client (3.1) calculates a checksum over this information. Within steps 1 -3 and 1 -4 the service client (3.1 ) requests token from the service provider (2.0). In step 1 -5 the token is attached into E- mail as a attachement. In step 2-1 E-mail client sends message to E-mail service.

Figure 12 is a signalling diagram illustrating reception of an e-mail message. In step 1 -1 an e-mail message will be read using service client (3.1 ) as a proxy service. In step 1-2 the service client (3.1) verifies the message content and actual token connected with the message. In steps 1 -3, 1 -4 and 1 - 5 the service client (3.1) resolves the location of the actual service provider (2.0) from which the token originated. In steps 2-1 , 2-2, 2-3 and 2-4 the service client (3.1) sends a verification request to the service provider (2.0). Based on verification, token type and set of handling rules, the service client handles an incoming message in step 3-1. Figure 13 is a signalling diagram illustrating communication a token factory (1.1 ) and a service provider (2.0). In step 1 -1 the service provider's

token service (2.3) gets a token request. Based on information on the user (and, optionally, company, community and/or marketing connections), the service provider make decision of the token's type, and in step 1 -2 sends a token request to the manufacturer's token factory (1.1). in step 1 -3 the manufacturer (1.0) creates the token, stores token-related information into token database (1.2) in step 1-4 and delivers the token to the service provider in step 1 -5. In step 1-6 the token has a structure and the three innermost layers, although layers 2 and 3 may be edited by the service provider. The service provider links the token to the user and usage context and completes the token's layers 2 and 3, and creates layer 4. In step 1 -7 the service provider stores information on the token for later verification requested by a token recipient. In step 1-8 the service provider delivers the token to the service client.

In the e-mail examples shown in Figures 8 through 13, it is worth noting that the e-mail programs being used can be entirely conventional, regardless of whether POP or IMAP protocols are being used. It is the distributed service network which uses the inventive token to provide managed spam control. The service client can be implemented as an overlay (plug-in) to the e-mail programs. The invention and its embodiments may be used to prevent or limit e-mail spamming by implementing one or more of the following features. Firstly, only registered user can receive tokens. Secondly, the system may be set up to provide a limited number of "free" tokens per user and period of time. The tokens may be tied to users (as opposed to computers or processes), whereby it is not possible to bypass the upper limit by using multiple computers or multiple processes (service clients) in a single computer. Thirdly, each service client has a unique ID, which means that a client attempting to send "spam" can be blocked from the e-mail service network. Fourthly, users can set up their e-mail service clients to delegate incoming e-mail without tokens to a secondary folder. As soon as a user's all contact persons are using the inventive token-based e-mail, the user may set up the service client or e-mail client to entirely block all e-mail without tokens.

It is readily apparent to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.