WO2014029904A1

WO2014029904A1 - Method and arrangement for a distributed recommendation system

Info

Publication number: WO2014029904A1
Application number: PCT/FI2013/050687
Authority: WO
Inventors: Ville Ollikainen; Raimo Launonen
Original assignee: VTT Technical Research Centre of Finland Ltd
Current assignee: VTT Technical Research Centre of Finland Ltd
Priority date: 2012-08-23
Filing date: 2013-06-20
Publication date: 2014-02-27
Anticipated expiration: 2015-02-23

Description

METHOD AND ARRANGEMENT FOR A DISTRIBUTED RECOMMENDATION SYSTEM

FIELD OF THE INVENTION

Generally the present invention relates to electronic computing devices and corresponding systems of multiple interconnected devices. Particularly, however not exclusively, the present invention pertains to provision of user privacy-preserving recommendations of entities associated with such devices and related synchronization of data.

BACKGROUND

Global amount of information has become 6-fold in past four years according to many estimates. If this trend continues, in 2020 the amount of information doubles every 73 days. Thus finding relevant information, no matter what it concerns, becomes even a bigger challenge in the near future.

There are numerous computational problems requiring a search through a huge number of entries. These problems often require computer programs to perform well also in whenever its environment is

changing. As one approach to overcome these challenges, principles of evolution have inspired computational algorithms with great

efficiency. Many of these types of algorithms are often referred as genetic algorithms .

Concisely stated, a genetic algorithm is a programming technique that mimics biological evolution as a problem-solving strategy.

Furthermore, it is a search technique to find approximate solutions to optimization and search problems. Genetic algorithms are

particularly applicable to solve problems where the space of all potential solutions is too vast for an exhaustive search within limited time. Genetic algorithms have been applied to scientific and engineering problems and they have been widely used in optimization problems. In addition, genetic algorithms have been applied to automatic programming (evolution of computer programs), machine learning (classification, prediction) and modelling processes in economics and immune systems, ecological processes, population genetics, evolution and learning and in social behaviour in social systems .

The method in genetic algorithms is to move from one population of "chromosomes" to a new population by using something to mimic natural selection of evolution together with operators known from genetics, such as crossover and mutation. Each chromosome consists of genes, each of which represent a particular feature of an individual, and its value represents how this feature is expressed in the solution, or chromosome. The selection operators choose the chromosomes in the population that are allowed to reproduce. In average, the chromosomes with better fit produce more offspring than the less fit ones.

Recommendations have become essential in creating additional value for mobile service providers . Contexts play a focal role in

understanding what the users of a mobile service want or need. Thus, understanding user's context and acting based upon it is of the utmost importance for a mobile service to be successful. On a more general approach, it can be said that there are numerous

computational problems, the purpose of which is to predict the behaviour of an entity, and for these problems genetic algorithms are applicable. Also, genetic algorithms can be used for understanding the context of a user and making recommendations thereafter.

The recommendation problem can be defined as estimation of the response of a user for new items, based on historical information stored in the system, and suggesting to this user novel and original items for which the predicted response is high (e.g. Desrosiers, C, Karypis, G.: A comprehensive survey of neighborhood-based

recommendation methods, pp. 107-144. Boston, MA: Springer US, 2011) . Numerous recommending algorithms have been proposed in the

literature, most commonly classified into two basic categories:

content-based and collaborative recommendations . Content-based recommendation methods are based on representing the items with a set of attributes, and using these attributes to find most relevant content for a user. Collaborative recommendation methods, on the other hand, learn from user behaviour. In academic literature (e.g. Lops, P., de Gemmis, M., & Semeraro, G.: Content-based recommender systems: State of the art and trends, pp. 73-105. Boston, MA: Springer US, 2011) the following challenges are often mentioned regarding content-based recommendations:

- need for domain knowledge

- over-specialization (so called serendipity problem)

- user profile creation

- item representation.

Social networking has been taken into account in the literature: For instance a publication (Golbeck, J. : Generating predictive movie recommendations from trust in social networks, pp. 93-104. Springer- Verlag Brelin, Germany) shows how trust and social networks can be exploited to refine the user experience. Another publication (Liu, F., Lee, H. J.: Use of social network information to enhance

collaborative filtering performance. Expert Systems with

Applications, 37(7), pp 4772-4778, 2012) suggests using social networking by emphasizing preferences of those users which, at the same time, are nearest neighbours and belong to the social network of a user.

In the patent application EP 2,249,261 Arpit Mathur presents a recommendation system which is based on social networking. In the presented approach preference information of a user is a necessity. Content item, which is accessed by a member of the same group as the said user, is recommended to the user based on this group relation. This is also known as collaborative filtering.

Content-based filtering is utilized in the patent application WO 2,009,146,489 by Dalgleish Andrew Robert. An item is recommended to a user by using rules, which determine the links between item features and the user's personal features.

Fishman Alex and Chai Chai Crx K. introduce a community-based recommendation engine in the patent application US 2,010,064,325. User receives a content recommendation from her contact. The recommendation engine determines the action to be performed according to the recommendation and on one or more rules, such as trust level of the contact, etc.

Based on similar relevance values as above, such as trust or

similarity between the search user and the entity providing the search results, a recommendation system is presented in the patent application US 2,011,010,366 by Varshavsky Roy et al. The entities may be virtually anything. The relationships between the user and the entity may be created through many different contact mechanisms and may be unidirectional, asymmetric bidirectional, or symmetric bidirectional relationships. The relationships may be different based on topic or other factors.

In the patent application EP 2,207,348 Barbieri Mauro and Pronk Serverius examine the challenges related to insufficient metadata. They present an apparatus for controlling of a recommender system which provides recommendations for a new, unknown domain, or area of interest, by using one or more user profiles from other, known domains. This is achieved by forming or using translations or relations between the known domains and the new domain, and by exploiting these translations or relations to extend the profiles in the known domains into the new domain.

Becker Ralf et al. present an invention (patent application EP

2,242,259) optimized for cross-domain recommendations by enabling the issuing of a recommendation for related predetermined content at a particular appropriate timing. Taken into account in the process are current broadcast content, past and future programs available from a service network and the user's viewing history.

Foster Benjamin et al. describe in the patent application US

2,010,325,011 a method to facilitate generating listing

recommendations to a user of a network-based commerce system. This method identifies a search term that corresponds to a category of items, which includes a plurality of listings hosted by a network- based system. Furthermore, a recommendation query is generated that includes the identified search term. A listing is identified from the plurality of listings as a recommended listing. The identification is based on the recommendation query.

Based on user' s listings representing items for sale on the

marketplace, user profile is formed, in the patent application WO 2,010,114,903 by Kassaei Farhang. The user profile is compared with other similar users who have subscribed to various applications, and the impact those applications have had on the metrics of the similar users is calculated in order to determine what impact the

applications will have on the user in question. The impact, combined with user preferences, is used to suggest appropriate applications to the user.

Murphy Shawn M. et al. present in the patent application US

2,010,325,205 an event recommendation service. Known selection data is compared with media content selected by a user, location data that corresponds to location of the user and event data are used to make recommendations of events the user is likely to attend.

Thus many prior art solutions somewhat regrettably disclose users' personal history or personal preferences in a process of requesting recommendation. Yet, constructing a recommendation system seems to require various tedious preparatory stages of collecting and

processing metadata.

It should be noted that trading personal information has become a significant business especially in loyalty card programs and social media. In these cases there is business value in aggregating user data while the monetary benefit for each user is relatively low. An approach has been proposed that a user could directly sell his profile data. Without middlemen there is at least in theory an opportunity to get most value in return from providing the data.

However, with the conventional approach the user could trade or exchange his profiling data for one entity only once, since the data is expected to remain fairly static.

Further, implementing and adopting typical standalone recommendation systems may generally easily fall into a number of pitfalls that basically relate to the uniqueness and seclusion of each particular solution as whenever new entities such as users, articles for trade or consumption, etc. appear therein, they simply lack the

characteristic profile data and data based on interaction history that is, however, in most such solutions necessary for determining relevant matches between them. In other words, it takes a long time or at least a considerable amount of adaptation for a new entity to be integrated in an isolated solution in terms of meaningful, valid recommendations from the standpoint thereof. Since the vast majority of contemporary recommendation engines are based on data gathered from a single service, this cold start problem is almost inevitable. In these cases, since data is gathered from a single service, the scope lacks a holistic view of overall user preferences.

Building up and dynamically managing recommendation engines and e.g. related sensitive/private information such as user profiles or preferences locally in secure manner with appropriate databases, is not in the core focus of most e-service providers like media houses or e-commerce operators either unless, in return, they can clearly provide better-targeted content to the users. Indeed, inaccurate recommendations may cause more annoyance than obtaining no

recommendations at all. On the contrary, from a user point of view, happy surprises, often referred as serendipity, are not typically provided by most contemporary content-based recommenders.

In contrast to traditional thinking according to which

personalization is based on gathering information of personal preferences and disclosing them to service providers, a safer to use recommendation system relying on token sets may be constructed by following the guidelines set forth herein. The present invention yields an arrangement and distributed method for realizing a recommendation system avoiding non-intended disclosure of personal preferences of individual users.

SUMMARY

The objective is to alleviate at least one or more of the aforesaid drawbacks associated with contemporary recommendation systems , and t facilitate service providers to provide easily adoptable and rapidly adapting, yet accurate, more holistic and serendipity enabled, recommendation services to their clients while being still capable of preserving user privacy and anonymity when needed.

Thereby, in one aspect, a communications network accessible

electronic arrangement, such as one or more servers optionally residing in a cloud computing environment preferably accessible via the Internet, comprises data transfer interface for transferring data, such as token data, between the arrangement and a plurality of external entities

including a number of e-services and e-service user terminals, token repository entity configured to store a local instance, or ^copy' , of a number of, preferably a plurality of, token sets (in theory the repository could be configured to store the instance regarding a single set only) , each stored token set comprising a plurality of identifiable tokens, each stored token set being further associated with an e-service user and related one or more, preferably at least two, e-services of said number of e-services each of which exploiting dedicated instances of the token set, optionally placed in local memories such as local databases of the e-services, wherein each dedicated instance of a token set is adapted based on

interaction between the associated user and an entity, such as a service resource like a content item, available through an e-service of said related one or more e-services, wherein based on a token set associated with the entity the dedicated instance of the token set associated with the user is altered to increasingly resemble the set associated with the entity and based on the dedicated instance of the token set associated with the user the token set associated with the entity is altered to increasingly resemble the former, the e-services preferably utilizing the dedicated instances of the token sets of the users and the entities to determine similarities between such and to provide recommendations of entities to the users utilizing the similarity as a criterion, and synchronization entity configured to synchronize, via the data transfer interface, the local instance of the token sets of said number and the remote dedicated instances of the token sets exploited and adapted by the e-services.

In the above, a dedicated instance of a token set may generally be utilized by one e-service only, or in some embodiments, by multiple services having access thereto.

In one embodiment, the arrangement further comprises a user interface (UI) entity configured to provide a UI to and/or authenticate the users of one or more of the e-services. For example, access control to the services may be effectuated accordingly utilizing a common (shared) authentication mechanism. Suitable content such as ads may be provided to the users via the related UI in response to successful authentication, or 'login' , during the same login session as the authentication procedure also links the user in question with the corresponding stored token set applicable for determination of relevant content from the standpoint of the user as described herein.

In another, either supplementary or alternative, embodiment, the arrangement further comprises a token set management entity

configured to initialize or modify a token set. Alternatively or additionally, at least part of the management entity and related functionality may be hosted by an external entity such as an external authority server or other server arrangement functionally connected to the electronic arrangement in accordance with the present

invention .

The initialization may be based on user-characterizing, preferably user-selected, attributes such as tags characterizing e.g. personal interests optionally relative to a multi-level ontology, such as 'pets' incorporating lower level entities 'cats' and 'dogs' or

'lifestyle' incorporating 'sport' and further 'ski' and 'soccer' . For instance, upon registration a user may construct a profile and/or indicate his/her interests regarding certain attributes utilizing a suitable input method such as tick boxes regarding e.g. liked or disliked topics. The attributes may be represented by nodes of an ontology tree wherein each node is associated with a token set. Thus the selection of an attribute may be implemented as an interaction between the token set of the user and the token set associated with the attribute, whereupon at least the token set of the user is modified to resemble the token set of the attribute, advantageously also vice versa. Alternatively the token set associated with the attribute may originate from other closeby attributes in the

ontology. For instance, the token set of the user may also be configured to interact with each upper level node of the same path in the tree (e.g. cat -> pet -> animal) .

Generally, token sets may be associated with profiles or in

particular, semantic profiles. E.g. user or item or generally entity, profiles may be utilized for the initialization of the related token sets, for instance.

In various embodiments of the present invention, a search engine entity, optionally external to the arrangement and further optionally included in or at least operated by an e-service of said number, may utilize the token sets associated with various attributes and optionally also the ontology tree nodes for conducting alternative or extended searches. In other words, when at least a part of a token set associated with e.g. a user is provided for retrieving a

recommendation, the search engine entity may conduct, besides e.g. a direct token set based search, indirect searches exploiting the attributes or tags associated with the provided token set. These indirect searches of finding e.g. most resembling token sets

associated with attributes can advantageously produce an intermediate result of an attribute list related to the provided token set, and possibly initiate further attribute (keyword) based recommendations. Thus the token set based search may also integrate different types of recommendation engines. An entity hosting the search entity and the arrangement may in some embodiments establish a related system. In a further, either supplementary or alternative, embodiment, the arrangement is configured to trigger a synchronization procedure in response to at least one triggering condition selected from the group consisting of: synchronization schedule, receipt of triggering signal, receipt of synchronization request, receipt of

synchronization request from an e-service, receipt of synchronization request from a user terminal, user authentication, and user log out.

In a further, either supplementary or alternative, embodiment, the arrangement is configured to utilize a predetermined synchronization mechanism, ^tool' , or scheme for the purpose. For example, Subversion ™ (SVN) or related solution could be applied.

Preferably, the arrangement incorporates a conflict resolving logic for recovering from potential synchronization conflicts that might arise e.g. due to parallel, contradictory changes made to a user's token set since the last synchronization by multiple e-services. The logic could, for example, abandon the changes made by all but one e- service according to predetermined rules.

In a further, either supplementary or alternative embodiment, one or more e-services of said number of e-services incorporate (are executed on) at least one server. The arrangement may be configured to communicate with such at least one server via the communications network possibly including a number of intermediate elements such as bridges, switches, routers or other network elements.

In a further, either supplementary or alternative, embodiment the entity available through an e-service of said related one or more services includes an information element such as a media article accessible via the service.

In a further, either supplementary or alternative, embodiment, the arrangement is configured to execute the items of

-obtaining information regarding a plurality of token sets associated with a corresponding plurality of entities, such as advertisements or links to different services,

-determining an indication of similarity between a token set

associated with a user and each set in said plurality of token sets, and -based on the determined indications of similarity, establishing a recommendation for the user regarding a sub-set of one or more entities from said plurality of entities.

The arrangement may be configured to indicate the recommended entity/entities to the user via the UI, optionally web browser accessible UI, thereof.

In some embodiments, the entity in said plurality may refer to a network accessible service, advantageously a Web site or other online service, and optionally further with a unique uniform resource identifier (URI) .

In some embodiments, the e-service user terminals may include at least one communications-enabled element selected from the group consisting of: a cellular phone, a smartphone, a tablet, a desktop computer, a PDA (personal digital assistant) , a wristop computer, and a laptop computer. The terminal may be equipped with client software such as proprietary application and/or web browser for accessing the arrangement and optionally the e-services.

In some embodiments, each token and/or token set may be associated with at least one indication selected from the group consisting of: indication of how many times it has been updated (more advantageous for a token set) , timestamp or other temporal indication of creation, validity period, expiry time, expiration date, a weight factor (more advantageous for single tokens), geolocation, timestamp or other, potentially temporal indication of last access, and timestamp or other temporal indication of last update, wherein the at least one indication is preferably utilized in the adaptation. The arrangement may be configured to execute such associations via the management entity thereof, for instance. Alternatively or additionally, an external server arrangement such as the aforementioned authority server arrangement may manage, store and/or distribute (announce) the associations as to be described in further detail hereinlater. Any one or more of the indications may be optionally included in or otherwise integrated with the tokens such that they follow the tokens automatically when tokens are allocated or exchanged during the token set adaptation procedure, for instance, i.e. they do not have to be transferred or signaled using a separate, dedicated procedure.

Alternatively, at least part of the indications could be implemented as separate or separable information elements that have to be linked with the tokens by the token id's for example. The indications could be then provided in dedicated data structure (s) such as lists identifying a number of tokens and related indications.

In some embodiments, the geolocation data, or in overall,

geographical data associated with a token may indicate the desired geographical scope thereof such that the token is not spread outside the scope (e.g. city, country, continent, or simply coordinate- defined area) . Depending on the embodiment, such geographically limited token may be deleted from the concerned set when the

associated user or other entity moves outside the allowed region according to available positioning data, for example, i.e. the geographical token expires. Additionally or alternatively, such token may be omitted from token set adaptation procedures when at least one of the concerned interaction parties is located outside the region.

In the above, validity period, expiry time, expiration date or geolocation may generally relate to the whole token set or, more likely, be token-specific (and defined only to certain token (s)) . Upon expiration, the concerned token (s) may be deleted from the set according to predetermined logic. Alternatively, expired tokens remain in the set but are neglected regarding a number of token- related operations such as token set adaptation. Optionally, during aging a temporally limited (numeric) token may reduce or increase in value, which may be indicated by the weight factor, for instance.

In some embodiments, it may be advantageous for the adaptation process to provide tokens to other entities using a random but weighted selection, more recent tokens having a priority. As a result, users interacting with same entities in within a short period of time are likely to exchange same tokens with each other. In one embodiment, the tokens may be sorted internally in the order in which they have been received, making this option more feasible.

In various embodiments of the present invention, the tokens may advantageously be or comprise integers, advantageously 32 bits each, whereas the token sets may contain hundreds, if not thousands of tokens .

Different electronic devices, or "computing units", such as terminals or servers are preferably capable of accessing the token sets associated with their owners such as device users: a first computing unit has a means to access the token set(s) associated with the first entity, a second computing unit has a means to access the token set(s) associated with the second entity, and so on.

Since one physical computing unit, for example a network service, may maintain a plurality of token sets associated with different

entities, we hereinafter refer processing a token set associated with a unique entity as a corresponding token process: the token process associated with the first entity is referred as the first token process, the token process associated with the second entity as the second token process, and so on. It should be further noted that although we for clarity refer to a "universal resource locator (URL) of a token process", it may be implemented as a combination of universal resource locator of the computing unit and applicable identification of the token process within the computing unit, for instance .

In various embodiments, a terminal device of a user associated with a first token process (and thus first token set) has access to a means for resolving universal resource locator (URL) of a second token process (and second token set) . These means may utilize as input either a unique identifier, such as universal resource identifier, of the service, or other data optionally transferred to the terminal from equipment associated with the service.

In another aspect, a method to be performed by a communications network accessible electronic arrangement, such as one or more servers optionally residing in a cloud computing environment

preferably accessible via the Internet, comprises storing a local instance, or "copy", of a number of token sets, each stored token set comprising a plurality of identifiable tokens, each stored token set being further associated with an e-service user and related one or more, preferably at least two, e-services each of which exploiting dedicated instances of the token set, optionally placed in local memories such as local databases of the e-services, wherein each dedicated instance of a token set is adapted based on interaction between the associated user and an entity, such as service resource, available through an e-service of said related one or more e-services, wherein based on a token set associated with the entity the dedicated instance of the token set associated with the user is altered to increasingly resemble the set associated with the entity and based on the dedicated instance of the token set

associated with the user the token set associated with the entity is altered to increasingly resemble the former, the e-services

preferably utilizing the dedicated instances of the token sets of the users and of the entities to determine similarities between such and to provide recommendations of entities to the users utilizing the similarity as criterion, synchronizing the local instance of at least one token set of said number and the remote dedicated instances of the at least one token set exploited by e-services, wherein synchronizing incorporates transferring data between the arrangement and the e-services.

In one embodiment, the method may comprise receiving a token set associated with a user from an external entity such as a user terminal for storage and optionally distribution to one or more e- services. Alternatively or additionally, the method may comprise modifying a token set or initializing/establishing a token set for the user according to predetermined logic and e.g. user preference information preferably defined by the user as explained herein. In another embodiment, the synchronization takes place in response to fulfillment of necessary triggering condition (s) that may be

schedule-based or event-based, for example.

Generally, the various considerations presented herein concerning the different embodiments of the arrangement may be flexibly applied to the embodiments of the method mutatis mutandis and vice versa, as being appreciated by a person skilled in the art.

A computer program (product) comprising code means adapted, when run on a computer, to execute an embodiment of the suggested method (items) may be provided. Accordingly, a carrier medium such as a non- transitory storage medium having the computer program embodied therein may be provided.

The utility of the present invention arises from a plurality of issues depending on each particular embodiment in question.

The suggested type of de-centralized storage and synchronization of token sets the copies of which are still locally exploited by multiple e-services provides an enhanced user experience in contrast to traditional by nature centralized (although they may be

computationally distributed) prior art solutions. The e-services have a local version of a token set associated with a user, which enables quick utilization (retrieval, adaptation, use in providing

recommendations, storing, etc.) in contrast to solutions wherein the token sets have to be always fetched from a central repository for use in connection with each related action. Still the arrangement suggested herein provides a secure back-up and synchronization repository for the user-associated token sets.

In some embodiments, a user may conveniently access an embodiment of the arrangement of the present invention by a terminal device for a single authentication procedure regarding one or several e-services that apply the arrangement as a token set repository for their users and as a synchronization tool for the same. The e-services may then apply both the token set associated with the user and token sets associated with various service items for recommendation and

adaptation purposes. Also, since a token may have an expiration time, the tokens in the token sets, and thereby the sets themselves, as well as individual tokens in general may get automatically renewed after a while. This makes it possible for a user to dynamically provide or trade his token set data to an entity multiple times when desired instead of fearing that a once provided set will remain valid or usable by the entity .

Further, as described earlier, different ontologies may be cleverly associated with the token set based infrastructure so that both the ontologies or related elements, e.g. semantic user profiles defined using the ontology, and token sets may be updated by the other and/or converted or mapped into the other. For example, third party

recommendation technologies and systems, e.g. search engines, may be integrated with the token based ecosystem.

Various recommendations may be flexibly generated e.g. from a user to an item (e.g. media recommendation), from a user to another user (e.g. social networking), from an item to another item (e.g. "see also" in internet shopping) and from an item to a user (e.g.

advertising), for instance. The users' privacy is preserved while they interact with other entities and exchange characteristic data, i.e. token data, to dynamically update such based on the

interactions, which subsequently enables providing recommendations through comparisons of characteristic data of different entities and finding common features such as same tokens/token values therein. Indeed, somewhat similar to genetic algorithms, the interacting entities adopt and radiate characteristic data, which is cleverly harnessed in analyzing the potential match or linkage between them. The suggested solution is by nature technically scalable according to the available hardware and software resources, and it adapts to different use cases with ease.

The terms "first" and "second" do not denote herein any particular priority or order. Instead, they are used to distinguish one entity such as a physical or logical element from another entity. The expression "a number of" refers herein to any positive integer starting from one (1), e.g. to one, two, or three.

The expression "a plurality of" refers herein to any positive integer starting from two (2), e.g. to two, three, or four.

The term "e-service" refers herein to any electronic service or application that may be accessed by a number of users e.g. via a communications network. The e-service may indeed be accessed using information and communication technology, such as but not necessarily the Internet and/or other network (s) or communication medium. The e- service may include or be based on a number of different aspects of (e-) commerce, online or web services in general, data storage service, data access service, data creation or modification service, computing or processing service, data transfer service, news or article service, communication service, social networking service, publication database, discussion forum, data indexing or search tool, or advertising medium among various other options.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure la illustrates one main concept and simultaneously enabler of the present invention with a number of units associated with token sets interacting with each other.

Figure lb incorporates a high-level flow chart of an embodiment of token adaptation and utilization in general for establishing

recommendations, and a related block diagram.

Figure 2 illustrates the first embodiment of token adaptation and related communication, with updating existing data sets associated with interacting units .

Figure 3 illustrates a scenario incorporating data transfer and signaling in connection with interactions between a user, a web site and other related entities, the scenario further including token set adaptation . Figure 4 illustrates a merely exemplary data graph for creating new user account to the system.

Figure 5 illustrates a merely exemplary data graph for information exchange comprising token data exchange.

Figure 6 illustrates a concept of creating different token set for different contexts following a genetic metaphor.

Figure 7 illustrates the context of an embodiment of an arrangement in accordance with the present invention.

Figure 8 is a flow diagram of a method in accordance with an

embodiment of the present invention.

DETAILED DESCRIPTION

One idea behind the utilization of tokens and token sets could be analyzed in the light of exchanging banknotes with individual serial numbers: If we repeatedly exchanged banknotes with other people we met and over a cashier desk wherever we went, and wrote down a list containing the serial numbers of the banknotes which have been in our possession, our friends and other people with similar habits, as well as places we visit, would have a tendency of having the same serial numbers in their lists as we have had. This underlying idea has been developed further in the present invention and embodied technically.

Next, a method for arranging exchange of information between a computing unit associated with a first entity, hereinafter referred as the first computing unit, and a computing unit associated with at least one second entity, hereinafter referred as the second computing unit, is discussed.

One shall notice that the computing units described in this text may in some embodiments be considered as virtual, preferably residing either in a cloud service or another platform and acting as computing unit for a plurality of entities. In practice, it may be advantageous to include an identification of the respective entity to the universal resource locator of a computing unit and have the same internet domain to carry out functionality of a number of computing units . Figure la illustrates a concept of having a number of entities 12...16 belonging to a group 11. These entities may be users, other people, real or virtual places, pieces of media content, database entries: any real or virtual entities that can be involved in a real or virtual interaction 18 can be considered an entity. For instance, in the exemplary description in Figure 3 User 13 and Web (site) service 12 and/or resources accessible via it may be seen as ^entities' .

An example of such an interaction is User #1 16 visiting a Gym 15 which occurrence is interpreted as an interaction between User #1 and the Gym 15. Another example could be Users #2 13 and #3 14

simultaneously visiting the same Web service 12, in which case there may not be only interactions between these Users 13, 14 and the Web site service, but also between these Users 13, 14. Each entity is preferably associated with at least one token set 17. In the beginning a new entity may be provided with none or only a small number of tokens, even just one or few of them, containing e.g. random values. However, if the initialization of a token set

associated e.g. with a user is at least partly based on preferably user-selectable profile such as user-selected attributes, such information may be converted into a number of predetermined tokens in the established set as explained herein elsewhere in more detail. Nevertheless, the token sets are updated in an interaction certain embodiments of which are described in further detail hereinbelow. Preferably, the tokens are identifiable by a number and/or some other identification-enabling data. However, even the randomly generated tokens do not necessarily have to be universally unique in a sense that each token initially allocated to some entity differs from all other tokens allocated to any other entity as long as the proportion of non-unique tokens is minuscule. Also in that sense, the tokens may be non-unique. Adaptation or recommendation noise potentially arising from similar tokens initially independently assigned to different entities is considered practically negligible in most foreseen use scenarios .

Moving on to the disclosure of some embodiments for updating token sets with reference to Figure 2, the interaction 18 generates an Information exchange 28 between token sets associated with the interacting entities, each of the interacting entities associated with a computing unit carrying out the actual information exchange, referred hereinafter as interacting computing units.

Unquestionably, it is of importance to provide some means to measure similarity between two token sets. As mentioned hereinbefore, it may be advantageous to use integers as tokens, and the number of tokes may advantageously be hundreds, if not thousands. One feasible option is to base distance measurement on the well-known Jaccard distance.

Figure lb is a high-level flow diagram of an embodiment of token utilization and adaptation in the general context of the present invention. At start-up 120, the necessary hardware and software, such as terminal device (s) and/or network element (s) like server (s), are acquired and configured.

At 122, the token set(s) associated with a first entity, such as a user of a terminal device, are obtained including a first token set, i.e. information defining the token set(s) at least in a level of detail which suffices for the execution of the remaining method items as represented herein is obtained. Depending on the device or devices executing the method, such as a terminal and/or a server, device (s) may themselves maintain, or "host", (the information defining) token set(s) or alternatively, at least one functionally connectable remote entity, such as a Web service operated by at least one server, may be configured to store (the information defining) the set(s) for retrieval and use by others as described hereinlater in further detail. Optionally, an embodiment of the communications network accessible electronic arrangement as discussed herein may be utilized for authenticating the first entity, whereupon a proper token set may be retrieved from a predetermined storage facility in response to the authentication data. In addition, the arrangement may be utilized for storing token sets and/or synchronizing local instances of the same token set at a plurality of locations. Different utilities provided by the arrangement are described in more detail relative to Figures 7 and 9.

The token set(s) associated with the first entity are needed both in the adaptation procedure 124 and determination of recommendations 140 as disclosed herein. Nevertheless, one shall realize that the adaptation 124 and determination of recommendations 140 are separable features and may be executed also independently, which is indicated in the figure by the broken vertical lines.

Item 124 refers to the aforesaid adaption procedure performed in connection with interaction taking place between the first entity and another entity, such as a network service or a resource optionally accessible therethrough. Herein, a resource may generally refer to anything that has identity such as an electronic document, an image, a Web site or page, a service, or a device. Triggered by the interaction, based on a second token set associated with the second entity the first token set is altered to increasingly resemble, or "reflect", the second set. Based on the first token set the second token set is preferably also altered to increasingly resemble the first token set. In case there are separate physical entities dealing with adaptation (alteration) of the first and second token sets, data transfer between such elements may be required. To alter the first token set, the corresponding executing entity, i.e. logically a first computing unit that may be physically implemented at a terminal or server, for instance, shall obtain at least part of the second token set. To alter the second token set, the corresponding executing entity, logically a second computing unit that may be physically implemented at the same or another terminal or server, shall obtain at least part of the first token set. In practice, a computing unit may request a certain amount of tokens from the other computing unit, both optimizing the amount of data transferred and at the same time giving the sending computing unit the final decision, how many tokens are given out to a certain other computing unit, the amount being based on e.g. privacy, security and performance optimization. Data transfer between physical entities typically implies coordinated data transmission (sender) and reception (recipient) in any feasible form over wired and/or wireless medium. In some embodiments, situations may occur where only one token set is adapted based on interaction between the first and second entities. Yet, token set adaptation may take place in response to an occurrence of an event other than the interaction .

Items 126-130 refer to the features of establishing recommendations of other entities to the first entity from the standpoint of the first token set.

At 126, a plurality of token sets associated with a corresponding plurality of entities is obtained. Instead of obtaining information completely defining the token sets in said plurality, at least information enabling the subsequent similarity analysis shall be alternatively obtained. Such, potentially reduced or derived, information may omit a number of unnecessary (in the light of the similarity assessment) elements of the full token set definitions.

Indeed, at 128, an indication of similarity between the first token set and each set in said plurality of token set is determined based on information on the first token set and the sets in the plurality. At 130, based on the determined indications of similarity, a

recommendation regarding a sub-set of one or more entities from said plurality of entities is established. For example, a number of entities that are considered similar to the first entity in view of the associated token sets according to the utilized decision-making logic may be included in the sub-set. In some embodiments, a

predetermined number of most similar entities may be included in the sub-set. Alternatively, all entities fulfilling the criterion or criteria defined by the logic may be included, for instance. At 132, the method execution is ended.

As the persons skilled m the art will understand, the execution various method items regarding the adaptation or recommendation procedures may be flexibly repeated upon need. Yet, several adaptation rounds 124 may occur in a row without intermediate recommendation rounds 140, and vice versa. More detailed examples of adaptation, related interaction, and provision of recommendations are set forth hereinafter.

The sketch at 142 illustrates a high-level block diagram of an embodiment of an electronic device, or "computer", for executing the method or at least selected items thereof. A computer program product embodied on a carrier medium, such as an optical disc or a memory card, comprising instructions (software 148) to carry out method items described herein, when run on a computer, may be provided. A number of different functional or logical entities may be formed by the software or other control logic and the underlying hardware. For example, a data transfer entity may take care of token data transfer and other communication, an adaptation entity may perform adaptation, and a recommendation entity may execute token set comparisons and determine recommendations based thereon. The computer, which may be included in (or be considered to be formed by) a terminal or a network server, for example, shall thus contain the necessary processing element (s) 146, such as microprocessor (s) , signal

processor (s) and/or microcontroller ( s ) , and memory element (s) 152 such as memory chip(s) to process and store the instructions (and various other data) , respectively. Yet, the computer shall include a communications interface 144 such as a wired or wireless transceiver for communicating with external entities, such as network (s) and/or terminal (s), and exchanging e.g. token data. Cellular, LAN (Local Area Network, e.g. Ethernet) or WLAN (Wireless LAN) communication may be enabled among other options. A user interface 150 may be provided for user-device interaction, i.e. receiving control input from the user and/or providing output to the user. Several such devices 142 may be functionally connected to establish a desired functional entity .

Figure 2 illustrates one merely exemplary concept on how the token sets 17, 29 associated with each interacting unit 21, 22 are updated as a result of the interaction 18. The update of a token set is based on the Information exchange 28, particularly receiving at least part of another token set, the set associated with the other interacting entity .

In this embodiment a token set 24 associated with the first

interacting unit 21 may be updated simply by copying there a number of tokens from the token set 25 associated with the second

interacting unit 22. The actual number of tokens copied may be determined as a percentage 27 indicating how large the intended change to the token set is (whereas in contrast, percentage 26 indicates the portion of the original token set 24 to remain

unaltered during the interaction 18) : Advantageously, the percentage 27 indicates the number of tokens copied relative to the total amount of tokens in the set. Advantageously at least one token is copied. A suitable percentage may be from a few percent up to 20% or so, and it can be experimented for optimal results by a person skilled in the art .

Choosing the tokens to be copied from the other token set may be based on a random selection.

From a practical point of view, it may be advantageous to associate a value for each token set indicating how many times it has been updated 210. Further advantages may be obtained if timestamps of creation 211, last access 212 and/or last update 213 are associated with the token set.

For instance, the percentage may be made regressive by reducing the percentage 27 in subsequent updates. For instance the following equation provides regressive influence: p_k = Po / (N+l) where p_k is the regressive percentage, p₀ the maximum percentage and N 210 the amount of previous updates to the token set.

As a result the updated token sets 214, 215 are likely to have smaller distance between each other they originally 24, 25 had. A maximum number of tokens may be defined as well, causing repeating update processes to eventually fill up the token set to the maximum. In this case space may be released by removing existing tokens randomly in order to make space for the update. Instead of deleting tokens in random, also deleting one token from a token pair which has closest resemblance in the token set, is also feasible although more computationally intensive. As an example of third method the token pair may be replaced by a single token which has an average value of the deleted tokens .

One should keep in mind that full disclosure of the other token set is not necessarily required for update, thus a partial disclosure may also be performed. In this case only the required amount of tokens may be requested from the other token set in the Information exchange 28.

After a number or updates, the token sets associated with the entities which have been interacting with each other are likely to increasingly resemble each other; that is, having more tokens in common and thus becoming increasingly similar to each other when measured with the chosen metric. This is one reason why the present invention enables constructing an efficient recommendation system: Recommendations for a particular unit may be carried out by searching for greatest similarity between a token set associated with the particular entity, hereinafter referred to as "primary token set", and the token sets of all other relevant entities, hereinafter referred as "searchable token sets". Those entities which have searchable token sets with smallest distance to the primary token set are the ones to be recommended in most embodiments.

In practice, such procedure may contain items of

a) requesting searchable token sets associated with different

entities 11,

b) receiving searchable token sets for comparison,

c) calculating distances between the primary token set and each of the received searchable token sets

d) memorizing the smallest distances and the entities associated with them, and e) returning the list of entities associated with the token sets with smallest distances to the primary token set.

Also, the following procedure may be performed

a) requesting searchable token sets associated with different

entities 11 while sending at least part of the primary token set to the second computing unit(s),

b) having the second computing units to calculate distances

between the primary token set and each of the searchable token sets accessible by the second computing unit

c) receiving identifiers, advantageously temporary identifiers of entities associated with the token sets with smallest distances from the second computing unit(s)

d) memorizing the smallest distances and the identifiers

associated with them,

e) requesting entities associated with token sets of the smallest distances from second computing units using the identifiers, and

f) returning the list of entities associated with the token sets with smallest distances to the primary token set.

The sub-set, or "list", thus generally comprises a lower number of entities than the initial plurality of searchable sets. Although trivial for a person skilled in the art, it is perhaps in order to clarify the above mentioned term "relevant" : If the invention is used to enable media content recommendation, only the token sets related to pieces of media content may be relevant as searchable token sets (user-to-item) . If trying to find companion when visiting a bar, only the token sets associated with those persons visiting the same bar at that moment may be relevant (user- to-user) . If searching for "see also" items in a Web store, only the token sets associated with items for sale in the same store may be relevant (item-to-item) .

In the "see also" case the primary token set may not necessarily be the token set associated with the person browsing the Web store, but with the item currently presented on the screen. When searching for the most suitable people for an advertisement (item-to-user) one feasible approach would be having a banner advertisement on a Web page. An interaction may be engaged whenever the banner is clicked, for instance. To whom the particular banner advertisement is displayed at all may be a result from using the token set associated with the advertisement as the primary token set and the token sets associated with all active users as searchable token sets.

Whenever there are more than one unit involved in an interaction, such as a Web site service #2 12, user #2 13 and user #3 14 in Figure la, the interaction can be advantageously divided into individual interactions between each pair of interacting entities: In this example one interaction could be between the Web site service #2 and user #2, one between the Web site service #2 and user #3 and one between user #2 and user #3. Another approach could be merging a temporary token set, combining tokens from each set and use the merged token set as the other set 25 in the information exchange 28 in Figure 2 for each interacting entity.

From privacy point of view, some entities or token sets may be defined as "private" whereas the rest might be referred as "public" . Whenever it comes to a private entity or token set, it is

advantageous not to disclose personal history. The token sets described above fulfill this requirement, because there is

advantageously no direct mapping between the tokens and interactions in the past; the previously mentioned initialization of the token sets 17 with some random values serves privacy in this respect.

Since a token set is at least partially disclosed in the Information exchange 28, the other interacting entity may adversely attempt to measure similarity between it and a plurality of known other token sets. Small distance between different sets, however, can't be determined as a direct interaction with a certain entity, since the tokens may have been received from just any token set. Since the user with the interacting token set cannot be held responsible for actions of other entities, which may well have had interaction with the unit associated with the known token set, the invention provides a fair degree of deniability.

Switching over to a specific case of having a user of a terminal device as the first entity and a Web site service potentially hosted by one or more servers as the second entity, Fig. 3 illustrates how the related system might operate in practice:

Assuming that the user 13 already is already associated with a token set, it becomes a practical question, how the same set will be accessed on each terminal device 32 the user is using. One feasible alternative would be having a user database 31 which can be accessed over the Internet, containing at least one user ID and the following information related to each user ID, hereinafter referred as processing credentials: a. a Uniform Resource Locator (URL) of the first computing unit 34 specific for the user ID or the token process associated with the user, that is, the first token process, and

b. authorization credentials which permit processing the token sets associated with the user. Authorization credentials may be in practice a message which is digitally signed using

certificates issued by a token process authorization service 42 as described below.

When the user 13 begins to use a terminal or a browser the first time, she can request 301 processing credentials from the user database 31 and after a successful response 302 store this piece of information locally to the terminal device 32 for subsequent use. It may not be worth mentioning, but the user database should have appropriate access control for authenticating the user, using best practices well known in prior art.

When accessing 303 content on a Web site service 12, the access may be based on some Unified Resource Identifier (URI) which by

definition may be a URL or any other unique identifier in a well specified format. From this point on, there are e.g. the following two advantageous alternatives : The content 304 received from the Web the service may contain explicit information, such as an HTML head element, which contains information of a URL 306 of the token process in the second computing unit 35 associated with the Web site service 12, that is, the second token process. Eventually, this would be efficient way to go. As a concept, the URL 306 is calculated from the content 304 by a token process address resolver 36. The input data 305 for the token process address resolver is in this concept the content 304.

In the absence of said explicit information, the URI is sent 305 to token process address resolver 36 which has an access to a Look-up table 37 containing means to convert the URI 307 to the URL 306 of the second token process.

It is important to note that whenever we refer to a URL of a token process in a computing unit it refers also to an identification of the entity in question. The identification in this terminology and as one potential embodiment is a parameter or other predetermined part of the locator (e.g.

https :/ /upcv . domain . fi/tokens?id=0x45c78el 03al3029a) . As another embodiment the locator, such as network address, may be associated with several entities, and the identification of the entity exists in the data, not in the locator (e.g. https://upcv.domain.fi/tokens, wherein the addressed resource such as (XML) document may include the ID of the entity) . However, for clarity, in this description whenever we refer to URL of a token process in a computing unit, we also refer to identification of the entity as being part of the URL and leave for a person skilled in the art the liberty to implement the

identification either as a part of the locator or as a part of the data .

In practice, the means for resolving the URL of the second token process may comprise a Look-up table 37 which translates the uniform resource identifier 307 of the Web site service to uniform resource locator 308 of the token process in the second computing unit 35. Alternatively, the content 304 received from the Web site service may be parsed in order to search for a specific tag explicitly defining the uniform resource locator of the second computing unit 35.

Logically, searching the specific tag may take place in the token process address resolver 36, now getting at least portion of the content 304 as the input data 305.

In practice, it would be beneficial to first search for the specific tag, and if it is not found, then make a request to the Look-up table 37 based on the URI 307. It should be noted that the token process address resolver 36 may be integrated to the terminal device 32 itself, even as a browser extension, or alternatively be for instance a service on the network. Obviously, it is advantageous to implement the Look-up table 37 as a network service shared by several users, having a centralized update.

In some embodiments, it may be advantageous, if the first computing unit 34 carries out the Information exchange 28 as a network service, but of course the implementation may also be such that the terminal device 32 contains the first computing unit.

After the second token process URL 306 has been resolved, the information exchange can be requested from the first computing unit 34, sending information containing at least the piece of information of the second token process URL 306 as a part of the request 309.

As a response to the request, the first computing unit 34 carries out the Information exchange 28 by sending 311 at least part of the tokens 24 associated with the user 13 to the second computing unit 35. Mutually, the second computing unit sends 312 in the Information exchange 28 at least part of the tokens 25 associated with the Web site service 12. After receiving tokens from the other computing unit, the token sets 24, 25 are updated as described earlier and illustrated in Figure 2. Signal 310 represents either acknowledgement of the executed information exchange procedure or alternatively an acknowledgement of receiving the tokens 311 for non-real-time processing . Some exemplary details of how a new entity, in this example being the user 13, might be registered in the system are illustrated in Figure 4: In the illustration, the user is accessing Web site service 12 with a Web browser within the user terminal 32, and the browser does not have access to locally stored processing credentials.

In this example the user terminal is first requesting 301 processing credentials from the user database 31. At this point the user is advantageously authenticated by a trusted third party. From a practical point of view the process may contain two phases, as a query of user existence in the user database does not necessarily need strong authentication, if any, but retrieving processing credentials from there does.

The system contains advantageously a token process authorization service 42 which may utilize existing public key infrastructure (PKI) . The revocation mechanisms in PKI may become useful in cases when a user tries to use the system adversely.

Now, assuming that the user does not exist in the database, a user registration process is in order. As a concept which of course may be designed in numerous way by a person skilled in the art, the new user requests certificates 402 from a token process authorization service 42 using her terminal device 32. At this point a strong

authentication according to best practices, not illustrated in this figure, is advantageous. As a certificate authority in PKI, the token process authorization service issues and returns (403) certificates to the user terminal 32.

With the certificates, the user terminal 32 requests 404 an account for a new token process in the first computing unit 34 using a certificate issued by the token process authorization service 42. Whenever we refer to "user certificates", it advantageously contains also the user identification used in requesting the certificates 402. The first computing unit advantageously validates 405 the certificate from the token process authorization service 42. It should be noted that whenever validating a certificate from the token process authorization service, at least all the data which contains user identification should be advantageously encrypted by using public key of the token process authorization service 42, if there is any chance that the identification would be seen by an adverse third party. In these cases the data containing user

identification should advantageously further salted by a random value in order to have the ciphertext containing user identification different each time. These methods are well known in prior art: As a simple implementation, the plaintext user identification could AES (Advanced Encryption Standard) encoded using PCBC mode (propagating cipher block chaining) and a random value in the first encryption stage (usually referred as Ml) . The key may be a random value which will subsequently be delivered together with the ciphertext, after being encrypted by a public key of the token process authorization service. When the token process authorization service receives the ciphertext and the encoded key, it first decodes the key using its private key, decodes PCBC message, removes the random value and validates the plaintext credentials. In other words, instead of sending an "User certificate"

E_K(rnd|User certificate) +E_KA (K) would be sent, E_K being the e.g. AES-PCBC encryption using K random key, and E_RA the public key encryption using KA public key of the Token process authorization service.

Between trusted parties and secure communications this encryption may not be necessary, although always illustrated in Figure 4 and Figure 5; this consideration who trust each other, and to which extent, can be left to a person skilled in the art of information security, designing the actual implementation.

By doing this, the anonymity of the user remains at all stages between the credential encryption and the token process authorization service 42. Furthermore, because of the random value prefix there will not be too many, if any, similar encoded credentials trespassing the network originating from a single user: Without the random value the same user would possibly send similar credentials, making it possible to track the individual user.

So, after the user was successfully acknowledged 406 by the token process authorization service 42, the first computing unit sends an acknowledgement 407 to the User terminal 32, containing the first token process URL for processing the tokens of the user. The URL may advantageously contain a fixed locator of the first computing unit and user identification.

It would be advantageous, if the second computing unit could be able to receive user identifications salted by a random value and

encrypted by its public key the same way described above for the token process authorization service 42. This would not be necessary for accessing Web site or other public services, since, as will be described later, a public service does not have to be aware of the identity of the user; it would rather be for the Information exchange (28) between individual users who may not want to disclose any of their identity between each other.

In our example of a new user the process continues by registering the new user to the user database 31 : The user terminal 32 sends request for the registration 408 accompanied with authenticated user ID (user authentication not illustrated here, either, since it's prior art), issued certificates and the first token process URL.

It is advantageous for the user database to validate 409, 410 User certificate from the token process authorization service 42, and validate that the User token process exists 411, 412. At its simplest the request may be signed using the private key in the Issued certificates .

It should perhaps be noted that since the user database 31 will contain the private key of the Issued certificates, it should in this arrangement be a trusted party for the user 13. Instead of a physical unit, the user database could also be an encrypted repository, the key being available to the user terminal 32 from another trusted source; In this case the functionality of the user database would be divided between several units. Therefore, the user database can also be considered rather as a virtual, not physical unit.

It should be also noted that the user database 31 may also be provided by the same trusted party as the first computing unit 34.

Following the previous example and regarding the existing user(s), in the scenario illustrated in Figure 5 the user 13 has an entry in the user database 31.

In this example, too, the user terminal is first requesting 301 processing credentials from the user database 31, with appropriate authorization. Unlike in the example in Figure 4, in this example the user database replies 501 with an acknowledgement containing the first token process URL and at least the part of User certificates which enable signing an authorization for processing tokens on behalf of the user 13.

Whenever the user accesses a Web site service 12, the Unified

Resource Identifier (URI) is sent 305 to the token process address resolver 36 as described earlier, and the token process address resolver responds with the second token process URL 306. As mentioned the URI may either be explicit or exist in the content received from the Web site service.

There is a chance that the no token process exists 502 in the Look-up table 37. One approach for resolving this is creating a new token process for the Web site service and associating the URI of the Web site service with the URL of the newly created token process in the Second computing unit. If performing this process whenever necessary, there may never be a response that the token process does not exist 505.

So, let's continue our example with the normal case that the token process for the Web site service exists 306: The request for token exchange is sent 309 to the first computing unit 34, the request containing the second token process URL 306 associated with the Web site service 12 as well as the user certificate for authorizing the token exchange in the first computing unit. The request at its simplest may be just a message signed with the private key issued in the certificates 403.

Whenever there may be a chance for misuse, the first computing unit 34 advantageously validates the certification 503, 504 before requesting token processing 505 from the second computing unit 35. I this request 505 the first computing unit sends its own certificate (signed request, as described earlier) to the second computing unit, which in turn validates 507 the certificate from the token process authorization service 42. After successful validation, the second computing unit sends its own certificate to the first computing unit 508 which validates it from the token process authorization service.

A person skilled in the art may advantageously use SSL/TLS (Secure Sockets Layer, Transport Layer Security) protocol for any

authorization between the first 34 and second computing unit 35, validating the certificates in the token process authorization service 42. By doing this, all communications between the first 34 and second computing unit becomes secured, too.

After all these validations have been successfully processed, the token exchange is processed 28, without the second computing unit 35 knowing the identity of the user 13.

In subsequent requests 511 it may no longer be necessary to access user database 31, but use locally stored processing credentials instead .

Regarding other potential implementations, in the example of Figure it should be noted that the new user registration may be a portal service triggered by the user 13 using the user terminal 32.

The order (who validates who first in the process) may be different from the example, while it is advantageous and the essential message from the examples of Figure 4 and Figure 5 to have method for preventing unauthorized user and revoke access from adverse parties. Different presented components may be integrated together, for instance the user database 31 may be integrated with the token process authorization service 42 or a first computing unit 34.

As a further embodiment it may be occasionally advantageous to have no requirements for a user 13 to obtain a certificate from the authorization service 42. As mentioned before, the token exchange may be processed 28 without the second computing unit 35 knowing the identity of the user 13. The first computing unit does not

necessarily have to manifest any of the users to the rest of the system. In this embodiment the first computing unit may create and maintain token sets for at least one user and by its own

authentication methods validate the user whenever an operation to at least one token set associated with the user is requested. In this respect it would be an internal matter for the first computing unit to maintain an internal user database.

Although the presented invention is described by means of a user 13 accessing a Web (site) service 12, it should be noted that the applicability of the suggested solution is not limited to this particular case.

The Information exchange 28 may be triggered by for instance reading an optical code, such as a QR (Quick Response) code, or an NFC (Near- Field Communication) tag, by a terminal like a smartphone . This optical code or NFC tag may contain the service URI , followed by step 305 or the second token process URL, followed by step 309. In these cases the smartphone may advantageously be the user terminal 32.

Let's have a look at Figure 6. As mentioned, at least the first entity may have a number of token sets 601, perhaps motivated by different contexts the entity may be in. One advantageous method for creating different token sets for different contexts is to search for the smallest distance between the other token set associated with the second entity and the token sets associated with the first entity and selecting the token set with smallest distance to be the token set for the interaction, hereinafter referred as the active token set 602. In this case it would be advantageous to receive 312 the token set from the second computing unit and search for the active token set to be sent from the first computing unit to the second computing unit. If the smallest distance is greater than a certain limit, it can be reasoned that the first entity is in a context it has not been in before. In this case a new token set 605 may be created as a

combination between the active token set 602 and the other token set (25), for instance using equal percentages 603, 604 for proportions, how many tokens from each token set are selected to the new token set. This selection takes advantageously place as random selection.

This approach leads to genetic evolution within the token sets, as the new token set 605 can be advantageously arranged into a family tree hierarchy as a child 607 of the active token set 602 with a link 606 between them.

The aforesaid approach may be utilized for detecting abnormal behavior in a complex system for instance, in fly-by-wire aircraft avionics, military applications, etc., comparing e.g. system statuses in real operation with system statuses in simulation. In some embodiments, various abnormal situations indicated by unexpected or at least previously unmaterialized or non-simulated combinations of sensor data as provided by a number of sensors may be detected and used to trigger establishing a new context with associated token set (of sensor data) and/or sending an alarm/notification signal among other potential responsive actions.

As the basic and also some more finely grained principles underlying the present invention have already been set forth in the preceding discussion, it is time to switch over to the review of a particular embodiment of a communications network accessible electronic

arrangement in accordance with the invention as shown at 701 in Figure 7 with other related entities.

An embodiment of the arrangement 708 comprises at least one network, e.g. Internet, accessible server with a token (set) repository such as a number of databases for backing up (storing) token sets 712 of a number of users 710 such as the depicted user ^Bob' . Each user may be associated with one or more personal token sets 712. In some

embodiments, a token set 712 may also be considered to encompass a plurality of sub-sets of tokens.

The arrangement 708 is configured to synchronize, through data transfer, service-specific and/or otherwise dedicated (use and/or access limited) instances 706A, 706B of the token set 712 associated with the user 710 between a number of e-services 702A, 702B utilized by the user 710. The e-services 702A, 702B may include or at least have access to local token repositories 704A, 704B such as databases where they store the local copies of the token sets of the service users to enable their rapid, problem-free retrieval, adaptation, and storage upon need without requisite to connect to the arrangement 708 first.

Advantageously, the arrangement 708 further comprises a means for providing user interface (s) to terminal devices 710a, 710b, 710c thus enabling accessing the arrangement itself and/or other services 702A, 702B via them.

Reverting to previous discussion especially relating to Figures 3-5, the arrangement 708 may contain e.g. the first computing unit 34 and user database 31. If there is fair trust of user identity from the first computing unit, it may logically also take responsibility of user authentication to a degree that requesting 402 specific user certificates from the token process authorization service 42 are not necessary and neither is user certificate validation 503. Instead, successful login in to the arrangement 708 may give in return the user terminal 32 e.g. a cookie which replaces the need for other user certificates .

The e-services 702A, 702B may be run by entities such as media houses, for instance, that are willing to provide online resources such as media items (e.g. news stories, articles or other items potentially incorporating text, images, audio, video, etc.) to their users via the services. Each service 702A, 702B may implement token set based recommendation logic for providing better personalized content suggestions. The content items and other entities that may be compared to the token sets associated with the users for providing recommendations and be thus also subjected to token set

interaction/adaptation procedures, are associated with

characterizing token sets 707A, 707B preferably stored by the e- services 702A, 702B in the repositories 704A, 704B.

Typically the e-services are accessible by a web browser executed in a user terminal 710a, 710b, 710c such as a mobile terminal,

laptop/desktop computer or a PDA/tablet 710c, respectively, with optional extension ( s ) , but alternatively or additionally also proprietary client software may be exploited for the access.

In some embodiments, one or more user terminals 710a, 710b, 710c and the arrangement 708 may form a related system, optionally with a number of e-services 702A, 702B included therein.

Synchronization of a token set or multiple, e.g. all, token sets may take place periodically according to predetermined schedule (e.g. once a day or a week) or triggered by some predetermined event such as adaptation of a local instance of a token set or e.g. sufficient level of adaptation taken place.

In some embodiments, maintaining the local instances (copies) of the token sets completely coherent all the time is not a crucial issue as still, even though local adaptation may take place by the e-services, it is usually gradual and any of the dispersed instances of the initially same token set does not usually abruptly change completely and render the other, still non-updated, instances totally obsolete.

The users 710 may generally connect to the arrangement 708 via their terminal devices 710a, 710b, 710c. Suitable software for interaction may include web browsers (optionally with extension ( s ) ) and

proprietary applications both alike.

In some embodiments, the users 710 may access or at least enter the e-services 702A, 702B via the arrangement 708. The arrangement 708 may be configured to provide such access to the e-service ( s ) 702A, 702B via user-selectable links, for instance.

The arrangement 708 may be thus configured to provide a front end to the users 710 for the e-service (s) 702A, 702B in addition to the provision of related back-end services. The front end is preferably a graphical one and implemented e.g. as a web (browser) accessible service such as a web site. Preferably, the arrangement 708 is also configured to authenticate the users 710. A common, single authentication procedure (preferably session-based) implemented by the arrangement 708 may indeed enable accessing a plurality of e-services 702A, 702B through performing the necessary log-in tasks only once per session or once per

predetermined time period, for example.

For dealing with the various tasks assigned thereto, the arrangement 708 may comprise a plurality of at least logically or functionally separable entities such as a data transfer entity 722 with a number of wired or wireless data transfer interfaces, such as a wireless or wired network adapter, for receiving and transmitting data relative to external entities such as user terminals 710a, 710b, 710c and e- service entities (servers) 702A, 702B either directly or via

intermediate elements such as various network elements (routers, bridges, etc.) or access/core networks (e.g. cellular access network and related core network.

Yet, the arrangement 708 may include an ontology management and/or token set initialization entity/entities 720 for managing e.g.

ontology <-> token set mappings and token set initialization. The token repository 714 such as one or more databases preferably comprise the definitions of token sets associated with the users 710.

The arrangement 708 and/or the e-services themselves 702A, 702B may host a number of ontology token sets (e.g. a token set for each attribute or generally term/word) for integrating e.g. search engines, including external search engines, therewith to support searching entities associated with characterizing token sets by means of common search utilities and search terms/words.

The arrangement 708 may be configured to utilize semantic profiles with the users 710. The profiles may apply a predetermined ontology to characterize the concerned users via a number of attributes indicative of user preferences and/or his/her properties, e.g.

demographic properties. The arrangement 708 may be configured to communicate with e-services 702A, 702B and/or other external entities for receiving, exchanging and/or forwarding user-related information such as profile information and associated ontology definitions. The information may be exploited by the arrangement 708 and/or e-services 702A, 702B to cultivate the user profiles and/or associated token sets accordingly.

Synchronization entity 716 may be configured to manage token set updates between the e-services 702A, 702B. For example, suitable version control technology, such as Subversion ™ (SVN) or a

proprietary solution optionally based on that, may be utilized and optionally tailored for implementing the synchronization logic.

During synchronization, only changes made to the dedicated copies, or instances, 706A, 706B of the token set 712 used by the e-services 702A, 702B may be signaled to or retrieved by the arrangement 708. Obviously, also the contents of the whole set could be

indicated/ retrieved as an alternative solution. The arrangement 708 preferably takes the role of a coordinating entity combining the various e-service specific changes in a common instance of the token set and signaling the updates/whole updated set back to the

corresponding e-services for use as local, dedicated instances thereat .

User Interface entity 718 may be configured to provide e.g. login facility to a user desiring to access one or more of the e-services 702A, 702B. For the purpose, the entity 718 may maintain or have at least access to a repository such as a database of authentication information (e.g. usernames, passwords, optionally in at least partly secured, e.g. encrypted, form) needed for fulfilling the task. Upon registration, the users 710 may optionally input such information to the arrangement 708 via a provided UI such as a web site/page.

Alternatively or additionally, the e-services 702A, 702B may supply the arrangement 708 with at least some user-specific authentication information regarding a user registered therewith.

Recommendations entity 724, or recommendation engine, may be

configured to determine recommendations regarding e.g. ads or other content items as contemplated hereinbefore. Token set similarity may be utilized as a criterion for finding matches between a number of entities such as user entities and service (resource) entities.

The above entities may be implemented by means of hardware such as processor ( s ) , data bus (es) , memory, etc., and hardware-controlling software, for example. The shown distinction between entities is merely exemplary, logical one, and various implementations may comprise further entities and/or aggregate entities combining two or more of the shown ones .

In some embodiments, the physical elements implementing at least part of the aforementioned functional entities could be external to the arrangement 708. Obviously, the external elements could also perform further tasks. At least one externa1 entity 730 communicating with the arrangement 708 and typically also incorporating a server arrangement of its own, could be as signed with a number of duties regarding e.g. the management of tokens. In some embodiments, e.g. the tasks allocated to the management/initialization entity 720 could be at least partly implemented by such an external entity 730 either instead of or in addition to the arrangement 708, the redundancy arising in the latter case potentially elevating the overall

reliability of the system in terms of data preservation and

accessibility, for example.

In various embodiments of the present invention, temporally limited, or life-span limited, tokens, which may be called ^hourglasses' , may be applied by including them in the token sets. A token could have a half-life with Gaussian distribution, for example. Temporally limited tokens may be managed such as

established/distributed and/or deleted upon expiration by the arrangement and/or an external entity such as the aforementioned authority server arrangement, depending on the embodiment.

Depending on the embodiment, a number of permanent or temporary entities (e.g. event such as festival related entities, e.g. wireless 'beacons' ) or the suggested arrangement 708, when configured

accordingly, or the external entity 730, may emit or otherwise distribute temporally limited tokens that expire at a particular time instant or after a predetermined time, for example. These tokens could be delivered to multiple recipients for addition in their token sets or triggering other type of adaptation, for instance. In various embodiments, when the entities distributing tokens and/or adapting token sets are themselves geographically limited or fixed in position, they may be applied for geotagging type of applications. The entities and/or the provided tokens may thus be temporally and/or geographically limited.

Reverting to the at least one external entity 730 shown in the figure, an authority server entity 730 could be considered as one possible realization thereof. The authority server entity 730 may be functionally connected to a number, potentially a plurality, of arrangements 708. It may take the role of a trusted third party therefor. It may be configured to execute various token management relates tasks, for example, including but not limited to allocating or 'registering' a new token to be utilized in token sets,

maintaining a list of valid tokens, sending a list of valid tokens to the arrangement ( s ) , and sending either a blacklist of expired or otherwise invalid tokens or whitelist of currently valid or 'active' tokens to the arrangement ( s ) . It may also launch new tokens to the system creating them and sending to at least one arrangement 708. In some embodiments, the authority server entity 730 may be

configured to associate a token with a timestamp or other temporal indication of creation, validity period, expiry time, and/or

expiration date. Additionally or alternatively, it may assign thereto a weight factor, and/or a timestamp or other temporal indication of last access. Additionally or alternatively, it may assign thereto a timestamp or other temporal indication of last update or other predetermined token-related action. In some embodiments, the weight factor could be determined preferably dynamically and based on statistical properties of the token such that very rare and/or very common tokens should bear less weight according to predetermined criteria . Based on the available information, such as a received list or other indication of expired or otherwise invalid token (s), the

arrangement ( s ) 708 may take the necessary predetermined actions such as token deletion from the associated set(s) and optionally update of a locally maintained instance or version of a list of valid tokens. In some embodiments, tokens not included in the most recent list of valid tokens received, could be deleted from the associated set(s) e.g. periodically, optionally once a day or week.

In some embodiments, the arrangement ( s ) 708 may be configured to request a number of fresh (new) tokens from the entity 730. The entity 730 may allocate and register such token (s), and respond with information identifying them. Likewise, the arrangement ( s ) 708 may be configured to request general token deletion from the entity 730, whereupon the entity 730 may take the necessary action (s) and answer such request accordingly.

To secure the data transfer/prevent fraudulent activity the

information transferred between the entity 730 and the arrangement ( s ) 708, such as token lists or other token data, could be protected by digital signatures and optionally data encryption. Similar means could be used to protect information transfer between the arrangement 708 and e-services 702A, 702B. Examples of utilizing the Token process authorization service 42 have already been disclosed

hereinbefore. It may be the entity to create and maintain necessary certificates.

Figure 8 shows a flow diagram 800 of a method in accordance with an embodiment of the present invention. At method start-up 802, the necessary hardware and software, such as a number of at least functionally connected server (s) potentially associated with the arrangement in accordance with an embodiment of the present

invention, are acquired and configured for the execution of

subsequent method phases.

Item 804 refers to user registration that may take place whenever a new user is willing to access the e-services via the arrangement and acts accordingly by connecting, optionally through a web browser, to the arrangement and provides necessary predetermined registration information (e.g. login credentials for future use), for instance. Alternatively or additionally, the e-service(s) may ask for

synchronization duties concerning a number of their users to be taken care of by the arrangement and provide the necessary initial

information thereto.

In particular, as item 806 highlights, user-characterizing token set(s) are obtained to enable their storage and synchronization.

Besides receiving via a data transfer interface, the ^obtaining' may refer to establishing or initializing a new token set based on e.g. user-characterizing preference data, or ^profile' data, as

contemplated hereinbefore. A local instance, on in more practical terms ^copy' , of each obtained token set is preferably stored at the arrangement .

Item 808 refers generally to detecting the need to synchronize at least one user-associated token set. The detection may be based on schedule or (other) event based triggering, for example. The

synchronization may take place periodically, e.g. once a day or week, or upon receipt of an explicit or implicit synchronization triggering signal, such as a message from an e-service. One example of implicit triggering signal is e.g. user authentication, i.e. upon user authentication (login) also synchronization of his/her token set(s) is initiated. There may be several parallel triggering conditions for synchronization in use, in which case fulfillment of one or more thereof may be required to begin synchronizing. Item 810 refers to the synchronization tasks. Preferably at least the local copies of one token set utilized by the arrangement and at least one e-service are synchronized. The synchronization mechanism may be selected from a number of predetermined ones optionally e- service, user, and/or token set specifically by the user and/or the e-service (s) . SVN-based or any other feasible synchronization mechanism may be utilized as such or in a tailored form.

The utilized synchronization mechanism may be configured to make various copies of the same token set as coherent as possible by adopting thereto various changes previously made to local copies. In case of conflicting changes, predetermined conflict solving logic may be executed to overcome e.g. contradictory measures taken regarding certain tokens of the set (e.g. addition vs. deletion, increasing value vs. decreasing value, etc.) . In some embodiments, the

arrangement may be configured to host at least slightly different versions of the same token set for different e-services that may arise due to conflictive changes made thereto.

Item 812 refers to the end of method execution. The dotted loop-back arrows highlight the likely repetitive nature of certain method items. New synchronization requests, user registration requests, logins, etc. are awaited and related tasks such as synchronization executed in response.

Item 814 depicts how the existing users may authenticate themselves and also preferably centrally login to the e-service (s) via the arrangement. The arrangement may provide a UI to the users for login, authentication, and/or service access purposes, for instance. Any feasible predetermined authentication scheme may be utilized by the arrangement and the e-services enabling the central type of

authentication via the arrangement. Additionally, it may be possible to login directly to a certain e-service omitting the arrangement as an intermediate entity.

The arrangement may host a CAS (Central Authentication Service) or at least connected to one in order to support single sign-on type access. The e-services may be configured to implement web applications that redirect direct user access to a CAS or other applicable service for centralized login. As one alternative, e.g. WebAuth ™ may be utilized.

Following login/authentication, the arrangement may optionally, as indicated at 816, provide a number of product, service or content recommendations to the user based on matching the token set(s) of the user with token sets regarding different entities such as web sites, content therein, or advertisements. Yet, the user may indicate via the UI of the arrangement which e-service he/she wants to access next, whereupon the arrangement may forward the user to the desired service. The arrangement may display a plurality of e-services as links and/or icons that may be selected via the UI for easy access.

The scope is defined by the appended claims together with the equivalents thereof when supported by the jurisdiction in question. A person skilled in the art will appreciate the fact that the

explicitly disclosed embodiments were constructed for illustrative purposes only, and the scope will cover further embodiments that best suit each particular use case of the invention and still fall under the claim language properly interpreted.

Claims

1. A communications network accessible electronic arrangement (708), preferably one or more functionally connected servers, comprising data transfer interface (722) for transferring data between the arrangement and a plurality of external entities including a number of e-services (702A, 702B) and e-service user terminals (710a, 710b, 710c), token repository entity (714) configured to store a local instance of a number of token sets (712), each stored token set (712) comprising a plurality of identifiable tokens, each stored token set being further associated with an e-service user (710) and related one or more, preferably at least two, e-services of said number of e-services each of which exploiting dedicated instances (706A, 706B) of the token set (712), wherein each dedicated instance of a token set is adapted based on interaction between the associated user and an entity available through an e-service of said related one or more e-services, wherein based on a token set (707A, 707B) associated with the entity the dedicated instance of the token set associated with the user is altered to increasingly resemble the set associated with the entity, and based on the dedicated instance of the token set associated with the user, the token set associated with the entity is altered to increasingly resemble the former, and synchronization entity (716) configured to synchronize, via the data transfer interface, the local instance of the token sets of said number and the remote dedicated instances of the token sets exploited and adapted by the e-services.

2. The arrangement of claim 1, further comprising a user interface entity (718) configured to authenticate an e-service user (710) for single sign-on (SSO) access of at least two of said e-services (702A, 702B) .

3. The arrangement of any preceding claim, further comprising a token set management entity (720) configured to initialize or modify a token set (712) associated with a user (710) based on a number of user-characterizing attributes.

4. The arrangement of claim 3, wherein the arrangement is configured to initialize or modify the token set (712) based on a received user profile indicating the attributes.

5. The arrangement of claim 3 or 4, configured to adapt the token set associated with the user based on the token set associated with at least one user-characterizing attribute.

6. The arrangement of any preceding claim, configured to manage an ontology associating attributes with tokens or token sets.

7. The arrangement of any preceding claim, configured to convert or map a number of search terms into one or more tokens or token sets or vice versa.

8. The arrangement of any preceding claim, configured to execute and optionally integrate token and attribute based searches by associating a number of input attributes, optionally search terms given, with a target token set or associating an input token set with a number of target attributes, and conducting a number of searches evaluating the similarity between the target token set and other token sets associated with a plurality of entities and/or the similarity between the number of target attributes and attributes associated with a plurality of entities, such as media items, or related token sets, wherein the search results are preferably utilized in establishing a number of recommendations of entities to a user.

9. The arrangement of any preceding claim, configured to trigger a synchronization procedure based on at least one triggering condition selected from the group consisting of: synchronization schedule, receipt of triggering signal, receipt of synchronization request, receipt of synchronization request from an e-service, receipt of synchronization request from a user terminal, user authentication, and user log out.

10. The arrangement of any preceding claim, further comprising a

recommendation entity (724) configured to determine an indication of similarity between the first token set (712) associated with a user (710) and each set in a plurality of token sets, each token set in said plurality being associated with a different entity, optionally an advertisement or other content item, and based on the determined indications of similarity, establish a

recommendation for the user regarding a sub-set of one or more entities from said plurality of entities.

11. The arrangement of any preceding claim, configured to manage

temporally limited tokens through execution of at least one operation selected from the group consisting of: insertion of a temporally limited token in a token set associated with a user and storing the temporal validity information as integrated with the token or separately according to predetermined logic, and deletion of a temporally limited token from a token set associated with a user according to predetermined logic in response to token expiry .

12. The arrangement of any preceding claim, configured to manage

geographically limited tokens through execution of at least one operation selected from the group consisting of: insertion of a geographically limited token in a token set associated with a user and storing the geographical validity information as integrated with the token or separately according to predetermined logic, and deletion of a geographically limited token from a token set associated with a user according to predetermined logic in response to token expiry.

13. A system comprising a number of arrangements (708) according to any preceding claim and an authority server entity (730)

functionally connected thereto and configured to execute at least one action selected from the group consisting of: registering a token to be utilized in token sets, updating a list of valid tokens, sending a list of one or more valid tokens to an arrangement (708), sending a list of one or more expired or otherwise invalid tokens to an arrangement (708), associate a token with a timestamp or other temporal indication of

registration, validity period, expiry time, or expiration date, and associate a token with a weight factor.

. A method (800) to be performed by a communications network accessible electronic arrangement (708) optionally incorporating one or more at least functionally connected servers, comprising storing (806) a local instance of a number of token sets, each stored token set comprising a plurality of identifiable tokens, each stored token set being further associated with an e-service user and related one or more, preferably at least two, e-services each of which exploiting dedicated instances of the token set, wherein each dedicated instance of a token set is adapted based on interaction between the associated user and an entity available through an e-service of said related one or more e-services, wherein based on a token set associated with the entity the dedicated instance of the token set associated with the user is altered to increasingly resemble the set associated with the entity and based on the dedicated instance of the token set associated with the user the token set associated with the entity is altered to increasingly resemble the former, synchronizing (808, 810) the local instance of at least one token set of said number and the remote dedicated instances of the at least one token set exploited by e-services, wherein synchronizing incorporates transferring data between the arrangement and the e- services.

15. A computer executable program comprising code means adapted, when executed on a computer, to execute the method items of claim 14.

16. A non-transitory carrier medium, optionally a memory card or

optical disc, comprising the computer program of claim 15.