Patent Description:
Various types of videoconferencing systems are known, including those described in <CIT> (now <CIT>.

Typically, a videoconferencing room includes a system controller connected to a codec and other components in the room. The system controller includes a user interface such as a keypad, touchscreen and/or handheld remote to control the codec and other components in the room.

Some videoconferencing systems require that a mobile phone application and a codec are registered to a same proprietary cloud-based service (e.g., CISCO SPARK). A server in the cloud may store scheduled conference call information for the registered codec, and transmit information regarding the scheduled conference call to the registered mobile phone application to allow a user of the mobile phone application to initiate the scheduled conference call stored on the server. This approach is limited to specific videoconferencing components and videoconferencing service providers that are registered with the proprietary cloud-based service.

<CIT>) discloses methods and systems for joining a video conference endpoint to a video conference. A user may use a mobile device to take a picture of a Quick Response (QR) code or may place the mobile device in close proximity to a Near Field Communication (NFC) tag. Such QR code or NFC tag may be associated with a video conference endpoint. The user may then transmit the information encoded by the QR code or NFC tag, along with a meeting identifier, to a server. The server, in turn, may instruct a video conference endpoint identified by the QR code or NFC tag to join a video conference identified by the meeting identifier.

<CIT>) discloses systems, methods, and modes for initiating a conference call on a conferencing endpoint from a portable electronic device. The system comprises a conferencing endpoint associated with a network address and configured for receiving conferencing information and using said conferencing information to dial a conference call. The system also comprises a portable electronic device comprising a network interface configured for enabling communication between the portable electronic device and the conferencing endpoint. The portable electronic device pairs with the conferencing endpoint using the conferencing endpoint network address. The portable electronic device transmits dialing or conferencing information to the conferencing endpoint by accessing a calendar application, accessing a scheduled meeting event associated with the calendar application, retrieving conferencing information associated with the scheduled meeting event, and transmitting the conferencing information to the conferencing endpoint.

According to one aspect of the present disclosure, an example videoconferencing system includes multiple videoconferencing rooms, and a server adapted to store information regarding each videoconferencing room. Each videoconferencing room includes a videoconferencing codec and a system controller in communication with the videoconferencing codec via one or more wired and/or wireless communication networks to control the videoconferencing codec, and the system controller is in communication with the server via the one or more wired and/or wireless communication networks. The system also includes a mobile computing device including a user interface. The mobile computing device configured to communicate with the server via the one or more wired and/or wireless communication networks to exchange data with the server to determine whether at least one of the videoconferencing rooms is within a defined proximity of the mobile computing device. The mobile communication device is further configured to, in response to determining that at least one of the videoconferencing rooms is within the defined proximity, and in response to the user selecting said at least one of the videoconferencing rooms, transmit one or more commands to the server. The server is configured to transmit the one or more commands to the system controller located in the at least one of the videoconferencing rooms. The system controller is configured to control the videoconferencing codec located in the at least one of the videoconferencing rooms according to the one or more commands to establish or control a videoconference in said at least one of the videoconferencing rooms.

Further aspects and areas of applicability will become apparent from the description provided herein. It should be understood that various aspects and features of this disclosure may be implemented individually or in combination with one or more other aspects or features. It should also be understood that the description and specific examples herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

A videoconferencing system according to one example embodiment of the present disclosure is illustrated in <FIG>, and indicated generally by reference number <NUM>. As shown in <FIG>, the system <NUM> includes multiple videoconferencing rooms 104A and 104B, and a server <NUM> adapted to store information regarding each videoconferencing room 104A and 104B.

The videoconferencing room 104A includes a videoconferencing codec 106A and a system controller 108A in communication with the videoconferencing codec 106A via one or more wired and/or wireless communication networks <NUM> to control the videoconferencing codec 106A. The system controller 108A is in communication with the server <NUM> via the one or more wired and/or wireless communication networks <NUM>.

Similarly, the videoconferencing room 104B includes a videoconferencing codec 106B and a system controller 108B in communication with the videoconferencing codec 106B via one or more wired and/or wireless communication networks <NUM> to control the videoconferencing codec 106B. The system controller 108B is in communication with the server <NUM> via the one or more wired and/or wireless communication networks <NUM>.

The system <NUM> further includes a mobile computing device <NUM>, such as a smartphone, a tablet computer, a laptop computer, etc. Although <FIG> illustrates the mobile computing device <NUM> as a smartphone, other mobile computing devices can be used similarly.

The mobile computing device <NUM> includes a user interface (e.g., a keypad, a touchscreen, etc.) to receive input from a user <NUM>, and the mobile computing device <NUM> is adapted to communicate with the server <NUM> via the one or more wired/and or wireless communication networks <NUM>. For example, the communication network(s) <NUM> may include a WiFi network, a cellular network, a public communications network such as the Internet, a private proprietary network, network cables, etc..

The mobile computing device <NUM> is configured to exchange data with the server <NUM> to determine whether at least one of the videoconferencing rooms 104A and 104B is within a defined proximity <NUM> of the mobile computing device <NUM>. Although <FIG> illustrates the defined proximity <NUM> as a physical distance, the defined proximity may include any suitable proximity, such as a wireless signal strength, a physical distance threshold, etc..

The mobile computing device <NUM> is further configured to, in response to determining that at least one of the videoconferencing rooms 104A and 104B is within the defined proximity <NUM>, and in response to the user selecting said at least one of the videoconferencing rooms 104A and 104B, transmit one or more commands to the server <NUM>.

The server <NUM> is configured to transmit the one or more commands to the system controller 108A or 108B located in said at least one of the videoconferencing rooms 104A or 104B. The system controller 108A or 108B is configured to control the videoconferencing codec 106A or 106B located in said at least one of the videoconferencing rooms 104A or 104B according to the one or more commands to establish or control a videoconference in said at least one of the videoconferencing rooms 104A or 104B.

The smartphone <NUM> may exchange data with the server <NUM> to determine whether at least one of the videoconferencing rooms 104A and 104B is within the defined proximity <NUM> of the smartphone <NUM> according to one or more wireless signals received by the smartphone <NUM>. For example, as described further below, the smartphone <NUM> may exchange data with the server <NUM> to determine that the videoconferencing room 104A is within the defined proximity <NUM> of the smartphone <NUM> according to one or more received wireless beacon signals, a global positioning (GPS) signal, one or more received wireless access point channel signals, etc..

The server <NUM> may be a remote server based in a cloud (e.g., an AMAZON Web Services (AWS) cloud, etc.) at a separate location from the system controller 108A or 108B, such as a corporate data center server. Alternatively, or in addition a server <NUM> may be located on the same premises (e.g., on-site) as the system controller 108A or 108B, etc. For example, the server <NUM> could be a gateway server that acts as a proxy to direct the scheduled conference call information to the correct system controller 108A or 108B. The server <NUM> may store information regarding the videoconferencing rooms 104A and 104B, such as locations of the rooms, etc..

A videoconferencing system according to another example embodiment of the present disclosure is illustrated in <FIG>, and indicated generally by reference number <NUM>. As shown in <FIG>, the system <NUM> is similar to the system <NUM> of <FIG>, but further includes two wireless beacons 216A and 216B. The wireless beacon 216A is located in the videoconferencing room 104A and the wireless beacon 216B is located in the videoconferencing room 104B.

Each wireless beacon 216A and 216B includes a unique universal identifier (UUID), and the UUID of each wireless beacon 216A and 216B corresponds to a different one of the videoconferencing rooms 104A and 104B. Specifically, the UUID of wireless beacon 216A corresponds to the videoconferencing room 104A and the UUID of wireless beacon 216B corresponds to the videoconferencing room 104B.

The smartphone <NUM> may exchange data with the server <NUM> to determine whether at least one of the videoconferencing rooms 104A and 104B is within the defined proximity <NUM> of the smartphone <NUM> by identifying the UUID of one or both of the wireless beacons 216A and 216B, determining whether a signal strength from one or both of the wireless beacons 216A and 216B exceeds a threshold corresponding to the defined proximity <NUM>, and if so, determining the videoconferencing room 104A or 104B corresponding to the identified UUID having a signal strength exceeding the threshold.

In some embodiments, the smartphone <NUM> may identify the UUID of a nearest one of the wireless beacons 216A and 216B according to signal strengths from the wireless beacons 216A and 216B, may identify the UUID of only the wireless beacons 216A and 216B having the strongest signal strength (e.g., a strongest relative signal strength indicator (RSSI)), etc..

For example, the smartphone may determine whether an RSSI value from each of the wireless beacons 216A and 316B is above a specified threshold, may determine whether an estimated distance according to the RSSI value is within a physical distance threshold such as about ten feet, about fifty feet, about ten meters, etc. Once the smartphone <NUM> identifies a UUID, the smartphone <NUM> may transmit the identified UUID to the server <NUM> determine which videoconferencing room 104A and 104B corresponds to the identified UUID.

The beacons 216A and 216B each broadcast their UUID into the local environment (e.g., the videoconferencing rooms 104A or 104B, etc.). The smartphone <NUM> may scan for the UUIDs and associate a proximity of the smartphone <NUM> to the beacons 216A and 216B based on a relative signal strength indicator (RSSI) algorithm, which may be stored in the smartphone <NUM>.

The RSSI allows for approximation of distance between the smartphone <NUM> and the source of the signal (e.g., one of the wireless beacons 216A and 216B). When the smartphone <NUM> is within a defined proximity distance threshold (e.g., about ten feet, about fifty feet, about ten meters, etc.) of one of the wireless beacons 216A and 216B, the smartphone <NUM> may resolve the address of the UUID received from the wireless beacon to a corresponding videoconferencing room 104A or 104B through a secure sockets layer (SSL) transport layer security (TLS) connection to the server <NUM> and then to the corresponding system controller 108A or 108B. For example, the secure SSL TLS connection may be established through AMAZON web services (AWS), etc..

The wireless beacons 216A and 216B may include any suitable wireless beacon devices, such as a short-range wireless communication (e.g., BLUETOOTH) beacon, a WiFi beacon, a radio-frequency identification (RFID) beacon, a near-field communication (NFC) beacon, etc. The UUID may include one or more of a major UUID, a minor UUID, an iBeacon identifier, an Eddystone (e.g., a UID, a uniform resource locator (URL), a TLM), an encrypted Eddystone (e.g., an EID, an ETLM), etc..

In some embodiments, each wireless beacon 216A and 216B may be associated with its corresponding system controller 108A and 108B by having a same Eddystone URL address. For example, each system controller 108A and 108B may use a different Eddystone URL, which may be configured and loaded on the system controllers 108A and 108B during setup of the system controllers 108A and 108B, etc. Specifically, during the setup process a unique Eddystone URL address may be assigned and paired to a media access control (MAC) address of one of the system controllers 108A and 108B, which may be the same as the Eddystone URL of the corresponding wireless beacon 216A or 216B.

Once a smartphone <NUM> recognizes one or more of the wireless beacons 216A and 216B, the smartphone <NUM> may check whether the user <NUM> has appropriate privileges to access the videoconferencing rooms 104A or 104B corresponding to the recognized beacons 216A or 216B.

Each videoconferencing room 104A and 104B may allow access to anyone with a login credential (e.g., a login credential of a control application on the smartphone <NUM>), to only users that have an authenticated email address from a specific domain (e.g., john. com where nike. com is the specific domain), to only a predefined list of users, to only a single user for a private office, etc. As described further below, the smartphone <NUM> may also check (e.g., with the server <NUM>) whether a GPS location of the smartphone <NUM> is within a specific geographic location (e.g., a GPS location) where the wireless beacon 216A or 216B is located to inhibit "spoofing" or unauthorized location access.

A videoconferencing system according to another example embodiment of the present disclosure is illustrated in <FIG>, and indicated generally by reference number <NUM>. As shown in <FIG>, the system <NUM> is similar to the system <NUM> of <FIG>, but further includes two wireless access points <NUM> and <NUM>, such as WiFi routers, etc..

The wireless access point <NUM> and <NUM> may be separate from the videoconferencing rooms 104A and 104B as shown in <FIG>, although the wireless access points <NUM> and <NUM> could be located in the videoconferencing rooms 104A and 104B in another embodiment.

Each wireless access point <NUM> and <NUM> may include one or more wireless signal channels, and the smartphone <NUM> may receive different signal strengths of the one or more wireless signal channels of each access point <NUM> and <NUM> depending on a position and/or distance of the smartphone <NUM> relative to each wireless access point <NUM> and <NUM>.

Similarly, each videoconferencing room 104A and 104B may be associated with a defined wireless signal strength signature corresponding to received signal strengths from each of the multiple wireless access points <NUM> and <NUM> at the locations of the videoconferencing rooms 104A and 104B.

For example, the videoconferencing room 104B may receive a strong wireless signal strength from the wireless access point <NUM> because the videoconferencing room 104B is close to the wireless access point <NUM>, and may receive a weak wireless signal strength from the wireless access point <NUM> because the videoconferencing room 104B is far from the wireless access point <NUM>. Similarly, the videoconferencing room 104A may receive medium wireless signal strengths from the wireless access points <NUM> and <NUM> because the videoconferencing room 104A is located at a medium distance from both wireless access points <NUM> and <NUM>.

A correspondence relationship table (e.g., a heat map, etc.) may be generated that includes a defined wireless signal strength signature for each videoconferencing room 104A and 104B according to the received signal strengths from each of the wireless access points <NUM> and <NUM> at the locations of the videoconferencing rooms 104A and 104B. The correspondence relationship table may be stored at the server <NUM>, the smartphone <NUM>, etc., and can be used to identify a location of smartphone <NUM>.

<FIG> illustrates an example heat map <NUM> including multiple wireless access points <NUM> and multiple videoconferencing rooms <NUM>. The heat map <NUM> illustrates strength of WiFi signals from the wireless access points at different locations among the multiple video conferencing rooms <NUM>.

The smartphone <NUM> can use its wireless card (e.g., WiFi antenna, etc.) to take a local measurement of received WiFi signal strengths, and then compare the local measurement values to the heat map <NUM> to determine a location of the smartphone <NUM> relative to the multiple videoconferencing rooms <NUM>.

Referring back to <FIG>, the smartphone <NUM> can obtain a received signal strength for each of the wireless access points <NUM> and <NUM>, and transmit data (e.g., the received signal strengths) with the server <NUM> to determine whether at least one of the videoconferencing rooms 104A and 104B is within the defined proximity <NUM> of the smartphone <NUM> by identifying the videoconferencing room 104A or 104B having a defined wireless signal strength signature corresponding to the received signal strengths obtained by the smartphone <NUM>.

For example, if the smartphone <NUM> receives medium signal strengths from each wireless access point <NUM> and <NUM>, the smartphone <NUM> and/or server <NUM> may determine the smartphone <NUM> is located at or within the defined proximity <NUM> of the videoconferencing room 104A. Similarly, if the smartphone <NUM> receives a strong signal strength from the wireless access point <NUM> and a strong signal strength from the wireless access point <NUM>, the smartphone <NUM> and/or server <NUM> may determine the smartphone <NUM> is located at or within the defined proximity <NUM> of the videoconferencing room 104B.

Although <FIG> illustrates two wireless access points <NUM> and <NUM>, other embodiments may include more or less access points, having more or less wireless signal channels (e.g., at least five wireless signal channels in total, at least twenty wireless signal channels in total, etc.). The correspondence relationship table can specify signal strengths all wireless signal channels for each videoconferencing room, and the smartphone <NUM> and/or server <NUM> may determine the smartphone <NUM> is located within a defined proximity distance of a specific videoconferencing room 104A or 104B when the obtained signal strengths of the smartphone are within a tolerance threshold of the specified signal strengths of one or more (or all) wireless signal channels for one of the videoconferencing rooms 104A or 104B. For example, the tolerance threshold may be within five percent of the specified signal strength for each wireless signal channel, within ten percent, etc..

In some embodiments, each of the videoconferencing rooms 104A and 104B is associated with a global positioning system (GPS) location corresponding to a location of the videoconferencing room 104A or 104B. The smartphone <NUM> may obtain a GPS location of the smartphone, and exchange data with the server <NUM> to determine whether at least one of the videoconferencing rooms 104A and 104B is within the defined proximity of the smartphone <NUM> by determining whether one of the videoconferencing rooms 104A or 104B has an associated GPS location within the defined proximity of the GPS location of the smartphone <NUM>.

For example, the smartphone <NUM> and/or the server <NUM> may compare the GPS location of the smartphone <NUM> to the GPS locations of the videoconferencing rooms 104A and 104B to determine the nearest one of the videoconferencing rooms 104A and 104B, to determine whether one of the videoconferencing rooms 104A and 104B is within a defined proximity distance (e.g., about ten feet, about fifty feet, about ten meters, etc.) of the smartphone <NUM>, etc..

The example approaches described above for determining whether at least one of the videoconferencing rooms 104A and 104B is within a defined proximity of the smartphone <NUM> may be used individually or in combination with one another. For example, the smartphone <NUM> and/or server <NUM> could determine whether at least one of the videoconferencing rooms 104A and 104B within a defined proximity distance of the smartphone <NUM> using both GPS location and wireless beacons, both GPS location and wireless access point signal strengths, both wireless beacons and wireless access point signal strengths, etc. In some embodiments, the smartphone <NUM> and/or server <NUM> could determine whether at least one of the videoconferencing rooms 104A and 104B is within a defined proximity distance of the smartphone <NUM> using all three of GPS location, wireless beacons and wireless access point signal strengths.

In some embodiments, the GPS location of the smartphone <NUM> can be used to confirm the smartphone <NUM> is actually located near the wireless beacon, and is not instead providing a UUID that came from a source other than the wireless beacon. Therefore, the GPS location of the smartphone <NUM> can add an additional layer of security to the videoconferencing systems <NUM>, <NUM> or <NUM>.

Many control applications exist for videoconferencing components from different manufacturers, but these control applications are often fragmented and not part of a complete system. In those cases, the user must operate multiple different applications to control different videoconferencing components in the videoconferencing system. In an environment having multiple conferencing systems, a user typically must instruct an application to control a specific one of multiple systems. This can lead to problems where the user may accidentally control a system that the user does not intend to control.

As shown in <FIG>, the smartphone <NUM> may include a control application such as a smartphone app, which presents a user interface (PUI) <NUM> to the user <NUM>. The user interface <NUM> can allow the user <NUM> to transmit one or more commands to the system controllers 108A or 108B via the server <NUM>, in order to control the videoconferencing codecs 106A or 106B. In some embodiments, the user <NUM> may only be able to transmit commands to a system controller that has been identified within a defined proximity of the smartphone <NUM>.

For example, the user interface <NUM> includes multiple control buttons <NUM> each corresponding to a different command for the system controllers 108A or 108B, the videoconferencing codecs 106A or 106B, etc. The user interface <NUM> may be consistent across different types of system controllers, videoconferencing codecs, etc., to the user <NUM> does not need to learn different control interfaces for different controllers or components. One example smartphone app is ROOMREADY CONNECT distributed by Zdi, Inc. of Normal, IL.

In some embodiments, the system controller and the smartphone app may not need to be on the same production network (e.g., inside of a business firewall, etc.) to pass commands from the smartphone app to the system controller via a server. Therefore, there may be no need for a custom user interface for every videoconferencing system, or custom source code written for every videoconferencing system based on different application programming interfaces (APIs) and videoconferencing components for different videoconferencing rooms (e.g., no need for a different dedicated room interface for each different videoconferencing room, etc.).

The user interface <NUM> may allow the user to control one of multiple videoconferencing rooms <NUM> determined to be within a defined proximity of the smartphone <NUM>, as shown in <FIG>. The user interface <NUM> may display a signal strength <NUM> corresponding to each videoconferencing room <NUM>.

As shown in <FIG>, the user interface <NUM> may display a name of the identified videoconferencing room <NUM>, an occupancy status of the videoconferencing rooms <NUM> (e.g., occupied, vacant, etc.), available technologies in the videoconferencing rooms <NUM> (e.g., video enabled, audio enabled, presentation enabled, etc.), a number of seats available in the videoconferencing room <NUM>, the signal strength <NUM>, etc..

Optionally, the system controller 108A or 108B can store a local room calendar that includes a reservation schedule for the videoconferencing room 104A or 104B in which the system controller 108A or 108B is located. The system controller 108A or 108B may authenticate to a resource calendar (e.g., an OFFICE <NUM> calendar, a GOOGLE calendar, etc.). The authentication credentials can be stored locally with the system controller 108A or 108B.

The system controller 108A or 108B may synchronize its local room calendar with the resource calendar at periodic intervals (e.g., every three minutes, etc.), in response to a schedule update event (e.g., a new room reservation request), etc., to maintain substantially real-time updates. The resource calendar may be considered as a "source-of-truth" (SOT).

The smartphone <NUM> can poll available system controllers system controller 108A or 108B (e.g., though a secure and encrypted channel) for local conferencing room information. In some embodiments, the local room information may only be available while the smartphone <NUM> is within a defined proximity (e.g., about fifty feet, etc.) of the videoconferencing room.

If the videoconferencing room is available without any current calendar events scheduled, the smartphone <NUM> can prompt a user to reserve the room for a desired duration <NUM>, as shown in <FIG>. For example, the user may be able to reserve the room in increments (e.g., fifteen minute increments, etc.) up to a threshold (e.g., up to an hour, etc.).

Once a reservation request is transmitted from the smartphone <NUM> to the system controller 108A or 108B, the system controller 108A or 108B can update the resource calendar with a new reservation. The new reservation may round the desired increment up to the next closet interval. For example, if a conferencing room is booked for a fifteen minute meeting at <NUM>:<NUM>, the calendar may be updated to include a reservation from <NUM>:<NUM> to <NUM>:<NUM>.

In some embodiments, an optional visual indicator may be associated with (e.g., in connection with, attached to, mounted on, etc.) the system controller 108A or 108B. For example, the visual indicator may include a multi-color light emitting diode (LED). The indicator can illuminate a discrete color that is reported back to the smartphone <NUM> to provide wayfinding to the correct system controller 108A or 108B and associated videoconferencing room 104A or 104B, to confirm the intended videoconferencing room was correctly reserved, etc. The visual indicator may stay on for a specified time period (e.g., one minute, etc.) before turning off.

Once the smartphone <NUM> completes a reservation of a videoconferencing room associated with the system controller 108A or 108B, the conferencing room controls can be presented to the user in the form of a personal user interface on a smartphone app of the smartphone <NUM>. Optionally, the smartphone may automatically connect to the server <NUM> to begin controlling the system controller 108A or 108B once the reservation is completed. In other embodiments, the smartphone <NUM> may wait for activation of a button on a user interface, etc. before connecting to the server <NUM> to begin controlling the system controller 108A or 108B, etc..

The controls may include any suitable room functions such as, initiating a video and/or audio conferencing call, ending a call, sharing a presentation, muting and/or unmuting a microphone, controlling volume, reporting a problem, accessing contacts, accessing a calendar, locking a room, etc. For example, the videoconferencing system can also include a conferencing component coupled to the conferencing system controller. The system controller can control the videoconferencing component according to the one or more commands transmitted by the smartphone. As one example, a conferencing system controller (e.g., a ROOMREADY GO controller distributed by Zdi, Inc. of Normal, IL) may issue application programming interface (API) commands to a videoconference component, such as a television, a monitor, an integrated computer display, a camera, an audio digital signal processor (DSP), a speaker, an audio-visual (AV) switch, and a cable box, etc. As described above, example commands may include turning the conferencing system on, adjusting a volume of the conferencing system up and down, initiating an audio and/or video conference call, ending a call, presenting content, sharing a presentation, reporting a problem, accessing contacts, accessing a calendar, locking a room, etc..

As described above, the personal user interface can provide a consistent user interface across multiple conferencing systems, such that a user may download the consistent user interface to multiple mobile computing devices, multiple conferencing system controllers, etc. This may allow for consistent updates of application programming interfaces for compatible conferencing systems.

The videoconferencing codecs 106A and 106B may include a room-based videoconferencing codec, a mobile cart-based videoconferencing codec, a mobile phone-based videoconferencing codec, a mobile tablet-based videoconferencing codec, etc. The videoconferencing codec includes a coder/decoder for audio and for video, and may be used for a conference call including both audio and video, for a call involving only audio if desired, etc..

In some embodiments, the smartphone <NUM> may be configured to parse information (e.g., calendar events, emails, etc.) stored on the mobile smartphone <NUM> according to a parsing protocol to obtain information regarding a scheduled conference call, and to transmit at least a portion of the information regarding the scheduled conference call to the server <NUM> in response to user input. The server <NUM> is configured to transmit the information regarding the scheduled conference call to the system controller 108A or 108B, and the system controller 108A or 108B is configured to initiate the scheduled conference call via the videoconferencing codec 106A or 106B.

The smartphone app may use one or more libraries to pull information (e.g., calendar event data, emails, etc.) from the smartphone <NUM>, and parse the information to obtain details regarding a scheduled conference call. For example, calendar invites, email invites, etc. from videoconferencing services typically have a standardized format that may easily be gathered and processed by the smartphone app. For example, calendar events, emails, etc., stored on the smartphone <NUM> may be parsed by the smartphone app to search for indicators of a scheduled conference call.

In some embodiments, the smartphone app may search multiple stored calendar events for one or more text and/or numeric strings indicative of the scheduled conference call. For example, a calendar event that includes a session initiation protocol (SIP) uniform resource identifier (URI), a videoconferencing phone number, a videoconferencing meeting number, a personal identification (PIN) number, a passcode, etc., may be indicative of a scheduled conference call.

The smartphone app may search multiple stored calendar events, emails, etc. to identify text and/or numeric strings including a SIP URI, videoconferencing phone number, meeting number, PIN number, passcode, etc., to identify an upcoming scheduled conference call. In some cases, videoconferencing providers may use a standard textual format for invites to conference calls, and the smartphone app may search the multiple calendar events to identify formatted text that corresponds to a specific videoconferencing provider invite, which indicates an upcoming scheduled conference call.

The smartphone app may parse calendar events within a defined time period to search for scheduled conference calls. For example, the smartphone app could search calendar events within an hour from a current time, within a day, within a week, etc..

The control application can then pass the gathered information through a secure sockets layer (SSL) connection over the Internet, using any suitable Internet communication interface (e.g., WiFi, cellular, etc.). The gathered information may be transmitted to a gateway server based in a cloud (e.g., an AMAZON Web Services (AWS) cloud, etc.). The server acts as a proxy to direct the application content to the correct conferencing system controller, which contains the appropriate APIs to control a connected codec (e.g., a video codec, an audio codec, etc.), other conferencing components, etc..

The conferencing system controller translates the information received from the application into the correct API to communicate with the codec to make a conferencing call. The information received from the application may include an SIP URI, a phone number, a meeting number, a PIN number, etc..

As described above, the system may not be proprietary to any specific code or service, such that the system can use any codec, any web based conferencing application, etc. Call control features can be performed local to the controller, such the call control features are handled inside of a customer's network instead of in a cloud. Therefore, the Internet may be used as a common network instead of a proprietary cloud.

The smartphone <NUM> may transmit the information to the server <NUM> using a secure encrypted transport layer security (TLS) channel. For example, the smartphone app may organize the information into a specified format (e.g., JavaScript Object Notation (JSON) format, etc.) for transmission to the server <NUM>.

For example, when accessing personal contacts, calendar data, etc. of a user on the smartphone, the smartphone app can transmit normalized data to the server in a standard format (e.g., in a format documented in the Cisco CE9. <NUM> API, etc.). This may provide a standard format in which the system controller can add any conferencing room or site-specific information to the dial string (e.g., prepending "<NUM>", a country code, etc.) to the normalized number. In this case, the system controller may only have access to the string that is presented, and may not have access to the entirety of the personal contacts on the smartphone.

When accessing a personal calendar on the smartphone, the mobile application may optionally use calendar invites stored locally on the smartphone and parse the data to search for indicators of a conference call from a supported provider. The smartphone app can organize the data into a format for transmission to the server to automate the conference call process with all associated conferencing components in the conferencing room.

The transmitted information may not include personal data of the smartphone <NUM>, so personal data of the smartphone <NUM> may not be stored on the server <NUM> or the system controller 108A or 108B to provide privacy to a user of the smartphone <NUM>. Similarly, local videoconferencing room data of the system controller 108A or 108B may not be stored on the smartphone <NUM>, to protect privacy of local videoconferencing room data.

Controls for the system controller can be stored in the presentation layer of the smartphone app. This presentation layer can emulate controls, APIs, etc. of a videoconferencing codec (e.g., a CISCO conferencing codec, etc.) to provide a consistent set of external facing protocols regardless of the conferencing equipment that is actually installed in the room. Example features include making and ending conferencing calls, muting and unmuting microphones, sharing content, volume control, etc..

These features include commands that can be sent from the smartphone to the server, to the system controller, and then to conferencing equipment connected with the system controller. States of these functions can be reported from the connected conferencing equipment back to the system controller though acknowledgement signals transmitted by APIs of the connected conferencing equipment, and the system controller can send the information back to the smartphone.

The smartphone may optionally be configured to report problems with the videoconferencing system through email, through CISCO SPARK, etc. A user may be presented with a text box and a camera icon that allows the user to take a picture of a current conferencing room issue with a camera of the smartphone.

If the smartphone is connected directly to an individual videoconferencing room (e.g., to the system controller in a videoconferencing room, etc.), information associated with the conferencing room can be transmitted to a recipient of a problem support request. If the smartphone is not connected directly with an individual conferencing room, a closest conferencing room may be reported without capturing individual room data.

In some embodiments, the smartphone may include a toggle switch, button, etc. in the smartphone app that allows a user to lock others from controlling a conferencing room (e.g., when conducting an important meeting, a secure meeting, etc.). This may prevent others from being able to connect to the conferencing system controller in the conferencing room, may prevent others from controlling the conferencing system controller, etc..

In some embodiments, the smartphone <NUM> may display a join button <NUM> on the user interface <NUM> according to the obtained information regarding the scheduled conference call, as shown in <FIG>. The smartphone <NUM> may then transmit at least a portion of the obtained information regarding the scheduled conference call to the server <NUM> in response to activation of the join button <NUM> by the user <NUM>.

In some embodiments, the smartphone app determines a start time of the scheduled conference call according to the obtained information, and displays, highlights, etc. the join button <NUM> on the user interface <NUM> a defined time period before the determined start time of the scheduled conference call. As shown in <FIG>, the join button <NUM> may be highlighted five minutes prior to the scheduled conference call associated with the join button <NUM>, while another join button <NUM> is not highlighted because a current time is more than five minutes prior to the scheduled conference call associated with the join button <NUM>.

For example, the smartphone app could display the join button <NUM> on the user interface <NUM> at least one minute before the scheduled conference call, at least five minutes before the scheduled conference call, at least one hour before the scheduled conference call, etc..

Alternatively, or in addition, the smartphone app may display the join button <NUM> on the user interface <NUM> a defined time period after the determined start time of the scheduled conference call. For example, the smartphone app could display the join button <NUM> on the user interface <NUM> at least one minute after the scheduled conference call, at least five minutes after the scheduled conference call, at least one hour after the scheduled conference call, etc..

The join button <NUM> may include any suitable icon, toggle, switch, field, etc., such as the highlighted green square on the user interface <NUM> in <FIG>. The join button <NUM> may be displayed on a touchscreen of the smartphone <NUM>, etc. In other embodiments, the smartphone <NUM> may not display a join button and the user may initiate the scheduled conference call by providing input other than activation of a join button.

As described above, the system <NUM> may allow for joining a conference call using a simple (e.g., one-button) connection from the smartphone <NUM>. For example, as shown in <FIG>, the user <NUM> may simply enter a videoconferencing room and the smartphone app on the smartphone <NUM>, then press the join button <NUM> on the user interface <NUM> of the smartphone <NUM> to start a scheduled conference call. Videoconferencing call control, information, etc. may be handled in the background with respect to the user <NUM>. For example, a user may not have to locate a dialer for a meeting, may not have to dial a phone number for the conferencing service (e.g., using WEBEX, GOTOMEETING, ZOOM, BLUE JEAN NETWORKS, SKYPE, CISCO, etc.), may not have to input an ID or PIN for the meeting, etc..

In order to leave a room, a "Leave Room" button <NUM> displayed on user interface <NUM> of the smartphone <NUM> may automatically disconnect the initiated conference call when the smartphone <NUM> leaves the physical proximity of the conferencing room (e.g., leaves a proximity distance threshold of a beacon associated with the system controller 108A or 108B, etc.), as shown in <FIG>. The system controller 108A or 108B may disconnect communication with the smartphone <NUM> via the server <NUM> and shut down when the conferencing room is determined to be vacant.

The conferencing system controllers, mobile computing devices, etc. described herein may be configured to perform operations using any suitable combination of hardware and software. For example, the system controller may include any suitable circuitry, logic gates, microprocessor(s), computer-executable instructions stored in memory, etc. operable to cause the system controller to perform actions described herein.

In some embodiments, a user may be able to walk into a conferencing room with a mobile computing device, and a conferencing system controller can send a schedule for the conferencing room to the mobile computing device (e.g., instead of having a touch screen outside of the room, etc.). The mobile communication device may be able to control the conferencing room though the connection with the conferencing system controller, may be able to manage reservations for the conferencing room though the connection with the conferencing system controller, etc. Current occupancy of conferencing rooms in proximity to the mobile computing device may be displayed on the mobile computing device.

The location-based control approaches described herein may provide wayfinding functionality as described above. For example, the location beacons, location-based services of the mobile computing device, etc. may be used to orient a user among multiple conference rooms, to navigate the user between multiple conference rooms, etc..

In some embodiments, location-based control approaches may allow for room booking (e.g., reservations, etc.) as described above. For example, a user may reserve a room by physically entering a room before generating the reservation, to confirm that the user is reserving the correct room.

Location-based control approaches may be used for attendance, by confirming the conference call members that are present during a conference call based on proximity detection. Emergency notification can be provided to alert all user(s) within a certain proximity of a conferencing system, etc. In some embodiments, training videos can be implemented based on location, so that users attend the correct training video, an appropriate training video for a specific conference room/system is provided to a user, etc..

According to another example embodiment, a videoconferencing system includes multiple videoconferencing rooms, and a server adapted to store information regarding each videoconferencing room. Each videoconferencing room includes a videoconferencing codec and a system controller in communication with the videoconferencing codec via one or more wired and/or wireless communication networks to control the videoconferencing codec, the system controller in communication with the server via the one or more wired and/or wireless communication networks. The system also includes a mobile computing device including a user interface. The mobile computing device configured to communicate with the server via the one or more wired and/or wireless communication networks to exchange data with the server to determine whether at least one of the videoconferencing rooms is within a defined proximity of the mobile computing device. The mobile computing device is further configured to obtain information regarding a scheduled conference call from calendar information stored on the mobile computing device.

According to yet another example embodiment, a mobile computing device is configured to exchange data with a server to determine whether at least one of multiple videoconferencing rooms is within a defined proximity of the mobile computing device, and in response to determining that at least one of the videoconferencing rooms is within the defined proximity, and in response to the user selecting said at least one of the videoconferencing rooms, transmit one or more commands to a server to transmit the one or more commands to a system controller located in said at least one of the videoconferencing rooms.

According to a further example embodiment, a method of controlling a conference call includes determining whether at least one of multiple videoconferencing rooms is within a defined proximity of a mobile computing device, and in response to determining that at least one of the videoconferencing rooms is within the defined proximity, and in response to the user selecting said at least one of the videoconferencing rooms, transmitting one or more commands to a server to transmit the one or more commands to a system controller located in said at least one of the videoconferencing rooms.

According to another example embodiment, a system controller is configured to receive one or more commands from a server, the one or more commands transmitted to the server by a mobile computing device in response to determining whether a videoconferencing room in which the system controller is located is within a defined proximity of a mobile computing device.

Claim 1:
A videoconferencing system comprising:
multiple videoconferencing rooms (104A, 104B, <NUM>);
a server (<NUM>) adapted to store information regarding each videoconferencing room, each videoconferencing room including a videoconferencing codec (106A, 106B) and a system controller (108A, 108B) in communication with the videoconferencing codec via one or more wired and/or wireless communication networks (<NUM>) to control the videoconferencing codec, the system controller in communication with the server via the one or more wired and/or wireless communication networks; and
a mobile computing device (<NUM>) including a user interface (<NUM>), the mobile computing device configured to communicate with the server via the one or more wired and/or wireless communication networks to exchange data with the server to determine whether at least one of the videoconferencing rooms is within a defined proximity of the mobile computing device;
the mobile computing device further configured to, in response to determining that at least one of the videoconferencing rooms is within the defined proximity, and in response to the user selecting said at least one of the videoconferencing rooms, transmit one or more commands to the server;
the server configured to transmit the one or more commands to the system controller located in said at least one of the videoconferencing rooms;
said system controller configured to control the videoconferencing codec located in said at least one of the videoconferencing rooms according to the one or more commands to establish or control a videoconference in said at least one of the videoconferencing rooms.