EP3074931A1 - Procédé et serveur de notification d'une carte électronique - Google Patents

Procédé et serveur de notification d'une carte électronique

Info

Publication number
EP3074931A1
EP3074931A1 EP14821728.4A EP14821728A EP3074931A1 EP 3074931 A1 EP3074931 A1 EP 3074931A1 EP 14821728 A EP14821728 A EP 14821728A EP 3074931 A1 EP3074931 A1 EP 3074931A1
Authority
EP
European Patent Office
Prior art keywords
user
server
information data
electronic card
data
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
EP14821728.4A
Other languages
German (de)
English (en)
Inventor
Fano Ramparany
Cédric PRONZATO
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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
Application filed by Orange SA filed Critical Orange SA
Publication of EP3074931A1 publication Critical patent/EP3074931A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
    • G06Q10/1093—Calendar-based scheduling for persons or groups
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G06Q10/40—Business processes related to social networking or social networking services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G06Q10/40—Business processes related to social networking or social networking services
    • G06Q10/42—Determination of affinities or common interests between users
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G06Q10/40—Business processes related to social networking or social networking services
    • G06Q10/48—Business processes related to social networking or social networking services using social graphs

Definitions

  • the invention relates to the general field of communications.
  • This information is for example identification data such as a name, an address (personal or professional, postal or electronic), a telephone number, a photograph, etc.
  • Such cards can be in particular business cards or business cards, commonly exchanged between the users holding these cards to which the data on the cards relate, and users called holders or receivers or recipients of these cards to which cards were given by the executive users.
  • the invention proposes to extend the use of hardware or virtual cards embedding data relating to their holders by adding new means and new features to facilitate interactions between the holders and the persons in possession of these cards. It relies for this purpose on the one hand on the card itself, which is endowed in accordance with the invention means for notifying the user holding this card of the existence of opportunities for interaction with the holder of the card, and secondly on a server deployed in a telecommunications network, communicating with the card and able to detect the existence of such opportunities.
  • card holder user refers to the user to whom the information displayed on the card refers, and to the "cardholder” user, a user to whom the employee user has given his card.
  • the invention thus relates to a method of notification, by a server of a telecommunications network, of an electronic card associated with a registered user and registered with this server, this method comprising:
  • a step of notifying the electronic card via the telecommunications network If at least one piece of common information is detected, a step of notifying the electronic card via the telecommunications network.
  • the invention also relates to a server of a telecommunications network comprising:
  • a recording module able to record an electronic card associated with a role user and a user holding this electronic card
  • a search module for information data that is common to both the owner and the owner of the information data obtained
  • the invention also relates to an electronic card associated with a registered user and registered with a server, and comprising:
  • a communication module with the server, arranged to receive a notification issued by the server when at least one information data common to the owner and a user holder of the electronic card has been detected by the server;
  • a warning module of the user holding the electronic card activated upon receipt of the notification.
  • the information data relating to theoxy user and the user holding can be of very diverse natures and come from sources external to the electronic card itself. For example, it can be:
  • the search for data common to the incumbent user and to the user holding the card makes it possible in particular to detect the existence of one or more opportunities for exchanges between these users (eg participation in a common event listed in the user calendars, events of the activity of the holder user of interest to the cardholder user, etc.).
  • This search can consist in identifying any common data among the information data collected by the server, or alternatively, common data meeting one or more predetermined criteria.
  • criteria may in particular be chosen by the card-holder user so as to filter the exchange possibilities reported to the holding user to whom he has given his card (eg criterion on the professional or personal nature of the data of the card holder). information, location-related criteria associated with these data), or may depend on the card-holder user, etc.
  • this warning module can be in particular in the form of a light emitting diode (or LED (Light Emitting Diode)) or a buzzer or a module of audible warning, activated when receiving the server notification.
  • the invention proposes to make the card exchanged between the incumbent and the holding user proactive.
  • This proactive map makes it possible to create and maintain in a very simple way a social link between these two people, in a transparent way for them once the registration of the exchange of the card made with the server.
  • the invention offers the possibility of preserving the confidentiality of the information data collected by the server on the incumbent user vis-à-vis the user holder of the card. Only the server needs to access the details of this information data to perform the search for data common to both users.
  • the notification transmitted by the server to the card may advantageously not contain this data, nor contain details on the exchange opportunity underlying the detection by the server of data common to users.
  • the card according to the invention does not need to be endowed with complex and expensive means. It suffices to equip it with warning means for notifying the cardholder and a communication module with the server to be informed of the existence of data common to theoxy person and identified on the card. and to the holder of this card.
  • this communication module may comprise a module for direct connection to the telecommunications network of the server, or alternatively include a connection module to an intermediate equipment connected to the telecommunications network. the server through which the notification issued by the server is received.
  • the connection module can integrate for example a radio-identification module (also known as RFID module for Radio Frequency IDentification in English), or a USB port, etc.
  • the intermediate equipment may be in particular a reader or a terminal dedicated to the coupling with the card, or alternatively, a computer provided with a communication port compatible with the connection module of the card.
  • Such a card hardware has the advantage of being tangible to users.
  • the user holding the card can then connect to a website or portal powered by the server to obtain more information on the exchange opportunity or more generally on the common data detected by the server itself. Access to this data may be configured by the incumbent user to filter the information communicated to the owner user.
  • the invention thus has a preferred but non-limiting application in the field of the Internet of Things, which aims to associate real objects with intelligent interfaces for connecting and communicating in contexts of varied uses, via networks of applications. telecommunications such as the Internet.
  • the invention can also be applied to a virtual-type electronic card (ie an application), to which software means of communication with the server and of warning of the holding user (ex displaying an appropriate symbol, emitting a predetermined sound, etc.).
  • a virtual-type electronic card ie an application
  • software means of communication with the server and of warning of the holding user ex displaying an appropriate symbol, emitting a predetermined sound, etc.
  • the method according to the invention further comprises a step of aggregating the obtained information data relating to theoxy user and information data obtained relating to the user holding in a data structure designed to uniquely represent information data common to the incumbent and the owning user while associating them with each of them.
  • Such a data structure is for example modeled by a graph.
  • Graphs are powerful tools for easily and synthetically representing information data, including the concepts contained in these data and the relationships between these concepts.
  • the set of concepts and relationships linking these concepts to each other is also known as ontology.
  • information data according to which "X is registered in a conference CONF Y" can be modeled by a graph comprising two nodes associated respectively with the concept "X” and the concept "conference CONF Y", and an arc connecting these two nodes having the meaning "is registered with”.
  • the aggregation step can thus advantageously comprise an analysis of the information data obtained from a previously defined ontology comprising a plurality of types of concepts representing the information and relationship data linking these concepts.
  • the aggregation step makes it possible to merge the information data while preserving the uniqueness of the underlying concepts contained in these data. In this way, the duplication in the structure of the aggregated data of representations of information data common to users is avoided.
  • the structure of the aggregate data that results is thus advantageously synthetic.
  • the aggregation step consists, for example, in developing a graph whose nodes (or vertices) and arcs are deduced from the information data of the holder and of the card holder, each node being associated with a separate concept.
  • the graph constructed during the aggregation step contains a single node associated with the conference CONF Y connected via two distinct arcs to the nodes associated with the users "X" and "Z".
  • the search for common elements among the information data obtained relating to the holder and the cardholder is greatly facilitated.
  • the search for specific common elements, characterizing a particular type of interaction or a particular concept can be easily implemented by searching for a fragment of the data structure corresponding to this type of interaction.
  • this embodiment allows to rely on existing languages (or models) of resource description and query.
  • RDF Resource Description Framework
  • SPARQL query language SPARQL Protocol and RDF Query Language
  • the invention is not limited to the use of the aforementioned languages, and other languages such as the SQL query language (Structured Query Language) or proprietary description and query languages can be used.
  • SQL query language Structured Query Language
  • proprietary description and query languages can be used.
  • the search and, if applicable, notification steps are reiterated in taking into account the new information data obtained.
  • Obtaining new information data can be done at the initiative of the server, or alternatively, in push mode, when new information data concerning the holder or the card holder are detected by the sources. hosting this data and that they inform the server (for example following a subscription of the server from these sources of information).
  • the invention thus provides the cardholder with relevant information about the holder, updated in real time.
  • the different steps of the notification method are determined by computer program instructions.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a server or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a notification method as described above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention also relates to a system comprising a server and an electronic card according to the invention.
  • This electronic card can be hardware or virtual.
  • the notification method, the server, the electronic card and the system according to the invention present in combination all or part of the aforementioned characteristics.
  • FIG. 1 shows, schematically, a system, a server and an electronic card according to the invention in a particular embodiment
  • FIG. 2 schematically illustrates the architecture of the electronic card of FIG. 1;
  • FIG. 3 schematically illustrates the hardware architecture of the server of FIG. 1;
  • FIG. 4 represents, in the form of a flow chart, the main steps of a notification method according to the invention as implemented by the server of FIG. 1, in a particular embodiment;
  • FIGS. 5A-5E illustrate examples of graphs and a query on a graph that can be used by the server of FIG. 1. Detailed description of the invention
  • FIG. 1 represents, in its environment, a system 1 according to the invention in a particular embodiment.
  • the system 1 makes it possible to create and maintain a social link between two users X and Z via the exchange of a proactive electronic business card 2, according to the invention, on which User X identification data (eg the user's name, personal or business address, etc.) are displayed.
  • the electronic card 2 is here a hardware card.
  • the user X is a user of the electronic card 2 within the meaning of the invention, who has given his electronic business card 2 to the user Z.
  • the user Z is therefore a user holder of the electronic card 2 to sense of the invention.
  • the system 1 is based on the electronic card 2 entrusted by the user X to the user Z, and on a server 3 according to the invention, connected to a telecommunications network 4.
  • the telecommunications network 4 is for example here the public Internet network. However, no limitation is attached to the nature of the network 4; it can be a fixed or mobile network, public or proprietary, wired or wireless, etc.
  • the server 3 is adapted, in accordance with the invention, to aggregate and correlate information data relating to the user X and the user Z made available by different information sources 5 in order to identify common data likely to create opportunities for exchange between the two users, and to notify the electronic card 2 held by the user Z of the existence of such opportunities if any. It is assumed for this purpose that the user X has subscribed to the service offered by the server 3 and registered with it, at the time of its subscription, the electronic card 2 as well as possibly other electronic cards in his name, identical to the electronic card 2, and intended for future contacts. Each electronic card is identified during this registration by an identifier or an ID code: thus, the electronic card 2 is associated with the user X with the server 3 and identified by an identifier ID2.
  • the information sources 5 supplying the server 3 with information data. These sources of information may be maintained by the server 3 or alternatively by third parties and communicate with the server 3 via a telecommunications network such as the telecommunications network 4.
  • the information data provided by the sources 5 can be of different natures. This may include, but is not limited to:
  • - information data extracted from user profiles eg age, occupation, professional and / or personal interests, employer, skills, etc.
  • server 3 or by the fixed or mobile network operators from whom have subscribed the users X and Z and with which the server 3 has a partnership
  • server 3 has a partnership
  • - Location information data X and Z users for example provided to the server 3, if any, by mobile network operators X and Z users;
  • the choice of information sources 5 can be decided by the server 3 (in other words, by the operator of the service offered by the server 3), or alternatively be configured by the user X according to his preferences. . It can also be configured by the user X so as to depend on the user Z (depending in particular on the information that the user X wishes to make available to the user Z or opportunities that he wishes to have with the user Z).
  • the server 3 communicates with the electronic card 2 via an intermediate device 6.
  • the intermediate equipment 6 is a personal computer belonging to the user Z, and equipped with a connection module 6A with the electronic card 2, means 6B communication on the network 4, and a screen 6C.
  • the connection module 6A is for example a port or a USB (Universal Serial Bus), or a short-distance wireless communication module using for example RFID (Radio Frequency Identification) or Bluetooth, etc.
  • the intermediate equipment 6 acts as a relay of the notifications transmitted by the server 3 to the electronic card 2.
  • the intermediate equipment 6 may be a dedicated card reader comprising means 6A for connection with the electronic card 2 and means 6B for communication on the network 4.
  • the electronic card 2 is equipped with a connection module compatible with the connection module 6A of the intermediate equipment 6.
  • FIG. 2 schematically illustrates the architecture of the hardware electronic card 2 entrusted by the user X to the user Z.
  • the electronic card 2 has the format of a business card, and comprises:
  • a warning module 2B situated on the external surface of the electronic card 2, and comprising, for example, a buzzer or a light-emitting diode for signaling to the user Z the receipt of a notification from the server 3;
  • a communication module 2C here including the connection module compatible with the connection module 6A of the intermediate equipment 6 (socket or USB port, RFID or Bluetooth module, etc. depending on the nature of the connection module 6A).
  • the electronic card 2 is able to communicate directly with the server 3 via the telecommunications network 4 without requiring intermediate equipment such as the equipment 6.
  • the communication module 2C then integrates a module of connection to the telecommunications network 4 or to a network connected to the telecommunications network 4.
  • the electronic card 2 may take other forms than that illustrated schematically in FIG. 2. It may furthermore integrate other complementary means, such as for example a microprocessor or a programmable logic circuit, one or more memories enabling it store information transmitted in particular by the server 3, a screen for displaying information, etc.
  • other complementary means such as for example a microprocessor or a programmable logic circuit, one or more memories enabling it store information transmitted in particular by the server 3, a screen for displaying information, etc.
  • the server 3 has the hardware architecture of a computer, as schematically illustrated in FIG. 3. It notably comprises a processor 3A, a read-only memory 3B, a random access memory 3C, a memory non-volatile 3D and communication means 3E on the telecommunications network 4.
  • the read-only memory 3B of the server 3 constitutes a recording medium readable by the processor 3A and on which is recorded a computer program according to the invention, comprising instructions for performing the steps of a notification method according to the invention, the steps of this notification method being described later with reference to Figure 4 in a particular embodiment.
  • (Software) of the server 3 such as in particular a recording module of the electronic card 2 and the user Z holder of the electronic card 2, a module for obtaining information data relating to the user X and to the user Z from the information sources 5 and an aggregation module of these data, a data search module common to the users X and Z among the aggregated data and a notification module of the electronic card 2 the case applicable.
  • the obtaining and notification modules use in particular the communication means 3E on the telecommunications network 4 of the server 3. The functions of these various modules are described in more detail with reference to the steps of the notification method illustrated in FIG. 4.
  • the user X has subscribed to the service offered by the server 3. He has, during this subscription, registered with the server 3 (ie the registration module of the server 3) the electronic card 2 by providing its identifier ID2 (step E10), and possibly other electronic cards identical to the electronic card 2 and that it is intended for other users. It is further assumed that the user X gives his electronic card 2 to the user Z, and that the latter is registered with the registration module of the server 3 (step E20). During this registration, the user Z provides the identifier ID2 of the electronic card 2 as well as his own identifier (eg a name and / or a telephone number, etc.).
  • the server 3 sends, via the telecommunications network
  • This request can take the form of a subscription to all or part of the sources 5, so that they transmit on their own initiative to the server 3 (that is to say in push mode) the information data relating to the users X and Z which they have as soon as they obtain these data or as soon as they are updated.
  • the request from the server 3 may be repeated periodically or predetermined in order to have relevant and up-to-date information data from the sources on the X and Z users.
  • the server 3 thus obtains information sources 5, via its obtaining software module, the information data that these sources have on the users X and Z (step E30).
  • the server 3 aggregates the information data received from the various information sources 5 in the form of a graph G conforming to the description language RDF.
  • RDF description language
  • the RDF language describes all information in the form of a model and more precisely of a graph, representing the concepts involved in this information as well as the relationships linking these concepts to each other.
  • the concepts involved in this information are “X” and “conference CONF Y”, and the relationship linking these concepts is "is registered to” .
  • the RDF language relies on the definition and use of ontologies, which are themselves RDF models defining types of data or objects whose the concepts contained in each information are relevant.
  • An ontology in a computer context, refers to a conceptualization of a field of knowledge. By conceptualization, we mean here the definition of the terms that are necessary to express the meaning of information pertaining to this domain and the properties of these terms. Terms include object types (or classes) and the relationships between these object types. A property of a relation is, for example, its transitivity.
  • an ontology means both a choice as to how to describe a domain, and a formal description of that domain.
  • Ontologies are commonly used in areas such as artificial intelligence, semantic web, software engineering, etc.
  • FIGS. 5A and 5B illustrate two examples of graphs conforming to the RDF language respectively modeling information (or equivalently a set of information data in the sense of the invention) stating that "X is registered at a conference CONF Y" and information stating "X was born on September 20, 1980".
  • the information "X is registered at a conference CONF Y" is modeled, in accordance with the RDF language, by a graph comprising two distinct nodes N1 and N2 associated respectively with the concept "X” and concept “CONF Y".
  • the concepts "X” and “conference CONF Y” are associated with different types of data or objects, namely a "PERSON” type ("X") and a CONFERENCE type (“CONF Y CONFERENCE”).
  • the concepts carried by the nodes N1 and N2 are linked by a relation A12 of type "is inscribed with”.
  • the information "X has the date of birth on September 20, 1980” is modeled in accordance with the RDF language by a graph comprising two distinct nodes N3 and N4 associated respectively with the concept "X” and to the concept "September 20, 1980".
  • the concepts "X” and “September 20, 1980” are associated with different data types, namely a PERSON type ("X") and a DATE type ("September 20, 1980”).
  • the concepts carried by nodes N3 and N4 are linked by a relation A34 of type "a for date of birth the".
  • the aggregation by the server 3 of the information data obtained from the sources 5 is thus based on the prior definition of an ontology making it possible to represent these information data in the form of a single graph G, in which a piece of data of information (typically a concept) common to the information sources 5 and to the users considered is represented by means of a single element of the graph, namely of a single node of this graph: one thus avoids to duplicate the concepts under -Coments represented in this graph.
  • a piece of data of information typically a concept
  • This definition of ontology includes the typing of the concepts contained in the information data, that is to say the definition of the types or classes of objects to which the various information data relate, and relations linking these types or classes of objects.
  • This typing of the concepts can be predefined and determined in advance according to the nature of the information that the server 3 expects to receive information sources 5 or the type of information sources 5 requested by the server 3. For example, it may include the following types of concepts: PERSON, DATE, PLACE, CONFERENCE, HOBBY, FRIENDS, etc., and the following relationships "is registered with”, “has for date of birth”, “is at,” “ has for hobby ",” has for friend “, etc.
  • the typing of the concepts can be determined dynamically by the server 3 from an analysis (in particular semantics) of the information data that it receives from the sources 5.
  • this typing can come from information sources 5 themselves if they already use a graphical representation, for example in accordance with RDF language, to model the information data they have on X and Z users.
  • the server 3 analyzes the information data obtained from the sources 5 from the ontology thus previously defined. More specifically, it identifies each concept contained in the information data, and associates with each identified concept a type of ontology concept previously defined. For example, he identifies in the information "X is registered at the conference CONF Y", the concept "X” and the concept “conference CONF Y”, and associates with the concept “X” the type “PERSON” and the concept " conference CONF Y "type” CONFERENCE ".
  • Each node of the graph is connected to one or more other nodes of the graph as a function of the relations linking the concepts to each other in the information data received from the sources 5.
  • FIG. 5C illustrates the aggregation according to the invention of the information data "X is registered at a conference CONF Y" and "X has the date of birth on September 20, 1980".
  • the server 3 identifies the concepts "X” of type “PERSON” (abbreviated as “PERS” in the figure), “conference CONF Y” of the type “CONFERENCE” (abbreviated as “CONF” on the figure) and "September 20, 1980” of type “DATE”.
  • Each distinct concept is associated with a single node of the graph G, namely:
  • CONF Y conference (abbreviated to "CONF Y” in the figure) is associated with node N 2 'which is an instance of type “CONFERENCE” (modeled by link 102' on the graph); and
  • the node ⁇ is connected to the two concepts "CONF Y conference" and "September 20, 1980" via two separate links A12 'and A13' respectively modeling the relations "is registered with” and "has for date of birth on”.
  • FIG. 5D illustrates the aggregation according to the invention of the information data "X is registered at a conference CONF Y" and "Z is registered at a conference CONF Y".
  • the server 3 identifies the concepts "X” and “Z” of type “PERSON” (abbreviated “PERS” in the figure) and “conference CONF Y” type “CONFERENCE” (abbreviated as “CONF” in the figure).
  • Each distinct concept is associated with a single node of the graph G, namely:
  • CONF Y conference (abbreviated to "CONF Y” in the figure) is associated with node N 2 'which is an instance of type “CONFERENCE” (modeled by link 102' on the graph); and
  • This graph is indeed designed so to avoid representing in the graph G several times (in other words using distinct representation elements) common information data (and especially common concepts) to the users. es common information are instead represented by a single node connected users share data.
  • the graph G thus offers a synthetic representation of the information data obtained from the sources 5, and which makes it possible in this form to easily and quickly identify the data common to the users X and Z.
  • the invention is not limited to the use of graphs and other aggregated data structures can be envisaged to represent information data obtained from information sources 5, such as tuples (ie n-tuples) Relational models conventionally used in databases ... These alternative data structures are preferably designed to avoid duplication of elements representing information data common to both users and sources. However, one can also consider having a suboptimal aggregated data structure in which such duplications exist.
  • the server 3 searches in the graph G for information data common to the user X and the user Z (step E50). This search step allows the server 3 to identify opportunities for interaction (that is to say exchange) between the user X holder of the electronic card 2 and the user Z holder thereof.
  • the definition of ontologies and the construction of the graph G advantageously facilitate this search.
  • An opportunity for interaction between the users X and Z is indeed detected by searching graph fragments characteristic of this interaction, ie characteristics of the common data that is sought.
  • the server 3 searches in the graph G for the presence of the sub-graph shown in FIG. 5E, in which the concept or node " ?? Is a CONFERENCE variable.
  • Such a search is performed by the server 3 by applying a specific request to the graph G and defining the desired graph fragment (i.e. characteristic of the common data).
  • This request is expressed, in the embodiment described here, using the SPARQL dedicated language, known per se.
  • this concept must be connected to the users X and Y by links of type "is inscribed at", and be a concept of the type "CONFERENCE” (modeled by the link 10 on the graph fragment of Figure 5D).
  • the server 3 can define requests so as to search for any type of data common to the users X and Z, or conversely, common data that respond to one or more predetermined criteria, decided for example by the user X (eg search for a presence at the same conference while not looking for hobbys data common to both users, for example). It can thus be envisaged that the user X can define or limit, during his subscription or later, the type of interactions that he wishes to be searched by the server.
  • the server 3 here associates with the common data (s) thus detected (s) an opportunity for interaction between users X and Z. It notifies the electronic card 2 of the existence of this opportunity, or of more generally, the existence of data common to users X and Z (step E70).
  • This notification is sent to the electronic card 2 via its communication means 3E on the telecommunications network 4. In the embodiment described here, it is transmitted to the electronic card 2 via the intermediate equipment 6.
  • the electronic card 2 warns the user Z by activating its warning module 2B. In other words, the electronic card 2 lights up if the warning module comprises an LED type diode, or emits a vibration if it includes a buzzer on receipt of the notification of the server 3.
  • the user Z thus informed can then connect for example to a portal managed by the server 3 via the intermediate equipment 6, to learn the meaning of the notification sent by the server 3, including access to further information on the opportunity of exchange with the user X detected by the server 3 (eg nature of the opportunity, namely here presence at a common conference, name of the conference, etc.) - This information can be viewed by the user Z on the screen 6C of the intermediate equipment 6.
  • the user Z can access this information using a device separate from the intermediate equipment 6.
  • the search for information data common to X and Z users is reiterated each time one or more information sources provide the server 3 with new user information data.
  • X and / or on the user Z step E80, and answer yes to step E80 looping back to step E40, from the graph G in which these new information data are integrated.
  • the server 3 can store in memory this opportunity and the information relating thereto emanating from the graph G and signal the existence of this opportunity as soon as it detects the connection of the electronic card 2 to the intermediate equipment 6 or as soon as the electronic card 2 registers with the server 3 again.
  • the electronic card 2 is a hardware card, in other words a physical object.
  • the electronic card 2 may be a virtual card (ie an application), to which software means of communication with the server and of the user holding the message are conferred (eg display of an appropriate symbol, transmission predetermined sound, etc.).

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Information Transfer Between Computers (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Procédé et serveur de notification d'une carte électronique L'invention concerne un procédé de notification, par un serveur d'un réseau de télécommunications, d'une carte électronique associée à un utilisateur titulaire enregistrée auprès de ce serveur, comprenant : - une étape (E20) d'enregistrement d'un utilisateur détenteur de la carte électronique; - une étape (E30,E40) d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur; - une étape (E50) de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues; et - si au moins une donnée d'information commune est détectée, une étape de notification (E70) de la carte électronique via le réseau de télécommunications.

Description

Procédé et serveur de notification d'une carte électronique
Arrière-plan de l'invention
L'invention se rapporte au domaine général des communications.
Elle concerne plus particulièrement le domaine des cartes matérielles (objets physiques) ou virtuelles embarquant des informations sur leurs titulaires. Ces informations sont par exemple des données d'identification telles qu'un nom, une adresse (personnelle ou professionnelle, postale ou électronique), un numéro de téléphone, une photographie, etc.
De telles cartes peuvent être notamment des cartes de visite ou des cartes professionnelles, couramment échangées entre les utilisateurs titulaires de ces cartes auxquels les données présentes sur les cartes se rapportent, et des utilisateurs dits détenteurs ou récepteurs ou encore destinataires de ces cartes auxquels les cartes ont été données par les utilisateurs titulaires.
Dans l'état actuel de la technique, les informations affichées sur ces cartes qu'elles soient matérielles ou virtuelles sont statiques, c'est-à-dire immuables. Ces informations sont également passives dans le sens où la seule interaction possible avec ces informations pour un utilisateur détenteur de la carte est de les lire.
Ces cartes ont par conséquent un usage relativement restreint.
Les possibilités d'interactions par le biais de ces cartes entre les utilisateurs titulaires et détenteurs sont en outre limitées aujourd'hui à des échanges directs entre ces utilisateurs (ex. échanges téléphoniques ou informatiques), à l'initiative de l'utilisateur détenteur sur la base des informations affichées sur la carte.
Objet et résumé de l'invention
L'invention propose d'étendre l'usage des cartes matérielles ou virtuelles embarquant des données relatives à leurs titulaires en leur adjoignant de nouveaux moyens et de nouvelles fonctionnalités visant à faciliter les interactions entre les titulaires et les personnes en possession de ces cartes. Elle s'appuie à cet effet d'une part sur la carte à proprement parler, qui est dotée conformément à l'invention de moyens permettant de notifier l'utilisateur détenteur de cette carte de l'existence d'opportunités d'interaction avec le titulaire de la carte, et d'autre part sur un serveur déployé dans un réseau de télécommunications, communiquant avec la carte et apte à détecter l'existence de telles opportunités.
Au sens de l'invention, on désigne par utilisateur « titulaire » de la carte, l'utilisateur auquel se réfèrent les informations affichées sur la carte, et par utilisateur « détenteur » de la carte, un utilisateur auquel l'utilisateur titulaire a donné sa carte.
L'invention concerne ainsi un procédé de notification, par un serveur d'un réseau de télécommunications, d'une carte électronique associée à un utilisateur titulaire et enregistrée auprès de ce serveur, ce procédé comprenant :
— une étape d'enregistrement d'un utilisateur détenteur (i.e. récepteur) de la carte électronique ; — une étape d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ;
— une étape de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et
— si au moins une donnée d'information commune est détectée, une étape de notification de la carte électronique via le réseau de télécommunications.
Corrélativement, l'invention vise aussi un serveur d'un réseau de télécommunications comprenant :
— un module d'enregistrement, apte à enregistrer une carte électronique associée à un utilisateur titulaire et un utilisateur détenteur de cette carte électronique ;
— un module d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ;
— un module de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et
— un module de notification de la carte électronique via le réseau de télécommunications activé si au moins une donnée d'information commune est détectée par le module de recherche.
L'invention concerne également une carte électronique associée à un utilisateur titulaire et enregistrée auprès d'un serveur, et comprenant :
— un module de communication avec le serveur, agencé pour recevoir une notification émise par le serveur lorsqu'au moins une donnée d'information commune à l'utilisateur titulaire et à un utilisateur détenteur de la carte électronique a été détectée par le serveur ; et
— un module d'avertissement de l'utilisateur détenteur de la carte électronique, activé sur réception de la notification.
Les données d'information relatives à l'utilisateur titulaire et à l'utilisateur détenteur peuvent être de natures très diverses et provenir de sources externes à la carte électronique elle- même. Ainsi, à titre d'exemple, il peut s'agir :
— de données extraites d'un profil de l'utilisateur ;
— de données de localisation de l'utilisateur ;
— de données représentatives d'une activité de l'utilisateur ; et/ou
— de données provenant de serveurs de réseaux sociaux.
Bien entendu, d'autres types de données peuvent être envisagés en variante, en complément ou en remplacement des données précitées.
La recherche de données communes à l'utilisateur titulaire et à l'utilisateur détenteur de la carte permet notamment de détecter l'existence d'une ou de plusieurs opportunités d'échanges entre ces utilisateurs (ex. participation à un événement commun répertorié dans les calendriers des utilisateurs, événements de l'activité de l'utilisateur titulaire porteur d'intérêt pour l'utilisateur détenteur de la carte, etc.). Cette recherche peut consister à identifier n'importe quelles données communes parmi les données d'information recueillies par le serveur, ou en variante, des données communes répondant à un ou plusieurs critères prédéterminés. De tels critères peuvent être notamment choisis par l'utilisateur titulaire de la carte de sorte à filtrer les possibilités d'échanges signalées à l'utilisateur détenteur auquel il a donné sa carte (ex. critère sur la nature professionnelle ou personnelle des données d'information, critère concernant une localisation associée à ces données), ou peuvent dépendre de l'utilisateur détenteur de la carte, etc.
Une fois détectées par le serveur suite à l'enregistrement de l'utilisateur titulaire et de l'utilisateur détenteur, les opportunités d'échanges sont signalées à la carte qui en informe à son tour son détenteur par le biais de son module d'avertissement. Dans l'exemple d'une carte électronique matérielle, ce module d'avertissement peut se présenter notamment sous la forme d'une diode électroluminescente (ou LED (Light Emitting Diode)) ou encore d'un buzzer ou encore d'un module d'avertissement sonore, activé(e) sur réception de la notification du serveur.
Ainsi, l'invention propose de rendre proactive la carte échangée entre l'utilisateur titulaire et l'utilisateur détenteur. Cette carte proactive permet de créer et de maintenir de manière très simple un lien social entre ces deux personnes, de manière transparente pour eux une fois l'enregistrement de l'échange de la carte effectué auprès du serveur.
En outre, l'invention offre la possibilité de préserver la confidentialité des données d'informations recueillies par le serveur sur l'utilisateur titulaire vis-à-vis de l'utilisateur détenteur de la carte. Seul le serveur a en effet besoin d'accéder aux détails de ces données d'information pour effectuer la recherche de données communes aux deux utilisateurs. En revanche, la notification transmise par le serveur à la carte peut avantageusement ne pas contenir ces données, ni contenir de détails sur l'opportunité d'échange sous-jacente à la détection par le serveur de données communes aux utilisateurs.
Il convient de noter qu'avantageusement la carte selon l'invention n'a pas besoin d'être dotée de moyens complexes et coûteux. Il suffit en effet de l'équiper de moyens d'avertissement destinés à notifier le détenteur de la carte et d'un module de communication avec le serveur pour être informée de l'existence de données communes à la personne titulaire et identifiée sur la carte et au détenteur de cette carte.
Dans le cas d'une carte électronique matérielle (i.e. carte physique), ce module de communication peut comprendre un module de connexion directe au réseau de télécommunications du serveur, ou en variante comprendre un module de connexion à un équipement intermédiaire relié au réseau de télécommunications du serveur via lequel la notification émise par le serveur est reçue. Le module de connexion peut intégrer par exemple un module de radio-identification (aussi connu sous l'appellation de module RFID pour Radio Frequency IDentification en anglais), ou un port USB, etc. L'équipement intermédiaire peut être notamment un lecteur ou une borne dédiée au couplage avec la carte, ou en variante, un ordinateur muni d'un port de communication compatible avec le module de connexion de la carte.
Il est ainsi possible de conserver un format peu encombrant pour la carte, compatible avec les formats existants de cartes professionnelles ou de cartes de visite. Une telle carte électronique matérielle présente l'avantage d'être tangible pour les utilisateurs. L'utilisateur détenteur de la carte peut ensuite se connecter à un site web ou un portail alimenté par le serveur pour obtenir de plus amples informations sur l'opportunité d'échange ou plus généralement sur les données communes détectées par le serveur à proprement parler. L'accès à ces données peut être configuré par l'utilisateur titulaire afin de filtrer les informations communiquées à l'utilisateur détenteur.
L'invention a ainsi une application privilégiée mais non limitative dans le domaine de l'Internet des objets, qui vise à associer à des objets réels des interfaces intelligentes pour se connecter et communiquer au sein de contextes d'usages variés, via des réseaux de télécommunications tels que le réseau Internet.
Il convient toutefois de noter que l'invention peut également s'appliquer à une carte électronique de type virtuelle (i.e. une application), à laquelle sont conférés des moyens logiciels de communication avec le serveur et d'avertissement de l'utilisateur détenteur (ex. affichage d'un symbole approprié, émission d'un son prédéterminé, etc.).
Dans un mode particulier de réalisation de l'invention, le procédé selon l'invention comprend en outre une étape d'agrégation des données d'information obtenues relatives à l'utilisateur titulaire et des données d'information obtenues relatives à l'utilisateur détenteur dans une structure de données conçue pour représenter de façon unique des données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur tout en les associant à chacun d'entre eux.
Une telle structure de données est par exemple modélisée par un graphe.
Les graphes sont des outils puissants permettant de représenter aisément et de façon synthétique des données d'information, et notamment les concepts contenus dans ces données ainsi que les relations liant ces concepts entre eux. L'ensemble des concepts et des relations liant ces concepts entre eux est aussi connu sous le nom d'ontologie. Par exemple, des données d'information selon lesquelles « X est inscrit à une conférence CONF Y » peuvent être modélisées par un graphe comprenant deux nœuds associés respectivement au concept « X » et au concept « conférence CONF Y », et un arc reliant ces deux nœuds ayant pour signification « est inscrit à ».
L'étape d'agrégation peut ainsi avantageusement comprendre une analyse des données d'information obtenues à partir d'une ontologie préalablement définie comprenant une pluralité de types de concepts représentant les données d'informations et de relations liant ces concepts.
Cette étape d'agrégation permet de fusionner les données d'information en préservant l'unicité des concepts sous-jacents contenus dans ces données. De cette sorte, la duplication dans la structure des données agrégées des représentations des données d'information communes aux utilisateurs est évitée. La structure des données agrégées qui en résulte est ainsi avantageusement synthétique. Ainsi, dans l'exemple d'une structure de données modélisée par un graphe, l'étape d'agrégation consiste par exemple à élaborer un graphe dont les nœuds (ou sommets) et les arcs sont déduits des données d'information du titulaire et du détenteur de la carte, chaque nœud étant associé à un concept distinct. A titre illustratif, s'ils résultent des données obtenues par le serveur que X, titulaire de la carte, est inscrit à une conférence CONF Y, et que Z, détenteur de la carte, est également inscrit à la même conférence CONF Y, le graphe construit lors de l'étape d'agrégation contient un seul nœud associé à la conférence CONF Y reliés via deux arcs distincts aux nœuds associés aux utilisateurs « X » et « Z ».
Grâce à l'étape d'agrégation, la recherche d'éléments communs parmi les données d'information obtenues relatives au titulaire et au détenteur de la carte est grandement facilitée. De même, la recherche d'éléments communs spécifiques, caractérisant un type d'interaction particulier ou encore un concept particulier, peut être mise en œuvre aisément en recherchant un fragment de la structure de données correspondant à ce type d'interaction.
En outre, ce mode de réalisation permet de s'appuyer sur des langages (ou modèles) existants de description de ressources et de requête. Ainsi, notamment, l'usage du langage de description RDF (Resource Description Framework) couramment utilisé pour décrire des ressources Web et leurs métadonnées, ou d'un langage de description dérivé de RDF, et du langage de requête SPARQL (SPARQL Protocol and RDF Query Language) permettant d'interroger les modèles RDF peuvent être envisagés pour mettre en œuvre les étapes d'obtention, le cas échéant d'agrégation, et de recherche de l'invention.
Bien entendu, l'invention ne se limite pas à l'utilisation des langages précités, et d'autres langages comme le langage de requête SQL (Structured Query Language) ou encore des langages de description et de requête propriétaires peuvent être utilisés.
Dans un mode particulier de réalisation de l'invention, suite à l'obtention de nouvelles données d'information relatives à l'utilisateur titulaire et/ou à l'utilisateur détenteur, les étapes de recherche et le cas échéant de notification sont réitérées en tenant compte des nouvelles données d'information obtenues.
L'obtention de nouvelles données d'information peut se faire à l'initiative du serveur, ou en variante, en mode push, dès lors que de nouvelles données d'information concernant le titulaire ou le détenteur de la carte sont détectées par les sources hébergeant ces données et qu'elles en informent le serveur (par exemple suite à une souscription du serveur auprès de ces sources d'information).
L'invention permet ainsi d'offrir au détenteur de la carte des informations pertinentes concernant le titulaire, mises à jour en temps réel.
Dans un mode particulier de réalisation, les différentes étapes du procédé de notification sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de notification tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention vise également un système comprenant un serveur et une carte électronique conformes à l'invention.
Cette carte électronique peut être matérielle ou virtuelle.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de notification, le serveur, la carte électronique et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures :
— la figure 1 représente, de façon schématique, un système, un serveur et une carte électronique conformes à l'invention dans un mode particulier de réalisation ;
— la figure 2 illustre de façon schématique l'architecture de la carte électronique de la figure 1 ;
— la figure 3 illustre, de façon schématique, l'architecture matérielle du serveur de la figure 1 ;
— la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de notification selon l'invention telles que mises en œuvre par le serveur de la figure 1, dans un mode particulier de réalisation ;
— les figures 5A-5E illustrent des exemples de graphes et d'une requête sur un graphe pouvant être utilisés par le serveur de la figure 1. Description détaillée de rinvention
La figure 1 représente, dans son environnement, un système 1 conforme à l'invention dans un mode particulier de réalisation.
Dans l'exemple envisagé à la figure 1, le système 1 permet de créer et de maintenir un lien social entre deux utilisateurs X et Z via l'échange d'une carte de visite électronique 2 proactive, conforme à l'invention, sur laquelle sont affichées des données d'identification relatives à l'utilisateur X (ex. le nom de l'utilisateur, son adresse personnelle ou professionnelle, etc.). La carte électronique 2 est ici une carte matérielle. L'utilisateur X est un utilisateur titulaire de la carte électronique 2 au sens de l'invention, qui a donné sa carte de visite électronique 2 à l'utilisateur Z. L'utilisateur Z est donc un utilisateur détenteur de la carte électronique 2 au sens de l'invention.
Pour créer et maintenir ce lien social, le système 1 s'appuie sur la carte électronique 2 confiée par l'utilisateur X à l'utilisateur Z, et sur un serveur 3 conforme à l'invention, relié à un réseau de télécommunications 4. Le réseau de télécommunications 4 est par exemple ici le réseau public Internet. Toutefois aucune limitation n'est attachée à la nature du réseau 4 ; il peut s'agir aussi bien d'un réseau fixe ou mobile, public ou propriétaire, filaire ou sans fil, etc.
Le serveur 3 est adapté, conformément à l'invention, à agréger et à corréler des données d'information relatives à l'utilisateur X et à l'utilisateur Z mises à sa disposition par différentes sources d'information 5 afin d'identifier des données communes susceptibles de créer des opportunités d'échange entre les deux utilisateurs, et à notifier la carte électronique 2 détenue par l'utilisateur Z de l'existence de telles opportunités le cas échéant. On suppose à cet effet que l'utilisateur X a souscrit au service offert par le serveur 3 et enregistré auprès de celui-ci, lors de sa souscription, la carte électronique 2 ainsi qu'éventuellement d'autres cartes électroniques à son nom, identiques à la carte électronique 2, et destinées à de futurs contacts. Chaque carte électronique est identifiée lors de cet enregistrement par un identifiant ou un code ID : ainsi, la carte électronique 2 est associée à l'utilisateur X auprès du serveur 3 et identifiée par un identifiant ID2.
Aucune limitation n'est attachée aux sources d'information 5 alimentant le serveur 3 en données d'information. Ces sources d'information peuvent être maintenues par le serveur 3 ou en variante par des tiers et communiquer avec le serveur 3 par le biais d'un réseau de télécommunications tel que le réseau de télécommunications 4. En outre, les données d'information fournies par les sources 5 peuvent être de différentes natures. Il peut s'agir notamment, de façon non exhaustive :
— de données d'information extraites de profils utilisateurs (ex. âge, profession, intérêts professionnels et/ou personnels, employeur, compétences, etc.), maintenus par exemple par le serveur 3 ou par les opérateurs de réseaux fixes ou mobiles auprès desquels ont souscrit les utilisateurs X et Z et avec lequel le serveur 3 possède un partenariat ; — de données d'information de localisation des utilisateurs X et Z, fournies par exemple au serveur 3, le cas échéant, par les opérateurs des réseaux mobiles des utilisateurs X et Z ;
— de données d'information représentatives d'une activité des utilisateurs X et Z, poussées vers le serveur 3 par une application de calendrier électronique utilisée par les utilisateurs X et Z (ex. en association avec leur messagerie électronique) ;
— de données provenant de serveurs gérant des réseaux sociaux ;
— etc.
Le choix des sources d'information 5 peut être décidé par le serveur 3 (en d'autres mots, par l'opérateur du service offert par le serveur 3), ou en variante être configuré par l'utilisateur X en fonction de ses préférences. Il peut également être configuré par l'utilisateur X de sorte à dépendre de l'utilisateur Z (en fonction notamment des informations que l'utilisateur X souhaite rendre accessibles à l'utilisateur Z ou des opportunités qu'il souhaite avoir avec l'utilisateur Z).
Dans le mode de réalisation décrit ici, le serveur 3 communique avec la carte électronique 2 par le biais d'un équipement intermédiaire 6. Dans l'exemple envisagé à la figure 1, l'équipement intermédiaire 6 est un ordinateur personnel appartenant à l'utilisateur Z, et équipé d'un module de connexion 6A avec la carte électronique 2, de moyens 6B de communication sur le réseau 4, et d'un écran 6C. Le module de connexion 6A est par exemple un port ou une prise USB (Universal Sériai Bus), ou encore un module de communication sans fil courte distance utilisant par exemple la technologie RFID (Radio Frequency Identification) ou Bluetooth, etc. L'équipement intermédiaire 6 joue le rôle de relai des notifications transmises par le serveur 3 à la carte électronique 2.
En variante, l'équipement intermédiaire 6 peut être un lecteur de cartes dédié comprenant des moyens 6A de connexion avec la carte électronique 2 et des moyens 6B de communication sur le réseau 4.
La carte électronique 2 est équipée d'un module de connexion compatible avec le module de connexion 6A de l'équipement intermédiaire 6. La figure 2 illustre schématiquement l'architecture de la carte électronique 2 matérielle confiée par l'utilisateur X à l'utilisateur Z. Dans l'exemple illustré à la figure 2, la carte électronique 2 a le format d'une carte de visite, et comprend :
— une zone d'affichage 2A des données d'identification de l'utilisateur X ;
— un module d'avertissement 2B, situé sur la surface externe de la carte électronique 2, et comprenant par exemple un buzzer ou une diode électroluminescente pour signaler à l'utilisateur Z la réception d'une notification du serveur 3 ; et
— un module de communication 2C incluant ici le module de connexion compatible avec le module de connexion 6A de l'équipement intermédiaire 6 (prise ou port USB, module RFID ou Bluetooth, etc. en fonction de la nature du module de connexion 6A). Dans une variante de réalisation, la carte électronique 2 est apte à communiquer directement avec le serveur 3 par le biais du réseau de télécommunications 4 sans nécessiter d'équipement intermédiaire tel que l'équipement 6. Le module de communication 2C intègre alors un module de connexion au réseau de télécommunications 4 ou à un réseau relié au réseau de télécommunications 4.
Bien entendu, la carte électronique 2 peut revêtir d'autres formes que celle illustrée schématiquement à la figure 2. Elle peut en outre intégrer d'autres moyens complémentaires, comme par exemple un microprocesseur ou un circuit logique programmable, une ou plusieurs mémoires lui permettant de stocker des informations transmises notamment par le serveur 3, un écran lui permettant d'afficher des informations, etc.
Dans le mode de réalisation décrit ici, le serveur 3 a l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 3. Il comprend notamment un processeur 3A, une mémoire morte 3B, une mémoire vive 3C, une mémoire non volatile 3D et des moyens de communication 3E sur le réseau de télécommunications 4. La mémoire morte 3B du serveur 3 constitue un support d'enregistrement lisible par le processeur 3A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de notification conforme à l'invention, les étapes de ce procédé de notification étant décrites ultérieurement en référence à la figure 4 dans un mode particulier de réalisation.
Ce programme d'ordinateur définit de façon équivalente des modules fonctionnels
(logiciels) du serveur 3, tels que notamment un module d'enregistrement de la carte électronique 2 et de l'utilisateur Z détenteur de la carte électronique 2, un module d'obtention de données d'information relatives à l'utilisateur X et à l'utilisateur Z auprès des sources d'information 5 et un module d'agrégation de ces données, un module de recherche de données communes aux utilisateurs X et Z parmi les données agrégées et un module de notification de la carte électronique 2 le cas échéant. Les modules d'obtention et de notification utilisent notamment les moyens de communication 3E sur le réseau de télécommunications 4 du serveur 3. Les fonctions de ces divers modules sont décrites plus en détail en référence aux étapes du procédé de notification illustrées à la figure 4.
Nous allons maintenant décrire, en référence à la figure 4, les principales étapes du procédé de notification selon l'invention telles que mises en œuvre par le serveur 3 de la figure 1 dans un mode particulier de réalisation.
Comme mentionné précédemment, on suppose au préalable que l'utilisateur X a souscrit au service offert par le serveur 3. Il a, lors de cette souscription, enregistré auprès du serveur 3 (i.e. du module d'enregistrement du serveur 3) la carte électronique 2 en fournissant son identifiant ID2 (étape E10), ainsi qu'éventuellement d'autres cartes électroniques identiques à la carte électronique 2 et qu'il destine à d'autres utilisateurs. On suppose par ailleurs que l'utilisateur X donne sa carte électronique 2 à l'utilisateur Z, et que celui-ci s'enregistre auprès du module d'enregistrement du serveur 3 (étape E20). Lors de cet enregistrement, l'utilisateur Z fournit l'identifiant ID2 de la carte électronique 2 ainsi que son propre identifiant (ex. un nom et/ou un numéro de téléphone, etc.).
Suite à cet enregistrement, le serveur 3 envoie, via le réseau de télécommunications
4, une requête identifiant les utilisateurs X et Z aux sources d'informations 5, afin d'obtenir les données d'information relatives à ces utilisateurs dont disposent les sources 5. Cette requête peut prendre la forme d'une souscription auprès de tout ou partie des sources 5, afin qu'elles transmettent de leur propre initiative au serveur 3 (c'est-à-dire en mode push) les données d'informations relatives aux utilisateurs X et Z dont elles disposent dès qu'elles obtiennent ces données ou dès que celles-ci sont mises à jour.
En variante, la requête du serveur 3 peut être réitérée de manière périodique ou prédéterminée afin de disposer de données d'information pertinentes et à jour provenant des sources 5 sur les utilisateurs X et Z.
Le serveur 3 obtient ainsi des sources d'information 5, via son module logiciel d'obtention, les données d'information dont ces sources disposent sur les utilisateurs X et Z (étape E30).
Dans le mode de réalisation décrit ici, le serveur 3 agrège les données d'information reçues des différentes sources d'information 5 sous la forme d'un graphe G conforme au langage de description RDF. Ce langage est décrit notamment dans le document RDF - Semantic Web Standards disponible sur le site www.vv3.org/RDF.
De façon connue, le langage RDF décrit toute information sous la forme d'un modèle et plus précisément d'un graphe, représentant les concepts impliqués dans cette information ainsi que les relations liant ces concepts entre eux. A titre illustratif, si l'information considérée est « X est inscrit à une conférence CONF Y », les concepts impliqués dans cette information sont « X » et « conférence CONF Y », et la relation liant ces concepts est « est inscrit à ».
Plus spécifiquement, afin de garantir la cohérence et la bonne interprétation des modèles, le langage RDF s'appuie sur la définition et l'utilisation d'ontologies, qui sont elles-mêmes des modèles RDF définissant des types de données ou d'objets dont les concepts contenus dans chaque information relèvent. Une ontologie, dans un contexte informatique, désigne une conceptualisation d'un domaine de connaissances. Par conceptualisation, on entend ici la définition des termes qui sont nécessaires pour exprimer le sens d'une information relevant de ce domaine et les propriétés de ces termes. Les termes incluent les types d'objet (ou classes) et les relations entre ces types d'objet. Une propriété d'une relation est par exemple sa transitivité.
Autrement dit, une ontologie désigne à la fois un choix quant à la manière de décrire un domaine, et la description formelle de ce domaine. Les ontologies sont couramment utilisées dans des domaines tels que l'intelligence artificielle, le web sémantique, le génie logiciel, etc. Les figures 5A et 5B illustrent deux exemples de graphes conformes au langage RDF modélisant respectivement une information (ou de façon équivalente un ensemble de données d'information au sens de l'invention) stipulant que « X est inscrit à une conférence CONF Y » et une information stipulant « X est né le 20 septembre 1980 ».
Plus précisément, en référence à la figure 5A, l'information « X est inscrit à une conférence CONF Y » est modélisée, conformément au langage RDF, par un graphe comportant deux nœuds distincts NI et N2 associés respectivement au concept « X » et au concept « CONF Y ». Les concepts « X » et « conférence CONF Y » sont associés à des types de données ou d'objets différents, à savoir un type « PERSONNE » (« X ») et un type CONFERENCE (« conférence CONF Y). Les concepts portés par les nœuds NI et N2 sont liés par une relation A12 de type « est inscrit à ».
De façon similaire, en référence à la figure 5B, l'information « X a pour date de naissance le 20 septembre 1980 » est modélisée conformément au langage RDF par un graphe comportant deux nœuds distincts N3 et N4 associés respectivement au concept « X » et au concept « 20 septembre 1980 ». Les concepts « X » et « 20 septembre 1980 » sont associés à des types de données différents, à savoir un type PERSONNE (« X ») et un type DATE (« 20 septembre 1980 »). Les concepts portés par les nœuds N3 et N4 sont liés par une relation A34 de type « a pour date de naissance le ».
L'agrégation par le serveur 3 des données d'information obtenues des sources 5 repose ainsi sur la définition préalable d'une ontologie permettant de représenter ces données d'information sous la forme d'un unique graphe G, dans lequel une donnée d'information (typiquement un concept) commune aux sources d'information 5 et aux utilisateurs considérés est représentée à l'aide d'un unique élément du graphe, à savoir d'un unique nœud de ce graphe : on évite ainsi de dupliquer les concepts sous-jacents représentés dans ce graphe.
Cette définition de l'ontologie comprend le typage des concepts contenus dans les données d'information, c'est-à-dire la définition des types ou des classes d'objets auxquels se rapportent les différentes données d'information, et des relations liant ces types ou classes d'objets. Ce typage des concepts peut être prédéfini et déterminé préalablement en fonction de la nature des informations que le serveur 3 s'attend à recevoir des sources d'information 5 ou du type de sources d'information 5 sollicitées par le serveur 3. Ainsi par exemple, il peut comprendre les types de concepts suivants : PERSONNE, DATE, LIEU, CONFERENCE, HOBBY, AMIS, etc., et les relations suivantes « est inscrit à », « a pour date de naissance », « se trouve à », « a pour hobby », « a pour ami », etc.
En variante, le typage des concepts peut être déterminé de manière dynamique par le serveur 3 à partir d'une analyse (notamment sémantique) des données d'informations qu'il reçoit des sources 5.
Dans une autre variante encore, ce typage peut provenir des sources d'information 5 elles-mêmes si celles-ci utilisent déjà une représentation graphique, par exemple conforme au langage RDF, pour modéliser les données d'information dont elles disposent sur les utilisateurs X et Z.
Dans une autre variante encore, une combinaison des variantes précitées peut être envisagée.
Lors de l'agrégation des données d'information, le serveur 3 analyse les données d'information obtenues des sources 5 à partir de l'ontologie ainsi préalablement définie. Plus spécifiquement, il identifie chaque concept contenu dans les données d'informations, et associe à chaque concept identifié un type de concept de l'ontologie préalablement définie. Par exemple, il identifie dans l'information « X est inscrit à la conférence CONF Y », le concept « X » et le concept « conférence CONF Y », et associe au concept « X » le type « PERSONNE » et au concept « conférence CONF Y » le type « CONFERENCE ».
Il détermine par ailleurs les relations liant les concepts ainsi identifiés entre eux.
Puis le serveur 3 construit un unique graphe G à partir des concepts et des relations ainsi identifiés, dans lequel :
— chaque concept distinct est associé à un unique nœud ;
— chaque nœud du graphe est relié à un ou plusieurs autres nœuds du graphe en fonction des relations liant les concepts entre eux dans les données d'information reçues des sources 5.
La figure 5C illustre l'agrégation conformément à l'invention des données d'information « X est inscrit à une conférence CONF Y » et « X a pour date de naissance le 20 septembre 1980 ».
Dans ces données d'information, le serveur 3 identifie les concepts « X » de type « PERSONNE » (abrégé en « PERS » sur la figure), « conférence CONF Y » de type « CONFERENCE » (abrégé en « CONF » sur la figure) et « 20 septembre 1980 » de type « DATE ». Chaque concept distinct est associé à un nœud unique du graphe G, à savoir :
— « X » est associé au nœud Nl' qui est une instance de type « PERSONNE » (modélisé par la liaison ΙΟ sur le graphe) ;
— « conférence CONF Y » (abrégé en « CONF Y » sur la figure) est associé au nœud N2' qui est une instance de type « CONFERENCE » (modélisé par la liaison 102' sur le graphe) ; et
— « 20 septembre 1980 » (abrégé en « 20 sept 1980 » sur la figure) est associé au nœud N3' qui est une instance de type « DATE » (modélisé par la liaison 103' sur le graphe).
Le nœud Ν est relié aux deux concepts « conférence CONF Y » et « 20 septembre 1980 » via deux liaisons A12' et A13' distinctes modélisant respectivement les relations « est inscrit à » et « a pour date de naissance le ».
Selon un autre exemple, la figure 5D illustre l'agrégation conformément à l'invention des données d'information « X est inscrit à une conférence CONF Y » et « Z est inscrit à une conférence CONF Y ».
Dans ces données d'information, le serveur 3 identifie les concepts « X » et « Z » de type « PERSONNE » (abrégé en « PERS » sur la figure) et « conférence CONF Y » de type « CONFERENCE » (abrégé en « CONF » sur la figure). Chaque concept distinct est associé à un nœud unique du graphe G, à savoir :
— « X » est associé au nœud Nl' qui est une instance de type « PERSONNE » (modélisé par la liaison ΙΟ sur le graphe) ;
— « conférence CONF Y » (abrégé en « CONF Y » sur la figure) est associé au nœud N2' qui est une instance de type « CONFERENCE » (modélisé par la liaison 102' sur le graphe) ; et
— « Z » est associé au nœud NI" qui est une instance de type « PERSONNE » (modélisé par la liaison 101" sur le graphe).
Le concept « conférence CONF Y » est commun aux deux utilisateurs X et Z. Le nœud N2' est ainsi relié aux deux concepts « X » et « Z » via deux liaisons A12' et A12" distinctes modélisant respectivement la relation « est inscrit à ». Ainsi selon cet exemple la duplication des concepts communs est évitée. Il convient de noter en revanche que ceci ne s'applique pas ici aux relations liant les concepts entre eux (ex. deux liaisons distinctes A12' et A12" relient les nœuds Ν et NI" au nœud N2 .Le graphe G construit par le serveur 3 est une structure de données conçue avantageusement pour représenter de manière unique les différents concepts contenus dans les données d'information reçues des sources 5. Ce graphe est en effet conçu de manière à éviter de représenter plusieurs fois dans le graphe G (autrement dit à l'aide d'éléments de représentation distincts) des données d'information communes (et notamment des concepts communs) aux utilisateurs. Ces données d'information communes sont au contraire représentées par un unique nœud relié aux utilisateurs partageant ces données. Le graphe G offre ainsi une représentation synthétique des données d'information obtenues des sources 5, et qui permet sous cette forme d'identifier aisément et rapidement les données communes aux utilisateurs X et Z.
Il convient de noter que l'invention ne se limite toutefois pas à l'utilisation de graphes et d'autres structures de données agrégées peuvent être envisagées pour représenter les données d'information obtenues des sources d'information 5, comme par exemple des tuples (i.e. n-uplets) de modèles relationnels utilisés classiquement dans les bases de données... Ces structures de données alternatives sont préférentiellement conçues de manière à éviter une duplication des éléments représentant des données d'information communes aux deux utilisateurs et aux sources. Toutefois, on peut également envisager d'avoir une structure de données agrégées sous optimale dans laquelle de telles duplications existent.
Suite à l'étape d'agrégation, le serveur 3 recherche dans le graphe G des données d'information communes à l'utilisateur X et à l'utilisateur Z (étape E50). Cette étape de recherche permet au serveur 3 d'identifier des opportunités d'interaction (c'est-à-dire d'échange) entre l'utilisateur X titulaire de la carte électronique 2 et l'utilisateur Z détenteur de celle-ci.
Comme mentionné précédemment, la définition d'ontologies et la construction du graphe G facilitent avantageusement cette recherche. Une opportunité d'interaction entre les utilisateurs X et Z est en effet détectée en recherchant des fragments de graphe caractéristiques de cette interaction, autrement dit caractéristiques des données communes que l'on recherche. Ainsi, à titre d'exemple, pour détecter une inscription commune des utilisateurs X et Z à une même conférence, le serveur 3 recherche dans le graphe G la présence du sous-graphe illustré à la figure 5E, dans lequel le concept ou nœud « ?? » est une variable de type « CONFERENCE ».
Une telle recherche est réalisée par le serveur 3 en appliquant une requête spécifique au graphe G et définissant le fragment de graphe recherché (i.e. caractéristique des données communes). Cette requête est exprimée, dans le mode de réalisation décrit ici, à l'aide du langage dédié SPARQL, connu en soi. Le concept représenté par la variable « ?? » peut s'identifier à n'importe quel concept du graphe pourvu que les relations qui le lient à ses nœuds voisins soient identiques à celles du fragment défini dans la requête. Ainsi, dans l'exemple illustré à la figure 5D, ce concept doit être relié aux utilisateurs X et Y par des liaisons de type « est inscrit à », et être un concept de type « CONFERENCE » (modélisée par la liaison 10 sur le fragment de graphe de la figure 5D).
Bien entendu cet exemple n'est donné qu'à titre illustratif, et d'autres occurrences peuvent être recherchées dans le graphe G de sorte à identifier des données d'information communes à l'utilisateur X et à l'utilisateur Z.
Il convient de noter que le serveur 3 peut définir des requêtes de sorte à chercher tout type de données communes aux utilisateurs X et Z, ou au contraire, des données communes répondant à un ou plusieurs critères prédéterminés, décidés par exemple par l'utilisateur X (ex. recherche d'une présence à une même conférence tandis que ne sont pas recherchées des données relatives à des hobbys communs aux deux utilisateurs par exemple). On peut ainsi envisager que l'utilisateur X puisse définir ou limiter, lors de sa souscription ou ultérieurement, le type d'interactions qu'il souhaite être recherchées par le serveur.
Par ailleurs, plusieurs requêtes portant sur des types de concepts distincts par exemple peuvent être appliquées par le serveur 3 au graphe G.
Si l'application par le serveur 3 d'une telle requête retourne un résultat positif
(réponse oui à l'étape test E60), autrement dit si le fragment de graphe défini dans la requête est présent dans le graphe G, cela signifie qu'il existe dans le graphe G au moins une donnée commune aux utilisateurs X et Z conforme à ce fragment de graphe. La réponse à la requête fournit le concept commun aux utilisateurs X et Z, c'est-à-dire, dans l'exemple de la figure 5D, le concept commun de type « CONFERENCE » auquel la variable « ?? » de la requête a été identifiée, autrement dit encore, la conférence commune à laquelle sont inscrits les utilisateurs X et Z.
Le serveur 3 associe ici à la ou aux donnée(s) commune(s) ainsi détectée(s) une opportunité d'interaction entre les utilisateurs X et Z. Il notifie la carte électronique 2 de l'existence de cette opportunité, ou de manière plus générale, de l'existence de données communes aux utilisateurs X et Z (étape E70). Cette notification est envoyée à la carte électronique 2 via ses moyens de communication 3E sur le réseau de télécommunications 4. Dans le mode de réalisation décrit ici, elle est transmise à la carte électronique 2 par le biais de l'équipement intermédiaire 6. Sur réception de cette notification, la carte électronique 2 avertit l'utilisateur Z en activant son module d'avertissement 2B. Autrement dit, la carte électronique 2 s'allume si le module d'avertissement comprend une diode de type LED, ou émet une vibration si celui-ci comprend un buzzer sur réception de la notification du serveur 3.
L'utilisateur Z ainsi averti peut ensuite se connecter par exemple à un portail géré par le serveur 3 via l'équipement intermédiaire 6, pour prendre connaissance de la signification de la notification adressée par le serveur 3, et notamment accéder à de plus amples informations sur l'opportunité d'échange avec l'utilisateur X détectée par le serveur 3 (ex. nature de l'opportunité, à savoir ici présence à une conférence commune, nom de la conférence, etc.)- Ces informations peuvent être visualisées par l'utilisateur Z sur l'écran 6C de l'équipement intermédiaire 6.
En variante, l'utilisateur Z peut accéder à ces informations à l'aide d'un dispositif distinct de l'équipement intermédiaire 6.
Dans le mode de réalisation décrit ici, la recherche de données d'information communes aux utilisateurs X et Z est réitérée à chaque fois qu'une ou plusieurs sources d'information 5 fournit au serveur 3 de nouvelles données d'informations sur l'utilisateur X et/ou sur l'utilisateur Z (étape E80, et réponse oui à l'étape E80 rebouclant sur l'étape E40), à partir du graphe G dans lequel ces nouvelles données d'informations sont intégrées.
On note que lorsqu'une opportunité d'échange est détectée par le serveur 3 alors que la carte électronique 2 n'est pas connectée à l'équipement intermédiaire 6, et ne peut ainsi pas recevoir la notification du serveur 3, le serveur 3 peut stocker en mémoire cette opportunité ainsi que les informations s'y rapportant émanant du graphe G et signaler l'existence de cette opportunité dès qu'elle détecte la connexion de la carte électronique 2 à l'équipement intermédiaire 6 ou dès que la carte électronique 2 s'enregistre de nouveau auprès du serveur 3.
Dans le mode de réalisation décrit ici, la carte électronique 2 est une carte matérielle, autrement dit un objet physique. En variante, la carte électronique 2 peut être une carte virtuelle (i.e. une application), à laquelle sont conférés des moyens logiciels de communication avec le serveur et d'avertissement de l'utilisateur détenteur (ex. affichage d'un symbole approprié, émission d'un son prédéterminé, etc.).

Claims

REVENDICATIONS
1. Procédé de notification, par un serveur (3) d'un réseau de télécommunications, d'une carte électronique (2) associée à un utilisateur titulaire (X) et enregistrée auprès de ce serveur, ledit procédé comprenant :
— une étape (E20) d'enregistrement d'un utilisateur détenteur (Z) de la carte électronique ;
— une étape (E30,E40) d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ;
— une étape (E50) de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et
— si au moins une donnée d'information commune est détectée, une étape de notification (E70) de la carte électronique via le réseau de télécommunications.
2. Procédé selon la revendication 1 comprenant en outre une étape d'agrégation (E40) des données d'information obtenues relatives à l'utilisateur titulaire et des données d'information obtenues relatives à l'utilisateur détenteur dans une structure de données conçue pour représenter de façon unique les données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur tout en les associant à chacun d'entre eux.
3. Procédé selon la revendication 2 dans laquelle la structure de données est modélisée par un graphe (G).
4. Procédé selon la revendication 2 ou 3 dans lequel l'étape d'agrégation comprend une analyse des données d'information obtenues à partir d'une ontologie préalablement définie comprenant une pluralité de types de concepts représentant les données d'informations et de relations liant ces concepts.
5. Procédé selon la revendication 3 ou 4 dans laquelle le graphe est conforme au langage de description RDF (Resource Description Framework) ou à un langage dérivé du langage RDF.
6. Procédé selon l'une quelconque des revendications 1 à 5 dans lequel, suite à l'obtention (E80) de nouvelles données d'information relatives à l'utilisateur titulaire et/ou à l'utilisateur détenteur, les étapes de recherche et le cas échéant de notification sont réitérées en tenant compte des nouvelles données d'information obtenues.
7. Procédé selon l'une quelconque des revendications 1 à 6 dans lequel les données d'information relatives à l'utilisateur titulaire et/ou à l'utilisateur détenteur sont sélectionnées parmi au moins :
— des données extraites d'un profil de l'utilisateur ;
— des données de localisation de l'utilisateur ;
— des données représentatives d'une activité de l'utilisateur ;
— des données provenant de serveurs de réseaux sociaux.
8. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par un ordinateur.
9. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de notification selon l'une quelconque des revendications 1 à 7.
10. Serveur (3) d'un réseau de télécommunications comprenant :
— un module d'enregistrement, apte à enregistrer une carte électronique (2) associée à un utilisateur titulaire (X) et un utilisateur détenteur (Z) de cette carte électronique ;
— un module d'obtention de données d'information relatives à l'utilisateur titulaire et de données d'information relatives à l'utilisateur détenteur ;
— un module de recherche de données d'information communes à l'utilisateur titulaire et à l'utilisateur détenteur parmi les données d'informations obtenues ; et
— un module de notification de la carte électronique via le réseau de télécommunications (4) activé si au moins une donnée d'information commune est détectée par le module de recherche.
11. Carte électronique (2) associée à un utilisateur titulaire et enregistrée auprès d'un serveur comprenant :
— un module de communication (2C) avec le serveur, agencé pour recevoir une notification émise par le serveur lorsqu'au moins une donnée d'information commune à l'utilisateur titulaire et à un utilisateur détenteur de la carte électronique a été détectée par le serveur ; et
— un module d'avertissement (2B) de l'utilisateur détenteur de la carte électronique, activé sur réception de ladite notification.
12. Carte électronique selon la revendication 11 dans lequel le module de communication comprend un module de connexion audit réseau de télécommunications dudit serveur.
13. Carte électronique selon la revendication 11 dans lequel le module de communication comprend un module de connexion à un équipement intermédiaire relié au réseau de télécommunications du serveur via lequel ladite notification du serveur est reçue.
14. Système (1) comprenant :
— un serveur (2) selon la revendication 10 ; et
— une carte électronique (2) selon l'une quelconque des revendications 11 à 13.
15. Système selon la revendication 14 dans lequel la carte électronique est une carte électronique matérielle.
EP14821728.4A 2013-11-29 2014-11-21 Procédé et serveur de notification d'une carte électronique Ceased EP3074931A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1361870A FR3014220A1 (fr) 2013-11-29 2013-11-29 Procede et serveur de notification d'une carte electronique
PCT/FR2014/052991 WO2015079145A1 (fr) 2013-11-29 2014-11-21 Procédé et serveur de notification d'une carte électronique

Publications (1)

Publication Number Publication Date
EP3074931A1 true EP3074931A1 (fr) 2016-10-05

Family

ID=50482939

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14821728.4A Ceased EP3074931A1 (fr) 2013-11-29 2014-11-21 Procédé et serveur de notification d'une carte électronique

Country Status (5)

Country Link
US (1) US20170004458A1 (fr)
EP (1) EP3074931A1 (fr)
CN (1) CN106415617B (fr)
FR (1) FR3014220A1 (fr)
WO (1) WO2015079145A1 (fr)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7051086B2 (en) * 1995-07-27 2006-05-23 Digimarc Corporation Method of linking on-line data to printed documents
FR2750334B1 (fr) * 1996-07-01 1998-09-04 Oreal Utilisation de derives amino-alcools a fonction uree dans et pour la preparation de compositions cosmetiques ou dermatologiques
US6607136B1 (en) * 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
AU1230900A (en) * 1998-10-26 2000-05-15 Gte Service Corporation Data access system
US6643652B2 (en) * 2000-01-14 2003-11-04 Saba Software, Inc. Method and apparatus for managing data exchange among systems in a network
AU2001269856B2 (en) * 2000-06-16 2007-11-29 Mih Technology Holdings Bv Methods and systems to distribute content via a network utilizing distributed conditional access agents and secure agents, and to perform digital rights management (drm)
JP2002281061A (ja) * 2001-03-19 2002-09-27 Sony Corp ネットワークシステム、接続装置、接続方法、ネットワーク、プログラムおよび記録媒体
US7103379B2 (en) * 2003-02-03 2006-09-05 Hewlett-Packard Development Company, L.P. Wearable electronic device
CN101075316A (zh) * 2007-06-25 2007-11-21 陆航程 一种电子票证交易认证管理方法、载体结构、系统、终端
CN102292735A (zh) * 2008-10-28 2011-12-21 西斯·饶 国家公民身份管理和电子政务的集成系统及其方法
KR100978740B1 (ko) * 2010-04-16 2010-08-30 한국과학기술정보연구원 Ｒｄｆ 탐색기반 질의응답 서비스 시스템 및 방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2015079145A1 *

Also Published As

Publication number Publication date
FR3014220A1 (fr) 2015-06-05
CN106415617A (zh) 2017-02-15
US20170004458A1 (en) 2017-01-05
WO2015079145A1 (fr) 2015-06-04
CN106415617B (zh) 2020-08-25

Similar Documents

Publication Publication Date Title
US20190173826A1 (en) Alert modification based on social media activity
CN112352233B (zh) 自动数字资产共享建议
Goodwin et al. Social media and young adults’ drinking cultures: Research themes, technological developments and key emerging concepts
EP3074931A1 (fr) Procédé et serveur de notification d'une carte électronique
Rosi et al. Integrating social sensors and pervasive services: approaches and perspectives
FR3048101A1 (fr) Procede et dispositif d'evaluation de la robustesse d'une anonymisation d'un jeu de donnees
EP2351328B1 (fr) Procede et dispositif de generation d'informations descriptives de la situation d'un utilisateur
EP2645311B1 (fr) Procédé et système de notification, à un utilisateur d'un terminal, de données contextuelles relatives à des éléments identifiés dans une application de type répertoire
Alberto User-centric mobile services: context provisioning and user profiling
EP3465567A1 (fr) Terminal pour l'établissement de communications par diffusion à l'intérieur d'un groupe
FR3061589A1 (fr) Dispositif et procede de generation de listes d'utilisateurs d'interet au sein d'une architecture reseau structuree
WO2017064446A1 (fr) Procede de communication entre deux utilisateurs, systeme utilisant un tel procede
EP2979234A1 (fr) Acces a un sous-ensemble d'informations relatives a un utilisateur
FR2849561A1 (fr) Systeme de communication multi-protocoles
EP2193651A2 (fr) Procede de representation d'un utilisateur, dispositif, et produit programme d'ordinateur correspondants
FR3042628A1 (fr)
FR3030820A1 (fr) Procede pour l'acces a un contenu numerique dans un reseau de communication, au moyen d'un equipement terminal connecte audit reseau de communication
EP2902927A1 (fr) Procédé et dispositif d'étiquetage d'au moins un objet multimédia
Weidemann GeosocialFootprint (2103): Social Media Location Privacy Web Map
FR3049365A1 (fr) Systeme et procede de filtrage et de priorisation d'indicateurs
FR3005181A1 (fr) Generation d'un document multimedia personnalise relatif a un evenement
Hieu A Context-Aware View Over Social Media
FR3098625A1 (fr) Système de diffusion confidentielle d’information à caractère commercial, mettant en œuvre une plateforme informatique et une clé mémoire de type USB apte à communiquer avec la plateforme
Kollanyi Methodological challenges of studying social media from the perspective of information manipulation
FR3055724A1 (fr) Systeme et procede de lecture automatique par annonce vocale des donnees recues par un dispositif mobile concernant une zone geographique

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160531

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180208

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20190419