Systems and methods for locking encrypted video conferences

Abstract

One disclosed exemplary method includes obtaining a conference encryption key, sending a request from a client device to a video conferencing provider to initiate an encrypted video conference including a plurality of participants, and distributing the conference encryption key to each participant of the plurality of participants. The disclosed exemplary method further includes receiving an indication that the encrypted video conference should be locked, receiving an indication that the encrypted conference should be locked, receiving a request to admit an additional participant into the encrypted video conference, determining whether the additional participant is one of the plurality of participants, and in response to determining that the additional participant is not one of the plurality of participants, rejecting the request to admit the additional participant into the encrypted video conference.

Description

Technical Field

[0001]

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Patent Application No. 17 / 162,400, filed on January 29, 2021, entitled "Systems and Methods for Locking Encrypted Video Conferences", which is hereby incorporated by reference in its entirety.

[0002]

[0002] This application generally relates to hosting or participating in video conferences, and more particularly, to systems and methods for locking encrypted video conferences.

Background Art

[0003]

[0003] Video conferencing has become a common way for people to gather as a group without being in the same physical location. Participants can be invited to a video conference and join from a personal computer or phone, and can see, hear, and talk to each other as they would during a direct group meeting or event. The advent of user - friendly video conferencing software has made it possible for teams to work together, despite being dispersed across a country or the world. It has also made it possible for families and friends to interact with each other in a more meaningful way, despite being physically apart.

Summary of the Invention

[0004]

[0004] Various examples of systems and methods for securely recording and retrieving encrypted video conferences are described. One exemplary method includes obtaining a conference encryption key, sending a request from a client device to a video conferencing provider to start an encrypted video conference with multiple participants, distributing the conference encryption key to each of the multiple participants, receiving instructions that the encrypted video conference should be locked, receiving a request to accept additional participants into the encrypted video conference after receiving instructions that the encrypted conference should be locked, determining whether the additional participant is one of the multiple participants, and, in response to determining that the additional participant is not one of the multiple participants, rejecting the request to accept additional participants into the encrypted video conference. Another exemplary method involves a video conferencing provider initiating an encrypted video conference. This includes the video conferencing provider receiving and remembering instructions from the encrypted video conference host that the encrypted video conference should be locked by initiating an encrypted video conference for multiple participants, receiving a request to allow additional participants to join the encrypted video conference following the receipt of the instructions that the encrypted conference should be locked, and receiving a notification that the request to allow additional participants to join the encrypted video conference has been denied.

[0005]

[0005] One exemplary system includes a non-temporary computer-readable medium, a communication interface, a microphone, an image sensor, and a processor communicatively coupled to the non-temporary computer-readable medium, the communication interface, the microphone, and the image sensor, wherein the processor is configured to execute processor-executable instructions stored in the non-temporary computer-readable medium to obtain a conference encryption key, to send a request from the client device to the video conferencing provider to start an encrypted video conference including multiple participants, to distribute the conference encryption key to each of the multiple participants, to receive an instruction that the encrypted video conference should be locked, to receive an instruction that the encrypted video conference should be locked, to receive a request to allow an additional participant, to determine whether the additional participant is one of the multiple participants, and to reject the request to allow an additional participant to the encrypted video conference in response to determining that the additional participant is not one of the multiple participants.

[0006]

[0006] Another exemplary system includes a non-temporary computer-readable medium, a communication interface, and a processor communicatively coupled to the non-temporary computer-readable medium and the communication interface, wherein the processor is configured to execute processor-executable instructions stored in the non-temporary computer-readable medium to initiate an encrypted video conference for multiple participants by a video conferencing provider, to receive instructions from the host of an encrypted video conference that the encrypted video conference should be locked after receiving instructions that the encrypted video conference should be locked, to receive a request to accept additional participants into the encrypted video conference, and to receive a notification that the request to accept additional participants into the encrypted video conference has been rejected.

[0007]

[0007] These exemplary examples are mentioned not to limit or define the scope of the present disclosure, but rather to provide examples to aid in its understanding. The exemplary examples are described in “Modes for Carrying Out the Invention” which provide further explanation. The advantages provided by the various examples can be further understood by examining this specification.

[0008]

[0008] The accompanying drawings incorporated herein and constituting part thereof illustrate one or more specific examples and, together with descriptions of the examples, are useful in illustrating the principles and implementations of the specific examples. [Brief explanation of the drawing]

[0009] [Figure 1] This illustrates an exemplary system for locking encrypted video conferences. [Figure 2] This illustrates an exemplary system for locking encrypted video conferences. [Figure 3] This illustrates an exemplary system for locking encrypted video conferences. [Figure 4] This example demonstrates how to lock an encrypted video conference. [Figure 5] This example demonstrates how to lock an encrypted video conference. [Figure 6] This disclosure provides exemplary computing devices suitable for use with any system or method for locking encrypted video conferencing. [Modes for carrying out the invention]

[0010]

[0012] This specification provides examples in the context of systems and methods for securely recording and retrieving encrypted video conferences. Those skilled in the art will understand that the following description is illustrative and not intended to be limiting. Hereinafter, embodiments of the examples shown in the accompanying drawings are given in detail. The same reference numerals are used throughout the drawings and the following description to refer to the same or similar items.

[0011]

[0013] For clarity, not all of the everyday characteristics of the examples described herein are shown or explained. Naturally, in developing such actual implementations, numerous implementation-specific decisions must be made to achieve the developer's specific goals, such as compliance with application and business-related constraints, and it will be understood that these specific goals will differ from implementation to implementation and from developer to developer.

[0012]

[0014] People participate in video conferences for a wide variety of reasons, including staying in touch with family, conducting business, and managing groups or organizations. In some cases, participants in a video conference may want to keep the content confidential and accessible only to specific authorized personnel. This can be done by encrypting the audio and video streamed between participants in the video conference, preventing potential eavesdroppers from accessing the streamed audio and video. Without the necessary decryption information, accessing encrypted audio and video can be computationally very difficult. However, in some cases, uninvited participants may attempt to join an encrypted conference in order to eavesdrop.

[0013]

[0015] Such scenarios can be undesirable for several reasons. For example, in some cases, the host may want to restrict participants in a video conference and exclude others attempting to join. Normally, when a prospective participant attempts to join a meeting, the video conferencing provider presents the new participant to the meeting. However, the video conferencing provider's server may be "untrustworthy" by the current participant, meaning that the server's and the prospective participant's origin and identity may not be verifiable by the current participant, or may otherwise be questionable. In some cases, the audio or video may contain sensitive information that may not be shared with the video conferencing provider, for example, by law or regulation. Furthermore, the participant themselves may simply not want the video conferencing provider or an unverified participant to access the video conference content.

[0014]

[0016] In such a case, the exemplary system would allow the meeting host to start the meeting and allow participants to join, and then choose the option to lock the meeting, thereby preventing additional participants from joining. The exemplary system would notify all current participants of the meeting that the meeting is currently locked, and additional participants would not be able to join.

[0015]

[0017] In some exemplary systems, current participants can be dropped from a meeting. In such cases, those participants can rejoin the ongoing video conference. In other exemplary systems, if a member drops, for example, the host, the meeting ends, a new meeting automatically starts, and then participants can join. Locking an encrypted video conference prevents both potential unintentional access by participants and attempts by someone to actively access a meeting they should not be able to access.

[0016]

[0018] To enable a video conferencing provider to offer an encrypted video conference and allow one or more participants to access it, the host initiates an end-to-end ("E2E") encrypted video conference. For example, the host may select an option on the user interface to initiate E2E encryption. Once the host initiates an E2E conference, the host's client device 320 generates an encryption key (referred to herein as the "conference key") to be used by the conference participants. In an exemplary system, the encryption key is a symmetric key. The host's client device 320 may distribute the symmetric key to the conference participants using public-key cryptography. Once E2E encryption is enabled, the video conferencing provider 310 is not provided with the symmetric key and therefore only relays the audio and video, and cannot decrypt the audio and video content.

[0017]

[0019] In an example system, if the host locks a meeting, the host will no longer provide the meeting key to the attendees. Therefore, attendees will be unable to join the encrypted video conference and, consequently, will be unable to access the encrypted audio and video. However, the host will allow dropped participants to be re-enrolled.

[0018]

[0020] Using such technology, video conference hosts and participants can enjoy privacy for their communications and ensure that unwanted participants are not given access to encrypted video conferences. Such technology may be particularly advantageous in financial institutions, law firms, or healthcare organizations that must guarantee a certain degree of confidentiality. As mentioned above, this can help comply with various privacy regulations or ensure that any other attempts to access encrypted records must be mediated by the host (or a corresponding entity such as the host's employer).

[0019]

[0021] This exemplary example is provided to introduce the general subject matter discussed in this specification, and the present disclosure is not limited to this example. In the following sections, various additional non-limiting examples and illustrations of systems and methods for securely recording and retrieving encrypted video conferences will be described.

[0020]

[0022] Referring now to FIG. 1, FIG. 1 shows an exemplary system 100 that provides video conferencing capabilities to various client devices. System 100 includes a video conferencing provider 110 connected to a plurality of communication networks 120, 130, through which various client devices 140-180 can participate in video conferences hosted by video conferencing provider 110. For example, video conferencing provider 110 can be located within a private network to provide video conferencing services to devices within the private network, or can be connected to a public network, such as the Internet, so that anyone can access it. Some examples can even provide a hybrid model in which video conferencing provider 110 supplies components to enable private organizations to host private internal video conferences or to connect their systems to video conferencing provider 110 via a public network.

[0021]

[0023] The system can also optionally include one or more user identity providers, such as user identity provider 115, that can provide user identity services to users of client devices 140-160 and authenticate the user identities of one or more users to video conferencing provider 110. In this example, user identity provider 115 is operated by an entity different from video conferencing provider 110, but in some examples, they can be the same entity.

[0022]

[0024] Video conferencing provider 110 enables a client to create a video conference (or "meeting"), invite others to participate in those meetings, as well as record meetings, generate transcripts from meeting audio, manage user functions in meetings, enable text messaging during meetings, create and manage breakout rooms from a main meeting, and perform other related functions. FIG. 2, described below, provides a more detailed description of the architecture and functions of video conferencing provider 110.

[0023]

[0025] Meetings of this exemplary video conferencing provider 110 are provided in a virtual "room" to which participants connect. A room in this context is a structure provided by a server that provides a common point where various video and audio data are received before being multiplexed and provided to various participants. Although "room" is the label for this concept in the present disclosure, any suitable function that enables multiple participants to participate in a common video conference can be used. Further, in some examples, as suggested above, a meeting can also have "breakout" rooms. Such breakout rooms may also be rooms associated with a "main" video conference room. Thus, participants in the main video conference room can leave the room and enter a breakout room, for example, to discuss a particular topic, before returning to the main room. The breakout rooms in this example are separate meetings associated with the meeting in the main room. However, to participate in a breakout room, a participant must first enter the main room. A room may have any number of associated breakout rooms according to various examples.

[0024]

[0026] To create a meeting with video conferencing provider 110, the user can contact video conferencing provider 110 using client devices 140-180 and select the option to create a new meeting. Such an option may be provided on a web page accessed by client devices 140-160, or in a client application run by client devices 140-160. In the case of telephone equipment, the user may be presented with an audio menu that can be navigated by pressing the number buttons on the telephone equipment. To create a meeting, video conferencing provider 110 may prompt the user for specific information such as the date, time, and duration of the meeting, the number of participants, the type of encryption to use, and whether the meeting is confidential or private. After receiving the various meeting settings, video conferencing provider may create a meeting record, generate a meeting identifier, and, in some examples, a corresponding meeting password or passcode (or other authentication information), and provide all meeting information to the meeting host.

[0025]

[0027] After receiving meeting information, users can distribute it to invite one or more users to the meeting. To start the meeting at the scheduled time (or immediately if the meeting is set to start immediately), the host provides a meeting identifier and, if applicable, corresponding authentication information (e.g., password or passcode). The video conferencing system can then start the meeting and accept users into it. Depending on the options set for the meeting, users may be accepted immediately upon providing the appropriate meeting identifier (and authentication information, if necessary) even if the host has not yet arrived, or users may be presented with information indicating that the meeting has not yet started, or the host may request that one or more users be specifically accepted.

[0026]

[0028] During the meeting, participants can use client devices 140-180 to capture audio or video information and stream that information to the video conferencing provider 110. They also receive audio or video information from the video conferencing provider 210, which is displayed by each client device 140, enabling various users to join the meeting.

[0027]

[0029] At the end of the meeting, the host may choose to end the meeting, or it may end automatically after a scheduled end time or a predetermined period of time. When the meeting ends, the various participants are disconnected from the meeting and will no longer receive the meeting's audio or video stream (the transmission of the audio or video stream will stop). The video conferencing provider 110 may also disable meeting information such as the meeting identifier or password / passcode.

[0028]

[0030] To provide such functionality, one or more client devices 140–180 can communicate with the video conferencing provider 110 using one or more communication networks, such as network 120 or the public switched telephone network ("PSTN") 130. Client devices 140–180 may be any suitable computing or communication device having audio or video capabilities. For example, client devices 140–160 may be conventional computing devices, such as desktop or laptop computers, having a processor and computer-readable media, connected to the video conferencing provider 110 using the Internet or other suitable computer network. Suitable networks include the Internet, any local area network ("LAN"), metro area network ("MAN"), wide area network ("WAN"), cellular network (e.g., 3G, 4G, 4G LTE, 5G, etc.), or any combination thereof. Alternatively, or similarly, other types of computing devices may be used, such as tablets, smartphones, and dedicated video conferencing equipment. Each of these devices may provide both audio and video capabilities, enabling one or more users to participate in a video conference hosted by the video conferencing provider 110.

[0029]

[0031] In addition to the computing devices described above, client devices 140-180 may also include one or more telephone devices, such as a mobile phone (e.g., mobile phone 170), an Internet Protocol ("IP") phone (e.g., phone 180), or a conventional telephone. Such telephone devices may enable a user to make conventional calls to other telephone devices using the PSTN, including the video conferencing provider 110. It should be understood that certain computing devices may also provide telephone functionality and can operate as telephone devices. For example, a smartphone typically provides mobile phone functionality and can therefore operate as a telephone device in the exemplary system 100 shown in Figure 1. Furthermore, conventional computing devices may run software that enables telephone functionality, allowing a user to make and receive calls using, for example, a headset and microphone. Such software may communicate with a PSTN gateway to route calls from the computer network to the PSTN. Thus, telephone devices encompass any device capable of making conventional calls and are not limited to dedicated telephone devices such as conventional telephones.

[0030]

[0032] Referring again to client devices 140-160, these devices 140-160 can use network 120 to contact video conferencing provider 110 and provide the video conferencing provider 110 with information to access the functions provided by the video conferencing provider 110, such as access to create new meetings or join existing meetings. To this end, client devices 140-160 may provide user identification information, meeting identifiers, meeting passwords or passcodes, etc. In an example using user identity provider 115, client devices, for example, client devices 140-160, can work in conjunction with user identity provider 115 to provide user identification information or other user information to video conferencing provider 110.

[0031]

[0033] The user identity provider 115 may be any entity trusted by the video conferencing provider 110 that can help identify the user to the video conferencing provider 110. For example, a trusted entity may be a server operated by a company or other organization where the user has established their identity, such as an employer or a trusted third party. The user can sign in to the user identity provider 115 by providing a username and password, for example, to access their identity with the user identity provider 115. Identity, in this sense, is information established and maintained by the user identity provider 115 that can be used to identify a particular user regardless of the client device the user is using. An example of identity may be an email account established by a user with the user identity provider 110 and protected by a password or additional security features such as biometric authentication or two-factor authentication. However, identity may be different from a function such as email. For example, a healthcare provider may establish the identity of its patient, and such an identity may have associated email accounts, but identity is different from those email accounts. Thus, a user's "identity" concerns a set of secure and verified information that is tied to a particular user and must be accessible only by that user. By accessing their identity, the associated user can verify themselves against other computing devices or services, such as the video conferencing provider 110.

[0032]

[0034] When a user accesses the video conferencing provider 110 using a client device, the video conferencing provider 110 communicates with the user identity provider 115 using information provided by the user to verify the user's identity. For example, the user may provide a username or cryptographic signature associated with the user identity provider 115. The user identity provider 115 then either confirms the user's identity or rejects the request. Based on this response, the video conferencing provider 110 grants or denies access to its services, respectively.

[0033]

[0035] For example, in the case of telephone equipment such as client devices 170-180, the user can make a call to the video conferencing provider 110 to access the video conferencing service. After answering the call, the user can provide information about the video conferencing, such as a conference identifier ("ID"), passcode, or password, to enable the telephone equipment to join the conference and participate using the telephone equipment's audio devices, such as a microphone and speaker, even if the telephone equipment does not have video capabilities.

[0034]

[0036] Because telephone devices typically have more limited functionality than traditional computing devices, they may not be able to provide certain information to the video conferencing provider 110. For example, a telephone device may not be able to provide the video conferencing provider 110 with user identification information to identify the telephone device or the user. Therefore, the video conferencing provider 110 may provide functionality that is limited by such telephone devices. For example, a user may be allowed to join a meeting after providing meeting information such as a meeting identifier and passcode, but may only be identified as an anonymous participant in the meeting. This can limit the ability to interact with the meeting in several ways, such as by restricting the ability to speak in the meeting, restricting the ability to hear or see certain content shared during the meeting, or by restricting access to other meeting features such as joining breakout rooms or text chatting with other participants in the meeting.

[0035]

[0037] Users should understand that even when using a client device with a video conferencing provider 110 that has an authenticated identity and can identify the user, they may choose to participate in a meeting anonymously and refuse to provide user identification information to the video conferencing provider 110. The video conferencing provider 110 may determine whether or not to allow such anonymous users to use the services provided by the video conferencing provider 110. Anonymous users, regardless of the reason for anonymity, may be restricted as described above with respect to users using telephone equipment, and in some cases may be prevented from accessing certain meetings or other services, or may be completely prevented from accessing the video conferencing provider.

[0036]

[0038] Referring again to the video conferencing provider 110, in some examples, this allows client devices 140-160 to encrypt their respective video and audio streams to help improve privacy in the meeting. Encryption may be provided between client devices 140-160 and the video conferencing provider 110, or in an end-to-end configuration where the multimedia streams transmitted by client devices 140-160 are not decrypted until they are received by another client device 140-160 participating in the meeting. Encryption may also be provided only during a portion of the communication; for example, encryption may be used for unencrypted communication across international borders.

[0037]

[0039] Client-to-server encryption can be used to protect communication between client devices 140-160 and the video conferencing provider 110, while allowing the video conferencing provider 110 to access the decrypted multimedia stream to perform certain actions, such as recording the meeting for participants or generating a transcript of the meeting for participants. End-to-end encryption can be used to keep the meeting completely private to participants without worrying about the video conferencing provider 110 accessing the meeting content. Any suitable encryption method can be used, including key-pair encryption of the stream. For example, to provide end-to-end encryption, a client device of the conference host can obtain the public key of each of the other client devices participating in the meeting and securely exchange sets of keys to encrypt and decrypt multimedia content transmitted during the meeting. Thus, client devices 140-160 can communicate securely with each other during the meeting. Furthermore, in some examples, certain types of encryption may be limited by the type of device participating in the meeting. For example, telephone equipment may lack the ability to encrypt and decrypt multimedia streams. Therefore, while encrypting multimedia streams may often be desirable, it is not essential as it may prevent some users from participating in the meeting.

[0038]

[0040] Using the exemplary system shown in Figure 1, users can create and join meetings using their respective client devices 140–180 via a video conferencing provider 110. Furthermore, such a system allows users to utilize a wide variety of different client devices 140–180, ranging from conventional standards-based video conferencing hardware to dedicated video conferencing equipment, laptops or desktop computers, handheld devices, and legacy telephone equipment.

[0039]

[0041] Referring now to Figure 2, Figure 2 shows an exemplary system 200 in which a video conferencing provider 210 provides video conferencing functionality to various client devices 220-250. The client devices 220-250 include two conventional computing devices 220-230, dedicated equipment for the video conference room 240, and telephone equipment 250. Each client device 220-250 communicates with the video conferencing provider 210 via a communication network such as the Internet for client devices 220-240 or the PSTN for client device 250, generally as described above with respect to Figure 1. The video conferencing provider 210 also communicates with one or more user identity providers 215, which can authenticate various users to the video conferencing provider 210, generally as described above with respect to Figure 1.

[0040]

[0042] In this example, the video conferencing provider 210 uses multiple different servers (or groups of servers) to provide different aspects of video conferencing functionality, thereby enabling various client devices to create and participate in video conferences. The video conferencing provider 210 uses one or more real-time media servers 212, one or more network service servers 214, one or more video room gateways 216, and one or more telephone gateways 218. Each of these servers 212-218 is connected to one or more communication networks, enabling them to collectively provide client devices 220-250 with access to and participation in one or more video conferences.

[0041]

[0043] The real-time media server 212 provides multiplexed multimedia streams to conference participants, such as client devices 220-250 shown in Figure 2. While video and audio streams typically originate on each client device, they are transmitted from client devices 220-250 to the video conferencing provider 210 via one or more networks received by the real-time media server 212. The real-time media server 212 determines the optimal protocol based on factors such as proxy settings and the presence of firewalls. For example, a client device might select UDP, TCP, TLS, or HTTPS for audio and video, and UDP for content screen sharing.

[0042]

[0044] Next, the real-time media server 212 multiplexes various video and audio streams based on the target client devices and communicates the multiplexed streams to each client device. For example, the real-time media server 212 receives audio and video streams from client devices 220-240 and only the audio stream from client device 250. Then, the real-time media server 212 multiplexes the streams received from devices 230-250 and provides the multiplexed streams to client device 220. The real-time media server 212 is adaptive, for example, in how it provides these streams, by reacting to changes in the real-time network and clients. For example, the real-time media server 212 can monitor client bandwidth, CPU usage, memory, and network I / O parameters, as well as network parameters such as packet loss, latency, and jitter, to determine how to change how the streams are provided.

[0043]

[0045] Client device 220 receives the stream, performs any decoding, decoding, and demultiplexing on the received stream, and then outputs audio and video using the client device's video and audio equipment. In this example, the real-time media server does not multiplex the client device's own video and audio feeds when sending the stream to client device 220. Instead, each client device 220-250 receives only multimedia streams from other client devices 220-250. For example, in the case of a telephone device lacking video capabilities, such as client device 250, the real-time media server 212 delivers only the multiplexed audio stream. Client device 220 can receive multiple streams for a particular communication, allowing client device 220 to switch between streams to provide a higher quality of service.

[0044]

[0046] In addition to multiplexing multimedia streams, in some examples, the real-time media server 212 can also decrypt incoming multimedia streams. As mentioned above, the multimedia streams may be encrypted between client devices 220-250 and the video conferencing system 210. In some such examples, the real-time media server 212 can decrypt the incoming multimedia streams, multiplex the multimedia streams appropriately for various clients, and encrypt the multiplexed streams for transmission.

[0045]

[0047] As described above with respect to Figure 1, the video conferencing provider 210 can provide certain functions with respect to unencrypted multimedia streams at the user's request. For example, the conference host may request that the conference be recorded or that a transcript of the audio stream be prepared, which may then be performed by the real-time media server 212 using the decrypted multimedia stream, or the recording or transcription function may be offloaded to a dedicated server (or multiple servers) for recording audio and video streams, such as a cloud recording server. In some examples, the video conferencing provider 210 can allow conference participants to notify other conference participants of inappropriate behavior or content in the conference. Such a notification may trigger the real-time media server 212 to record a portion of the conference for review by the video conferencing provider 210. Further functions can be implemented to take action based on the decrypted multimedia stream at the video conferencing provider, such as monitoring video or audio quality, or adjusting or modifying the media encoding mechanism.

[0046]

[0048] It should be understood that multiple real-time media servers 212 may be involved in the communication of data for a single conference, and that multimedia streams may be routed through multiple different real-time media servers 212. Furthermore, the various real-time media servers 212 do not have to be jointly located, but instead may be located in multiple different geographical locations, thereby enabling high-quality communication between clients distributed across a wide geographical area, such as located in different countries or different continents. In addition, in some examples, one or more of these servers may be jointly located at a client's facility, e.g., a company or other organization. For example, each different geographical area may have one or more real-time media servers 212 to enable client devices within the same geographical area to send and receive multimedia streams with a high-quality connection to the video conferencing provider 210 via a local server 212, rather than connecting to a real-time media server located in a different country or different continent. The local real-time media server 212 can then communicate with the physically distant server using a high-speed network infrastructure, such as an internet backbone network, which the client devices 220-250 themselves might otherwise not have direct access to. Therefore, the routed multimedia stream may be distributed across the entire video conferencing system 210, including many different real-time media servers 212.

[0047]

[0049] Turning to the network service servers 214, these servers 214 provide administrative functions to enable client devices to create or join meetings, send invitations to meetings, create or manage user accounts or subscriptions, and perform other related functions. Furthermore, these servers may be configured to perform different functions or operate at different levels of the hierarchy, for example, for specific areas or locations, in order to manage parts of the video conferencing provider under a set of monitoring servers. When client devices 220-250 access the video conferencing provider 210, they typically communicate with one or more network service servers 214 to access their accounts or to join meetings.

[0048]

[0050] In this example, when client devices 220-250 first contact the video conferencing provider 210, they are routed to the network service server 214. The client devices can then provide user access credentials, such as a username and password or single sign-on credentials, to obtain authenticated access to the video conferencing provider 210. This process may include the network service server 214 contacting the user identity provider 215 to verify the provided credentials. Once the user credentials are accepted, the client devices 214 can interact with the network service server 214 to perform administrative functions, such as updating user account information if the user has identity with the video conferencing provider 210, or scheduling a new meeting.

[0049]

[0051] In some cases, a user can access the video conferencing provider 210 anonymously. When communicating anonymously, client devices 220-250 can communicate with one or more network service servers 214, but only provide information to create or join a meeting, depending on the functions the video conferencing provider allows anonymous users to use. For example, an anonymous user can use client 220 to access the video conferencing provider and provide a meeting ID and passcode. The network service server 214 can use the meeting ID to identify upcoming or ongoing meetings and verify that the passcode is correct for the meeting ID. After doing so, the network service server 214 can then communicate information to the client device 220 to enable it to join the meeting and communicate with the appropriate real-time media server 212.

[0050]

[0052] When a user wants to schedule a meeting, they can choose the option to schedule a new meeting (anonymous or authenticated), and then select various meeting options such as the date and time of the meeting, the duration of the meeting, the type of encryption to use, one or more users to invite, privacy controls (e.g., not allowing anonymous users, preventing screen sharing, manually allowing participation in the meeting), and meeting recording options. The network service server 214 can then create and store a meeting record of the scheduled meeting. When the scheduled meeting time arrives (or within a predetermined threshold period), the network service server 214 can accept requests to join the meeting from various users.

[0051]

[0053] To process requests to join a meeting, the network service server 214 can receive meeting information, such as the meeting ID and passcode, from one or more client devices 220-250. The network service server 214 finds the meeting record corresponding to the provided meeting ID, and then checks whether the scheduled start time of the meeting has arrived, whether the meeting host has started the meeting, and whether the passcode matches the passcode in the meeting record. If the request is made by a host, the network service server 214 activates the meeting and connects the host to the real-time media server 212, enabling the host to begin sending and receiving multimedia streams.

[0052]

[0054] When the host starts a conference, a conference record is created, and subsequent users requesting access are accepted into the conference if the passcode matches the passcode provided by the requesting client devices 220-250. In some examples, additional access controls may also be used. However, if the network service server 214 determines to accept the requesting client devices 220-250 into the conference, the network service server 214 identifies a real-time media server 212 for processing multimedia streams with the requesting client devices 220-250 and provides the client devices 220-250 with information to connect to the identified real-time media server 212. Additional client devices 220-250 may be added to the conference when requesting access via the network service server 214.

[0053]

[0055] After joining a meeting, client devices send and receive multimedia streams via the real-time media server 212, but can also communicate with the network service server 214 as needed during the meeting. For example, if a meeting host leaves the meeting, the network service server 214 can appoint another user as the new meeting host and assign host management privileges to that user. The host may have administrative privileges that enable them to manage the meeting, such as enabling or disabling screen sharing, muting or removing users from the meeting, creating sub-meetings or "breakout" rooms, and recording the meeting. Such functions can be managed by the network service server 214.

[0054]

[0056] For example, if a host wants to remove a user from a meeting, the host can identify the user and issue a command via the user interface on the client device. The command may also be sent to the network service server 214, which may then disconnect the identified user from the corresponding real-time media server 212. If a host wants to create breakout rooms for one or more meeting participants to join, such a command may be processed by the network service server 214, which may create a new meeting record corresponding to the breakout rooms and then connect one or more meeting participants to the breakout rooms, just as it initially accepted the participants into the meeting itself.

[0055]

[0057] In addition to creating and managing ongoing meetings, the network service server 214 can also be responsible for closing and discarding meetings after they have finished. For example, a meeting host can issue a command to terminate an ongoing meeting, which is then sent to the network service server 214. The network service server 214 can then remove any remaining participants from the meeting, communicate with one or more real-time media servers 212 to stop streaming the meeting's audio and video, deactivate the meeting by, for example, removing the meeting's corresponding passcode from the meeting record, or delete the meeting record corresponding to the meeting. Thus, if a user later attempts to access the meeting, the network service server 214 can reject the request.

[0056]

[0058] Depending on the features provided by the video conferencing provider, the network service server 214 may provide additional features, such as providing private meeting functions for the organization, special types of meetings (e.g., webinars), etc. Such features may be provided according to the various examples of video conferencing providers described in this explanation.

[0057]

[0059] Referring here to the video room gateway server 216, these servers 216 provide an interface between dedicated video conferencing hardware, such as that which may be used in a dedicated video conference room. Such video conferencing hardware may include one or more cameras and microphones, and a computing device designed to receive video and audio streams from each of the cameras and microphones and connect to the video conferencing provider 210. For example, the video conferencing hardware may be provided by the video conferencing provider to one or more of its subscribers, who may provide access credentials to the video conferencing hardware for use in connecting to the video conferencing provider.

[0058]

[0060] The video room gateway server 216 provides special authentication and communication with dedicated video conferencing hardware that may not be available to other client devices 220-230, 250. For example, the video conferencing hardware may register with a video conferencing provider when it is first installed, and the video room gateway can authenticate the video conferencing hardware using such registration, as well as information provided to the video room gateway server 216 when the dedicated video conferencing hardware connects, such as device ID information, subscriber information, hardware functionality, and hardware version information. Upon receiving such information and authenticating the dedicated video conferencing hardware, the video room gateway server 216 can interact with the network service server 214 and the real-time media server 212 to enable the video conferencing hardware to create or join a conference hosted by the video conferencing provider 210.

[0059]

[0061] Referring here to the telephone gateway server 218, these servers 218 enable and facilitate the participation of telephone equipment in conferences hosted by the video conferencing provider. Since telephone equipment communicates using the PSTN and does not use computer networking protocols such as TCP / IP, the telephone gateway server 218 acts as an interface that translates between the PSTN and the networking system used by the video conferencing provider 210.

[0060]

[0062] For example, if a user uses a telephone device to connect to a conference, the user can dial a telephone number corresponding to one of the video conferencing provider's telephone gateway servers 218. The telephone gateway server 218 answers the call and generates an audio message requesting information from the user, such as a conference ID and passcode. The user can input such information using buttons on the telephone device, for example, by sending a dual-tone multi-frequency ("DTMF") audio signal to the telephone gateway server 218. The telephone gateway server 218 determines the numbers or characters entered by the user, generally as described above, and provides the conference ID and passcode information to the network service server 214, along with a request to join or start the conference. Once the telephone client device 250 is accepted into the conference, the telephone gateway server 218 joins the conference on behalf of the telephone device.

[0061]

[0063] After joining the conference, the telephone gateway server 218 receives audio streams from the telephone equipment and provides them to the corresponding real-time media server 212, receives audio streams from the real-time media server 212, decodes them, and provides the decoded audio to the telephone equipment. Thus, the telephone gateway server 218 essentially operates as a client device, while the telephone equipment primarily acts as an input / output device for the corresponding telephone gateway server 218, such as a microphone and speaker, thereby enabling the user of the telephone equipment to participate in the conference even if they are not using a computing device or video.

[0062]

[0064] It should be understood that the components of the video conferencing provider 210 described above are merely examples of such devices and exemplary architectures. Some video conferencing providers may offer more or fewer features than those described above, and it may not be possible to separate functions into different types of servers as described above. Instead, any suitable server and network architecture can be used, according to different examples.

[0063]

[0065] Referring now to Figure 3, Figure 3 shows a simplified system 300 that enables users to participate in end-to-end ("E2E") encrypted video conferencing. The system includes two client devices 320, 330 and a video conferencing provider 310. The client devices 320, 330 are connected to the video conferencing provider 310 via one or more communication networks (not shown), generally as described above with respect to Figures 1 and 2.

[0064]

[0066] In an end-to-end encrypted video conference, each participant joins the video conference on their respective client device 320-330, and the host establishes a conference key used to encrypt and decrypt the audio and video streams. Each participant also has their own unique public / private key pair that can be used to communicate with each other, and each participant's public key is made public or distributed in any appropriate way, such as by registering with a trusted entity or by using the private key to generate an encrypted signed name, allowing the host or other participants to verify the signature using a publicly available copy of the public key.

[0065]

[0067] Once each participant's public key has been verified, the host can securely distribute the meeting key to participants by encrypting it using each participant's public key. For example, the host can generate an encrypted message containing the meeting key and send it to each participant using their respective public key. Upon receiving and successfully decrypting the meeting key, each participant can then encrypt and decrypt the meeting content.

[0066]

[0068] In the system 300 shown in Figure 3, the client device 320 first connects to the video conferencing provider 310 and requests that the video conferencing provider create a new meeting. Once the meeting is created, the client device 320 is designated as the host of the meeting and establishes a meeting key to be used to provide E2E encryption in the meeting, but does not provide it to the video conferencing provider 310. Subsequently, the participant client device 330 joins the meeting and uses its private key to generate an encrypted signed message which it provides to the host client device 320, which then verifies the message using the participant's public key. After verifying the public key, the host client device 320 encrypts the meeting key using the participant's public key and sends it to the participant client device 330, which then decrypts the meeting key. Once the meeting key is successfully received and decrypted by the participant client device 330, it can begin transmitting encrypted audio and video using the meeting key.

[0067]

[0069] In this example, each participant generates a per-stream encryption key by calculating a new key using the non-secret stream ID of each data stream they transmit (e.g., audio and video), and then encrypts their audio and video streams using the corresponding stream encryption key. The video conferencing provider receives the various encrypted streams, multiplexes them as described above with respect to Figures 1 and 2, and distributes them to the various participant client devices 320, 330. Each client device 320, 330 can then decrypt the incoming stream using the conference key and view the video conference content.

[0068]

[0070] However, as part of this process, the video conferencing provider 310 does not have access to the conference key. Therefore, the video conferencing provider 310 cannot decode the various audio and video streams. However, since the individual streams are received separately from the various participants, the video conferencing provider 310 can identify the source of each stream and, therefore, can properly multiplex the streams for distribution to each participant.

[0069]

[0071] Referring here to Figure 4, Figure 4 shows an exemplary method 400 for locking an encrypted video conference. Method 400 in Figure 4 is described with respect to the system shown in Figure 3. However, any suitable system provided herein may be used, including any of the systems shown in Figures 1-3 or Figure 6.

[0070]

[0072] In block 410, the host's client device 320 obtains the conference encryption key. Any suitable technique can be used to generate the conference encryption key. For example, the conference encryption key may include an encryption key pair generated according to any suitable encryption key pair technique, such as using elliptic curves. In some examples, the conference encryption key may be a single encryption key.

[0071]

[0073] In block 420, the host's client device 320 sends a request to the video conferencing provider 310 to start an encrypted video conference. The request may identify specific conference information, such as a conference identifier and passcode. It may also include one or more options for the conference, including the option to use end-to-end encryption. Alternatively, the request to use end-to-end encryption may be sent separately from the request to start the conference.

[0072]

[0074] In block 430, the host's client device 320 distributes the conference encryption key to each of the multiple participants. For example, the host's client device can obtain the public encryption key from each participant of the encrypted video conference and, for each participant, encrypt a copy of the conference encryption key using the participant's public key. The host's client device 320 can then send each encrypted conference encryption key to each participant based on the public key used.

[0073]

[0075] The host's client device 320 also obtains the public encryption key of the encryption key pair. As with block 410, any suitable technique can be used to generate the encryption key pair. In this example, the key pair is generated using an elliptic curve function, and the host's client device 320 obtains one of the encryption keys of the encryption key pair, which becomes the public encryption key. The host's client device 320 then uses the public encryption key to encrypt the conference encryption key.

[0074]

[0076] In block 440, the host's client device 320 receives an instruction that the encrypted video conference should be locked. In other words, only the current participants of the encrypted video conference can access it. Additional participants cannot join. In some exemplary systems, if a current participant unintentionally leaves the encrypted video conference, for example due to an insufficient internet connection, they can rejoin the encrypted video conference even though it is locked.

[0075]

[0077] In one example, the host can select an option from the user interface of a video conferencing application running on the host's client device 320, which triggers an instruction to the video conferencing software. The video conferencing software running on the host's client device 320 can respond by sending a notification to each participant in the video conference indicating that the conference is currently locked. In one exemplary system, the notification is presented as an emoji on each participant's client device. In another example, an overlay indicating that the conference is locked appears on the user interface.

[0076]

[0078] In some cases, video conferencing software can automatically lock a video conference once all invited guests have joined. For example, video conferencing software may have access to a meeting invitation or calendar entry that identifies one or more invitees to the meeting. In some cases, video conferencing software may generate and send invitations to the meeting. Thus, once participants join the meeting, the video conferencing software can track which participants have joined. After the last participant has joined, the video conferencing software may receive instructions based on the fact that the last participant has joined the meeting.

[0077]

[0079] In block 450, the host's client device 320 receives a request to allow additional participants. The request may also be triggered when a prospective participant clicks a link to access the video conferencing provider 310, which then presents the additional participants to the encrypted video conference.

[0078]

[0080] In block 460, the host's client device 320 determines whether this additional participant is on the original participant list. The original participant list is the list of participants who were present at the encrypted video conference when the host locked it. The participant list may include a public key to enable verification that the participant list is authentic. As mentioned above, an original participant might attempt to rejoin the conference after being unintentionally disconnected, for example, due to an insufficient internet connection.

[0079]

[0081] In block 470, the host's client device 320 determined that the additional participant was not in the original participant list. Therefore, the host's client device 320 rejected the additional participant, and the additional participant was not accepted into the meeting. In some cases, the meeting continued afterward.

[0080]

[0082] In this example, neither the host nor the other participants inherently trust the video conferencing provider 310. For example, if the video conferencing provider 310 presents a participant, the host's client device 320 will not automatically allow the participant. Figure 4 illustrates the host's client device 320 performing these steps, but in some examples, a trusted server, such as a server managed by the host's organization, could instead take on the role of approving or denying additional participants.

[0081]

[0083] In block 480, the host's client device 320 terminates the current meeting in response to the refusal of an additional participant, and then restarts the encrypted meeting as a second encrypted video conference. Such an example can provide a higher level of security by changing the encryption key. In an example where the meeting encryption key is changed during a video conference, the host's client device 320 can also send a notification to the video conferencing provider 310 that the meeting encryption key has been changed, along with a corresponding timestamp of when the participant changed to use the new meeting encryption key. However, in some examples, when a new meeting encryption key is sent, a notification that the meeting encryption key has been changed is provided.

[0082]

[0084] In block 490, the host's client device 320 determined that the additional participant was present in the original participant list. In the example shown, the additional participant is then accepted into the encrypted video conference, and the video conference continues as before.

[0083]

[0085] In some exemplary systems, the host may leave the meeting and be replaced by another participant who then becomes the host. In some such examples, the new host's client device is responsible for rejecting (or accepting) additional participants. In other examples, the encrypted meeting may be restarted on the new host of the new encrypted meeting when the new host replaces the original host.

[0084]

[0086] It should be understood that method 400 described above is merely one example provided in this disclosure. In other examples, the blocks described above may be executed in a different order, or one or more blocks may be omitted. For example, the order of blocks 450-490 may be in any suitable order according to other examples, or they may be omitted, or additional steps may be added.

[0085]

[0087] Referring here to Figure 5, Figure 5 shows an exemplary method 500 for locking an encrypted video conference. Method 500 in Figure 5 is described in relation to the system shown in Figure 3. However, any suitable system provided by this disclosure, including any of the systems shown in Figures 1 to 3 or Figure 6, may be used.

[0086]

[0088] In block 510, the video conferencing provider 410 initiates an encrypted video conference. The process for initiating such a video conference is described, for example, in relation to Figure 4.

[0087]

[0089] In block 520, the video conferencing provider 410 receives a notification that the encrypted video conference has been locked. In this example, the video conferencing provider 310 receives the notification from the host computing device 320. In some examples, the video conferencing provider 410 may record the fact that the conference has been locked. For example, the video conferencing provider 410 may identify the participants in the video conference at the time the lock is indicated for use when additional participants attempt to join the encrypted video conference.

[0088]

[0090] In block 530, the video conferencing provider 410 receives a request to allow additional participants. For example, a user of a client device may access a link to an encrypted video conference. In response, the video conferencing provider 410 may present additional participants to the encrypted video conference. For example, the video conferencing provider 410 may send a notification to the host's client device 320 indicating that a new participant is attempting to join the video conference.

[0089]

[0091] In block 540, the video conferencing provider 410 receives a notification that an additional participant has been rejected. In the example described in relation to Figure 4, the meeting is locked, and the additional participant may be rejected because they were not on the original list of participants in the encrypted video conference when it was locked by the host.

[0090]

[0092] In block 550, the video conferencing provider terminates the encrypted video conference. For example, the host client device 320 may send a request to terminate the encrypted video conference in response to receiving and then being rejected a request from an additional participant to join the encrypted video conference. In some examples, the video conferencing provider may start another encrypted video conference that the original participants can join after the original locked encrypted video conference has been terminated. In other words, the original encrypted video conference can be terminated and then automatically resumed. If the conference is resumed, a new link can be sent to the original participants.

[0091]

[0093] Referring here to Figure 6, Figure 6 shows an exemplary computing device 600 suitable for use in an exemplary system or method for identifying risky meetings according to the present disclosure. The exemplary computing device 600 includes a processor 610 that communicates with memory 620 and other components of the computing device 600 using one or more communication buses 602. The processor 610 is configured to execute processor-executable instructions stored in memory 620 to perform one or more methods for identifying risky meetings according to different examples, such as some or all of the exemplary method 400 described with respect to Figure 4. In this example, the computing device also includes one or more user input devices 650, such as a keyboard, mouse, touchscreen, microphone, etc., for accepting user input. The computing device 600 also includes a display 640 for providing visual output to the user. The computing device also includes a video input device 260, such as a camera.

[0092]

[0094] The computing device 600 also includes a communication interface 640. In some examples, the communication interface 630 may enable communication over one or more networks, including local area networks ("LANs"), wide area networks such as the Internet ("WANs"), metropolitan area networks ("MANs"), and point-to-point or peer-to-peer connections. Communication with other devices can be achieved using any suitable network protocol. For example, one suitable network protocol may include the Internet Protocol ("IP"), the Transmit Control Protocol ("TCP"), the User Datagram Protocol ("UDP"), or a combination thereof such as TCP / IP or UDP / IP.

[0093]

[0095] While some examples of methods and systems described herein are described in relation to software running on various machines, methods and systems may also be implemented as hardware specifically configured for performing the various methods described herein, such as field-programmable gate arrays (FPGAs). For example, examples can be implemented in digital electronic circuits, or in computer hardware, firmware, software, or a combination thereof. In one example, a device may include one or more processors. The processors include computer-readable media such as random access memory (RAM) coupled to the processors. The processors execute computer-executable program instructions stored in memory, such as executing one or more computer programs. Such processors may include microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and state machines. Such processors may further include programmable electronic devices such as PLCs, programmable interrupt controllers (PICs), programmable logic devices (PLDs), programmable read-only memory (PROMs), electronically programmable read-only memory (EPROMs or EEPROMs), or other similar devices.

[0094]

[0096] Such a processor may include, or communicate with, a medium capable of storing processor-executable instructions that, when executed by the processor, cause the processor to perform the method of the Disclosure, either to be executed by the processor or with assistance from the processor. Examples of non-temporary computer-readable media include, but are not limited to, electronic, optical, magnetic, or other storage devices that can provide processor-executable instructions to a processor, such as a processor in a web server. Other examples of non-temporary computer-readable media include, but are not limited to, floppy disks, CD-ROMs, magnetic disks, memory chips, ROMs, RAMs, ASICs, configured processors, all optical media, all magnetic tapes or other magnetic media, or any other media that a computer processor can read. The described processors and processes may reside in one or more structures or be distributed across one or more structures. The processor may include code for performing the method (or part of the method) of the Disclosure.

[0095]

[0097] The above-mentioned examples are provided for illustrative and explanatory purposes only and are not intended to be exhaustive or to limit this disclosure to the exact form disclosed. Numerous modifications and adaptations thereto will be apparent to those skilled in the art without departing from the spirit and scope of this disclosure.

[0096]

[0098] References to examples or embodiments herein mean that certain features, structures, operations, or other characteristics described in relation to the examples may be included in at least one embodiment of this disclosure. This disclosure is not limited to any specific example or embodiment described herein. The appearance of phrases such as “in one example,” “in one embodiment,” or “in an embodiment,” or variations thereof, in various parts of this specification does not necessarily refer to the same example or embodiment. Any particular feature, structure, operation, or other characteristic described herein in relation to an example or embodiment may be combined with other features, structures, operations, or other characteristics described in relation to any other example or embodiment.

[0097]

[0099] The use of the word "or" in this specification is intended to cover both inclusive and exclusive OR conditions. In other words, A or B or C includes any or all of the following alternative combinations that are appropriate for a particular use: A only, B only, C only, A and B only, A and C only, B and C only, and A, B and C.

Claims

1. Obtaining the conference encryption key, Sending a request from a client device to a video conferencing provider to start an encrypted video conference, wherein the encrypted video conference includes multiple participants. Distributing the aforementioned conference encryption key to each of the multiple participants, Receiving instructions that an encrypted video conference should be locked, After receiving the instruction that the encrypted video conference should be locked, receiving a request to accept additional participants into the encrypted video conference, To determine whether the additional participant is one of the aforementioned multiple participants, A method comprising: refusing the request to accept the additional participant into the encrypted video conference in response to determining that the additional participant is not one of the aforementioned group of participants.

2. Receiving a request to accept a second additional participant into the encrypted video conference, The method according to claim 1, further comprising: in response to determining that the second additional participant is one of the plurality of participants, accepting the request to accept the second additional participant into the encrypted video conference.

3. The method according to claim 1, wherein the instruction that the encrypted video conference should be locked is triggered by a first participant acting as the host.

4. After receiving the instruction that the encrypted video conference should be locked, receiving a request to reassign the host role to a second participant who was participating in the encrypted video conference, The method according to claim 3, further comprising reassigning the role of the host to the second participant.

5. To generate a notice indicating that the aforementioned request for acceptance has been rejected, The method according to claim 3, further comprising providing the notification to the first participant.

6. The method according to claim 1, further comprising terminating the encrypted video conference in response to determining that the additional participant is not one of the plurality of participants.

7. The method according to claim 6, wherein the encrypted video conference is a first encrypted video conference, further comprising sending a request from the client device to the video conferencing provider to start a second encrypted video conference, the second encrypted video conference comprising the plurality of participants.

8. The method according to claim 1, further comprising notifying each of the plurality of participants that the video conference is locked in response to receiving the instruction that the encrypted video conference should be locked.

9. The method according to claim 8, wherein notifying each participant includes generating an overlay message on the user interface in which the video conference is displayed.

10. The video conferencing provider enables the initiation of an encrypted video conference for multiple participants, Receiving instructions from the host of the encrypted video conference that the encrypted video conference should be locked, After receiving the instruction that the encrypted video conference should be locked, receiving a request to accept additional participants into the encrypted video conference, Receiving a notification that the request to accept the additional participants into the encrypted video conference has been denied, A method comprising sending a message to the additional participant indicating that their request to join the video conference has been denied.

11. In response to receiving notification that the request to accept the additional participants into the encrypted video conference has been denied, Terminating the aforementioned encrypted video conference, The method according to claim 10, further comprising resuming the encrypted video conference including the plurality of participants.

12. Non-temporary computer-readable media and Communication interface, The system comprises a non-temporary computer-readable medium and a processor communicatively coupled to the communication interface, wherein the processor executes processor-executable instructions stored in the non-temporary computer-readable medium. Obtaining the conference encryption key, Sending a request from the client device to the video conferencing provider to start an encrypted video conference with multiple participants, Distributing the aforementioned conference encryption key to each of the multiple participants, Receiving instructions that the encrypted video conference should be locked, After receiving the instruction that the encrypted video conference should be locked, receiving a request to accept additional participants into the encrypted video conference, To determine whether the additional participant is one of the aforementioned multiple participants, A system configured to, in response to determining that the additional participant is not one of the aforementioned participants, reject the request to accept the additional participant into the encrypted video conference.

13. The system according to claim 12, wherein the processor is configured to execute further processor-executable instructions stored in the non-temporary computer-readable medium in response to the request to accept the additional participant into the encrypted video conference, in response to the determination that the additional participant is one of the plurality of participants.

14. The system according to claim 12, wherein the processor is configured to execute further processor-executable instructions stored in the non-temporary computer-readable medium to terminate the encrypted video conference in response to the processor determining that the additional participant is not one of the plurality of participants.

15. The system according to claim 14, wherein the instruction that the encrypted video conference should be locked is triggered by a first participant acting as the host.

16. The processor executes further processor-executable instructions stored in the non-temporary computer-readable medium. After receiving the instruction that the encrypted video conference should be locked, a request is received to reassign the host role to a second participant who was participating in the encrypted video conference, The system according to claim 15, configured to reassign the role of the host to the second participant.

17. The system according to claim 14, wherein the encrypted video conference is a first encrypted video conference, the processor is configured to execute further processor-executable instructions stored in the non-temporary computer-readable medium to send a request from the client device to the video conference provider to start a second encrypted video conference, and the second encrypted video conference includes the plurality of participants.

18. The system according to claim 12, wherein the processor is configured to execute further processor-executable instructions stored in the non-temporary computer-readable medium in response to receiving the instruction that the encrypted video conference should be locked, in order to notify each of the plurality of participants that the video conference is locked.

19. Non-temporary computer-readable media and Communication interface, Microphone and, Image sensor and, The system comprises a non-temporary computer-readable medium, a communication interface, a microphone, and a processor communicatively coupled to the image sensor, wherein the processor executes processor-executable instructions stored in the non-temporary computer-readable medium. The video conferencing provider enables the initiation of an encrypted video conference for multiple participants, Receiving instructions from the host of the encrypted video conference that the encrypted video conference should be locked, After receiving the instruction that the encrypted video conference should be locked, receiving a request to accept additional participants into the encrypted video conference, A system configured to receive a notification that the request to accept the additional participants into the encrypted video conference has been denied.

20. In response to receiving notification that the request to accept the additional participants into the encrypted video conference has been denied, the processor executes further processor-executable instructions stored in the non-temporary computer-readable medium. Terminating the aforementioned encrypted video conference, The system according to claim 14, configured to resume the encrypted video conference including the aforementioned multiple participants.

Images