WO2014029904A1 - Procédé et agencement pour système de recommandation distribué - Google Patents

Procédé et agencement pour système de recommandation distribué Download PDF

Info

Publication number
WO2014029904A1
WO2014029904A1 PCT/FI2013/050687 FI2013050687W WO2014029904A1 WO 2014029904 A1 WO2014029904 A1 WO 2014029904A1 FI 2013050687 W FI2013050687 W FI 2013050687W WO 2014029904 A1 WO2014029904 A1 WO 2014029904A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
user
entity
arrangement
token set
Prior art date
Application number
PCT/FI2013/050687
Other languages
English (en)
Inventor
Ville Ollikainen
Raimo Launonen
Original Assignee
Teknologian Tutkimuskeskus Vtt
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FI20126249A external-priority patent/FI126426B/en
Application filed by Teknologian Tutkimuskeskus Vtt filed Critical Teknologian Tutkimuskeskus Vtt
Publication of WO2014029904A1 publication Critical patent/WO2014029904A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0631—Item recommendations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9535—Search customisation based on user profiles and personalisation

Definitions

  • 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.
  • a genetic algorithm is a programming technique that mimics biological evolution as a problem-solving strategy.
  • Genetic algorithms have been applied to scientific and engineering problems and they have been widely used in optimization problems.
  • 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.
  • 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
  • Content-based and collaborative recommendations 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 learn from user behaviour.
  • 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
  • challenges are often mentioned regarding content-based recommendations:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • characteristic profile data and data based on interaction history that is, however, in most such solutions necessary for determining relevant matches between them.
  • this cold start problem is almost inevitable.
  • the scope lacks a holistic view of overall user preferences.
  • the present invention yields an arrangement and distributed method for realizing a recommendation system avoiding non-intended disclosure of personal preferences of individual users.
  • 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.
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • UI user interface
  • 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.
  • the arrangement further comprises a token set management entity
  • 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
  • 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
  • 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.
  • 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.
  • the token set associated with the attribute may originate from other closeby attributes in the
  • 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) .
  • token sets may be associated with profiles or in
  • semantic profiles E.g. user or item or generally entity, profiles may be utilized for the initialization of the related token sets, for instance.
  • a search engine entity may utilize the token sets associated with various attributes and optionally also the ontology tree nodes for conducting alternative or extended searches.
  • a token set associated with e.g. a user may be provided for retrieving a
  • 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
  • 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.
  • 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
  • the arrangement is configured to utilize a predetermined synchronization mechanism, ⁇ tool' , or scheme for the purpose.
  • a predetermined synchronization mechanism ⁇ tool'
  • scheme for the purpose.
  • SVS Subversion TM
  • SVN Subversion TM
  • 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.
  • 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.
  • 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.
  • the arrangement is configured to execute the items of
  • the arrangement may be configured to indicate the recommended entity/entities to the user via the UI, optionally web browser accessible UI, thereof.
  • 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) .
  • a network accessible service advantageously a Web site or other online service
  • URI uniform resource identifier
  • 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.
  • 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.
  • 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.
  • 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.
  • 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) .
  • 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.
  • 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)) .
  • the concerned token (s) may be deleted from the set according to predetermined logic.
  • expired tokens remain in the set but are neglected regarding a number of token- related operations such as token set adaptation.
  • a temporally limited (numeric) token may reduce or increase in value, which may be indicated by the weight factor, for instance.
  • the adaptation process 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.
  • the tokens may be sorted internally in the order in which they have been received, making this option more feasible.
  • 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 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.
  • one physical computing unit for example a network service, may maintain a plurality of token sets associated with different
  • token process associated with the first entity is referred as the first token process
  • token process associated with the second entity is referred as the second token process
  • URL universal resource locator
  • a terminal device of a user associated with a first token process has access to a means for resolving universal resource locator (URL) of a second token process (and second token set) .
  • URL universal resource locator
  • 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
  • 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
  • the token set associated with the entity is altered to increasingly resemble the former, the e-services
  • synchronizing incorporates transferring data between the arrangement and the e-services.
  • 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.
  • 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.
  • the synchronization takes place in response to fulfillment of necessary triggering condition (s) that may be
  • a computer program 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 e-services have a local version of a token set associated with a user, which enables quick utilization (retrieval, adaptation, use in providing
  • 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
  • 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 .
  • 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.
  • third party e.g. semantic user profiles defined using the ontology
  • recommendation technologies and systems 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.
  • 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.
  • a plurality of refers herein to any positive integer starting from two (2), e.g. to two, three, or four.
  • 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.
  • 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 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
  • first computing unit a computing unit associated with a first entity
  • second computing unit a computing unit associated with at least one second entity
  • FIG. 1 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.
  • User 13 and Web (site) service 12 and/or resources accessible via it may be seen as ⁇ entities' .
  • Each entity is preferably associated with at least one token set 17.
  • 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
  • the tokens are identifiable by a number and/or some other identification-enabling data.
  • 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 .
  • 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.
  • Figure lb is a high-level flow diagram of an embodiment of token utilization and adaptation in the general context of the present invention.
  • the necessary hardware and software such as terminal device (s) and/or network element (s) like server (s), are acquired and configured.
  • the token set(s) associated with a first entity 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first token set is altered to increasingly resemble, or "reflect", the second 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.
  • 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.
  • 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.
  • 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.
  • situations may occur where only one token set is adapted based on interaction between the first and second entities.
  • 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.
  • 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.
  • 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.
  • a determination 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.
  • 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
  • the method execution is ended.
  • 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.
  • a data transfer entity may take care of token data transfer and other communication
  • an adaptation entity may perform adaptation
  • 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
  • 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.
  • 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 .
  • interacting unit 21 may be updated simply by copying there a number of tokens from the token set 25 associated with the second
  • 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
  • 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.
  • the percentage may be made regressive by reducing the percentage 27 in subsequent updates.
  • 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.
  • the token pair may be replaced by a single token which has an average value of the deleted tokens .
  • 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.
  • the sub-set, or "list”, thus generally comprises a lower number of entities than the initial plurality of searchable sets.
  • 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) .
  • 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.
  • searching for the most suitable people for an advertisement 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.
  • the interaction can be advantageously divided into individual interactions between each pair of interacting entities:
  • 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.
  • 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.
  • FIG. 3 illustrates how the related system might operate in practice:
  • 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
  • URL Uniform Resource Locator
  • 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
  • the user 13 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.
  • URI Unified Resource Identifier
  • the 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.
  • 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.
  • 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.
  • the locator such as network address
  • the locator 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) .
  • the addressed resource such as (XML) document may include the ID of the entity
  • identification either as a part of the locator or as a part of the data .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • Figure 4 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.
  • the user terminal is first requesting 301 processing credentials from the user database 31.
  • 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) .
  • PKI public key infrastructure
  • the revocation mechanisms in PKI may become useful in cases when a user tries to use the system adversely.
  • the token process authorization service issues and returns (403) certificates to the user terminal 32.
  • 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.
  • a certificate issued by the token process authorization service 42 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
  • 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.
  • 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
  • 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.
  • the second computing unit could be able to receive user identifications salted by a random value
  • 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.
  • the user database 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 .
  • 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.
  • 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.
  • the user database 31 may also be provided by the same trusted party as the first computing unit 34.
  • the user terminal is first requesting 301 processing credentials from the user database 31, with appropriate authorization.
  • 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.
  • URI Resource Identifier
  • 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.
  • 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.
  • 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.
  • SSL/TLS Secure Sockets Layer, Transport Layer Security
  • the token exchange is processed 28, without the second computing unit 35 knowing the identity of the user 13.
  • 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.
  • 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
  • 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.
  • 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.
  • the smartphone may advantageously be the user terminal 32.
  • 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.
  • the active token set 602. 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • characterizing token sets 707A, 707B preferably stored by the e- services 702A, 702B in the repositories 704A, 704B.
  • 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.
  • 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.
  • predetermined schedule e.g. once a day or a week
  • some predetermined event such as adaptation of a local instance of a token set or e.g. sufficient level of adaptation taken place.
  • 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
  • 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.
  • 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.
  • 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
  • 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
  • servers e- service entities
  • intermediate elements such as various network elements (routers, bridges, etc.) or access/core networks (e.g. cellular access network and related core network.
  • the arrangement 708 may include an ontology management and/or token set initialization entity/entities 720 for managing e.g.
  • 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.
  • ontology token sets e.g. a token set for each attribute or generally term/word
  • 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.
  • 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.
  • suitable version control technology such as Subversion TM (SVN) or a
  • 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
  • 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.
  • 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.
  • 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.
  • the users 710 may optionally input such information to the arrangement 708 via a provided UI such as a web site/page.
  • 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 may be any resource provisioned by Recommendations entity 724, or recommendation engine.
  • 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.
  • processor ( s ) processor
  • data bus (es) data bus
  • memory etc.
  • 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 .
  • the physical elements implementing at least part of the aforementioned functional entities could be external to the arrangement 708.
  • 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.
  • 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
  • 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
  • a number of permanent or temporary entities e.g. event such as festival related entities, e.g. wireless 'beacons'
  • the suggested arrangement 708 when configured
  • 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.
  • 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.
  • 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,
  • the authority server entity 730 may be
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • Figure 8 shows a flow diagram 800 of a method in accordance with an embodiment of the present invention.
  • 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
  • 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
  • user-characterizing token set(s) are obtained to enable their storage and synchronization.
  • the ⁇ obtaining' may refer to establishing or initializing a new token set based on e.g. user-characterizing preference data, or ⁇ profile' data, as
  • 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.
  • 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.
  • implicit triggering signal is e.g. user authentication, i.e. upon user authentication (login) also synchronization of his/her token set(s) is initiated.
  • Item 810 refers to the synchronization tasks.
  • 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.
  • 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.) .
  • the set e.g. addition vs. deletion, increasing value vs. decreasing value, etc.
  • 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
  • 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.
  • WebAuth TM may be utilized.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur un agencement électronique accessible par réseau de communication (708), tel qu'un ou plusieurs serveurs de préférence accessibles par Internet, comprenant une interface de transfert de données (722) pour transférer des données entre l'agencement et une pluralité d'entités externes comprenant un certain nombre de services électroniques (702A, 702B) et des terminaux utilisateurs de service électronique (710a, 710b, 710c), une entité référentiel de jetons (714) configurée pour stocker une instance locale d'une pluralité d'ensembles de jetons (712), chaque ensemble de jetons stocké comprenant une pluralité de jetons identifiables, chaque ensemble de jetons stocké étant en outre associé à un utilisateur de service électronique (710) et à un ou plusieurs, de préférence au moins deux, services électroniques en rapport dudit certain nombre de services électroniques dont chacun exploite des instances dédiées (706A, 706B) de l'ensemble de jetons, chaque instance dédiée d'un ensemble de jetons étant adaptée sur la base d'une interaction entre l'utilisateur associé et une entité accessible par l'intermédiaire d'un service électronique dudit ou desdits services électroniques en rapport, l'instance dédiée de l'ensemble de jetons associé à l'utilisateur étant modifiée, sur la base d'un ensemble de jetons (707A, 707B) associé à l'entité, afin de ressembler de plus en plus à l'ensemble associé à l'entité et l'ensemble de jetons associé à l'entité étant modifié, sur la base de l'instance dédiée de l'ensemble de jetons associé à l'utilisateur, afin de ressembler de plus en plus à ce dernier, et une entité de synchronisation (716) configurée pour synchroniser, par l'intermédiaire de l'interface de transfert de données, l'instance locale des ensembles de jetons de ladite pluralité et les instances dédiées distantes des ensembles de jetons exploitées et adaptées par les services électroniques. Un procédé correspondant pour synchroniser des ensembles de jetons est présenté.
PCT/FI2013/050687 2012-08-23 2013-06-20 Procédé et agencement pour système de recommandation distribué WO2014029904A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201261692315P 2012-08-23 2012-08-23
US61/692,315 2012-08-23
FI20126249 2012-11-28
FI20126249A FI126426B (en) 2012-08-23 2012-11-28 Procedure and apparatus for a token exchange recommendation system

Publications (1)

Publication Number Publication Date
WO2014029904A1 true WO2014029904A1 (fr) 2014-02-27

Family

ID=50149487

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2013/050687 WO2014029904A1 (fr) 2012-08-23 2013-06-20 Procédé et agencement pour système de recommandation distribué

Country Status (1)

Country Link
WO (1) WO2014029904A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018150081A1 (fr) 2017-02-20 2018-08-23 Teknologian Tutkimuskeskus Vtt Oy Procédé, unité de calcul et système pour échange d'informations à base de jetons
US20220129926A1 (en) * 2020-10-23 2022-04-28 The Travelers Indemnity Company Dynamic web content insertion
US12033170B2 (en) 2023-04-07 2024-07-09 The Travelers Indemnity Company Dynamic web content insertion

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060010117A1 (en) * 2004-07-06 2006-01-12 Icosystem Corporation Methods and systems for interactive search
US7908182B1 (en) * 2004-08-04 2011-03-15 Rajiv Gupta Personal advisor service and mechanisms for advice and interactions

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060010117A1 (en) * 2004-07-06 2006-01-12 Icosystem Corporation Methods and systems for interactive search
US7908182B1 (en) * 2004-08-04 2011-03-15 Rajiv Gupta Personal advisor service and mechanisms for advice and interactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NANDI ET AL.: "P3: A Privacy Preserving Personalization Middleware for recommendation-based services", 4TH HOT TOPICS IN PRIVACY ENHANCING TECHNOLOGIES (HOTPETS), 29 July 2011 (2011-07-29), Retrieved from the Internet <URL:http://petsymposium.org/2011/papers/hotpets11-final6Nandi.pdf> [retrieved on 20131128] *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018150081A1 (fr) 2017-02-20 2018-08-23 Teknologian Tutkimuskeskus Vtt Oy Procédé, unité de calcul et système pour échange d'informations à base de jetons
US20220129926A1 (en) * 2020-10-23 2022-04-28 The Travelers Indemnity Company Dynamic web content insertion
US11645664B2 (en) * 2020-10-23 2023-05-09 The Travelers Indemnity Company Dynamic web content insertion
US12033170B2 (en) 2023-04-07 2024-07-09 The Travelers Indemnity Company Dynamic web content insertion

Similar Documents

Publication Publication Date Title
FI126426B (en) Procedure and apparatus for a token exchange recommendation system
US20240169322A1 (en) Predictive targeting, analytics and modeling of users and audiences
US8826155B2 (en) System, method, and computer program product for presenting an indicia of risk reflecting an analysis associated with search results within a graphical user interface
US7562304B2 (en) Indicating website reputations during website manipulation of user information
US7822620B2 (en) Determining website reputations using automatic testing
US9384345B2 (en) Providing alternative web content based on website reputation assessment
US8700705B2 (en) Sharing of user preferences
US7765481B2 (en) Indicating website reputations during an electronic commerce transaction
US20160253700A1 (en) System and method for automated advocate marketing with digital rights registration
KR101964293B1 (ko) 인증된 콘텐츠를 콘텐츠 소비자로 이동시키는 기법
US20110276563A1 (en) Systems, methods, and computer readable media for security in profile utilizing systems
US20140331119A1 (en) Indicating website reputations during user interactions
US20060253582A1 (en) Indicating website reputations within search results
US20060253584A1 (en) Reputation of an entity associated with a content item
Shen et al. SocialQ&A: An online social network based question and answer system
Dhekane et al. Talash: Friend Finding In Federated Social Networks.
WO2014029904A1 (fr) Procédé et agencement pour système de recommandation distribué
Müsse et al. Ethics of Personal Data in IoT
Shaharin Private Recommendation: Extending Capabilities Of Privacy-Protection Recommender Systems
KR20220012541A (ko) 웹기반 스마트 무인 오더 방법, 시스템 및 그 방법을 수행하는 컴퓨터 프로그램
Guidi et al. Online Social Networks and Media
Puglisi Analysis, modelling and protection of online private data
Schlee et al. Analysis of Key Building Blocks in Targeted Advertising Technologies

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13830692

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13830692

Country of ref document: EP

Kind code of ref document: A1