EP3948752A1 - Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication - Google Patents

Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication

Info

Publication number
EP3948752A1
EP3948752A1 EP20732257.9A EP20732257A EP3948752A1 EP 3948752 A1 EP3948752 A1 EP 3948752A1 EP 20732257 A EP20732257 A EP 20732257A EP 3948752 A1 EP3948752 A1 EP 3948752A1
Authority
EP
European Patent Office
Prior art keywords
communication
terminal
product
service
offer
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.)
Pending
Application number
EP20732257.9A
Other languages
German (de)
English (en)
Inventor
Fabrice JEANNE
Romain TRINQUART
Sandrine LE CALVEZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP3948752A1 publication Critical patent/EP3948752A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0613—Third-party assisted
    • G06Q30/0615—Anonymizing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0251—Targeted advertisements
    • G06Q30/0267—Wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer

Definitions

  • the user to order a product or service using a communication terminal, the user enters information about the product or service into a search engine. Such information describes the product or service that the user wishes to order and possibly includes the amount at which the user wishes to purchase the product or service.
  • a search is then launched on the basis of the information entered and, in return, the user's terminal displays a list of suppliers who may offer the user the product or service corresponding to the information entered.
  • Another drawback of this type of process is that personal data relating to the suppliers is disclosed in the list of suppliers received. Suppliers are therefore not immune to being contacted by a malicious user, for example in the event that the amount of the product or service required is high. The fact also that the user contacts a supplier from the list a
  • One of the aims of the invention is to remedy the drawbacks of the aforementioned state of the art.
  • an object of the present invention relates to a method of ordering a product or a service by means of a communication terminal associated with a communication identifier.
  • Such a method is remarkable in that it comprises the following, at the terminal level:
  • N communication identifiers N> 1
  • the N terminals being supplier terminals identified by the server as being able to provide the product or service, as a function of all or part of the information contained in the request, said communication being established by masking the identifier of
  • the communication receives an offer of the product or service from at least one supplier terminal among at least K, such as 1 ⁇ K ⁇ N, the offer having been generated during the communication and selected as optimizing a compromise between, on the one hand, all or part of the information contained in the request and, on the other hand, a datum for locating the communication terminal and / or a time datum associated with the request, ordering the return of the offer, the communication identifier of said at least one supplier terminal as well as the identification of the supplier of said at least one supplier terminal being masked during the return.
  • K such as 1 ⁇ K ⁇ N
  • Such a method of ordering a product or service is particularly simple and quick to implement for the user, since the latter is content to just send a request to a server using his terminal to specify the information. relating to the product or service he wishes to order.
  • the user also does not need to contact one by one the N suppliers of the product or service he wishes to obtain, such contacts being executed in the background or in the background. initiative of the user's terminal.
  • the method of ordering a product or service is easier to use and is performed much faster than in the prior art.
  • Another advantage of such a method is that it preserves the confidentiality of personal data both on the side of the terminal which requested the product or service offer, and on the side of the N terminals of product or service providers who have been identified.
  • the method comprises the following, in the event of acceptance of the offer:
  • the anonymity of the user of the communication terminal and the anonymity of the supplier of the product or service whose offer has been accepted are lifted only once the offer has been accepted by the terminal user.
  • the method comprises the following, in the event of refusal of the offer:
  • the terminal receives, from respectively N-K product or service provider terminals identified by the server, N-K refusal to provide the product or service corresponding to the request.
  • Such an embodiment advantageously allows the user of the terminal who sent the request to order the product or service, to only receive offers from the remaining K suppliers interested in the product or service ordered. This results in a reduction in the exchanges which will be likely to take place during the communication between the user's terminal and the remaining K supplier terminals, which leads to a limitation of the congestion of the communication network between the terminal. user and provider terminals.
  • the product or service offer received during the communication is generated by taking into account at least one adjustment variable of:
  • the advantage of such an embodiment is that the user of the terminal receives at least one product or service offer, even if the latter does not exactly correspond to the information relating to the product or service mentioned in the request and / or the location of the terminal and / or the date / time at which the request was sent and / or the time information indicated in the request.
  • the various aforementioned embodiments or features can be added independently or in combination with each other, to the product or service ordering method defined above.
  • the invention also relates to a communication terminal for ordering a product or a service, said communication terminal being associated with a communication identifier.
  • Such a terminal is remarkable in that it comprises a processor which is configured to implement the following:
  • N communication identifiers N> 1
  • the N terminals being supplier terminals identified by the server as being able to provide the product or service, as a function of all or part of the information contained in the request, said communication being established by masking the identifier of
  • the communication identifier of said at least one supplier terminal as well as the identification of the supplier of said at least one supplier terminal being masked during the return.
  • Such a communication terminal is in particular able to implement the aforementioned product or service ordering method.
  • the invention also relates to a computer program comprising instructions for implementing the method for ordering a product or service according to the invention, according to any one of the particular embodiments described above, when said program is executed by a processor.
  • Such instructions can be stored durably in a non-transient memory medium of the communication terminal.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other. desirable shape.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the recording medium can be any entity or device capable of storing the program.
  • the medium can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a USB key or a hard disk.
  • the recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet type network.
  • the recording medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned product or service ordering method.
  • Figure 1 is a schematic and general view of an architecture in which the product or service ordering method is implemented, in a particular embodiment of the invention
  • FIG. 2 represents a communication terminal for ordering a product or a service, in a particular embodiment of the invention
  • FIG. 3 represents the main actions implemented in the product or service ordering method according to a particular embodiment of the invention.
  • FIG. 1 represents an environment in which the method of ordering a product or a service according to the invention is implemented.
  • a server SER for connecting the terminal TERu with each of the communication terminals TERf-i, TERf 2 , ..., TERf N of suppliers.
  • an RC communication network This may be, for example, an IP type network (abbreviation for "Internet Protocol"), an x-DSL, fiber or even 3G, 4G, 5G, etc. type network.
  • IP type network abbreviation for "Internet Protocol”
  • x-DSL abbreviation for "x-DSL”
  • fiber or even 3G, 4G, 5G, etc. type network.
  • the TERu terminal and the TERf-i, TERf 2 , ..., TERf N terminals are:
  • the terminal TERu is conventionally associated with a communication identifier ICu, such as for example the mobile telephone number, the fixed line number, the IP address or else the permanent email address of the user UT, such an identifier itself. having been assigned by one or more telecommunications operators to which the user UT is subscribed or even by one or more communication identifier ICu, such as for example the mobile telephone number, the fixed line number, the IP address or else the permanent email address of the user UT, such an identifier itself. having been assigned by one or more telecommunications operators to which the user UT is subscribed or even by one or more communication identifier ICu, such as for example the mobile telephone number, the fixed line number, the IP address or else the permanent email address of the user UT, such an identifier itself. having been assigned by one or more telecommunications operators to which the user UT is subscribed or even by one or more communication identifier ICu, such as for example the mobile telephone number, the fixed line number, the IP address or else the permanent email address of the
  • the terminal TERf For a provider terminal TERf, (1 ⁇ i £ N) considered among N, the terminal TERf, is conventionally associated with a communication identifier ICf , such as for example the mobile telephone number, the fixed line number, the 'IP address or the permanent email address of the supplier f ,, such an identifier having been assigned to it by one or more telecommunications operators to which the supplier f is subscribed or even by one or more service providers
  • the terminal TERu comprises a software application (or application program) APu which is dedicated to the implementation of the product or service ordering method in accordance with the present invention.
  • the APu application is downloaded to the TERu terminal, upstream of the execution of the product or service ordering process.
  • the supplier terminals TERf-i, TERf 2 , ..., TERf N also each include a corresponding software application (or application program) APf-i, APf 2 , ..., APfisi which is able to communicate with the application AP U during the implementation of the product or service ordering method according to the present invention.
  • the applications APf-i, APf 2 , ..., APf N are respectively downloaded in the supplier terminals TERf-i, TERf 2 , ..., TERf N , upstream of the execution of the product ordering process or on duty.
  • the SER server stores in a memory or a database:
  • a virtual communication identifier is for example a sequence of numeric or alphanumeric characters generated for example randomly.
  • the virtual identifier of the user UT (respectively of a supplier f, considered among N) is intended to circulate in the communication network RC instead of the communication identifier ICu (respectively of the communication identifier ICfj ) in order to preserve the anonymity of the user UT (respectively the supplier f, product or service).
  • FIG. 2 shows the simplified structure of the communication terminal TERu suitable for implementing the method for ordering a product or a service which will be described below.
  • the communication terminal TERu comprises:
  • connection interface IC which is adapted to communicate, via the communication network RC, according to for example the http protocol (English abbreviation of
  • the TERu terminal stores in a memory MEM1 the application APu dedicated to the execution of the product or service ordering process according to the invention.
  • the actions executed by the product or service ordering method are implemented by instructions from a computer program PG.
  • the terminal TERu has the conventional architecture of a computer and comprises in particular a memory MEM2, a processing unit UTR, equipped for example with a processor PROC, and controlled by the computer program PG stored in memory MEM2 .
  • the computer program PG comprises instructions for implementing the actions of the product or service ordering method which will be described below, when the program is executed by the processor PROC, according to any one of the particular modes. embodiment of the invention.
  • the code instructions of the computer program PG are for example loaded into a RAM memory (not shown) before being executed by the processor PROC.
  • the processor PROC of the processing unit UTR notably implements the actions of the product or service ordering method, according to the instructions of the computer program PG. Description of an embodiment of the product or service ordering method
  • the user UT wishes, within the framework of an electronic purse service, to withdraw cash using his TERu terminal, in a partner store.
  • the user wishes to buy a car of brand X, model Y and color Z.
  • the user UT opens the APu application and enters, via a user interface generated by the APu application, information relating to the product or service that the user wishes to order.
  • a user interface can be vocal and reproduced via the loudspeaker HP of FIG. 2 or else textual and reproduced on the screen EC of FIG. 2.
  • the information relating to the product or service includes the amount that the user UT wishes to withdraw, ie t euros.
  • the information relating to the product or the service comprises the type of product: “car”, the price, the brand X, the model Y, the color Z of the desired car.
  • the information could be limited to the word “car” or to a combination of the word “car” with one and / or the other of the headings "price”, make X, model Y, color Z.
  • Product or service information may also include:
  • GPS coordinates abbreviation for “Global Positioning System” of the TERu terminal.
  • one or more temporal data relating to the entry for example the date of the entry, the instant of the entry in hours, minute (s), second (s),
  • temporal data relating to the sending of the request such as for example time-stamping data
  • temporal data relating to the provision of the desired product or service such as for example a day of the week or of the current month, a time slot during the day, 9:30 to 12:30, for example.
  • the information relating to the product or service required also includes one or more adjustment variables:
  • an adjustment variable consists for example of a tolerance range on this price, for example plus or minus 5%, 10%, etc. .
  • information contained in the request is location data, such as a distance of j kilometers around the terminal of
  • an adjustment variable consists for example of a tolerance range over this distance, for example j plus or minus 500 m, 1 km, etc.
  • an adjustment variable consists for example of a variation of a time slot initially mentioned in the request or a period of validity of the order of the product or the desired service, for example 1 day, 2 days, 1 week, etc ...
  • the information entered is sent, via the RC network in Figure 1, to the SER server, using the APu application.
  • Such sending can be implemented by means of a key generated by the user interface of the application APu and reproduced on the screen EC or by means of a voice command generated by the user interface of the application.
  • the request sent complies, for example, with the http or https protocol.
  • the SER server receives the request. It then identifies the N suppliers fi, f 2 , - - -, Î N as being able to provide the requested product or service. Such identification is implemented using a data analysis mechanism which uses all or part of the information relating to the product or the service contained in the request sent in S2 and which calculates a probability according to which the N suppliers fi, f 2 , - - -, Î N are able to provide the required product or service. The probability is possibly calculated on the basis of a local history accessible by the SER server.
  • the SER server thus estimates from the transactions already carried out by the suppliers fi, f 2 , ..., f N and stored in a local history, that they are capable of providing the amount of t euros requested by the user UT.
  • the server SER is able to evaluate from the local history that such and such a car required by the user UT is in stock with all the suppliers fi, f 2 ,. .., ÎN-
  • Such identification makes it possible to obtain in a completely transparent manner for the user UT, and in a dynamic and targeted manner, a list of suppliers for whom there is a high probability that they will be able to respond favorably to the request for ordering a product or service sent in S2.
  • the server SER sends the application APu a response to the request received.
  • a response contains the relative virtual identifiers IVf-i, IVf 2 , ..., IVf N
  • the virtual identifiers IVf-i, IVf 2 , ..., IVf N sent in S4 are associated respectively with the probabilities calculated by the server SER, according to which the N providers fi, f 2 , ..., ÎN are able to provide the required product or service.
  • the APu application receives the response.
  • the server SER receives the request and then creates an anonymized exchange channel for the connection in peer-to-peer mode of the application APu of the terminal TERu with each of the applications APf-i, APf 2 , etc. , APf N of the supplier terminals TERf-i, TERf 2 , .. repetTERf N.
  • the server SER sends a connection request to each of the applications APu and APf-i, APf 2 , ..., APf N.
  • the communication between the application APu and each of the applications APf-i, APf 2 , ..., APf N is then established, after validation with the server SER, by the applications APu and APf 1; APf 2 , ..., APf N , of the connection request.
  • Communication is established for example by means of a synchronous or asynchronous bidirectional communication protocol, such as for example of the WebSocket, http, etc. type.
  • the communication is implemented in the background, therefore in a transparent manner for the user UT.
  • the aforementioned public communication identifiers ICu and ICf-i, ICf 2 , ..., ICÎN are masked during the communication since they are replaced by the aforementioned virtual identifiers respectively IVu, IVf-i, IVf 2 , .. ., IVf N.
  • the application APu sends in the background, to each of the applications APf 1; APf 2 , ..., APf N , the request previously sent to S2.
  • Said request may contain, in addition to the information already mentioned in relation to operation S2 above, one or more adjustment variables:
  • a temporal data associated with the request such as for example the date of the entry, the instant of the entry in hour, minute (s), second (s), a day of the week or of the current month , a time slot during the day, 9:30 am to 12:30 pm, for example.
  • the adjustment variable may for example consist of a tolerance of plus or minus 5% of the amount of t euros requested.
  • the adjustment variable may for example consist of a tolerance on the color Z initially entered.
  • Each of the supplier terminals TERf-i, TERf 2 , ..., TERf N then estimates locally whether it is able, at the moment when it receives the request sent in S10, whether the
  • suppliers fi, f 2 , ..., f N identified are able to respond favorably to the request, depending on all or part of the information contained in this request, the adjustment variables contained in this request and / or possibly variables adjustment exchanged during said communication between the application APu and each of the applications APf-i, APf 2 , ..., APf N and / or any adjustment variables already accepted by the service providers.
  • Such an estimate is established by calculating probabilities considering as input the information contained in this request and the aforementioned adjustment variables.
  • the estimate is based, for example:
  • the estimate is based, for example:
  • the estimate is calculated by taking into account another color, for example the color gray and / or the color black.
  • NK suppliers such as K £ N
  • the application APu receives (not shown in Figure 3) N-K messages refusing to provide the desired product or service from the N-K corresponding applications from the N-K supplier terminals K + 1, ..., N.
  • K applications APf-i, APf 2 , ..., APf K each send a response to the application APu, each response containing the conditions of the offer that can be proposed by the corresponding supplier fi, f 2 ,. .., f “and which are based on the calculation of the estimate above.
  • the application APu receives in the background each of the K responses respectively containing K offers of the required product or service.
  • a phase of negotiation between the application APu and each of the K applications APf-i, APf 2 , ..., APf K is then implemented in the background, so as to select at least one product offer or optimal service.
  • This offer is selected as optimizing a compromise between, on the one hand, all or part of the information contained in the request sent in S10 and, on the other hand, at least one data item for the location of the communication terminal TERu, as described above.
  • All offers that the APu application has responded favorably can be ranked in order of best to least optimal offer.
  • the APu application receives the optimal product or service offer in the background.
  • the control of the return of the optimal offer is carried out on, for example, a return interface of the terminal TERu, such as for example the screen EC or the loudspeaker HP of FIG. 2.
  • a return interface of the terminal TERu such as for example the screen EC or the loudspeaker HP of FIG. 2.
  • an icon representing anonymously the supplier f is displayed on a map of the location of the supplier f , which allows the user UT to roughly locate the location of the supplier f ,.
  • no personal information on the supplier f is displayed on the EC screen.
  • a sentence of the type: "the supplier f, is 5km from your home to the north-west” is spoken via the loudspeaker HP.
  • Such a sentence does not disclose any personal information about the provider f ,, whether it is his name, address, communication identifier ICf, provider terminal TERf, etc.
  • a contract for the offer of the desired product or service is generated by the application APu according to preprogrammed parameters, such a contract being considered as signed by the user UT, but not including at this stage any personal data relating to the user UT.
  • the terminal TERf receives the contract, and if it is validated by the supplier f, according to the same principles as those implemented for the user UT, the generation of a contract signature by the supplier f, is triggered via the APf application ,. At this stage, the contract does not include any personal data relating to the supplier f ,.
  • the terminal TERu receives the contract signed by the supplier f i.
  • the user UT are restored in S21 on the terminal TERf ,, in a textual or voice manner.
  • this could be the name and email address of the user UT.
  • the terminal TERu also receives in the background, from the terminal TERf ,, and according to a predefined configuration, personal data relating to the supplier f i. Depending on this predefined configuration, it can be, for example, the name, an e-mail address of the
  • the personal data of the supplier f, which have been received are restored in S21 on the terminal TERu, in a textual manner, for example on the screen EC of the terminal TERu, or alternatively by voice, using the top - loudspeaker of the TERu terminal.
  • the The ordering method returns to operation S13 to select one of the remaining offers among K-1.
  • the selection is implemented by iteration in the order in which the offers were sorted, an iteration being performed until a new optimal offer is selected.
  • the connection established in S13 ends.
  • the control method then returns to the input operation S1, where the user UT is invited to input additional information to that initially input in S1. Then the S2 and following operations are repeated.
  • the connection established in S13 remains, and the control method returns to S10 where pre-configured adjustment variables are applied to:

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Bioethics (AREA)
  • Human Resources & Organizations (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Game Theory and Decision Science (AREA)
  • Quality & Reliability (AREA)
  • Medical Informatics (AREA)
  • Operations Research (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Primary Health Care (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un procédé de communication sécurisée pour commander un produit ou un service au moyen d'un terminal de communication, comprenant ce qui suit, au niveau du terminal : - envoyer (S2, S10) à un serveur une requête contenant des informations relatives à un produit ou à un service, - établir (S9) en arrière-plan une communication vers N terminaux de fournisseur(N≥1) identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations de la requête, ladite communication étant établie en masquant l'identifiant de communication du terminal et des N terminaux, - au cours de la communication, recevoir (S14) en provenance d'au moins un terminal de fournisseur parmi au moins K, tel que 1≤K≤ N, une offre d'un produit ou d'un service correspondant auxdites informations, l'offre ayant été générée durant la communication.

Description

Procédé de communication sécurisée adapté pour commander un produit ou un service à l’aide d’un terminal de communication
Domaine de l'invention
La présente invention se rapporte de manière générale au domaine des
communications sécurisées, en particulier dans le cadre de la commande d’un produit ou d’un service à l’aide d’un terminal de communication (téléphone mobile, tablette, ordinateur, etc.).
Art antérieur
Actuellement, pour commander un produit ou un service à l’aide d’un terminal de communication, l’utilisateur saisit des informations relatives au produit ou au service dans un moteur de recherche. De telles informations décrivent le produit ou le service que l’utilisateur souhaite commander et comprennent éventuellement le montant auquel l’utilisateur souhaite acquérir le produit ou le service. Une recherche est alors lancée sur la base des informations saisies et, en retour, le terminal de l’utilisateur affiche une liste de fournisseurs susceptibles d’offrir à l’utilisateur le produit ou le service correspondant aux informations saisies.
L’inconvénient de ce type de procédé de commande réside dans le fait que l’utilisateur doit ensuite naviguer dans la liste des fournisseurs reçue, prendre contact avec chacun d’entre eux afin de savoir si les fournisseurs sont réellement en mesure de répondre à la commande. Un tel procédé de commande est fastidieux et chronophage pour l’utilisateur. Il est aussi peu fiable compte tenu du fait que la recherche est elle-même généralement très approximative.
Un autre inconvénient de ce type de procédé est que des données personnelles relatives aux fournisseurs sont divulguées dans la liste de fournisseurs reçue. Les fournisseurs ne sont donc pas à l’abri d’être contactés par un utilisateur mal intentionné, dans le cas par exemple où le montant du produit ou du service requis est élevé. Le fait aussi que l’utilisateur contacte un fournisseur de la liste a
l’inconvénient de divulguer à ce dernier des données personnelles de l’utilisateur (ex : nom ou numéro de téléphone de l’utilisateur qui s’affiche sur le terminal de communication du fournisseur), alors que la commande du produit ou du service n’a même pas encore été finalisée. Afin de simplifier ce type de procédé de commande et d’obtenir une liste de fournisseurs plus ciblée par rapport aux critères de recherche saisis par l’utilisateur, certains sites de vente en ligne proposent maintenant à l’utilisateur de filtrer les résultats d’une recherche de produit ou de service que l’utilisateur souhaite
commander, en se basant sur la localisation d’un terminal de communication de l’utilisateur. Un tel filtrage permet certes de réduire la liste des fournisseurs potentiels du produit ou du service. Toutefois, l’utilisateur est toujours obligé de contacter un à un les fournisseurs de la liste et la divulgation des données personnelles de l’utilisateur, comme celles des fournisseurs, n’est toujours pas préservée.
Objet et résumé de l'invention
Un des buts de l'invention est de remédier à des inconvénients de l'état de la technique précité.
A cet effet, un objet de la présente invention concerne un procédé de commande d’un produit ou d’un service au moyen d’un terminal de communication associé à un identifiant de communication.
Un tel procédé est remarquable en ce qu’il comprend ce qui suit, au niveau du terminal :
- envoyer à un serveur une requête de commande du produit ou du service, ladite requête contenant des informations relatives au produit ou au service,
- établir en arrière-plan une communication vers N terminaux associés
respectivement à N identifiants de communication (N>1 ), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de
communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1 <K< N, l’offre ayant été générée durant la communication et sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête, - commander la restitution de l’offre, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution.
Un tel procédé de commande de produit ou de service est particulièrement simple et rapide à mettre en oeuvre pour l’utilisateur, puisque celui-ci se contente juste d’envoyer une requête à un serveur à l’aide de son terminal pour spécifier les informations relatives au produit ou au service qu’il souhaite commander.
De manière avantageuse, l’utilisateur n’a en outre pas besoin de contacter un par un les N fournisseurs du produit ou du service qu’il souhaite obtenir, de tels contacts étant exécutés en arrière-plan ou en tâche de fond à l’initiative du terminal de l’utilisateur. Il en résulte que le procédé de commande de produit ou de service est plus facile à utiliser et est exécuté beaucoup plus rapidement que dans l’art antérieur.
Un autre avantage d’un tel procédé est qu’il préserve la confidentialité des données personnelles aussi bien du côté du terminal ayant requis l’offre de produit ou de service, que du côté des N terminaux de fournisseurs de produit ou de service qui ont été identifiés.
Selon un mode de réalisation particulier, le procédé comprend ce qui suit, en cas d’acceptation de l’offre :
- envoyer des données d’identification de l’utilisateur du terminal audit au moins un terminal de fournisseur,
- recevoir des données d’identification de l’utilisateur dudit au moins un terminal de fournisseur.
Grâce à un tel mode de réalisation, l’anonymat de l’utilisateur du terminal de communication et l’anonymat du fournisseur du produit ou du service dont l’offre a été acceptée sont levés seulement une fois que l’offre a été acceptée par l’utilisateur du terminal.
Selon un autre mode de réalisation particulier, le procédé comprend ce qui suit, en cas de refus de l’offre :
- poursuivre la communication, au cours de laquelle les actions de recevoir une offre et de commander la restitution de l’offre reçue sont itérées, tant qu’une offre n’est pas acceptée. Un tel mode de réalisation permet de proposer à l’utilisateur du terminal et même si ce dernier a décliné l’offre optimale, une ou plusieurs autre(s) offres de produit ou de service qui correspondent à ses critères de recherche, sans que l’utilisateur n’ait besoin de contacter de sa propre initiative les différents fournisseurs de produit ou de service. En outre, les identités des fournisseurs n’étant pas connues de l’utilisateur, un tel mode de réalisation permet de protéger les fournisseurs, en particulier dans le cas où les informations contenues dans la requête sont sensibles, telles que par exemple un montant élevé du produit ou du service requis, un objet rare, etc....
Selon un autre mode de réalisation particulier, au cours de la communication, le terminal reçoit, en provenance de respectivement N-K terminaux de fournisseur de produit ou de service identifiés par le serveur, N-K refus de fournir le produit ou le service correspondant à la requête.
Un tel mode de réalisation permet avantageusement pour l’utilisateur du terminal qui a envoyé la requête de commande du produit ou du service, de ne recevoir que les offres des K fournisseurs restants, intéressés par le produit ou le service commandé. Il en ressort une diminution des échanges qui seront susceptibles d’avoir lieu au cours de la communication entre le terminal de l’utilisateur et les K terminaux de fournisseur restants, ce qui entraîne une limitation de l’encombrement du réseau de communication entre le terminal de l’utilisateur et les terminaux de fournisseur.
Compte tenu du fait que la communication est établie en arrière-plan et que l’identité des fournisseurs et de leurs terminaux de communication correspondants n’est pas connue de l’utilisateur, il n’est avantageusement pas possible pour l’utilisateur d’identifier les N-K fournisseurs ayant refusé de fournir le produit ou le service correspondant à la requête.
Selon un autre mode de réalisation particulier, l’offre de produit ou de service reçue au cours de la communication est générée en tenant compte d’au moins une variable d’ajustement de :
- tout ou partie des informations contenues dans la requête, et/ou
- une donnée de localisation du terminal de communication, et/ou
- une donnée temporelle associée à la requête.
L’avantage d’un tel mode de réalisation est que l’utilisateur du terminal reçoit au moins une offre de produit ou de service, même si cette dernière ne correspond pas exactement aux informations relatives au produit ou service mentionnées dans la requête et/ou à la localisation du terminal et/ou à la date/instant à laquelle a été envoyée la requête et/ou à des informations temporelles indiquées dans la requête. Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de commande de produit ou de service défini ci-dessus.
L'invention concerne également un terminal de communication pour commander un produit ou un service, ledit terminal de communication étant associé à un identifiant de communication.
Un tel terminal est remarquable en ce qu’il comprend un processeur qui est configuré pour mettre en oeuvre ce qui suit :
- envoyer à un serveur une requête de commande du produit ou du service, ladite requête contenant des informations relatives au produit ou au service,
- établir en arrière-plan une communication vers N terminaux associés
respectivement à N identifiants de communication (N>1 ), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service, en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de
communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir une offre du produit ou du service en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1 <K< N, l’offre ayant été générée durant la communication et sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête,
- commander la restitution de l’offre sur une interface de restitution, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution.
Un tel terminal de communication est notamment apte à mettre en oeuvre le procédé de commande de produit ou de service précité.
L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de commande de produit ou de service selon l'invention, selon l’un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur.
De telles instructions peuvent être stockées durablement dans un support mémoire non transitoire du terminal de communication.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise également un support d’enregistrement ou support d’informations lisible par un ordinateur, et comportant des instructions d’un programme d’ordinateur tel que mentionné ci-dessus.
Le support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de commande de produit ou de service précité.
Brève description des dessins
D'autres caractéristiques et avantages apparaîtront à la lecture de modes de réalisation particuliers de l'invention, donnés à titre d’exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
[Fig. 1 ] la figure 1 est une vue schématique et générale d’une architecture dans laquelle est mis en oeuvre le procédé de commande de produit ou de service, dans un mode de réalisation particulier de l’invention,
[Fig. 2] la figure 2 représente un terminal de communication pour commander un produit ou un service, dans un mode de réalisation particulier de l’invention, [Fig. 3] la figure 3 représente les principales actions mises en oeuvre dans le procédé de commande de produit ou de service selon un mode de réalisation particulier de l’invention.
Description détaillé d’un mode de réalisation de l’invention
Environnement architectural
La figure 1 représente un environnement dans lequel est mis en oeuvre le procédé de commande de produit ou de service selon l’invention.
Sur la figure 1 sont représentés :
- un terminal de communication TERu d’un utilisateur UT souhaitant commander un produit ou un service,
- N terminaux de communication TERf-i, TERf2,..., TERfN appartenant
respectivement à N fournisseurs f-i, f2, ..., ÎN de produit ou de service,
- un serveur SER de mise en relation du terminal TERu avec chacun des terminaux de communication TERf-i, TERf2,..., TERfN de fournisseurs.
Le terminal TERu, les terminaux TERf-i, TERf2,..., TERfN et le serveur SER
communiquent entre eux via un réseau de communication RC. Il peut s’agir par exemple d’un réseau de type IP (abréviation anglaise de « Internet Protocol »), d’un réseau de type x-DSL, fibre ou encore 3G, 4G, 5G, etc.
A titre d’exemples non exhaustifs, le terminal TERu et les terminaux TERf-i, TERf2,..., TERfN sont :
- un téléphone portable, et/ou
- un smartphone (« téléphone intelligent »), et/ou
- une tablette, et/ou
- un ordinateur portable, et/ou
- un ordinateur personnel de type PC, et/ou
- etc....
Le terminal TERu est classiquement associé à un identifiant de communication ICu, tel que par exemple le numéro de téléphone mobile, le numéro de ligne fixe, l’adresse IP ou bien l’adresse email permanente de l’utilisateur UT, un tel identifiant lui ayant été attribué par un ou plusieurs opérateurs de télécommunications au(x)quel(s) l’utilisateur UT est abonné ou bien encore par un ou plusieurs
fournisseurs de service de télécommunications auprès duquel/desquels l’utilisateur UT a créé un compte. Pour un terminal de fournisseur TERf, (1 <i£N) considéré parmi N, le terminal TERf, est classiquement associé à un identifiant de communication ICf,, tel que par exemple le numéro de téléphone mobile, le numéro de ligne fixe, l’adresse IP ou bien l’adresse email permanente du fournisseur f,, un tel identifiant lui ayant été attribué par un ou plusieurs opérateurs de télécommunications au(x)quel(s) le fournisseur f, est abonné ou bien encore par un ou plusieurs fournisseurs de service de
télécommunications auprès duquel/desquels le fournisseur f, a créé un compte.
Le terminal TERu comprend une application logicielle (ou programme applicatif) APu qui est dédiée à la mise en oeuvre du procédé de commande de produit ou de service conformément à la présente invention. L’application APu est téléchargée dans le terminal TERu, en amont de l’exécution du procédé de commande de produit ou de service.
Les terminaux de fournisseur TERf-i, TERf2,..., TERfN comprennent également chacun une application logicielle (ou programme applicatif) correspondante APf-i, APf2,..., APfisi qui est apte à dialoguer avec l’application APU lors de la mise en oeuvre du procédé de commande de produit ou de service conformément à la présente invention. Les applications APf-i, APf2,..., APfN sont respectivement téléchargées dans les terminaux de fournisseurs TERf-i, TERf2,..., TERfN, en amont de l’exécution du procédé de commande de produit ou de service.
Le serveur SER stocke dans une mémoire ou une base de données :
- un identifiant de communication virtuel IVu attribué à l’utilisateur UT, un tel identifiant étant associé à l’identifiant de communication ICu du terminal TERu,
- des identifiants de communication virtuels IVf-i, IVf2,..., IVfN relatifs respectivement aux fournisseurs fi, f2,..., ÎN, de tels identifiants étant associés respectivement aux identifiants de communication ICf-i, ICf2,..., ICfN.
Un identifiant de communication virtuel est par exemple une suite de caractères numériques ou alphanumériques générée par exemple de manière aléatoire.
L’identifiant virtuel de l’utilisateur UT (respectivement d’un fournisseur f, considéré parmi N) est destiné à circuler dans le réseau de communication RC à la place de l’identifiant de communication ICu (respectivement de l’identifiant de communication ICfj) de façon à préserver l’anonymat de l’utilisateur UT (respectivement du fournisseur f, de produit ou de service). Description d’un mode de réalisation du terminal de communication TERu
La figure 2 présente la structure simplifiée du terminal de communication TERu adapté pour mettre en oeuvre le procédé de commande de produit ou de service qui va être décrit ci-dessous.
De façon connue en soi, le terminal de communication TERu comprend :
- une interface de connexion IC qui est adaptée pour communiquer, via le réseau de communication RC, selon par exemple le protocole http (abréviation anglaise de
« HyperText Transfer Protocol »), avec le serveur SER de la figure 1 ,
- un écran de visualisation EC,
- un haut-parleur HP,
- un microphone MIC.
Selon l’invention, le terminal TERu stocke dans une mémoire MEM1 l’application APu dédiée à l’exécution du procédé de commande de produit ou de service selon l’invention.
Selon un mode particulier de réalisation de l'invention, les actions exécutées par le procédé de commande de produit ou de service sont mises en oeuvre par des instructions d’un programme d'ordinateur PG. Pour cela, le terminal TERu a l'architecture classique d'un ordinateur et comprend notamment une mémoire MEM2, une unité de traitement UTR, équipée par exemple d'un processeur PROC, et pilotée par le programme d'ordinateur PG stocké en mémoire MEM2. Le programme d'ordinateur PG comprend des instructions pour mettre en oeuvre les actions du procédé de commande de produit ou de service qui va être décrit ci-dessous, lorsque le programme est exécuté par le processeur PROC, selon l'un quelconque des modes particuliers de réalisation de l'invention.
A l'initialisation, les instructions de code du programme d'ordinateur PG sont par exemple chargées dans une mémoire RAM (non représentée) avant d'être exécutées par le processeur PROC. Le processeur PROC de l'unité de traitement UTR met notamment en oeuvre les actions du procédé de commande de produit ou de service, selon les instructions du programme d'ordinateur PG. Description d’un mode de réalisation du procédé de commande de produit ou de service
En référence à la figure 3, on décrit maintenant le déroulement d’un procédé de commande de produit ou de service selon un mode de réalisation de l’invention. Selon un premier exemple de réalisation, l’utilisateur UT souhaite, dans le cadre d’un service de porte-monnaie électronique, effectuer un retrait d’espèces à l’aide de son terminal TERu, dans un commerce partenaire.
Selon un deuxième exemple de réalisation, l’utilisateur souhaite acheter une voiture de marque X, de modèle Y et de couleur Z.
En S1 , l’utilisateur UT ouvre l’application APu et saisit, via une interface utilisateur générée par l’application APu, des informations relatives au produit ou au service que l’utilisateur souhaite commander. Une telle interface utilisateur peut être vocale et restituée via le haut-parleur HP de la figure 2 ou bien encore textuelle et restituée sur l’écran EC de la figure 2.
Dans le cas du premier exemple de réalisation, les informations relatives au produit ou au service comprennent le montant que l’utilisateur UT souhaite retirer, soit t euros.
Dans le cas du deuxième exemple de réalisation, les informations relatives au produit ou au service comprennent le type de produit : « voiture », le prix, la marque X, le modèle Y, la couleur Z de la voiture souhaitée. Bien entendu, de telles informations pourraient être limitées au mot « voiture » ou à une combinaison du mot « voiture » avec l’une et/ou l’autre des rubriques « prix », marque X, modèle Y, couleur Z.
Les informations relatives au produit ou au service peuvent également comprendre :
- une donnée de localisation du terminal TERu, telle que par exemple les
coordonnées GPS (abréviation anglaise de « Global Positioning System ») du terminal TERu ; et/ou
- une ou plusieurs données temporelles associées à la requête, telles que:
- une ou plusieurs données temporelles relatives à la saisie, par exemple la date de la saisie, l’instant de la saisie en heure, minute(s), seconde(s),
- une ou plusieurs données temporelles relatives à l’envoi de la requête, telles que par exemple des données d’horodatage, - une ou plusieurs données temporelles relatives à la fourniture du produit ou du service souhaité, telles que par exemple un jour de la semaine ou du mois en cours, une plage horaire dans la journée, 9h30-12h30, par exemple.
De manière optionnelle, les informations relatives au produit ou au service requis comprennent en outre une ou plusieurs variables d’ajustement :
- de tout ou partie des informations contenues dans la requête, et/ou
- d’une donnée de localisation du terminal de communication, et/ou
- d’au moins une des données temporelles associées à la requête précitées.
Si par exemple, une information contenue dans la requête est un prix du produit ou du service, une variable d’ajustement consiste par exemple en une plage de tolérance sur ce prix, par exemple plus ou moins 5%, 10%, etc...
Si par exemple, une information contenue dans la requête est une donnée de localisation, telle qu’une distance de j kilomètres autour du terminal de
communication, une variable d’ajustement consiste par exemple en une plage de tolérance sur cette distance, par exemple j plus ou moins 500 m, 1 km, etc...
Si par exemple, une information contenue dans la requête est au moins une donnée temporelle, une variable d’ajustement consiste par exemple en une variation d’une plage horaire mentionnée initialement dans la requête ou encore une durée de validité de la commande du produit ou du service souhaité, par exemple 1 jour, 2 jours, 1 semaine, etc...
En S2, une requête de commande de produit ou de service contenant les
informations saisies est envoyée, via le réseau RC de la figure 1 , au serveur SER, au moyen de l’application APu. Un tel envoi peut être mis en oeuvre au moyen d’une touche générée par l’interface utilisateur de l’application APu et restituée sur l’écran EC ou au moyen d’une commande vocale générée par l’interface utilisateur de l’application APu et restituée par le haut-parleur HP. La requête envoyée est conforme par exemple au protocole http ou https.
En S3, le serveur SER reçoit la requête. Il identifie alors les N fournisseurs f-i , f2, - - - , ÎN comme étant aptes à fournir le produit ou le service demandé. Une telle identification est mise en oeuvre à l’aide d’un mécanisme d’analyse de données qui utilise tout ou partie des informations relatives au produit ou au service contenues dans la requête envoyée en S2 et qui calcule une probabilité selon laquelle les N fournisseurs f-i, f2, - - -, ÎN sont aptes à fournir le produit ou le service requis. La probabilité est éventuellement calculée sur la base d’un historique local accessible par le serveur SER.
Dans le cas du premier exemple de réalisation, le serveur SER estime ainsi à partir des transactions déjà effectuées par les fournisseurs fi, f2, ..., fN et stockées dans un historique local, qu’ils sont capables de fournir le montant de t euros demandé par l’utilisateur UT.
Dans le cas du deuxième exemple de réalisation, le serveur SER est en mesure d’évaluer à partir de l’historique local, que telle voiture requise par l’utilisateur UT est en stock chez l’ensemble des fournisseurs f-i, f2,..., ÎN-
Une telle identification permet d’obtenir de façon complètement transparente pour l’utilisateur UT, et de manière dynamique et ciblée, une liste de fournisseurs pour lesquels il existe une forte probabilité qu’ils puissent répondre favorablement à la requête de commande de produit ou de service envoyée en S2.
En S4, le serveur SER envoie à l’application APu une réponse à la requête reçue. Une telle réponse contient les identifiant virtuels IVf-i, IVf2,..., IVfN relatifs
respectivement aux fournisseurs fi, f2, ..., ÎN-
De manière optionnelle, les identifiants virtuels IVf-i , IVf2, ..., IVfN envoyés en S4 sont associés respectivement aux probabilités calculées par le serveur SER, selon lesquelles les N fournisseurs f-i , f2, ..., ÎN sont aptes à fournir le produit ou le service requis.
En S5, l’application APu reçoit la réponse.
En S6, une requête en demande de communication avec les terminaux de fournisseur TERf-i, TERf2,..., TERfN est alors envoyée en arrière-plan par
l’application APu au serveur SER, ladite requête contenant l’identifiant virtuel IVu du terminal TERu et les identifiant virtuels IVf-i, IVf2,..., IVfN relatifs respectivement aux fournisseurs , , · · · , fi\i·
En S7, le serveur SER reçoit la requête et crée alors un canal d’échange anonymisé pour la mise en relation en mode pair à pair de l’application APu du terminal TERu avec chacune des applications APf-i, APf2, ..., APfN des terminaux de fournisseur TERf-i , TERf2, ..„ TERfN.
En S8, le serveur SER envoie une demande de mise en relation à chacune des applications APu et APf-i, APf2,..., APfN. En S9, la communication entre l’application APu et chacune des applications APf-i, APf2,..., APfN est alors établie, après validation auprès du serveur SER, par les applications APu et APf1 ; APf2,..., APfN, de la demande de mise en relation. La communication est établie par exemple au moyen d’un protocole de communication bidirectionnel synchrone ou asynchrone, tel que par exemple du type WebSocket, http, etc.
De façon particulièrement avantageuse, la communication est mise en oeuvre en arrière-plan, donc de façon transparente pour l’utilisateur UT. Par ailleurs, les identifiants de communication publics précités ICu et ICf-i, ICf2,..., ICÎN sont masqués durant la communication puisqu’ils sont remplacés par respectivement les identifiants virtuels précités IVu, IVf-i, IVf2,..., IVfN.
En S10, l’application APu envoie en arrière-plan, à chacune des applications APf1 ; APf2,..., APfN, la requête précédemment envoyée en S2. Ladite requête peut contenir, en plus des informations déjà mentionnées en relation avec l’opération S2 ci-dessus, une ou plusieurs variables d’ajustement :
- de tout ou partie des informations contenues dans la requête, et/ou
- d’une donnée de localisation du terminal de communication, et/ou
- d’une donnée temporelle associée à la requête, telle que par exemple la date de la saisie, l’instant de la saisie en heure, minute(s), seconde(s), un jour de la semaine ou du mois en cours, une plage horaire dans la journée, 9h30-12h30, par exemple.
Dans le cas du premier exemple de réalisation précité, la variable d’ajustement peut par exemple consister en une tolérance de plus ou moins 5% du montant de t euros demandé.
Dans le cas du deuxième exemple de réalisation précité, la variable d’ajustement peut par exemple consister en une tolérance sur la couleur Z initialement saisie. Chacun des terminaux de fournisseurs TERf-i, TERf2,..., TERfN estime alors en local s’il est en mesure, à l’instant où il reçoit la requête envoyée en S10, si les
fournisseurs f-i, f2,..., fN identifiés sont aptes à répondre favorablement à la requête, en fonction de tout ou partie des informations contenues dans cette requête, des variables d’ajustement contenues dans cette requête et/ou éventuellement de variables d’ajustement échangées lors de ladite communication entre l’application APu et chacune des applications APf-i, APf2,..., APfN et/ou des éventuelles variables d’ajustement déjà acceptées par les fournisseurs de service. Une telle estimation est établie par calcul de probabilités considérant en entrée les informations contenues dans cette requête et les variables d’ajustement précitées.
Selon le premier exemple de réalisation précité, l’estimation est basée par exemple :
- uniquement sur le montant de t euros mentionné dans la requête envoyée en S10,
- sur le montant de t euros et sur une donnée de localisation du terminal TERu, telle que par exemple un rayon de j kilomètres autour du terminal TERu ;
- sur le montant de t euros, et/ou sur une donnée de localisation du terminal TERu, telle que par exemple un rayon de j kilomètres autour du terminal TERu et/ou une variable d’ajustement de plus ou moins 5% du montant de t euros.
Selon le deuxième exemple de réalisation précité, l’estimation est basée par exemple :
- uniquement sur le type de produit : « voiture », le prix, la marque X, le modèle Y, la couleur Z de la voiture souhaitée ;
- sur le type de produit : « voiture », le prix, la marque X, le modèle Y, la couleur Z de la voiture souhaitée et/ou sur une donnée de localisation du terminal TERu, telle que par exemple un rayon de j kilomètres autour du terminal TERu et/ou une variable d’ajustement sur, par exemple, la couleur Z. Si la couleur Z est par exemple bleue, l’estimation est calculée en prenant en compte une autre couleur, par exemple la couleur grise et/ou la couleur noire.
A l’issue de cette estimation, N-K fournisseurs, tel que K£N, peuvent abandonner la communication parce que soit ils ne disposent pas du produit souhaité, soit ils ne peuvent pas rendre le service souhaité, dans les conditions acceptées par ces fournisseurs au regard des conditions souhaitées par l’utilisateur UT. A cet effet, l’application APu reçoit (non représenté sur la figure 3) N-K messages de refus de fournir le produit ou le service souhaité en provenance des N-K applications correspondantes des N-K terminaux de fournisseur K+1 ,..., N.
En S1 1 , K applications APf-i, APf2,..., APfK envoient chacune une réponse à l’application APu, chaque réponse contenant les conditions de l’offre que peut proposer le fournisseur correspondant f-i, f2,..., f« et qui sont basées sur le calcul de l’estimation ci-dessus.
En S12, l’application APu reçoit en arrière-plan chacune des K réponses contenant respectivement K offres du produit ou du service requis. En S13, est alors mise en oeuvre en arrière-plan une phase de négociation entre l’application APu et chacune des K applications APf-i, APf2,..., APfK, de manière à sélectionner au moins une offre de produit ou de service optimale. Cette offre est sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête envoyée en S10 et, d’autre part, au moins une donnée de localisation du terminal de communication TERu, telle que décrite plus haut, et/ou au moins une donnée temporelle associée à la requête envoyée en S10, dont des exemples ont déjà été décrits plus haut, et/ou encore au moins une variable d’ajustement telle que décrite plus haut. Au cours de la négociation, pour chaque offre envoyée à l’application APu par une application APf, considérée parmi K, l’application APu répond à l’offre en renvoyant à l’application APf, considérée, soit un message de refus, soit un message d’acceptation. Cet échange est itéré pour 1 <i£K. L’offre optimale est par exemple celle envoyée par l’application APf, du terminal de fournisseur TERf,.
Toutes les offres auxquelles a répondu favorablement l’application APu peuvent être classées dans l’ordre allant de l’offre optimale à l’offre la moins optimale.
En S14, l’application APu reçoit en arrière-plan l’offre de produit ou de service optimale.
En S15, il est procédé à la commande de la restitution de l’offre optimale sur, par exemple, une interface de restitution du terminal TERu, telle que par exemple l’écran EC ou le haut-parleur HP de la figure 2. Selon un exemple de réalisation, une icône représentant de façon anonyme le fournisseur f, est affichée sur une carte de l’endroit où est situé le fournisseur f,, ce qui permet à l’utilisateur UT de situer grossièrement la localisation du fournisseur f,. De manière particulièrement avantageuse, aucune information personnelle sur le fournisseur f,, qu’il s’agisse de son nom, de son adresse, de l’identifiant de communication ICf, du terminal de fournisseur TERf,, etc... n’est affichée sur l’écran EC. Selon un autre exemple, une phrase du type : « le fournisseur f, est à 5km de chez vous au nord-ouest » est énoncée via le haut-parleur HP. Une telle phrase ne divulgue aucune information personnelle sur le fournisseur f,, qu’il s’agisse de son nom, de son adresse, de l’identifiant de communication ICf, du terminal de fournisseur TERf,, etc..
En S16, si l’utilisateur UT valide l’offre (« O » sur la figure 3), par exemple en appuyant sur une touche dédiée de l’écran EC ou en disant « OK » via le microphone MIC de la figure 2, un contrat de l’offre du produit ou service souhaité est généré par l’application APu selon des paramètres préprogrammés, un tel contrat étant considéré comme signé par l’utilisateur UT, mais ne comprenant à ce stade aucune données personnelles relatives à l’utilisateur UT.
En S17, le contrat signé par l’utilisateur UT est envoyé en arrière-plan par
l’application APu à l’application APf,.
Le terminal TERf, reçoit le contrat, et s’il est validé par le fournisseur f, selon les mêmes principes que ceux mis en oeuvre pour l’utilisateur UT, la génération d’une signature de contrat par le fournisseur f, est déclenchée via l’application APf,. A ce stade, le contrat ne comprend pas non plus de données personnelles relatives au fournisseur f,.
En S18, le contrat signé par le fournisseur f, est envoyé en arrière-plan par
l’application APf, à l’application APu.
En S19, le terminal TERu reçoit le contrat signé par le fournisseur f,.
En S20, des données personnelles relatives à l’utilisateur UT sont envoyées en arrière-plan au terminal TERf, selon une configuration prédéfinie. A l’issue de cet envoi, et selon cette configuration prédéfinie, les données personnelles de
l’utilisateur UT sont restituées en S21 sur le terminal TERf,, de manière textuelle ou vocale. Il peut s’agir par exemple du nom et de l’adresse de messagerie électronique de l’utilisateur UT. En S20, le terminal TERu reçoit également en arrière-plan, en provenance du terminal TERf,, et selon une configuration prédéfinie, des données personnelles relatives au fournisseur f,. Selon cette configuration prédéfinie, il peut s’agir par exemple du nom, d’une adresse de messagerie électronique du
fournisseur f,, ainsi que l’adresse de visite de ce dernier. Selon cette configuration prédéfinie, les données personnelles du fournisseur f, qui ont été reçues sont restituées en S21 sur le terminal TERu, de manière textuelle, par exemple sur l’écran EC du terminal TERu, ou bien de manière vocale, au moyen du haut-parleur HP du terminal TERu.
Si en S16, l’utilisateur UT ne valide pas l’offre (« N » sur la figure 3), par exemple en appuyant sur une touche dédiée de l’écran EC ou en disant « NON OK » via le microphone MIC, le procédé de commande retourne à l’opération S13 en vue de sélectionner l’une des offres restantes parmi K-1. La sélection est mise en oeuvre par itération dans l’ordre selon lequel les offres ont été triées, une itération étant effectuée tant qu’une nouvelle offre optimale n’est pas sélectionnée. Si aucune des offres n’est acceptée par l’utilisateur UT, selon un exemple de réalisation, la mise en relation établie en S13 prend fin. Le procédé de commande revient alors à l’opération de saisie S1 , où l’utilisateur UT est invité à saisir des informations complémentaires de celles saisies initialement en S1. Puis les opérations S2 et suivantes sont réitérées. Selon un autre exemple de réalisation, la mise en relation établie en S13 demeure, et le procédé de commande repasse en S10 où sont appliquées des variables d’ajustement préconfigurées sur :
- tout ou partie des informations contenues dans la requête, et/ou
- une donnée de localisation du terminal de communication, et/ou
- une donnée temporelle associée à la requête.
Il va de soi que les modes de réalisation qui ont été décrits ci-dessus ont été donnés à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art, sans pour autant sortir du cadre de l’invention. D’autres applications de l’invention sont également possibles, telles que par exemple un système d’enchères électroniques ou encore un système de paiement via une application mobile téléchargée sur un terminal de
télécommunications.

Claims

REVENDICATIONS
1. Procédé de communication sécurisée adapté pour commander un produit ou un service au moyen d’un terminal de communication (TERu) associé à un identifiant de communication (ICu), comprenant ce qui suit, au niveau du terminal :
- envoyer (S2, S10) à un serveur (SER), via un réseau de communication (RC), une requête contenant des informations relatives à un produit ou à un service,
- établir (S9) en arrière-plan une communication vers N terminaux associés respectivement à N identifiants de communication (N>1 ) (ICf-i, ICf2, - - - , ON), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir (S14), en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1 <K< N, une offre d’un produit ou d’un service correspondant auxdites informations, l’offre ayant été générée durant la communication.
2. Procédé de communication sécurisée selon la revendication 1 , comprenant en outre :
- commander (S15) la restitution de l’offre sur une interface du terminal, l’identifiant de communication dudit au moins un terminal de fournisseur ainsi que l’identification du fournisseur dudit au moins un terminal de fournisseur étant masqués lors de la restitution.
3. Procédé de communication sécurisée selon la revendication 1 ou la revendication 2, dans lequel en cas d’acceptation de l’offre :
- envoyer (S20) des données d’identification de l’utilisateur du terminal audit au moins un terminal de fournisseur,
- recevoir (S20) des données d’identification de l’utilisateur dudit au moins un terminal de fournisseur.
4. Procédé de communication sécurisée selon la revendication 1 ou la revendication 2, dans lequel en cas de refus de l’offre, poursuivre la communication (S10 ; S13), au cours de laquelle les actions de recevoir une offre et de commander la restitution de l’offre reçue sont itérées, tant qu’une offre n’est pas acceptée.
5. Procédé de communication sécurisée selon l’une quelconque des revendications 1 à 4, dans lequel l’offre générée est sélectionnée comme optimisant un compromis entre, d’une part, tout ou partie des informations contenues dans la requête et, d’autre part, une donnée de localisation du terminal de communication et/ou une donnée temporelle associée à la requête.
6. Procédé de communication sécurisée selon l’une quelconque des revendications 1 à 5, dans lequel, au cours de la communication, le terminal reçoit, en provenance de respectivement N-K terminaux de fournisseur de produit ou de service identifiés par le serveur, N-K refus de fournir le produit ou le service correspondant à la requête.
7. Procédé de communication sécurisée selon l’une quelconque des revendications 1 à 6, dans lequel l’offre de produit ou de service reçue au cours de la communication est générée en tenant compte d’au moins une variable d’ajustement de :
- tout ou partie des informations contenues dans la requête, et/ou
- une donnée de localisation du terminal de communication, et/ou
- une donnée temporelle associée à la requête.
8. Terminal de communication sécurisée (TERu) adapté pour commander un produit ou un service, ledit terminal de communication étant associé à un identifiant de communication (ICu) et comprenant un processeur (PROC) qui est configuré pour mettre en oeuvre ce qui suit :
- envoyer à un serveur, via un réseau de communication (RC), une requête contenant des informations relatives à un produit ou à un service,
- établir en arrière-plan une communication vers N terminaux associés respectivement à N identifiants de communication (N>1 ), les N terminaux étant des terminaux de fournisseurs identifiés par le serveur comme étant aptes à fournir le produit ou le service en fonction de tout ou partie des informations contenues dans la requête, ladite communication étant établie en masquant l’identifiant de communication du terminal et les N identifiants de communication,
- au cours de la communication, recevoir en provenance d’au moins un terminal de fournisseur parmi au moins K, tel que 1 <K< N, une offre d’un produit ou d’un service correspondant auxdites informations, l’offre ayant été générée durant la communication.
9. Programme d'ordinateur comportant des instructions de code de programme pour la mise en oeuvre du procédé de commande selon l’une quelconque des revendications 1 à 7, lorsqu'il est exécuté sur un ordinateur.
10. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 9.
EP20732257.9A 2019-04-01 2020-03-20 Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication Pending EP3948752A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1903440A FR3094539A1 (fr) 2019-04-01 2019-04-01 Procédé de commande anonymisé d’un produit ou d’un service à l’aide d’un terminal de communication
PCT/FR2020/050610 WO2020201663A1 (fr) 2019-04-01 2020-03-20 Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication

Publications (1)

Publication Number Publication Date
EP3948752A1 true EP3948752A1 (fr) 2022-02-09

Family

ID=68072538

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20732257.9A Pending EP3948752A1 (fr) 2019-04-01 2020-03-20 Procédé de communication sécurisée adapté pour commander un produit ou un service à l'aide d'un terminal de communication

Country Status (4)

Country Link
US (1) US20220180403A1 (fr)
EP (1) EP3948752A1 (fr)
FR (1) FR3094539A1 (fr)
WO (1) WO2020201663A1 (fr)

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0001882D0 (en) * 2000-01-28 2000-03-22 Beca Limited Raw cotton trading web
EP1345396A1 (fr) * 2001-08-14 2003-09-17 Siemens Aktiengesellschaft Rendre disponible d'un chiffre pour une annonce
AUPR969501A0 (en) * 2001-12-20 2002-01-24 Global Trade Finance Network Pte Ltd Forfaiting transactions
US20070203821A1 (en) * 2006-02-24 2007-08-30 Dufour Remi Computer system, method and software capable of listing identified goods in transit or storage and managing buyer and seller communications regarding such goods
US20070226152A1 (en) * 2006-03-21 2007-09-27 Austin Jones System and method for anonymous transactions and conveyances
WO2008046059A2 (fr) * 2006-10-12 2008-04-17 Shapiro Peter A ProcÉDÉ et systÈme de rÉalisation d'achats anonymes en ligne
US7797202B1 (en) * 2007-02-20 2010-09-14 Asian Atlantic Industries, Inc. Method of masking the identities of both a bidder and seller in an auction
US20110060730A1 (en) * 2008-05-06 2011-03-10 Rejean Desrosiers Reverse portal system and method
US8438072B2 (en) * 2009-02-20 2013-05-07 Consumercartel, Llc Online exchange system and method with reverse auction
FR2945364B1 (fr) * 2009-05-06 2016-07-29 Goodkap Procede de mise en relation a l'usage de voyageurs, module et systeme associes
US20110302096A1 (en) * 2010-06-02 2011-12-08 Apple Inc. Authentication service for sales of goods and services
US20120005102A1 (en) * 2010-07-02 2012-01-05 Mcclung Robert Thomas Method and System for Anonymous Communication Between A Consumer and Provider
US10074146B2 (en) * 2010-08-26 2018-09-11 Adam Selsby Buyer driven market system and method
FR2972826A1 (fr) * 2011-03-14 2012-09-21 France Telecom Traitement de donnees pour la gestion d'offres et de demandes de trajets de covoiturage.
US20140108067A1 (en) * 2012-10-11 2014-04-17 Getgoing, Inc. Using qualification events to provide price differentiation for travel products
US10713698B2 (en) * 2014-01-27 2020-07-14 Ushur, Inc. Instant generation and usage of HTTP URL based unique identity for engaging in multi-modal real-time interactions in online marketplaces, social networks and other relevant places
US20170109814A1 (en) * 2015-10-19 2017-04-20 Wesley John Boudville Linket to control mobile deep links

Also Published As

Publication number Publication date
WO2020201663A1 (fr) 2020-10-08
US20220180403A1 (en) 2022-06-09
FR3094539A1 (fr) 2020-10-02

Similar Documents

Publication Publication Date Title
EP3243176B1 (fr) Procédé de traitement d&#39;une transaction à partir d&#39;un terminal de communication
FR2837953A1 (fr) Systeme d&#39;echange de donnees
EP1269360A1 (fr) Procede permettant a un adjudicateur de faire parvenir un appel d&#39;offre a un ou plusieurs prestataires selectionnes
EP1314143B1 (fr) Dispositif et procede de sauvegarde d&#39;information de transaction en ligne
EP1326401A1 (fr) Procédé de contrôle d&#39;accès à un contenu et système pour le contrôle d&#39;accès à un contenu
EP3948752A1 (fr) Procédé de communication sécurisée adapté pour commander un produit ou un service à l&#39;aide d&#39;un terminal de communication
FR2863811A1 (fr) Systeme de communication entre un terminal mobile et un serveur de communication et les procedes de communications associes.
FR3062499A1 (fr) Procede de reduction de la taille d&#39;une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
EP2336967A1 (fr) Messagerie personnalisée sur encarts Web.
EP3928501A1 (fr) Procédé de gestion d&#39;accès d&#39;un utilisateur à un service vocal, dispositif, système et programmes correspondants
EP3035723B1 (fr) Procédé de transmission de données en relation avec une communication
FR3101497A1 (fr) Terminal, dispositif de personnalisation de requêtes de services et procédés permettant un service personnalisé.
EP3738061A1 (fr) Procédé de détermination d&#39;une association entre une carte bancaire et un terminal de communication, dispositif, système et programme correspondant
EP1208519B1 (fr) Systeme et procede de chargement de commandes dans une carte a circuit integre
EP2769528A1 (fr) Systeme de communication pour l&#39;affichage d&#39;annonces publicitaires
EP1865454A1 (fr) Procédé et système de gestion automatique et transparente de requetes utilisateurs sur un système de messagerie instantée via des contacts virtuels
FR3057085A1 (fr) Controle de delegation de droits
EP4099249A1 (fr) Procédé et dispositif de transmission d&#39;un identifiant d&#39;un utilisateur lors d&#39;un paiement électronique réalisépar l utilisateur
FR3143249A1 (fr) Procédé et dispositif d’obtention d’au moins une donnée associée à un contenu audiovisuel en cours de consultation par un utilisateur
EP4320534A1 (fr) Méthode de contrôle d&#39;accès à un bien ou service distribué par un réseau de communication de données
EP4154137A1 (fr) Procede et systeme d&#39;authentification d&#39;un utilisateur aupres d&#39;un serveur d&#39;authentification
WO2021053300A1 (fr) Procede de transmission d&#39;une information complementaire relative a une transaction financiere
FR3140184A1 (fr) Procédé et dispositif d’attribution d’un NFT
EP4294067A1 (fr) Gestion de l authentification d&#39;un terminal pour accéder à un service d&#39;un fournisseur de service
FR3003966A1 (fr) Procede d&#39;adaptation dynamique d&#39;un environnement logiciel execute a partir d&#39;un terminal de communication d&#39;un utilisateur, au cours d&#39;une communication entre l&#39;utilisateur et au moins un interlocuteur.

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211018

AK Designated contracting states

Kind code of ref document: A1

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

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20221021