EP4165889A1 - Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant - Google Patents

Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant

Info

Publication number
EP4165889A1
EP4165889A1 EP21737113.7A EP21737113A EP4165889A1 EP 4165889 A1 EP4165889 A1 EP 4165889A1 EP 21737113 A EP21737113 A EP 21737113A EP 4165889 A1 EP4165889 A1 EP 4165889A1
Authority
EP
European Patent Office
Prior art keywords
session
terminal
participating
access
requesting
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
EP21737113.7A
Other languages
German (de)
English (en)
Inventor
Richard Guignon
Sébastien Poivre
Nicolas Doisy
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 EP4165889A1 publication Critical patent/EP4165889A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1093—In-session procedures by adding participants; by removing participants
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822—Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147—Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Definitions

  • the invention relates to access to a secure communication session between participating communication terminals by a requesting access terminal.
  • secure communication session is meant in particular a secure shared digital space such as a conference call, a video conference, a virtual collaborative space, etc. which requires the use of access keys for each of the participating communication terminals.
  • This type of secure communication session requires the list of participants to be defined prior to the establishment of the communication session: for example user and / or participant user IDs. Thus, only the participants identified in the list will be authorized to establish and / or access the secure communication session.
  • provision can also be made for the establishment and / or access to the secure communication session to be further conditioned on the provision by the participating communication terminal wishing to establish and / or access the secure communication session of a key composed in particular of an access code (such as a digital code, an alphanumeric code, also called a password, a diagram, a code composed of a succession of images, etc. ) and / or biometric data ...
  • an access code such as a digital code, an alphanumeric code, also called a password, a diagram, a code composed of a succession of images, etc.
  • a participant may have forgotten or lost their access code. This can be problematic because the content (conversation, textual documents, audio and / or video, etc.) that the participant had to share during this secure communication session will then not be accessible by the other participants. And, when the secure communication session allows the generation of at least one final content, this final content will be erroneous because it will not be a function of the content of the participant who has not accessed the secure communication session but only of the content. shared by participants who accessed this session.
  • the list of participants may be incorrect: a person and / or a communication device having been omitted from the list.
  • the omitted person will not be authorized to access the secure communication session: he will therefore not be able to contribute to the session and if this generates final content, this final content will be incorrect.
  • a solution if such a person is aware of the communication session or has been notified by a participant of the communication session, would be for him to contact the person administering the list of participants and the latter to add them to this list. of participants in order to be able to access the secure communication session. But this process is laborious because first requires that the skipped person be aware of the scheduled secure communication session, then the skipped person knows the person administering the participant list and at least one way to contact them (phone number, email address, etc.), and that the person administering the list of participants be contacted by the omitted person before the secure communication session to integrate them into the list of participants. In addition, even in this case, there is still a risk of error that the omitted person is included in another list when the administrator manages several lists of participants in separate secure communication sessions.
  • One of the aims of the present invention is to remedy drawbacks with respect to the state of the art.
  • An object of the invention is a method of accessing a first secure communication session, called the first session, in progress between participating communication terminals, called participating terminals, by a requesting communication terminal, called requesting terminal, the method access comprising
  • the requesting terminal will easily access the first secure communication session even if the requesting terminal does not follow the secure access procedure (i.e. the requesting terminal is not a terminal from the list of participants authorized to access the first secure communication session, or the requesting terminal does not have the access code to the first secure communication session).
  • the requesting terminal accessing the first secure communication session will have access to the same exchanges carried out in the first session as any of the terminals participating in the first session.
  • the access method comprising
  • the acceptance is managed directly by the access method avoiding network overload if the acceptance is first transmitted to the requesting terminal which must then transmit it to the access method to trigger entry into the first session. of the requesting terminal.
  • the access method comprising:
  • the participating terminal has the necessary elements for the transmission of the acceptance directly to the access method since the access request comes from the access method and not directly from the requesting terminal.
  • the requesting terminal can thus make a request for access to a first session even if it does not have the means (telephone number, email address, user identifier in a social network, etc.) to directly contact a participant. at the first session.
  • sending the access request message to the at least one terminal participating in the first session comprises one of the following steps:
  • the message is received by at least one participant and the requesting terminal is not aware of the exchanges taking place in the first session before accessing them. upon acceptance.
  • broadcasting the message thus maximizes the possibility of an acceptance of the access request.
  • the access request message comprising at least one data from the following data:
  • the access method comprising
  • the access method comprising
  • Another object of the invention is a method of requesting access to a first secure communication session, called the first session, in progress between participating communications terminals, called participating terminals, by a requesting communication terminal, called requesting terminal.
  • the access request method comprising
  • An object of the invention is also a method for administering access to a first secure communication session, called first session, in progress between participating communications terminals, called participating terminals, by a requesting communication terminal, called terminal. requesting, the access administration method comprising
  • the various steps of the method according to the invention are implemented by software or computer program, this software comprising software instructions intended to be executed by a data processor of a device forming part of a communication architecture and being designed to control the execution of the various steps of this method.
  • the invention is therefore also aimed at a program comprising program code instructions for executing the steps of the method for accessing a first secure communication session and / or the method for requesting access and / or the method for accessing a first secure communication session. administration of access when said program is executed by a processor.
  • 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 form.
  • An object of the invention is also a device for managing access to a first secure communication session, called the first session, in progress between participating communications terminals, called participating terminals, by a requesting communication terminal, called requesting terminal.
  • the access management device comprising
  • a controller capable of triggering an entry in the first session in progress of the requesting terminal upon receipt of an acceptance from one of the participating terminals following a transmission of an access request message sent by the requesting terminal to the destination of 'at least one terminal participating in the first session.
  • An object of the invention is also a requesting communication terminal, called requesting terminal, able to request access to a first secure communication session, called first session, in progress between participating communication terminals, called participating terminals, by a requesting communication terminal, called requesting terminal, the requesting terminal comprising
  • a connector capable of entering the requesting terminal into the first session in progress, the connector being triggered upon receipt of an acceptance from one of the participating terminals following a transmission of an access request message sent by the requesting terminal to at least one terminal participating in the first session.
  • the requesting terminal comprising
  • An object of the invention is also a communication terminal participating, called a participating terminal, in a first secure communication session called a first session, in progress between participating communications terminals, called participating terminals, the participating terminal comprising
  • a connector capable of establishing the first session between the participating terminal and at least one other participating terminal
  • a validator capable of accepting access to the first session following a transmission of an access request message sent by the requesting terminal to at least one terminal participating in the first session, the validator triggering an entry in the first current session of the requesting terminal.
  • the participating terminal comprising
  • FIG 1a Figure 1a, a simplified diagram of a method for managing access to a first secure communication session
  • FIG. 1b Figure 1b, a simplified diagram of a method for accessing a first secure communication session by a requesting terminal according to the invention
  • FIG. 2 Figure 2 a simplified diagram of a method for requesting access to a first secure communication session by a requesting terminal according to the invention
  • FIG. 3 Figure 3, a simplified diagram of a method for administering access to a first secure communication session by a requesting terminal according to the invention
  • FIG. 4 a simplified diagram of an exchange diagram in a communication architecture implementing a method for accessing a first secure communication session by a requesting terminal according to the invention
  • FIG. 5 a simplified diagram of a communication architecture comprising a device for managing access to a first secure communication session by a requesting terminal according to the invention
  • FIG 6a Figure 6a, a simplified diagram of the use of an access management method in a particular use case of the invention
  • FIG. 6b Figure 6b, a simplified diagram of the use of a possible first step of an access request process according to the invention in the case of use of the invention of Figure 6a,
  • FIG. 6c Figure 6c, a simplified diagram of the use of a possible second step of an access request method according to the invention in the case of use of the invention of Figure 6a,
  • FIG. 6d Figure 6d, a simplified diagram of the use of an access administration method according to the invention in the case of use of the invention of Figure 6a,
  • FIG. 6e a simplified diagram of the use of a possible second step of an access request method according to the invention in the use case of the invention of FIG. 6a. Description of the embodiments
  • Figures 1a and 1b illustrate a method of managing access to a first secure communication session.
  • Figure 1a shows the access management method as it may exist in the prior art.
  • Figure 1b shows steps that can be integrated alone or in combination with the management method of Figure 1a following the establishment of the first session.
  • FIG. 1a therefore illustrates a simplified diagram of a method for managing access to a first secure communication session.
  • the method for managing access to the first secure communication session SSix_MNGT comprises an establishment of the first secure communication session SSix_STB, in particular, following a request for establishment of a secure communication session ssix_oreq from a first terminal of communication TPi participant.
  • the first participant communication terminal TPi is a communication terminal of the list of participants associated with the first secure communication session SSix.
  • the establishment of the first SSix_STB session involves access from the first participating terminal TP1 to the first SSix session.
  • the SSix_MNGT access management method comprises providing SSix_SACC of a secure access to the first SSix session to at least one participating terminal from the list 7 n ne [2 iV] on subsequent request for a secure access ssi x _sreq at the first session by the at least one participating terminal from the list TR hh f N ]
  • the at least one participating terminal TPn accesses the first SSix session.
  • the participating terminals TPi, ⁇ TP n ⁇ n accessing the first SSix session exchange data such as text messages, audio and / or video communications, content, etc. with each other. via this first SSix session.
  • a management device separate from the participating terminals TP n , in particular implemented in a communication server of a communication network;
  • a particular embodiment of the SS1X_MNGT management method is a program comprising program code instructions for executing the steps of the SSix_MNGT management method when said program is executed by a processor.
  • FIG. 1b illustrates a simplified diagram of a method for accessing a first secure communication session by a requesting terminal according to the invention.
  • the SSix_ACC access method includes
  • the requesting terminal is in particular a communication terminal not belonging to the list of participants associated with the first secure communication session.
  • the requesting terminal can also be one of the participating terminals that does not have the access code.
  • the access code is provided to the user of the requesting terminal on a communication terminal of the user of the requesting terminal separate from the requesting terminal which the user does not have at the time of the access request (in particular, the terminal requesting is a computer or a tablet by means of which a user requests access to a collaborative space, for example while on the move, this collaborative space sends the user's mobile phone an access code . If the user has forgotten their mobile phone, for example at home, they will not be able to access this space.).
  • the SSix_ACC access method includes
  • the SSix_ACC access method comprising:
  • the DACC_TR transmission of the access request message to the at least one terminal participating in the first SSix session comprises:
  • the DACC_TR transmission of the access request message to the at least one terminal participating in the first SSix session comprises:
  • the DACC_TR transmission of the access request message to at least one participating terminal of the first SSix session includes:
  • the dacc_mssg access request message includes at least one of the following data:
  • a short warning sound data in particular a jingle, a ringing, a warning tone ..., such as an entry gong, an entry bell dring, an audio data corresponds to a "knock knock" at a door, etc. ;
  • an identifier associated with the requesting terminal such as a telephone number, an IMEI identifier, etc. a name, pseudonym or email address of a user of the requesting terminal, etc. ;
  • the SSix_ACC access method includes
  • the SS1X_ACC access method comprises, in particular, an implementation of an SS 2 _COM communication via the second SS 2 session between the participating terminal TPi and the requesting terminal TR. They can thus exchange in particular messages ss 2 _mssgi, ss 2 _mssg 2 ... Through these exchanges, the participating terminal TPi and / or the user of the participating terminal TPi can ask the requesting terminal TR and / or the user of the terminal requesting information TR complementary. For example, when only the telephone number of the requesting terminal is provided by the access request message dacc_mssg, the participating terminal TPi and / or its user can request the name of the user of the requesting terminal and any other information.
  • the additional information will allow the user of the participating terminal TPi or the participating terminal to implement a decision process to accept or not the access request from the requesting terminal.
  • the SSix_ACC access method includes
  • the reception of an OK_REC acceptance or the triggering of the ENT_TRG entry commands ss 2 _stp the closing of the second SS 2 _CL session.
  • the SSix_ACC access method includes managing a second SS 2 _MNGT communication session, called the second session, distinct from the first session.
  • the second session SS 2 allows the requesting terminal TR to exchange with at least one terminal participating in the first session TPi.
  • the management of a second SS 2 _MNGT session includes in particular the implementation of the SS 2 _COM communication via the second SS 2 session between the participating terminal TPi and the requesting terminal TR.
  • the management of a second SS 2 _MNGT session includes establishing the second SS 2 _STB session and / or closing the second SS 2 _CL session.
  • the steps of managing a second SS 2 _MNGT session are implemented by the SSix_ACC access method.
  • the requesting terminal TR accesses the first SSix session.
  • the participating terminals TPi, ⁇ TP n ⁇ n and the requesting terminal TR accessing the first session SSix exchange data such as text messages, audio and / or video communications, content, etc. with each other. via this first SSix session.
  • the SSix_ACC access method is implemented in the SSix_MNGT access management method, in particular as illustrated in FIG. 1a, following the establishment of the first SSix_STB session.
  • the SSix_MNGT management method comprises creating a first secure communication session SSix_CREA prior to its establishment SSix_STB.
  • the SSix_CREA creation of the first session is carried out at the request of a participating terminal called the administrator of the first session, for example the first participating terminal TPi.
  • SSix_CREA is generated a list of participants of which at least one identifier associated with each of the participants is provided by the administrator terminal.
  • the identifier associated with a participant is in particular an identifier relating to a participating user having a communication terminal by means of which the first session is accessed and / or a participating communication terminal.
  • the participant identifiers are in particular the numbers of the participating phones.
  • the identifiers of the participants are notably email addresses of participating users.
  • the SSix_MNGT management process establishes the first SSix_STB session either (first option) automatically on a date and / or a start of session time associated with the first session, or (second option) upon receipt by the SSix_MNGT management method of a first session request ssi x _oreq from a first participating terminal TPi, etc.
  • first option automatically on a date and / or a start of session time associated with the first session
  • second option upon receipt by the SSix_MNGT management method of a first session request ssi x _oreq from a first participating terminal TPi, etc.
  • the example of FIG. 1a corresponds to this second option.
  • the SSix_MNGT management method verifies that the request for the first ssix_oreq session comes from the administrator terminal which contributed to the creation of the first session before establishing the first SSix_STB session.
  • the SSix_MNGT management method provides secure SSix_SACC access to the first session to a participating communication terminal, called a participating terminal, upon request for secure access ssix_sreq by a participating terminal TP n .
  • participating terminal is, in particular, meant a communication terminal of which an identifier forms part of the list of participants associated with the first session or of which the user has an identifier which forms part of the list of participants associated with the first session.
  • providing access to the first SSix_SACC session includes checking whether the communication terminal from which the secure access request ssix_sreq originates is a communication terminal relating to one of the participants in the list of participants.
  • a terminal relating to one of the participants of the list of participants is in particular heard a terminal corresponding to a terminals from the list of participants (when this list includes terminal identifiers) and / or a terminal available to a user corresponding to one of the users from the list of participants (when this list includes identifiers relating to users: email address , name, nickname, etc.) ...
  • the list of participants can also include both terminal identifiers (telephone number, IP address, IMEI, etc.), user identifiers ( email address, name, nickname, etc.) ...
  • the triggering of the ENT_TRG entry of a requesting terminal TR implemented by the SSix_ACC access method results from an ok cmd acceptance by a participating terminal TPi following a transmission of a dacc_mssg access request message by the requesting terminal TR.
  • the SSix_ACC access method comprises receiving DACC_REC an access request acc_req (dacc_mssg) from the requesting terminal and then transmitting DACC_TR the access request message dacc_mssg to at least one participating terminal TPi.
  • the requesting terminal TR does not know the participating terminals TP n , nor their users UPn, its access request will all the same be studied or even accepted and, in this case, it will all the same access the first session SSix.
  • the access request acc_req is transmitted directly from the requesting terminal TR to the participating terminal TPi or to the participating user UPi (provided with a participating terminal TPi).
  • the participating terminal TPi accepting the access request directly or indirectly command ok cmd the triggering ENT_TRG by the SSix_ACC access method of the input of the requesting terminal TR in the first SSix session.
  • the ENT_TRG trigger is commanded directly ok cmd by the participating terminal TPi.
  • the SSix_ACC access method includes receiving OK_REC an acceptance ok cmd from the participating terminal TPi. Receipt of an OK_REC acceptance commands ent_ok to trigger entry into the first ENT_TRG session.
  • the ok_cmd acceptance includes, in addition to validating the entry into the first SS1X session of the requesting terminal (for example, in the form of an identifier associated with the requesting terminal and, optionally, of an identifier of the first session ), data relating to access granted.
  • access to the first SSix session for the requesting terminal TR can be:
  • nth category in particular when the participants are themselves already divided into several categories for differentiated access: access in:
  • the terminated TPi participant (s) having received the access request message dacc_mssg from the requesting terminal TR can exchange synchronous or asynchronous with the requesting terminal TR prior to acceptance ok cmd.
  • the terminated TPi participant (s) can notably send the requesting terminal a first message mssgl
  • the first message mssgl from (one of) terminated (l) (ux) participant (s) TPi includes a request relating to the requesting terminal TR, in particular to its capacities in terms of peripheral (camera, microphone, size of screen, etc.), in terms of memory, in terms of processing (software, plug-in, etc.), etc. and / or to the user of the requesting terminal (identity, location, age, skill (s), level of skill (s), etc.).
  • the requesting terminal TR can send in return or in response a second message mssg2 comprising in particular one or more responses to the requests of the first message mssgl
  • the exchange can continue with additional messages between the terminated (s) TPi participant (s) and the requesting terminal TR.
  • the exchange is closed in particular by accepting ok cmd by one of the participating terminals TPi exchanging with the requesting terminal TR.
  • one of the mssg messages coming from the participating terminal TPi includes the acceptance command ok cmd.
  • the requesting terminal TR commands ok cmd to trigger its entry into the first ENT_TRG session by transmitting the accept command contained in the first mssgl message to the SSix_ACC access method.
  • a particular embodiment of the SSix_ACC access method is a program comprising program code instructions for executing the steps of the SSix_ACC access method when said program is executed by a processor.
  • a particular embodiment of the SS1X_MNGT management method is a program comprising program code instructions for the execution of the steps of the SSix_MNGT management method and of the SSix_ACC access method when said program is executed by a processor.
  • FIG. 2 illustrates a simplified diagram of a method for requesting access to a first secure communication session by a requesting terminal according to the invention.
  • the SSix_DACC access request method is a method of requesting access to a first secure communication session, called the first session, in progress between participating communication terminals TPi, called participating terminals, by a requesting communication terminal TR, said requesting terminal.
  • the SSix_DACC access request process includes
  • the SSix_DACC access request process comprises:
  • the DACC_EM transmission of the access request message to at least one participating terminal of the first SSix session includes:
  • the DACC_EM transmission of the access request message to the at least one terminal participating in the first SSix session comprises:
  • the DACC_EM transmission of the access request message to at least one participating terminal of the first SSix session includes:
  • the dacc_mssg access request message includes at least one of the following data:
  • a short warning sound data in particular a jingle, a ringtone, a bell warning ..., such as an entry gong, an entry bell dring, an audio data corresponds to a "knock knock" on a door, etc. ;
  • an identifier associated with the requesting terminal such as a telephone number, an IMEI identifier, etc. a name, pseudonym or email address of a user of the requesting terminal, etc. ;
  • the SSix_DACC access request process comprises
  • the SS1X_DACC access request method comprises, in particular, an implementation of an SS2_COM communication via the second SS2 session between the participating terminal TPi and the requesting terminal TR. They can thus exchange in particular messages ss2_mssgi, ss2_mssg2 ... Through these exchanges, the participating terminal TPi and / or the user of the participating terminal TPi can ask the requesting terminal TR and / or the user of the requesting terminal TR for information. complementary. For example, when only the telephone number of the requesting terminal is provided by the access request message dacc_mssg, the participating terminal TPi and / or its user can request the name of the user of the requesting terminal and any other information.
  • the additional information will allow the user of the participating terminal TPi or the participating terminal to implement a decision process to accept or not the access request from the requesting terminal.
  • the SSix_DACC access request process comprises
  • the SS1X_DACC access request method includes participating as a caller SS2_CE in a second communication session, called the second session, distinct from the first session.
  • the second session SS2 allows the requesting terminal TR to exchange with at least one terminal participating in the first TPi session.
  • Participation as a caller in a second SS2_CE session comprises in particular the implementation of the SS2_COM communication via the second SS2 session between the participating terminal TPi and the requesting terminal TR.
  • participation as a caller in a second SS2_CE session includes connecting SS2_CNX and / or disconnecting SS2_DCNX the requesting terminal TR from the second SS2 session.
  • the steps of participating as a caller in a second SS2_CE session are implemented by the SSix_DACC access request method.
  • the requesting terminal TR accesses the first SSix session.
  • the participating terminals TPi, ⁇ TP n ⁇ n and the requesting terminal TR accessing the first session SSix exchange data such as text messages, audio and / or video communications, content, etc. with each other. via this first SSix session.
  • the SSix_ENT entry of a requesting terminal TR results from an acc_cmd acceptance by a participating terminal TPi following a transmission of an access request message dacc_mssg by the requesting terminal TR.
  • the SSix_DACC access request method includes sending DACC_EM an acc_req (dacc_mssg) access request from the requesting terminal to at least one participating terminal TPi, in particular via the SSix_ACC access method.
  • the access request acc_req is transmitted directly from the requesting terminal TR to the participating terminal TPi or to the participating user UPi (provided with a participating terminal TPi).
  • the participating terminal TPi accepting the access request commands directly or indirectly ok cmd the entry into the first session of the requesting terminal SS1X_ENT
  • the SSix_ENT input is controlled directly acc_cmd by the participating terminal TPi.
  • the SSix_ACC access method receiving an ok cmd acceptance from the participating terminal TPi commands acc_cmd the SSix_ENT entry.
  • the requesting terminal TR can in particular receive SS2_REC from (u) (es) terminated (l) (ux) participant (s) TPi a first message mssgl, in particular via a second session SS2 - the first message mssgl is then, for example, relayed from the participating terminal TPi to the requesting terminal TR by management of the second session SS2_MNGT.
  • the first mssgl message includes a request relating to the requesting terminal TR, in particular to its capacities in terms of peripheral device (camera, microphone, screen size, etc.), in terms of memory, in terms of processing (software, plug -in ...), etc. and / or to the user of the requesting terminal (identity, location, age, skill (s), level of skill (s), etc.).
  • the requesting terminal TR can send SS2_EM in return or in response to a second message mssg2 comprising in particular one or more responses to the requests of the first message mssgl, in particular via the second session SS2 if the first message mssgl was transmitted via it.
  • the second message mssg2 is then, for example, relayed from the requesting terminal TR to the participating terminal TPi by the management of the second session SS2_MNGT.
  • the exchange can continue with additional messages between the TPi participant (s) and the requesting terminal TR.
  • the exchange is closed in particular by the accept command acc_cmd by one of the participating terminals TPi exchanging with the requesting terminal TR.
  • one of the mssg messages coming from the participating terminal TPi includes the acceptance command acc_cmd, ok cmd.
  • the requesting terminal TR commands acc_cmd its entry in the first SSix_ENT session by transmitting the acc_cmd, ok cmd acceptance command contained in the received message mssg either directly to the SS1X_ENT entry or to the SSix_ACC access method .
  • a particular embodiment of the SSix_DACC access request method is a program comprising program code instructions for performing the steps of the SSix_DACC access request method when said program is executed by a processor.
  • FIG. 3 illustrates a simplified diagram of a method for administering access to a first secure communication session by a requesting terminal according to the invention.
  • the SSix_ADM access administration method administers an access to a first secure communication session SSix, called the first session, in progress between participating communications terminals TPn, called participating terminals, by a requesting communication terminal TR, called requesting terminal .
  • the SSix_ADM access administration method comprises - sending an OK_EM acceptance from one of the participating terminals TPi following receipt of a dacc_mssg access request message received by at least one participating terminal TPi of the first session of the requesting terminal TR at destination, the ok cmd acceptance sent triggering, on reception, an entry in the first session in progress of the requesting terminal.
  • the SSix_ADM access administration method comprises:
  • the reception DACC_REC is a reception of an access request acc_req comprising the access request message dacc_mssg
  • the access request message dacc_mssg is relayed by an SS1X_ACC access method, for example such as described in connection with figure 1 b.
  • the dacc_mssg access request message includes at least one of the following data:
  • a short warning sound data in particular a jingle, a ringing, a warning tone ..., such as an entry gong, an entry bell dring, an audio data corresponds to a "knock knock" at a door, etc. ;
  • an identifier associated with the requesting terminal such as a telephone number, an IMEI identifier, etc. a name, pseudonym or email address of a user of the requesting terminal, etc. ;
  • the sending of the OK_EM acceptance is activated ok_act by the participating user UPi with the participating terminal TPi implementing the SSix ADM access administration method.
  • the access request message dacc_mssg includes an input gong and the name of the requesting user UR of the requesting terminal TR.
  • the dacc_mssg access request message will be reproduced by the participating terminal TPi.
  • the participating user UPi with the participating terminal TPi will perform an ok_act approval action: oral approval, pressing an OK key on a physical or virtual keyboard, nodding.
  • the SSix_ADM access administration process optionally includes a UP_CPT capture of the ok_act approval action which activates the issuance of the OK_EM acceptance.
  • the SSix_ADM access administration method comprises
  • the SSix_ADM access administration method comprises, in particular, an implementation of an SS 2 _COM communication via the second SS 2 session between the participating terminal TPi and the requesting terminal TR. They can thus exchange in particular messages ss 2 _mssgi, ss 2 _mssg 2 ...
  • the participating terminal TPi and / or the user of the participating terminal TPi can ask the requesting terminal TR and / or the user of the terminal requesting additional information TR.
  • the additional information will allow the user of the participating terminal TPi or the participating terminal to implement a decision process to accept or not the access request from the requesting terminal.
  • the SSix_ADM access administration method comprises
  • the SSix_ADM access administration method includes participating as a caller SS 2 _CG in a second communication session, called the second session, distinct from the first session.
  • the second SS session 2 allows the participating terminal TPi to exchange with the requesting terminal.
  • Participation as a caller in a second SS 2 _CG session includes in particular the implementation of the SS 2 _COM communication via the second SS 2 session between the participating terminal TPi and the requesting terminal TR.
  • participation as a caller in a second SS 2 _CG session includes requesting the establishment of the second SS 2 _STBR session and / or disconnecting the participating terminal TPi from the second SS 2 _DCNX session.
  • the steps of participating as a caller in a second SS 2 _CG session are implemented by the SSix_ADM access administration method.
  • the requesting terminal TR accesses the first SSix session.
  • the participating terminals TPi, ⁇ TP n ⁇ n and the requesting terminal TR accessing the first session SSix exchange data such as text messages, audio and / or video communications, content, etc. with each other. via this first SSix session.
  • the triggering of the ENT_TRG entry of a requesting terminal TR implemented by the SSix_ACC access method results from an OK_EM transmission, by a participating terminal TPi, of an ok cmd acceptance received, in particular by the method of SS1X_ACC access, following a transmission of a dacc_mssg access request message by the requesting terminal TR.
  • the SSix_ADM access administration method comprises receiving DACC_REC an access request message dacc_mssg from a requesting terminal TR, in particular in the form of an access request acc_req (dacc_mssg) from the requesting terminal comprising the dacc_mssg access request message.
  • the access request message dacc_mssg received DACC_REC by the SSix_ADM access administration method is sent by an SSix_DACC access request method as described in particular in connection with FIG. 2 and relayed (this is ie received from the requesting terminal then sent to at least one participating terminal TPi) by an SSix_ACC access method as described in particular in connection with FIG. 1b.
  • the access request acc_req is received DACC_REC directly by the user.
  • participating terminal TPi of the requesting terminal TR the participating terminal TPi accepting the access request directly or indirectly command ok cmd the triggering ENT_TRG by the SSix_ACC access method of the input of the requesting terminal TR in the first SSix session.
  • the ENT_TRG trigger is commanded directly ok cmd by the participating terminal TPi by an OK_EM transmission of acceptance to the SSix_ACC access process.
  • the SSix_ACC access method includes receiving OK_REC an acceptance ok cmd from the participating terminal TPi. Receipt of an OK_REC acceptance commands ent_ok to trigger entry into the first ENT_TRG session.
  • the OK_EM acceptance comprises, in addition to a validation of the entry into the first SS1X session of the requesting terminal ok_cmd ⁇ SSix, TR) (for example, in the form of an identifier associated with the requesting terminal and, optionally, of an identifier of the first session), data relating to the access granted ok_cmd ⁇ SSix, TR, acc_tyTR).
  • the acc_tyTR access to the first SSix session for the requesting terminal TR can be:
  • nth category in particular when the participants are themselves already divided into several categories for differentiated access: access in:
  • the participating terminal TPi having received the access request message dacc_mssg from the requesting terminal TR can exchange synchronously or asynchronously with the requesting terminal TR prior to the OK_EM issue of acceptance ok cmd.
  • the participating terminal TPi can in particular send to the requesting terminal a first message mssgl.
  • the first message mssgl from the participating terminal TPi comprises a request relating to the requesting terminal TR, in particular to its capacities in terms of peripheral device (camera, microphone, screen size, etc.), in terms of memory, in terms of processing. (software, plug-in ...), etc. and / or to the user of the requesting terminal (identity, location, age, skill (s), level of skill (s), etc.).
  • the requesting terminal TR can send in return or in response a second message mssg2 comprising in particular one or more responses to the requests of the first message mssgl
  • the exchange can continue with additional messages between the participating terminal TPi and the requesting terminal TR.
  • the exchange is closed in particular by accepting ok cmd by the participating terminal TPi exchanging with the requesting terminal TR.
  • one of the mssg messages coming from the participating terminal TPi includes the acceptance command ok cmd.
  • the requesting terminal TR commands ok cmd to trigger its entry into the first ENT_TRG session by transmitting the accept command contained in the first mssgl message to the SSix_ACC access method.
  • a particular embodiment of the SSix_ADM access administration method is a program comprising program code instructions for performing the steps of the SSix_ADM access administration method when said program is executed by a processor.
  • the invention relates to a program comprising program code instructions for executing the steps of the method for accessing a first secure communication session and / or the method for requesting information. access and / or the access administration method when said program is executed by a processor.
  • FIG. 4 illustrates a simplified diagram of an exchange diagram in a communication architecture implementing a method for accessing a first secure communication session by a requesting terminal according to the invention.
  • FIG. 4 provides for the use of a SCOM communication server implementing an SS1X_ACC access method according to the invention, in particular an SS1X_ACC access method as illustrated by FIG. 1b and / or an SS1X_MNGT access management method optionally implementing the SS1X_ACC access method.
  • the SCOM communication server is or comprises a separate management device from the participating terminals TP n in the first secure communication session SSix and from the requesting communication terminal TR.
  • a first secure communication session SSix is established by the communication server SCOM (as shown in phase I of FIG. 4).
  • the SSix_MNGT access management method implemented by the SCOM communication server includes the establishment of the first SSix secure communication session.
  • the first secure communication session SSix is established on a request for establishment of the first ssix_oreq session originating from a participating terminal: the first participating terminal TPi in the case of FIG. 4.
  • the first participating terminal TP1 is in particular a terminal communication administrator of the first session, i.e. the communication terminal having defined a list of participants in the first SSix session and / or the type (s) of access authorized for the at least one of the participants (the same predefined type of access can be authorized for one or more or even all of the participants).
  • the first terminal TP1 having access to the first SSix session can prepare the work envisaged in the first session, for example by sharing content c and / or by depositing a welcome message from the other participants.
  • At any time of the first SS1X session at least one of the participating terminals TPi, ⁇ TP n ⁇ (distinct from the first terminal in the example of FIG. 4) requests ssix_sreq secure access to the first session to the SCOM communication server .
  • the SS1X_MNGT access management method checks AUTH_V whether the participating terminal in question TPi, ⁇ TP n ⁇ is authorized to access the first SS1X session prior to providing the secure SS1X_ACC access to the first session ssix to the participating terminal TPi, ⁇ TPn ⁇ requiring this secure access.
  • This AUTH_V authorization check comprises in particular at least one of the following verification steps:
  • the SCOM communication server provides secure access to the first SSix participating terminal session in question TPi, ⁇ TP n ⁇ (as shown in phase II of FIG. 4).
  • the first terminal TP1 and the other participating terminals TPi, ⁇ TP n ⁇ having access to the first SSix session can then exchange with each other and / or share content depending on the type of the first communication session: conference call, and / or conference text or "chat room" in English, and / or audio conference, and / or videoconference, and / or collaborative space with in particular document sharing in reading and / or writing.
  • a requesting terminal TR can, at any time, request access to the first session, in particular from the SCOM communication server as illustrated in FIG. 4.
  • This transmission of a daccc_mssg access request message by the requesting terminal is in particular a step of an SS1X_DACC access request method (in particular as illustrated by FIG. 2) implemented by the requesting terminal.
  • the SCOM communication server receiving the access request message daccc_mssg transmits it to at least one participating terminal TPi, TPi, TP n .
  • the reception then the transmission to a participating terminal TPi, TPi, TP n of the access request message daccc_mssg is a step of an SS1X_ACC access method, in particular as illustrated by FIG. 1b , and / or an SS1X_MNGT access management method (possibly implementing steps of an SS1X_ACC access method) implemented by the SCOM communication server.
  • At least one participating terminal TPi can send an ok_cmd acceptance of this request to the SCOM communication server.
  • the transmission of an acceptance by the participating terminal TPi to the SCOM communication server is a step of an SS1X_ADM access administration method, in particular as illustrated in FIG. 3.
  • the server communication SCOM commands acc_cmd access by the requesting terminal to the first SS1X session which triggers the entry of the requesting terminal TR into the first SS1X session (phase III illustrated by FIG. 4).
  • the first terminal TP1, the other participating terminals TPi, ⁇ TPn ⁇ and the requesting terminal having access to the first session SSix can then exchange with each other and / or share content depending on the type of the first communication session and / or their type. access.
  • the participating terminal Prior to the issuance of an ok cmd acceptance by the participating terminal TPi, the participating terminal can request an ss2_req establishment of a second communication session between the participating terminal TPi and the requesting terminal TR to the SCOM communication server.
  • the SCOM communication server establishes the second SS2 session.
  • the participating terminal TPi and the requesting terminal TR can exchange to allow in particular the participating terminal TPi and / or its user UPi to determine APV_DT whether the access by the requesting terminal to the first session is approved or not.
  • the exchanges are notably exchanges of messages ss2_mssgi, ss2_mssg2 ...
  • the reception by the SCOM communication server of the ok_cmd acceptance or the triggering by the SCOM communication server of the input of the requesting terminal TR closes s2_stp the second session.
  • FIG. 5 illustrates a simplified diagram of a communication architecture comprising a device for managing access to a first secure communication session by a requesting terminal according to the invention.
  • the access management device 31 is able to manage access to a first secure communication session, called the first session, in progress between participating communications terminals 1 1 ..1 n, 1i, called participating terminals, by a requesting communication terminal 2, called requesting terminal.
  • the access management device 31 comprises
  • controller 312 capable of triggering an entry in the first session in progress of the requesting terminal 2 upon receipt of an ok cmd acceptance from one of the participating terminals 1i..1n, 1 i (the terminal 1i in the example illustrated by FIG. 5) following a transmission of a dacc_mssg access request message sent by the requesting terminal 2 to at least one participating terminal of the first session 1 1 ..1 n, 1i.
  • the communication architecture illustrated in Figure 5 comprises
  • the access management device 31 is implemented in a communication server, that is to say a device capable of managing at least one communication session via the communication network 4.
  • the access management device 31 is, or comprises, or is implemented in a device for managing a first secure communication session via the communication network 4.
  • the device management system implements a device for managing a first secure communication session 310.
  • the access management device 31 comprises a base of first secure sessions 313 in which lists of participants are recorded in association with the first secure communication sessions.
  • the access management device 31 comprises a generator 310o capable of establishing ssix_stb a first secure communication session SSix.
  • the generator 310o receives an establishment request ssix_oreq from a first participating terminal 1i. Then the generator 310o is able to establish ssix_stb the first secure communication session SS-ix upon receipt of the establishment request ssix_oreq.
  • the access management device 31 comprises a connector 310 A capable of providing secure access ssix_sacc to the first secure communication session SSix to other participating terminals l 2 ... 1n, 1i on access request secure ssix_sreq of these participating terminals l 2 ... 1n, 1i. Then, at least one of the participating terminals comprises in particular a generator / transmitter of a request for the establishment of a first secure session (not illustrated).
  • the participating terminals comprising in particular a generator / sender of a request for access to the first secure session (not illustrated). This is the case, in particular, of the other participating terminals l 2 ... 1 n, 1 i of FIG. 5.
  • the management device 31 further comprises an access request relay 311 capable of transmitting to at least one of the participating terminals l 2 ... 1n, 1i an access request message dacc_mssg received from a terminal requesting 2.
  • the relay comprises a receiver (not illustrated) of the access request message dacc_mssg and / or access request acc_req coming from the requesting terminal, the access request acc_req (dacc_mssg) comprising the request message d 'access.
  • the relay includes a sender (not shown) of the dacc_mssg access request message to at least one of the participating terminals l 2 ...
  • the relay also includes, in particular, a message extractor (not illustrated) from a request capable of extracting an access request message dacc_mssg from an access request acc_req.
  • the extractor is implemented between the request receiver and the access request message sender to provide the sender with the access request message extracted from the received access request.
  • FIG. 5 also illustrates a requesting communication terminal 2, called requesting terminal, capable of requesting access to a first secure communication session SSix, called first session, in progress between participating communication terminals 1i, l 2 ... 1n , 1i, called participating terminals, by the requesting communication terminal 2, said requesting terminal.
  • the requesting terminal 2 has
  • a connector 22 capable of entering the requesting terminal 2 in the first current session SSix, the connector 22 being triggered acc_cmd upon receipt of an ok cmd acceptance from one of the participating terminals 1 i following a transmission of a message from access request dacc_mssg sent by the requesting terminal 2 to at least one participating terminal of the first session 1 i, l 2 ... 1 n, 1i.
  • the requesting terminal 2 comprises
  • the requesting terminal 2 comprises at least one output man-machine interface, called the output interface, or reproduction means 24, such as a screen, at least one loudspeaker, etc. and / or at least one.
  • human-machine input or input interface (not shown), called the input interface, such as a keyboard, a mouse, a touch screen, a microphone, a camera, etc.
  • the generator 21 receives from an input interface data relating to the dact action relating to this interface d user input requesting UR.
  • the requesting user activates a warning button (equivalent to an entrance doorbell) on this input interface or hits the touch screen in a manner similar to knocking the door (“knock knock”) ...
  • FIG. 5 also illustrates participating communication terminals 1 1, 1 2 ... 1 n, 1 i.
  • a participant communication terminal 1 1, 1 2 ... 1 n, 1 i, called participant terminal is a communication terminal able to access a first secure communication session SSix called first session, in progress between communication terminals participantsli, l 2 ... 1n, 1i, called participating terminals.
  • a participating terminal 1 1, l 2 ... 1n, 1i has
  • a connector 12i (illustrated in FIG. 5 only for the participating terminal 1i) capable of establishing the first session SSix between the participating terminal 1i and at least one other participating terminal 1 1, I 2 ... I n,
  • a validator 16i (illustrated in FIG. 5 only for the participating terminal 1 i) capable of accepting an ok access cmd to the first SSix session following a transmission of an access request message dacc_mssg sent by the requesting terminal 2 to destination of at least one participating terminal 1 i of the first session, the validator 16i triggering an acc_cmd entry in the first session SSix in progress of the requesting terminal 2.
  • the participating terminal 1i includes a receiver 11i of a dacc_mssg access request message to the first SS1X session from the requesting terminal 2.
  • the participating terminal 1i comprises at least one output man-machine interface, called the output interface, or reproduction means 14i, such as a screen, at least one loudspeaker ... and / or at least one.
  • human-machine input or input interface (not shown), called the input interface, such as a keyboard, a mouse, a touch screen, a microphone, a camera, etc.
  • the receiver 11 i optionally supplies the access request message dacc_mssg to the output interface 14i so that the access request message dacc_mssg can be perceived (read, heard, etc.) by the participating user UPi of the participating terminal TPi.
  • the validator 16i receives, directly or via an input interface (not shown) from the participating terminal TPi, an ok_act acceptance action from the participating user UPi in response in particular to the access request message dacc_mssg provided to the participating user UPi by the output interface 14i.
  • the participating terminal 1i comprises
  • a connector 130i capable of establishing a second SS2 synchronous communication session with the requesting terminal 2 prior to the ok cmd acceptance by the validator 16i.
  • the participating terminal 1i comprises a generator 15i for requesting the establishment of a second ss2_req session.
  • the generator 15i sends the request to establish a second session ss2_req to a second session management device 32 in particular implemented in a communication server 3.
  • the first secure communication session management device 31 and the second session management device 32 can, for example, be implemented in a communication server 3.
  • the access management device 32 comprises a generator 320 capable of establishing ss2_stb a second communication session SS2 between the requesting terminal 2 and the participating terminal 1i.
  • the participating terminal 1 i and the requesting terminal 2 each comprise a communication device, respectively 13i, 23, via the second session SS2.
  • the communication devices 13i, 23 include connectors 130i, 230 for the second session SS2, and possibly transmitters 131 i, 231 and / or receivers 132i, 232 for example of messages mssg-i, mssg2 ... which are transmitted via the second SS2 session under the names of ss2_mssgi, ss2_mssg2 ...
  • the second session establishment request generator 15i SS2 activates xtrg the communication device via the second session 13i of the participating terminal 1 i.
  • the messages mssg-i, mssg2 ... transmitted via the second session are input via the input interfaces respectively 131 i, 231 and reproduced by the output interfaces respectively 132i, 232 respectively intended for the participating user UPi and the requesting user UR.
  • the validator 16i comprises an analyzer capable of deciding according to the access request message dacc_mssg, and / or the messages exchanged via the second session ss2_mssgi, ss2_mssgi ..., in particular those received from the requesting terminal 2, and / or or an ok act action by the participating user UPi of an access acceptance by the requesting terminal 2 to the first SSix session. If the analyzer decides on an acceptance, the validator 16i sends an acceptance ok_cmd to the management device of the first session 31, in particular to the controller 312.
  • the first secure session is a collaborative space comprising a textual exchange space, a videoconference and a document sharing space between participating users UPi, UP2 .. UPn each equipped with at least one participating communication terminal to access this collaborative space.
  • FIG. 6a illustrates a simplified diagram of the use of an access management method in a particular use case of the invention.
  • FIG. 6a represents a screen of the participating terminal of a first participating user LIP1.
  • the screen possibly includes several windows, including a window associated with the first SSix_WD session and possibly in sub-windows:
  • SSIX_XWDUPI in which the text messages exchanged by the various participants in the first session are reproduced, in particular in chronological order (in the example of FIG. 6a: the messages of the first participating user mssgi, upi, mssg4, upi, a message from the second participating user mssg2, up2, a message from an nth participating user mssg3, up n ...); and or
  • the SSix_pWD sharing sub-window itself comprising in particular one or more sub-window, for example
  • FIG. 6b illustrates a simplified diagram of the use of a possible first step of an access request method according to the invention in the case of use of the invention of FIG. 6a.
  • FIG. 6a represents a screen of the requesting terminal of a user requesting UR.
  • the requesting user is aware of the first session and, for example, enters an address from the first session (such as a url type address in their browser). Its screen then displays a first entry window in the first SSix_EWDi session.
  • This first SSix_EWDi session entry window comprises in particular a zone for entering an identifier id_cptz of the user requesting UR and / or an identifier of his terminal and / or a zone for entering an access code cd_cptz.
  • the UR requesting user who does not have the access code or is not part of the list of participants cannot enter the ID identifier and / or the CD access code requested for secure access.
  • the first SSix_EWDi session entry window comprises in particular a virtual warning button kk_cptz on which the requesting user can act dact to send an access request message.
  • the entry window only comprises an interaction element such as the virtual warning button kk_cptz, or a capture of a knocking gesture on a door, or a capture of an oral “Hello! Is there anyone? "," Hello ", or etc.
  • FIG. 6c illustrates a simplified diagram of the use of a possible second step of an access request method according to the invention in the case of use of the invention of FIG. 6a.
  • a second entry window SSIX_EWD2 is reproduced allowing the requesting user UR to complete the access request message dacc_cpl.
  • the requesting user can add their name, the reason for their access request, etc.
  • the dacc_mssg access request message thus constituted by the user's dact action and / or a dacc_cpl complement is transmitted from the requesting terminal to at least one participating terminal of one of the participating users U1 ... UPn.
  • FIG. 6d illustrates a simplified diagram of the use of an access administration method according to the invention when using the invention of FIG. 6a.
  • At least one of the participating terminals of the participating users UP1 ... UPn receives the access request message and reproduces it in a DACC_WD access request window.
  • FIG. 6d illustrates the screen of the participating terminal of the participating user i UPi.
  • new messages are reproduced: mssg5, up2, mssg6, up3, mssg7, up2, mssgs.upi, mssgg.upi in the pane d 'textual exchange SSIX_XWDUPÎ
  • the exchanges relating to this second session are reproduced in connection with the access request window DACC_WD.
  • DACC_WD access request window
  • the exchanges are reproduced in textual form in the DACC_WD access request window at least if they are textual exchanges, or even also by voice-to-text conversion when they are voice and / or audio.
  • a Visio stream originating from the requesting terminal of the requesting user SS2_VUR is reproduced.
  • the access request window DACC_WD comprises at least one interaction element OK_BT allowing the participating user UPi to accept the access request from the requesting user.
  • This interaction element is in particular a physical or virtual acceptance button, and / or a camera picking up a nod of the head, and / or a microphone picking up an oral acceptance, etc.
  • FIG. 6e illustrates a simplified diagram of the use of a possible second step of an access request method according to the invention in the case of use of the invention of FIG. 6a.
  • Figure 6e shows a screen of the requesting terminal of the requesting user UR.
  • the screen possibly includes several windows, including a window associated with the first SSix_WD session and possibly in sub-windows:
  • an SS IX _XWDU R text exchange sub-window in which the text messages exchanged by the various participants in the first session are reproduced, in particular in chronological order (in the example of FIG. 6e: all the messages exchanges started in FIG. 6a and then continued in particular in FIG. 6d, including a message from the terminal requesting the first SSix session (mssg-io.upR, mssg4, upi, etc.); and or
  • the SSix_pWD sharing sub-window itself comprising in particular one or more sub-window, for example
  • a requesting user who knows the location of the secure shared digital space (for example, the access url, the name of the virtual room, etc.) but who is not able to enter their usernames and / or passwords due to forgetting, loss, etc. has the possibility of requesting access (in particular in the form of a voice, sound, liver, visual, etc.) call to this space that he seeks to reach via a secure channel.
  • This call visible from inside this space, allows anyone already present to accept their entry into / access to this space.
  • the invention is applicable to any secure shared digital space as soon as it requires an access key (regardless of its form). Thus, only one person will need their key to access this space before validating (by acceptance ok cmd) the access of the other participants one by one by recognizing them using their voice when the request message for access includes a voice message, their face when the access request message includes a photo or video of the requesting user, their access material, a secret question or any other recognition element.
  • the invention is also aimed at a support.
  • the information 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 floppy disk or a hard disk.
  • the information 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 over a network, in particular of the Internet type.
  • the information 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 method in question.
  • the invention is implemented by means of software and / or hardware components.
  • module can correspond equally well to a software component or to a hardware component.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or of a software capable of implementing a function or a function set as described above.
  • a hardware component corresponds to any element of a hardware set (or hardware) capable of implementing a function or a set of functions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne l'accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal d'accès requérant. Un objet de l'invention est un procédé d'accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d'accès comportant - déclencher une entrée dans la première session en cours du terminal requérant dès réception d'une acceptation d'un des terminaux participants suite à une transmission d'un message de demande d'accès émis par le terminal requérant à destination d'au moins un terminal participant de la première session. Ainsi, le terminal requérant accédera facilement à la première session de communication sécurisée même si le terminal requérant ne suit pas la procédure d'accès sécurisée.

Description

DESCRIPTION
PROCEDE D’ACCES ET DISPOSITIF DE GESTION D’ACCES A UNE SESSION DE COMMUNICATION SECURISEE ENTRE DES TERMINAUX DE COMMUNICATION PARTICIPANTS PAR UN TERMINAL DE COMMUNICATION
REQUERANT
Domaine technique
L'invention concerne l’accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal d’accès requérant. Par session de communication sécurisée est notamment entendu un espace numérique partagé sécurisé tel qu’une conférence téléphonique, une visioconférence, un espace collaboratif virtuel, etc. qui nécessite l’usage de clefs d’accès pour chacun des terminaux de communication participants.
État de la technique
Ce type de session de communication sécurisée nécessite de définir préalablement à l’établissement de la session de communication la liste des participants : par exemple identifiant utilisateurs et/ou terminaux participants. Ainsi, seuls les participants identifiés dans la liste seront autorisés à établir et/ou accéder à la session de communication sécurisée.
Pour ajouter un degré de sécurité supplémentaire, il peut aussi être prévu que l’établissement et/ou l’accès à la session de communication sécurisée soit en outre conditionnée à la fourniture par le terminal de communication participant souhaitant établir et/ou accéder à la session de communication sécurisée d’un clef composé notamment par un code d’accès (tel qu’un code numérique, un code alphanumérique, aussi appelé mot de passe, un schéma, un code composé d’une succession d’images, etc.) et/ou des données biométriques...
Ainsi, seuls les participants préalablement inscrits peuvent accéder à cette session de communication sécurisés et, si nécessaire, doivent pouvoir présenter le code d’accès pour être autoriser à y accéder.
Or, un participant peut avoir oublié ou perdu son code d’accès. Cela peut s’avérer problématique car les contenus (conversation, documents textuels, audio et/ou vidéo, etc.) que le participant devait partager durant cette session de communication sécurisée ne seront alors pas accessibles par les autres participants. Et, lorsque la session de communication sécurisée permet la génération d’au moins un contenu final, ce contenu final sera erroné car il ne sera pas fonctions des contenus du participant qui n’a pas accédé à la session de communication sécurisée mais seulement des contenus partagés par les participants ayant accédé cette session.
Une solution serait l’utilisation d’un système de récupération du code d’accès. Mais, si un système de récupération du code d’accès n’est pas prévu en lien avec l’accès sécurisé à la session de communication sécurisée ou si le participant ne dispose pas des moyens nécessaire à cette récupération du code d’accès (par exemple, s’il n’a pas avec lui le téléphone mobile recevant le code temporaire par SMS), il ne sera pas autorisé à accéder à la session de communication sécurisée.
En outre, la liste des participants peut être erronée : une personne et/ou un dispositif de communication ayant été omis dans la liste. Dans ce cas aussi, la personne omise ne sera pas autorisé à accéder à la session de communication sécurisée : il ne pourra donc pas contribuer à la session et si celle-ci est génératrice d’un contenu final, ce contenu final sera erroné.
Une solution, si une telle personne a connaissance de la session de communication ou a été avertie par un participant de la session de communication, serait qu’il contacte la personne administrant la liste des participants et que celle-ci l’ajoute à cette liste de participants afin de pouvoir accéder à la session de communication sécurisée. Mais ce processus est laborieux car nécessite d’abord que la personne omise ait connaissance de la session de communication sécurisée planifiée, puis que la personne omise connaisse la personne administrant la liste de participants et au moins un moyen de la contacter (numéro de téléphone, adresse email, etc.), et que la personne administrant la liste de participants soit contacter par la personne omise avant la session de communication sécurisée pour l’intégrer à la liste des participants. En outre, même dans ce cas, il subsiste un risque d’erreur que la personne omise soit intégrer dans une autre liste lorsque la personne administrant gère plusieurs liste de participants à des sessions de communication sécurisée distinctes.
Exposé de l’invention
Un des buts de la présente invention est de remédier à des inconvénients par rapport à l'état de la technique.
Un objet de l’invention est un procédé d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’accès comportant
- déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
Ainsi, le terminal requérant accédera facilement à la première session de communication sécurisée même si le terminal requérant ne suis pas la procédure d’accès sécurisée (soit que le terminal requérant ne soit pas un terminal de la liste de participants autorisés à accéder à la première session de communication sécurisée, soit que le terminal requérant n’ait pas le code d’accès à la première session de communication sécurisée). En outre, le terminal requérant accédant à la première session de communication sécurisée aura accès aux mêmes échanges effectués dans la première session que n’importe lequel des terminaux participants à la première session. Avantageusement, le procédé d’accès comportant
- recevoir l’acceptation d’un terminal participant.
Ainsi, l’acceptation est gérée directement par le procédé d’accès évitant une surcharge de réseau si l’acceptation est d’abord transmise au terminal requérant qui doit ensuite la transmettre au procédé d’accès pour déclencher l’entrée dans la première session du terminal requérant.
Avantageusement, le procédé d’accès comportant :
- recevoir une requête d’accès d’un terminal requérant, la requête d’accès comportant le message de demande d’accès, et
- émettre le message de demande d’accès à destination d’au moins un terminal participants de la première session.
Ainsi, le terminal participant dispose des éléments nécessaires pour la transmission de l’acceptation directement au procédé d’accès puisque la demande d’accès provient du procédé d’accès et non directement du terminal requérant.
En outre, le terminal requérant peut ainsi effectuer une demande d’accès à une première session même s’il ne dispose pas de moyens (numéro de téléphone, adresse email, identifiant utilisateur dans un réseau social, etc.) pour contacter directement un participant à la première session.
Avantageusement, émettre le message de demande d’accès à destination du au moins un terminal participant de la première session comporte une des étapes suivantes :
- diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session;
- émettre le message par communication asynchrone à destination d’au moins un des terminaux participants;
- émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session.
Ainsi, quel que soit le mode d’émission du message de demande d’accès, le message est reçu par au moins un participant et le terminal requérant n’a pas connaissance des échanges ayant lieu dans la première session avant d’y accéder suite à l’acceptation.
En outre, la diffusion du message permet ainsi de maximiser la possibilité d’une acceptation de la demande d’accès.
De plus, avec l’émission du message en dehors de la première session, une suspension des échanges dans la première session peut ainsi être évité. Avantageusement, le message de demande d’accès comportant au moins une données parmi les données suivantes :
- une donnée sonore courte d’avertissement,
- un identifiant associé au terminal requérant,
- un identifiant associé à un terminal participant à la session de communication sécurisée,
- un identifiant de la première session à laquelle le terminal requérant demande l’accès,
- un message textuel, audio ou vidéo d’un utilisateur du terminal requérant.
Avantageusement, le procédé d’accès comportant
- établir, préalablement au déclenchement de l’entrée dans la première session du terminal requérant, une deuxième session de communication synchrone entre le terminal requérant et un des terminaux participants à la première session sur requête d’établissement dudit un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication.
Avantageusement, le procédé d’accès comportant
- clore la deuxième session dès mise en œuvre par le procédé d’accès d’une étape parmi les suivantes :
+ la réception d’une acceptation par le terminal participant de la deuxième session,
+ le déclenchement de l’entrée dans la première session du terminal requérant.
Un autre objet de l’invention est un procédé de demande d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé de demande d’accès comportant
- entrer dans la première session en cours du terminal requérant déclenchée dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
Un objet de l’invention est aussi un procédé d’administration d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’administration d’accès comportant
- émettre une acceptation d’un des terminaux participants suite à une réception d’un message de demande d’accès reçu par au moins un terminal participant de la première session du terminal requérant, l’acceptation envoyée déclenchant, dès réception, une entrée dans la première session en cours du terminal requérant. Avantageusement, selon une implémentation de l'invention, les différentes étapes du procédé selon l'invention sont mises en œuvre par un logiciel ou programme d'ordinateur, ce logiciel comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif faisant partie d’une architecture de communication et étant conçus pour commander l'exécution des différentes étapes de ce procédé.
L'invention vise donc aussi un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès à une première session de communication sécurisée et/ou du procédé de demande d’accès et/ou du procédé d’administration d’accès lorsque ledit programme est exécuté par un processeur.
Ce programme peut utiliser n'importe quel langage de programmation et être sous la forme de code source, code objet ou 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.
Un objet de l’invention est encore un dispositif de gestion d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le dispositif de gestion d’accès comportant
- un contrôleur apte à déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
Un objet de l’invention est également un terminal de communication requérant, dit terminal requérant, apte à demander un accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le terminal requérant comportant
- un connecteur apte à entrer le terminal requérant dans la première session en cours, le connecteur étant déclenché dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
Avantageusement, le terminal requérant comportant
- un générateur d’un message de demande d’accès apte à être émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
Un objet de l’invention est en outre un terminal de communication participant, dit terminal participant, à une première session de communication sécurisée dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, le terminal participant comportant
- un connecteur apte à établir la première session entre le terminal participant et au moins un autre terminal participant,
- un validateur apte à accepter un accès à la première session suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session, le validateur déclenchant une entrée dans la première session en cours du terminal requérant.
Avantageusement, le terminal participant comportant
- un connecteur apte à établir une deuxième session de communication synchrone avec le terminal requérant préalablement à l’acceptation par le validateur.
Brève description des dessins
Les caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description, faite à titre d'exemple, et des figures s’y rapportant qui représentent :
[Fig 1a] Figure 1a, un schéma simplifié d’un procédé de gestion d’accès à une première session de communication sécurisée,
[Fig. 1b] Figure 1b, un schéma simplifié d’un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention,
[Fig. 2] Figure 2, un schéma simplifié d’un procédé de demande d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention,
[Fig. 3] Figure 3, un schéma simplifié d’un procédé d’administration d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention,
[Fig. 4] Figure 4, un schéma simplifié d’un diagramme d’échanges dans une architecture de communication mettant en œuvre un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention,
[Fig. 5] Figure 5, un schéma simplifié d’une architecture de communication comportant un dispositif de gestion d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention,
[Fig 6a] Figure 6a, un schéma simplifié d’utilisation d’un procédé de gestion d’accès dans un cas d’usage particulier de l’invention,
[Fig. 6b] Figure 6b, un schéma simplifié d’utilisation d’une éventuelle première étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a,
[Fig. 6c] Figure 6c, un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a,
[Fig. 6d] Figure 6d, un schéma simplifié d’utilisation d’un procédé d’administration d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a,
[Fig. 6e] Figure 6e, un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a. Description des modes de réalisation
Les figures 1a et 1b illustrent un procédé de gestion d’accès à une première session de communication sécurisée. La figure 1a montre le procédé de gestion d’accès tel qu’il peut exister dans l’art antérieur. La figure 1b montre des étapes qui peuvent être intégrées seules ou en combinaison au procédé de gestion de la figure 1a suite à l’établissement de la première session.
La figure 1a illustre donc un schéma simplifié d’un procédé de gestion d’accès à une première session de communication sécurisée.
Le procédé de gestion d’accès à la première session de communication sécurisée SSix_MNGT comporte un établissement de la première session de communication sécurisée SSix_STB, notamment, suite à une requête d’établissement d’une session de communication sécurisée ssix_oreq d’un premier terminal de communication participant TPi. Le premier terminal de communication participant TPi est un terminal de communication de la liste de participants associée à la première session de communication sécurisée SSix. Dans ce cas particulier, l’établissement de la première session SSix_STB implique un accès du premier terminal participant TP1 à la première session SSix.
En particulier, le procédé de gestion d’accès SSix_MNGT comporte une fourniture SSix_SACC d’un accès sécurisé à la première session SSix à au moins un terminal participant de la liste 7 n ne[2 iV] sur demande ultérieurement d’un accès sécurisé ssix_sreq à la première session par le au moins un terminal participant de la liste TRh hf N]
Suite à la fourniture d’un accès sécurisé à la première session SSix_SACC, le au moins un terminal participant TPn accède à la première session SSix. Les terminaux participants TPi, {TPn}n accédant à la première session SSix échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SSix.
Le procédé de gestion SS1X_MNGT est mis en œuvre
- soit par un dispositif de gestion distinct des terminaux participants TPn, notamment implémenté dans un serveur de communication d’un réseau de communication ;
- soit par un dispositif de gestion implémenté dans le terminal administrateur de la première session ;
- soit par un dispositif de gestion implémenté dans le premier terminal participant TPi ayant requis l’établissement de la première session.
Un mode de réalisation particulier du procédé de gestion SS1X_MNGT est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé de gestion SSix_MNGT lorsque ledit programme est exécuté par un processeur. La figure 1b illustre un schéma simplifié d’un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention.
Le procédé d’accès SSix_ACC est un procédé d’accès à une première session de communication sécurisée SSix dite première session, en cours entre des terminaux de communications participants {TPn}n=1...N, dit terminaux participants, par un terminal de communication requérant TR, dit terminal requérant. Le procédé d’accès SSix_ACC comporte
- déclencher une entrée ENT_TRG dans la première session SSix en cours du terminal requérant TR dès réception d’une acceptation OK_REC d’un des terminaux participants TP, suite à une transmission DAC_TR d’un message de demande d’accès dacc_mssg émis par le terminal requérant TR à destination d’au moins un terminal participant de la première session
Dans le cas où l’accès à la première session de communication sécurisée est conditionné à l’appartenance à une liste de terminaux de communication participants associée à cette première session pour sécuriser la première session (par exemple, éviter que des terminaux tiers, c’est-à-dire n’appartenant pas à cette liste accèdent aux échanges effectués durant cette première session), le terminal requérant est notamment un terminal de communication n’appartenant pas à la liste de participants associée à la première session de communication sécurisée.
Dans le cas où, poursécuriser la première session, les terminaux participants doivent en outre fournir un code d’accès pour être autorisé à accéder à la première session, le terminal requérant peut aussi être un des terminaux participants ne disposant pas du code d’accès lors de sa demande d’accès : soit que l’utilisateur du terminal d’accès est oublié le code d’accès à la première session, soit que le code d’accès préalablement enregistré par le terminal requérant ait été perdu, soit que le code d’accès soit fourni à l’utilisateur du terminal requérant sur un terminal de communication de l’utilisateur du terminal requérant distinct du terminal requérant dont l’utilisateur ne dispose pas au moment de la demande d’accès (en particulier, le terminal requérant est un ordinateur ou une tablette au moyen duquel un utilisateur demande l’accès à un espace collaboratif par exemple alors qu’il est en déplacement, cet espace collaboratif envoi au téléphone mobile de l’utilisateur un code d’accès. Si l’utilisateur a oublié son téléphone mobile, par exemple chez lui, il ne pourra pas accédé à cet espace.).
En particulier, le procédé d’accès SSix_ACC comporte
- recevoir l’acceptation OK_REC d’un terminal participant TPi.
En particulier, le procédé d’accès SSix_ACC comportant :
- recevoir DACC_REC une requête d’accès acc_req d’un terminal requérant TR, la requête d’accès acc_req comportant le message de demande d’accès dacc_mssg, et
- émettre DACC_TR le message de demande d’accès dacc_mssg à destination d’au moins un terminal participants de la première session En particulier, l’émission DACC_TR du message de demande d’accès à destination du au moins un terminal participant de la première session SSix comporte:
- diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session.
Dans un mode de réalisation alternatif, l’émission DACC_TR du message de demande d’accès à destination du au moins un terminal participant de la première session SSix comporte:
- émettre le message par communication asynchrone à destination d’au moins un des terminaux participants.
En particulier, l’émission DACC_TR du message de demande d’accès à destination du au moins un terminal participant de la première session SSix comporte:
- émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session.
En particulier, le message de demande d’accès dacc_mssg comporte au moins une données parmi les données suivantes :
- une donnée sonore courte d’avertissement, notamment un jingle, une sonnerie, un timbre avertissement..., tel qu’un gong d’entrée, un dring de sonnette d’entrée, une donnée audio correspond à un « toc toc » à une porte, etc. ;
- un identifiant associé au terminal requérant, tel qu’un numéro de téléphone, un identifiant IMEI, etc. un nom, pseudonyme ou adresse email d’un utilisateur du terminal requérant, etc. ;
- un identifiant associé à un terminal participant à la session de communication sécurisée,
- un identifiant de la première session à laquelle le terminal requérant demande l’accès,
- un message textuel, audio ou vidéo d’un utilisateur du terminal requérant.
En particulier, le procédé d’accès SSix_ACC comporte
- établir SS2_STB, préalablement au déclenchement de l’entrée ENT_TRG dans la première session SSix du terminal requérant TR, une deuxième session SS2 de communication synchrone entre le terminal requérant TR et un des terminaux participants TPi à la première session sur requête d’établissement ss2_req dudit un des terminaux participants TPi suite à une transmission DACC_TR d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication.
Alors, le procédé d’accès SS1X_ACC comporte, en particulier, une mise en œuvre d’une communication SS2_COM via la deuxième session SS2 entre le terminal participant TPi et le terminal requérant TR. Ils peuvent ainsi échanger notamment des messages ss2_mssgi, ss2_mssg2... Par ces échanges, le terminal participant TPi et/ou l’utilisateur du terminal participant TPi peut demander au terminal requérant TR et/ou à l’utilisateur du terminal requérant TR des informations complémentaires. Par exemple, lorsque seul le numéro de téléphone du terminal requérant est fourni par le message de demande d’accès dacc_mssg, le terminal participant TPi et/ou son utilisateur peut demander le nome de l’utilisateur du terminal requérant et d’éventuelles autres informations sur le terminal requérant (capacités techniques par exemple pour vérifier sa compatibilité pour accéder à tout ou partie de la première session - contenu, type de communication vidéo, etc.) ou sur l’utilisateur du terminal requérant (rattachement à une école, un niveau scolaire, une entreprise, une équipe, etc. ; compétences ; âge, etc.). Les informations complémentaires permettront à l’utilisateur du terminal participant TPi ou au terminal participant de mettre en œuvre un procédé de décision pour accepter ou non la demande d’accès du terminal requérant.
En particulier, le procédé d’accès SSix_ACC comporte
- clore SS2_CL la deuxième session dès mise en œuvre par le procédé d’accès SSix_ACC d’une étape parmi les suivantes :
+ la réception d’une acceptation OK_REC par le terminal participant TPi de la deuxième session SS2,
+ le déclenchement de l’entrée ENT_TRG dans la première session SSix du terminal requérant TR.
En particulier, la réception d’une acceptation OK_REC ou le déclenchement de l’entrée ENT_TRG commande ss2_stp la clôture de la deuxième session SS2_CL.
En particulier, le procédé de d’accès SSix_ACC comporte gérer une deuxième session de communication SS2_MNGT, dite deuxième session, distincte de la première session. La deuxième session SS2 permet au terminal requérant TR d’échanger avec au moins un terminal participant à la première session TPi. La gestion d’une deuxième session SS2_MNGT comporte notamment la mise en œuvre de la communication SS2_COM via la deuxième session SS2 entre le terminal participant TPi et le terminal requérant TR.
En particulier, la gestion d’une deuxième session SS2_MNGT comporte établir la deuxième session SS2_STB et/ou clore la deuxième session SS2_CL.
En particulier, les étapes de la gestion d’une deuxième session SS2_MNGT sont mises en œuvre par le procédé d’accès SSix_ACC.
Suite au déclenchement de l’entrée ENT_TRG dans la première session SSix du terminal requérant TR, le terminal requérant TR accède à la première session SSix. Les terminaux participants TPi, {TPn}n et le terminal requérant TR accédant à la première session SSix échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SSix. En particulier, le procédé d’accès SSix_ACC est implémenté dans le procédé de gestion d’accès SSix_MNGT, notamment tel qu’illustré dans la figure 1a, suite à l’établissement de la première session SSix_STB.
Dans un mode de réalisation particulier, le procédé de gestion SSix_MNGT comporte créer une première session de communication sécurisée SSix_CREA préalablement à son établissement SSix_STB. La création SSix_CREA de la première session est effectuée sur demande d’un terminal participant dit administrateur de la première session, par exemple le premier terminal participant TPi. Lors de cette création SSix_CREA est générée une liste de participants dont au moins un identifiant associé à chacun des participants est fourni par le terminal administrateur. L’identifiant associé à un participant est notamment un identifiant relatif à un utilisateur participant disposant d’un terminal de communication au moyen duquel accédé à la première session et/ou un terminal de communication participant. Par exemple, lors de la création d’une première session pour une conférence téléphonique (audioconférence ou visioconférence), les identifiants des participants sont notamment des numéros des téléphones participants. Autre exemple, lors de la création d’une première session pour un espace collaboratif permettant à la fois des échanges textuels et/ou audio et/ou vidéo en plus d’un partage de contenu(s), les identifiants des participants sont notamment des adresses email des utilisateurs participants.
Une fois la première session créée, le procédé de gestion SSix_MNGT établit la première session SSix_STB soit (première option) automatiquement à une date et/ou un horaire de début de session associé(e)(s) à la première session, soit (deuxième option) dès réception par le procédé de gestion SSix_MNGT d’une requête de première session ssix_oreq d’un premier terminal participant TPi, etc. L’exemple de la figure 1a correspond à cette deuxième option.
En particulier, le procédé de gestion SSix_MNGT vérifie que la requête de première session ssix_oreq provienne du terminal administrateur ayant contribué à création de la première session avant d’établir la première session SSix_STB.
Une fois la première session établit, le procédé de gestion SSix_MNGT fournit un accès sécurisé SSix_SACC à la première session à un terminal de communication participant, dit terminal participant, dès demande d’accès sécurisée ssix_sreq par un terminal participant TPn. Par terminal participant est, notamment, entendu un terminal de communication dont un identifiant fait partie de la liste des participants associée à la première session ou dont l’utilisateur a un identifiant qui fait partie de la liste des participants associée à la première session.
En particulier, la fourniture d’accès à la première session SSix_SACC comporte vérifier si le terminal de communication dont provient la demande d’accès sécurisée ssix_sreq est un terminal de communication relatif à l’un des participant de la liste des participants. Par un terminal relatif à l’un des participants de la liste des participant est notamment entendu un terminal correspondant à un des terminaux de la liste des participants (lorsque cette liste comportant des identifiants de terminaux) et/ou un terminal dont dispose un utilisateur correspondant à un des utilisateurs de la liste des participants (lorsque cette liste comporte des identifiants relatifs à des utilisateurs : adresse email, nom, pseudo, etc.)... Il est à noter que la liste des participants peut aussi comporter à la fois des identifiants de terminaux (numéro de téléphone, adresse IP, IMEI...), des identifiants d’utilisateurs (adresse email, nom, pseudo, etc.)...
En particulier, le procédé de gestion SSix_MNGT active le procédé d’accès SSix_ACC dès qu’au moins un terminal participant TPi accède à la première session, soit le terminal administrateur lorsque la première session est établit SSix_STB à sa demande ssix_oreq ou tout autre terminal participant TPn, n=i ...N lorsque la première session est établit automatiquement par exemple à une heure donnée.
Le déclenchement de l’entrée ENT_TRG d’un terminal requérant TR mis en œuvre par le procédé d’accès SSix_ACC résulte d’une acception ok cmd par un terminal participant TPi suite à une transmission d’un message de demande d’accès dacc_mssg par le terminal requérant TR.
En particulier, le procédé d’accès SSix_ACC comporte recevoir DACC_REC une requête d’accès acc_req(dacc_mssg) du terminal requérant puis transmettre DACC_TR le message de demande d’accès dacc_mssg à au moins un terminal participant TPi. Ainsi, si le terminal requérant TR ne connaît pas les terminaux participants TPn, ni leurs utilisateurs UPn, sa demande d’accès sera tout de même étudiée voire acceptée et, dans ce cas, il accédera tout de même à la première session SSix.
De manière alternative, à condition que le terminal requérant TR connaisse au moins un terminal participant TPi ou un utilisateur participant UPi (doté d’un terminal participant TPi) à la première session SSix, la requête d’accès acc_req est transmise directement du terminal requérant TR au terminal participant TPi ou à l’utilisateur participant UPi (doté d’un terminal participant TPi). Et, le terminal participant TPi acceptant la demande d’accès commande directement ou indirectement ok cmd le déclenchement ENT_TRG par le procédé d’accès SSix_ACC de l’entrée du terminal requérant TR dans la première session SSix.
En particulier, le déclenchement ENT_TRG est commandé directement ok cmd par le terminal participant TPi. De manière alternative, le procédé d’accès SSix_ACC comporte recevoir OK_REC une acceptation ok cmd du terminal participant TPi. La réception d’une acceptation OK_REC commande ent_ok le déclenchement de l’entrée dans la première session ENT_TRG.
Eventuellement, l’acceptation ok_cmd comporte, outre la validation de l’entrée dans la première session SS1X du terminal requérant (par exemple, sous la forme d’un identifiant associé au terminal requérant et, éventuellement, d’un identifiant de la première session), des données relatives à l’accès accordé. Par exemple, l’accès à la première session SSix pour le terminal requérant TR peut être :
- total, c’est-à-dire identique aux accès accordés aux autres participants ;
- un accès d’une catégorie prédéfinie, telle que la catégorie invité, ou nième catégorie (notamment lorsque les participants sont déjà eux-mêmes divisé en plusieurs catégories pour des accès différenciés : accès en:
+ échanges textuels et/ou audio et/ou vidéo, et/ou + lecture, et/ou en écriture de contenus, et/ou + partage ou non de contenus) ;
- limité (accès en échange textuel uniquement, et écoute/visualisation des échanges des terminaux participants et/ou accès en lecture aux contenus partagés, sans partage de document par le terminal requérant), etc.
Dans un mode de réalisation particulier, éventuellement complémentaire au mode de réalisation particulier précédent, le(s) termina(l)(ux) participant(s) TPi ayant reçu le message de demande d’accès dacc_mssg du terminal requérant TR peut échanger de manière synchrone ou asynchrone avec le terminal requérant TR préalablement à l’acceptation ok cmd. Le(s) termina(l)(ux) participant(s) TPi peu(ven)t notamment envoyer au terminal requérant un premier message mssgl
En particulier, le premier message mssgl du(d’un des) termina(l)(ux) participant(s) TPi comporte une requête relative au terminal requérant TR notamment à ses capacités en terme de périphérique (caméra, microphone, taille d’écran, etc.), en terme de mémoire, en terme de traitements (logiciels, plug-in...), etc. et/ou à l’utilisateur du terminal requérant (identité, localisation, âge, compétence(s), niveau dans la(les) compétence(s), etc.). Dans ce cas, le terminal requérant TR peut transmettre en retour ou en réponse un deuxième message mssg2 comportant notamment une ou des réponses aux requêtes du premier message mssgl L’échange peut se poursuivre par des messages supplémentaires entre le(s) termina(l)(ux) participant(s) TPi et le terminal requérant TR. Notamment, l’échange est clos notamment par l’acception ok cmd par un des terminaux participants TPi échangeant avec le terminal requérant TR.
En particulier, un des messages mssg provenant du terminal participant TPi comporte la commande d’acceptation ok cmd. Dans ce dernier cas, le terminal requérant TR commande ok cmd le déclenchement de son entrée dans la première session ENT_TRG en transmettant la commande d’acceptation contenue dans le premier message mssgl vers le procédé d’accès SSix_ACC.
Un mode de réalisation particulier du procédé d’accès SSix_ACC est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès SSix_ACC lorsque ledit programme est exécuté par un processeur. Un mode de réalisation particulier du procédé de gestion SS1X_MNGT est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé de gestion SSix_MNGT et du procédé d’accès SSix_ACC lorsque ledit programme est exécuté par un processeur.
La figure 2 illustre un schéma simplifié d’un procédé de demande d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention.
Le procédé de demande d’accès SSix_DACC est un procédé de demande d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants TPi, dit terminaux participants, par un terminal de communication requérant TR, dit terminal requérant. Le procédé de demande d’accès SSix_DACC comporte
- entrer SSix_ENT dans la première session en cours SSix du terminal requérant TR déclenchée acc_cmd dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant TR à destination d’au moins un terminal participant TPi de la première session.
En particulier, le procédé de demande d’accès SSix_DACC comporte :
- émettre DACC_EM une requête d’accès acc_req du terminal requérant TR à destination d’au moins un terminal participant de la première session SSix, la requête d’accès acc_req comportant le message de demande d’accès dacc_mssg.
En particulier, l’émission DACC_EM du message de demande d’accès à destination du au moins un terminal participant de la première session SSix comporte:
- diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session.
Dans un mode de réalisation alternatif, l’émission DACC_EM du message de demande d’accès à destination du au moins un terminal participant de la première session SSix comporte:
- émettre le message par communication asynchrone à destination d’au moins un des terminaux participants.
En particulier, l’émission DACC_EM du message de demande d’accès à destination du au moins un terminal participant de la première session SSix comporte:
- émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session.
En particulier, le message de demande d’accès dacc_mssg comporte au moins une données parmi les données suivantes :
- une donnée sonore courte d’avertissement, notamment un jingle, une sonnerie, un timbre avertissement..., tel qu’un gong d’entrée, un dring de sonnette d’entrée, une donnée audio correspond à un « toc toc » à une porte, etc. ;
- un identifiant associé au terminal requérant, tel qu’un numéro de téléphone, un identifiant IMEI, etc. un nom, pseudonyme ou adresse email d’un utilisateur du terminal requérant, etc. ;
- un identifiant associé à un terminal participant à la session de communication sécurisée,
- un identifiant de la première session à laquelle le terminal requérant demande l’accès,
- un message textuel, audio ou vidéo d’un utilisateur du terminal requérant.
En particulier, le procédé de demande d’accès SSix_DACC comporte
- connecté SS2_CNX le terminal requérant TR, préalablement à l’entrée SSix_ENT dans la première session SSix du terminal requérant TR, à une deuxième session SS2 de communication synchrone établie avec un des terminaux participants TPi à la première session suite à l’émission DACC_EM du message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication.
Alors, le procédé de demande d’accès SS1X_DACC comporte, en particulier, une mise en œuvre d’une communication SS2_COM via la deuxième session SS2 entre le terminal participant TPi et le terminal requérant TR. Ils peuvent ainsi échanger notamment des messages ss2_mssgi, ss2_mssg2... Par ces échanges, le terminal participant TPi et/ou l’utilisateur du terminal participant TPi peut demander au terminal requérant TR et/ou à l’utilisateur du terminal requérant TR des informations complémentaires. Par exemple, lorsque seul le numéro de téléphone du terminal requérant est fourni par le message de demande d’accès dacc_mssg, le terminal participant TPi et/ou son utilisateur peut demander le nome de l’utilisateur du terminal requérant et d’éventuelles autres informations sur le terminal requérant (capacités techniques par exemple pour vérifier sa compatibilité pour accéder à tout ou partie de la première session - contenu, type de communication vidéo, etc.) ou sur l’utilisateur du terminal requérant (rattachement à une école, un niveau scolaire, une entreprise, une équipe, etc. ; compétences ; âge, etc.). Les informations complémentaires permettront à l’utilisateur du terminal participant TPi ou au terminal participant de mettre en œuvre un procédé de décision pour accepter ou non la demande d’accès du terminal requérant.
En particulier, le procédé de demande d’accès SSix_DACC comporte
- déconnecter SS2_DCNX de la deuxième session du terminal requérant dès clôture de la deuxième session par un procédé de gestion de la deuxième session SS2_MNGT suite à:
+ une acceptation OK_REC de l’entrée dans la première session SSix du terminal requérant TR par le terminal participant TPi de la deuxième session SS2,
+ l’entrée ENT_TRG dans la première session SSix du terminal requérant TR.
En particulier, le procédé de demande d’accès SS1X_DACC comporte participer en tant qu’appelant SS2_CE à une deuxième session de communication, dite deuxième session, distincte de la première session. La deuxième session SS2 permet au terminal requérant TR d’échanger avec au moins un terminal participant à la première session TPi. La participation en tant qu’appelant à une deuxième session SS2_CE comporte notamment la mise en œuvre de la communication SS2_COM via la deuxième session SS2 entre le terminal participant TPi et le terminal requérant TR.
En particulier, la participation en tant qu’appelant à une deuxième session SS2_CE comporte connecter SS2_CNX et/ou déconnecter SS2_DCNX le terminal requérant TR de la deuxième session SS2.
En particulier, les étapes de la participation en tant qu’appelant à une deuxième session SS2_CE sont mises en œuvre par le procédé de demande d’accès SSix_DACC.
Suite à l’entrée SS1X_ENT dans la première session SSix du terminal requérant TR, le terminal requérant TR accède à la première session SSix. Les terminaux participants TPi , {TPn}n et le terminal requérant TR accédant à la première session SSix échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SSix.
Dans un mode de réalisation particulier, l’entrée SSix_ENT d’un terminal requérant TR résulte d’une acception acc_cmd par un terminal participant TPi suite à une émission d’un message de demande d’accès dacc_mssg par le terminal requérant TR.
En particulier, le procédé de demande d’accès SSix_DACC comporte émettre DACC_EM une requête d’accès acc_req(dacc_mssg) du terminal requérant à destination d’au moins un terminal participant TPi notamment via le procédé d’accès SSix_ACC.
De manière alternative, à condition que le terminal requérant TR connaisse au moins un terminal participant TPi ou un utilisateur participant UPi (doté d’un terminal participant TPi) à la première session SSix, la requête d’accès acc_req est transmise directement du terminal requérant TR au terminal participant TPi ou à l’utilisateur participant UPi (doté d’un terminal participant TPi). Et, le terminal participant TPi acceptant la demande d’accès commande directement ou indirectement (notamment, via le procédé d’accès SSix_ACC) ok cmd l’entrée dans la première session du terminal requérant SS1X_ENT
En particulier, l’entrée SSix_ENT est commandée directement acc_cmd par le terminal participant TPi. De manière alternative, le procédé d’accès SSix_ACC recevant une acceptation ok cmd du terminal participant TPi commande acc_cmd l’entrée SSix_ENT.
Dans un mode de réalisation particulier, éventuellement complémentaire au mode de réalisation particulier précédent, le(s) termina(l)(ux) participant(s) TPi ayant reçu le message de demande d’accès dacc_mssg du terminal requérant TR peu(ven)t échanger de manière synchrone ou asynchrone avec le terminal requérant TR préalablement à l’acceptation déclenchant la commande d’entrée acc_cmd. Le terminal requérant TR peut notamment recevoir SS2_REC d(u)(es) termina(l)(ux) participant(s) TPi un premier message mssgl , notamment via une deuxième session SS2- le premier message mssgl est alors, par exemple, relayé du terminal participant TPi au terminal requérant TR par une gestion de la deuxième session SS2_MNGT.
En particulier, le premier message mssgl comporte une requête relative au terminal requérant TR notamment à ses capacités en termes de périphérique (caméra, microphone, taille d’écran, etc.), en termes de mémoire, en termes de traitements (logiciels, plug-in...), etc. et/ou à l’utilisateur du terminal requérant (identité, localisation, âge, compétence(s), niveau dans la(les) compétence(s), etc.). Dans ce cas, le terminal requérant TR peut émettre SS2_EM en retour ou en réponse un deuxième message mssg2 comportant notamment une ou des réponses aux requêtes du premier message mssgl , notamment via la deuxième session SS2 si le premier message mssgl a été transmis via celle-ci - le deuxième message mssg2 est alors, par exemple, relayé du terminal requérant TR au terminal participant TPi par la gestion de la deuxième session SS2_MNGT. L’échange peut se poursuivre par des messages supplémentaires entre le(s) termina(l)(ux) participant(s) TPi et le terminal requérant TR. Notamment, l’échange est clos notamment par la commande d’acception acc_cmd par un des terminaux participants TPi échangeant avec le terminal requérant TR.
En particulier, un des messages mssg provenant du terminal participant TPi comporte la commande d’acceptation acc_cmd, ok cmd. Dans ce dernier cas, le terminal requérant TR commande acc_cmd son entrée dans la première session SSix_ENT en transmettant la commande d’acceptation acc_cmd, ok cmd contenue dans le message reçu mssg soit directement à l’entrée SS1X_ENT soit vers le procédé d’accès SSix_ACC.
Un mode de réalisation particulier du procédé de demande d’accès SSix_DACC est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé de demande d’accès SSix_DACC lorsque ledit programme est exécuté par un processeur.
La figure 3 illustre un schéma simplifié d’un procédé d’administration d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention.
Le procédé d’administration d’accès SSix_ADM administre un accès à une première session de communication sécurisée SSix, dite première session, en cours entre des terminaux de communications participants TPn, dit terminaux participants, par un terminal de communication requérant TR, dit terminal requérant. Le procédé d’administration d’accès SSix_ADM comporte - émettre une acceptation OK_EM d’un des terminaux participants TPi suite à une réception d’un message de demande d’accès dacc_mssg reçu par au moins un terminal participant TPi de la première session du terminal requérant TR à destination, l’acceptation ok cmd envoyée déclenchant, dès réception, une entrée dans la première session en cours du terminal requérant.
En particulier, le procédé d’administration d’accès SSix_ADM comporte :
- recevoir DACC_REC un message de demande d’accès dacc_mssg d’un terminal requérant TR. Notamment, la réception DACC_REC est une réception d’une requête d’accès acc_req comportant le message de demande d’accès dacc_mssg Eventuellement, le message de de demande d’accès dacc_mssg est relayé par un procédé d’accès SS1X_ACC, par exemple tel que décrit en lien avec la figure 1 b.
En particulier, le message de demande d’accès dacc_mssg comporte au moins une données parmi les données suivantes :
- une donnée sonore courte d’avertissement, notamment un jingle, une sonnerie, un timbre avertissement..., tel qu’un gong d’entrée, un dring de sonnette d’entrée, une donnée audio correspond à un « toc toc » à une porte, etc. ;
- un identifiant associé au terminal requérant, tel qu’un numéro de téléphone, un identifiant IMEI, etc. un nom, pseudonyme ou adresse email d’un utilisateur du terminal requérant, etc. ;
- un identifiant associé à un terminal participant à la session de communication sécurisée,
- un identifiant de la première session à laquelle le terminal requérant demande l’accès,
- un message textuel, audio ou vidéo d’un utilisateur du terminal requérant.
En particulier, l’émission de l’acceptation OK_EM est activé ok_act par l’utilisateur participant UPi disposant du terminal participant TPi mettant en œuvre le procédé d’administration d’accès SSix ADM.
A titre d’exemple, le message de demande d’accès dacc_mssg comporte un gong d’entrée et le nom de l’utilisateur requérant UR du terminal requérant TR. Le message de demande d’accès dacc_mssg sera reproduit par le terminal participant TPi. Et, l’utilisateur participant UPi disposant du terminal participant TPi effectuera une action d’approbation ok_act: approbation orale, appui sur une touche OK sur un clavier physique ou virtuel, hochement de tête. Le procédé d’administration d’accès SSix_ADM comporte éventuellement une capture UP_CPT de l’action d’approbation ok_act qui active l’émission de l’acceptation OK_EM.
En particulier, le procédé d’administration d’accès SSix_ADM comporte
- requérir SS2_STBR un établissement, préalablement au déclenchement de l’entrée ENT_TRG dans la première session SSix du terminal requérant TR, d’une deuxième session SS2 de communication synchrone entre le terminal requérant TR et un des terminaux participants TPi à la première session sur requête d’établissement ss2_req dudit un des terminaux participants TPi suite à la réception DACC_REC du message de demande d’accès émis par le terminal requérant TR. Alors, le procédé d’administration d’accès SSix_ADM comporte, en particulier, une mise en œuvre d’une communication SS2_COM via la deuxième session SS2 entre le terminal participant TPi et le terminal requérant TR. Ils peuvent ainsi échanger notamment des messages ss2_mssgi, ss2_mssg2... Par ces échanges, le terminal participant TPi et/ou l’utilisateur du terminal participant TPi peut demander au terminal requérant TR et/ou à l’utilisateur du terminal requérant TR des informations complémentaires. Les informations complémentaires permettront à l’utilisateur du terminal participant TPi ou au terminal participant de mettre en œuvre un procédé de décision pour accepter ou non la demande d’accès du terminal requérant.
En particulier, le procédé d’administration d’accès SSix_ADM comporte
- déconnecter SS2_DCNX le terminal participant TPi de la deuxième session SS2 dès mise en œuvre par le procédé d’accès SSix_ACC d’une étape parmi les suivantes :
+ la réception d’une acceptation OK_REC par le terminal participant TPi de la deuxième session SS2,
+ le déclenchement de l’entrée ENT_TRG dans la première session SSix du terminal requérant TR.
En particulier, le procédé d’administration d’accès SSix_ADM comporte participer en tant qu’appelant SS2_CG à une deuxième session de communication, dite deuxième session, distincte de la première session. La deuxième session SS2 permet au terminal participant TPi d’échanger avec le terminal requérant. La participation en tant qu’appelant à une deuxième session SS2_CG comporte notamment la mise en œuvre de la communication SS2_COM via la deuxième session SS2 entre le terminal participant TPi et le terminal requérant TR.
En particulier, la participation en tant qu’appelant à une deuxième session SS2_CG comporte requérir l’établissement de la deuxième session SS2_STBR et/ou déconnecter le terminal participant TPi de la deuxième session SS2_DCNX.
En particulier, les étapes de la participation en tant qu’appelant à une deuxième session SS2_CG sont mises en œuvre par le procédé d’administration d’accès SSix_ADM.
Suite au l’émission de l’acceptation OK_EM déclenchant, par le procédé d’accès SSix_ACC, l’entrée ENT_TRG dans la première session SSix du terminal requérant TR, le terminal requérant TR accède à la première session SSix. Les terminaux participants TPi, {TPn}n et le terminal requérant TR accédant à la première session SSix échangent entre eux des données tels que des messages textuels, des communications audio et/ou vidéo, des contenus, etc. via cette première session SSix.
Le déclenchement de l’entrée ENT_TRG d’un terminal requérant TR mis en œuvre par le procédé d’accès SSix_ACC résulte d’une émission OK_EM, par un terminal participant TPi, d’une acception ok cmd reçue, notamment par le procédé d’accès SS1X_ACC, suite à une transmission d’un message de demande d’accès dacc_mssg par le terminal requérant TR. En particulier, le procédé d’administration d’accès SSix_ADM comporte recevoir DACC_REC un message de demande d’accès dacc_mssg d’un terminal requérant TR, notamment sous la forme d’une requête d’accès acc_req(dacc_mssg) du terminal requérant comportant le message de demande d’accès dacc_mssg.
En particulier, le message de demande d’accès dacc_mssg reçu DACC_REC par le procédé d’administration d’accès SSix_ADM est envoyé par un procédé de demande d’accès SSix_DACC tel que décrit notamment en lien à la figure 2 et relayé (c’est-à-dire reçu du terminal requérant puis émis vers au moins un terminal participant TPi) par un procédé d’accès SSix_ACC tel que décrit notamment en lien avec la figure 1b.
De manière alternative, à condition que le terminal requérant TR connaisse au moins un terminal participant TPi ou un utilisateur participant UPi (doté d’un terminal participant TPi) à la première session SSix, la requête d’accès acc_req est reçu DACC_REC directement par le terminal participant TPi du terminal requérant TR. Et, le terminal participant TPi acceptant la demande d’accès commande directement ou indirectement ok cmd le déclenchement ENT_TRG par le procédé d’accès SSix_ACC de l’entrée du terminal requérant TR dans la première session SSix.
En particulier, le déclenchement ENT_TRG est commandé directement ok cmd par le terminal participant TPi par une émission OK_EM de l’acception au procédé d’accès SSix_ACC. De manière alternative, le procédé d’accès SSix_ACC comporte recevoir OK_REC une acceptation ok cmd du terminal participant TPi. La réception d’une acceptation OK_REC commande ent_ok le déclenchement de l’entrée dans la première session ENT_TRG.
Eventuellement, l’acceptation OK_EM comporte, outre une validation de l’entrée dans la première session SS1X du terminal requérant ok_cmd{ SSix,TR) (par exemple, sous la forme d’un identifiant associé au terminal requérant et, éventuellement, d’un identifiant de la première session), des données relatives à l’accès accordé ok_cmd{ SSix,TR,acc_tyTR). Par exemple, l’accès acc_tyTR à la première session SSix pour le terminal requérant TR peut être :
- total, c’est-à-dire identique aux accès accordés aux autres participants ;
- un accès d’une catégorie prédéfinie, telle que la catégorie invité, ou nième catégorie (notamment lorsque les participants sont déjà eux-mêmes divisé en plusieurs catégories pour des accès différenciés : accès en:
+ échanges textuels et/ou audio et/ou vidéo, et/ou + lecture, et/ou en écriture de contenus, et/ou + partage ou non de contenus) ;
- limité (accès en échange textuel uniquement, et écoute/visualisation des échanges des terminaux participants et/ou accès en lecture aux contenus partagés, sans partage de document par le terminal requérant), etc. Dans un mode de réalisation particulier, éventuellement complémentaire au mode de réalisation particulier précédent, le terminal participant TPi ayant reçu le message de demande d’accès dacc_mssg du terminal requérant TR peut échanger de manière synchrone ou asynchrone avec le terminal requérant TR préalablement à l’émission OK_EM de l’acceptation ok cmd. Le terminal participant TPi peut notamment envoyer au terminal requérant un premier message mssgl .
En particulier, le premier message mssgl du terminal participant TPi comporte une requête relative au terminal requérant TR notamment à ses capacités en terme de périphérique (caméra, microphone, taille d’écran, etc.), en terme de mémoire, en terme de traitements (logiciels, plug-in...), etc. et/ou à l’utilisateur du terminal requérant (identité, localisation, âge, compétence(s), niveau dans la(les) compétence(s), etc.). Dans ce cas, le terminal requérant TR peut transmettre en retour ou en réponse un deuxième message mssg2 comportant notamment une ou des réponses aux requêtes du premier message mssgl L’échange peut se poursuivre par des messages supplémentaires entre le terminal participant TPi et le terminal requérant TR. Notamment, l’échange est clos notamment par l’acception ok cmd par le terminal participant TPi échangeant avec le terminal requérant TR.
En particulier, un des messages mssg provenant du terminal participant TPi comporte la commande d’acceptation ok cmd. Dans ce dernier cas, le terminal requérant TR commande ok cmd le déclenchement de son entrée dans la première session ENT_TRG en transmettant la commande d’acceptation contenue dans le premier message mssgl vers le procédé d’accès SSix_ACC.
Un mode de réalisation particulier du procédé d’administration d’accès SSix_ADM est un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’administration d’accès SSix_ADM lorsque ledit programme est exécuté par un processeur.
Dans un mode de réalisation particulier de l’invention, l’invention concerne un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès à une première session de communication sécurisée et/ou du procédé de demande d’accès et/ou du procédé d’administration d’accès lorsque ledit programme est exécuté par un processeur.
La figure 4 illustre un schéma simplifié d’un diagramme d’échanges dans une architecture de communication mettant en œuvre un procédé d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention.
Le mode de réalisation de la figure 4 prévoit l’utilisation d’un serveur de communication SCOM mettant en œuvre un procédé d’accès SS1X_ACC selon l’invention, notamment un procédé d’accès SS1X_ACC tel qu’illustré par la figure 1b et/ou un procédé de gestion d’accès SS1X_MNGT implémentant éventuellement le procédé d’accès SS1X_ACC. Le serveur de communication SCOM est ou comporte un dispositif de gestion distinct des terminaux participants TPn à la première session de communication sécurisée SSix et du terminal de communication requérant TR.
Une première session de communication sécurisée SSix est établit par le serveur de communication SCOM (comme le montre la phase I de la figure 4). Notamment, le procédé de gestion d’accès SSix_MNGT mis en œuvre par le serveur de communication SCOM comporte l’établissement de la première session de communication sécurisée SSix. Eventuellement, la première session de communication sécurisée SSix est établit sur requête d’établissement de la première session ssix_oreq provenant d’un terminal participant : le premier terminal participant TPi dans le cas de la figure 4. Le premier terminal participant TP1 est notamment un terminal de communication administrateur de la première session, c’est-à-dire le terminal de communication ayant défini une liste des participants à la première session SSix et/ou le(s) type(s) d’accès autorisé(s) pour au moins un des participants (un même type d’accès prédéfini pouvant être autorisé pour un ou plusieurs voire la totalité des participants).
Le premier terminal TP1 ayant accès à la première session SSix peut préparer le travail envisagé dans la première session par exemple en y partageant des contenus c et/ou en y déposant un message d’accueil des autres participants.
A tout instant de la première session SS1X, au moins un des terminaux participants TPi, {TPn} (distincts du premier terminal dans l’exemple de la figure 4) demande ssix_sreq l’accès sécurisé à la première session au serveur de communication SCOM.
En particulier, le procédé de gestion d’accès SS1X_MNGT vérifie AUTH_V si le terminal participant en question TPi, {TPn} est autorisé à accéder à la première session SS1X préalablement à la fourniture de l’accès sécurisé SS1X_ACC à la première session ssix au terminal participant TPi, {TPn} requérant cet accès sécurisé. Cette vérification d’autorisation AUTH_V comporte notamment au moins une parmi les étapes de vérification suivante :
- vérifier LST_V si le terminal participant en question TPi, {TPn} est un terminal de la liste des participants et/ou un terminal à disposition d’un utilisateur de la liste des participants ;
- vérifier CDA_V si le code d’accès fournit par le terminal participant en question TPi, {TPn} correspond à un code d’accès à la première session.
Le serveur de communication SCOM fournit l’accès sécurisé à la première session SSix terminal participant en question TPi, {TPn} (comme le montre la phase II de la figure 4). Le premier terminal TP1 et les autres terminaux participants TPi, {TPn} ayant accès à la première session SSix peuvent alors échanger entre eux et/ou partager des contenus suivant le type de la première session de communication : conférence téléphonique, et/ou conférence textuelle ou « chat room » en anglais, et/ou conférence audio, et/ou visioconférence, et/ou espace collaboratif avec notamment partage de document en lecture et/ou écriture. Durant cette première session SSix, un terminal requérant TR peut, à tout instant, demander l’accès à la première session notamment au serveur de communication SCOM comme illustré par la figure 4. Pour cela, il émet un message de demande d’accès daccc_mssg éventuellement dans une requête d’accès acc_req. Cette émission d’un message de demande d’accès daccc_mssg par le terminal requérant est notamment une étape d’un procédé de demande d’accès SS1X_DACC (notamment tel qu’illustré par la figure 2) mis en œuvre par le terminal requérant.
Le serveur de communication SCOM recevant le message de demande d’accès daccc_mssg le transmet à au moins un terminal participant TPi, TPi, TPn. Eventuellement, la réception puis l’émission à destination d’un terminal participant TPi, TPi, TPn du message de demande d’accès daccc_mssg est une étape d’un procédé d’accès SS1X_ACC, notamment tel qu’illustré par la figure 1b, et/ou d’un procédé de gestion d’accès SS1X_MNGT (implémentant éventuellement des étapes d’un procédé d’accès SS1X_ACC) mis en œuvre par le serveur de communication SCOM.
Suite à cette demande, au moins un terminal participant TPi peut émettre une acceptation ok_cmd de cette demande vers le serveur de communication SCOM. Eventuellement, l’émission d’une acceptation par le terminal participant TPi au serveur de communication SCOM est une étape d’un procédé d’administration d’accès SS1X_ADM, notamment tel qu’illustré par la figure 3. Dans ce cas, le serveur de communication SCOM commande un accès acc_cmd par le terminal requérant à la première session SS1X qui déclenche l’entrée du terminal requérant TR dans la première session SS1X (phase III illustrée par la figure 4). Le premier terminal TP1 , les autres terminaux participants TPi, {TPn} et le terminal requérant ayant accès à la première session SSix peuvent alors échanger entre eux et/ou partager des contenus suivant le type de la première session de communication et/ou leur type d’accès.
Préalablement à l’émission d’une acceptation ok cmd par le terminal participant TPi, le terminal participant peut requérir un établissement ss2_req d’une deuxième session de communication entre le terminal participant TPi et le terminal requérant TR au serveur de communication SCOM. Le serveur de communication SCOM établit la deuxième session SS2. Ainsi, le terminal participant TPi et le terminal requérant TR peuvent échanger pour permettre notamment au terminal participant TPi et/ou à son utilisateur UPi de déterminer APV_DT si l’accès par le terminal requérant à la première session est approuvé ou non. Les échanges sont notamment des échanges de messages ss2_mssgi, ss2_mssg2... En particulier, la réception par le serveur de communication SCOM de l’acceptation ok_cmd ou le déclenchement par le serveur de communication SCOM de l’entrée du terminal requérant TR clôt ss2_stp la deuxième session.
La figure 5 illustre un schéma simplifié d’une architecture de communication comportant un dispositif de gestion d’accès à une première session de communication sécurisée par un terminal requérant selon l’invention. Le dispositif de gestion d’accès 31 est apte à gérer l’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants 11..1 n, 1i, dit terminaux participants, par un terminal de communication requérant 2, dit terminal requérant. Le dispositif de gestion d’accès 31 comporte
- un contrôleur 312 apte à déclencher une entrée dans la première session en cours du terminal requérant 2 dès réception d’une acceptation ok cmd d’un des terminaux participants 1i..1n, 1 i (le terminal 1i sur l’exemple illustré par la figure 5) suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant 2 à destination d’au moins un terminal participant de la première session 11..1 n, 1i.
L’architecture de communication illustrée par la figure 5 comporte
- plusieurs terminaux participants 1 i, l2...1n, 1i à la première session de communication sécurisée SSix via un réseau de communication 4,
- un terminal de communication requérant 2 l’accès à la première session SSix, et
- un dispositif de gestion d’accès 31.
En particulier, le dispositif de gestion d’accès 31 est implémenté dans un serveur de communication, c’est-à-dire un dispositif apte à gérer au moins une session de communication via le réseau de communication 4.
En particulier, le dispositif de gestion d’accès 31 est, ou comporte, ou est implémenté dans un dispositif de gestion d’une première session de communication sécurisée via le réseau de communication 4. Dans l’exemple de la figure 5, le dispositif de gestion d’accès implémente un dispositif de gestion d’une première session de communication sécurisée 310.
En particulier, le dispositif de gestion d’accès 31 comporte une base de premières sessions sécurisées 313 dans laquelle sont enregistré des listes de participants en association avec des premières sessions de communication sécurisées. Eventuellement, sont en outre enregistrées dans la base de premières sessions sécurisées 313 des dates et/ou horaires prédéfinis de début et/ou de fin de premières sessions sécurisées en association avec une première session.
En particulier, le dispositif de gestion d’accès 31 comporte un générateur 310o apte à établir ssix_stb une première session de communication sécurisée SSix.
Eventuellement, le générateur 310o reçoit une requête d’établissement ssix_oreq d’un premier terminal participant 1i. Alors le générateur 310o est apte à établir ssix_stb la première session de communication sécurisée SS-ixdès réception de la requête d’établissement ssix_oreq. En particulier, le dispositif de gestion d’accès 31 comporte un connecteur 310A apte à fournir un accès sécurisé ssix_sacc à la première session de communication sécurisée SSix à d’autres terminaux participants l2...1n, 1i sur requête d’accès sécurisé ssix_sreq de ces terminaux participants l2...1n, 1i. Alors, au moins un des terminaux participants comporte notamment un générateur/émetteur de requête d’établissement de première session sécurisé (non illustré). C’est le cas, en particulier, du premier terminal participant 1 i de la figure 5. Et, les terminaux participants comportant notamment un générateur/émetteur de requête d’accès à la première session sécurisée (non illustré). C’est le cas, en particulier, des autres terminaux participants l2...1 n, 1 i de la figure 5.
En particulier, le dispositif de gestion 31 comporte en outre un relai de demande d’accès 311 apte à transmettre à au moins un des terminaux participants l2...1n, 1i un message de demande d’accès dacc_mssg reçu d’un terminal requérant 2. Notamment le relai comporte un récepteur (non illustré) de message de demande d’accès dacc_mssg et/ou de requête d’accès acc_req provenant du terminal requérant, la requête d’accès acc_req(dacc_mssg) comportant le message de demande d’accès. Eventuellement, le relai comporte un émetteur (non illustré) de message de demande d’accès dacc_mssg à destination d’au moins un des terminaux participants l2...1n, 1 i via la première session SSix ou en dehors, par communication synchrone, asynchrone ou diffusion. Le relai comporte aussi, notamment, un extracteur (non illustré) de message d’une requête apte à extraire un message de demande d’accès dacc_mssg d’une requête d’accès acc_req. L’extracteur est implémenté entre le récepteur de requête et l’émetteur de message de demande d’accès pour fournir à l’émetteur le message de demande d’accès extrait de la requête d’accès reçue.
La figure 5 illustre aussi un terminal de communication requérant 2, dit terminal requérant, apte à demander un accès à une première session de communication sécurisée SSix, dite première session, en cours entre des terminaux de communications participants 1i, l2...1n, 1i, dit terminaux participants, par le terminal de communication requérant 2, dit terminal requérant. Le terminal requérant 2 comporte
- un connecteur 22 apte à entrer le terminal requérant 2 dans la première session en cours SSix, le connecteur 22 étant déclenché acc_cmd dès réception d’une acceptation ok cmd d’un des terminaux participants 1 i suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant 2 à destination d’au moins un terminal participant de la première session 1 i, l2...1 n, 1i.
En particulier, le terminal requérant 2 comporte
- un générateur 21 d’un message de demande d’accès dacc_mssg apte à être émis par le terminal requérant 2 à destination d’au moins un terminal participant de la première session 1i, l2...1n, 1i. Eventuellement, le générateur 21 est apte à générer une requête d’accès acc_req comportant le de demande d’accès dacc_mssg. Le générateur 21 génère un signal d’accès acc_sg tel que le message de demande d’accès dacc_mssgo u la requête d’accès acc_regsuite à une action dact de l’utilisateur requérant UR. En particulier, le terminal requérant 2 comporte au moins une interface homme-machine de sortie, dite interface de sortie, ou moyen de reproduction 24, tel qu’un écran, au moins un haut-parleur... et/ou au moins une interface homme-machine d’entrée ou de saisie (non illustrée), dite interface d’entrée, tel qu’un clavier, une souris, un écran tactile, un microphone, une caméra...
Dans le cas où le générateur 21 génère un signal d’accès acc_sg suite à une action dact de l’utilisateur requérant UR, le générateur 21 reçoit d’une interface d’entrée des données relatives à l’action dact relative à cette interface d’entrée de l’utilisateur requérant UR. Par exemple, l’utilisateur requérant actionne un bouton avertisseur (équivalent d’une sonnette d’entrée) sur cette interface d’entrée ou frappe l’écran tactile de manière semblable au frappement de la porte (« toc toc »)...
La figure 5 illustre également des terminaux de communication participants 11, 12...1 n, 1 i. Un terminal de communication participant 11, 12...1 n, 1 i, dit terminal participant, est un terminal de communication apte à accéder à une première session de communication sécurisée SSix dite première session, en cours entre des terminaux de communications participantsli, l2...1n, 1i, dit terminaux participants. Un terminal participant 11, l2...1n, 1i comporte
- un connecteur 12i (illustré dans la figure 5 uniquement pour le terminal participant 1i) apte à établir la première session SSix entre le terminal participant 1i et au moins un autre terminal participant 11, I2...I n,
- un validateur 16i (illustré dans la figure 5 uniquement pour le terminal participant 1 i) apte à accepter un accès ok cmdà la première session SSix suite à une transmission d’un message de demande d’accès dacc_mssg émis par le terminal requérant 2 à destination d’au moins un terminal participant 1 i de la première session, le validateur 16i déclenchant une entrée acc_cmd dans la première session SSix en cours du terminal requérant 2.
En particulier, le terminal participant 1i comporte un récepteur 11 i d’un message de demande d’accès dacc_mssg à la première session SS1X provenant du terminal requérant 2.
En particulier, le terminal participant 1i comporte au moins une interface homme-machine de sortie, dite interface de sortie, ou moyen de reproduction 14i, tel qu’un écran, au moins un haut-parleur... et/ou au moins une interface homme-machine d’entrée ou de saisie (non illustrée), dite interface d’entrée, tel qu’un clavier, une souris, un écran tactile, un microphone, une caméra...
Le récepteur 11 i fournit éventuellement le message de demande d’accès dacc_mssgà l’interface de sortie 14i de tel sorte que le message de demande d’accès dacc_mssg puisse être perçu (lu, entendu...) par l’utilisateur participant UPi du terminal participant TPi.
En particulier, le validateur 16i reçoit, directement ou via une interface d’entrée (non illustrée) du terminal participant TPi, une action d’acceptation ok_act de l’utilisateur participant UPi en réponse notamment au message de demande d’accès dacc_mssg fournit à l’utilisateur participant UPi par l’interface de sortie 14i.
En particulier, le terminal participant 1i comporte
- un connecteur 130i apte à établir une deuxième session SS2 de communication synchrone avec le terminal requérant 2 préalablement à l’acceptation ok cmd par le validateur 16i.
En particulier, le terminal participant 1i comporte un générateur 15i de requête d’établissement d’une deuxième session ss2_req. Le générateur 15i émet la requête d’établissement d’une deuxième session ss2_req à destination d’un dispositif de gestion de deuxième session 32 notamment implémenté dans un serveur de communication 3. Ainsi, le dispositif de gestion de première session de communication sécurisée 31 et le dispositif de gestion de deuxième session 32 peuvent, par exemple, être implémentée dans un serveur de communication 3.
En particulier, le dispositif de gestion d’accès 32 comporte un générateur 320 apte à établir ss2_stb une deuxième session de communication SS2 entre le terminal requérant 2 et le terminal participant 1i.
En particulier, le terminal participant 1 i et le terminal requérant 2 comportent chacun un dispositif de communication, respectivement 13i, 23, via la deuxième session SS2. Les dispositifs de communication 13i, 23 comportent des connecteurs 130i, 230 à la deuxième session SS2, et éventuellement des émetteurs 131 i, 231 et/ou des récepteurs 132i, 232 par exemple de messages mssg-i, mssg2... qui sont transmis via la deuxième session SS2 sous les noms de ss2_mssgi, ss2_mssg2...
En particulier, le générateur 15i de requête d’établissement de deuxième session SS2 active xtrg le dispositif de communication via la deuxième session 13i du terminal participant 1 i.
En particulier, les messages mssg-i, mssg2... transmis via la deuxième session sont entrées via les interfaces d’entrée respectivement 131 i, 231 et reproduits par les interfaces de sortie respectivement 132i, 232 à l’intention respectivement de l’utilisateur participant UPi et de l’utilisateur requérant UR.
En particulier, le validateur 16i comporte un analyseur apte à décider en fonction du message de demande d’accès dacc_mssg, et/ou des messages échangés via la deuxième session ss2_mssgi, ss2_mssgi..., notamment ceux reçus du terminal requérant 2, et/ou d’une action ok act de l’utilisateur participant UPi d’une acceptation d’accès du terminal requérant 2 à la première session SSix. Dans le cas où l’analyseur décide d’une acceptation, le validateur 16i émet une acceptation ok_cmd vers le dispositif de gestion de la première session 31 , en particulier vers le contrôleur 312. Les figures 6a à 6e illustrent une utilisation de l’invention dans le cas où la première session sécurisée est un espace collaboratif comportant un espace d’échange textuel, une visioconférence et un espace de partage de document entre des utilisateurs participants UPi, UP2 ... UPn doté chacun d’au moins un terminal de communication participant pour accéder à cet espace collaboratif.
La figure 6a illustre un schéma simplifié d’utilisation d’un procédé de gestion d’accès dans un cas d’usage particulier de l’invention.
La figure 6a représente un écran du terminal participant d’un premier utilisateur participant LIP1.
L’écran comporte éventuellement plusieurs fenêtres dont une fenêtre associée à la première session SSix_WD et éventuellement en sous-fenêtres:
- une sous-fenêtre d’échange textuel SSIX_XWDUPI dans laquelle est reproduite les messages textuels échangés par les différents participants à la première session notamment dans l’ordre chronologique (dans l’exemple de la figure 6a : les messages du premier utilisateur participant mssgi,upi, mssg4,upi, un message du deuxième utilisateur participant mssg2,up2, un message d’un nième utilisateur participant mssg3,upn...); et/ou
- une sous-fenêtre de partage SSix_pWD, la sous-fenêtre de partage SSix_pWD comportant notamment elle-même une ou plusieurs sous-fenêtre, par exemple
+ une sous-fenêtre dans laquelle un flux Visio est reproduit, en l’occurrence le flux Visio du premier utilisateur participant LIP1, et/ou
+ une sous-fenêtre dans laquelle un contenu est partagé, en l’occurrence un jième contenu q,upi du premier utilisateur participant LIP1,
+ etc.
La figure 6b illustre un schéma simplifié d’utilisation d’une éventuelle première étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a.
La figure 6a représente un écran du terminal requérant d’un utilisateur requérant UR. L’utilisateur requérant a connaissance de la première session et, par exemple, saisie une adresse de la première session (tel qu’une adresse de type url dans son navigateur). Son écran affiche alors une première fenêtre d’entrée dans la première session SSix_EWDi.
Cette première fenêtre d’entrée de session SSix_EWDi comporte notamment une zone de saisie d’un identifiant id_cptz de l’utilisateur requérant UR et/ou d’un identifiant de son terminal et/ou une zone de saisie d’un code d’accès cd_cptz. L’utilisateur requérant UR n’ayant pas le code d’accès ou ne faisant pas partie de la liste des participants ne peut y saisir l’identifiant ID et/ou le code d’accès CD demandé(s) pour accéder de manière sécurisé à la première session SSix. La première fenêtre d’entrée de session SSix_EWDi comporte notamment un bouton virtuel d’avertissement kk_cptz sur lequel l’utilisateur requérant peut agir dact pour émettre un message de demande d’accès. Dans une variante non illustrée de l’invention, l’utilisateur requérant UR ayant préalablement été identifié comme n’appartenant pas à la liste des participants, la fenêtre d’entrée comporte uniquement un élément d’interaction tel que le bouton virtuel d’avertissement kk_cptz, ou une capture d’une gestuelle de frapper à une porte, ou une capture d’une interpellation orale « Bonjour ! Y-t-il quelqu’un ? », « Allô », ou etc.
La figure 6c illustre un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a.
Eventuellement, suite à l’action de l’utilisateur requérant dact relativement à la première fenêtre d’entrée de session SSix_EWDi, une deuxième fenêtre d’entrée SSIX_EWD2 est reproduite permettant à l’utilisateur requérant UR de compléter le message de demande d’accès dacc_cpl. Notamment, l’utilisateur requérant peut ajouter son nom, la raison de sa demande d’accès, etc. Et, le message de demande d’accès dacc_mssg ainsi constitué par l’action dact de l’utilisateur et/ou un complément dacc_cpl est transmis du terminal requérant à au moins un terminal participant d’un des utilisateurs participants U1...UPn.
La figure 6d illustre un schéma simplifié d’utilisation d’un procédé d’administration d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a.
Au moins un des terminaux participants des utilisateurs participants UP1...UPn reçoit le message de demande d’accès et le reproduit dans une fenêtre de demande d’accès DACC_WD. La figure 6d illustre l’écran du terminal participant de l’utilisateur participant i UPi. A cet instant, les échanges se sont poursuivi par rapport à ceux illustrés par la figure 6a : de nouveaux messages sont reproduits : mssg5,up2, mssg6,up3, mssg7,up2, mssgs.upi, mssgg.upi dans la sous-fenêtre d’échange textuel SSIX_XWDUPÎ
Si l’utilisateur participant i UPi établit une deuxième session avec le terminal requérant de l’utilisateur requérant UR, les échanges relatifs à cette deuxième session sont reproduits en lien avec la fenêtre de demande d’accès DACC_WD. Par exemple, si ces échanges sont vocaux, ils ne seront possible que si la fenêtre de demande d’accès DACC_WD est activée (par exemple par sélection par l’utilisateur participant i UPi). Dans un autre exemple, les échanges sont reproduit sous forme textuelle dans la fenêtre de demande d’accès DACC_WD au moins si ce sont des échanges textuels, voire également par conversion vocal en texte lorsqu’ils sont vocaux et/ou audio. Dans l’exemple de la figure 6d, un flux Visio provenant du terminal requérant de l’utilisateur requérant SS2_VUR est reproduit. Ainsi, l’utilisateur requérant UR a l’impression de s’adresser à un utilisateur participant comme via un visiophone ou un interphone à l’entrée d’une salle sécurisée ou d’un domicile. La fenêtre de demande d’accès DACC_WD comporte au moins un élément d’interaction OK_BT permettant à l’utilisateur participant UPi d’accepter la demande d’accès de l’utilisateur requérant. Cet élément d’interaction est notamment un bouton physique ou virtuel d’acceptation, et/ou une caméra captant un hochement de tête, et/ou un microphone captant une acceptation orale, etc.
La figure 6e illustre un schéma simplifié d’utilisation d’une éventuelle deuxième étape d’un procédé de demande d’accès selon l’invention dans le cas d’usage de l’invention de la figure 6a.
La figure 6e représente un écran du terminal requérant de l’utilisateur requérant UR.
L’écran comporte éventuellement plusieurs fenêtres dont une fenêtre associée à la première session SSix_WD et éventuellement en sous-fenêtres:
- une sous-fenêtre d’échange textuel SSIX_XWDUR dans laquelle est reproduite les messages textuels échangés par les différents participants à la première session notamment dans l’ordre chronologique (dans l’exemple de la figure 6e : l’ensemble des messages des échanges démarrés la figure 6a et poursuivis ensuite notamment à la figure 6d dont un message du terminal requérant la première session SSix mssg-io.upR, mssg4,upi ...); et/ou
- une sous-fenêtre de partage SSix_pWD, la sous-fenêtre de partage SSix_pWD comportant notamment elle-même une ou plusieurs sous-fenêtre, par exemple
+ une sous-fenêtre dans laquelle un flux Visio est reproduit, en l’occurrence le flux Visio du premier utilisateur participant UPi, et/ou
+ une sous-fenêtre dans laquelle un contenu est partagé, en l’occurrence un jième contenu q,upi du premier utilisateur participant UPi,
+ etc.
En utilisant l’invention, un utilisateur requérant qui connaît la localisation de l’espace numérique partagé sécurisé (par exemple, l’url d’accès, le nom de la salle virtuelle, etc.) mais qui n’est pas en mesure de saisir ses identifiants et/ou mots de passe en raison d’un oubli, d’une perte, etc. a la possibilité de demander l’accès (notamment sous la forme d’un appel vocal, sonore, hépatique, visuel, etc.) en direction de cet espace qu’il cherche rejoindre via un canal sécurisé. Cet appel, visible depuis l’intérieur de cet espace permet à toute personne déjà présente d’accepter son entrée dans/ son accès à cet espace.
L’invention est applicable à tout espace numérique partagé sécurisé dès lors que celui-ci nécessite une clef d’accès (peu importe sa forme). Ainsi, seule une personne aura besoin de sa clef pour accéder à cet espace avant de valider (par acceptation ok cmd) l’accès des autres participants un à un en les reconnaissant à l’aide de leur voix lorsque le message de demande d’accès comporte un message vocal, de leur visage lorsque le message de demande d’accès comporte une photo ou une vidéo de l’utilisateur requérant, leur matériel d’accès, une question secrète ou tout autre élément de reconnaissance. L'invention vise aussi un support. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique ou encore un moyen d'enregistrement magnétique, par exemple une disquette ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau notamment de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Dans une autre implémentation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique le terme module peut correspondre aussi bien à un composant logiciel ou à un composant matériel. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonction selon la description ci-dessus. Un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions.

Claims

REVENDICATIONS
1. Procédé d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’accès comportant
- déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
2. Procédé d’accès à une première session de communication sécurisée selon la revendication précédente, le procédé d’accès comportant
- recevoir l’acceptation d’un terminal participant.
3. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, le procédé d’accès comportant :
- recevoir une requête d’accès d’un terminal requérant, la requête d’accès comportant le message de demande d’accès, et
- émettre le message de demande d’accès à destination d’au moins un terminal participants de la première session.
4. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, dans lequel émettre le message de demande d’accès à destination du au moins un terminal participant de la première session comporte une des étapes suivantes :
- diffuser le message à destination de l’ensemble des terminaux participants préalablement à un accès du terminal requérant à la première session;
- émettre le message par communication asynchrone à destination d’au moins un des terminaux participants;
- émettre le message à destination d’au moins un terminal participant de la première session en dehors de la première session.
5. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, le message de demande d’accès comportant au moins une données parmi les données suivantes :
- une donnée sonore courte d’avertissement,
- un identifiant associé au terminal requérant,
- un identifiant associé à un terminal participant à la session de communication sécurisée,
- un identifiant de la première session à laquelle le terminal requérant demande l’accès,
- un message textuel, audio ou vidéo d’un utilisateur du terminal requérant.
6. Procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications précédentes, le procédé d’accès comportant
- établir, préalablement au déclenchement de l’entrée dans la première session du terminal requérant, une deuxième session de communication synchrone entre le terminal requérant et un des terminaux participants à la première session sur requête d’établissement dudit un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participants de la session de communication.
7. Procédé d’accès à une première session de communication sécurisée selon la revendication précédente, le procédé d’accès comportant
- clore la deuxième session dès mise en œuvre par le procédé d’accès d’une étape parmi les suivantes :
+ la réception d’une acceptation par le terminal participant de la deuxième session,
+ le déclenchement de l’entrée dans la première session du terminal requérant.
8. Procédé de demande d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé de demande d’accès comportant
- entrer dans la première session en cours du terminal requérant déclenchée dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
9. Procédé d’administration d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le procédé d’administration d’accès comportant
- émettre une acceptation d’un des terminaux participants suite à une réception d’un message de demande d’accès reçu par au moins un terminal participant de la première session du terminal requérant, l’acceptation envoyée déclenchant, dès réception, une entrée dans la première session en cours du terminal requérant.
10. Programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’accès à une première session de communication sécurisée selon l’une quelconque des revendications 1 à 7 et/ou du procédé de demande d’accès selon la revendication 8 et/ou du procédé d’administration d’accès selon la revendication 9 lorsque ledit programme est exécuté par un processeur.
11. Dispositif de gestion d’accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le dispositif de gestion d’accès comportant
- un contrôleur apte à déclencher une entrée dans la première session en cours du terminal requérant dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
12. Terminal de communication requérant, dit terminal requérant, apte à demander un accès à une première session de communication sécurisée, dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, par un terminal de communication requérant, dit terminal requérant, le terminal requérant comportant
- un connecteur apte à entrer le terminal requérant dans la première session en cours, le connecteur étant déclenché dès réception d’une acceptation d’un des terminaux participants suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
13. Terminal requérant selon la revendication précédente, le terminal requérant comportant
- un générateur d’un message de demande d’accès apte à être émis par le terminal requérant à destination d’au moins un terminal participant de la première session.
14. Terminal de communication participant, dit terminal participant, à une première session de communication sécurisée dite première session, en cours entre des terminaux de communications participants, dit terminaux participants, le terminal participant comportant
- un connecteur apte à établir la première session entre le terminal participant et au moins un autre terminal participant, - un validateur apte à accepter un accès à la première session suite à une transmission d’un message de demande d’accès émis par le terminal requérant à destination d’au moins un terminal participant de la première session, le validateur déclenchant une entrée dans la première session en cours du terminal requérant.
15. Terminal participant selon la revendication précédente, le terminal participant comportant - un connecteur apte à établir une deuxième session de communication synchrone avec le terminal requérant préalablement à l’acceptation par le validateur.
EP21737113.7A 2020-06-16 2021-06-15 Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant Pending EP4165889A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2006267A FR3111504A1 (fr) 2020-06-16 2020-06-16 Procédé d’accès et dispositif de gestion d’accès à une session de communication sécurisée entre des terminaux de communication participants par un terminal de communication requérant
PCT/FR2021/051063 WO2021255375A1 (fr) 2020-06-16 2021-06-15 Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant

Publications (1)

Publication Number Publication Date
EP4165889A1 true EP4165889A1 (fr) 2023-04-19

Family

ID=73138892

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21737113.7A Pending EP4165889A1 (fr) 2020-06-16 2021-06-15 Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant

Country Status (4)

Country Link
US (1) US20230308493A1 (fr)
EP (1) EP4165889A1 (fr)
FR (1) FR3111504A1 (fr)
WO (1) WO2021255375A1 (fr)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070208806A1 (en) * 2006-03-02 2007-09-06 Sun Microsystems, Inc. Network collaboration system with conference waiting room
US8880598B2 (en) * 2007-04-10 2014-11-04 Microsoft Corporation Emulation of room lock and lobby feature in distributed conferencing system
US9060094B2 (en) * 2007-09-30 2015-06-16 Optical Fusion, Inc. Individual adjustment of audio and video properties in network conferencing
US10091257B2 (en) * 2015-02-10 2018-10-02 Cisco Technology, Inc. Managing a virtual waiting room for online meetings
US10320856B2 (en) * 2016-10-06 2019-06-11 Cisco Technology, Inc. Managing access to communication sessions with communication identifiers of users and using chat applications
US20200084057A1 (en) * 2018-09-12 2020-03-12 Avaya Inc. Conference session management with mode selection
US11050801B2 (en) * 2018-12-04 2021-06-29 T-Mobile Usa, Inc. Call to meeting upgrade
US20230136777A1 (en) * 2021-11-04 2023-05-04 Avaya Management L.P. Communication channel into a conference session of a subsequent meeting when a current meeting overruns

Also Published As

Publication number Publication date
US20230308493A1 (en) 2023-09-28
WO2021255375A1 (fr) 2021-12-23
FR3111504A1 (fr) 2021-12-17

Similar Documents

Publication Publication Date Title
EP2284803B1 (fr) Système sécurisé de programmation de dispositifs de serrure à commande électronique par accréditations acoustiques chiffrées
EP2586175B1 (fr) Procédé et dispositif de vérification de reconnaissance physique entre un appelant et un appelé
EP2282297A1 (fr) Système sécurisé de commande d'ouverture de dispositifs de serrure par accréditions acoustiques chiffrées
CN101663658A (zh) 用于语音应用程序的预认证呼叫
EP2795870B1 (fr) Procede d'acces par un terminal de telecommunication a une base de donnees hebergee par une plateforme de services accessible via un reseau de telecommunications
EP1646176A2 (fr) Attribution d'une autorisation d'accès à une ressource
CN102164119A (zh) 认证系统、传送终端、以及传送系统
EP2360889B1 (fr) Création et utilisation d'un lien de télécommunication entre deux utilisateurs d'un réseau de télécommunication
EP1449092B1 (fr) Procede de securisation d un acces a une ressource numerique
WO2021255375A1 (fr) Procede d'acces et dispositif de gestion d'acces a une session de communication securisee entre des terminaux de communication participants par un terminal de communication requerant
WO2019102120A1 (fr) Procédés et dispositifs pour l'enrôlement et l'authentification d'un utilisateur auprès d'un service
EP3662629A1 (fr) Procede de creation et de participation a une conference audio ou video
EP3078203B1 (fr) Module de pilotage d'un récepteur de contenus multimédias, serveur et procédés d'élaboration de contenus et de messages associés
EP1985093A1 (fr) Procédé et dispositif de gestion d'au moins un groupe d'utilisateurs, produit programme d'ordinateur correspondant
EP0581689A1 (fr) Procédé et système de communication entre un équipement appelant et un équipement appelé via un autocommutateur
EP2538646A2 (fr) Serveur d'application apte à contrôler une conférence téléphonique
FR3105482A1 (fr) Procédé d’obtention de mot de passe pour l’accès à un service
EP2179568A2 (fr) Procede de controle d'un fournisseur de services a partir d'un terminal mobile
FR3122266A1 (fr) Procédés et systèmes d’accès d’un utilisateur à un service de visioconférence
EP3900294A1 (fr) Processus de déclaration de non-exploitabilité de données échangées
FR3122267A3 (fr) Procédés et systèmes d’accès d’un utilisateur à un service de visioconférence
FR3084551A1 (fr) Recuperation de cle reseau, gestion de recuperation de cle reseau, mise a disposition de cle reseau, terminal, serveur et point d'acces les mettant en œuvre
FR2904902A1 (fr) Procede et systeme d'authentification d'utilisateurs dans un reseau de communication
WO2012080632A1 (fr) Procédé et système d'agrégation de données collectives et personnelles présentées sur un terminal
FR2992808A1 (fr) Systeme, serveur, procede, produit programme d'ordinateur et moyen de stockage pour la mise en oeuvre d'une conference multipoints

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: 20230112

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)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE