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.

Applications Claiming Priority (2)

Publications (1)

Family

ID=73138892

Family Applications (1)

Country Status (4)

Family Cites Families (7)

• 2020
  • 2020-06-16 FR FR2006267A patent/FR3111504A1/fr not_active Withdrawn
• 2021
  • 2021-06-15 US US18/001,950 patent/US20230308493A1/en active Pending
  • 2021-06-15 WO PCT/FR2021/051063 patent/WO2021255375A1/fr unknown
  • 2021-06-15 EP EP21737113.7A patent/EP4165889A1/de active Pending

Also Published As

Similar Documents

Legal Events