WO2006092505A1 - Procede et dispositif de mise en relation automatique de terminaux proches - Google Patents

Procede et dispositif de mise en relation automatique de terminaux proches Download PDF

Info

Publication number
WO2006092505A1
WO2006092505A1 PCT/FR2006/000464 FR2006000464W WO2006092505A1 WO 2006092505 A1 WO2006092505 A1 WO 2006092505A1 FR 2006000464 W FR2006000464 W FR 2006000464W WO 2006092505 A1 WO2006092505 A1 WO 2006092505A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
during
terminals
process according
search
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
PCT/FR2006/000464
Other languages
English (en)
Inventor
Olivier Samy Chouraki
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.)
MOBILUCK SA
Original Assignee
MOBILUCK 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
Priority claimed from FR0502095A external-priority patent/FR2882875A1/fr
Application filed by MOBILUCK SA filed Critical MOBILUCK SA
Publication of WO2006092505A1 publication Critical patent/WO2006092505A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks

Definitions

  • the present invention relates to a method and a device for automatically relating close terminals. It applies, in particular, to wireless communication short-range radio waves (called “short range wireless”).
  • badges that identify people and allow others to determine if they have a reason to come into contact.
  • SMS short message System
  • Bluetooth wireless communication is used primarily to replace cables. You can create a Bluetooth connection between two devices. We put one of the devices in detectable mode and another in detection mode. We select the first device among all those that were detected by the second, then establishes the connection. Sometimes the first device must accept the link. Sometimes you even have to enter the same code on both devices to create the link.
  • the short-range wireless communication terminals are not capable of simultaneously performing multiple communication functions. They can not detect other terminals at the same time, be detectable, attempt to establish connections and exchange data.
  • the present invention aims to provide users of mobile devices equipped with short-range communication systems, an automatic means to contact and exchange information, if desired.
  • This information can represent all or part of the identity of the user, what he seeks, what he offers or who he wants to meet, for example.
  • the implementation of the present invention makes it possible to develop short-range wireless communication applications comprising an automatic detection, in the background, of the other terminals capable of communicating, and then a connection with these devices. terminals and an automated data exchange.
  • the present invention aims, in the case of the implementation of the Bluetooth standard, to allow detection between terminals and an automatic data exchange in less than one minute.
  • the present invention aims at a method of automatically relating close terminals, characterized in that it comprises a mutual detection procedure in the background including alternately, in a cycle:
  • a detection step of the detectable terminals and. a step during which the terminal is itself detectable.
  • the "local" terminal can communicate with another "remote" terminal, permanently and in the background, or on demand, without having any prior knowledge of the remote terminal.
  • the terminal alternating these steps seems to be at the same time and permanently detectable and in the process of detecting the other terminals.
  • a terminal implementing the method that is the subject of the present invention can automatically detect any other terminal capable of communicating with it, without disturbing the applications operating in the foreground on said terminal. If at least two terminals implementing the method that is the subject of the present invention are within range of each other, each of the terminals can detect each other terminal within range.
  • the present invention thus makes it possible to set up automatic, direct and complex communications between terminals without passing through a central server by means of short-range wireless communication technology, for example Bluetooth technology.
  • short-range wireless communication technology for example Bluetooth technology.
  • the method comprises, for at least one cycle, a random draw step and, depending on the result of said draw, a step of defining, for this cycle, the duration of at least one of the detection steps or detectability.
  • the random draw is equiprobable and defines the duration of the detectability step as a function of a multiple of the duration of the detection step and the result of the random draw.
  • the duration D of the detection step is fixed.
  • the duration of the detectability step is defined randomly and can take three equally equiprobable values: 2D, 3D, or 4D. In this way, two terminals perfectly synchronized during a cycle have two chances out of three to choose different durations and to be sufficiently desynchronized to detect the next cycle. The time spent on the detectability steps is then, on average, three times greater than the detection time.
  • a terminal once a terminal has detected another terminal capable of communicating, it makes at least one connection attempt to this other terminal. Thanks to these provisions, the connection between these terminals is automatic. According to particular characteristics, the number of successive connection attempts with the same terminal is less than a predetermined value. Thanks to these provisions, it avoids devoting too much of the cycle to connection attempts and time is saved for the other steps of detection and detectability.
  • a limit number of connection attempts per terminal is defined, when this number of attempts is reached without a connection being established, waiting for at least a predetermined duration, before performing again at least an attempt to connect with this terminal.
  • the present invention aims at a method of automatically relating close terminals, characterized in that it comprises:
  • a step of analyzing the name of the detected terminal in order to look for said recognition sign in the event of detection of another terminal, a step of analyzing the name of the detected terminal in order to look for said recognition sign.
  • the terminal As soon as the terminal is detected, the other terminal that has detected it is able to know that a predetermined application is likely to communicate with it, without having to establish a connection with this terminal, by simple analysis. its detectable name. Thus the terminal attempts to establish a connection with the terminals recognized as likely to accept this connection and avoids wasting time trying to connect to others.
  • At least one recognizable character is added at the beginning of the detectable name.
  • the character " is added to the detectable name.
  • the detectable name is modified to incorporate either a first sign of recognition indicating the installation on said terminal of a predetermined application, said application being stopped, or a second sign of recognition indicating the installation on said terminal of the predetermined application, said application being in operation.
  • the terminal which has detected said terminal can act differently depending on the case, for example to send said application when it is not installed, that is to say when neither of the two signs of recognition has not been incorporated into the detectable name.
  • the method as briefly described above includes a detection step of detecting at least one terminal having a detectable name having said recognition sign, and this step is interrupted as soon as such a terminal has been detected.
  • the step of modifying the detectable name of the terminal incorporates several information organized according to a predetermined format.
  • said information comprises: an identification of their format and
  • a step of analyzing the name of the detected terminal is carried out in order to search for said information.
  • the short-range wireless links being set up on the initiative of the user, and generally between two terminals chosen in advance, as indicated above, it is not necessary to optimize the communication procedures of the terminals, for example when several successive connection attempts fail.
  • the present invention aims at a method of automatically linking a user terminal with close terminals, characterized in that it comprises:
  • a number of connection establishment attempts with said other terminal already made are memorized. Thanks to these provisions, this number can be taken into account in deciding whether to continue, or no, the said attempts and, if so, when.
  • the presence of this application can be taken into account in deciding whether or not to continue such attempts and, if so, when. For example, when an application is likely to make the communication channel less available, the number of connection establishment attempts is increased.
  • the method as briefly described above includes a presence probability determination step and a connection attempt step in which a probability of presence of said other terminal is taken into account to determine whether a connection attempt must be made. Thanks to these provisions, unnecessary connection attempts are avoided with terminals that are no longer nearby.
  • the probability of presence of a terminal is calculated as a function of the number of successive detection steps for which said terminal has not been detected since its last detection. According to particular characteristics, during the presence probability determination step, the probability of presence of a terminal is calculated as a function of the operation of an application on said terminal and making said terminal more difficult to detect.
  • the probability of presence of a terminal is calculated according to the type of said other terminal. According to particular characteristics, during the presence probability determination step, the probability of presence of a terminal is calculated as a function of the history of the detections of said terminal.
  • the present invention aims at a method of automatically linking a user terminal with close terminals, characterized in that it comprises:
  • the method as briefly described above also comprises a step of storing a number of access attempts made with each terminal whose identifier has been stored during a cycle. or a predetermined time interval.
  • the method as briefly described above comprises, in addition, a step of storing terminal identifiers with which the user does not wish to communicate.
  • the method as briefly described above also includes a step of storing the update date of the data already transmitted to each terminal whose identifier has been stored.
  • the method as briefly described above comprises a step of determining a communication mode between at least:
  • the application does not communicate with any other terminal.
  • part of the information is transmitted only to terminals explicitly identified in memory of said terminal.
  • the method as briefly described above comprises a detection alert step of another terminal when at least a predetermined duration has elapsed since its last detection.
  • the fifth aspect of the present invention seeks to overcome these disadvantages.
  • the fifth aspect of the present invention aims at a method of automatically relating close terminals, characterized in that it comprises:
  • each time another terminal is detected its probability of presence is maximum and this probability then decreases gradually.
  • the present invention aims at a method of automatically relating close mobile terminals, which comprises:
  • transmitting terminal a step of wireless communication between one of said terminals, called “transmitting terminal” and another of said terminals, called “destination terminal”, during which the transmitting terminal transmits to the destination terminal information representative of at least one research
  • users of mobile terminals can perform a description of their searches, for example offers or requests for products or services or meeting proposal, and the user of the destination terminal can contact the user of the transmitting terminal when their searches match, possibly automatically.
  • the method as briefly described above comprises, in case of correspondence, a step of communicating information representative of said correspondence, from the destination terminal to the transmitting terminal. Thanks to these provisions, the user of the transmitting terminal can also enter into communication with the user of the destination terminal when their searches match, possibly automatically.
  • a descriptive heading of the search is selected in a tree structure. Thanks to these provisions, the processing step makes it possible to compare the searches automatically, quickly and safely, by simply comparing the sections of the searches to be compared.
  • an identifier of each selected item is communicated. Thanks to these provisions, the bandwidth used for the communication of a search is reduced, the identifiers requiring less information than the names of the items.
  • the items are displayed in a language selected for the destination terminal, from the identifiers of the selected items. Thanks to these provisions, users of different languages can enter into the research base expressed in their respective languages.
  • the item selected in the tree structure of the headings and sub-headings is specified by entering a free text. For example, we can specify the heading "Community / School” by the text "HEC”.
  • an offer is described by assigning at least one value to a characteristic attribute of this offer.
  • a request is described by assigning at least one condition relating to an attribute.
  • said condition comprises a comparison operator and a value entered freely or selected from a list of possible values.
  • each predefined value that can be assigned to an attribute has an identifier and labels in one or more languages. According to particular characteristics,
  • a match between an offer and a request is determined only if the items correspond and if all the conditions of the request are fulfilled by the attributes of the offer.
  • a match between an offer and a request is determined if the keywords of the request are all found in the free text describing the offer or in the labels of the items and values describing the offer, in the language used to express the request.
  • a proposed exchange is described, consisting of at least one offer and at least one request related to each other.
  • a dating offer consisting of an offer corresponding to a user profile of the transmitting terminal and a request describing conditions to be fulfilled by a profile of the user of the destination terminal.
  • the description stage of a search includes a step of assigning a visibility level which defines the devices that can receive this search during the communication step.
  • the levels of visibility include a level of visibility said "visible by all", each search having this level of visibility that can be broadcast to all devices encountered.
  • the visibility levels comprise a so-called "filtered" level of visibility, each search having this level of visibility being disclosed to the user of the destination terminal only in case of correspondence with one of his searches.
  • the levels of visibility comprise a level of visibility said "invisible", each search with this level of visibility is never communicated automatically to other terminals.
  • each search can be specified by a list of individually “excluded” terminals, to which this search is never communicated automatically and by a list of individually “authorized” terminals that can automatically receive this search.
  • the method as briefly described above comprises a step of identifying terminals of a so-called "black" list, no information being communicated to said terminals of the blacklist.
  • a time stamp of the communication in the transmitting terminal is carried out.
  • a time stamp of the last edition of the search is carried out.
  • a time stamp of the last edition of the search is carried out for each level of visibility, in order to preserve the date and time of the last modification affecting the searches. visible information at that level.
  • a destination terminal determines whether a destination terminal has received all the searches it can receive by comparing the time stamp of the previous communication with said destination terminal with the time stamp of the last edition of each search having affected the information visible by said terminal.
  • the destination terminal is only communicated to searches whose latest version has not yet been communicated to it.
  • the present invention aims at a method of matching terminals located in the vicinity, characterized in that it comprises:
  • the method as succinctly described above includes a level of visibility known as "visible to all" which allows profiles, groups of information and information having this level of visibility to be automatically communicated to a group of other terminals encompassing all detected terminals.
  • the method as briefly described above includes a so-called “invisible” level of visibility which prohibits profiles, groups of information and information having this level of visibility to be automatically communicated to other terminals.
  • the method as briefly described above comprises a so-called “filtered” level of visibility and a step of defining a list of so-called “friendly” terminals, said terminals constituting a group of terminals authorized to receive the profiles, groups of information or information with visibility levels "visible by all” or "filtered".
  • the method as briefly described above includes a step of defining a list of blocked terminals called "black list" constituting a group of terminals that are not allowed to receive any information.
  • the visibility of a profile, a group of information or information can be specified by a list of individually “excluded” terminals to which this profile, this group of information or this information does not belong. is never communicated automatically and by a list of individually “authorized” terminals that can automatically receive this profile, this group of information or this information.
  • a time stamp of said communication is stored by the local terminal.
  • a time stamp is assigned to the modified profile.
  • a timestamp is assigned to the modified profile.
  • a time stamp is assigned to the profile modified for each level of visibility whose information are modified.
  • the timestamp of the previous communication between said terminals is compared to the time stamp of each information group defined with the local terminal and, only for groups for which the second time stamp is later than the first time stamp, the step of communicating said information group is performed.
  • the present invention aims at a method for matching nearby terminals, characterized in that it comprises: a step of defining topics, sub-topics and possible values of attributes or criteria in at least two different languages; a step of selecting a language by at least two users of two terminals; a step of defining a search, on a first terminal, by selection in lists of possible values of attributes or criteria in headings and sub-headings, said values, headings and sub-headings being expressed in the chosen language by the user of the first terminal; a step of communicating, from the first terminal to a second terminal located near the first terminal, information representative of each heading or sub-heading and each attribute or criterion value selected by the first user, and display case, on the second terminal, elements of the search defined on the first terminal, said display is performed with values, items and sub-items expressed in the language chosen by the user of the second terminal.
  • the present invention aims at a method for matching nearby terminals, characterized in that it comprises, in a user terminal: a step of receiving a message from a first terminal at proximity and a step of automatically retransmitting said message to another terminal nearby.
  • the method as briefly described above includes a step of authorization, by the user of said user terminal, of retransmission of messages and, only if the authorization is given, the step of automatic retransmission is carried out .
  • a number incorporated in said message is incremented or decremented.
  • said number is extracted from the received message and compared to a limit value and, only if said number is less than the limit threshold value, it is retransmitted during the automatic retransmission step.
  • the method as briefly described above comprises a step of extracting the message received from a retransmission indicator and only if the retransmission flag is present, said message is retransmitted during the automatic retransmission step.
  • the present invention relates to a method of operating a short-range wireless communication terminal with mobile terminals, characterized in that it comprises:
  • the present invention is directed to a method of wireless communication between a first terminal and a second terminal within range of one another, characterized in that it comprises:
  • a computer application can be automatically broadcast from one terminal to another.
  • said predetermined content includes a computer address for downloading software for installing said computer application. According to particular features, said predetermined content includes software for installing said computer application.
  • the method as briefly described above comprises a step of requesting permission to transmit the predetermined content to the user of the second terminal and, only if this authorization is given, the step of transmitting the content predetermined is performed.
  • the method as briefly described above comprises a step of requesting permission to install said computer application to the user of the second terminal and, if the authorization is given, an installation step of said computer application.
  • an installation file is copied to said second terminal in order to be transmitted to a third terminal in said predetermined content.
  • the method as briefly described above comprises a step of recognition, by the first terminal, of compatibility of the second terminal with said computer application and, in case of compatibility, said predetermined content is transmitted from the first terminal to the second terminal.
  • said recognition step includes a step of processing a name of the second terminal and a step of reading a database relating at least a part of said name with compatibility information.
  • the method as briefly described above comprises a step of recognition, by the first terminal, of an operating system implemented by the second terminal, the predetermined content transmitted from the first terminal to the second terminal. terminal variant with said operating system.
  • said recognition step includes a step of processing a name of the second terminal and a step of reading a database relating at least a part of said name to an operating system.
  • all the labels of said computer application are kept in a database each label containing a unique identifier and a language code.
  • the computer application can:
  • the present invention aims at a method of wireless communication between a first terminal and a second terminal within range of one of the other, characterized in that it comprises: a communication step between said terminals;
  • a step of transmitting said predetermined content from the first terminal to the second terminal according to the presence of said predetermined information on the second terminal, a step of transmitting said predetermined content from the first terminal to the second terminal.
  • said predetermined information represents an authorization for transmission of content.
  • said content transmission authorization includes an identification of the contents whose transmission is authorized.
  • said predetermined content includes an identifier of contents available on the first terminal and the method as briefly described above further comprises a content selection step by the user of the second terminal, a step of downloading each selected content from the first terminal to the second terminal.
  • said predetermined information comprises compatibility information of the second terminal with contents to be downloaded and said predetermined content depends on said compatibility information.
  • each content to be downloaded is associated with a counter, the value of said counter being incremented or decremented each time said content is downloaded and compared to a limit value, said content not being available again for downloading when said value limit has been reached.
  • each content to be downloaded is associated with a counter, the value of said counter being incremented or decremented each time the said content is made available to a user and compared to a limit value, the said content being no longer available for be made available to the user when said limit value has been reached.
  • the present invention is directed to a method for recharging service usage rights comprising:
  • a step of transmission of an identifier by a user terminal to a remote server a step of transmission by the server to the terminal of information representative of rights, signed by a private key held by the server;
  • said user terminal identifier is an address of the terminal on a communication network.
  • said identifier is associated by the server with the representative rights information and during the signature verification, the correspondence between the identifier sent by the terminal and the identifier associated with the signature is verified. representative information of rights.
  • the terminal transmits, with said identifier, a random reference, said reference is associated, by the server, with the representative information of rights and during the signature verification, the correspondence between the reference issued is checked. by the terminal and the reference associated with the representative information of rights.
  • a date is associated, by the server, with the representative information of rights and when said date arrives, the computer application subtracts said rights from the contents of the memory of the user terminal.
  • the identifier transmitted by the user terminal to the server comprises an identifier of the computer application, the server associates this identifier with the representative rights information and during the signature verification step, the computer application verifies the correspondence between its identifier and the identifier associated with the right representative information received.
  • FIG. 1 represents tasks performed by each terminal, in a particular embodiment of the method that is the subject of the present invention, and their relationships;
  • FIG. 2 represents, in the form of a logic diagram, steps performed during an initialization task illustrated in FIG. 1;
  • FIG. 3 represents, in the form of a logic diagram, steps performed during a terminal search task illustrated in FIG. 1;
  • FIG. 4 represents, in the form of a logic diagram, steps performed during a terminal list scanning task illustrated in FIG. 1;
  • FIG. 5 represents, in the form of a logic diagram, steps performed during a connection waiting task illustrated in FIG. 1;
  • FIG. 6 represents, in the form of a logic diagram, steps performed during a connection attempt task illustrated in FIG. 1;
  • FIG. 7 represents, in the form of a logic diagram, steps performed during a sending task illustrated in FIG. 1;
  • FIG. 8 represents, in the form of a logic diagram, steps performed during a data exchange task illustrated in FIG. 1;
  • FIG. 9 represents, in the form of a logic diagram, steps performed during a data exchange task illustrated in FIG. 1;
  • FIG. 10 represents, in the form of a logic diagram, steps performed during a data exchange task illustrated in FIG. 8;
  • FIG. 11 represents, in the form of a logic diagram, steps performed during a data exchange task illustrated in FIG. 8;
  • FIG. 12 represents, in the form of a logic diagram, steps performed during a data exchange task illustrated in FIG. 8;
  • FIG. 13 represents exchanges of data between two terminals in the implementation of the particular embodiment illustrated in FIGS. 1 to 12 and
  • FIG. 14 represents successions of steps implemented by two terminals for the matching of searches.
  • the term "application” refers to a software application that operates on a portable terminal and implements each of the aspects of the present invention in a particular embodiment of the method that is the subject of the present invention.
  • the status of the application can take an "active" value, when the application is launched and an “inactive” value, when the application is stopped.
  • FIG. 1 shows a task 100 of initialization, activation of the application and a detectable name change of the terminal (see details with reference to FIG. 2).
  • task 200 concerns the search for other terminals capable of communicating with the terminal in question, detection of other terminals, update of list and alert in case of detection (see details in relation to the Figure 3).
  • a task 300 of terminal list scanning is started (see details with reference to FIG. 4).
  • a connection waiting task 400 is started (see details with reference to FIG. 5).
  • a task 500 of connection attempt is launched (see details with reference to FIG. 6).
  • task 500 terminates without any connection being accepted by another terminal, task 200 is restarted.
  • a stop and restore task 800 is started.
  • the stopping task 800 includes a step (not shown) of restoring the detectable name of the terminal, to eliminate the indication that the application implementing the various aspects of the present invention is active, while maintaining the indication that the terminal is equipped with this application. Then we stop the application.
  • the predetermined maximum timeout detection tasks (in English "timeout"), which determine whether a predetermined duration has been reached for the execution of the task 200 (respectively 400), n have not been represented.
  • the tasks 400 and 500 are exchanged, the latter then being performed before the task 400 when the task 200 has reached its predetermined maximum duration.
  • the task 100 first includes a step 105 for initializing the terminal. Then, during a step 110, the short-range communication means are activated, here according to the Bluetooth standard. During an optional step 115, a message is received from another terminal including a sponsorship offer.
  • step 120 the installation files of the application (from a personal computer, from another mobile terminal (sponsorship), from a site accessible online, from a removable memory) are downloaded. It is observed that these installation files can also be stored in the mobile terminal before the provision of this terminal to a user. Then, we install the application, copy the installation files to allow the sponsorship of another user, ie the automatic transmission of an invitation to another terminal that does not implement the application, to download the installer for this application (see step 115 for this other terminal). During step 120, the installation files are copied so that they can be transmitted to another terminal (sponsorship) and a database stored by the mobile terminal is initialized.
  • the application is launched, the mark and the model of the mobile terminal are detected, the address of this terminal on the short-range communication medium, for example the Bluetooth address, and the language used by this mobile terminal and we install labels corresponding to this language in the database and we memorize the make, model and address of the terminal and the date of installation of the application.
  • the short-range communication medium for example the Bluetooth address
  • the detectable name of the local terminal is updated for its communications according to the communication standard (name called "Bluetooth” name when this standard is set implement) to include a sign of recognition of the application implementing the present invention and its active or inactive state.
  • the local terminal upon detection of another terminal (“remote terminal"), the local terminal can determine whether its application implementing the present invention will be able to communicate with a peer application operating on that remote terminal or, in the case where the remote terminal does not have this application, if a sponsorship offer can be implemented.
  • the sign of recognition is a silent character, that is to say one that does not pronounce itself, for example "(", “ ⁇ ", “[”, ")”, “ ⁇ ", “]", “°", “#”, “ ⁇ ", “&”,, "-”, “_”, “ ⁇ ”.
  • the sign of recognition is the second sign of a pair of signs that are conventionally used in an ordered pair, for example ")", “ ⁇ " or “]", the first being preferred, when the remote terminal has the application and that it is active because it also suggests a radio wave.
  • the recognition sign " ⁇ " may, in addition, be used in the case where the remote terminal has the application but it is inactive.
  • the detectable name of the local terminal incorporates several information organized in a predetermined format.
  • the information incorporated in the detectable name preferably includes:
  • the information incorporated in the detectable name is organized and compressed to successively represent the surname, the first name, enterprise and the business sector of the user and, in a second format, intended to be selected by the user during his periods of professional inactivity, the information incorporated in the detectable name is organized and compressed to represent the pseudonym, age, gender and topics of interest to the user.
  • the information embedded in the detectable name is organized and compressed to describe a search (offer, request or identity, as explained further).
  • a timer is issued for the duration of activity of the application intended to provide statistical elements.
  • the user customizes the application and enters a personal profile which may include an identity for the purpose of recognizing other terminal users who have the same identity (for example the establishment where one works, the sports club that we support, the institutions where we studied, ...), one or more offers defined by their attributes and one or more requests defined by criteria and files that we want to share with other users of the application.
  • the topics with which the user defines his searches are chosen in a predefined hierarchy or tree, each choice that the user can make in a node of the tree being stored in several languages in the database of his terminal.
  • the first level of the tree can include the topics "meetings", "employment”, real estate "," car / motorcycle “,” purchase / sale ",” services ",” information "and” other ". end of the tree, the sheets correspond to codes that are free, the user, or a group of users can thus choose a common code to define a search.
  • the offers are defined by attributes and predefined attribute values (for example car - sedan - three doors - years> 2002).
  • the requests (search of another particular type) are defined by criteria which are attributes, operators acting between the values of these attributes (for example AND and OR) and values of these predefined attributes (for example motorcycle - 750 cm 3 - year> 2001 AND year ⁇ 2003 AND mileage ⁇ 40,000). Requests can also be defined by keywords (eg "Convertible"). Then, we memorize the date of last modification of the data to be exchanged.
  • the user chooses, for each set of data (identity, profile, searches, for example), the mode of communication to other terminals:
  • steps 135 and 145 can be repeated at any time by the user.
  • the task 100 is then completed and the task 200 is launched (FIG. 3). It can be seen in FIG. 3 that the task 200 first includes a step 205 for detecting other terminals.
  • the response to the detection requests is inhibited at the beginning of the task 200 and it is disinhibited at the end of this task.
  • step 205 continues. It is observed that the local terminal is detectable as long as it does not use its communication functions. It is also observed that the recovery of the name is expensive in time. To limit this cost, it implements an internal cache of recently detected terminals. However, in order to periodically check that the detectable name of a terminal has not changed, during one detection step out of ten, the name of each terminal detected or re-detected during this step is retrieved, and this refreshes the content of the cache memory and the database.
  • - a name called "definitive, or address on the short-range communication medium, for example Bluetooth, no which is unique, that is to say that no other terminal can have the same definitive name and - a name detectable ("Bluetooth" name when this standard is used) chosen by its user and modified by the task 100 of the application implementing the method that is the subject of the present invention as explained with reference to FIG. 2.
  • the data extracted from the detectable name are stored in a profile of the detected remote terminal.
  • the list of the terminals that have already been detected is searched for, and during a step 215, it is determined whether the definitive name of the other terminal, which has just been detected, is present in this listing.
  • step 215 If the result of step 215 is negative, during a step 220, is added in the list of recently detected terminals, at least the following information concerning the detected new terminal: - the date of the detection, as a that date of last detection,
  • step 215 If the result of step 215 is positive, during a step 225, the list of recently detected terminals is updated with at least the following information concerning the terminal that has just been detected again :
  • the new date of the detection as the last detection date, while preserving the old last detection date, the highest probability of presence, as the probability of presence of the detected terminal
  • the status of the application implementing the method that is the subject of the present invention for the detected terminal a status that can take two "active or passive" values, depending on whether or not the detectable name includes the recognition sign ")" which indicates that this terminal is likely to exchange data.
  • an alert is triggered (for example a ringing or a vibration of the mobile terminal constituting the device object of the present invention) if at the same time: - the terminal which has just been detected is not filtered (are filtered, for example, the terminals whose status is "passive", the terminals which are not intended to transmit messages on behalf of their user, for example blacklisted printers and terminals) and
  • This alert comprises displaying, on the screen of the local terminal, data extracted from the detected detectable name of the terminal which has been detected and other stored data concerning this remote terminal.
  • step 205 is repeated, without resetting the predetermined maximum time (in English "timeout").
  • FIG. 4 shows that the task 300 first comprises a step 305 of determining if there are no longer, in the list of recently detected terminals, terminals having a probability of presence greater than 0. If the result of step 305 is positive, task 300 is completed and task 400 is started.
  • a positioning step 310 is performed on the first terminal of the list of recently detected terminals which has a probability of presence greater than the lowest probability of possible presence.
  • the probability of presence of the terminal in question is decremented by a value that depends on the status of the terminal, "active or" passive. For example, when the remote terminal is passive, the highest probability is “3" and is decremented by "1" at each cycle without further detection of this remote terminal, whereas if the remote terminal is active, the most probable probability high is "6". Finally, for some models that are difficult to detect, the maximum probability is "7" or "8".
  • the screen of the terminal that implements the method that is the subject of the present invention is refreshed to represent, on this screen, the level of probability of each terminal of the list of recently detected terminals. During this estimation or presence probability determination step, it is possible to calculate the probability of presence of a terminal based on
  • the type of said other terminal plus the remote terminal has a low detectability, the less rapidly its presence probability decreases
  • the history of detections of said terminal for example if a remote terminal has been detected, in average, three times for four phases of detection and it is no longer detected three times in a row, its probability of presence is more rapidly reduced than if it has been detected, on average for two phases of detection).
  • a step 320 it is determined whether the terminal considered simultaneously fulfills the following conditions:
  • the terminal has a probability of presence greater than the lowest probability of presence, here "0"
  • step 305 is repeated.
  • a parameterizable filter is provided: it excludes terminals according to criteria (exclude present, parties, ignored black list, friends, telephones, PDA, PC, printers, liabilities, the sans-profiles, the profiles ). But we keep them in the cache for a while.
  • An activatable "autodelete” function deletes excluded or "hidden” terminals that are not detected for a predetermined time.
  • the task 400 first comprises a reading step 405, in memory of the selected detection time "D" (by default setting), for example of four seconds. Then, during a step 410, it is determined whether there are still terminals to be processed, that is to say terminals whose number of connection attempts to perform is strictly greater than "0". If yes, the value "0" is assigned to the variable "T" during a step 415. Otherwise, during a step 420, an equiprobable random draw is performed between three values: 2, 3 or 4, the result of the print is assigned to the variable "T".
  • the waiting time to be observed is calculated as being equal to the product of the selected detection time "D" by the variable "T", product to which a predetermined duration is added, for example two seconds.
  • the waiting time can equally equitably be one of 10, 14 or 18 seconds when "D" is four seconds and the added duration is two seconds.
  • Task 400 is then completed and task 500 is started.
  • the task 500 firstly comprises a step 505 of selecting the terminal from the list of recently detected terminals for which the duration passed since the date of the last connection attempt is the highest, eliminating terminals whose number of connection attempts to perform is zero. Then, during a step 510, a connection attempt step is made with the terminal in question, according to known techniques, in particular according to the Bluetooth standard.
  • step 510 If the result of the connection attempt of step 510 is successful, the connection being accepted by the target terminal, task 700 is started (see FIGS. 8-12), step 515.
  • step 520 If the result of the connection attempt of step 510 is a failure, i.e. a maximum predetermined time is exceeded for step 510 (in English "timeout"), during a step 520, the number of connection attempts to be made for the terminal considered is decremented and the date of the last connection attempt of the terminal considered is updated.
  • step 525 it is determined whether three connection attempts have been made since the last launch of the task 500 or whether a predetermined duration for the progress of the step 500 is exceeded. If so, task 500 is completed and task 200 is started (see FIG. 3). Otherwise, step 505 is repeated. Of course, the predetermined duration implemented during step 525 is greater than the predetermined duration implemented during steps 510 and 515.
  • the sending task 600 firstly comprises a step 605 for initializing a connection attempt counter. Then, during a step 610, it is determined whether the value of the retry counter is equal to a predetermined number, for example three. If so, task 600 is complete and task 200 is started. Otherwise, in step 615, one makes a connection attempt that implements a service discovery protocol known as SDP for "service discovery protocol”, and it starts a timer (English “timer") and launches a predetermined maximum timeout detection (English "timeout").
  • SDP service discovery protocol
  • connection attempt counter is incremented.
  • the OBEX port available that is to say available for a connection in accordance with FIG. standard Bluetooth. Then, during a step 635, an OBEX connection attempt is made and, as soon as the connection is accepted, during a step 640, the message to be transmitted is sent (message, business card or file, by example).
  • the sponsorship offer of another mobile terminal user is a manual send request.
  • the entry of the task 700 when it is started by the task 400, that is to say that a connection received from another terminal has been accepted, starts with a step 705 of first reception (reception of a reference referenced "1" in the following description and 11) and recording first data. Then, during a step 710, it is determined whether the terminal with which the connection has been established is already referenced in the database, looking for its final address. If the terminal is already referenced, during a step 715, the data relating to this terminal is updated in the database. If the terminal is not already referenced, during a step 720, the terminal and the received data are added to the database.
  • a comparison is made of the searches received from the other terminal and the searches stored in the local database. .
  • This comparison is detailed in FIG. 10.
  • the comparison shows a correspondence of at least one search by terminal
  • the number of the offer and the number of the request are stored in a memory of correspondences and an alarm is emitted. to the user of the terminal, in sound, visual or vibrating mode, for example. This alert is only performed if the correspondence has not already been reported, which can be determined by searching the bid number and request number pair in the match memory.
  • a first data transmission is made to the terminal with which the connection is established.
  • This first shipment is detailed in FIG. 11.
  • a second reception is carried out (reception of a shipment referenced "2" in the remainder of the description and detailed in FIG. 12) and registration of second data.
  • the number of the offer and the number of the request are memorized in the memory of correspondences and an alarm is emitted to the user of the terminal, in sound, visual or vibrating form, for example, if the correspondence has not already been reported. Otherwise, or after the triggering of the alert, the task 700 is completed and task 200 is restarted.
  • the entry into the task 700 when it is started by the task 500, that is to say that a connection has been sent to another terminal and accepted by it.
  • first comprises a step 745 of first sending first data (see detail of the sending "1" in Figure 11).
  • the local database is updated with respect to the other terminal.
  • a step 750 a step is performed for receiving the first data (sending receipt "1" of the other terminal), this first data is recorded from the other terminal and day data about the other terminal in the local database.
  • a step is made to compare received searches and searches stored in database (see detail in Figure 10).
  • the comparison shows a correspondence of at least one search by terminal
  • the number of the offer and the number of the request are stored in the correspondence memory and an alert is sent to the user of the terminal, under sound, visual or vibrating sound, for example, if the correspondence has not already been reported.
  • a second step of sending second data sending "2", see detail in FIG. 12) relating to the filtered searches for which a match has been detected during step 755 (see FIG. 10).
  • the filtered searches are the searches for which the mode of communication is "filtered", that is to say that these searches are reserved for the friends, and that the other terminal is identified like friend. It can be seen in FIG. 10 that the search comparison first comprises a step 905 for matching received searches with searches stored in the database, according to their type. Thus, searches related to identity are matched only between them.
  • Requests are matched only with offers and exchanges are mapped only between them. If there is no such correspondence between the received searches and the searches stored in the local database, the comparison is complete.
  • a comparison is made by heading.
  • identity match searches, these match only if their fields are exactly the same.
  • heading here covers all the nodes and leaves of a tree of choice.
  • an identity heading may mean the two following predetermined selections "community / school” to indicate that the identity is that of a community consisting of students from the same school.
  • step 910 For an offer to match a request, in step 910 all the attributes of the offer must be included in all the criteria of the request. If there is no such correspondence between the received searches and the searches stored in the local database, the comparison is complete.
  • a code HEC86 represents the alumni of the HEC 1986 class. If there is no match to be processed after step 915, the comparison is complete.
  • a step 925 in the case of the exchanges, which are the combination of at least one offer and at least one request, if at least one correspondence offers received / demand stored has been established during the step 920, and that the offer is part of an exchange search, it is searched whether at least one correspondence can be established between an offer stored in a local database and a request received forming part of the same exchange search. . If so, there is exchange search match. In all cases where a correspondence between a received search and a stored search has been established, during a step 930, an alert is sent to the user of the terminal and the comparison is completed and the procedure is continued. task 700.
  • FIG. 11 shows that the sending "1" first comprises a search step 1005 if, with the terminal with which a connection is accepted, the local database keeps a “friend” relation, "neutral””or” ignored “, the latter case corresponding to the" black "list of terminals with which one refuses to communicate.
  • the data visible by the terminal with which the connection is accepted is searched according to the relationship indication found in the local database.
  • These data are the data visible to all, unless this relationship is “ignored”, the profile information filtered if the relationship indication is "friend” and the searches visible to all, unless this relationship is "ignored”.
  • the relation is "ignored”, no data is sent, if the relation is "neutral”, we send only the data visible by all, if the relationship is "friend”, we send the data visible by all and profile information visible to friends.
  • the technical information to be transmitted is sought, in particular the name detectable on the short-range communication medium, for example Bluetooth, the class of device (in English "class of device”).
  • one of the transmissible data is searched for those that have been modified since the last sending made to the terminal with which the connection has been accepted.
  • the information to be transmitted is formatted, even if there is no modified information, in which case the formatting concerns an empty information frame.
  • the transmission of the information to be transmitted is formatted.
  • the date of the data sent to the terminal with which the connection is accepted is updated. It can be seen in FIG. 12 that the sending "2" firstly comprises a step 1105 for searching the filtered data in correspondence with searches received from the other terminal (see detail in FIG. 10).
  • the information to be transmitted is formatted, even if there is no modified information, in which case the formatting concerns an empty information frame.
  • the transmission of the information to be transmitted is formatted.
  • the date of the data sent to the other terminal is updated.
  • FIG. 13 summarizes the exchanges made between two terminals, "A” and “B", "A” being the terminal that detects the other terminal, here “B", communication 1205. Then, the terminal "A” attempts to connect to the terminal "B", communication 1210. If the connection attempt is successful, the terminal "B” opens the connection, communication 1215. Then, the terminal "A” sends the information visible to all, the filtered information if the terminal "B” is referenced as “friends" in the terminal database "A” and searches visible to all, communication 1220.
  • the terminal "B” sends to the terminal "A” the information visible to all, the filtered information if the terminal "A” is referenced as “friend” in the database of the terminal “B”, its searches visible by all and filtered searches if matches have been detected between the searches transmitted by the terminal "A” and the searches stored in the database of the terminal “B", communication 1225.
  • the terminal "A” sends to the terminal " B "filtered searches whose correspondence was detected by the terminal” A ", communication 1230. It is observed that the searches are transmitted by description of tree branches and the free part. This allows multilingual communication because displaying the description of tree branches can then be done in the language of the terminal chosen by its user. Thus, are multilingual, the user interface and the labels of topics, fields and values.
  • "invisible" searches if there is a match with a received search, the user is alerted and displayed the profile of the remote user. The user then decides to answer, which makes the search visible to the other terminal, or not.
  • the telephone number is inserted in the detectable Bluetooth name, this telephone number is automatically retrieved by the application implementing the present invention and it makes a proposal for Immediate call or instant messaging sending and possibly performs the storage of the telephone number in the terminal directory and in the profile associated with the remote terminal.
  • a remote terminal is blacklisted, it is indicated.
  • the software is sent via Bluetooth while in the Java (registered trademark) or Windows mobile (registered trademark) version, a business card is sent in the "V" format. -card "with, in the name, a message of what to do to install the application implementing the present invention and a link on a WAP site where you can find the application (opening of automatic web browser by selecting the link).
  • FIG. 14 represents successions of steps implemented by two terminals for the matching of searches, in a particular embodiment. The steps implemented by one of the terminals are shown on the left of Figure 14, while the steps implemented by the other terminal are shown on the right of Figure 14.
  • each of the users of the terminals defines its profile, describing the user of the terminal, this profile is composed of information defined by assigning values to attributes and, possibly, by giving keywords in free fields.
  • each of the users of the terminals describes at least one search, on each of at least two terminals.
  • the user selects, in a tree, a descriptive section of the search then descriptive sub-headings and specifying the search.
  • the user specifies the heading chosen in the tree of headings and sub-headings, by entering a free text.
  • the user describes an offer by assigning at least one value to a characteristic attribute of this offer and seizes a free text.
  • a "request” type search For a "request” type search, the user describes a request by assigning at least one attribute condition, which condition includes a comparison operator and a value entered freely or selected from a list of possible values. In addition, the user enters one or more keywords. With regard to an "exchange” type search, the user describes an "offer” type search and a “request” type search, these two searches being linked together in an underlying way.
  • the user describes an offer corresponding to his user profile and a request describing conditions to be fulfilled by a profile of the user of the destination terminal.
  • each user assigns a visibility level that defines the devices that can receive the search during the communication step. This level of visibility can then be changed at any time by the user concerned, through the use of appropriate menus. For this purpose, the user chooses between different levels of visibility that are presented to him in a menu. These levels of visibility include a level of visibility known as "visible by all" which means that each search with this level of visibility can be broadcast to all the devices encountered.
  • the levels of visibility comprise a so-called "filtered" level of visibility, each search having this level of visibility being disclosed to the user of the destination terminal only in case of correspondence with one of the searches of the destination terminal.
  • Visibility levels include a so-called “invisible” level of visibility, each search with this level of visibility never being automatically communicated to other terminals and therefore only communicated after a manual action by the user. user.
  • the visibility of each search can be specified by a list of individually “excluded” terminals, to which this search is never automatically communicated and by a list of individually “authorized” terminals that can automatically receive this search.
  • the user can identify terminals of a so-called "black" list, no information being communicated to said terminals of the blacklist. This identification can be done at the time of entry into communication with another terminal, by selecting, in a menu, a blacklist entry function.
  • the search already transmitted to the destination terminal is immediately updated as an empty search in the destination terminal, which can not display it to its user.
  • a time stamp of the search is carried out last edition of the research.
  • a time stamp of the last edition of the search is carried out for each visibility level, in order to keep the date and time of the last modification affecting the visible information audit. level.
  • each predefined value that can be assigned to an attribute has an identifier and labels in one or more languages.
  • the transmitting terminal transmits to the destination terminal a information representative of at least one search.
  • step 1420 of wireless communication between the transmitting terminal and the destination terminal, an identifier of each selected item is communicated, which considerably reduces the amount of information to be transferred, on the one hand, and to display the headings and sub-headings in the language of the recipient, on the other hand (for this purpose, the list of the headings, associated with their identifiers, is translated in each language in which the software works). Free texts, keywords, values, attributes, and conditions are also passed during this step 1420.
  • a time stamp of the communication is carried out in the transmitting terminal.
  • the transmitting terminal determines whether a destination terminal has received all the searches it can receive by comparing the time stamp of the previous communication with said destination terminal to the timestamp of the last edition of each search which has affected the information visible by said terminal. And the destination terminal is only sent to searches whose latest version has not yet been communicated to it.
  • the destination terminal performs the processing of each received search to determine a possible match between the search received from the transmitting terminal with at least one search stored by the destination terminal.
  • the destination terminal determines a match between an offer and a request only if the items correspond and if all the conditions of the request are fulfilled by the attributes of the offer. In addition, in embodiments, it determines a match between an offer and a request if the keywords of the request are all found in the free text describing the offer or in the labels of the items and values describing the offer. , in the language used to express the request.
  • a display step 1480 is performed on the destination terminal of information representative of this correspondence.
  • the items are displayed in a language selected for the destination terminal, from the identifiers of the selected items.
  • the destination terminal performs a communication step at the transmitting terminal, respectively steps 1485 and 1425, of information representative of the correspondence found and, during a step 1430, displays , on the transmitting terminal, the elements of the search described on the destination terminal, by its user.
  • the software implementing the present invention in this embodiment, is a communication software between Bluetooth terminals.
  • the implementation of the present invention brings on a mobile phone or a personal assistant (“PDA”) communication functions similar to personal pages, messaging, communities, classifieds, advertising, communications and transfers between peers ("peer to peer”), etc.
  • PDA personal assistant
  • the software consists of 3 functional modules: - a user interface module,
  • the user interface module groups and manages all the software screens: parameter screens and information screens.
  • the communication module manages the detection of terminals, the exchange of information and searches between terminals and the comparison of received searches with local searches.
  • the data management module supports the reading and writing, in the memory of the terminal, of the data which must be kept when the software is stopped: searches, answers, parameters, statistics, ...
  • the first two modules use the data management module on a one-off basis to use its data read and backup capabilities.
  • the terminal in English “device” is the device supporting the Bluetooth standard on which is executed the application implementing the present invention (in the following “the application”). It is recalled that “Bluetooth” distinguishes several classes of terminal (in English “class of device” whose acronym is “COD”), for example:
  • PDAs personal assistants
  • Each terminal is identifiable by its unique Bluetooth address ("Bluetooth address”). It also has a Bluetooth name (in English “Bluetooth name”) which is generally modifiable.
  • the terminal can not run the application but its Bluetooth name contains a message from the application implementing the present invention.
  • Bluetooth the terminal is a Bluetooth terminal that is not compatible with the application.
  • the user can define his relationship (in English “relationship”) with each of the other terminals, among the following relationships:
  • the user has a profile (in English "profile") which contains information grouped into blocks of information.
  • the user can define an elementary visibility (in English "item visibility") for each block, which defines which remote terminals will be able to read the information contained in this block.
  • item visibility There are 3 levels of visibility:
  • filter the information contained in the block will be visible only by the friends terminals
  • invisible the information contained in the block will not be visible to anyone.
  • the application also has a global visibility (in English “global visibility”) that allows to define at once the maximum visibility of information. The visibility applied is the most restrictive, between the basic visibility and the global visibility. There are four levels of general visibility:
  • the terminal's Bluetooth settings are automatically updated according to the selected mode: if Bluetooth was disabled and the application switched to a mode other than "inactive 1 , then Bluetooth is enabled Bluetooth is still restored to the state it was in before starting the application, when you return to the" inactive "mode.
  • the application stops the communication module and as soon as we switch to another mode it restarts this module Thanks to the application, the user can create searches (search, which allows it to find information, products, people or services located nearby (Bluetooth range)
  • search can be: permanent: it is stored in the terminal, and warns the user as soon as possible that it is close to what it is looking for It has an immediate name: it is executed immediately for a short time, and is not kept in the terminal, so it is not named.
  • a search has a basic visibility
  • a search in visibility "filter” is visible only by the terminals on which a search matches ante has been detected, each terminal publishes its searches and receives the searches from the other terminals, according to the chosen visibilities.
  • the software compares the searches and detects matches (in English "matchings"). If there is a match, the user is warned by an alert and can consult the answer (in English "resuit") to its search, that is to say the remote search (on the remote terminal) which corresponds to his local search (on the local terminal).
  • a search is defined firstly by a topic (in English "class") which indicates the object of the search within a tree classification.
  • a topic can contain subtopics, which are called its "girls” sections, and it is then their parent section.
  • a search can contain: keywords a descriptive text
  • a search whatever its type, therefore contains an offer (in English "offer") and / or a request (in English "request”).
  • an offer has a list of information describing what is offered; a request has a list of criteria describing what we are looking for.
  • search template search template which defines the information to enter to create this search. There may be several different searches based on the same search pattern.
  • the search templates are classified in the "class" or sub-sections.
  • the path in the topics to the search template defines the classification of searches created by this search template.
  • the match mode of the search template defines the type of searches that can be created from this template.
  • an "identity” type search model creates “identity” type searches
  • a "request / offer” type search model creates "offer” or “request” type searches and a search pattern of "type”.
  • type "exchange” creates "exchange” type searches.
  • a search template contains an offer template and / or request template, depending on how it is matched, to create search offers and requests.
  • - identity a supply / demand supply model: an offer model and an exchange demand model: an offer model and a demand model.
  • An offer template is a list of available fields to define offer information.
  • a request template is a list of criteria definitions available to define the criteria for an application. To be able to compare two searches, they must have been created from the same search pattern.
  • Search patterns are defined by "wizards”.
  • the user can add or remove wizards in the software.
  • a wizard When a wizard is installed, it can add to the software: new topics and search templates in them and new information in the profile, added in existing blocks or in new blocks.
  • the wizard does not define how the information will be displayed: it only describes the search templates and their classification (topics).
  • Each assistant has a unique identifier (in English "id") consisting of three letters (uppercase or lowercase) or number (in other words: [a-zA-ZO-9] [a-zA-ZO-9] [a-zA -ZO-9]). This offers the possibility to create 238328 different assistants.
  • a field is defined by a label, a set of possible values, and possibly a list of accepted units. For example :
  • a criterion is a triplet (field, operator, value).
  • the field corresponds to a value in an offer.
  • the comparison of the two values by the operator makes it possible to determine whether the criterion is verified or not.
  • a criterion model belongs to a demand model. It contains a label, a reference to a field of the associated offer template and an operator.
  • a value can be associated with a unit, when it is of numeric type. For example: - 10 years 174 euros
  • a set of possible values can specify possible units.
  • the user interface of the application is suitable for many operating systems (Symbian Series 60, UIQ, Palm OS, Pocket PC, Windows, WEB, etc., registered trademarks %) whose ergonomic standards and technical constraints are different.
  • the user interface is composed of screens and dialogs.
  • the screens allow you to display six lines of text of about twenty characters simultaneously. A line can be selected using the up and down keys. It is possible to display more than six lines in a screen by scrolling.
  • the dynamic keys on the left and right of the keyboard are reserved for the "Options” and “Return” functions.
  • the “Return” function returns to the screen previously displayed.
  • the "Options” function displays the “Options” menu which shows the available commands, determined dynamically according to the selected line.
  • a submenu with several choices is displayed.
  • the submenu is opened using the right arrow or the arrow pad selection key.
  • a choice can be selected using the up and down keys, then validated with the selection key.
  • Shortcut keys make it easy to run certain options. These keys are the left arrow (G), the right arrow (D) and the selection (S) of the directional pad.
  • the software uses the "edit” key to display the corresponding help for the selected field or screen.
  • the example used is the parameter "My Bluetooth name”.
  • the title of the initial screen is “MobiLuck” (registered trademark). This is a menu that offers the most common actions.
  • the initial screen could be "Who's there?" or “My Searches”. The screen "who is there?" displays a list of detected Bluetooth devices nearby.
  • This screen exploits the information stored in memory in the list of terminals by the communication module. It is refreshed dynamically as soon as a new terminal is detected. When this screen is opened, the communication module initiates a "inquiry" (if it is in listening mode).
  • the status can be used as a filtering criterion in the "Who is there?" screen or to trigger alerts.
  • Each status is represented by a distinctive logo to look for,
  • the relation can be used as a filtering criterion in the "Who is there?" screen or to trigger alerts. Blacklisted terminals are systematically ignored and -
  • the payment principle selected is to charge the user a single unit per contact, that is to say either during the consultation or use of personal information, or during the display the detail of an answer.
  • Paid actions (actions requiring that the terminal have been paid: open terminal, open answer, send message, call, add contact, show and launch) can be activated from the screens "who is there?", "Terminal X", “My Answers” and "Answer X”.
  • the "Terminal X" screen can be displayed from the following screens:
  • This screen displays the visible information blocks of the selected terminal as well as the information blocks with filter visibility if the local terminal is registered in "My friends" of the selected terminal. Information in information blocks with only one or two fields filled in is displayed directly. The names of information blocks with three or more fields filled in, are displayed and serve as links. We note a special case, for the blocks of information containing lists of object (ex: "shared files”), the number of objects is specified.
  • the "Preset Messages” screen allows you to choose a predefined message to send or create a new message.
  • the "Message X” screen is used to modify a predefined message or to create a new message.
  • the title of this screen is the name of the message.
  • the "Alert Message” screen displays a simple alert message (as for SMS notification) to the user as soon as an alert selected in the "Settings / Alerts" menu option occurs. This message is displayed even if the user interface is not active. If it is an alert response in this case the screen offers to see the screen "My Answers” by displaying the answers corresponding to the (s) search (s) conclusive (s). The message is automatically deleted after a configurable time (see “Settings”). Examples of displayed messages: - "1 new answer from a remote application",
  • the "Filtering” screen is used to filter the list of terminals displayed on the "Who is there?" Screen. It is accessible through the "settings menu” (personal assistant version) or in the “Who is there” screen (Symbian version).
  • the terminals Several criteria are proposed to define the terminals to be displayed: - the main Bluetooth class of the terminal (Class Of Device): telephone, PDA, computer, printer, fax, headset, others,
  • the “Search X” screen is named after the search. It does not directly modify the content of the search. This screen displays all the fields filled in when defining the search.
  • the “My answers” screen is displayed differently depending on the interface from which it is opened.
  • Unread responses are at the top of the list and are sorted by date.
  • the title of the "Answer X" screen is the name of the remote search. This screen is very similar to the “Search X” screen but for a remote search, knowing that there is some additional information to display and some different actions.
  • the "My Profile” screen allows the user to enter all the information about him in order to publish them and / or use them as default values for the creation of searches.
  • the "Information Block X" screen is named after the open information block. In this screen all information in the information block is displayed.
  • the "Settings” screen is a menu for viewing and modifying various software settings.
  • This screen are displayed the different categories of parameters: alerts, predefined messages, modules, My friends, blacklist, languages, settings, reloading and statistics.
  • the "Alerts" screen allows you to choose the events that trigger the display of an alert message and specify the sound used to report each event.
  • Checkboxes are provided to the user to select from the following events:
  • the “Modules” screen is used to manage the different modules. In particular, it allows you to delete modules and modify the classification of the modules so that the order in the search definition wizard corresponds to the preferences of the user. Some "hidden” modules do not appear on this screen and can not be deleted. In this screen are displayed the names of the various visible modules installed, classified in the order of the classification indices.
  • the "My friends” screen displays the names of the terminals registered in the friends list in the same way as the "Who is there?" Screen, without the friend symbol.
  • the "Blacklist” screen displays the names of the terminals registered in the blacklist in the same way as the "Who is there?" Screen without the blacklist symbol.
  • the "Languages” screen allows the user to indicate the languages that the software will have to manage. Note that if, among all the languages of the wizard, none appear in these four languages then the wizard will be displayed in his first language.
  • the "Settings” screen allows you to define technical parameters of the software:
  • the detection strategy (in the form of a list) can be modified by the user to modify these settings, without knowing the details, the user preferring the speed of detection of other terminals or his and / or the autonomy of his terminal.
  • the "Statistics" screen displays the various statistics relating to the use of the application implementing the present invention.
  • the main data management needs are as follows: save and load certain information into the permanent memory of the terminal.
  • o Manage units (unit counter, count, reload, ...) manipulate in memory the data necessary for the operation of the software.
  • the technical constraints that apply include: the software must support several languages, the language used is defined by a parameter, most strings displayed are different depending on the language chosen; all versions of the software (symbian, palm, pocket pc, trademarks) must be compatible with each other (can communicate and use the same search modules), security: o not be able to imitate the behavior of the software (ie: create compatible software, capable of communicating with the application implementing the present invention) o not be able to modify the unit counter to add to it or not be able to create modules that undermine the proper functioning of the application - compliance with standards in order to obtain certifications (eg Nokia OK, registered trademark).
  • the inventors made the following technical choices: the data are coded in the most portable manner possible.
  • buffer classes that allow to abstract a part of the platform. For example, strings are not handled in the same way in Symbian, Palm OS and Pocket PC
  • the targeted platforms do not allow us to use the format WBXML which would have saved space (no library was found under Symbian). Some data are: - saved on the local terminal in order to be able to keep them between two launches of the application and / or - transferred between the local terminal and a remote terminal.
  • the application and the files are stored in a "mobiluck” directory organized as follows.
  • the “assist” directory contains all wizard definitions.
  • the "Profiles” directory contains one directory per profile, the name of each directory being the nickname chosen for this profile. Each of these directories contains all the information concerning this profile: searches, lists of friends, personal information, correspondences.
  • XML The transfer and storage of data is in the same format: XML.
  • the format of these XML files is described by XML schema files.
  • Some attributes are present in the generated XML document only when transferring or only when storing. For example, information visibility information blocks are present when storing the profile on the local terminal to save it, but not when transferring his profile to a remote terminal. This is documented in XML schemas.
  • the term "client” defines the terminal that establishes the connection.
  • the term server defines the terminal that accepts the connection. Note that terminal / terminal transactions are not considered.
  • the exchanged file contains all small visible searches and information.
  • the receiving terminal compares the received searches with its searches and returns all of its visible searches and filter searches that matched. Large information (photos, for example) will be sent using the explicit request file transfer from the user.
  • the local terminal processes the received searches from the remote terminal before sending its own to the remote terminal so that it can also send the search filters that correspond to searches from the remote terminal. This avoids having to do a particular treatment for the terminals, all searches of the terminals are in "filter" mode.
  • the transaction for sending search and information updates takes place when the content of a search changes or when searches or information change visibility. Events that may cause an update are:
  • the file transfer transaction takes place between two terminals implementing the present invention. It allows you to request a file from one terminal to another (such as the user's photo, music, documents, etc.).
  • the transfer takes place at the request of the user of the destination terminal.
  • the list of files is available in the user information of the source terminal. This solution has the advantage of avoiding an additional request to the source terminal to obtain this list of available files.
  • This message exchange can take place only if the initial message exchange has taken place (to retrieve the list of available files).
  • the sponsorship transaction takes place between a local terminal implementing the application and a sponsor terminal.
  • the terminal implementing the application sends an ObEx message containing the application for the operating system of the remote terminal. Once the message is received, the newly sponsored ObEx terminal automatically offers to install the software.
  • the SDP database is used to recover the Class Of Device (COD) of a given terminal.
  • COD Class Of Device
  • the COD of a terminal contains the type of terminal (mouse, headset, ).
  • a passive terminal is a Bluetooth terminal that does not execute the application implementing the present invention but whose detectable name contains a search or profile elements of the user (see FIGS. 2 and 3).
  • This transaction occurs between a passive terminal and a terminal whose application is active or a terminal.
  • the active terminal retrieves the search in the Bluetooth name of the passive terminal and compares it with its local searches.
  • the local terminal When a local terminal registers a remote terminal in its friend list, the local terminal sends to the remote terminal a message containing the confirmation that it is registered in the list of friends of the local terminal.
  • the searches can be indifferently visible or filtered and the information can be indifferently filtered or visible.
  • the information part and / or the search part may be empty.
  • the communication module uses the basic functions described below.
  • the detection of terminals is via Bluetooth "inquiries”. This gives the Bluetooth addresses and the Bluetooth name.
  • the inquiry phase has a variable duration
  • - a terminal is detectable when it is not connected to another terminal and is not doing any inquiry
  • the terminal can publish service information using SDP ("Service Discovery Protocol"). It is therefore possible for the terminals to know if the application implementing the present invention is installed on a terminal and if so, what is its version, the state of the software (Active, %), the modules installed. If SDP does not work, it is still possible to use the Bluetooth name of the terminal,
  • the local terminal obtains the service information by interrogating the SDP base of the remote terminal. If the Bluetooth name of the terminal is used to store the service information, the local terminal retrieves it by requesting its name from the remote terminal during the inquiry,
  • the RFCOMM connections the OBEX (OBject EXchange) connections implemented in the embodiments described above and the transmission of data via SDP (the transmitting terminal). update this data SDP, the receiving terminal interrogates the SDP base of the transmitter).
  • the text of the search starts with a specific character that is unlikely to start by chance the name of a terminal, for example ')'.
  • the Bluetooth name will be considered as a search and interpreted. If the terminal name begins with the character ')' by chance, but it is not a search, the software will never detect a match or will not be able to respond. The software will behave correctly if there is an error in formatting the search.
  • the processing of the detected terminals includes the following functions: - When discovering a terminal, the blacklist is searched for the Bluetooth address of the detected terminal. If the terminal is not in the blacklist and the terminal is not in the "DeviceList” terminal list, the terminal is processed and added to the "DeviceList” terminal list;
  • the DeviceList terminal list must be updated at regular intervals to remove terminals that have not been detected for some time.
  • a remote terminal if a passive search is contained in the Bluetooth name of the remote terminal, the search is processed. If it is a terminal whose application implementing the present invention is active, the search is exchanged and processed.
  • the file sent to the remote terminal contains the visible searches stored on the terminal and the visible information stored on the terminal. If the remote terminal is in the list of the friendly terminals, the filter information available on the terminal is sent. If the file is sent after receiving remote searches on the local terminal, we add the filter searches that matched the freshly received searches. If the local terminal has answers to searches "word of mouth", the local terminal adds to the existing searches offers containing the data to propagate and corresponding with requests "word of mouth”.
  • the software cuts the search and creates the internal data structures corresponding to the search. Then a comparison with all available local searches is made. In case of correspondence (in English "matching"), the user is notified.
  • the passive terminal may be warned by a telephone call or an SMS.
  • classifications are 5-character codes, that for a match, the classification of the application must correspond to the first characters of the classification of the offer and that the offer may be more precise than Requirement but it must be included in the application. In case of precision deviation, only the search for the least accurate is satisfied. A less precise search may not be of interest to the user (inclusion logic and not equality).
  • the local search class For searches to match, the local search class must be included in the distance class, the local search topic code must match that of the remote search, the local search keywords must match those in the search remote. The conditions of supply are compared with the characteristics of the distant demand. If a condition of the offer is not in the request, there is no match.
  • a local condition is a remote condition if there is an attribute in the remote search named as the local condition, and the value of the remote attribute is in agreement with the local condition. There is a match if all local conditions are in agreement with the remote attributes.
  • the search string containing the keywords is analyzed and split. It can contain multiple keywords separated by spaces. If all the keywords specified in the search are in the offer text, there is a match.
  • - I / O processes are those managing the backup and retrieval of information. For writing (and also for sending on the network) we will go through a phase of formatting data. For the reading of the data (and for the reception on the network) one will pass by a phase of parsing (that one could translate by "cutting / interpretation") of the data.
  • the application implementing the present invention does not use a database, the data is saved in an XML file.
  • Backup processes consist of formatting the data and writing it to this file.
  • the loading processes consist of reading this file, analyzing it and creating the objects internal to the application.
  • the formatting of the data consists in generating XML code conforming to the "XML Schemas" defined in the given part from the objects in memory. - in order to preserve the confidentiality of the exchanges between the users and to avoid
  • Reverse engineering Reverse engineering of the protocol used to communicate between devices, all communications over the Bluetooth network will be encrypted using the automatic encryption capabilities offered by Bluetooth.
  • the profile used is the unprotected default profile.
  • the user can create secret profiles protected by password. He enters the chosen password and the new profile is created. To switch from one profile to another, simply enter the desired password. When the user changes profile, his Bluetooth name is updated. Once this profile is activated, it can delete it. when initializing the application implementing the present invention, it loads the profile, registers in the SDP database, provides all the necessary information to this database, starts the communication module and displays the main menu.
  • the application implementing the present invention saves the current profile, restores the Bluetooth parameters that it would have modified and puts its status "inactive" in the SDP database.
  • the communication module continues to turn in the background.
  • id addrBT + systemTime systemTime being the number of milliseconds elapsed since the time "zero" on the terminal (generally since January 1 , 1970) at the creation of search or when editing.
  • Correspondence notifications are reported to the user in the form of a ring when the terminal is in "visible” or “filter” mode, via the vibrator if the terminal is equipped and the mode of the terminal is "invisible”. If the terminal does not have a vibrator, no sound will be emitted.
  • Among the applications of the present invention are classified ads, game sharing, communities, local information, eg traffic status, station information, such as the track and time of a train , bank teller information, museum audio guides, offers from all the shops of a shopping center.
  • local information eg traffic status
  • station information such as the track and time of a train
  • bank teller information such as the track and time of a train
  • museum audio guides offers from all the shops of a shopping center.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Le procédé comporte une procédure de détection mutuelle en tâche de fond comportant en alternance : - une étape de détection des terminaux détectables (200) et - une étape au cours de laquelle le terminal est lui-même détectable (400). Préférentiellement, le procédé comporte, pour au moins un cycle, une étape de tirage aléatoire et, en fonction du résultat dudit tirage, une étape de définition, pour ce cycle, de la durée d'au moins une des étapes de détection ou de détectabilité.

Description

PROCEDE ET DISPOSITIF DE MISE EN RELATION AUTOMATIQUE DE TERMINAUX PROCHES
La présente invention concerne un procédé et un dispositif de mise en relation automatique de terminaux proches. Elle s'applique, en particulier, à la communication sans fil par ondes radio à courte portée (appelée en anglais "Short range wireless").
On connaît de nombreux moyens d'aider les personnes qui se trouvent géographiquement proches, à rentrer en contact. On peut citer, par exemple, les badges qui identifient les personnes et permettent aux autres personnes de déterminer si elles ont une raison de rentrer en contact. On peut aussi citer les annonces classées des journaux locaux, les sites de la toile ("web" en anglais) qui utilisent un critère géographique pour mettre en correspondance deux utilisateurs et les services de rencontre par minimessages (en anglais "SMS" acronyme de "short message System") proposés par les opérateurs de téléphonie mobile.
Ces moyens présentent de nombreux inconvénients : leur mise en oeuvre est onéreuse lorsqu'ils utilisent des supports physiques, le critère géographique n'est pas assez précis et représente, en général, le domicile ou le lieu de travail des personnes et non leur réelle position "nomade" ou mobile, ils manquent de confidentialité puisqu'ils imposent la présence d'un tiers ou opérateur et, souvent, le stockage de données dans un système informatique.
Il est très facile d'établir manuellement une liaison durable entre deux appareils placés à proximité munis de systèmes de communication sans fil à courte portée, par exemple mettant en oeuvre le standard "Bluetooth" (marque déposée). En revanche, ni l'établissement, ni l'interruption de cette communication ne sont automatiques.
La communication sans fil Bluetooth sert essentiellement à remplacer des câbles. On peut créer une liaison Bluetooth entre deux appareils. On met l'un des appareils en mode détectable et un autre en mode détection. On sélectionne le premier appareil parmi tous ceux qui ont été détectés par le deuxième, puis on établit la liaison. Parfois, il faut que le premier appareil accepte la liaison. Parfois, il faut même saisir un code identique sur les deux appareils pour créer la liaison. De plus, les terminaux de communication sans fil à courte portée ne sont pas capables d'effectuer simultanément plusieurs fonctions de communication. Ils ne peuvent pas en même temps détecter les autres terminaux, être détectables, tenter d'établir des connexions et échanger des données. La présente invention vise à donner à des utilisateurs de dispositifs mobiles munis de systèmes de communication à courte portée, un moyen automatique de rentrer en contact et d'échanger des informations, s'ils le désirent. Ces informations peuvent représenter toute ou partie de l'identité de l'utilisateur, ce qu'il recherche, ce qu'il offre ou qui il souhaite rencontrer, par exemple. D'une manière générale, la mise en oeuvre de la présente invention permet de développer des applications de communication par liaison sans fil à courte portée comportant une détection automatique, en tâche de fond, des autres terminaux susceptibles de communiquer, puis une connexion avec ces terminaux et un échange de données automatisé.
Plus précisément, la présente invention vise, dans le cas de la mise en oeuvre du standard Bluetooth, à permettre une détection entre terminaux et un échange de données automatique en moins d'une minute. Selon un premier aspect, la présente invention vise un procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte une procédure de détection mutuelle en tâche de fond comportant en alternance, dans un cycle :
. une étape de détection des terminaux détectables et . une étape au cours de laquelle le terminal est lui-même détectable.
Grâce à ces dispositions, le terminal "local" peut entrer en communication avec un autre terminal "distant", en permanence et en tâche de fond, ou à la demande, sans avoir aucune connaissance préalable du terminal distant.
Pour l'utilisateur, le terminal alternant ces étapes semble être en même temps et en permanence détectable et en train de détecter les autres terminaux.
Grâce à ces dispositions, un terminal mettant en oeuvre le procédé objet de la présente invention peut détecter automatiquement tout autre terminal susceptible de communiquer avec lui, sans perturber les applications fonctionnant en premier plan sur ledit terminal. Si au moins deux terminaux mettant en oeuvre le procédé objet de la présente invention se trouvent à portée l'un de l'autre, chacun des terminaux peut détecter chaque autre terminal se trouvant à portée.
Une liaison de courte durée entre des équipements de différentes personnes est ainsi établie de façon rapide et automatique sans demande spécifique de leur part.
La présente invention permet ainsi la mise en place de communications automatiques, directes et complexes entre des terminaux sans passer par un serveur central grâce à une technologie de communication sans fil à courte portée, par exemple la technologie Bluetooth.
Selon des caractéristiques particulières, le procédé comporte, pour au moins un cycle, une étape de tirage aléatoire et, en fonction du résultat dudit tirage, une étape de définition, pour ce cycle, de la durée d'au moins une des étapes de détection ou de détectabilité.
Grâce à ces dispositions, si deux terminaux mettant en oeuvre le procédé objet de la présente invention sont synchronisés et qu'ils ne peuvent pas se détecter puisqu'ils sont simultanément détectables puis simultanément en recherche de détection, le tirage aléatoire permet de les désynchroniser rapidement, permettant ainsi leur détection mutuelle.
Selon des caractéristiques particulières, le tirage aléatoire est équiprobable et définit la durée de l'étape de détectabilité en fonction d'un multiple de la durée de l'étape de détection et du résultat du tirage aléatoire.
Par exemple, la durée D de l'étape de détection est fixe. A chaque cycle, la durée de l'étape de détectabilité est définie aléatoirement et peut prendre trois valeurs différentes équiprobables : 2D, 3D, ou 4D. De cette façon, deux terminaux parfaitement synchronisés au cours d'un cycle ont deux chances sur trois de choisir des durées différentes et d'être suffisamment désynchronisés pour se détecter au cycle suivant. Le temps consacré aux étapes de détectabilité est alors, en moyenne, trois fois plus important que le temps de détection.
Selon des caractéristiques particulières, une fois qu'un terminal a détecté un autre terminal susceptible de communiquer, il effectue au moins une tentative de connexion à cet autre terminal. Grâce à ces dispositions, la connexion entre ces terminaux est automatique. Selon des caractéristiques particulières, le nombre de tentatives de connexion successives avec le même terminal est inférieur à une valeur prédéterminée. Grâce à ces dispositions, on évite de consacrer une part trop importante du cycle aux tentatives de connexion et on conserve du temps pour les autres étapes de détection et de détectabilité.
Selon des caractéristiques particulières, si des tentatives de connexions avec plusieurs terminaux sont à effectuer, on ne tente pas plusieurs fois de suite de se connecter au même terminal. Grâce à ces dispositions, on augmente les chances de se connecter à un des terminaux avec lesquels on tente successivement de se connecter.
Selon des caractéristiques particulières, un nombre limite de tentatives de connexion par terminal est défini, lorsque ce nombre de tentatives est atteint sans qu'une connexion puisse être établie, on attend pendant au moins une durée prédéterminée, avant d'effectuer de nouveau au moins une tentative de connexion avec ce terminal.
Dans l'art antérieur, pour qu'un terminal reconnaisse un autre terminal susceptible d'échanger des données, il doit, après la détection de l'autre terminal, soit tenter d'établir une connexion, soit effectuer une reconnaissance grâce à un protocole de découverte connu sous le nom de "Service Discovery Protocol". Chacune des ces procédures consomme 10 à 20 secondes par terminal détecté.
Or, pour faire communiquer entre eux deux terminaux, il serait intéressant qu'avant même d'établir une connexion, dès la détection, le terminal détecté soit reconnu comme susceptible ou non de communiquer avec les applications du terminal qui l'a détecté.
Le deuxième aspect de la présente invention vise à remédier à ces inconvénients. A cet effet, selon un deuxième aspect, la présente invention vise un procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte :
- une étape de modification du nom détectable du terminal pour y incorporer un signe de reconnaissance d'une application prédéterminée en fonctionnement et susceptible d'échanger des données avec d'autres terminaux et - pendant une étape de détectabilité, en cas de détection par un autre terminal, une étape de transmission dudit nom détectable.
- pendant une étape de détection, en cas de détection d'un autre terminal, une étape d'analyse du nom du terminal détecté afin d'y rechercher ledit signe de reconnaissance.
Grâce à ces dispositions, dès la détection du terminal, l'autre terminal qui l'a détecté est capable de savoir qu'une application prédéterminée est susceptible de communiquer avec lui, sans avoir à établir de liaison avec ce terminal, par la simple analyse de son nom détectable. Ainsi le terminal ne tente d'établir une connexion qu'avec les terminaux reconnus comme susceptibles d'accepter cette connexion et évite de perdre du temps à tenter de se connecter aux autres.
Selon des caractéristiques particulières, au cours de ladite étape de modification du nom détectable, on ajoute au moins un caractère reconnaissable en début du nom détectable.
Selon des caractéristiques particulières, au cours de l'étape de modification de nom détectable, on ajoute le caractère ")" au nom détectable.
Selon des caractéristiques particulières, au cours de l'étape de modification du nom détectable, on modifie le nom détectable pour y incorporer soit un premier signe de reconnaissance indiquant l'installation sur ledit terminal d'une application prédéterminée, ladite application étant arrêtée, soit un deuxième signe de reconnaissance indiquant l'installation sur ledit terminal de l'application prédéterminée, ladite application étant en fonctionnement.
Grâce à ces dispositions, le terminal qui a détecté ledit terminal peut agir de manière différente selon les cas, par exemple pour envoyer ladite application lorsqu'elle n'est pas installée, c'est-à-dire lorsque aucun des deux signes de reconnaissance n'a été incorporé dans le nom détectable.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de recherche de détection d'au moins un terminal possédant un nom détectable possédant ledit signe de reconnaissance, et cette étape est interrompue dès qu'un tel terminal a été détecté.
Selon des caractéristiques particulières, au cours de l'étape de modification du nom détectable du terminal, on y incorpore plusieurs informations organisées selon un format prédéterminé.
Selon des caractéristiques particulières, les dites informations comportent : - une identification de leur format et
- des informations organisées selon ledit format.
Selon des caractéristiques particulières, en cas de détection d'un autre terminal, on effectue une étape d'analyse du nom du terminal détecté afin d'y rechercher lesdites informations.
Dans l'art antérieur, les liaisons sans fil à courte portée étant mises en place sur l'initiative de l'utilisateur, et généralement entre deux terminaux choisis à l'avance, comme indiqué ci-dessus, il n'est pas nécessaire d'optimiser les procédures de mise en communication des terminaux, par exemple lorsque plusieurs tentatives de connexion successives échouent.
Dans le cas de liaisons automatiques de courte durée, il serait intéressant d'éviter des échanges de données inutiles, notamment lorsque, après détection, l'établissement d'une liaison entre deux terminaux pose problème. En particulier, il peut y avoir d'autres terminaux accessibles et un terminal ne doit pas perdre trop de temps à entrer en communication avec un terminal particulier, puisque la durée de maintien à courte portée des autres terminaux peut être limitée.
Le troisième aspect de la présente invention vise à remédier à ces inconvénients. A cet effet, la présente invention vise un procédé de mise en relation automatique d'un terminal utilisateur avec des terminaux proches, caractérisé en ce qu'il comporte :
- une étape de détection d'un autre terminal et
- une étape de mémorisation d'au moins :
. un identifiant dudit autre terminal et . la date de la dernière de ces tentatives. Grâce à ces dispositions, on peut tenir compte des difficultés à établir une liaison pour décider de poursuivre, ou non, lesdites tentatives et, si oui, à quel moment.
Selon des caractéristiques particulières, au cours de l'étape de mémorisation, on mémorise, en outre, un nombre de tentatives d'établissement de connexion avec ledit autre terminal déjà effectuées. Grâce à ces dispositions, on peut tenir compte de ce nombre pour décider de poursuivre, ou non, lesdites tentatives et, si oui, à quel moment.
Selon des caractéristiques particulières, après un nombre prédéterminé de tentatives infructueuses concernant un autre terminal, on arrête les tentatives d'établissement de liaison avec ledit autre terminal. Selon des caractéristiques particulières, au cours de l'étape de mémorisation, on mémorise, en outre, si une application prédéterminée fonctionne sur ledit autre terminal.
Grâce à ces dispositions, on peut tenir compte de la présence de cette application pour décider de poursuivre, ou non, lesdites tentatives et, si oui, à quel moment. Par exemple, lorsqu'une application est susceptible de rendre moins disponible le canal de communication, on augmente le nombre de tentatives d'établissement de liaison.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de détermination de probabilité de présence et une étape de tentative de connexion au cours de laquelle on tient compte d'une probabilité de présence dudit autre terminal pour déterminer si une tentative de connexion doit être effectuée. Grâce à ces dispositions, on évite des tentatives de connexion inutiles avec des terminaux qui ne sont plus à proximité.
Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction du nombre d'étapes de détection successives pour lesquelles ledit terminal n'a pas été détecté depuis sa dernière détection. Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction du fonctionnement d'une application sur ledit terminal et rendant ledit terminal plus difficile à détecter.
Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction du type dudit autre terminal. Selon des caractéristiques particulières, au cours de l'étape de détermination de probabilité de présence, on calcule la probabilité de présence d'un terminal en fonction de l'historique des détections dudit terminal.
Ainsi, plus un terminal aura été détecté fréquemment, plus la répétition d'une absence de détection signifiera une probabilité de présence faible. Une autre difficulté de la communication sans fil à courte portée concerne le risque qu'un terminal qui s'était éloigné revienne à portée d'un terminal local et qu'une partie des communications et transferts de données déjà effectués se reproduisent en pure perte. De plus, au cas où plusieurs tentatives d'entrée en communication ont été infructueuses, il serait néfaste, pour la disponibilité du terminal utilisateur, de poursuivre, en permanence, les tentatives d'entrée en communication. Le quatrième aspect de la présente invention vise à remédier à ces difficultés. Selon ce quatrième aspect, la présente invention vise un procédé de mise en relation automatique d'un terminal utilisateur avec des terminaux proches, caractérisé en ce qu'il comporte :
- une étape de mémorisation d'identifiants de terminaux avec lesquels une communication a été établie et - une étape de mémorisation de la date et de l'heure à laquelle une communication a été établie, pour chaque terminal dont un identifiant a été mémorisé.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape de mémorisation d'un nombre de tentatives d'accès effectuées auprès de chaque terminal dont un identifiant a été mémorisé, au cours d'un cycle ou d'un intervalle de temps prédéterminé.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape de mémorisation d'identifiants de terminaux avec lequel l'utilisateur ne souhaite pas communiquer.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape de mémorisation de la date de mise à jour des données déjà transmises à chaque terminal dont un identifiant a été mémorisé.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de détermination d'un mode de communication entre au moins :
- un mode de communication dans lequel une application mise en oeuvre par ledit terminal communique avec tout autre terminal, à l'exception de terminaux avec lequel l'utilisateur ne souhaite pas communiquer et
- un mode de communication dans lequel une application mise en oeuvre par ledit terminal ne communique qu'avec des terminaux explicitement identifiés en mémoire dudit terminal.
Selon des caractéristiques particulières, dans un mode de communication, l'application ne communique avec aucun autre terminal.
Selon des caractéristiques particulières, dans au moins un mode communication, une partie des informations n'est transmise qu'à des terminaux explicitement identifiés en mémoire dudit terminal.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'alerte de détection d'un autre terminal lorsque au moins une durée prédéterminée s'est écoulée depuis sa dernière détection.
Dans l'art antérieur, une fois qu'un terminal a été détecté, la liaison est considérée comme permanente jusqu'à une demande explicite de déconnexion de la part de l'utilisateur. L'art antérieur s'intéresse en effet, à des applications de la communication à courte portée dans lesquelles les terminaux sont fixes.
Or, il peut être intéressant de prévoir des applications dans lesquelles les terminaux sont mobiles et l'art antérieur ne résout pas le problème de la déconnexion d'un terminal trop éloigné pour communiquer.
Le cinquième aspect de la présente invention vise à remédier à ces inconvénients. A cet effet, le cinquième aspect de la présente invention vise un procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte :
- une étape de détection d'au moins un autre terminal et
- une étape d'estimation de probabilité de présence de chaque dit autre terminal.
Selon des caractéristiques particulières, au cours de l'étape d'estimation de probabilité de présence, à chaque fois qu'un autre terminal est détecté, sa probabilité de présence est maximale et cette probabilité décroît ensuite progressivement.
Selon des caractéristiques particulières, au cours de l'étape d'estimation de probabilité de présence, la probabilité de présence décroît en fonction du nombre de fois où un autre terminal n'est pas détecté. Selon un sixième aspect, la présente invention vise un procédé de mise en relation automatique de terminaux mobiles proches, qui comporte :
- une étape de description d'au moins une recherche sur chacun d'au moins deux terminaux, par leurs utilisateurs respectifs,
- une étape de communication sans fil, entre un desdits terminaux, dit « terminal émetteur » et un autre desdits terminaux, dit « terminal destinataire », au cours de laquelle, le terminal émetteur transmet au terminal destinataire une information représentative d'au moins une recherche,
- une étape de traitement de chaque recherche reçue, par le terminal destinataire, pour déterminer une éventuelle correspondance entre la recherche reçue du terminal émetteur avec au moins une recherche conservée par ledit terminal destinataire et - en cas de correspondance, une étape d'affichage, sur le terminal destinataire, d'une information représentative de ladite correspondance.
Grâce à ces dispositions, les utilisateurs des terminaux mobiles peuvent réaliser une description de leurs recherches, par exemple offres ou demandes de produits ou services ou proposition de rencontres, et l'utilisateur du terminal destinataire peut entrer en relation avec l'utilisateur du terminal émetteur lorsque leurs recherches se correspondent, éventuellement automatiquement.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, en cas de correspondance, une étape de communication d'une information représentative de ladite correspondance, depuis le terminal destinataire au terminal émetteur. Grâce à ces dispositions, l'utilisateur du terminal émetteur peut aussi entrer en communication avec l'utilisateur du terminal destinataire lorsque leurs recherches se correspondent, éventuellement automatiquement.
Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on sélectionne, dans une arborescence, une rubrique descriptive de la recherche. Grâce à ces dispositions, l'étape de traitement permet de comparer les recherches de façon automatique, rapide et sûre, par simple comparaison des rubriques des recherches à comparer.
Selon des caractéristiques particulières, au cours de l'étape de communication sans fil, entre le terminal émetteur et le terminal destinataire, on communique un identifiant de chaque rubrique sélectionnée. Grâce à ces dispositions, on réduit la bande-passante utilisée pour la communication d'une recherche, les identifiants nécessitant moins d'information que les noms des rubriques.
Selon des caractéristiques particulières, au cours de l'étape d'affichage, on affiche les rubriques dans une langue sélectionnée pour le terminal destinataire, à partir des identifiants des rubriques sélectionnées. Grâce à ces dispositions, des utilisateurs de langues différentes peuvent entrer en relation sur la base de recherches exprimées dans leurs langues respectives.
Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on précise la rubrique choisie dans l'arborescence des rubriques et sous-rubriques, par la saisie d'un texte libre. Par exemple, on peut préciser la rubrique « Communauté / Ecole » par le texte « HEC ».
Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on décrit une offre en affectant au moins une valeur à un attribut caractéristique de cette offre.
Par exemple, on peut affecter la valeur « 5 000 Euros » à l'attribut « prix » ou choisir la valeur « Renault » dans une liste pour l'attribut « Marque ». Selon des caractéristiques particulières, au cours de l'étape de description d'une offre, on saisit un texte libre.
Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on décrit une demande en affectant au moins une condition portant sur un attribut.
Selon des caractéristiques particulières, ladite condition comporte un opérateur de comparaison et une valeur saisie librement ou choisie dans une liste de valeurs possibles.
Par exemple, on peut ainsi fixer un prix maximum de 100 Euros en sélectionnant l'attribut « Prix », l'opérateur « <= (inférieur ou égal) » et la valeur « 100 Euros ».
Selon des caractéristiques particulières, chaque valeur prédéfinie pouvant être affectée à un attribut possède un identifiant et des libellés dans une ou plusieurs langues. Selon des caractéristiques particulières,
Selon des caractéristiques particulières, au cours de l'étape de traitement, on détermine une correspondance entre une offre et une demande seulement si les rubriques se correspondent et si toutes les conditions de la demande sont remplies par les attributs de l'offre.
Selon des caractéristiques particulières, caractérisé en ce que, au cours de l'étape de description d'une demande, on saisit un ou plusieurs mots clés.
Selon des caractéristiques particulières, caractérisé en ce que, au cours de l'étape de traitement, on détermine une correspondance entre une offre et une demande si les mots clés de la demande se retrouvent tous dans le texte libre décrivant l'offre ou dans les libellés des rubriques et des valeurs décrivant l'offre, dans la langue utilisée pour exprimer la demande. Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on décrit un échange proposé, constitué d'au moins une offre et d'au moins une demande liées entre elles.
Selon des caractéristiques particulières, caractérisé en ce qu'il comporte une étape de définition d'au moins un profil décrivant l'utilisateur du terminal, ce profil étant composé d'informations définies en affectant des valeurs à des attributs.
Selon des caractéristiques particulières, au cours de l'étape de description d'au moins une recherche, on décrit une offre de rencontre, constituée d'une offre correspondant à un profil de l'utilisateur du terminal émetteur et d'une demande décrivant des conditions à remplir par un profil de l'utilisateur du terminal destinataire. Selon des caractéristiques particulières, l'étape de description d'une recherche comporte une étape d'affectation d'un niveau de visibilité qui définit les appareils qui pourront recevoir cette recherche lors de l'étape de communication.
Selon des caractéristiques particulières, les niveaux de visibilité comportent un niveau de visibilité dit « visible par tous », chaque recherche possédant ce niveau de visibilité pouvant être diffusée à tous les appareils rencontrés.
Selon des caractéristiques particulières, les niveaux de visibilité comportent un niveau de visibilité dit « filtré », chaque recherche possédant ce niveau de visibilité n'étant divulguée à l'utilisateur du terminal destinataire qu'en cas de correspondance avec une de ses recherches.
Selon des caractéristiques particulières, les niveaux de visibilité comportent un niveau de visibilité dit « invisible », chaque recherche possédant ce niveau de visibilité n'étant jamais communiquée automatiquement à d'autres terminaux.
Selon des caractéristiques particulières, la visibilité de chaque recherche peut être précisée par une liste de terminaux individuellement « exclus », auxquels cette recherche n'est jamais communiquée automatiquement et par une liste de terminaux individuellement « autorisés » qui peuvent automatiquement recevoir cette recherche.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'identification de terminaux d'une liste dite « noire », aucune information n'étant communiquée aux dits terminaux de la liste noire.
Selon des caractéristiques particulières, au cours de l'étape de communication avec un terminal destinataire, on effectue un horodatage de la communication dans le terminal émetteur.
Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche.
Selon des caractéristiques particulières, au cours de l'étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche pour chaque niveau de visibilité, afin de conserver la date et l'heure de la dernière modification affectant les informations visibles audit niveau.
Selon des caractéristiques particulières, au cours de l'étape de communication, on détermine si un terminal destinataire a reçu l'ensemble des recherches qu'il peut recevoir en comparant l'horodatage de la précédente communication avec ledit terminal destinataire à l'horodatage de la dernière édition de chaque recherche ayant affecté les informations visibles par ledit terminal.
Selon des caractéristiques particulières, au cours de l'étape de communication, on communique au terminal destinataire seulement les recherches dont la dernière version ne lui a pas encore été communiquée.
Selon un septième aspect, la présente invention vise un procédé de mise en correspondance de terminaux se trouvant à proximité, caractérisé en ce qu'il comporte :
- une étape de définition, sur un terminal utilisateur local, d'au moins un profil décrivant l'utilisateur du terminal, composé d'informations à transmettre à d'autres terminaux, éventuellement regroupées en groupes d'informations - une étape d'attribution à au moins un profil, un groupe d'informations ou une information d'un niveau de visibilité choisi entre différents niveaux de visibilité définissant des sous-ensembles d'informations et des groupes de terminaux destinataires autorisés à les recevoir ;
- une étape de détection de terminaux situés à proximité ; - une étape de détermination d'appartenance d'un terminal détecté à l'un des groupes de terminaux destinataires et
- si le terminal détecté fait partie d'un groupe de terminaux autorisés à recevoir des informations, une étape de communication audit terminal du sous-ensemble d'informations correspondant. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte un niveau de visibilité dit « visible par tous » qui autorise les profils, groupes d'informations et informations possédant ce niveau de visibilité à être communiqués automatiquement à un groupe d'autre terminaux englobant tous les terminaux détectés.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte un niveau de visibilité dit « invisible » qui interdit les profils, groupes d'informations et informations possédant ce niveau de visibilité à être communiqués automatiquement à d'autre terminaux.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte un niveau de visibilité dit « filtré » et une étape de définition d'une liste de terminaux dits « amis », lesdits terminaux constituant un groupe de terminaux autorisés à recevoir les profils, groupes d'informations ou informations possédant les niveaux de visibilité « visible par tous » ou « filtré ».
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de définition d'une liste de terminaux bloqués dite « liste noire », constituant un groupe de terminaux qui ne sont autorisés à recevoir aucune information.
Selon des caractéristiques particulières, la visibilité d'un profil, d'un groupe d'informations ou d'une information peut être précisée par une liste de terminaux individuellement « exclus » auxquels ce profil, ce groupe d'informations ou cette information n'est jamais communiqué automatiquement et par une liste de terminaux individuellement « autorisés » qui peuvent recevoir automatiquement ce profil, ce groupe d'informations ou cette information.
Selon des caractéristiques particulières, au cours de chaque étape de communication entre le terminal local et un autre terminal, un horodatage de ladite communication est mémorisée par le terminal local.
Selon des caractéristiques particulières, au cours de l'étape d'édition d'une information, un horodatage est affecté au profil modifié.
Selon des caractéristiques particulières, au cours de l'étape d'affectation d'un niveau de visibilité, un horodatage est affecté au profil modifié.
Selon des caractéristiques particulières, au cours de l'étape d'édition d'une information et au cours de l'étape d'affectation d'un niveau de visibilité, un horodatage est affecté au profil modifié pour chaque niveau de visibilité dont les informations sont modifiées. Selon des caractéristiques particulières, au cours de chaque étape de communication entre le terminal local et un autre terminal, l'horodatage de la précédente communication entre lesdits terminaux est comparé à l'horodatage de chaque groupe d'information défini avec le terminal local et, seulement pour les groupes pour lesquels le deuxième horodatage est postérieur au premier horodatage, l'étape de communication dudit groupe d'information est effectuée.
Selon un huitième aspect, la présente invention vise un procédé de mise en correspondance de terminaux se trouvant à proximité, caractérisé en ce qu'il comporte : une étape de définition de rubriques, sous-rubriques et valeurs possibles d'attributs ou de critères dans au moins deux langues différentes ; - une étape de sélection d'une langue par au moins deux utilisateurs de deux terminaux ; une étape de définition d'une recherche, sur un premier terminal, par sélection dans des listes de valeurs possibles d'attributs ou de critères dans des rubriques et sous-rubriques, lesdites valeurs, rubriques et sous-rubriques étant exprimées dans la langue choisie par l'utilisateur du premier terminal ; - une étape de communication, depuis le premier terminal à un deuxième terminal se trouvant à proximité du premier terminal, d'une information représentative de chaque rubrique ou sous-rubrique et chaque valeur d'attribut ou de critère sélectionnée par le premier utilisateur et en cas d'affichage, sur le deuxième terminal, d'éléments de la recherche définie sur le premier terminal, ledit affichage est effectué avec des valeurs, rubriques et sous-rubriques exprimées dans la langue choisie par l'utilisateur du deuxième terminal. Grâce à ces dispositions, l'information représentative d'une recherche peut être très compacte, sa communication étant donc très rapide. De plus, deux utilisateurs peuvent se communiquer des recherches même s'ils ne pratiquent aucune langue commune. Selon un neuvième aspect, la présente invention vise un procédé de mise en correspondance de terminaux se trouvant à proximité, caractérisé en ce qu'il comporte, dans un terminal utilisateur : une étape de réception d'un message depuis un premier terminal se trouvant à proximité et une étape de retransmission automatique dudit message à un autre terminal se trouvant à proximité.
Selon des caractéristiques, le procédé tel que succinctement exposé ci-dessus comporte une étape d'autorisation, par l'utilisateur dudit terminal utilisateur, de retransmission de messages et, seulement si l'autorisation est donné, l'étape de retransmission automatique est effectuée.
Selon des caractéristiques particulières, au cours de l'étape de retransmission automatique, un numéro incorporé dans ledit message est incrémenté ou décrémenté.
Selon des caractéristiques particulières, ledit numéro est extrait du message reçu et comparé à une valeur limite et, seulement si ledit numéro est inférieur à la valeur seuil limite, il est retransmis au cours de l'étape de retransmission automatique.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape d'extraction du message reçu d'un indicateur de retransmission et seulement si l'indicateur de retransmission est présente, ledit message est retransmis au cours de l'étape de retransmission automatique.
Selon un dixième aspect, la présente invention vise un procédé de fonctionnement d'une borne de communication sans fil à courte portée avec des terminaux mobiles, caractérisé en ce qu'il comporte :
- une étape de réception, par ladite borne, d'une information provenant d'un premier terminal se trouvant à portée de ladite borne ;
- une étape de conservation; pendant une durée prédéterminée, de ladite information et
- en cas de connexion avec un deuxième terminal différent du premier terminal, une étape de transmission, par ladite borne, de ladite information au deuxième terminal.
Selon un onzième aspect, la présente invention vise un procédé de communication sans fil entre un premier terminal et un deuxième terminal se trouvant à portée l'un de l'autre, caractérisé en ce qu'il comporte :
- une étape de communication entre lesdits terminaux ; - une étape de détermination de présence d'une application informatique sur ledit deuxième terminal et
- en cas d'absence de ladite application informatique sur ledit deuxième terminal, une étape de transmission d'un contenu prédéterminé depuis le premier terminal à destination du deuxième terminal, ledit contenu prédéterminé permettant l'installation de ladite application informatique sur ledit deuxième terminal.
Grâce à ces dispositions, une application informatique peut être diffusée automatiquement d'un terminal à un autre.
Selon des caractéristiques particulières, ledit contenu prédéterminé comporte une adresse informatique de téléchargement d'un logiciel d'installation de ladite application informatique. Selon des caractéristiques particulières, ledit contenu prédéterminé comporte un logiciel d'installation de ladite application informatique.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de demande d'autorisation de transmission du contenu prédéterminé à l'utilisateur du deuxième terminal et, seulement si cette autorisation est donnée, l'étape de transmission du contenu prédéterminé est effectuée.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de demande d'autorisation d'installation de ladite application informatique à l'utilisateur du deuxième terminal et, si l'autorisation est donnée, une étape d'installation de ladite application informatique. Selon des caractéristiques particulières, au cours de l'étape d'installation, un fichier d'installation est recopié sur ledit deuxième terminal afin d'être transmis à un troisième terminal dans ledit contenu prédéterminé.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de reconnaissance, par le premier terminal, de compatibilité du deuxième terminal avec ladite application informatique et, en cas de compatibilité, ledit contenu prédéterminé est transmis depuis le premier terminal au deuxième terminal.
Selon des caractéristiques particulières, ladite étape de reconnaissance comporte une étape de traitement d'un nom du deuxième terminal et une étape de lecture d'une base de données mettant en relation au moins une partie dudit nom avec une information de compatibilité.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une étape de reconnaissance, par le premier terminal, d'un système d'exploitation mis en œuvre par le deuxième terminal, le contenu prédéterminé transmis depuis le premier terminal au deuxième terminal variant avec ledit système d'exploitation. Selon des caractéristiques particulières, ladite étape de reconnaissance comporte une étape de traitement d'un nom du deuxième terminal et une étape de lecture d'une base de données mettant en relation au moins une partie dudit nom avec un système d'exploitation.
Selon des caractéristiques particulières, tous les libellés de ladite application informatique sont conservés dans une base de données chaque libellé compotant un identifiant unique et un code de langue.
Grâce à ces dispositions, l'application informatique peut :
- éviter d'avoir à être recompilée lorsque des libellés sont ajoutés ou mis à jours,
- gérer un grand nombre de langues,
- donner à l'utilisateur le choix de la langue, automatiquement ou dynamiquement, - permettre le parrainage d'autres utilisateurs, même si leur langue est différente et
- être installée à partir de fichiers d'installation compacts.
Selon un douzième aspect, la présente invention vise un procédé de communication sans fil entre un premier terminal et un deuxième terminal se trouvant à portée l'un de l'autre, caractérisé en ce qu'il comporte : - une étape de communication entre lesdits terminaux ;
- une étape de détermination de présence d'une information prédéterminée sur ledit deuxième terminal et
- en fonction de la présence de ladite information prédéterminée sur le deuxième terminal, une étape de transmission dudit contenu prédéterminé depuis le premier terminal à destination du deuxième terminal.
Selon des caractéristiques particulières, ladite information prédéterminée représente une autorisation de transmission de contenu.
Selon des caractéristiques particulières, ladite autorisation de transmission de contenu comporte une identification des contenus dont la transmission est autorisée. Selon des caractéristiques particulières, ledit contenu prédéterminé comporte un identifiant de contenus disponibles sur le premier terminal et le procédé tel que succinctement exposé ci-dessus comporte, en outre, une étape de sélection de contenu par l'utilisateur du deuxième terminal, une étape de téléchargement de chaque contenu sélectionné depuis le premier terminal vers le deuxième terminal. Selon des caractéristiques particulières, ladite information prédéterminée comporte une information de compatibilité du deuxième terminal avec des contenus à télécharger et ledit contenu prédéterminé dépend de ladite information de compatibilité.
Selon des caractéristiques particulières, chaque contenu à télécharger est associé à un compteur, la valeur dudit compteur étant incrémentée ou décrémentée à chaque téléchargement dudit contenu et comparée à une valeur limite, ledit contenu n'étant plus à nouveau disponible pour être téléchargée lorsque ladite valeur limite a été atteinte.
Selon des caractéristiques particulières, chaque contenu à télécharger est associé à un compteur, la valeur dudit compteur étant incrémentée ou décrémentée à chaque mise à disposition dudit contenu à un utilisateur et comparée à une valeur limite, ledit contenu n'étant plus à nouveau disponible pour être mis à disposition de l'utilisateur lorsque ladite valeur limite a été atteinte.
Selon un treizième aspect, la présente invention vise un procédé de recharge de droits d'usage de services comportant :
- une étape de transmission d'un identifiant par un terminal utilisateur à un serveur distant, - une étape de transmission, par le serveur au terminal, d'une information représentative de droits, signée par une clé privée conservée par le serveur,
- une étape de vérification de signature avec un signature publique mise en œuvre par une application informatique sur le terminal utilisateur et
- en cas de vérification positive, une étape d'incrémentation du contenu d'une mémoire dudit terminal et une étape de transmission d'un accusé de réception audit serveur.
Grâce à ces dispositions, la procédure de rechargement de droits d'usage est aisée et sûre.
Selon des caractéristiques particulières, ledit identifiant du terminal utilisateur est une adresse du terminal sur un réseau de communication.
Selon des caractéristiques particulières, ledit identifiant est associé, par le serveur, à l'information représentative de droits et au cours de la vérification de signature, on vérifie la correspondance entre l'identifiant émis par le terminal et l'identifiant associé à l'information représentative de droits.
Selon des caractéristiques particulières, le terminal transmet, avec ledit identifiant, une référence aléatoire, ladite référence est associée, par le serveur, à l'information représentative de droits et au cours de la vérification de signature, on vérifie la correspondance entre la référence émise par le terminal et la référence associée à l'information représentative de droits.
Selon des caractéristiques particulières, une date est associée, par le serveur, à l'information représentative de droits et lorsque ladite date arrive, l'application informatique soustrait lesdits droits du contenu de la mémoire du terminal utilisateur. Selon des caractéristiques particulières, l'identifiant transmis par le terminal utilisateur au serveur comporte un identifiant de l'application informatique, le serveur associe cet identifiant à l'information représentative de droits et au cours de l'étape de vérification de signature, l'application informatique vérifie la correspondance entre son identifiant et l'identifiant associé à l'information représentative de droit reçue. Les différents aspects de la présente invention, et leurs caractéristiques essentielles, préférentielles ou particulières, sont préférentiellement combinés pour réaliser un dispositif et un procédé de mise en relation de terminaux proches cumulant les avantages de ces différents aspects.
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés dans lesquels :
- la figure 1 représente des tâches effectuées par chaque terminal, dans un mode de réalisation particulier du procédé objet de la présente invention, et leurs relations ;
- la figure 2 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'initialisation illustrée en figure 1 ; - la figure 3 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche de recherche de terminaux illustrée en figure 1 ;
- la figure 4 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche de balayage de liste de terminaux illustrée en figure 1 ;
- la figure 5 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'attente de connexion illustrée en figure 1 ;
- la figure 6 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche de tentative de connexion illustrée en figure 1 ;
- la figure 7 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'envoi illustrée en figure 1 ; - la figure 8 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 1 ;
- la figure 9 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 1 ;
- la figure 10 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 8 ;
- la figure 11 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 8 ;
- la figure 12 représente, sous forme d'un logigramme, des étapes effectuées au cours d'une tâche d'échange de données illustrée en figure 8 ; - la figure 13 représente des échanges de données entre deux terminaux dans la mise en oeuvre du mode particulier de réalisation illustré dans les figures 1 à 12 et
- la figure 14 représente des successions d'étapes mise en oeuvre par deux terminaux pour la mise en correspondance de recherches.
Dans toute la description, on appelle "l'application", une application logicielle fonctionnant sur un terminal portable et qui implémente chacun des aspects de la présente invention dans un mode de réalisation particulier du procédé objet de la présente invention. Le statut de l'application peut prendre une valeur "active", lorsque l'application est lancée et une valeur "inactive", lorsque l'application est arrêtée.
On observe, en figure 1, une tâche 100 d'initialisation, d'activation de l'application et de changement de nom détectable du terminal (voir détails en regard de la figure 2). A la suite de la tâche 100, la tâche 200 concerne la recherche d'autres terminaux susceptibles de communiquer avec le terminal en question, de détection d'autres terminaux, de mise à jour de liste et d'alerte en cas de détection (voir détails en regard de la figure 3). Lorsque la tâche 200 se termine sur une détection de dépassement de durée maximale prédéterminée (en anglais "timeout"), une tâche 300 de balayage de liste des terminaux est lancée (voir détails en regard de la figure 4). Après la fin de la tâche 300, une tâche 400 d'attente de connexion est lancée (voir détails en regard de la figure 5). Lorsque la tâche 400 se termine sur une détection de dépassement de durée maximale prédéterminée (en anglais "timeout"), une tâche 500 de tentative de connexion est lancée (voir détails en regard de la figure 6). Lorsque la tâche 500 se termine sans qu'aucune connexion n'ait été acceptée par un autre terminal, la tâche 200 est relancée.
Lorsque l'une des tâches 200, 400 ou 500 est interrompue par une demande d'arrêt de la part de l'utilisateur, une tâche d'arrêt et de restauration 800 est lancée.
Lorsque l'une des tâches 200, 400 ou 500 est interrompue par une demande d'envoi de message de la part de l'utilisateur, une tâche de reconnaissance de service, de recherche de port disponible et d'envoi de message 600 est lancée (voir détails en regard de la figure 7).
Lorsque la tâche 400 se termine par une connexion reçue et acceptée ou lorsque la tâche 500 se termine par une connexion émise et acceptée, une tâche 700 de vérification d'acceptation de connexion, d'échange de données, de comparaison de données et d'alerte est lancée (voir détails en regard des figures 8 à 12). La tâche d'arrêt 800 comporte une étape (non représentée) de restauration du nom détectable du terminal, pour en éliminer l'indication que l'application implémentant les différents aspects de la présente invention est active, tout en maintenant l'indication que le terminal est équipé de cette application. Puis on arrête l'application.
Pour faciliter la compréhension des figures 3 et 5, les tâches de détection de dépassement de durée maximale prédéterminée (en anglais "timeout"), qui déterminent si une durée prédéterminée a été atteinte pour la réalisation de la tâche 200 (respectivement 400), n'ont pas été représentées.
Selon une variante, on intervertit les tâches 400 et 500, cette dernière étant alors effectuée avant la tâche 400 lorsque la tâche 200 a atteint sa durée maximale prédéterminée.
Avant de décrire les figures 2 à 13, on observe que la tâche de paramétrage du dispositif et de l'application, tâche indépendante des tâches décrites en figure 1, n'est pas détaillée dans la description. Elle met en oeuvre des interfaces utilisateurs spécifiques, éventuellement contextuelles, en fonction de la tâche et/ou de l'étape en cours de réalisation, selon des techniques connues.
On observe, en figure 2 que la tâche 100 comporte d'abord une étape 105 d'initialisation du terminal. Puis, au cours d'une étape 110, on active les moyens de communication à courte portée, ici selon le standard Bluetooth. Au cours d'une étape optionnelle 115, on reçoit un message de la part d'un autre terminal comportant une offre de parrainage.
Au cours de l'étape 120, on télécharge les fichiers d'installation de l'application (depuis un ordinateur personnel, depuis un autre terminal mobile (parrainage), depuis un site accessible en ligne, depuis une mémoire amovible). On observe que ces fichiers d'installation peuvent aussi être mis en mémoire du terminal mobile avant la mise à disposition de ce terminal auprès d'un utilisateur. Puis, on installe l'application, on copie les fichiers d'installation pour permettre le parrainage d'un autre utilisateur, c'est à dire la transmission automatique d'une invitation à un autre terminal qui ne met pas encore en oeuvre l'application, à télécharger le programme d'installation de cette application (voir étape 115 pour cet autre terminal). Au cours de l'étape 120, on copie les fichiers d'installation pour pouvoir les transmettre à un autre terminal (parrainage) et on initialise une base de données conservée par le terminal mobile.
Puis, au cours d'une étape 125, on lance l'application, on détecte la marque et le modèle du terminal mobile, l'adresse de ce terminal sur le support de communication à courte portée, par exemple l'adresse Bluetooth, et la langue utilisée par ce terminal mobile et on installe des libellés correspondant à cette langue dans la base de données et on mémorise la marque, le modèle et l'adresse du terminal ainsi que la date d'installation de l'application.
Puis, et à chaque nouveau lancement de l'application, au cours d'une étape 130, on met à jour le nom détectable du terminal local pour ses communications selon le standard de communication (nom appelé nom "Bluetooth" lorsque ce standard est mis en oeuvre) pour qu'il comporte un signe de reconnaissance de l'application implémentant la présente invention et de son état actif ou inactif. Grâce à cette caractéristique, dès la détection d'un autre terminal ("terminal distant"), le terminal local peut déterminer si son application implémentant la présente invention pourra communiquer avec une application homologue fonctionnant sur ce terminal distant ou, dans le cas où le terminal distant ne dispose pas de cette application, si une offre de parrainage peut être mise en oeuvre.
Préférentiellement, le signe de reconnaissance est un caractère muet, c'est-à-dire qui ne se prononce pas, par exemple "(", "{", "[", ")", "}", "]", "°", "#", "~", "&", , "-", "_", "≈". Préférentiellement, le signe de reconnaissance est le deuxième signe d'un couple de signes qui s'utilisent traditionnellement par paire ordonnée, par exemple ")", "}" ou "]", le premier étant préféré, lorsque le terminal distant possède l'application et qu'elle est active car il suggère aussi une onde radio. Le signe de reconnaissance "}" peut, en complément, être utilisé dans le cas où le terminal distant possède l'application mais qu'elle est inactive.
En variante, au cours de l'étape de modification du nom détectable du terminal local, on y incorpore plusieurs informations organisées selon un format prédéterminé. Préférentiellement, dans cette variante, les informations incorporées dans le nom détectable comportent :
- une identification de leur format et
- des informations organisées selon ledit format.
Par exemple, selon un premier format, destiné à être sélectionné par l'utilisateur lors de ses périodes d'activité ou de rencontres professionnelles, l'information incorporée dans le nom détectable est organisée et compressée pour représenter successivement le nom, le prénom, l'entreprise et le secteur d'activité de l'utilisateur et, dans un deuxième format, destiné à être sélectionné par l'utilisateur lors de ses périodes d'inactivité professionnelles, l'information incorporée dans le nom détectable est organisée et compressée pour représenter le pseudonyme, l'âge, le sexe et des sujets d'intérêt de l'utilisateur. Selon un troisième format, l'information incorporée dans le nom détectable est organisée et compressée pour décrire une recherche (offre, demande ou identité, comme expliquer plus loin).
De plus, au cours de l'étape 130 on lance un chronomètre de la durée d'activité de l'application destiné à fournir des éléments statistiques.
Au cours d'une étape 135, l'utilisateur personnalise l'application et saisit un profil personnel qui peut comporter une identité en vue de reconnaissance d'autres utilisateurs de terminaux qui possèdent la même identité (par exemple l'établissement où on travaille, le club de sport dont on est supporter, les établissement où on a fait ses études, ...), une ou plusieurs offres définies par leurs attributs et une ou plusieurs demandes définies par des critères et les fichiers que l'on souhaite partager avec d'autres utilisateurs de l'application. Les rubriques avec lesquelles l'utilisateur définit ses recherches sont choisies dans une hiérarchie ou arborescence prédéfinie, chaque choix que l'utilisateur peut faire en un noeud de l'arborescence étant mémorisé en plusieurs langues dans la base de données de son terminal. Par exemple, le premier niveau de l'arborescence peut comporter les rubriques "rencontres", "emploi", immobilier", "auto/moto", "achat/vente", "services", "informations" et "autre". En fin d'arborescence, les feuilles correspondent à des codes qui sont libres, l'utilisateur, ou un groupe d'utilisateur pouvant ainsi se choisir un code commun pour définir une recherche.
Les offres (recherche d'un type particulier) sont définies par des attributs et des valeurs d'attributs prédéfinies (par exemple voiture - berline - trois portes - années > 2002). Les demandes (recherche d'un autre type particulier) sont définies par des critères qui sont des attributs, des opérateurs agissant entre les valeurs de ces attributs (par exemple ET et OU) et des valeurs de ces attributs prédéfinies (par exemple moto - 750 cm3 - année > 2001 ET année < 2003 ET kilométrage < 40.000). Les demandes peuvent aussi être définies par mots clés (par exemple "décapotable"). Puis, on mémorise la date de dernière modification des données à échanger. Au cours d'une étape 145, l'utilisateur choisit, pour chaque ensemble de données (identité, profil, recherches, par exemple), le mode de communication à d'autres terminaux :
- visible par tous (sauf liste noire),
- "filtré" ou visible que par ses "amis" (liste blanche) ou
- invisible par tous.
Ces données sont mises en mémoire dans la base de données. On observe que les étapes 135 et 145 peuvent être répétées à tout moment par l'utilisateur.
La tâche 100 est alors terminée et on lance la tâche 200 (figure 3). On observe, en figure 3, que la tâche 200 comporte d'abord une étape 205 de détection d'autres terminaux.
Pour certains terminaux téléphoniques qui ne peuvent accepter une demande de détection lorsqu'ils sont eux-mêmes en détection, on inhibe la réponse aux demandes de détection au début de la tâche 200 et on la désinhibe à la fin de cette tâche.
Tant qu'aucun autre terminal n'a été détecté et qu'aucune interruption de tâche n'a lieu (par détection de dépassement de durée maximale prédéterminée, demande d'arrêt de la part de l'utilisateur ou demande d'envoi de la part de l'utilisateur), l'étape 205 se poursuit. On observe que le terminal local est détectable tant qu'il n'utilise pas ses fonctions de communication. On observe aussi que la récupération du nom est coûteuse en temps. Pour limiter ce coût, on met en oeuvre une mémoire cache interne des terminaux détectés récemment. Cependant, afin de vérifier périodiquement que le nom détectable d'un terminal n'a pas changé, au cours d'une étape de détection sur dix, on récupère le nom de chaque terminal détecté ou re-détecté au cours de cette étape, et on rafraîchit ainsi le contenu de la mémoire cache et la base de données.
Dès qu'un nouveau terminal a été détecté, on reçoit de lui :
- un nom dit "définitif, ou adresse sur le support de communication à courte portée, par exemple Bluetooth, non qui est unique, c'est-à-dire qu'aucun autre terminal ne peut posséder le même nom définitif et - un nom détectable (nom "Bluetooth" lorsque ce standard est utilisé) choisi par son utilisateur et modifié par la tâche 100 de l'application implémentant le procédé objet de la présente invention comme expliqué en regard de la figure 2. Les données extraites du nom détectables sont mises en mémoire dans un profil du terminal distant détecté.
Au cours d'une étape 210, on recherche la liste des terminaux déjà récemment détectés et, au cours d'une étape 215, on détermine si le nom définitif de l'autre terminal, qui vient d'être détecté, est présent dans cette liste.
Si le résultat de l'étape 215 est négatif, au cours d'une étape 220, on ajoute, dans la liste des terminaux récemment détectés, au moins les informations suivantes concernant le nouveau terminal détecté : - la date de la détection, en tant que date de dernière détection,
- la probabilité de présence la plus élevée, en tant que probabilité de présence du terminal détecté,
- l'adresse et le nom détectable du terminal détecté ;
- le statut de l'application implémentant le procédé objet de la présente invention dans le terminal qui vient d'être détecté, statut qui peut prendre deux valeurs "actif ou "passif représentative de l'activité de l'application implémentant la présente invention,
- le nombre de tentatives de connexion à effectuer est initialisé à 6 si le statut de l'application est actif et
- les informations extraites du nom détectable du terminal distant. Si le résultat de l'étape 215 est positif, au cours d'une étape 225, on met à jour, dans la liste des terminaux récemment détectés, au moins les informations suivantes concernant le terminal qui vient d'être, de nouveau, détecté :
- la nouvelle date de la détection, en tant que date de dernière détection, tout en conservant l'ancienne date de dernière détection, - la probabilité de présence la plus élevée, en tant que probabilité de présence du terminal détecté,
- l'adresse et le nom détectable du terminal détecté et
- le statut de l'application implémentant le procédé objet de la présente invention pour le terminal détecté, statut qui peut prendre deux valeurs "actif ou "passif, selon que le nom détectable comporte, ou non, le signe de reconnaissance ")" qui indique que ce terminal est susceptible d'échanger des données.
A la suite de l'une ou l'autre des étapes 220 et 225, au cours d'une étape 230, on déclenche une alerte (par exemple une sonnerie ou une vibration du terminal mobile constituant le dispositif objet de la présente invention) si, à la fois : - le terminal qui vient d'être détecté n'est pas filtré (sont filtrés, par exemple, les terminaux dont le statut est "passif, les terminaux qui ne sont pas destinés à transmettre des messages de la part de leur utilisateur, par exemple les imprimantes et les terminaux en liste noire) et
- la différence entre la dernière date de détection et l'ancienne dernière date de détection est supérieure à une durée prédéterminée, par exemple une heure. Cette alerte comporte l'affichage, sur l'écran du terminal local, des données extraites du nom détectable du terminal qui a été détecté et d'autres données mémorisées concernant ce terminal distant.
Après l'étape 230, l'étape 205 est réitérée, sans réinitialisation de la durée maximale prédéterminée (en anglais "timeout"). On observe, en figure 4, que la tâche 300 comporte d'abord une étape 305 de détermination s'il n'y a plus, dans la liste des terminaux récemment détectés, de terminaux possédant une probabilité de présence supérieure à 0. Si le résultat de l'étape 305 est positif, la tâche 300 est achevée et on lance la tâche 400.
Sinon, on effectue une étape 310 de positionnement sur le premier terminal de la liste des terminaux récemment détectés qui possède une probabilité de présence supérieure à la plus faible probabilité de présence possible.
Puis, au cours d'une étape 315, on décrémente la probabilité de présence du terminal considéré, d'une valeur qui dépend du statut du terminal, "actif ou "passif. Par exemple, lorsque le terminal distant est passif, la probabilité la plus élevée est de "3" et est décrémentée de "1" à chaque cycle sans nouvelle détection de ce terminal distant alors que si le terminal distant est actif, la probabilité la plus élevée est de "6". Enfin, pour certains modèles difficilement détectables, la probabilité maximale est de "7" ou "8". Au cours de l'étape 315, on rafraîchit l'écran du terminal qui implémente le procédé objet de la présente invention pour représenter, sur cet écran, le niveau de probabilité de chaque terminal de la liste des terminaux récemment détectés. Au cours de cette étape d'estimation ou de détermination de probabilité de présence, on peut calculer la probabilité de présence d'un terminal en fonction
- du nombre d'étapes de détection successives pour lesquelles ledit terminal n'a pas été détecté depuis sa dernière détection, comme indiqué ci-dessus ;
- du fonctionnement d'une application sur ledit terminal et rendant ledit terminal plus difficile à détecter, auquel cas la probabilité de présence décroît plus lentement (en particulier l'application implémentant la présente invention dont le fonctionnement est signalé dans le nom détectable du terminal distant) ;
- du type dudit autre terminal (plus le terminal distant a une détectabilité faible, moins vite sa probabilité de présence décroît) et/ou - de l'historique des détections dudit terminal (par exemple si un terminal distant a été détecté, en moyenne, trois fois pour quatre phases de détection et qu'il n'est plus détecté trois fois de suite, sa probabilité de présence est plus rapidement réduite que s'il a été détecté, en moyenne fois pour deux phases de détection).
Au cours d'une étape 320, on détermine si le terminal considéré remplit simultanément les conditions suivantes :
- le statut d'application de ce terminal est "actif ;
- le terminal présente une probabilité de présence supérieure à la probabilité de présence la plus faible, ici "0",
- les données auquel le terminal à droit (voir modes de communication visible, filtré ou invisible) qui ont été transmises à ce terminal ne sont pas à jour, c'est-à-dire que la date du dernière échange de données est plus ancienne que la date de dernière mise à jour des données à échanger et
- la durée depuis la date de la dernière tentative de connexion (voir tâche 500) avec le terminal considéré est supérieure à une durée prédéterminée, par exemple cinq minutes. Si oui, on initialise à une valeur prédéterminée (par exemple 6), le nombre de tentatives de connexion à effectuer pour le terminal considéré. Puis on réitère l'étape 305.
Pour éliminer un terminal distant de la liste des terminaux détectés, on prévoit un filtre paramétrable : on exclut des terminaux en fonction de critères (exclure les présents, partis, ignorés liste noire, amis, téléphones, PDA, PC, imprimantes, les passifs, les sans-profils, les avec profils ...). Mais on les garde dans le cache un certain temps. Une fonction "autodelete" activable supprime les terminaux exclus ou "masqués" qui ne sont pas détectés pendant une durée prédéterminée.
On observe, en figure 5, que la tâche 400 comporte d'abord une étape 405 de lecture, en mémoire de la durée "D" de détection choisie (par paramétrage par défaut), par exemple de quatre secondes. Puis, au cours d'une étape 410, on détermine s'il existe encore des terminaux à traiter, c'est-à-dire des terminaux dont la nombre de tentatives de connexion à effectuer est strictement supérieur à "0". Si oui, on affecte la valeur "0" à la variable "T" au cours d'une étape 415. Sinon, au cours d'une étape 420, on effectue un tirage aléatoire équiprobable entre trois valeurs : 2, 3 ou 4, le résultat du tirage étant affecté à la variable "T".
Puis, au cours d'une étape 425, on calcule la durée d'attente à observer comme étant égale au produit de la durée de détection choisie "D" par la variable "T", produit auquel on ajoute une durée prédéterminée, par exemple deux secondes. Ainsi, la durée d'attente peut prendre, de manière équiprobable, l'une des valeurs 10, 14 ou 18 secondes lorsque "D" vaut quatre secondes et que la durée prédéterminée ajoutée vaut deux secondes.
Puis, au cours d'une étape 430, on attend de recevoir une connexion pendant la durée d'attente calculée. La tâche 400 est alors achevée et on lance la tâche 500.
Ce tirage aléatoire permet de désynchroniser deux terminaux qui ne pourraient se détecter parce qu'ils sont synchronisés, c'est-à-dire détectable au même moment et en recherche de détection au même moment. Le tirage à trois valeurs permet d'obtenir deux chances sur trois que deux terminaux synchronisés au cours d'un cycle soient suffisamment désynchronisés au cycle suivant pour que l'un d'entre eux détecte l'autre. On observe, en figure 6, que la tâche 500 comporte d'abord une étape 505 de sélection du terminal de la liste des terminaux récemment détectés pour lequel la durée passées depuis la date de la dernière tentative de connexion est la plus élevée, en éliminant les terminaux dont le nombre de tentatives de connexion à effectuer est nul. Puis, au cours d'une étape 510, on effectue une étape de tentative de connexion avec le terminal considéré, selon des techniques connues, notamment conformément au standard Bluetooth.
Si le résultat de la tentative de connexion de l'étape 510 est un succès, la connexion étant acceptée par le terminal cible, on lance la tâche 700 (voir figures 8 à 12), étape 515.
Si le résultat de la tentative de connexion de l'étape 510 est un échec, c'est-à-dire qu'une durée prédéterminée maximale est dépassée pour l'étape 510 (en anglais "timeout"), au cours d'une étape 520, on décrémente le nombre de tentatives de connexion à effectuer pour le terminal considéré et on met à jour la date de la dernière tentative de connexion du terminal considéré.
Puis, au cours d'une étape 525, on détermine si on a effectué, depuis le dernier lancement de la tâche 500, trois tentatives de connexion ou si une durée prédéterminée pour le déroulement de l'étape 500 est dépassé. Si oui, la tâche 500 est achevée et on lance la tâche 200 (voir figure 3). Sinon, on réitère l'étape 505. Bien entendu, la durée prédéterminée mise en oeuvre au cours de l'étape 525 est supérieure à la durée prédéterminée mise en oeuvre au cours des étapes 510 et 515.
On observe, en figure 7, que la tâche d'envoi 600 comporte d'abord une étape 605 d'initialisation d'un compteur de tentatives de connexion. Puis, au cours d'une étape 610, on détermine si la valeur du compteur de tentatives est égal à un nombre prédéterminé, par exemple trois. Si oui, la tâche 600 est terminée et on lance la tâche 200. Sinon, au cours d'une étape 615, une effectue une tentative de connexion qui met en oeuvre un protocole de découverte de service, connu sous le nom anglais de SDP pour "service discovery protocol", et on initialise un chronomètre (en anglais "timer") et on lance une détection de dépassement de durée maximale prédéterminée (en anglais "timeout").
Si, au moment de cette détection de dépassement de durée, la connexion n'a pas été acceptée, ce qui est déterminé au cours d'une étape 620, au cours d'une étape 625, on incrémente le compteur de tentative de connexion et on retourne à l'étape 610.
Sinon, c'est-à-dire si la connexion est acceptée avant la fin de la durée prédéterminée, au cours d'une étape 630, on récupère le port OBEX disponible, c'est-à-dire disponible pour une connexion conformément au standard Bluetooth. Puis, au cours d'une étape 635, on effectue une tentative de connexion OBEX et, dès que la connexion est acceptée, au cours d'une étape 640, on envoie le message à transmettre (message, carte de visite ou fichier, par exemple).
Puis, au cours d'une étape 645, on met fin à la connexion et la tâche 600 étant achevée, on lance la tâche 200.
Par exemple, l'offre de parrainage d'un autre utilisateur de terminal mobile est une demande d'envoi manuelle.
On observe, en figure 8, que l'entrée de la tâche 700, lorsqu'elle est lancée par la tâche 400, c'est-à-dire qu'une connexion reçue de la part d'un autre terminal a été acceptée, commence par une étape 705 de première réception (réception d'un envoi référencé "1" dans la suite de la description et détaillée en figure 11) et d'enregistrement de premières données. Puis, au cours d'une étape 710, on détermine si le terminal avec lequel la connexion a été établie est déjà référencé dans la base de données, en y cherchant son adresse définitive. Si le terminal est déjà référencé, au cours d'une étape 715, on effectue une mise à jour des données concernant ce terminal, dans la base de données. Si le terminal n'est pas déjà référencé, au cours d'une étape 720, on ajoute le terminal et les données reçues dans la base de données.
A la suite de l'une ou l'autre des étapes 715 ou 720, au cours d'une étape 725, on effectue une comparaison des recherches reçues de la part de l'autre terminal et des recherches conservées dans la base de données locale. Cette comparaison est détaillée en figure 10. Au cas où la comparaison montre une correspondance d'au moins une recherche par terminal, on mémorise le numéro de l'offre et le numéro de la demande, dans une mémoire de correspondances et on émet une alerte à l'utilisateur du terminal, sous forme sonore, visuelle ou par déclenchement de vibreur, par exemple. Cette alerte n'est effectuée que si la correspondance n'a pas déjà été signalée, ce qui peut être déterminé en recherchant le couple numéro d'offre et numéro de demande dans la mémoire de correspondances.
Puis, au cours d'une étape 730, on effectue un premier envoi de données au terminal avec lequel la connexion est établie. Ce premier envoi est détaillé en figure 11. Puis, au cours d'une étape 735, on effectue une deuxième réception (réception d'un envoi référencé "2" dans la suite de la description et détaillé en figure 12) et enregistrement de deuxièmes données. Puis, au cours d'une étape 740, on détermine si au moins un filtre a montré une correspondance avec une recherche filtrée transmise dans les deuxièmes données par l'autre terminal (voir détail en figure 10).
Si oui, on mémorise le numéro de l'offre et le numéro de la demande dans la mémoire de correspondances et on émet une alerte à l'utilisateur du terminal, sous forme sonore, visuelle ou par déclenchement de vibreur, par exemple, si la correspondance n'a pas déjà été signalée. Sinon, ou après le déclenchement de l'alerte, la tâche 700 est achevée et on relance la tâche 200.
On observe en figure 9, que l'entrée dans la tâche 700, lorsqu'elle est lancée par la tâche 500, c'est-à-dire qu'une connexion a été émise à destination d'un autre terminal et acceptée par lui, comporte d'abord une étape 745 de premier envoi de premières données (voir détail de l'envoi "1" en figure 11). A la suite de ce premier envoi, on met à jour la base de données locale en ce qui concerne l'autre terminal. Puis, au cours d'une étape 750, on effectue une étape de réception de premières données (réception d'envoi "1" de l'autre terminal), on enregistre ces premières données en provenance de l'autre terminal et on met à jour les données concernant l'autre terminal dans la base de données locale.
Au cours d'une étape 755, on effectue une étape de comparaison des recherches reçues et des recherches conservées en base de données (voir détail en figure 10). Au cas où la comparaison montre une correspondance d'au moins une recherche par terminal, on mémorise le numéro de l'offre et le numéro de la demande, dans la mémoire de correspondance et on émet une alerte à l'utilisateur du terminal, sous forme sonore, visuelle ou par déclenchement de vibreur, par exemple, si la correspondance n'a pas déjà été signalée. Puis, au cours d'une étape 760, on effectue une deuxième étape d'envoi de deuxièmes données (envoi "2", voir détail en figure 12) qui concernent les recherches filtrées pour lesquelles une correspondance a été détectée au cours de l'étape 755 (voir figure 10). Les recherches filtrées sont les recherches pour lesquelles le mode de communication est "filtré", c'est-à-dire que ces recherches sont réservées aux amis, et que l'autre terminal est identifié comme ami. On observe, en figure 10, que la comparaison de recherches comporte d'abord une étape 905 de mise en correspondance de recherches reçues et de recherches stockées en base de données, selon leur type. Ainsi, les recherches liées à l'identité ne sont mises en correspondance qu'entre elles.
Les demandes ne sont mises en correspondance qu'avec des offres et les échanges ne sont mis en correspondance qu'entre eux. S'il n'y a aucune telle correspondance entre les recherches reçues et les recherches conservées dans la base de données locale, la comparaison est terminée.
Sinon, au cours d'une étape 910, on effectue une comparaison par rubrique. Dans le cas des recherches de correspondance d'identités, celles-ci ne correspondent que si leurs rubriques sont exactement identiques. On rappelle que le terme de rubrique couvre ici l'ensemble des noeuds et feuilles d'une arborescence de choix. Par exemple une rubrique d'identité peut signifier les deux sélections suivantes prédéterminées "communauté / Ecole" pour indiquer que l'identité est celle d'une communauté constitué des élèves sortis d'une même école.
Pour qu'une offre corresponde à une demande, au cours de l'étape 910, il faut que tous les attributs de l'offre soient inclus dans tous les critères de la demande. S'il n'y a aucune telle correspondance entre les recherches reçues et les recherches conservées dans la base de données locale, la comparaison est terminée.
Sinon, au cours d'une étape 915, pour les recherches identitaires, on met en correspondance les codes. Par exemple un code HEC86 représente les anciens élèves de la promotion 1986 de l'école HEC. S'il ne reste aucune correspondance à traiter après l'étape 915, la comparaison est terminée.
Sinon, au cours d'une étape 920, pour les offres et demandes à mettre en correspondance, on considère comme en correspondance les offres dont tous les attributs répondent à tous les critères de la demande.
Au cours d'une étape 925, dans le cas des échanges, qui sont la combinaison d'au moins une offre et d'au moins une demande, si au moins une correspondance offre reçue/demande stockée a été établie au cours de l'étape 920, et que l'offre fait partie d'une recherche d'échange, on recherche si au moins une correspondance peut être établie entre une offre stockée en base de données locale et une demande reçue faisant partie de la même recherche d'échange. Si oui, il y a correspondance de recherche d'échange. Dans tous les cas où une correspondance entre une recherche reçue et une recherche stockée a été établie, au cours d'une étape 930, on émet une alerte à destination de l'utilisateur du terminal et la comparaison est achevée et on poursuit le déroulement de la tâche 700.
On observe, en figure 11 , que l'envoi "1" comporte d'abord une étape 1005 de recherche si, avec le terminal avec lequel une connexion est acceptée, la base de données locale conserve une indication relation "ami", "neutre" ou "ignoré", ce dernier cas correspondant à la liste "noire" des terminaux avec lequel on refuse de communiquer.
Puis, au cours d'une étape 1010, on recherche les données visibles par le terminal avec lequel la connexion est acceptée, en fonction de l'indication de relation retrouvée en base de données locale. Ces données (informations du profil et recherches) sont les données visibles par tous, sauf si cette relation est "ignoré", les informations du profil filtrées si l'indication de relation est "ami" et les recherches visibles par tous, sauf si cette relation est "ignoré". Ainsi, si la relation est "ignorée", on n'envoie aucune donnée, si la relation est "neutre", on envoie uniquement les données visibles par tous, si la relation est "ami", on envoie les données visibles par tous et les informations de profil visibles par les amis. Puis, au cours d'une étape 1015, on recherche les informations techniques à transmettre, en particulier le nom détectable sur le support de communication à courte portée, par exemple Bluetooth, la classe de dispositif (en anglais "class of device").
Au cours d'une étape 1020, on recherche, parmi les données transmissibles, celles qui ont été modifiées depuis le dernier envoi fait au terminal avec lequel la connexion a été acceptée. Au cours d'une étape 1025, on formate les informations à transmettre, même s'il n'y a aucune information modifiée, auquel cas le formatage concerne une trame d'information vide. Au cours d'une étape 1030, on effectue la transmission de l'information à transmettre formatée. Puis, au cours d'une étape 1035, on met à jour la date des données envoyées au terminal avec lequel la connexion est acceptée. On observe, en figure 12, que l'envoi "2" comporte d'abord une étape 1105 de recherche des données filtrées en correspondance avec des recherches reçues de la part de l'autre terminal (voir détail en figure 10).
Au cours d'une étape 1110, on formate les informations à transmettre, même s'il n'y a aucune information modifiée, auquel cas le formatage concerne une trame d'information vide. Au cours d'une étape 1115, on effectue la transmission de l'information à transmettre formatée. Puis, au cours d'une étape 1120, on met à jour la date des données envoyées à l'autre terminal.
La figure 13 récapitule les échanges effectués entre deux terminaux, "A" et "B", "A" étant le terminal qui détecte l'autre terminal, ici "B", communication 1205. Puis, le terminal "A" tente de se connecter au terminal "B", communication 1210. Si la tentative de connexion est un succès, le terminal "B" ouvre la connexion, communication 1215. Puis, le terminal "A" envoie les informations visibles par tous, les informations filtrées si le terminal "B" est référencé comme "amis" dans la base de données du terminal "A" et les recherches visibles par tous, communication 1220.
En réponse, le terminal "B" envoie au terminal "A" les informations visibles par tous, les informations filtrées si le terminal "A" est référencé comme "ami" dans la base de données du terminal "B", ses recherches visibles par tous et les recherches filtrées si des correspondances ont été détectées entre les recherches transmises par le terminal "A" et les recherches conservées dans la base de données du terminal "B", communication 1225. Enfin, le terminal "A" envoie au terminal "B" les recherches filtrées dont la correspondance a été détectée par le terminal "A", communication 1230. On observe que les recherches sont transmises par description de branches d'arborescence et de la partie libre. Ceci permet une communication multilingue car afficher la description de branches d'arborescence peut ensuite être effectué dans la langue du terminal choisie par son utilisateur. Ainsi, sont multilingues, l'interface utilisateur et les libellés des rubriques, des champs et des valeurs. Dans le cas des recherches "invisibles", s'il y a correspondance avec une recherche reçue, on alerte l'utilisateur et on lui affiche le profil de l'utilisateur distant. L'utilisateur décide ensuite de répondre, ce qui rend la recherche visible pour l'autre terminal, ou non.
On observe que, pour le passage d'un terminal distant en liste noire, après connexion à ce terminal distant et envoi de profil, si l'utilisateur du terminal local prend la décision de passer le terminal distant en liste noire, le terminal local effectue une nouvelle connexion avec le terminal distant et lui envoie un profil vide, ce qui provoque l'écrasement du premier profil en mémoire de l'autre terminal, comme toute mise à jour de profil.
On observe que la détection mutuelle des terminaux s'effectue en tâche de fond. Plusieurs applications utilisant l'application de communication implémentant la présente invention peuvent fonctionner simultanément en partageant le canal de communication à courte portée. Dans ce cas, dans l'étape de recherche de données à échanger, on recherche les données de plusieurs applications. L'application implémentant la présente invention transmet toutes ces données ensembles, elles sont multiplexées comme si plusieurs canaux de communication étaient simultanément utilisés, et démultiplexées par l'application mettant en oeuvre la présente invention, sur le terminal distant, qui comporte un filtre multi-applications à cet effet.
En variante, au cours de l'exécution de la tâche 200, on insert le numéro de téléphone dans le nom détectable Bluetooth, ce numéro de téléphone est automatiquement récupérée par l'application mettant en oeuvre la présente invention et elle fait une proposition d'appel immédiat ou d'envoi de minimessage immédiat et, éventuellement effectue la mémorisation du numéro de téléphone dans le répertoire du terminal et dans le profil associé au terminal distant.
En variante, si un terminal distant est en liste noire, on le lui indique. Concernant l'offre de parrainage, dans la version Symbian (marque déposée), le logiciel est envoyé par Bluetooth alors que dans la version Java (marque déposée) ou Windows mobile (marque déposée), on envoie une carte de visite au format "V-card" avec, dans le nom, un message de ce qu'il faut faire pour installer l'application implémentant la présente invention et un lien sur un site WAP où on peut trouver l'application (ouverture de navigateur web automatique par sélection du lien).
La figure 14 représente des successions d'étapes mise en œuvre par deux terminaux pour la mise en correspondance de recherches, dans un mode particulier de réalisation. Les étapes mises en œuvre par l'un des terminaux sont représentées sur la gauche de la figure 14, tandis que les étapes mises en œuvre par l'autre terminal sont représentées sur la droite de la figure 14.
Au cours d'étapes 1405 et 1455, chacun des utilisateurs des terminaux définit son profil, décrivant l'utilisateur du terminal, ce profil est composé d'informations définies en affectant des valeurs à des attributs et, éventuellement, en donnant des mots-clés dans des champs libres.
Puis, au cours d'étapes 1410 et 1460, chacun des utilisateurs des terminaux décrit au moins une recherche, sur chacun d'au moins deux terminaux. A cet effet, l'utilisateur sélectionne, dans une arborescence, une rubrique descriptive de la recherche puis des sous-rubriques descriptives et précisant la recherche. Enfin, l'utilisateur on précise la rubrique choisie dans l'arborescence des rubriques et sous-rubriques, par la saisie d'un texte libre.
En ce qui concerne une recherche de type « offre », l'utilisateur décrit une offre en affectant au moins une valeur à un attribut caractéristique de cette offre et on saisit un texte libre.
En ce qui concerne une recherche de type « demande » l'utilisateur décrit une demande en affectant au moins une condition portant sur un attribut, cette condition comportant un opérateur de comparaison et une valeur saisie librement ou choisie dans une liste de valeurs possibles. En complément, l'utilisateur saisit un ou plusieurs mots clés. En ce qui concerne une recherche de type « échange », l'utilisateur décrit une recherche de type « offre » et une recherche de type « demande », ces deux recherches étant liées entre elles de manière sous-jacente.
En ce qui concerne une recherche de type « rencontre », l'utilisateur décrit une offre correspondant à son profil d'utilisateur et une demande décrivant des conditions à remplir par un profil de l'utilisateur du terminal destinataire.
Pour chaque type de demande, au cours d'une étape 1415 et 1465, chacun des utilisateurs affecte un niveau de visibilité qui définit les appareils qui pourront recevoir la recherche lors de l'étape de communication. Ce niveau de visibilité peut ensuite être modifié à tout moment par l'utilisateur concerné, par l'utilisation de menus appropriés. A cet effet, l'utilisateur choisit entre différents niveaux de visibilité qui lui sont présentés dans un menu. Ces niveaux de visibilité comportent un niveau de visibilité dit « visible par tous » qui a pour conséquence que chaque recherche possédant ce niveau de visibilité peut être diffusée à tous les appareils rencontrés.
Les niveaux de visibilité comportent un niveau de visibilité dit « filtré », chaque recherche possédant ce niveau de visibilité n'étant divulguée à l'utilisateur du terminal destinataire qu'en cas de correspondance avec une des recherches du terminal destinataire.
Les niveaux de visibilité comportent un niveau de visibilité dit « invisible », chaque recherche possédant ce niveau de visibilité n'étant jamais communiquée automatiquement à d'autres terminaux et n'étant donc communiquée qu'après une action manuelle de la part de l'utilisateur. La visibilité de chaque recherche peut être précisée par une liste de terminaux individuellement « exclus », auxquels cette recherche n'est jamais communiquée automatiquement et par une liste de terminaux individuellement « autorisés » qui peuvent automatiquement recevoir cette recherche.
Enfin, l'utilisateur peut identifie des terminaux d'une liste dite « noire », aucune information n'étant communiquée aux dits terminaux de la liste noire. Cette identification peut se faire au moment de l'entrée en communication avec un autre terminal, par sélection, dans un menu, d'une fonction d'entrée en liste noire. Comme on le verra ci-dessous, dans ce cas, la recherche déjà transmise au terminal destinataire est immédiatement réactualisée comme une recherche vide dans le terminal destinataire, qui ne peut donc l'afficher à son utilisateur. Au cours de chaque étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche. Préférentiellement, au cours de l'étape de description d'une recherche, on effectue un horodatage de la dernière édition de la recherche pour chaque niveau de visibilité, afin de conserver la date et l'heure de la dernière modification affectant les informations visibles audit niveau. Techniquement, chaque valeur prédéfinie pouvant être affectée à un attribut possède un identifiant et des libellés dans une ou plusieurs langues.
Au cours d'étapes 1420 et 1470 de communication sans fil, entre un desdits terminaux, dit « terminal émetteur », à gauche, et un autre desdits terminaux, dit « terminal destinataire », à droite, le terminal émetteur transmet au terminal destinataire une information représentative d'au moins une recherche.
Au cours de l'étape 1420 de communication sans fil, entre le terminal émetteur et le terminal destinataire, on communique un identifiant de chaque rubrique sélectionnée, ce qui permet de réduire considérablement la quantité d'information à transférer, d'une part, et d'afficher les rubriques et sous- rubriques dans la langue du destinataire, d'autre part (à cet effet, la liste des rubriques, associée à leurs identifiants, est traduite dans chaque langue dans laquelle le logiciel fonctionne). Les textes libres, mots-clés, valeurs, attributs et conditions sont aussi transmises au cours de cette étape 1420.
Au cours de l'étape 1420 de communication avec un terminal destinataire, on effectue un horodatage de la communication dans le terminal émetteur. Le terminal émetteur détermine si un terminal destinataire a reçu l'ensemble des recherches qu'il peut recevoir en comparant l'horodatage de la précédente communication avec ledit terminal destinataire à l'horodatage de la dernière édition de chaque recherche ayant affecté les informations visibles par ledit terminal. Et on communique au terminal destinataire seulement les recherches dont la dernière version ne lui a pas encore été communiquée.
Au cours d'une étape 1475, le terminal destinataire effectue le traitement de chaque recherche reçue pour déterminer une éventuelle correspondance entre la recherche reçue du terminal émetteur avec au moins une recherche conservée par le terminal destinataire.
Le terminal destinataire détermine une correspondance entre une offre et une demande seulement si les rubriques se correspondent et si toutes les conditions de la demande sont remplies par les attributs de l'offre. De plus, dans des modes de réalisation, il détermine une correspondance entre une offre et une demande si les mots clés de la demande se retrouvent tous dans le texte libre décrivant l'offre ou dans les libellés des rubriques et des valeurs décrivant l'offre, dans la langue utilisée pour exprimer la demande.
En cas de correspondance, on effectue une étape d'affichage 1480, sur le terminal destinataire, d'une information représentative de cette correspondance. Préférentiellement, au cours de l'étape d'affichage, on affiche les rubriques dans une langue sélectionnée pour le terminal destinataire, à partir des identifiants des rubriques sélectionnées.
Dans des modes de réalisation, en cas de correspondance, le terminal destinataire effectue une étape de communication au terminal émetteur, respectivement étapes 1485 et 1425, d'une information représentative de la correspondance trouvée et, au cours d'une étape 1430, on affiche, sur le terminal émetteur, les éléments de la recherche décrite sur le terminal destinataire, par son utilisateur.
Dans la suite de la description, on décrit, pour un mode de réalisation particulier de la présente invention, des concepts, des interfaces utilisateur, des traitements effectués et des données gérées dans un mode de réalisation particulier de la présente invention. On ne décrit ici que les caractéristiques communes à toutes les versions de ce mode de réalisation, indépendamment du système d'exploitation mis en oeuvre (par exemple des marques déposées Symbian, UIQ, Pocket PC, etc.).
Le logiciel implémentant la présente invention, dans ce mode de réalisation, est un logiciel de communication entre terminaux Bluetooth. La mise en oeuvre de la présente invention apporte sur un téléphone mobile ou un assistant personnel ("PDA") des fonctionnalités de communication similaires à des pages personnelles, une messagerie, des communautés, des petites annonces, de la publicité, des communications et transferts entre pairs ("peer to peer"), etc..
Le logiciel est composé de 3 modules fonctionnels : - un module interface utilisateur,
- un module de communication et
- un module de gestion de données.
Le module interface utilisateur regroupe et gère tous les écrans du logiciel : écrans de paramétrage et écrans d'information. Le module de communication gère la détection des terminaux, les échanges d'informations et de recherches entre les terminaux et la comparaison des recherches reçues avec les recherches locales.
Le module de gestion de données prend en charge la lecture et l'écriture, dans la mémoire du terminal, des données qui doivent être conservées lorsque le logiciel est arrêté : recherches, réponses, paramètres, statistiques, ...
Les deux premiers modules font appel au module de gestion des données de façon ponctuelle pour utiliser ses fonctionnalités de lecture et de sauvegarde des données.
Le terminal (en anglais "device") est l'appareil supportant le standard Bluetooth sur lequel est exécutée l'application implémentant la présente invention (dans la suite "l'application"). On rappelle que "Bluetooth" distingue plusieurs classes de terminal (en anglais "class of device" dont l'acronyme est "COD"), par exemple :
- les téléphones,
- les assistants personnels ("PDA"),
- les ordinateurs. Chaque terminal est identifiable par son adresse Bluetooth (en anglais "Bluetooth address") unique. Il a aussi un nom Bluetooth (en anglais "Bluetooth name") qui est en général modifiable.
On appelle terminal local (en anglais "local device"), le terminal du point de vue duquel on se place, et terminal distant (en anglais "remote device") chaque terminal avec lequel le terminal local interagit. Chaque terminal possède un statut pour l'application implémentant la présente invention (en anglais "status") :
"visible" : le terminal a l'application installée et lancée en mode visible, "arrêté" : le terminal a l'application installée et lancée dans un autre mode, "parrainable" : le terminal n'a pas l'application installée mais semble compatible (on peut le parrainer, c'est-à-dire lui envoyer l'application pour qu'elle l'installe).
"passif : le terminal ne peut pas faire tourner l'application mais son nom Bluetooth contient un message de l'application implémentant la présente invention.
"Bluetooth" : le terminal est un terminal Bluetooth qui n'est pas compatible avec l'application. L'utilisateur peut définir sa relation (en anglais "relationship") avec chacun des autres terminaux, parmi les relations suivantes :
- "neutre", "ami" ou "indésirable".
Ces relations permettent de créer deux listes : - la liste des "amis" (en anglais "friend list"), liste contenant tous les terminaux amis et la liste noire (en anglais "black list"), liste contenant tous les terminaux indésirables. Il existe une troisième liste appelée liste des terminaux (en anglais "device list") qui contient tous les terminaux Bluetooth présents sur le moment autour du terminal local.
L'utilisateur possède un profil (en anglais "profile") qui contient des informations regroupées en blocs d'information.
L'utilisateur peut définir une visibilité élémentaire (en anglais "item visibility") pour chaque bloc, qui définit quels terminaux distants pourront lire les informations contenues dans ce bloc. Il existe 3 niveaux de visibilité :
"visible" : les informations contenues dans le bloc seront visibles par tous les terminaux sauf les terminaux indésirables.
"filtre" : les informations contenues dans le bloc ne seront visibles que par les terminaux amis, "invisible" : les informations contenues dans le bloc ne seront visibles par personne. L'application possède également une visibilité générale (en anglais "global visibility") qui permet de définir d'un coup la visibilité maximale des informations. La visibilité appliquée est la plus restrictive, entre la visibilité élémentaire et la visibilité globale. Il y a quatre niveaux de visibilités générale :
- "visible",
- "filtre", "invisible" et - "arrêté".
Lorsqu'elle est "arrêtée", l'application n'envoie aucune information aux autres terminaux et ne répond pas aux demandes. Toutes les communications sont désactivées, mais l'utilisateur a accès aux écrans.
Si nécessaire, les paramètres Bluetooth du terminal sont mis à jour automatiquement en fonction du mode sélectionné : si Bluetooth était désactivé et que l'application passe à un mode autre que "inactif1, alors Bluetooth est activé. Bluetooth est toujours remis dans l'état où il se trouvait avant de démarrer l'application, lorsque l'on repasse au mode "inactif .
Dès que l'on passe au mode "inactif1, l'application arrête le module de communication et dès que l'on passe à un autre mode elle relance ce module. Grâce à l'application, l'utilisateur peut créer des recherches (en anglais "searches") qui lui permettent de trouver des informations, des produits, des personnes ou des services situés à proximité (portée Bluetooth). Une recherche peut être : permanente : elle est stockée dans le terminal, et prévient l'utilisateur dès qu'il est à proximité de ce qu'il recherche. Elle possède un nom. immédiate : elle est exécutée immédiatement pendant un court laps de temps, et n'est pas conservée dans le terminal, donc elle n'est pas nommée. A la fin du laps de temps elle peut être oubliée ou sauvegardée en tant que recherche permanente. Il faudra alors la nommer. Une recherche possède une visibilité élémentaire. Une recherche en visibilité "filtre" n'est visible que par les terminaux sur lesquels une recherche correspondante a été détectée. Chaque terminal publie ses recherches et reçoit les recherches des autres terminaux, en fonction des visibilités choisies. Le logiciel compare les recherches et détecte les correspondances (en anglais "matchings"). S'il y a correspondance, l'utilisateur est prévenu par une alerte et peut consulter la réponse (en anglais "resuit") à sa recherche, c'est-à-dire la recherche distante (sur le terminal distant) qui correspond à sa recherche locale (sur le terminal local).
Une recherche est définie tout d'abord par une rubrique (en anglais "class") qui indique l'objet de la recherche au sein d'une classification arborescente. Une rubrique peut contenir des sous-rubriques, qui sont appelées ses rubriques "filles", elle est alors leur rubrique mère.
Par exemple : - véhicule o auto o moto objet o CD o Meuble communauté o école o association
"auto" est une rubrique fille de "véhicule" et "véhicule" est la rubrique mère de "auto". Pour apporter un degré de précision supplémentaire, l'utilisateur peut définir un code rubrique
(en anglais "class code"). Cette information offre souplesse et extensibilité à la classification des rubriques.
Par exemple, pour rechercher les élèves et anciens élèves de l'école "EPITA", on pourra créer une recherche avec la rubrique "école" et le code rubrique "EPITA" (identifiant convenu). De plus une recherche peut contenir : des mots clés un texte descriptif
II existe 4 types de recherches (en anglais "search type") :
"offre" : recherche qui décrit une offre (par exemple dont la signification est "je vends une moto").
"demande" : recherche qui décrit une demande ("j'achète une moto"), "identité" : recherche qui décrit à la fois une offre et une demande ("je suis passionné de voile et je voudrais rencontrer d'autres passionnés de voile").
"échange" : recherche qui combine une offre et une demande ("je suis un homme et je cherche une femme").
Une recherche, quel que soit son type, contient donc une offre (en anglais "offer") et / ou une demande (en anglais "request"). une offre possède une liste d'informations décrivant ce qu'on propose ; une demande possède une liste de critères décrivant ce qu'on recherche. Chaque recherche est créée grâce à un modèle de recherche (en anglais "search template") qui définit les informations à rentrer pour créer cette recherche. Il peut exister plusieurs recherches différentes basées sur le même modèle de recherche.
Les modèles de recherche sont classés dans les rubriques (en anglais "class") ou les sous- rubriques. Le chemin dans les rubriques vers le modèle de recherche définit la classification des recherches créées par ce modèle de recherche.
Il existe trois modes de correspondance (en anglais "matching mode") : "identité" : une recherche de type "identité" correspond à une recherche de type "identité", "offre/demande" : une "offre" correspond à une "demande", - "échange" : l'offre et la demande de la recherche correspondent à la demande et à l'offre, respectivement, d'une recherche d'un terminal distant.
Le mode de correspondance du modèle de recherche définit le type des recherches qui pourront être créées à partir de ce modèle. Ainsi, un modèle de recherche de type "identité" crée des recherches de type "identité", - un modèle de recherche de type "offre/demande" crée des recherches de type "offre" ou "demande" et un modèle de recherche de type "échange" crée des recherches de type "échange". Un modèle de recherche contient un modèle d'offre et/ou un modèle de demande, selon son mode de correspondance, qui permettent de créer les offres et les demandes des recherches. - identité : un modèle d'offre offre/demande : un modèle d'offre et un modèle de demande échange : un modèle d'offre et un modèle de demande.
Un modèle d'offre est une liste de champs disponibles pour définir les informations d'une offre. Un modèle de demande est une liste de définitions de critère disponibles pour définir les critères d'une demande. Pour pouvoir comparer deux recherches, elles doivent avoir été créées à partir du même modèle de recherche.
Les modèles de recherche sont définis par des "assistants" (en anglais "wizards"). L'utilisateur peut ajouter ou supprimer des assistants dans le logiciel. Lorsqu'un assistant est installé, il peut ajouter dans le logiciel : de nouvelles rubriques et des modèles de recherche dans celles-ci et de nouvelles informations dans le profil, ajoutées dans des blocs existants ou dans de nouveaux blocs.
L'assistant ne définit pas comment les informations seront affichées : il ne décrit que les modèles de recherche et leur classification (les rubriques).
Chaque assistant possède un identifiant unique (en anglais "id") constitué de trois lettres (majuscules ou minuscules) ou chiffre (autrement dit : [a-zA-ZO-9] [a-zA-ZO-9] [a-zA-ZO-9] ). Ceci offre la possibilité de créer 238328 assistants différents.
Un champ est défini par un label, un ensemble des valeurs possibles, et éventuellement une liste des unités acceptées. Par exemple :
"âge", valeur numérique comprise entre 0 et 200, "couleur", à choisir entre { rouge, vert, bleu } et
- "taille" en cm (de 0 à 300) ou en inch (de 0 à 120). Une information est une valeur qui correspond à un champ, en précisant une unité si plusieurs sont possibles. Par exemple : âge = 10 ans couleur = bleu - prix = 10 euros
Un critère est un triplet (champ, opérateur, valeur). Le champ correspond à une valeur dans une offre. La comparaison des deux valeurs grâce à l'opérateur permet de déterminer si le critère est vérifié ou non.
Par exemple : - "10" > âge et
- "texte" contient "Mobil uck".
Un modèle de critère appartient à un modèle de demande. Il contient un label, une référence vers un champ du modèle d'offre associé et un opérateur. Un modèle de critère permet de créer des critères. Par exemple : age_min, âge, < artiste, artiste, =
Une valeur peut se voir associer une unité, lorsqu'elle est de type numérique. Par exemple : - 10 ans 174 euros
Un ensemble de valeurs possibles peut préciser des unités possibles.
On décrit ci-après les contraintes et normes d'ergonomie de l'interface utilisateur :
L'interface utilisateur de l'application est adaptée à de nombreux systèmes d'exploitation (Symbian Séries 60, UIQ, Palm OS, Pocket PC, Windows, WEB, etc, marques déposées...) dont les normes d'ergonomie et les contraintes techniques sont différentes.
L'interface utilisateur est composée d'écrans et de boîtes de dialogue. Les écrans permettent d'afficher simultanément six lignes de texte d'une vingtaine de caractères. Une ligne peut être sélectionnée à l'aide des touches haut et bas. Il est possible d'afficher plus de six lignes dans un écran grâce à un défilement.
On peut aussi utiliser une autre présentation d'écran, elle aussi basé sur six lignes affichées, cependant les lignes sont groupées deux par deux ce qui permet d'associer le descriptif et le contenu d'un champs.
Dans les écrans, les touches dynamiques de gauche et de droite du clavier sont réservées aux fonctions Options" et "Retour". La fonction "Retour" revient à l'écran affiché précédemment. La fonction "Options" affiche le menu "Options" qui présente les commandes disponibles, déterminées dynamiquement en fonction de la ligne sélectionnée.
Pour certaines options, un sous-menu proposant plusieurs choix est affiché. Le sous-menu est ouvert à l'aide de la flèche vers la droite ou de la touche de sélection du pavé directionnel. Un choix peut être sélectionné à l'aide des touches haut et bas, puis validé avec la touche sélection.
Des touches de raccourci facilitent l'exécution de certaines options. Ces touches sont la flèche vers la gauche (G), la flèche vers la droite (D) et la sélection (S) du pavé directionnel.
De plus, le logiciel utilise la touche "modifier" afin de faire apparaître l'aide correspondante au champs ou à l'écran sélectionné. Pour la saisie des textes longs (texte des annonces, textes des messages, etc), l'exemple retenu est celui du paramètre "Mon nom Bluetooth".
Le titre de l'écran initial est "MobiLuck" (marque déposée). Il s'agit d'un menu qui propose les actions les plus courantes. Pour les autres versions, l'écran initial pourrait être "Qui est là ?" ou "Mes Recherches". L'écran "qui est là ?" affiche la liste des terminaux Bluetooth détectés à proximité.
Cet écran exploite les informations stockées en mémoire dans la liste des terminaux par le module de communication. Il est rafraîchit dynamiquement dès qu'un nouveau terminal est détecté. A l'ouverture de cet écran, le module de communication lance une " inquiry " (s'il est en mode écoute).
Pour les terminaux passifs le nom Bluetooth n'apparaîtra pas en entier, seul le pseudo est affiché dans cet écran.
On remarques que :
- le statut peut être utilisée comme un critère de filtrage dans l'écran " Qui est là ? " ou pour déclencher des alertes. Chaque statut est représenté par un logo distinctif à rechercher,
- la relation peut être utilisée comme un critère de filtrage dans l'écran " Qui est là ? " ou pour déclencher des alertes. Les terminaux en liste noire sont systématiquement ignorés et - dans ce mode de réalisation, le principe de paiement retenu est de faire payer à l'utilisateur une seule unité par contact, c'est-à-dire soit lors de la consultation ou utilisation des informations personnelles, soit lors de l'affichage du détail d'une réponse.
Des actions payantes (actions nécessitant que le terminal ai été payé : ouvrir terminal, ouvrir réponse, envoyer message, téléphoner, ajouter contact, montrer et lancer) peuvent être activées à partir des écrans "qui est là ?", "terminal X", "Mes Réponses" et "Réponse X".
Les écrans "Terminal X" et "Réponses X" ne sont accessibles qu'après paiement d'une unité et peuvent donc proposer toutes ces actions. Par contre, les écrans "Qui est là ?" et "Mes réponses" peuvent contenir des terminaux/réponses payés et d'autres non payés. Trois solutions sont donc possibles :
- actions payantes non affichées,
- actions payantes affichées uniquement pour les terminaux payés ou affichées mais grisés pour les terminaux non payés.
- actions payantes affichées pour tous les terminaux payés et non-payés avec paiement automatique lors de la première action payante.
L'écran "Terminal X" peut être affiché à partir des écrans suivants :
- "Qui est là ?" (le titre de cet écran est alors le nom Bluetooth du terminal sélectionné).
- "Réponse X" (Le titre de cet écran est alors le nom Bluetooth du terminal émetteur de la réponse). Cet écran affiche les blocs d'information visibles du terminal sélectionné ainsi que les blocs d'information avec la visibilité filtre si le terminal local est enregistré dans "Mes amis" du terminal sélectionné. Les informations des blocs d'informations ne possédant qu'un ou deux champs renseignés sont affichées directement. Les noms des blocs d'informations possédant trois champs renseignés ou plus, sont affichés et servent de liens. On note un cas particulier, pour les blocs d'information contenant des listes d'objet (ex : "fichiers partagés"), le nombre d'objets est précisé.
Les actions proposées varient selon le terminal sélectionné. Des conditions spécifiques doivent être réunies pour qu'une action soit proposée.
L'écran "Messages prédéfinis" permet de choisir un message prédéfini à envoyer ou de créer un nouveau message. L'écran "Message X" permet de modifier un message prédéfini ou de créer un nouveau message. Le titre de cet écran est le nom du message.
Les actions proposées varient selon le terminal sélectionné. Des conditions spécifiques doivent être réunies pour qu'une action soit proposée.
L'écran "Message alerte" affiche un simple message d'alerte (comme pour la notification d'un SMS) à l'utilisateur dès qu'une alerte choisie dans l'option de menu "paramètres/alertes" se produit. Ce message s'affiche même si l'interface utilisateur n'est pas active. S'il s'agit d'une alerte réponse dans ce cas l'écran propose de voir l'écran "Mes Réponses" en affichant que les réponses correspondant à la (aux) recherche(s) concluante(s). Le message s'efface automatiquement au bout d'une durée paramétrable (voir "Réglages"). Exemples de message affichés : - " 1 nouvelle réponse provenant d'une application distante ",
- " 1 nouveau terminal parrainable. ",
- " 1 nouveau terminal implémentant l'application ",
- " 1 nouveau terminal Bluetooth. " ou - " 1 nouveau terminal Ami. "
L'écran "Filtrage" permet de filtrer la liste des terminaux affichés par l'écran "Qui est là ?". Il est accessible par le " menu paramètres " (version assistant personnel) soit dans l'écran "Qui est là" (version Symbian).
Plusieurs critères sont proposés pour définir les terminaux à afficher : - la classe principale Bluetooth du terminal (Class Of Device) : téléphone, PDA, ordinateur, imprimante, fax, oreillette, autres ,
- le statut d'application : "Bluetooth", "Parrainable", "Passif, "arrêté",
- la relation avec le terminal : "Ami", "Neutre", "Liste noire".
- la présence : "présent", "parti" (s'il a été payé). Cet écran permet également d'activer/désactiver l'alerte déclenchée lorsqu'un nouveau terminal apparaît dans l'écran "Qui est là ?".
L'écran "Recherche X" a pour titre le nom de la recherche. Il ne permet pas directement de modifier le contenu de la recherche. Cet écran affiche l'ensemble des champs renseignés lors de la définition de la recherche L'écran "Mes réponses" est affiché différemment selon l'interface depuis laquelle il est ouvert.
Les réponses non lues figurent en tête de liste et sont triées par date.
Le titre de l'écran "Réponse X" est le nom de la recherche distante. Cet écran est très similaire à l'écran " Recherche X " mais pour une recherche distante, sachant qu'il y a quelques informations supplémentaires à afficher et quelques actions différentes. L'écran "Mon profil" permet à l'utilisateur de saisir toutes les informations le concernant afin de les publier et/ou de les utiliser comme valeurs par défaut pour la création de recherches.
L'écran "Bloc d'information X" a pour titre le nom du bloc d'information ouvert. Dans cet écran sont affichés toutes les informations du bloc d'information.
Il y a quatre écrans du type "Fichiers partagés" : Photos, Vidéos, Sons et Autres. On remarque que les fichiers de l'application (installation et modules supplémentaires) sont automatiquement mis dans "Autres Fichiers" et n'y apparaissent pas. Dans ces écrans sont affichés les différents fichiers partagés du type correspondant à l'écran.
L'écran "Paramètres" est un menu permettant de consulter et de modifier les divers paramètres du logiciel. Dans cet écran sont affichés les différentes catégories de paramètres : alertes, messages prédéfinis, modules, Mes amis, liste noire, langues, réglages, rechargement et statistiques.
L'écran "Alertes" permet de choisir les événements qui déclenchent l'affichage d'un message d'alerte et de préciser le son utilisé pour signaler chaque événement. Des cases à cocher sont proposées à l'utilisateur pour faire une sélection parmi les événements suivants :
- détection d'un nouveau terminal Bluetooth , - détection d'un nouveau terminal parrainable, - détection d'un nouveau terminal implémentant l'application,
- détection d'un nouveau terminal ami,
- détection d'une nouvelle correspondance et
- réception d'un message d'une application distante. Des listes déroulantes permettent de choisir les sons correspondants. Le logiciel tient compte du mode de fonctionnement sélectionné avant d'émettre une alerte. Les alertes sonores sont remplacées par une vibration en mode " Invisible ".
L'écran "Modules" sert à gérer les différents modules. Il permet notamment de supprimer des modules et de modifier le classement des modules pour que l'ordre dans l'assistant de définition de recherches corresponde aux préférences de l'utilisateur. Certains modules " masqués " n'apparaissent pas dans cet écran et ne peuvent pas être supprimés. Dans cet écran sont affichés les noms des différents modules visibles installés, classés dans l'ordre des indices de classement.
L'écran "Mes amis" affiche les noms des terminaux inscrits dans la liste des amis de la même manière que l'écran " Qui est là ? ", sans le symbole ami. L'écran "Liste noire" affiche les noms des terminaux inscrits dans la liste noire de la même manière que l'écran " Qui est là ? " sans le symbole liste noire.
L'écran "Langues" permet à l'utilisateur d'indiquer les langues que le logiciel aura à gérer. On remarque que si, parmi toutes les langues de l'assistant, aucune ne figure dans ces quatre langues alors l'assistant sera affiché dans sa première langue. L'écran "Réglages" permet de définir des paramètres techniques du logiciel :
- durée "Inquiry" (un nombre entier de seconde) qui définit la durée d'une étape de détection,
- ratio "Inquiry'V'écoute" (un pourcentage) qui définit le ratio des durées des étapes de détection et de détectabilité,
- durée de vie des terminaux de la liste de terminaux "deviceList" (un nombre entier de minutes) qui définit une durée avant de renouveler une alerte après une absence de détection lorsque le terminal est détecté de nouveau,
- le nombre de tentatives de connexion.
La stratégie de détection (sous la forme d'une liste) peut être modifiée par l'utilisateur pour modifier ces réglages, sans en connaître le détail, l'utilisateur privilégiant la rapidité de détection des autres terminaux ou du sien et/ou l'autonomie de son terminal.
L'écran "Statistiques" affiche les différentes statistiques relatives à l'utilisation de l'application implémentant la présente invention.
Les principaux besoins de gestion de données sont les suivants : sauvegarder et charger certaines informations dans la mémoire permanente du terminal. o Mémoriser des informations de types divers (nombres, chaînes de caractères,...) regroupées par blocs d'informations, et gérer la visibilité de chaque bloc. o Charger des assistants complémentaires pour créer des recherches envoyer certaines informations à d'autres terminaux, et pouvoir en recevoir. o Gérer une liste de fichiers disponibles pour les autres terminaux, et les envoyer. o Gérer une liste de terminaux amis et une liste de terminaux indésirables o Gérer les unités (compteur d'unités, décompte, rechargement, ...) manipuler en mémoire des données nécessaires au fonctionnement du logiciel. Les contraintes techniques qui s'appliquent comportent : le logiciel doit supporter plusieurs langues, la langue utilisée est définie par un paramètre, la plupart des chaînes de caractères affichées sont différentes selon la langue choisie ; il faut que toutes les versions du logiciel (symbian, palm, pocket pc, marques déposées) soient compatibles entre elles (puissent communiquer et utiliser les mêmes modules de recherche), sécurité : o ne pas pouvoir imiter le comportement du logiciel (i.e. : créer un logiciel compatible, capable de communiquer avec l'application implémentant la présente invention) o ne pas pouvoir modifier le compteur d'unités pour s'en rajouter o ne pas pouvoir créer de modules qui mettent à mal le bon fonctionnement de l'application - respect des standards, afin d'obtenir des certifications (par exemple Nokia OK, marque déposée).
Pour la réalisation du prototype, les inventeurs ont effectué les choix techniques suivants : les données sont codées de la manière la plus portable possible. Ainsi on crée des classes "tampon" qui permettent d'abstraire une partie de la plate-forme. Par exemple, les chaînes de caractères ne sont pas gérées de la même façon sous Symbian, Palm OS et Pocket PC
(marques déposées). On crée donc une classe chaîne (en anglais "string") qu'on utilisera pour gérer les données, qui présentera la même interface dans toutes les versions, mais qui sera implémentée de manière différente, le volume de données géré étant faible, on n'utilisera pas de base de données, - le stockage et l'échange des données se fait via des fichiers XML, les fichiers XML sont décrits par des fichiers XML schéma,
Les plates-formes visées ne nous permettent pas d'utiliser le format WBXML qui aurait permis d'économiser de la place (aucune librairie n'a été trouvée sous Symbian). Certaines données sont : - sauvegardées sur le terminal local afin de pouvoir les conserver entre deux lancements de l'application et/ou - transférées entre le terminal local et un terminal distant.
Du point de vue du stockage, l'application et les fichiers sont stockés dans un répertoire " mobiluck " organisé de la façon suivante. Le répertoire " assist " contient toutes les définitions d'assistants. Le répertoire " Profiles " contient un répertoire par profil, le nom de chaque répertoire étant le pseudo choisi pour ce profil. Chacun de ces répertoires contient toutes les informations concernant ce profil : recherches, listes d'amis, informations personnelles, correspondances.
Le transfert et le stockage des données se fait sous le même format : XML. Le format de ces fichiers XML est décrit par des fichiers XML schémas. Certains attributs sont présents dans le document XML généré seulement lorsqu'on transfère ou seulement lorsqu'on stocke. Par exemple, les informations de visibilité des blocs d'information sont présents lorsqu'on stocke le profil sur le terminal local pour le sauvegarder, mais pas lorsqu'on transfère son profil à un terminal distant. Ceci est documenté dans les schémas XML.
Le chapitre suivant décrit les traitements effectués par le logiciel implémentant la présente invention sur le réseau Bluetooth, les terminaux, et les recherches :
- communications,
- gestion des terminaux,
- gestion et comparaison des annonces,
- sauvegarde et chargement des données, - traitements de sécurité,
- actions effectuées par l'utilisateur et
- traitements divers.
Dans tout ce qui suis, le terme "client" définit le terminal qui établit la connexion. Le terme serveur définit le terminal qui accepte la connexion. On note que les transactions bornes / bornes ne sont pas envisagées. Le fichier échangé contient toutes les recherches et informations visibles de petite taille. Le terminal qui reçoit les recherches compare les recherches reçues avec ses recherches et renvoie toute ses recherches visibles ainsi que les recherches filtres qui ont correspondu. Les informations de grosse taille (photos par exemple) seront envoyées en utilisant le transfert de fichier sur demande explicite de l'utilisateur. Le terminal local traite les recherches reçues à partir du terminal distant avant d'envoyer les siennes au terminal distant de manière a pouvoir aussi envoyer les recherches filtres qui correspondent à des recherches en provenance du terminal distant. Ceci évite d'avoir à faire un traitement particulier pour les bornes, toutes les recherches des bornes sont en mode "filtre".
La transaction d'envoi de mises à jour des recherches et des informations a lieu quand le contenu d'une recherche change ou que des recherches ou informations changent de visibilité. Les événements susceptibles d'entraîner une mise à jours sont :
- l'ajout d'une recherche ou d'une information,
- le changement de visibilité élémentaire d'une recherche ou d'une information et
- la modification d'une recherche ou d'une information. Dés qu'il y a un changement, on renvoie toute les recherches et les informations comme dans la transaction (annulation et remplacement) afin d'éviter des traitements de mise à jour des informations dans le terminal distant.
La transaction de transfert de fichiers a lieu entre deux terminaux implémentant la présente invention. Elle permet de demander un fichier d'un terminal à un autre (comme par exemple la photo de l'utilisateur, de la musique, des documents, etc.).
Le transfert a lieu à la demande de l'utilisateur du terminal de destination. La liste des fichiers est disponible dans les informations de l'utilisateur du terminal source. Cette solution a l'avantage d'éviter une requête supplémentaire au terminal source pour obtenir cette liste des fichiers disponibles. Cet échange de messages ne peut avoir lieux que si l'échange de message initial a eu lieu (pour récupérer la liste des fichiers disponibles).
La transaction de parrainage a lieu entre un terminal local implémentant l'application et un terminal parrainable. Le terminal implémentant l'application envoie un message ObEx contenant l'application pour le système d'exploitation du terminal distant. Un fois le message reçu, le terminal nouvellement parrainé ObEx propose automatiquement d'installer le logiciel.
La base SDP permet de récupérer la Class Of Device (COD) d'un terminal donné. Le COD d'un terminal contient le type de terminal (souris, oreillette, ...).
Un terminal passif est un terminal Bluetooth n'exécutant pas l'application implémentant la présente invention mais dont le nom détectable contient une recherche ou des éléments de profil de l'utilisateur (voir figures 2 et 3).
Cette transaction se passe entre un terminal passif et un terminal dont l'application est active ou une borne. Le terminal actif récupère la recherche dans le nom Bluetooth du terminal passif et la compare avec ses recherches locales.
Quand un terminal local enregistre dans sa liste d'amis un terminal distant, le terminal local envoie au terminal distant un message contenant la confirmation qu'il est inscrit dans la liste d'amis de du terminal local.
Dans un message qui contient les informations et recherches à envoyer au terminal distant, les recherches peuvent être indifféremment visible ou filtre et les informations peuvent être indifféremment filtre ou visible. Il se peut que la partie information et/ou la partie recherche soit vide. Avec un message qui contient la demande de fichier à télécharger à partir du terminal distant, le terminal local peut retrouver les fichiers disponibles dans les informations de l'utilisateur du terminal distant.
Le module de communication utilise les fonctions élémentaires décrites ci-dessous.
- la détection des terminaux se fait via des "inquiries" Bluetooth. On obtient ainsi les adresses Bluetooth et le nom Bluetooth. La phase d'inquiry a une durée variable,
- un terminal est détectable lorsqu'il n'est pas connecté à un autre terminal et qu'il n'est pas en train de faire d'inquiry,
- le terminal peut publier des informations de service en utilisant SDP ("Service Discovery Protocol"). Il est donc possible aux terminaux de savoir si l'application implémentant la présente invention est installée sur un terminal et si oui, quelle est sa version, l'état du logiciel (Actif, ...), les modules installés. Si SDP ne fonctionne pas, il est toujours possible d'utiliser le nom Bluetooth du terminal,
- le terminal local obtient les informations de service en interrogeant la base SDP du terminal distant. Si on utilise le nom Bluetooth du terminal pour stocker les informations de service, le terminal local les récupère en demandant son nom au terminal distant lors de l'inquiry,
- pour l'envoi et la réception des données, trois techniques sont envisageables : les connexions RFCOMM, les connexions OBEX (OBject EXchange) mise en oeuvre dans les modes de réalisation décrits ci-dessus et - transmission de données via SDP (Le terminal émetteur met à jours ces données SDP, le terminal récepteur interroge la base SDP de l'émetteur). Pour détecter certains terminaux, le texte de la recherche commence par un caractère spécifique qui a peu de chance de débuter par hasard le nom d'un terminal, par exemple ')'. Lorsque ce caractère est détecté, le nom Bluetooth sera considéré comme une recherche et interprété. Si le nom du terminal commence par le caractère ')' par hasard, mais qu'il ne s'agit pas d'une recherche, le logiciel ne détectera jamais de correspondance ou bien ne sera pas capable de répondre. Le logiciel se comportera correctement en cas d'erreur de formatage de la recherche.
Le traitement des terminaux détectés comportent les fonctions suivantes : - lors de la découverte d'un terminal, on recherche dans la liste noire l'adresse Bluetooth du terminal détecté. Si le terminal n'est pas dans la liste noire et que le terminal n'est pas dans la liste des terminaux "DeviceList", on traite le terminal et on l'ajoute dans la liste des terminaux "DeviceList" ;
- la liste des terminaux "DeviceList" doit être mise à jour à intervalle de temps régulier de manière à retirer les terminaux qui n'ont pas été détectés depuis un certain temps.
- le traitement d'un terminal distant : si une recherche passive est contenue dans le nom Bluetooth du terminal distant, on traite la recherche. Si c'est un terminal dont l'application implémentant la présente invention est active, on échange et on traite les recherches.
- le fichier envoyé au terminal distant contient les recherches visibles stockées sur le terminal et les informations visibles stockées sur le terminal. Si le terminal distant est dans la liste des terminaux amis, on envoie les informations filtres disponibles sur le terminal. Si le fichier est envoyé après la réception des recherches distantes sur le terminal local, on y rajoute les recherches filtres qui ont matchées avec les recherches fraîchement reçues. Si le terminal local possède des réponses à des recherches " bouche à oreille ", le terminal local rajoute aux recherches existante des offres contenant les données à propager et correspondant avec des demande " bouche à oreille ".
- le logiciel découpe la recherche et crée les structures de données internes correspondant à la recherche. Ensuite une comparaison avec toutes les recherches locales disponibles est faite. En cas de correspondance (en anglais "matching"), on notifie l'utilisateur. On prévient éventuellement le terminal passif par un appel téléphonique ou un SMS.
- pour chaque recherche reçue, si la recherche n'est pas déjà enregistrée dans la liste des réponses (Match List), pour chaque recherche stockée, s'il y a correspondance entre la recherche reçue et la recherche stockée, enregistrer la réponse et la signaler à l'interface utilisateur. On compare le type de la recherche distante et le type de la recherche locale. Si les types correspondent on poursuit la comparaison en comparant les offres et les demandes. S'il y a correspondance entre l'offre de la recherche 1 et la demande de la recherche 2 et qu'il y a correspondance entre la demande de la recherche 1 et l'offre de la recherche 2, alors, il y a correspondance entre les deux recherches. On vérifie tout d'abord la correspondance des classes des recherches. Puis on compare les codes des deux recherches. Ensuite on compare les conditions de la recherche locale avec les caractéristiques de la recherche distante. Enfin on compare les mots clefs de la recherche locale avec le texte libre de la recherche distante. On note que les classifications sont des codes de 5 caractères, que pour qu'il y ait correspondance, il faut que la classification de la demande corresponde aux premiers caractères de la classification de l'offre et que l'offre peut être plus précise que la demande mais elle doit être incluse dans la demande. En cas d'écart de précision, seule la recherche du moins précis est satisfaite. Une recherche moins précise peut ne pas potentiellement intéresser l'utilisateur (Logique d'inclusion et non d'égalité). Pour que les recherches correspondent, la classe locale de la recherche doit être inclue dans la classe distance, le code rubrique de la recherche locale doit correspondre avec celui de la recherche distante, les mots clés de la recherche locale doivent correspondre avec ceux de la recherche distante. On compare les conditions de l'offre avec les caractéristiques de la demande distante. Si une condition de l'offre n'est pas dans la demande, il n'y a pas correspondance. Une condition locale correspond à une condition distante s'il existe un attribut dans la recherche distante nommée comme la condition locale, et que la valeur de l'attribut distant est en accord avec la condition locale. Il y a correspondance si toutes les conditions locales sont en accords avec les attributs distants. La chaîne de recherche contenant les mots clés est analysée et découpée. Elle peut contenir plusieurs mots clés séparés par des espaces. Si tous les mots clefs spécifiés dans la recherche sont dans le texte de l'offre, il y a correspondance. - les traitements d'entrée-sortie sont ceux gérant la sauvegarde et la récupération des informations. Pour l'écriture (et aussi pour l'envoi sur le réseau) on passera par une phase de formatage des données. Pour la lecture des données (et pour la réception sur le réseau) on passera par une phase de parsing (que l'on pourrait traduire par "découpage/interprétation") des données. L'application implémentant la présente invention n'utilise pas de base de données, les données sont sauvegardées dans un fichier XML. Les traitements de sauvegarde consistent à formater les données et à les écrire dans ce fichier. Les traitements de chargement consistent à lire ce fichier, à l'analyser et à créer les objets interne à l'application. Ces traitements classiques ne sont pas décris dans ce document.
- comme le format de stockage choisi pour les données est (WB)XML, le formatage des données consiste à générer du code XML conforme aux "XML Schémas" définis dans la partie donnée à partir des objets en mémoire. - de manière à préserver la confidentialité des échanges entre les utilisateurs et à éviter le
"reverse engineering" (ingénierie inversée) du protocole utilisé pour communiquer entre les périphériques, toutes les communications passant sur le réseau Bluetooth seront cryptées en utilisant les possibilités de cryptage automatique proposées par Bluetooth.
- pour recharger les unités d'un terminal, on génère aléatoirement un identifiant de quatre chiffres (en se basant sur l'heure en cours, l'adresse Bluetooth du terminal, ...). L'utilisateur envoie cet identifiant à un serveur qui renvoie la réponse contenant cet identifiant et le nombre d'unités achetées crypté avec la clé privée de l'application. Le téléphone décrypte le message reçu, compare l'identifiant reçu avec l'identifiant généré, et en cas de similitude, incrémente le compteur d'unités du nombre d'unités achetées. - au lancement de l'application, le profil utilisé est le profil par défaut non protégé. L'utilisateur peu créer des profils secrets protégés par mot de passe. Il saisit le mot de passe choisis et le nouveau profil est crée. Pour passer d'un profil à un autre, il lui suffit de taper le mot de passe désiré. Lorsque l'utilisateur change de profil, son nom Bluetooth est mis à jours. Un fois ce profil activé il peut le supprimer. - lors de l'initialisation de l'application implémentant la présente invention, celle-ci charge le profile, s'enregistre dans la base SDP, fourni à cette base toutes les informations nécessaires, lance le module de communication et affiche le menu principal.
- lors du passage en mode inactif, l'application implémentant la présente invention sauvegarde le profile courant, restaure les paramètres Bluetooth qu'elle aurait éventuellement modifié et mets son statut à "inactif" dans la base SDP. Lors de la fermeture de l'interface graphique, le module de communication continue à tourner en tache de fond.
- l'identifiant unique associé à chaque recherche est calculé de la manière suivante : id = addrBT + systemTime systemTime étant le nombre de millisecondes écoulées depuis le temps " zéro " sur le terminal (généralement depuis le 1ler janvier 1970) à la création de la recherche ou lors de sa modification.
- les notifications de correspondance sont reportées à l'utilisateur sous forme de sonnerie quand le terminal est en mode "visible" ou "filtre", via le vibreur si le terminal en est équipé et que le mode du terminal est "invisible". Si le terminal ne possède pas de vibreur, aucun son ne sera émis.
Parmi les applications de la présente invention, on peut citer les petites annonces, le partage de jeux, les communautés, les informations locales, par exemple état du trafic, les informations de gares, par exemple la voie et l'heure d'un train, les informations de guichet bancaire, les audio-guides de musées, les offres de tous les magasins d'un centre commercial.

Claims

REVENDICATIONS
I - Procédé de mise en relation automatique de terminaux proches, caractérisé en ce qu'il comporte une procédure de détection mutuelle en tâche de fond comportant en alternance :
. une étape de détection des terminaux détectables (200) et . une étape au cours de laquelle le terminal est lui-même détectable (400). 2 - Procédé selon la revendication 1, caractérisé en ce qu'il comporte, pour au moins un cycle, une étape de tirage aléatoire (420) et, en fonction du résultat dudit tirage, une étape de définition (425), pour ce cycle, de la durée d'au moins une des étapes de détection ou de détectabilité.
3 - Procédé selon la revendication 2, caractérisé en ce que le tirage aléatoire (420) est équiprobable et l'étape de définition (425) définit la durée de l'étape de détectabilité en fonction d'un multiple de la durée de l'étape de détection et du résultat du tirage aléatoire.
4 - Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, une fois qu'un terminal a détecté un autre terminal susceptible de communiquer, il effectue au moins une tentative de connexion à cet autre terminal (500).
5 - Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que au cours de chaque cycle, le nombre de tentatives de connexion est inférieur à une valeur prédéterminée (320,
610).
6 - Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que le nombre de tentatives de connexion successives au même terminal est inférieur à une valeur prédéterminée (525, 610). 7 - Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que si des tentatives de connexions avec plusieurs terminaux sont à effectuer, on ne tente pas plusieurs fois de suite de se connecter au même terminal (500).
8 - Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'un nombre limite de tentatives de connexion par terminal est défini (320), lorsque ce nombre de tentatives est atteint sans qu'une connexion puisse être établie, on attend pendant au moins une durée prédéterminée, avant d'effectuer de nouveau au moins une tentative de connexion avec ce terminal.
9 - Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comporte :
- une étape de modification du nom détectable du terminal (130) pour y incorporer au moins un signe de reconnaissance d'une application prédéterminée en fonctionnement et susceptible d'échanger des données avec d'autres terminaux et
- pendant une étape de détectabilité, en cas de détection par un autre terminal, une étape de transmission dudit nom détectable.
- pendant une étape de détection, en cas de détection d'un autre terminal, une étape d'analyse du nom du terminal détecté afin d'y rechercher ledit signe de reconnaissance (220, 225). 10 - Procédé selon la revendication 9, caractérisé en ce que, au cours de ladite étape de modification du nom détectable (130), on ajoute au moins un caractère reconnaissable en début du nom détectable.
II - Procédé selon l'une quelconque des revendications 9 ou 10, caractérisé en ce que, au cours de l'étape de modification de nom détectable (130), on ajoute le caractère ")" au nom détectable.
12 - Procédé selon l'une quelconque des revendications 9 à 11, caractérisé en ce que, au cours de l'étape de modification du nom détectable (130), on modifie le nom détectable pour y incorporer soit un premier signe de reconnaissance indiquant l'installation sur ledit terminal d'une application prédéterminée, ladite application étant arrêtée, soit un deuxième signe de reconnaissance indiquant l'installation sur ledit terminal de l'application prédéterminée, ladite application étant en fonctionnement.
13 - Procédé selon l'une quelconque des revendications 9 à 12, caractérisé en ce qu'il comporte une étape de recherche de détection (200) d'au moins un terminal possédant un nom détectable possédant ledit signe de reconnaissance et, lorsqu'un tel terminal a été détecté, une étape d'arrêt momentané de recherche d'autres terminaux.
14 - Procédé selon l'une quelconque des revendications 9 à 13, caractérisé en ce que, au cours de l'étape de modification du nom détectable du terminal (130), on y incorpore plusieurs informations organisées selon un format prédéterminé. 15 - Procédé selon la revendication 14, caractérisé en ce que lesdites informations comportent :
- une identification de leur format et
- des informations organisées selon ledit format.
16 - Procédé selon l'une quelconque des revendications 14 ou 15, caractérisé en ce que, en cas de détection d'un autre terminal, on effectue une étape d'analyse du nom du terminal détecté afin d'y rechercher lesdites informations.
17 - Procédé selon Tune quelconque des revendications 1 à 16, caractérisé en ce que qu'il comporte :
- une étape de détection d'un autre terminal (200, 205) et
- une étape de mémorisation (220, 225) d'au moins :
. un identifiant dudit autre terminal et . la date de la dernière de ces tentatives.
18 - Procédé selon la revendication 17, caractérisé en ce que, au cours de l'étape de mémorisation (220, 225), on mémorise, en outre, un nombre de tentatives d'établissement de connexion avec ledit autre terminal déjà effectuées (520).
19 - Procédé selon l'une quelconque des revendications 17 ou 18, caractérisé en ce que, après un nombre prédéterminé de tentatives infructueuses concernant un autre terminal, on arrête les tentatives d'établissement de liaison avec ledit autre terminal (610).
20 - Procédé selon l'une quelconque des revendications 17 à 19, caractérisé en ce que, au cours de l'étape de mémorisation (220, 225), on mémorise, en outre, si une application prédéterminée fonctionne sur ledit autre terminal. 21 - Procédé selon l'une quelconque des revendications 17 à 20, caractérisé en ce qu'il comporte une étape de détermination de probabilité de présence (315) et une étape de tentative de connexion (300, 305) au cours de laquelle on tient compte d'une probabilité de présence dudit autre terminal pour déterminer si une tentative de connexion doit être effectuée. 22 - Procédé selon la revendication 21, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction du nombre d'étapes de détection successives pour lesquelles ledit terminal n'a pas été détecté depuis sa dernière détection.
23 - Procédé selon l'une quelconque des revendications 21 ou 22, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction du fonctionnement d'une application sur ledit terminal et rendant ledit terminal plus difficile à détecter.
24 - Procédé selon l'une quelconque des revendications 21 à 23, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction du type dudit autre terminal. 25 - Procédé selon l'une quelconque des revendications 21 à 24, caractérisé en ce que, au cours de l'étape de détermination de probabilité de présence (315), on calcule la probabilité de présence d'un terminal en fonction de l'historique des détections dudit terminal.
26 - Procédé selon l'une quelconque des revendications 1 à 25, caractérisé en ce qu'il comporte :
- une étape de mémorisation d'identifiants de terminaux avec lesquels une communication a été établie (220, 225, 715, 720) et
- une étape de mémorisation (220, 225, 715, 720) de la date et de l'heure à laquelle une communication a été établie, pour chaque terminal dont un identifiant a été mémorisé.
27 - Procédé selon la revendication 26, caractérisé en ce qu'il comporte, en outre, une étape de mémorisation d'un nombre de tentatives d'accès effectuées auprès de chaque terminal dont un identifiant a été mémorisé, au cours d'un cycle ou d'un intervalle de temps prédéterminé.
28 - Procédé selon l'une quelconque des revendications 26 ou 27, caractérisé en ce qu'il comporte, en outre, une étape de mémorisation d'identifiants de terminaux avec lequel l'utilisateur ne souhaite pas communiquer (145).
29 - Procédé selon l'une quelconque des revendications 26 à 28, caractérisé en ce qu'il comporte, en outre, une étape de mémorisation (715, 720) de la date de mise à jour des données déjà transmises à chaque terminal dont un identifiant a été mémorisé.
30 - Procédé selon l'une quelconque des revendications 1 à 29, caractérisé en ce qu'il comporte une étape d'alerte de détection d'un autre terminal (230) lorsque au moins une durée prédéterminée s'est écoulée depuis sa dernière détection. 31 - Procédé selon l'une quelconque des revendications 1 à 30, caractérisé en ce qu'il comporte une étape de détermination d'un mode de communication (145) entre au moins :
- un mode de communication dans lequel une application mise en oeuvre par ledit terminal communique avec tout autre terminal, à l'exception de terminaux avec lequel l'utilisateur ne souhaite pas communiquer et - un mode de communication dans lequel une application mise en oeuvre par ledit terminal ne communique qu'avec des terminaux explicitement identifiés en mémoire dudit terminal. 32 - Procédé selon la revendication 31, caractérisé en ce que, au cours de l'étape de détermination d'un mode de communication (145), dans un mode de communication, l'application ne communique avec aucun autre terminal. 33 - Procédé selon l'une quelconque des revendications 31 ou 32, caractérisé en ce que, au cours de l'étape de détermination d'un mode de communication (145), dans au moins un mode communication, une partie des informations n'est transmise qu'à des terminaux explicitement identifiés en mémoire dudit terminal.
33 - Procédé selon l'une quelconque des revendications 1 à 32, caractérisé en ce qu'il comporte : - une étape de détection d'au moins un autre terminal (205) et
- une étape d'estimation de probabilité de présence (220, 225, 315) de chaque dit autre terminal.
34 - Procédé selon la revendication 33, caractérisé en ce que, au cours de l'étape d'estimation de probabilité de présence (220, 225, 315), à chaque fois qu'un autre terminal est détecté (205, 220, 225), sa probabilité de présence est maximale et cette probabilité décroît ensuite progressivement (315).
35 - Procédé selon l'une quelconque des revendications 33 ou 34, caractérisé en ce que, au cours de l'étape d'estimation de probabilité de présence (220, 225, 315), la probabilité de présence d'un terminal décroît en fonction du nombre de fois où ledit terminal n'est pas détecté.
PCT/FR2006/000464 2005-03-01 2006-03-01 Procede et dispositif de mise en relation automatique de terminaux proches Ceased WO2006092505A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR0502095 2005-03-01
FR0502095A FR2882875A1 (fr) 2005-03-01 2005-03-01 Procede et dispositif de mise en relation automatique de terminaux proches
FR0509109 2005-09-06
FR0509109A FR2882876A1 (fr) 2005-03-01 2005-09-06 Procede et dispositf de mise en relation automatique de terminaux proches

Publications (1)

Publication Number Publication Date
WO2006092505A1 true WO2006092505A1 (fr) 2006-09-08

Family

ID=36337450

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/000464 Ceased WO2006092505A1 (fr) 2005-03-01 2006-03-01 Procede et dispositif de mise en relation automatique de terminaux proches

Country Status (2)

Country Link
FR (1) FR2882876A1 (fr)
WO (1) WO2006092505A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2369964A (en) * 2000-12-11 2002-06-12 Ubinetics Ltd Short range data communication between Personal Digital Assistants
WO2004064328A2 (fr) * 2003-01-10 2004-07-29 Philips Intellectual Property & Standards Gmbh Formation de reseau dynamique pour reseaux adhoc sans fil

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2369964A (en) * 2000-12-11 2002-06-12 Ubinetics Ltd Short range data communication between Personal Digital Assistants
WO2004064328A2 (fr) * 2003-01-10 2004-07-29 Philips Intellectual Property & Standards Gmbh Formation de reseau dynamique pour reseaux adhoc sans fil

Also Published As

Publication number Publication date
FR2882876A1 (fr) 2006-09-08

Similar Documents

Publication Publication Date Title
EP1836636A1 (fr) Support personnel de mémoire de masse portatif et système informatique d&#39;accès sécurisé a un espace utilisateur via un réseau
EP2199966A1 (fr) Procédé de sécurisation de transactions, dispositif de transaction, serveur bancaire, terminal mobile, et produits programmes d&#39;ordinateur correspondants
EP2143053A1 (fr) Procédé de communication et de transmission d&#39;un message concernant une transaction d&#39;une application sans contact, terminal, module sécurisé et système associés
WO2009047164A1 (fr) Dispositif et procedes de diffusion personnalisee de publicites ciblees depuis un serveur local
FR2837953A1 (fr) Systeme d&#39;echange de donnees
FR3065606A1 (fr) Procedes pour le partage de donnees de localisation entre un dispositif source et un dispositif destinataire, serveur, dispositifs source et destinataire et programme d&#39;ordinateur correspondants.
EP1378106B1 (fr) Systeme d&#39;echange de donnees numeriques
BE1021629B1 (fr) Procede et systeme de generation automatique de documents a partir d&#39;un index
FR2968497A1 (fr) Procede et systeme de diffusion de contenus informatiques vers un terminal mobile
EP1869942A2 (fr) Dispositif de communication locale selective sur base contextuelle
WO2003046730A2 (fr) Procede de securisation d&#39;un acces a une ressource numerique
WO2006092505A1 (fr) Procede et dispositif de mise en relation automatique de terminaux proches
FR2882875A1 (fr) Procede et dispositif de mise en relation automatique de terminaux proches
EP1473684A1 (fr) Système de création de communauté d&#39;intérêt
FR2914089A1 (fr) Appareil electronique communicant, systemes et procedes utilisant un tel appareil.
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
WO2015055653A1 (fr) Procede et systeme de generation automatique de documents a partir d&#39;un index
EP2351340B1 (fr) Procede de communication utilisant une image numerique et procede de transmission de donnees
EP2797284A1 (fr) Procédés et dispositifs pour l&#39;accès contrôlé à des données stockées dans un réseau
KR102162425B1 (ko) 연락처정보와 함께 서비스 검색결과를 제공하는 기능을 가지는 단말장치
FR2864283A1 (fr) Procede et dispositif de controle d&#39;acces a un document partage dans une reseau de communication poste a poste
EP2274882B1 (fr) Procede de transmission de message, dispositif et produit programme d&#39;ordinateur correspondants
FR3003978A1 (fr) Procede de gestion d&#39;une donnee confidentielle, systeme et programme d&#39;ordinateur associes
WO2009077568A1 (fr) Objet portable pour filtrer un message entrant non voulu, terminal et procede correspondants
FR2901381A1 (fr) Systeme informatique a gestion universelle et collaborative de fichiers utilisateurs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

122 Ep: pct application non-entry in european phase

Ref document number: 06726005

Country of ref document: EP

Kind code of ref document: A1

WWW Wipo information: withdrawn in national office

Ref document number: 6726005

Country of ref document: EP