A system and method for controlling online meeting attendance.
The video conferencing system addresses unauthorized access by using unique user identifiers to control meeting attendance, ensuring only valid participants can join, thereby maintaining meeting confidentiality and preventing disruptions.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- ZOOM COMMUNICATIONS INC
- Filing Date
- 2022-01-13
- Publication Date
- 2026-06-02
AI Technical Summary
Existing video conferencing systems face issues with unauthorized users joining meetings due to the use of common access control information, leading to breaches of confidentiality and disruption.
A video conferencing system that generates unique user identifiers for each invitee, allowing hosts to control attendance by matching user identifiers with contact information during the invitation process, ensuring only valid participants can join the meeting.
Effectively restricts meeting participation to invitees only, enhancing meeting confidentiality and preventing disruptions by unauthorized users.
Smart Images

Figure 0007869228000001 
Figure 0007869228000002 
Figure 0007869228000003
Abstract
Description
Technical Field
[0001]
[0001] This application generally relates to video conferencing, and more particularly to systems and methods for controlling attendance at online meetings.
Background Art
[0002]
[0002] Video conferencing has become a common way for people to gather as a group, without being in the same physical location. Participants are invited to a video conference and can participate from a personal computer or phone, and can see, hear, and talk to each other as if they were in 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
[0003]
[0003] Various examples of systems and methods for controlling attendance at online meetings are described. One exemplary method includes generating meeting information for a meeting, the meeting information including a meeting identifier; obtaining a set of guest identifiers corresponding to a plurality of meeting guests, each guest identifier being unique within the set of guest identifiers and corresponding to a different meeting guest; starting a meeting by a video conferencing system using the meeting identifiers; receiving a first request from a first client device by the video conferencing system to join the meeting, the first request including a meeting identifier; receiving a first user identifier corresponding to a first user, the first user identifier not being in the set of guest identifiers; determining that the first user is the first meeting guest among a plurality of meeting guests based on the correspondence between the first user identifier and the guest identifiers in the set of guest identifiers; and connecting the first client device to the meeting in response to the determination that the first user is the first meeting guest.
[0004]
[0004] Another exemplary method includes obtaining meeting information associated with a meeting, the meeting information including a meeting identifier; receiving a first request from a first client device by the video conferencing system to join a meeting, the first request including a meeting identifier; receiving a first user identifier corresponding to a first user; accessing a set of guest identifiers corresponding to a plurality of meeting guests invited to the meeting, each guest identifier being unique within the set of guest identifiers and corresponding to a different meeting guest; determining that the first user is the first meeting guest among the plurality of meeting guests, based on the correspondence between the first user identifier and the guest identifiers in the set of guest identifiers, and determining that the first user identifier is not in the set of guest identifiers; and connecting the first client device to the meeting in response to the determination that the first user is the meeting guest among the plurality of meeting guests.
[0005]
[0005] An 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 executes processor-executable instructions stored in the non-temporary computer-readable medium to obtain meeting information associated with a meeting, the meeting information including a meeting identifier, and using the communication interface to receive a first request from a first client device to join a meeting by a video conferencing system, the first request including a meeting identifier, and responding to a first user via the communication interface. The system is configured to: receive a first user identifier; access a set of guest identifiers corresponding to multiple meeting guests invited to a meeting, where each guest identifier is unique within the set of guest identifiers and corresponds to a different meeting guest; determine that the first user is the first meeting guest among multiple meeting guests, based on the correspondence between the first user identifier and the guest identifiers in the set of guest identifiers, where the first user identifier is not in the set of guest identifiers; and, in response to the determination that the first user is a meeting guest among multiple meeting guests, connect the first client device to the meeting.
[0006]
[0006] One exemplary non-temporary computer-readable medium includes a processor executable instruction and is configured to cause the processor to: retrieve meeting information associated with a meeting, the meeting information including a meeting identifier; receive a first request from a first client device by a video conferencing system to join a meeting, the first request including a meeting identifier, via a communication interface; receive a first user identifier corresponding to a first user via the communication interface; access a set of guest identifiers corresponding to a plurality of meeting guests invited to the meeting, each guest identifier being unique within the set of guest identifiers and corresponding to a different meeting guest; determine that the first user is the first meeting guest among the plurality of meeting guests, based on the correspondence between the first user identifier and the guest identifier in the set of guest identifiers, and that the first user identifier is not in the set of guest identifiers; and connect the first client device to the meeting in response to the determination that the first user is a meeting guest among the plurality of meeting guests.
[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 video conferencing system that allows for control over attendance at online meetings. [Figure 2]This illustrates an exemplary video conferencing system that allows for control over attendance at online meetings. [Figure 3] This illustrates an exemplary video conferencing system that allows for control over attendance at online meetings. [Figure 4] This illustrates an exemplary video conferencing system that allows for control over attendance at online meetings. [Figure 5] This provides an example of how to control attendance at online meetings. [Figure 6] This provides an example of how to control attendance at online meetings. [Figure 7] This document describes exemplary computing devices suitable for use with any disclosed system or method. [Modes for carrying out the invention]
[0010]
[0012] Examples described herein are in the context of systems and methods for controlling attendance at online meetings. 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] Video conferencing systems allow users to create and attend video conferences (or "conferences") via various types of client devices. After joining a conference, participants receive audio and video streams or feeds (or "multimedia" streams or feeds) from other participants, presented along with a view of the audio from the video feeds and audio feeds of one or more of the other participants. Using these different modalities, participants can see and hear each other, engage more deeply, and generally have a richer experience despite not being physically present in the same space.
[0013]
[0015] To create a meeting, a person (referred to as the "host" or "meeting host") accesses a video conferencing system, creates a new meeting, and identifies one or more other people to invite to the meeting. In response to the host creating the meeting, the video conferencing system establishes the meeting by generating a meeting identifier and optionally a passcode or other access control information. The host can then send the meeting identifier (and access control information) to each invitee, for example, by email.
[0014]
[0016] Once the meeting begins, inviters can access and join the meeting using the meeting identifier and any provided access control information. If the inviter provides the meeting code and correct access control information, the user will be accepted into the meeting and able to interact with other participants. However, if the meeting code or access control information is incorrect, the user will be denied access to the meeting.
[0015]
[0017] However, the difficulty with such a system is that some video conferencing systems may use common access control information for all invitees. Therefore, instead of each user receiving individual access control information, such as a passcode, each user receives the same passcode as all other invitees. As a result, individuals who were not invited to the meeting but otherwise obtained the meeting identifier and passcode can join the meeting. This can lead to numerous problems, including breaches of confidentiality or disruption of meetings caused by malicious actors.
[0016]
[0018] To help prevent uninvited users from joining a meeting, the video conferencing system provided in this disclosure allows a host to invite users to a meeting as described above via a preferred communication mechanism, such as email. To send invitations, the host provides the video conferencing system with each invitee's contact information, such as their email address, social media handle, etc., as part of the invitation list. Once the host has added all desired invitees, the host instructs the video conferencing system to send invitations to the invitees.
[0017]
[0019] Once the host starts a meeting, invitees can access it using the meeting identifier and access control information from the meeting invitation they received. However, to prevent uninvited users from joining, each participant sends additional information called a "user identifier" to the video conferencing system. The user identifier may be a screen name or alias not used by the host to send the invitation, an account name or account identifier in the video conferencing system, or identity information from a trusted third party or identity provider (e.g., a company or other organization). Therefore, the host can provide an email address to the video conferencing system but does not provide (and cannot know) a user identifier to invitees. The video conferencing system can achieve this by only allowing the host to use contact information such as an email address, social media handle, or phone number. As mentioned above, when a user attempts to join a meeting, the user provides a user identifier as well as the meeting code and access control information. If the meeting code and access control information match the meeting information, the video conferencing system uses the user identifier to determine whether the user is a valid participant in the meeting. To do this, the video conferencing system determines the correspondence between the user identifier and contact information of the user on the invitation list. For example, if a user provides user account information for a video conferencing system, such as a user number or account name, the video conferencing system can determine whether the contact information is associated with the identified user account. If contact information matching an invitee on the invitation list is identified, the video conferencing system determines that the user is one of the invitees and accepts them into the meeting.
[0018]
[0020] Therefore, even though all meeting information is generally available to all invitees, a video conferencing system can control which users are accepted into a meeting if the meeting information is shared, for example, on social media. Furthermore, such a system does not require the meeting host to possess information about invitees other than their contact information. Moreover, it is difficult for one user to impersonate another user, as other invitees are unlikely to know or have access to the user identifiers of other invitees. By using such technology, a video conferencing system can effectively restrict meeting participants to invitees only, thereby helping to ensure the confidentiality of the meeting and prevent potential disruption from uninvited guests.
[0019]
[0021] This illustrative example is provided to introduce the reader to the general subject matter discussed herein, and the disclosure is not limited to this example. The following sections describe various additional, non-limiting examples and cases of systems and methods for controlling attendance at online meetings.
[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, via which various client devices 140-180 can participate in video conferences hosted by the video conferencing provider 110. For example, the video conferencing provider 110 can be placed 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 where the video conferencing provider 110 supplies components to enable a private organization to host private internal video conferences or to connect their system to the 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 can authenticate the user identities of one or more users to the video conferencing provider 110. In this example, the user identity provider 115 is operated by an entity different from the 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 the 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] To create a meeting with video conferencing provider 110, a user can use client devices 140-180 to contact video conferencing provider 110 and select the option to create a new meeting. Such options may be provided in a web page accessed by client devices 140-160, or in a client application executed by client devices 140-160. In the case of a telephone device, the user can be presented with an audio menu that can be navigated by pressing the numeric buttons of the telephone device. To create a meeting, video conferencing provider 110 can 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, whether the meeting is confidential or non-public, etc. After receiving various meeting settings, the video conferencing provider can create a record of the meeting, generate a meeting identifier, and, in some examples, a corresponding meeting password or passcode (or other authentication information), and all meeting information is provided to the meeting host.
[0024]
[0026] 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.
[0025]
[0027] 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.
[0026]
[0028] 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.
[0027]
[0029] 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.
[0028]
[0030] 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.
[0029]
[0031] 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.
[0030]
[0032] 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.
[0031]
[0033] 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.
[0032]
[0034] 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.
[0033]
[0035] 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.
[0034]
[0036] 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.
[0035]
[0037] 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.
[0036]
[0038] 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.
[0037]
[0039] 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.
[0038]
[0040] 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.
[0039]
[0041] 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.
[0040]
[0042] 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.
[0041]
[0043] 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.
[0042]
[0044] 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.
[0043]
[0045] 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.
[0044]
[0046] 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.
[0045]
[0047] 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.
[0046]
[0048] 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.
[0047]
[0049] 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.
[0048]
[0050] 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.
[0049]
[0051] 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.
[0050]
[0052] 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.
[0051]
[0053] 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.
[0052]
[0054] 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.
[0053]
[0055] 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.
[0054]
[0056] 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.
[0055]
[0057] 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.
[0056]
[0058] 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.
[0057]
[0059] 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.
[0058]
[0060] 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.
[0059]
[0061] 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.
[0060]
[0062] 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.
[0061]
[0063] 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.
[0062]
[0064] Referring now to Figure 3, Figure 3 shows an exemplary system 300 for controlling online meeting attendance, which includes components similar to those shown in Figures 1 and 2. In this example, the system includes a public user identity provider 315 that can establish an identity that can be used to access various online services, including video conferencing services provided by a video conferencing provider 310. In this example, when a user attempts to access a video conference hosted by the video conferencing provider 310, the video conferencing provider 310 attempts to verify each participant, for example, by communicating with the user identity provider 315.
[0063]
[0065] Once a user establishes an identity with the user identity provider 315, the user provides certain personal information such as their name, address, date of birth, and email address. The user identity provider 315 can then establish the user's identity and provide certain features such as an identity indicator (e.g., account or username) and an encrypted signature name that the user can use to access various online services. In some examples, a user can connect to a video conferencing provider 310, log in to an account with the video conferencing provider 310 using the user identity provider 315, and access the features provided by the video conferencing provider 310. However, in some examples, a participant or host of a video conference may not have, or may not have, an account with the video conferencing provider 310.
[0064]
[0066] To accommodate such unregistered users, the video conferencing provider 310 may require the user to provide a user identifier, such as identification information established with a user identity provider, before accepting the user into a video conference or before allowing the user to create a video conference. After receiving the user's identification information and any potentially additional information such as cryptographic information, the network service server 314 operated by the video conferencing provider 310 may communicate with the user identity provider 315 to verify that the identification information is valid and to authenticate the user. After verifying the user's identity, the video conferencing provider 310 may allow the user to accept into a scheduled meeting or to host a scheduled meeting.
[0065]
[0067] By using such publicly available user identity providers, it is possible to provide broader access to video conferencing services without requiring individuals to register with video conferencing providers. This reduces the burden on users who can instead use their existing identities.
[0066]
[0068] Referring to Figure 4, Figure 4 shows another exemplary system 400 for controlling attendance at an online meeting, which includes components similar to those shown in Figures 1-3. However, the system 400 shown in Figure 4 includes multiple client devices 440-460 connected to a private network 420, such as a corporate network. To access the private network 420, users must provide access credentials, such as a username and password, which are verified by an identity server 415. If a user provides valid credentials, they can access the private network 420 and the resources available through it.
[0067]
[0069] A user connected to the private network 420 may wish to use the video conferencing service provided by the video conferencing provider 410, but may not wish to register a user account with the video conferencing provider 410, as described above with respect to Figure 3. To accommodate such users, the video conferencing provider can verify the user in the same way as described above with respect to Figure 3. However, in this example, the network service server 414 operated by the video conferencing provider can communicate with the identity server 415 to authenticate users accessing the private network 420. Therefore, in this example, a user attempting to access the video conferencing provider 410 while connected to the private network can be authenticated by the video conferencing provider 410 via communication with the identity server 415. Such an example allows the user to provide the video conferencing provider with a username for the private network, which then allows the video conferencing provider to verify their identity and thus enable access to the meeting, whether as a participant or host. However, if a user from outside the private network attempts to join the meeting, the video conferencing provider 410 may need to authenticate the user, for example, by communicating with an external user identity provider, as described above with respect to Figure 3. Therefore, while the identity provider may be public or private, the video conferencing provider under this disclosure may communicate with any appropriate such identity provider to authenticate the user before providing access to the meeting as either a participant or a host.
[0068]
[0070] In some cases, the video conferencing provider 410 may attempt to authenticate one or more participants based on factors other than their own identity, such as a username within a private network. For example, some users may have access to a private network because they are employees of a company that maintains the network, but can work remotely using a company-issued client device such as a laptop. Therefore, when such a user attempts to join a video conference, the video conferencing provider 410 may receive device information, such as its device ID, from the user's client device. The video conferencing provider 410 can then request the identity server 415 to authenticate the user based on the device ID. If the device ID matches an authorized client device, the identity server 415 may authenticate the user based solely on the device ID, or in combination with other information such as the user's provided identity information as described above, or based on other information such as biometric or location information as described later.
[0069]
[0071] In another example, a user may need to provide biometric information when accessing a client device or when attempting to participate in a video conference, such as a secure video conference, where confidential information may be shared. Therefore, the user may provide biometric information, such as a fingerprint or retinal scan, on or via an input device connected to the client device. Such information may optionally be encrypted and provided to the video conferencing provider 410, which may then request user authentication from the identity server 415. The identity server 415 can then determine whether the received biometric information corresponds to the user's stored biometric information. In a further example, one or more user client devices may provide location information corresponding to the geographical location of each client device, for example, based on Wi-Fi, cellular, or a satellite positioning system. Such information may be provided to the video conferencing provider 410 along with the user's request to participate in the video conference. The video conferencing provider 410 may provide such information to the identity server 415, which can then determine whether to authenticate the user based on such information. For example, the identity server 415 may refuse authentication of a user located in a prohibited area, for example, due to export control regulations. The identity server 415 can use any or all of such information to determine whether or not to authenticate the user to the video conferencing provider 410.
[0070]
[0072] Referring now to Figure 5, which shows an exemplary method 500 for controlling attendance at an online meeting. The description of method 500 in Figure 5 will be made with reference to the system shown in Figure 2. However, any suitable system provided herein may be used, such as the exemplary systems 100, 300, and 400 shown in Figures 1, 3, and 4.
[0071]
[0073] In block 510, the video conferencing system 210 generates meeting information for a meeting. In some examples, the video conferencing system may generate meeting information for a new meeting, such as a meeting identifier and a passcode, based on a request from a client device to create a new meeting. The meeting identifier can be any identifier that is unique to the time the meeting is scheduled. Given the constraints of computer hardware, a globally unique meeting ID may not be possible, as the identifier may be reused later. The passcode may be any appropriate information necessary to obtain access to the meeting associated with the meeting identifier. Thus, the passcode can be a series of numbers, alphanumeric characters, etc. It should be understood that a passcode is not used in all cases. For example, a public meeting may not use a passcode. In addition, other types of meeting information may be generated, such as a uniform resource identifier ("URI") (e.g., a uniform resource locator ("URL")) that allows a user to access the video conferencing system 210 to join the meeting, security settings that identify the type of encryption, or security settings that provide an encryption key (e.g., a public key), and whether the meeting is recorded by default.
[0072]
[0074] As described above, the host can issue a request to create a meeting. To do so, one of the meeting host's client devices, for example, client devices 220-250, sends a request to create a meeting to the video conferencing provider 210. In addition to the request to create a meeting, the client device can also provide the video conferencing provider 210 with an invitation list. To initiate such a process, the host can log in to their account with the video conferencing provider 210, schedule a new meeting, and choose the option to provide a list of email addresses to various invitees.
[0073]
[0075] However, it should be understood that in some cases, the request to create a meeting does not need to be explicitly initiated by the user, but may instead be generated based on contextual information determined by the client device, or based on information stored by a third party, for example, via an email or calendar application hosted by the user identity provider, or a chat thread within an online collaboration tool. For example, a user may participate in a text discussion on a messaging platform with one or more other users and propose scheduling a meeting for 3 p.m. on Monday. The user's client device can identify the date and time and infer that the user is trying to schedule a meeting, and can issue a request to the video conferencing provider 210 to create a meeting. The user may then be presented with a notification that the meeting has been scheduled and that the other users in the discussion are included as attendees. In some cases, the request may be identified as tentative or unconfirmed until the user actually attempts to create the meeting. Alternatively, the user may be presented with options, such as a pop-up notification asking whether they want to schedule a meeting and invite members of their email chain. If so, the request to create a meeting may be sent to the video conferencing provider.
[0074]
[0076] In block 520, the video conferencing system 210 obtains a set of guest identifiers for the invitees to the meeting. To obtain guest identifiers, the video conferencing system 210 receives a set of guest identifiers from the host's client device and can associate them with meeting information, for example, when a user is creating a meeting. Alternatively, if the user provides indirect access to the guest list from, for example, a calendar application hosted by a third party, the video conferencing system can access the user's calendar and look up guest identifiers from the calendar entries.
[0075]
[0077] Each guest identifier is unique within the set of guest identifiers and may be any set of identifiers, each corresponding to a different conference guest. For example, a guest identifier may be an email address or identity established by a third-party user identity provider, such as an account name managed by a network credential service. Furthermore, in some examples, a guest identifier may be an account name established with the video conferencing provider 210. It should be understood that all guest identifiers do not have to be of the same type; for example, they do not all have to be email addresses. Rather, any combination of guest identifiers can be used.
[0076]
[0078] It should be understood that the guest identifier may be obtained simultaneously with the receipt of the request to create the meeting, or it may be obtained at a different time. Furthermore, in some examples, the guest identifier may not be obtained by the video conferencing system 210. For example, participants may be authenticated based on information other than the guest identifier, or the video conferencing provider 410 may provide the user identity service with all requests to access the video conference without remembering any information about the invitees to the meeting. Alternatively, the video conferencing provider 210 may request authentication of any requesting participant and, as described later, determine whether to allow or deny such a user based on the response from the user identity provider 215.
[0077]
[0079] In block 530, the video conferencing system 210 sends invitations to invitees based on guest identifiers. For example, if the guest identifier is an email address, the video conferencing provider 210 can send email or calendar invitations to those invitees. If any guest identifier is a user identity provided by a third-party user identity provider, the video conferencing system 210 can send an invitation to the identity provider to identify each user identity. Such an identity may also be an email address, or it may be a handle that enables communication such as direct messages ("DMs") or group messages such as Slack or social media posts.
[0078]
[0080] However, while some examples in this disclosure may use the video conferencing provider 210 to send invitations to various invitees, it should be understood that in some examples, the user may instead communicate the meeting invitation to guests by, for example, sending an email or calendar invitation, or posting a message on social media. Therefore, in some such examples, block 530 may be omitted.
[0079]
[0081] In block 540, the video conferencing system 210 initiates a conference. To do so, the network service server 214 can receive a request to initiate a conference from a host's client device. To issue the request, the host may select a hyperlink that identifies a URL, or it may manually enter a conference identifier and passcode into a web page hosted by the video conferencing provider 210 or into a client application provided by the video conferencing provider 210.
[0080]
[0082] In response to receiving a request to start a meeting, the video conferencing provider 210 activates the meeting identifier, for example, by updating the record in the database associated with the meeting identifier. Furthermore, the video conferencing provider 210 activates an audio or video stream between the host's client devices and the video conferencing provider 210, and assigns the host's client devices to the real-time media server 212 through which the audio or video data flows to and from the user's client devices. In an example where the meeting information indicates that the meeting is recorded by default, the video conferencing provider 210 also configures the real-time media server 212 to record the audio or video data streamed from the participants.
[0081]
[0083] Once the meeting begins, other invitees can join, and method 500 proceeds to block 550. Please understand that guests may attempt to join the meeting before it begins. In that case, they may simply be denied access or moved to a waiting room to await the start of the meeting.
[0082]
[0084] In block 550, the video conferencing provider 210 receives a request from a client device to join a meeting. For example, the client device may navigate to a URL corresponding to the meeting, which may optionally include a meeting identifier and a passcode. Alternatively, the user may access a client application provided by the video conferencing provider 210 and provide the meeting identifier and passcode, or perform similar functions using a web page hosted by the video conferencing provider. In other examples, any other suitable method may be used for the user to request to join a meeting. After receiving the request to join a meeting, the method proceeds to block 560.
[0083]
[0085] In block 560, the user provides a user identifier to the video conferencing provider 210. For example, if a user accesses a meeting using an application or web page provided by the video conferencing provider, the user may enter a user identifier such as their name, online identity username, or email address. In some examples, other types of user identifiers may be received, such as biometric information, device ID information, or location information. Such information may be provided at the same time as the request to join the meeting, but in some examples, the video conferencing provider 210 may send the user a request to provide a user identifier after the user has requested to join the meeting. For example, the meeting organizer may configure the meeting to require the user to provide an authorized user identifier. In such an example, after receiving a request to join the meeting, the video conferencing provider 210 determines that the meeting configuration requires the user to provide a user identifier and issues a request for a user identifier. After receiving the user identifier, the method proceeds to block 570.
[0084]
[0086] In block 570, the video conferencing provider 210 determines whether a user is a guest based on the correspondence between a user identifier and one of the guest identifiers. In some cases, a user may provide a user identifier that exactly matches a guest identifier, such as an email address (for a telephone device) or a telephone number. In such cases, the video conferencing provider 210 may simply allow the user based on the match between the user identifiers. However, in some examples, the video conferencing provider 210 may issue a "challenge" to the user by requiring the user to enter a one-time code sent to the user, for example, using the user's email address or via a text message to a telephone device, or by requiring the user to answer a pre-selected question using answers previously provided by the user, such as "What is your mother's maiden name?". If the user provides the correct one-time code or response, the video conferencing provider 210 may determine that the user corresponds to a guest in the set of guest identifiers, and the method proceeds to block 580.
[0085]
[0087] However, in some cases, a user may provide a user identifier that is not included in the set of guest identifiers. Instead, the user may provide a reference to a user identity established by the user identity provider 215. For example, a user may provide a username used to access a private network environment, such as a workplace. Furthermore, the user identifier does not have to be explicitly provided by the user. For example, the user's login name for a computing environment may be automatically sent to the video conferencing provider 210 when attempting to join a meeting without any user action or intervention.
[0086]
[0088] After receiving the username, the video conferencing provider 210 may not be able to find an exact match in the set of guest identifiers. In response, the video conferencing provider 210 may supply the user identifier to the host's client device to determine whether the user identifier is a username recognized by the host's networking environment. If so, the host's client device may respond with identity information corresponding to the username, such as an email address or name. The video conferencing provider 210 may then attempt to match the received identity information with one of the guest identifiers in the list of guest identifiers. If a corresponding guest identifier is found, the video conferencing system 210 determines that the user corresponds to a guest in the set of guest identifiers, and the method proceeds to block 580. However, even if a corresponding identity is found in the host's networking environment, further authentication may be used.
[0087]
[0089] For example, identity information may (or may consist of) one or more device identifiers for a client device associated with a username. The video conferencing provider 210 may then query the user's client device to obtain the device name (or it may have already been received from the client device). If the device identifier received from the user's client device matches any of the device identifiers in the identity information, the video conferencing provider 210 may verify the user's identity and then determine that the user corresponds to a guest in the set of guest identifiers, at which point the method proceeds to block 580.
[0088]
[0090] In some cases, to help accelerate the determination of whether a user corresponds to a guest identifier, the video conferencing provider 210 can establish a user profile even if the user has not registered an account with the video conferencing provider 210. An example of this process is shown in Figure 6 and is explained in more detail below.
[0089]
[0091] In some cases, as described above, users may provide information such as biometric data, device ID information, or location information in place of (or along with) other identity information. Such received information can be used to determine whether the user is an authorized guest of the meeting. In cases where the meeting may be open to employees of a company or other organization, the list of guest identifiers may be based on records in a human resources system or other information technology system that include biometric information of company employees, such as fingerprint or retinal scan information, device identifiers of authorized client devices, or prohibited locations for video conference attendees. The identity provider can use such information to determine whether the user is a guest.
[0090]
[0092] In block 580, the video conferencing provider 210 determines whether to accept the user into the meeting. If the video conferencing provider 210 determines whether the user is a guest, the method proceeds to block 580. In this example, the video conferencing provider 210 can accept the user into the meeting if it determines a correspondence between the user identifier and the guest identifier. However, in some examples, the video conferencing provider may first attempt to authenticate the user, for example by communicating with the user identity provider 215. As mentioned above, it may provide information received from the user and request user authentication. This may include user actions such as confirming a request from the user identity provider that the video conferencing provider 210 is authorized to request user authentication. Furthermore, in some examples, the video conferencing provider 210 may issue a challenge to the user, and if the user responds correctly to the challenge, the video conferencing provider 210 can accept the user into the meeting.
[0091]
[0093] However, if user authentication fails, or if a guest identifier corresponding to the user identifier cannot be found, the video conferencing provider 210 may deny the user access to the meeting, or, in some cases, the video conferencing provider 210 may move the user to a waiting room and notify the host that the user needs to be accepted into (or denied access to) the meeting. The host can then access the waiting room and decide whether or not to accept the user.
[0092]
[0094] It should be understood that the steps described above are examples and may be performed in a different order. Furthermore, it should be understood that any individual server (or group of servers) within the video conferencing provider 310 may perform some of the steps of the method. For example, a server may perform the method starting from block 550 after a different server has handled the process of creating a new meeting or starting a meeting. Furthermore, as described above, block 530 may be omitted in some examples, or block 520 may not be performed until a request to join a meeting is received. Further variations are conceivable within the scope of this disclosure.
[0093]
[0095] Referring here to Method 600 shown in Figure 6, Figure 6 illustrates an exemplary Method 600 for controlling attendance at an online meeting. The description of Method 600 in Figure 6 is made with reference to System 200 shown in Figure 2. However, any suitable system provided herein may be used, such as the exemplary Systems 100, 300, and 400 shown in Figures 1, 3, and 4.
[0094]
[0096] This method begins with blocks 510-550 of method 500 shown in Figure 5, which are not repeated in Figure 6. After block 550 is completed, method 600 proceeds to block 610.
[0095]
[0097] In block 610, the video conferencing provider 210 receives a user identifier as described above with respect to block 560.
[0096]
[0098] In block 620, the video conferencing provider 210 attempts to identify a user profile created for the user based on the provided user identifier. As described above, the video conferencing provider 210 can create a profile corresponding to a user identifier even if the user has not registered with the video conferencing provider 210. For example, when a user first provides a username to join a meeting, as described above with respect to block 570, the video conferencing provider 210 can attempt to determine whether the user is a guest or not based on the correspondence between the user identifier and the guest identifier.
[0097]
[0099] If the video conferencing provider 210 does not have a user profile associated with a user identifier, it can create a user profile based on the user identifier. The information included in the user profile may include the user identifier, the device ID of the client device used by the user to attempt to join the meeting (e.g., device name, network ID, telephone number, International Mobile Equipment Identity (IMEI) number, etc.), the domain name associated with the user or the user's client device, a timestamp corresponding to the attempt to join the meeting (e.g., date and time), the meeting identifier and passcode, and the meeting host. Furthermore, the video conferencing provider 210 establishes an initial trust level for the profile, e.g., 0 or untrusted trust level. After creating the user profile, the method proceeds to block 640.
[0098]
[0100] If a user profile associated with a user identifier is identified, the method proceeds to block 630.
[0099]
[0101] In block 630, the video conferencing provider 210 determines the trust level associated with the user profile. The trust level is associated with whether the user requesting access to the meeting is likely to be the actual user or someone impersonating the user. For example, it may reflect whether the provided user identifier is attempting to join the invited meeting and whether the user associated with the user identifier has any other indicators that it is untrustworthy, such as a user profile having a history of disrupting meetings or streaming inappropriate content during meetings. The creation and updating of trust levels are described in more detail below with respect to block 650.
[0100]
[0102] In this example, to determine the confidence level, the video conferencing provider 210 extracts the current confidence level of the user profile from the user profile. However, in some examples, the confidence level may be determined based on information stored in the user profile. For example, the user profile may include a device ID associated with a device the user has previously used to join a meeting. Each time the user joins a meeting with the same device, the confidence level associated with the device ID can be increased (potentially up to its maximum value). Thus, the confidence value may be determined based on the confidence level associated with the device ID. Similarly, if other information in the user profile has associated confidence levels, such as a meeting host or domain name that the user commonly joins, such confidence levels can be used to determine the aggregated confidence level of the user profile. Once the confidence level has been determined, method 600 proceeds to block 640.
[0101]
[0103] In block 640, the video conferencing provider 210 determines whether a user is a guest based on the correspondence between the user identifier and one of the guest identifiers, as generally described above with respect to block 570.
[0102]
[0104] In block 650, the video conferencing provider 210 determines whether to accept the user into the meeting. In this example, the determination is based on whether the user identifier is determined to be a guest based on the correspondence between the user identifier and the guest identifier. In some of the examples described above with respect to block 570, the video conferencing provider 210 may issue a challenge to the user even if the correspondence is determined. However, in examples where the video conferencing provider 210 maintains a user profile, it can determine whether the trust level associated with the user profile meets or exceeds a threshold trust level. If so, the video conferencing provider 210 may accept the user into the meeting without issuing a challenge. However, if the trust level does not meet the threshold, it may issue a challenge as described above and deny the user access to the meeting. In some examples, if the trust level does not meet the threshold, the video conferencing provider 210 may notify the meeting host that the user has requested to join the meeting. For example, the video conferencing provider 210 may move the user to a waiting room so that the host can view the video or audio stream from the user and determine the user's identity and whether to accept the user.
[0103]
[0105] After determining whether to accept the user into the meeting, the method proceeds to block 660.
[0104]
[0106] In block 660, the video conferencing provider 210 updates the user profile based on the results of block 640. If it is determined that the user identifier corresponds to a guest identifier, the video conferencing provider 210 may update the user profile to include the guest identifier, which may be used in the future to determine the correspondence between the user identifier and the guest identifier received by the video conferencing provider 210. The user profile may also be updated with additional information, such as the device identifier of the user's client device or other information described above with respect to block 622. Furthermore, as described above with respect to block 630, the video conferencing provider 210 may update the confidence level associated with the data stored in the user profile. For example, if a user regularly uses the same device to access a meeting or participates in a meeting hosted by the same user, the video conferencing provider 210 may maintain a count or other value corresponding to the device identifier or meeting host.
[0105]
[0107] Furthermore, the video conferencing provider 210 can also increase the level of confidence associated with a user profile, for example, by adding a predetermined value to an existing level of confidence about the information stored in the user profile or to the user profile as a whole. Such techniques allow the video conferencing provider 210 to be confident that a particular user identifier requesting access to a meeting using a particular device or set of devices, or a meeting hosted by the same host or the same organization, is the user and not someone impersonating the user.
[0106]
[0108] Using the exemplary method 600 shown in Figure 6, a video conferencing provider can determine whether or not to accept a user into a meeting, but can also reduce the burden on the user by recognizing the user based on information associated with the user, such as past meeting access and frequently attended devices or meetings.
[0107]
[0109] Referring here to Figure 7, Figure 7 shows an exemplary computing device 700 suitable for use in an exemplary system or method for controlling attendance at an online meeting according to the present disclosure. The exemplary computing device 700 includes a processor 710 that communicates with memory 720 and other components of the computing device 700 using one or more communication buses 702. The processor 710 is configured to execute processor-executable instructions stored in memory 720 to perform one or more methods for controlling attendance at an online meeting according to different examples, such as some or all of the exemplary methods 500, 600 described with respect to Figures 5 and 6. In this example, the computing device also includes one or more user input devices 750, such as a keyboard, mouse, touchscreen, video input device (e.g., one or more cameras), microphone, etc., to accept user input. The computing device 700 also includes a display 740 for providing visual output to the user.
[0108]
[0110] The computing device 700 also includes a communication interface 740. In some examples, the communication interface 730 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 may 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.
[0109]
[0111] 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.
[0110]
[0112] 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.
[0111]
[0113] 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.
[0112]
[0114] 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.
[0113]
[0115] 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. To generate meeting information for a meeting, wherein the meeting information includes a meeting identifier. Obtaining a set of guest identifiers corresponding to multiple conference guests, wherein each guest identifier is unique within the set of guest identifiers and corresponds to a different conference guest. The video conferencing system is used to initiate the meeting using the aforementioned meeting identifier. The video conferencing system receives a first request from a first client device to join the meeting, wherein the first request includes the meeting identifier. Receiving a first user identifier corresponding to a first user, wherein the first user identifier is not in the set of guest identifiers, Based on the correspondence between the first user identifier and the guest identifier in the set of guest identifiers, it is determined that the first user is the first meeting guest among the multiple meeting guests. A method comprising connecting the first client device to the conference in response to the determination that the first user is the first conference guest.
2. Determining that the first user is the first meeting guest means Accessing a first user identity corresponding to the first user based on the first user identifier, wherein the first user identity includes first user identity information. The method according to claim 1, comprising determining the relationship between the first user identity and the guest identifier of the set of guest identifiers based on the first user identity information.
3. The video conferencing system receives a second request from a second client device for a second user to join the meeting, wherein the second request includes the meeting identifier. Receiving a second user identifier corresponding to the second user, Based on the second user identifier, it is determined that the second user is not one of the conference guests among the multiple conference guests, The method according to claim 1, further comprising denying access to the meeting to the second client device in response to determining that the second user is not a meeting guest.
4. The determination that the aforementioned second user is not a meeting guest is Accessing a second user identity corresponding to the second user based on the second user identifier, wherein the second user identity includes second user identity information. The method according to claim 3, further comprising determining, based on the second user identity information, the absence of a relationship between the second user identity and the set of guest identifiers.
5. Obtaining the set of guest identifiers corresponding to the plurality of meeting guests includes generating the set of guest identifiers, The method according to claim 1, further comprising ending the meeting using the video conferencing system.
6. The method according to claim 1, wherein each guest identifier in the set of guest identifiers includes an email address, and the first user identifier includes a screen name or alias not used as a guest identifier, an account name or account identifier of the video conferencing system, or identity information from a trusted third party or identity provider.
7. The video conferencing system receives a second request from a second client device for a second user to join the conference, wherein the second request includes the conference identifier. Receiving a second user identifier corresponding to the second user, Based on the second user identifier, it is determined that the second user is not one of the conference guests among the multiple conference guests, The method according to claim 1, further comprising sending a message to the meeting host indicating that an uninvited guest has requested access to the meeting.
8. Receiving instructions from the conference host granting permission to accept the second user into the conference, The method according to claim 7, further comprising connecting the second client device to the conference in response to receiving the instruction.
9. Identifying a first user profile based on the first user identifier, The process further includes determining the trust level associated with the first user identifier, The method according to claim 1, wherein determining that the first user is a first meeting guest is further based on the confidence level.
10. To obtain meeting information associated with a meeting, wherein the meeting information includes a meeting identifier. The video conferencing system receives a first request from a first client device to join the meeting, wherein the first request includes the meeting identifier. Receiving a first user identifier corresponding to the first user, Accessing a set of guest identifiers corresponding to multiple conference guests invited to the aforementioned conference, wherein each guest identifier is unique within the set of guest identifiers and corresponds to a different conference guest. Based on the correspondence between the first user identifier and the guest identifier in the set of guest identifiers, the first user is determined to be the first meeting guest among the plurality of meeting guests, and the first user identifier is not in the set of guest identifiers. A method comprising connecting the first client device to the conference in response to the determination that the first user is a conference guest among the plurality of conference guests.
11. Determining that the first user is the first meeting guest means Accessing a first user identity corresponding to the first user based on the first user identifier, wherein the first user identity includes first user identity information. The method according to claim 10, comprising determining the relationship between the first user identity and the guest identifier of the set of guest identifiers based on the first user identity information.
12. The video conferencing system receives a second request from a second client device for a second user to join the meeting, wherein the second request includes the meeting identifier. Receiving a second user identifier corresponding to the second user and Based on the second user identifier, it is determined that the second user is not one of the conference guests among the multiple conference guests, The method according to claim 10, further comprising denying access to the meeting to the second client device in response to determining that the second user is not a meeting guest.
13. The determination that the aforementioned second user is not a meeting guest is Accessing a second user identity corresponding to the second user based on the second user identifier, wherein the second user identity includes second user identity information. The method according to claim 12, further comprising determining, based on the second user identity information, the absence of a relationship between the second user identity and the set of guest identifiers.
14. The method according to claim 10, further comprising receiving an instruction from the video conferencing system that the meeting has ended.
15. The method according to claim 10, wherein each guest identifier in the set of guest identifiers includes an email address, and the first user identifier includes a screen name or alias not used as a guest identifier, an account name or account identifier of the video conferencing system, or identity information from a trusted third party or identity provider.
16. The video conferencing system receives a second request from a second client device for a second user to join the conference, wherein the second request includes the conference identifier. Receiving a second user identifier corresponding to the second user, Based on the second user identifier, it is determined that the second user is not one of the conference guests among the multiple conference guests, The method according to claim 10, further comprising sending a message to the meeting host indicating that an uninvited guest has requested access to the meeting.
17. Receiving instructions from the conference host granting permission to accept the second user into the conference, The method according to claim 16, further comprising connecting the second client device to the conference in response to the receipt of the instruction.
18. Identifying a first user profile based on a first user identifier, The process further includes determining the trust level associated with the first user identifier, The method according to claim 10, wherein determining that the first user is a first meeting guest is further based on the confidence level.
19. 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. To obtain meeting information associated with a meeting, wherein the meeting information includes a meeting identifier. Using the aforementioned communication interface, the video conferencing system receives a first request from a first client device to join the meeting, wherein the first request includes the meeting identifier. The communication interface receives a first user identifier corresponding to a first user, Accessing a set of guest identifiers corresponding to multiple conference guests invited to the aforementioned conference, wherein each guest identifier is unique within the set of guest identifiers and corresponds to a different conference guest. Based on the correspondence between the first user identifier and the guest identifier in the set of guest identifiers, the first user is determined to be the first meeting guest among the plurality of meeting guests, and the first user identifier is not in the set of guest identifiers. A system configured to connect the first client device to the conference in response to a determination that the first user is a conference guest among the plurality of conference guests.
20. The processor executes a processor-executable instruction stored in the non-temporary computer-readable medium. Identifying a first user profile based on the first user identifier, Determining the confidence level associated with the first user identifier, The system according to claim 19, further configured to determine, based on the confidence level, that the first user is the first meeting guest among the plurality of meeting guests.