WO2019095084A1 - User service interface and management platform for video conferencing and collaborative activities - Google Patents

Abstract

The invention relates to a method, system and platform for allowing deeper and more complete interaction between users in a meeting room and multiple information sources for video conferencing, both before deciding to arrange a video conference meeting and during said meeting. The present invention allows the user to better manage the meeting and achieve a better and simpler user experience, and allows a greater return on investment in devices and technology used for video conferencing.

Description

 USER SERVICE INTERFACE AND PLATFORM OF

MANAGEMENT FOR VIDEOCONFERENCE AND ACTIVITIES OF

COLLABORATION

Field of the invention

This request corresponds to a system, methods and user interfaces to coordinate, establish, operate and end meetings by videoconference between meeting rooms equipped with videoconference codes.

Description of prior art status

In general, video conferencing is established as a point-to-point connection between rooms equipped with compatible video conferencing equipment. To establish a video conference call (VC) between a video conference room and another (call point-to-point), the calling user sends an instruction to make this call directly to a local codec (usually one per room) by means of a remote control (from traditional type with keys, or touch screen type Tablet / PC / smartphone).

The codec then exchanges signaling elements directly with the remote codec, either by using an end-to-end communication protocol (with the remote codec), or eventually passing through a Gatekeeper, or SIP proxy, which can reject or propagate signaling to the remote site (these intermediate systems may modify the signaling exchanged slightly according to previously established fixed rules, such as, for example, replacing the remote site address with another one in case it is required by the network's addressing plan). To establish a multipoint call between several rooms (3 or more), using a multipoint control infrastructure (or MCU: Multipoint Control Unit), the user generally has three options:

- The MCU generates a call to each of the participating codes, following a manual instruction entered in the control interface of the MCU, or a previously registered instruction (scheduled meetings).

 - Or a user sends an instruction by other means (remote control, desktop application, App for smartphone or tablet, etc.) to the MCU, which in turn will generate and establish calls to the participating codes.

 - Or each user (in each meeting room) calls from his codec to the MCU in a virtual meeting room (VMR: virtual Meeting Room), in a moment of pre-agreed time.

In the first two cases, the way the call is received in the remote site (s) generates great inconveniences: - If the codec is configured to receive calls automatically (auto-response), the call can generate interruptions or interference with another call already established, or affect an ongoing meeting in the room, or the call can not be established. In addition, there is no way to know at a distance who is present in the room at this time, which can generate discomfort for users and even serious risks against confidentiality, for example, if the attendees in the room do not realize the establishment of this incoming call).

 - Otherwise, a user must be present in the room and manually accept the call, during a time window of a few seconds. Once again, the remote user does not necessarily have to know who is in the room at the moment when the call is generated. Just notifying the incoming call can be annoying to those present, even if they decide to reject the call. Any delay in accepting the call in this precise time window (for example, because the user entered late in the meeting room) could impact the correct start of the meeting. These methods for establishing VC calls have several negative impacts for users, such as:

- A point-to-point call follows a different process of a multipoint call, and different components. Consequently, users should experience different behaviors, both to establish a call and during a meeting, where different functionalities and how to use them are not consistent, can be difficult to use, or may not be available. For example, add an additional participant to the meeting, incorporate remote support staff into the collaborative meeting, or record the meeting.

 - While in a Multipoint meeting, the user loses the ability to easily and directly call another room, as he is used to.

- Instant calls (not reserved) may conflict with previously scheduled meetings, generating coordination problems and bad user experience. For example, a meeting (1) was previously scheduled including room A. Some minutes before the start scheduled for the meeting (1), a user enters room A and decides to make a brief meeting (2) by calling a room B directly using the remote control. At the time scheduled for the start of the meeting (1), it will not be possible to connect room A with the meeting (1).

 - Calls and reservations of rooms are usually mixed in the same layer. Existing solutions generally do not make the difference between ending a meeting and disconnecting a call. Thus, when the user disconnects the call, these solutions terminate the meeting automatically. In this way, users will not be able to keep the reservation of the local meeting room, for example, with the objective of formalizing conclusions of the meeting with the local group of collaborators. As soon as the call is disconnected, the room is available for other potential users, who can reserve it and therefore interrupt the meeting that had not ended.

- Point-to-point calls are not necessarily registered in the central scheduling system. Consequently, they could for example not have a reference id, not appear in the reports, or can not be adequately supported by the support staff.

It would be beneficial to have a system that has a simple and intuitive user interface to reserve and / or initiate calls and meetings, where the current and future status of all the rooms can be displayed, allowing automatic calls to be generated in a remote room, or Multiple room in uniform form. Such a system could manage and avoid potential conflicts between different use cases, improve the user experience both to generate and receive calls avoiding interruptions and confidentiality problems. Such a system could improve the return on investment in technology, in addition to increasing the use of meeting rooms.

Summary of the invention

The present invention corresponds to methods, system and platform that allow a deeper and more complete interaction between end users in meeting rooms and multiple sources of information, both before deciding to hold a videoconference meeting, and during the course of the same. The present invention allows the user to better manage the meeting, obtain an improved and easier experience, and facilitates a better return on investment in equipment and videoconferencing technology. The system of this invention also allows the user interface to be independent of the brand and / or model of the videoconferencing equipment in the room. The user interface communicates with a "back-end" processor, typically in the cloud (public, private or hybrid cloud), which in turn communicates a data repository. The data repository records and stores reservations, both previous and ongoing, and the references in such a way that the system of the invention is aware of who reserves which room (s) and for which connection (it is) ) and at what time. In part because the processor serves as a scheduling agent, it also provides the resources and functionalities required to establish and terminate calls, without the need for human intervention. It can also be used to incorporate additional features, such as facial or voice recognition, to ensure that the right people and only these are in the different rooms connected.

Thanks to the real-time management of the meeting status of each room (instant presence) together with the scheduled use of the rooms (future presence) and the improved interaction with the user that allows the service interface, the system avoids conflicts between scheduled meetings and meetings "on the fly" (without prior scheduling), as well as between the use of meetings with videoconference and local meetings using the same room. In this way, the present invention is used to schedule a meeting room that may or may not include a videoconference (for exclusive use or otherwise). The system of the present invention uses an innovative user interface, which allows to schedule, initiate, configure, operate and end meetings. The user interface is accessible via a Tablet-type device in the meeting room where the videoconference equipment is located, but can also be accessed in the form of a web interface, an application on a personal computer, or an App on a smartphone or tablet.

The present invention includes a service interface for the user. The user receives all the required and pertinent information in the User Service Interface (ISU), including the availability in the agenda.

Then the user can choose the duration and the participants of the meeting. The platform of the present invention prevents initiating meetings that may generate conflicts. Once the meeting started, the platform instructs each videoconferencing codec in each meeting room to call a specific virtual meeting room (VMR: Virtual Meeting Room) created in the MCU at this very moment with a random identifier (or in alternatively, the platform can instruct the MCU to generate a call to each room). The method simulates the user as if he were generating the call to remote systems, while in reality a much more complex signaling process is carried out. Virtually, a user can establish a point-to-point call from his room to another remote site, while in practice the platform establishes a multipoint call connecting the two rooms, but maintaining an experience very similar to a traditional point-to-point call.

It should be noted that fixed and not only random virtual rooms can also be used within the scope of the present invention. In this case, the user will specify which VMR will be used. Or the platform will be able to define the fixed VMR that should be used for this meeting using a predefined algorithm (for example, use a VMR specifies associated to one of the meeting rooms, or one of the participants).

In practice, the Service platform serves as a switch. Receive signaling commands from a controller (service interface). These signaling commands are sent to the service platform which interprets them to perform all the requested actions and changes, such as transforming a point-to-point multipoint meeting, changing the layout on the screen, turning on or off televisions and projectors, mute the room or participants, etc. These commands are the results of a user's interaction with a graphical user interface.

The system of the present invention includes a Tablet-type interface that allows anyone to operate the videoconferencing system at any time and virtually without the need for prior training. The benefits of the present invention include an increase in the rate of use of meeting rooms of up to 40%, for example, thanks to "no-show" functions and automatic detection of abandonment of meetings by its participants, automatically releasing the resources .

The system of the present invention includes a scheduling platform compatible with the actual communication needs of an organization, which go far beyond a rigid meeting scheduling system that requires all meetings to be previously reserved. The system of the present invention allows a user to make meetings and calls instantly, without prior reservation. The service interface (ISU) of the present invention is a real-time management interface which identifies and prevents any conflict at any time in the scheduling, although the user agendes at the same time.

Among the additional functionalities of the present invention are the strongly distributed and redundant architecture, which provides additional robustness. In addition, the controlled (ISU) in the room provides real-time access to the control of the meeting and call, including what is displayed on the local and remote screen, as well as the ability to extend the meeting, re-establish a call when necessary . Either microphone selection by the user, or automatic handling by the platform. In addition, the system of the present invention includes the processing of all available information to define and automatically set specific parameters of the meeting. For example, what is the best preset for the camera in each room depending on the number of participants in the same room, the number of rooms and remote participants, the duration of the meeting, the properties of the rooms (some could be configured how VIP rooms), the profile or identity of the participants, the type of meeting as defined in the reservation or at the beginning of this (interactive meeting, training, board meeting, presentation of the president to employees, etc.), bandwidth to be used to connect each room, the microphone status at the beginning of the meeting, the possibility (or not) for the users in each room to mute or unmute the microphone during the meeting, automatic call reconnection in case of cutting, reorganization of the connections (for example, automatically transferring a call to another room in case of unavailability), options for ending calls, meetings and room reservations. Brief description of the drawings:

Fig. 1: gives an overview of the architecture of the present invention

Fig. 2: gives an overview of the architecture of the present invention for a hybrid scenario (mixed private and public)

Fig. 3: provides a representation of the user interface screen of the present invention

Fig. 4: shows a view of the architecture of the interface and codec of the present invention Fig. 5: shows the steps in initiating a collaboration activity Fig. 6: shows the steps in accepting a meeting invitation Fig. 7: shows an example of workflow

DETAILED DESCRIPTION OF THE INVENTION The present invention considers a system and methods for combining, scheduling, initiating, operating and ending meetings and videoconference calls. The method of the present invention uses public protocols (and not proprietary and specific protocols) and allows the interconnection of multiple types of devices. The present invention includes various software-based devices used to manage these calls and meetings. In the present invention, multiple meeting rooms can be configured to be integrated with the system of the present invention. Each room will need a screen, at least one camera (including a Codee: COdificador- DECodificador) and microphone, and a meeting controller (ISU, also called RoMA: ROom Meeting Assistant). The controller will have some form of connectivity with a central processor implemented in a server, in which the platform of the present invention resides. The platform of the present invention is used, at least in part, to establish and distribute the video calls according to the needs of each meeting. The server will be connected to one or more data repositories where information relating to the rooms, users, policies and business processes of the client regarding the use of rooms and meetings, calls, the network, the agendas will be recorded and stored. In addition, users may have access to the controllers by other means, such as Tablet, smartphone or personal computer. It is important to consider that there may be two types of controllers: meeting room controller (RoMA), or personal controller. Both interact in a similar way with the central processor object of subtraction meeting. However, while the former is oriented to operate the meeting room where it resides and manage the meetings in which this room participates, a personal controller is oriented to meet the needs of a particular user regardless of where he / she is (but including functionalities of the room controller when the user is in the same room). As new information reaches the data repositories, the central processor processes it immediately and determines the actions and changes that must be made, and will update the controllers accordingly.

The platform of the present invention acts as a central point of distribution and coordination. The cameras, microphones and controllers of the rooms, as well as the personal controllers, are in permanent communication with the platform, and the platform processes information, receives and transmits information for the controllers, manages the agendas, users, and controls the actions and behavior of all devices, among other tasks. The controller of the present invention includes the ability to schedule meetings and calls, initiate meetings and un-scheduled calls ("ad-hoc"), and control all aspects of an actual meeting in progress using distributed videoconferencing resources. Once scheduled, a call can be established and the cameras and microphones can be controlled, automatically (the central processor will define and configure in real time the desired states of each component), or manual (the user chooses the configurations that you want through the controller in the room or your personal controller). The manual choices will always be sent to the central processor who will process them together with the rest of the available information. It is the central processor who in the last resort defines what manual commands should be considered, and even what the actual effect of each request will be based on the other information available in the server (repository) of information. FIG.1 shows an example diagram of the architecture of the components of the present invention. In this example, two rooms 100 and 200 have a videoconference set 110 and 210 respectively (which include screen, camera, codec and microphone), and user interface 120 and 220 respectively. In this particular scenario, the codec is located with the video screen. Each room is connected to the server-based processor 140, and has access to the MCU 330. The server 140 supports the service platform, which in turn is connected to one or more data repositories 150. Whereas the server 140 can be in the cloud and is undoubtedly remote from at least one room, the connection between each room and the server 140 can be via internet or other means of communication. The server 140 includes the service platform of the present invention. In addition, although each room has its own user interface (or controller), the control in place can be through a web interface or an app or software on a PC, Tablet, or Smartphone. The MCU 330 mixes the multimedia streams, allowing multipoint connections (MCU: Multipoint Control Unit, or multipoint control unit).

The server 140 controls the interaction between each of the components: codec 10 and MCU 330, but also the interactions between user interface (ISU) 120 and codec 10. Although the figure shows only two rooms, it should be clear to the user. reader that there could be more than two rooms (see Example in FIG.2), and that each room could be configured with additional devices such as a computer or tablet with local storage capacity, or cameras to detect and / or identify attendees in the living room. The cameras / codecs may have direct connection to the central processor 140, or indirectly via the user interface 120. Each room usually has one or more microphones and cameras, and perhaps electronic devices of different types, such as computers and text, image or video file stores (but not only), peripheral control devices (TV, projectors, camera of documents, etc.), lighting, air conditioning, interactive whiteboards, electric curtains, projector lifts, etc. The user interface 120 will have knowledge of each of these devices automatically or manually (eventually generating a modification of the graphic interface in the user interface to display the relevant commands for the user). It is the central processor 140 who will automatically determine and update the appropriate layout and graphic arrangement of the user interface 120 (ISU) based on all the available data, including the electronic devices present in the room.

The server 140 can be an individual server, or a server farm in a centralized or highly distributed architecture (in the cloud for example). Similarly, information repository 150 may be a single server, or a server farm in centralized or highly distributed architecture (cloud for example). And the MCU 330 can be a single MCU or a cluster of MCUs (centralized or highly distributed).

Although shown as a single information repository, the server 150 can perform various functions, including receiving and storing scheduling information and specific requirements for each meeting, receiving and maintaining the status of each of the components (codec, camera, interface). user, network, platform, users, rooms, peripherals, lighting in each room, number of participants in the rooms, identification of these, etc.).

The repository server 150 receives, records, stores and keeps updated information related to various aspects of the meetings and videoconferences in the creation and definition stages; scheduling: starting and launching calls; regenings; call cutoff; completion of meetings; information of the meeting rooms such as characteristics, location, capacities, existing devices, responsible or processes of own support of each one; policies, processes and preferences of business processes relevant to meetings; network topology and its status in real time in each of its points; information of the users, their preferences and even their customs and historical use of meetings in all their aspects. The platform of the present invention interacts with the repository on numerous occasions. For example, the platform determines the status and capabilities of the codec in the room and instructs the different components to be configured in a compatible manner, such as sending video content with the quality supported by the room. The platform also consults the appropriate presence of people (possibly their identity by facial recognition, voice and other electronic means) in the room. The platform defines what should be the best configuration for each component to achieve the best result as a whole, according to all available information such as: preferences of the client's business processes (for example, if the meetings can be automatically ended at the end of the day) , or if users must manually validate the term); preferences of the users (previously defined, or specific to this meeting, or deducted automatically by the platform according to the user's usage history and behavior); type and size of the room; resources available in the room; type of meeting; number of participants; topology, real-time load capabilities and network status. The platform also provides automatic scheduling and re-routing functionality, for example, when a call needs to be reassigned and routed to a different room (for example because the room initially reserved is no longer available, or more attendees arrived than its capacity, etc.) . The platform also always communicates with the controller (within the room, or staff of the people involved in this meeting), keeping it updated and displaying all the information required and relevant to the user depending on the specific context of the meeting, the current state and of all the information available at this time.

FIG. 2 shows a global view of the system architecture of the present invention in the case of a partially private and partially public hybrid scenario. The figure shows three rooms 100, 300 and 400, which are inside company A, and room 200 outside company A. Each room has its respective videoconference sets (screen, camera, codec, microphones) and user interface (controller). Although a local MCU 030 is shown here, used as an internal distribution point for multimedia flows within the company, there may be more than one of these distribution points of media flows within the company, according to considerations of topology, network, geography, policies or others. As shown, the Local MCU 030 communicates with the MCU 330 central to distribute the multimedia streams in the best way. There are other types of alternative architectures.

Following a similar architecture model, the 040 processor server is a local point of distribution of signaling, management and control of all the components within the company. There may be more than one of these distribution points of signaling, management and control within the company, according to considerations of topology, network, geography, policies or others. As shown, the server of the processor 040 communicates with the server of the central processor 140 to distribute the signaling, management and control flows in the best way, but also to share additional relevant information to improve the experience and functionalities (for example, in case of communications with external sites to the company).

Following the same model, a local 050 information repository server is shown to the company, which concentrates all the relevant information for meetings, rooms and calls. There may be more than one of these points registration and storage of information within the company, according to considerations of topology, network, geography, policies or others. As shown, the server 040 communicates with the central server 150 to share and eventually replicate relevant information throughout the environment. Regardless of the topology, servers 040 and 140 control the components, define and generate the required commands at the right time. While servers 050 and 150 register, store and keep updated all information, parameters, preferences, relevant for the proper management of meetings, rooms and calls.

FIG. 3 shows a collection of possible interface states that will be displayed in the Tablet controller (ISU or RoMA) present in each room of the present invention, but also in a personal computer, smartphone or Tablet, or in the personal controller of each user. Although multiple views can be provided depending on each state and function, only a few examples are shown here. The views are generally interactive in a graphical user interface (GUI). Some of the possible forms of interactivity between these example views are shown. The views are very intuitive and easy to use, and can include "sliders" and buttons or keys to control certain functions (for example, volume, mute, camera, add participants, end the call, end the reservation of the room, etc.). ).

The graphical user interface (GUI) will be referred to here as RoMA (Room Meeting Assitant) and corresponds to a service interface that allows to visualize and control all the states and actions of meetings, rooms and calls. The RoMA allows the user to control the room in which it is located, as well as eventually other remote rooms, for example, controlling the microphone mute of the remote site. In the room in which it is located, the user can subdivide the screen to show different combinations of remote rooms, or let the system of the present invention control the screen automatically, for example, using information of the number of rooms connected, the amount of people in each room, where there is sound, the type of meetings, the preferences of the meeting or general policies of the company. A user could also "lock" the screen to prevent automatic management, although the platform could also prevent this function for users in certain cases. The GUI of the present invention can inform the user in the room (or anywhere in his personal controller) which rooms are connected, and who is in each room.

The system of the present invention can request authentication of the users at the beginning of a call (by different means, from PIN to facial or vocal recognition or other means) before letting the call go forward. The system can also detect that all participants left a room for more than x minutes (or that there are fewer participants than a preset minimum amount), deciding then to disconnect the call and release all reserved resources (for example, the meeting room ). It could also determine that it does not correspond to release in certain cases (for example, if a meeting was defined as VIP, or recognized a user with special privileges) in which cases it will request a specific confirmation before releasing.

FIG. 4 describes the different components in the meeting rooms, as well as the service platform with its subcomponents. In the meeting room there is a 1 10 video conferencing codec, which is used to make video conference calls in the room. The user interacts in the room with the User Service Interface 120 (ISU, or room controller, or RoMA). According to the action requested in the ISU by the user, the ISU interacts with the service platform (the server 140 part of the present invention). The processor server 140 reviews the relevant data available in the information repository 150. It determines the actions to follow and eventually instructs all the components (1 10, 120 or 330) to carry out the pertinent actions according to the case. The MCU 330 centralized (can be in a datacenter, or distributed in the cloud, or even in any room (s) and even included in one or more of the codees.) Its purpose is to manage and mix the multimedia streams (audio , video, content) received and sent to each codec, in order to connect multiple participants in the same meeting, although the MCU itself is not part of this invention, but the way the components interact with it. This invention is used to display relevant and contextual information of the meeting for the user, as well as to receive instructions, requirements and preferences of the user.The ISU is the physical component on which the GUI (graphical user interface) is delivered. This invention The repository server 150 records, stores and maintains all the relevant data and parameters for meetings, for example, it is responsible for measuring the quality of each call in you. Real time, detect the status and presence of each component (1 10, 120, 330, 140 and other devices in the room or in the network). The integrated set of all these components allows to determine in each moment the future presence of each room and participant, avoid conflicts, rearrange calls or reservations in real time, determine the best parameters or configurations to use in each meeting, make recordings, authentications, release unused resources, etc. It also allows to modify in real time the visualizations on the screens of the different sources of content in an intelligent way, taking into account for example definitions of processes, number of participants in each room, identity of the participants, etc. FIG. 5 samples the stages to start a collaborative activity. Similar stages exist for other activities (for example local). FIG.5 shows nine essential stages to establish a collaboration. The Information Repository Server permanently records the status of each codec. The service platform updates all the meeting rooms and activities, and informs the user through the ISU (in the room or staff). The user decides to start or join a collaborative meeting, specifying through the ISU the duration and the participants / rooms required. The platform verifies the availability and determines if it rejects the requirement or confirms the availability of the rooms and participants for the entire duration of the meeting and updates their respective states. The platform generates a structured ID (with a random part), instructs the MCU to create a new dynamic virtual room (VMR: Virtual Meeting Room) with this ID. The platform then instructs the participating codes to generate calls to this specific VMR. Once established, the platform updates the states in the repository and in the ISU. It should be noted that, within the framework of this invention, fixed VMR virtual rooms can also be used: either manually defined by the user when scheduling a meeting or initiating an instantaneous meeting not scheduled "ad-hoc" via the ISU, or automatically chosen by the service platform depending on the characteristics of the meeting (for example using a fixed VMR related to one of the meeting rooms or a guest participant of the meeting).

FIG.6 shows the stages in accepting a meeting requirement. In general, assuming that the meeting is pre-scheduled, the platform notifies the users of each room of the meeting requirement (invitation) for the room with all the details of the meeting. The platform can simultaneously notify rooms (in the RoMAs) and users (in their personal controllers). The user accepts the invitation to the meeting through the ISU (both the RoMA in the room, or web interface, or App on a PC / Tablet / smartphone) then used to notify the platform. This in turn instructs the codec to establish a call to the VMR corresponding to this specific meeting. Alternatively, the platform can instruct the MCU to generate calls to users' devices (or a room, for example, if the respective codec is not registered in the platform, as if this room were in another company). It is understood within the framework of the present invention that a meeting can be established with more than two participants. It is also understood that additional participants may always be added during the course of a meeting, using the same methods and system.

FIG. 7 shows an example of process flow of the different states of a meeting

The platform, based on a processor, determines if an action can be performed depending on different databases of relevant information (room reservations, current and scheduled activities, profiles of the rooms and users, customer profiles and processes of business related to meetings, status of codecs, network topology, availability and loading of the network in real time, as examples) and obtains real-time status of the different components with all its features and capabilities (such as codec, network, routers, switches, meeting rooms, present and future presence of rooms and users, etc.)

Depending on the result of this evaluation, the platform instructs the codes (and eventually participants) to call and connect to the corresponding virtual room (VMR), or it can also instruct the MCU to generate calls to certain rooms (or all) or participants.

It should be noted that in this document the ISU never interacts directly with the codec in the room, and for this reason it can not be confused with a remote control of the codec, but it is rather a service control interface. Some very minor and codec-specific functions may be controlled directly by the ISU without going through the service platform (for example, in certain specific cases controlling the volume of sound). The platform is structured in layers, which allows to separate the control of the codees from the rest of the functions, and in this way have the ability to control a great variety of brands and models of codees, generating great benefits in terms of maintaining an experience homogeneous of the user in all the rooms independently of the codec model in the room, being able to add rooms or update part of them with different models without affecting the users, etc.

The information that the platform gives to the ISU (of the room or staff), may include present status of the room, the meeting, its invited or already connected participants, availability, current and future presence of the rooms and users in the next x hours (x: configurable by client or user), state of the network, quality of each call, potential conflicts in the near future, recommendations and notifications for users, how long participants can participate in the meeting and its extensions, etc. The user can then reserve the room and start the meeting, specifying the time requested for it, without any risk of generating conflicts with other previously scheduled meetings that may require any of the invited rooms (whether local or collaborative meetings). The ISU will be able to show a "slider" in the GUI so that the user can select the duration of this meeting.The size of the slider will change automatically depending on the future time actually available in the room: the user will not be able to select a time longer than availability real room according to all the information available on the platform.

We assume that the room is in an available state (1)

Start a local meeting (2). The user selects and moves the time slider to select the desired duration of the meeting. When releasing the slider, the ISU sends the corresponding request to the platform. The platform changes the state of the room from "available" to "local meeting", and modifies the view of the ISU user interface. It will update the status (present and future) of this room in the repository, and in the directories of all other rooms.

Interact with the ISU in a local meeting (3). The user can easily move from the "room control" view to the "management of the meeting" view. Through the control view of the room, the user can manage the behavior of all local aspects in the room. For example, start or stop he sent the contents of a computer on the screens, modify volume. When generating the user these instructions, the platform will send the corresponding instructions to the TVs / projectors controlled by the platform.

In the meeting management view, the user can extend the current meeting, join an ongoing collaborative activity (through a list of all ongoing activities that the platform updated to the ISU), or start their own meeting automatically Collaborative (by inviting another room or participant through the ISU)

While in a local meeting, the user can:

- Stay in a local meeting (3) using the control view of the room to manage all the functionalities and devices in the same room

 - At some point this room may be invited to participate in another collaborative activity by another user / room (4)

 - Join from this room to a collaborative activity in progress in the company

(5)

 - Create a collaborative activity by inviting other rooms or users (6)

Be invited to participate in an existing collaborative activity (4). In available state (1) or in a local meeting (3), the room can be invited from a collaborative activity in progress (scheduled or instantaneous initiated by another user) to join. Once invited, the ISU of the room will show an invitation indicating who invites, the name of the meeting and its duration. The invitation will remain on the ISU screen for the entire duration of the invitation, except if the invited user cancels the invitation, or if a guest user declines the invitation. In these two previous cases, the platform will cancel all state changes and return each room to its previous state.

- The user in the local room can suspend the invitation: it remains active, but the user can continue to use the room in their local meeting. At any time the user can retrieve the invitation and decide to accept or reject it.

 - The user in the local room accepts the invitation: in this case the platform generates the instructions to the codees to establish the call to the VMR already existing for this activity. The platform registers the change of the state of the room to "connected" (collaborative). Alternatively, as we have already established, the platform will be able to instruct the MCU to generate the call from the specific VMR of this meeting to the user / room.

Join an existing collaborative activity (5). While at a local meeting, a user can choose to join an existing and active collaborative activity in the organization

By selecting the "join" button, the ISU displays the updated list of all these activities in progress (or about to begin). The user selects one of these, the ISU instructs the platform which will then pass to the local codec the instructions and codes (ID and password) necessary to connect to the VMR corresponding to the chosen meeting.

In the event that this activity has been declared confidential by its owner, the platform will previously request via the ISU to enter a PIN of confidentiality, it will be compared with the PIN defined for this meeting, and in case of success it will continue with instructing the codec to connect.

Create a collaborative activity (6) by inviting other participants. The user can choose to invite another room (available or in local meeting). In this case the ISU will ask the platform to provide all the updated information available from all the rooms: current status (codec on / off / connected, not available) as well as future status (all future activities scheduled for each room).

By graphically displaying this information, which includes an aggregate state of availability status for this specific meeting, the user can now easily visualize which rooms are actually available for this meeting or not (for example, a codec may be out of service, already connected, or the room may have been reserved previously for another meeting whose start is prior to the end of the local meeting generating an eventual conflict), when time may participate in this meeting, or as long as more may be available to be invited) .

The user can select one or several rooms in the ISU, and start the activity. The ISU will then inform the platform, which revisits the present and future availability of these invited rooms. If it does not detect conflicts, the platform:

- Defines a new random ID of VMR

 - Choose an MCU, and ask the MCU to create a new VMR with the ID

 - Instruct the local codec to connect to the VMR

- Instruct all guest codes to connect to the VMR (if these codes have been configured in the repository to accept connections) automatically), or show an invitation in the ISU of the rooms. In this case, the users in each invited room must execute the same process indicated in "Being invited to participate in an existing collaborative activity (4)". Note: connecting a single room or several rooms is done using the same process. Thus, a so-called "point-to-point" is handled transparently for the user in the form of a "multipoint meeting hosted in a random VMR created by the platform". The user experience is similar to that of calling another room, while in reality the platform follows the whole process and manages a multipoint meeting.

Note: once connected to a collaborative activity with another participant (s), the user may need to add other rooms / participants at any time. Simply repeat the previous process, which will behave as "add participant", since the virtual room was created and the local room is already connected to it.

Release the room (8). While in a local meeting, the user can choose to end the meeting. Simply press the "free room" button on the ISU, which will inform the platform. This will change the state of the room (it will be available again), update the status in the ISU of this room, but also in the ISUs of all the rooms (and the personal controllers).

End a collaborative meeting. While in a collaborative activity, the user has two options in the ISU to choose how they want to end their participation in this activity: Disconnect from the activity and release the room (9) + (10): the platform will disconnect the room from the activity, but it will also release the room (8) and cancel the current reservation (it will modify its end time to now). The platform will notify all other rooms and users that this room is now unused and available.

 Disconnect from the collaborative activity but keep the room reservation (9) + (11): The user can continue using the room in local meeting mode until the end of the time previously reserved for this room. Or perform any activity typical of a local meeting (extend the time of the meeting, join an activity, create a new one)

Note: it is possible to configure the platform (in the information repository server) to automatically disconnect all the participants of the meeting in case the owner of the meeting (for example, the user who created the reservation or started the meeting, the room that was previously marked as the owner's room, or the room that started the activity) voluntarily disconnected from the activity.

Other new functionalities allowed by the signaling and platform of this invention:

Auto-reconnect: in certain cases (for example, momentary outage in a network link), a codec can be disconnected in an unwanted way from a collaborative activity. The platform detects this situation (through the information repository server) but also knows that the user did not request the disconnection (the ISU never notified this request to the platform). In In consequence, you can deduce that it is not a desired cut, and instruct the codec to reconnect to the conference (same VMR) as soon as it detects that the link returns to normal. It generates a benefit to the user by reducing unavailability times and the impacts of these in the meetings in progress. Automatic connections and conflict detection process. With full knowledge of all current states and scheduled activities, the platform can perform an activity of automatically connecting all the rooms to their respective meetings at the time established in the respective reservations. On the other hand, the knowledge of these states and activities allows us to provide users and support personnel with interfaces of processes that:

- They show all the sites that will have a potential conflict in the near future, such as:

 o Codec is off but there is a next meeting that I invite this room or Codec connected, but not to the correct activity. In effect, the platform always knows in which activity the room / codec is located, and in which activities it is scheduled

 o Other numerous situations of conflict or potential problem

- Show all the sites that are encountering some type of inconvenience Extensive functions to other types of components. All the signaling and benefits of the present invention can also be applied to other types of devices in meeting rooms, used to connect to collaborative activities. A good example of these are conference phones, which they can be managed by the platform in the same way as video conferencing codes, incorporating an ISU in the room.

Note: In certain cases, it is possible to incorporate the ISU directly into the device interface. Auto-terminate: the platform can handle functions of self-termination of meetings and calls. The user can always visualize the remaining time for the current meeting, receives notification of the soon-to-be-terminated meeting, and can easily extend the meeting from the ISU (provided there is room availability). When the meeting arrives at the end of the schedule established for the meeting, the platform will send instructions to all the codees participating in disconnecting from the activity. This allows you to terminate connections even if the user has forgotten to disconnect the call, with the benefits of greater confidentiality (someone could enter the room and have a private conversation without realizing that the room is still connected to other participants) and greater use and availability of the meeting rooms (since reservations are automatically completed at the end, they are immediately available to other users).

Auto extension: the platform can be configured to automatically extend all meetings and activities in progress until they are in conflict with other reservations. In this case the user must always notify of the end of an activity in the ISU. This can be activated for specific meetings (for example VIP) to prevent the rooms from being disconnected in the event that the executive has forgotten to disconnect. Group self-extension If one of the participating rooms requests the extension of the activity via the ISU, it will notify the platform, which in turn will extend all the agendas of all the participating rooms and will notify each room via its respective ISU. In case of future conflict in some of the rooms, the platform will propose the option of extending the participation of these rooms only until the beginning of the next meeting to avoid conflicts, or propose to notify the owner of the next meeting to evaluate if it is of agreement to cancel your meeting.

Automatic room changes: in case of detecting a potential conflict, the platform has all the information and resolution and signaling capabilities to automatically propose an alternative (and nearby) meeting room for the next meeting, informing all participants that there was a change of room and indicating the new room to use. When the room arrives, it will be available to be connected to the meeting. Management of VIP profiles: the platform manages numerous parameters and information from a variety of information sources to detect conflicts or define behaviors. It is then possible to implement a specific behavior for certain rooms, participants or even for specific activities. For example, a meeting can be configured by the user as a VIP. In this case, the auto-termination function will be disabled for this meeting, and the auto-extension function will be activated for all participating rooms. The rooms will not be disconnected until the VIP user requests it via his ISU and thus notified to the platform. In this scenario, previous reservations of the rooms involved can be notified and reassigned to other rooms available, and users of upcoming reservations will be automatically notified by the platform of these changes, as well as showing the changes on a specific screen located near the doors of each meeting room. These same functions can be used to automatically handle device failures (camera, codec, screen) in room devices, or room unavailability (maintenance), reprogramming alternative rooms for the meeting.

The present invention is supported by its own network of type MPLS (MultiProtocol Label Switching), specially adjusted to support quality of service in videoconference flows, interconnecting its essential components with high quality and availability. Users will have access to additional benefits from this global network, for example, using it to transport high-quality international bandwidth to avoid investing in additional capabilities in their own network. Even so, the platform object of this invention can be hosted or connected by any other means or link (public cloud, private cloud, On-Premise, SDWAN networks, hybrid public / Onpremise environment, etc.).

Interconnection options:

- An interconnection link may be required between the client's network and the platform, in case of not using a Public Cloud topology.

- For example, an MPLS type link to the nearest point of presence to ensure the best quality and availability VPN over the internet to reduce costs, or as an alternative means of backup to improve redundancy.

Integration options: numerous integration options with other services / platforms are available for the present invention, including:

- Integration with Active Directory ™ to facilitate the registration / entry of users without having to enter another account / password

 - Integration with Exchange ™ and Google Calendar ™ calendars, to synchronize all room, meeting or user agendas with the scheduling and conflict detection platform

 - Outlook Plugin: to create reservations and configure all its parameters directly from Outlook ™

 - SIPtrunk integration with telephone exchanges (PABX) or telephone services, allowing users to easily participate in any meeting even from a conventional telephone.

 - Integration with Skype for Business ™, to allow integration with corporate users in conferences

Distributed architecture In certain cases, a company may require (and achieves with the present invention) the option of integrating the platform within its own network, using some of the interconnection options (public cloud, private cloud or hybrid). Options: the system of the present invention is compatible with a wide variety of devices and accessories within the rooms of different manufacturers, thanks to its structure in layers and client server architecture. You can add a smart screen on the door of the room synchronized with the platform, which allows you to see the agenda of the room from the door, start meetings, accept invitations or check-in, extend or end meetings. O presence sensor to determine presence of participants in the room. Or peripheral control systems to further improve the usability of the room.

Security and confidentiality are keys for executives: The present invention includes essential improvements such as Dynamic VMR (the platform creates a unique and dedicated virtual room for each meeting), and random passwords. Users no longer need to change their passwords, or generate confidentiality risks if they forget to do so. The user can review in real time the list of connected users from their RoMA or block their meeting when necessary.

But they also benefit from not being disturbed while they are in a meeting: No more interruptions for an unexpected incoming call: instead they will receive a persistent invitation in their RoMA. You can accept it to join the conference at any time. Or they can join any conference in progress from any available room if they know the confidentiality PIN.

The platform allows to deliver the same user experience in each room, regardless of the brand codec, its model or SW version. The The user experiences the same behavior in each situation: call point to point or multipoint are obsolete concepts. Now a meeting is a meeting, with all the functionalities available when you need them

Mission-critical design: reliability is the key to user adoption. The call and meeting management platform of this innovation was designed to guarantee its availability. The RoMA ™ service interface (ISU) is a dedicated device, and can be remotely monitored and managed by a complementary help desk if required. Automated scheduled meeting launches and automatic reconnect functionality are examples of how the present invention prevents and resolves the vast majority of common problems. Exclusive QoS monitoring tools and unique reports help the IT area to maintain its network compatible with the high quality requirements for conferences, while user satisfaction measurements from each room via the ISU contribute to continuous improvement plans .

Self-service: In the era of the smartphone, executives are accustomed to self-service, at any time and immediately, without having to call an operator of the help desk or require an IT technician next to the door. Now you can really focus on your meetings! The functions of the platform delivered via the ISU allow users to attend:

Control the room • Multipoint layout

 • PiP

 • Zone-based camera control

 Send / stop presentation

 Mute and volume control

Manage and manage meetings

 • Invite rooms and people

 • Join a meeting in progress

 • Extend your meeting

 • End participation in the conference

 • Release the room and finish your reservation

Prevent conflict situations in meeting rooms Most companies require scheduling meetings to ensure the coordination of people and resources. But users also want it to be possible to easily start a meeting instantly in a room that is available. The rooms equipped with video conference are usually used for local meetings, generating potential conflicts and inconveniences with videoconferences. Does the user need to extend meetings with multiple rooms connected? Or use the room as soon as a meeting is canceled or terminated in advance? The present invention provides flexibility and autonomy of the users and at the same time prevents conflicts assuring the satisfaction of the users in any situation.

Connect any standard video conference room to a meeting

The platform object of this invention was designed based on standard market protocols, so it allows to ensure compatibility with incoming calls in H.323 or SIP. It also allows to generate calls to these devices in a simple and self-service way: thanks to the ISU, the user can select a specific entry in the directory of sites, including external rooms. Upon receiving the request from the ISU, the platform will generate an instruction to the MCU to generate a call from the VMR corresponding to the destination site.

Schedule video conferences, rooms and meetings.

The platform of this invention will easily manage these three layers via the service portal, integration with Exchange ™ / Google Calendar ™ or the Outlook ™ plugin. The integration of these layers together with the RoMA facilitates powerful functionalities such as: inviting a room even if it is in a local meeting, automatically extending the reservations of all meeting rooms, disconnecting the video call without finalizing the local reservation, preventing conflicts of use of rooms, etc. Invite people The user can send the invitation provided by the present invention at the time of scheduling, or at any time during the meeting from the ISU in the room (RoMA ™), or from his or her personal ISU. Advanced security. It is no longer necessary to schedule virtual rooms (VMRs): the present invention automatically and transparently creates a new virtual room (VMR) dedicated to each meeting. The platform generates a random ID with the password included for each meeting. Accessing online the list of connected participants from the ISU in the room (or the personal ISU), are examples of how security is at the heart of the present invention.

Mobile users

Participate or invite other users to any meeting at any time, from a PC, tablet or Smartphone, with video, audio and content. Use the company's preferred software client for internal users (Skype for Business ™, On365 ™, Realpresence ™, Jabber ™ etc).

Easily invite business partners without requiring them to install software. With a single click on a Chrome ™ browser and are connected to the meeting.

Integrated Conference Cali Integrating the present invention with an IP PBX allows to dial any meeting from an internal annex. Or you can invite external participants to dial a DID number to your PBX. They can even use an integrated service to participate in the conference by dialing a local number from almost any country in the world. The platform has the ability to automatically route the call to the VMR corresponding to its meeting, and regardless of the type of implementation (even in a hybrid configuration). In effect, you can route directly to a MCU-type component distributed in your own network. Recording and Streaming. Record any meeting. The user can request it at the time of scheduling the meeting, directly from the ISU (room or staff RoMA), or request it from a specialized help desk.

Confidentiality is always considered. The client can define their own workflow and permissions: who is authorized to request a recording, who will receive the file of the recording, or where they want the files to be delivered and stored, are key aspects to consider for any reliable recording service.

It allows to easily broadcast any meeting by streaming to a large audience (up to 1000 simultaneous viewers).

The user only needs to forward to his audience the URL that the platform created and delivered automatically at the time of booking. At the established start time, the platform will generate the video, audio and content flows to the invited users. The invention allows managing recorded videos on an integrated centralized / distributed platform. It allows the user to define tags for each meeting, assign the video to one or more channels for different audiences (through the scheduling interface, or via the ISU). The contents will be immediately available to the desired audience. Reports Having information is key to measuring the service and continuously improving user satisfaction. The present invention provides profiled and customized reports online and in real time. Use of meetings, rooms and video conference; User behavior, satisfaction of users in each room or satisfaction of the owners for each meeting. QoS (Quality of Service) by conference and even detailed graph by connection, or even benefits and sustainability, are some examples of the depth of reports that the structure of the platform of the invention allows.

Control and manage the meeting easily, with the assistant of the meeting room Room Assistant Assistant (ISU) of the present invention. The user does not need to request and wait for support. Only do what you need and when you need it. The conferences are launched automatically on time. In case of unexpected cuts in video calls, the rooms are automatically reconnected immediately. The user can use any meeting room available at any time without having to resolve scheduling conflicts, and much more ... Attributes of ease of use, self-service and intuitive behavior, combined with a meeting service of high quality and reliability and complete in functionalities are the keys for user satisfaction. With great benefits in increasing the use and reducing the learning curve, the platform contributes in achieving the objective of a better efficiency in expenses and investments in collaboration technology. With the Room Display integrated to the platform of the invention, together with the management of smart meeting rooms, it increases the availability of meeting rooms and increases the ROI of the square meters of offices Processes and personalized workflows of the present invention ensure a harmonious integration with the policies of the organizations and habits of their executives, which in turn drives adoption and cultural change. The invention makes it possible to obtain all the expected benefits and capitalize the potentials of videoconferencing and collaboration technologies across the entire organization. It is a contribution to the digital transformation of companies.

The present invention integrates different functions in a single service, while many companies have to contract each one from different providers or platforms. It allows easier and integrated management, control and auditing.

Thanks to the numerous automated functions incorporated in the invention, it allows to reduce the amount of support personnel usually required to support videoconferences, delivering self-service capacity to users, increasing flexibility, quality and confidentiality. The automated functions based on processes and wokflows ensure a consistent experience for users, reducing the impact of possible human errors, as well as the load on the computer and support equipment.

Claims

1. A method for a service platform to manage videoconference calls between several sites, CHARACTERIZED because it includes the stages of:

 to. Establish a directory of users in an information repository.

 This user directory including authentication information, and a list of available codes. Each of these codes in this list includes information related to elements in communication with this codec.

 b. Establish a schedule of availability of rooms available for meetings, this schedule being updated based on requirements

 c. Receive a videoconference requirement from a user, this requirement includes other users for this conference as well as a time window for this conference

 d. Analyze the scheduling of availability and users in such a way to identify available resources for this conference and these users.

 and. Review this availability schedule based on these results

F. Notify this conference to these users, informing of a location for this conference for each user g. Call and connect the codes corresponding to this conference at the time established for its start

 h. Establish this conference based on the authentication of users in the rooms corresponding to the respective codes

 i. Where this service platform is in communication with at least one information repository

 2. The method of claim 1, CHARACTERIZED because the authentication is performed based, at least in part, on facial recognition

 3. The method of claim 1, CHARACTERIZED because the authentication is performed based, at least in part, on speech recognition

 4. The method of claim 1, CHARACTERIZED because this conference is controllable using a controller with a graphical user interface (GUI) in at least one room.

 5. The method of claim 4, CHARACTERIZED because said controllability includes the functionality of adding other rooms during the meeting

 6. The method of claim 4, CHARACTERIZED because said controllability can be performed remotely to the controlled room

7. The method of claim 4, CHARACTERIZED because said controllability includes the functionality of controlling what is displayed on the screen

8. The method of claim 4, CHARACTERIZED because said controllability includes the functionality of controlling the duration of said conference and, when executing this control, that said The service platform determines if the users and / or the rooms should be relocated and so it is notified to all and / or each one.

 9. The method of claim 4, CHARACTERIZED because said GUI is updated based on the participants present / connected to the conference, and a user can control the screens, camera, codec or microphone from said GUI

 10. The method of claim 4, characterized in that said controller is associated with an app on a smartphone or tablet

 1. The method of claim 1, CHARACTERIZED because in case of an unexpected and unsolicited disconnection, the service platform reconnects the call automatically

 12. The method of claim 1, CHARACTERIZED because the aforementioned GUI in each room presents a persistent invitation until all users in the room have been authenticated

13. A system for videoconferencing, CHARACTERIZED because it includes a. In a first room (room 1), it includes at least one camera, at least one microphone, at least one screen or projector, a first codec, and a controller that includes a graphical user interface to exercise control, mentioned first codec in communication with the other elements of the aforementioned room 1 b. In a second room (room 2), it includes at least one camera, at least one microphone, at least one screen or projector, a second codec, and a controller that includes a graphical user interface for exercise control, the aforementioned second codec being in communication with the other elements of the aforementioned room 2 c. A service platform in communication with the aforementioned codes; and a repository of information in communication with the aforementioned service platform: where the service platform controls user access and the scheduling for the set of sites, and where the GUI is updated based on changes in call states

 14. The system of claim 13, CHARACTERIZED because said controllability includes the functionality of adding other rooms during the meeting

 15. The system of claim 13, CHARACTERIZED because said controllability can be performed remotely to the controlled room

16. The system of claim 13, CHARACTERIZED because said controllability includes the functionality of controlling what is being displayed on the screen

 17. The system of claim 13, CHARACTERIZED because said controllability includes controlling the duration of the conference or meeting, and when executing this control, said service platform determines whether the users and / or the rooms must be relocated and so on. it is notified to all and / or each one.

18. The system of claim 13, CHARACTERIZED because said GUI is updated based on the participants present / connected to the conference, and a user can control the screens, camera, codec or microphone from the aforementioned GUI

 19. The system of claim 13, characterized in that in case of an unexpected and unsolicited disconnection, the service platform reconnects the call automatically

 20. The system of claim 13, CHARACTERIZED because the aforementioned GUI in each room presents a persistent invitation until all users in the room have been authenticated

 21. The system of claim 13, CHARACTERIZED because said controller is associated with an app on a smartphone or tablet

 22. An apparatus for distributed videoconferencing, CHARACTERIZED because it includes:

 to. A manageable media switch for communicating with a video bridge that can be managed to receive control information, as well as multiple streams of audio, video and content from at least a first and a second terminal equipment (codec) for a meeting of videoconference

 b. An engine to authenticate use of room and participants in each room c. A communication port for communicating equipment for encoding and sending audio and video within the room, and for receiving an input stream and sending an output stream; Y

d. A communication channel with at least one information repository and. Where the mentioned apparatus postpones the establishment of the call until authenticating the users in the corresponding rooms f. Where an entry-to-exit mapping for each room is determined for each video entry, based on at least one delivery algorithm and control instructions received from a controller g. Where the aforementioned media switch is controlled by a service platform based on commands received from a controller inside the room for controllability with a graphical user interface (GUI); Y

 h. Where based on programmed control instructions, said apparatus delivers a recording of said video delivered to said information repository

 23. The apparatus of claim 22, CHARACTERIZED because the controllability includes the functionality of adding other rooms during the course of the conference.

 24. The apparatus of claim 22, CHARACTERIZED because the controllability can be performed remotely to the controlled room

25. The apparatus of claim 22, CHARACTERIZED because the controllability includes the functionality of controlling what is being displayed on the screen

26. The apparatus of claim 22, CHARACTERIZED because the controllability includes controlling the duration of the conference or meeting, and when executing this control, that the aforementioned service platform determines whether the users and / or the rooms must be relocated and so it is notified to all and / or each one.

 27. The apparatus of claim 22, CHARACTERIZED because said GUI is updated based on the participants present / connected to the conference, and a user can control the screens, camera, codec or microphone from the said GUI

 28. The apparatus of claim 22, CHARACTERIZED because in case of unexpected and unsolicited disconnection, the service platform automatically reconnects the call.

29. The apparatus of claim 22, CHARACTERIZED because said GUI in each room presents a persistent invitation until all users in the room have been authenticated.

 30. The apparatus of claim 22, CHARACTERIZED because said controller is associated with an app on a smartphone or tablet.