Field of the Invention

The present invention relates to providing means to access video teleconference calls (VTCs) using non-standard teleconference devices. In particular, it may relate to use of devices which typically do not allow input of typed text to access VTCs. Such devices may not have any form of keyboard or they may have a type of keyboard on which selection is made by voice command or a scrolling interface or a small number of buttons. None of these input mechanisms allow typing (in which input may be rapid for example using all or most of the fingers on both hands).

Background of the Invention

Modern video calls, meetings or video teleconferences (any of which may be referred to as a VTC) are typically hosted on virtualized and distributed multipoint computing environments comprising securely interconnected conferencing nodes and a management node. Both types of nodes are software applications that may be deployed as Virtual Machines (VMs) on host servers distributed globally or on cloud servers. VTCs involving two users or involving many users may be regarded as taking place in virtual meeting rooms (VMRs), each VMR with its own meeting identification information (for example, a meeting alias) and each VMR hosted on conferencing nodes.

One emergent barrier to accessing VTCs is the stringent hardware requirement. Conventional means of joining a VTC require manual user input by navigating and clicking on a VTC access link or by manual string input of the VTC address and any further necessary access information. The devices that simply enable such user input are therefore limited to devices equipped with means for the user to manually enter the necessary inputs, such as desktop computers, laptops, tablets, and smartphones. Joining VTCs with non-standard devices that do not have keyboards (whether on touch screen interfaces or with physical keys) or mice for example is a difficult, non-instantaneous process as there are many processes that the user must go through to join.

Existing systems and methods that use such non-standard devices require users to either authenticate the non-standard device online prior to accessing the VTC or for the user to be signed into a specific VTC application on the non-standard device permanently (or at least until the user goes through the potentially arduous task of manually signing out of the VTC application on the non-standard device). In the former case, the process of authentication inevitably impedes VTC access and, in the latter case, this effectively means that the user is siloed into the VTC application.

The global video teleconferencing market has been estimated at 5.32 billion USD in 2019 and forecasts project this to reach 10.92 billion USD by 2027. With the impact of the Covid-19 pandemic having increased corporate reliance on VTC solutions, many organizations and their employees may well only be getting used to joining video calls on laptops; the difficulty of quickly and reliably accessing VTCs using other non-standard devices may not yet be fully realized.

Considering a non-standard device equipped to accept voice input (and without means for typed text input), there is a problem with dial out in existing conventional methods for accessing VTCs - for example it takes a user a long time to spell out the VTC identification or the callee’s name when trying to use voice as an input mechanism.

A further problem here is that these non-standard devices are commonly shared (for example, amongst employees of a single company) so there are significant security issues. Password entry is also extremely difficult and, on some devices, impossible. When accessing a VTC requiring password entry using one’s voice, the user is effectively reading the password out loud, which is inevitably a security risk.

The inventors have realised that it would be advantageous to overcome the challenges of accessing VTCs using non-standard devices. Thus, they have come to the realisation that it is desirable to provide a VTC access method that enables devices that may not have standard user interfaces or standard user input mechanisms to join video meetings quickly and efficiently.

Summary of the Invention

The invention is defined in the independent claims, to which reference should now be made. Further features are set out in the dependent claims.

According to an aspect of the invention, there is provided a computer-implemented method for accessing a video teleconference, VTC, using a teleconference device (also referred to as a non-standard device) and a companion device. The method comprises accepting input of meeting identification information into a GUI of the companion device and retrieving, by the companion device, an access status over a (first) communication network. When access status is positive, the GUI of the companion device displays a scannable code corresponding to the meeting identification information. This allows scanning of the scannable code using a camera of the teleconference device. Once the code has been scanned, it is decoded by the teleconference device to retrieve the meeting identification information. The teleconference device then accesses the VTC with the teleconference device over a (first or second) communication network using the decoded meeting identification information.

Embodiments provide a method for accessing VTCs using a companion device and a teleconference device. Embodiments enable users to directly connect to VTCs with the teleconference device by scanning a scannable code without prior authentication of the user on the teleconference device and without requiring user account sign-in, thereby making the user experience significantly more streamlined. In this way, users who are required to share teleconference devices with other users (where the teleconference device may be employer- owned, for example) are not hindered when attempting to access VTCs: they may simply connect directly into a VTC. For example, teleconference robots and wearables are typically shared between employees of a firm and embodiments of the invention allow an employee to join a VTC on these devices without necessarily needing to register the device (or sign in to the device) in their name.

Also, in some cases, since the user cannot type into the teleconference device, for example because it may have no normal or pop-up keyboard, it is cumbersome to try to enter the information to join a VTC. In this case, the companion device also allows the teleconference device to access the VTC without undue burden on the user. The two devices may be used in combination by the same user. VTCs may be established or set-up by other users prior to the user of the teleconference device beginning. Methods then transcode the VTC meeting addresses (where the VTC is encoded in any suitable way with any of, for example the video codecs VP8, VP9, WebRTC, SIP, H.323) into scannable codes to enable non-standard devices to join VTC calls and meetings. This can be done at an integrated layer (by, for example, making the scannable code appear in an application or system or webpage). Alternatively, methods, when built into a mobile application on a companion device, allow users to generate scannable codes on an ad hoc basis.

Embodiments provide for a graphical user interface (GUI) that enables the user to enter identifying details (meeting identification information) of the VTC into the companion device, which may include entry of a meeting alias (also known, for example, as a meeting room or meeting room ID) and optionally also a meeting PIN (also known, for example, as a meeting passcode or meeting password). Optionally, all or part of the meeting identification information may be encrypted prior to or during transmission, so as to ensure security of the transmission.

Embodiments, performed by the companion device, retrieve an access status over a communication network. The access status may be an indicator as to whether the input meeting identification information does in fact correspond to an existing VTC. In some arrangements, the access status could be a simple binary bit or short string, which confirms the correspondence of the input meeting identification with expected meeting identification information. For example, a binary bit access status may indicate positively or negatively that the input meeting identification information matches meeting identification information server on a server (in the communication network). In this way, transmissions costs (in terms of data quantity and processing times) may be kept to a minimum. In other arrangements, the access status could itself be a scannable code incorporating the input meeting identification information and, optionally, any additional information for meeting access appended by the sending server. In this way, processing control is handed to the server that sends the access status, minimizing processing costs at the companion device.

Embodiments, performed by the companion device, present to the user of the companion device a scannable code, which provides access to a VTC. The scannable code may be rendered locally (on the companion device) using the same meeting identification information as input by the user and/or any further information derived from the server that confirms the existence of the VTC (for instance, further information may include a pointer to a command to be performed by the host of the VTC, so as to permit the user access before the user is able to fully join the VTC).

Embodiments, performed by the teleconference device, scan the scannable code using a camera peripheral as provided on or in the teleconference device. For example, a teleconference device in the form of a wearable head-mounted display device, may include input means (for example (a) button(s) or a microphone) that accepts commands to initiate the camera. Optionally, the camera may be accessible using a GUI on the teleconference device, which enables initiation of the camera peripheral and enables the user to monitor the captured image. In this way, the user may initiate the camera peripheral and access the VTC only when they desire.

Methods according to embodiments enable cloud video interoperability. For instance, third- party VMRs and VTCs from personal video devices are able to join meetings hosted on proprietary communication platforms (for example, Microsoft Teams or Google Hangouts). With such proprietary communication platforms, the user is offered rich online content collaboration in VTCs that include audio, video, and content sharing. This content can be enjoyed by the user through desktop and web clients provided from the proprietary communication platform providers, as well as through many partner devices that integrate natively with the proprietary platforms. However, many users may have already invested in VTC devices, which may be expensive to upgrade. Cloud video interoperability provides a solution, allowing the user to keep using their existing devices until they are ready to upgrade.

Interoperability may be enabled by use of third-party software for connection, such as Pexip Infinity. This type of software may be used for the access part of the method.

For instance, embodiments may enable interoperability with Microsoft Teams using Microsoft’s Cloud Video Interop (CVI) third-party solution. CVI is a Microsoft Qualified third-party solution that enables third-party meeting rooms (telepresence) and personal video devices (VTCs) (for example, those using SIP/H.323 systems) to join Microsoft Teams meetings as if they were native Microsoft Teams clients. Wth existing methods, CVI deployments do not expose scannable codes join for teleconference devices (for example, wearable devices) - existing methods just present a meeting alias (or ID) for the user to type into a system.

For instance, embodiments may enable interoperability with Google Meet using Google Interoperability, which is a qualified third-party solution that enables third-party meeting rooms (telepresence) and personal video devices (VTCs) (for example, those using SIP/H.323 systems) to join Google Meet meetings as if they were native Google Meet clients. Wth existing methods, Google Interoperation deployments do not expose scannable code join for teleconference device (for example, wearable devices) - existing methods just presents a meeting alias (or ID) for the user to type into a system.

Methods according to embodiments enable non-standard teleconference devices to join proprietary communication platforms as if they were a native client or user. Methods enable VTC systems to join proprietary communication platform meetings and additionally allow authenticated VTC systems to join as trusted participants without additional user interaction (i.e. lobby bypass). This applies to: any devices configured to support the methods herein; H.323 and SIP room-based VTC systems, including those offered by Cisco, Polycom, LifeSize, etc.; and any mainstream web browser that supports WebRTC.

Optionally, the retrieving of the access status, which is performed by the companion device comprises: transmission of the user input meeting identification information, which is input into the GUI of the companion device, to a remote server; and reception of the access status from the remove server, the access status indicating whether the meeting identification information corresponds to that of an existing VTC. Only when the access status is positive (indicating that the input meeting identification information does correspond to or match (at least in part) expected or stored meeting identification information) does the companion device render (or is provided with a rendered) scannable code. In this way, the user is immediately made aware of incorrect input details; the GUI of the companion device may present this as an error message to the user.

Optionally, the access status may further indicate if the necessary permissions have been granted to the companion device and possibly also the teleconference device (or users of the devices, for example the user currently logged into the companion device). For instance, a system administrator may be provided with means to grant licenses to users or devices, without which the use of scannable access codes may be prohibited. A “positive” access status in this scenario may therefore further require (as well at the input meeting identification information being correct) that the user or device holds an active licence.

Optionally, accepting input of meeting identification information may be, in part, an implicit activity. Where a companion device is a device running a web browser, for example, the user may enter at the meeting alias as part of a URL string. Where a meeting PIN is also required, the web browser GUI may include an input field such that the user may manually enter the PIN prior to transmission of the meeting identification information (comprising both meeting alias and meeting PIN) to a server. The omission of a meeting PIN from the URL ensures security of the VTC is preserved.

Optionally, accessing the VTC with the teleconference device involves transmission of the meeting identification information decoded from the scannable code to a server. The teleconference device then receives a second (further) access status. The transmission and reception by the teleconference device may be over the same network as used in the retrieving of the (first) access status or alternatively may be a separate network. The second access status, produced by the server, indicates if the decoded meeting identification information derived from the scannable code corresponds or matches (at least in part) expected or stored meeting identification information. Only when the decoded meeting identification information does correspond to that of an existing VTC does the teleconference device begin preparation of an access string, which contains the meeting identification information (and other required, VTC codec-dependent information) to enable access of the teleconference device directly into the VTC. Optionally, all or part of the decoded meeting identification information may be encrypted prior to or during transmission, so as to (further) ensure security of the transmission. As for the first access status, the second access status may further indicate if the necessary permissions have been granted to the companion device and/or the teleconference device. Preferably, the permission in the second access status relate to the teleconference device.

All these accessing steps may be carried out under licence with software provided to allow cloud video interoperability, as mentioned above.

Embodiments of another aspect of the invention include a system for accessing a VTC comprising a teleconference device and a companion device, wherein the teleconference device comprises processor hardware and memory hardware and the companion device comprises processor hardware and memory hardware. The (first) memory hardware of the companion device stores processing instructions, which when executed by the (first) processor hardware of the companion device, cause the (first) processor hardware to execute the method steps of the companion device as set out above. The (second) memory hardware of the teleconference device stores processing instructions, which when executed by the (second) processor hardware of the teleconference device, cause the (second) processor hardware to execute the method steps of the teleconference device as set out above.

Embodiments of another aspect of the invention include a teleconference device, which comprises processor hardware and memory hardware, the memory hardware storing processing instructions which, when executed by the processor hardware, cause the processor hardware to execute the method steps of the teleconference device as set out above.

The teleconference device may further comprise imaging hardware for scanning scannable meeting access codes and for capturing visual VTC media, and a display unit through which visual VTC media is displayed. Additionally, the teleconference device may comprise an audio output unit through which aural VTC media is output.

Embodiments of another aspect of the invention include a companion device, which comprises processor hardware and memory hardware, the memory hardware storing processing instructions which, when executed by the processor hardware, cause the processor hardware to execute the method steps of the companion device as set out above.

The companion device may further comprise a display unit through which a GUI is displayed and through which a scannable meeting access code is displayed. Embodiments of another aspect include a computer program which, when executed by a teleconference device, causes the teleconference device to execute a method of an embodiment. The computer program may be stored on a computer-readable medium. The computer-readable medium may be non-transitory.

Embodiments of another aspect include a computer program which, when executed by a companion device, causes the companion device to execute a method of an embodiment. The computer program may be stored on a computer-readable medium. The computer-readable medium may be non-transitory.

The invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. The invention may be implemented as a computer program or a computer program product, i.e. a computer program tangibly embodied in a non-transitory information carrier, e.g. in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, one or more hardware modules. A computer program may be in the form of a stand-alone program, a computer program portion, or more than one computer program, and may be written in any form of programming language, including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a data processing environment.

The invention is described in terms of particular embodiments. Other embodiments are within the scope of the following claims. For example, the steps of the invention may be performed in a different order and still achieve desirable results.

Brief Description of the Drawings

Reference is made, by way of example only, to the accompanying drawings in which:

Figure 1a is a flow chart of accessing a VTC according to an existing method;

Figure 1b is a flow chart of accessing a VTC according to another existing method;

Figure 2 is a flow chart of a method for accessing a VTC using a companion device according to an embodiment;

Figure 3 is a flow chart of a method for accessing a VTC using a teleconference device according to an embodiment;

Figure 4 is a block diagram of a computer device (cloud services) for use with embodiments; Figure 5 is a block diagram of a computer apparatus (companion device) according to embodiments; Figure 6 is a block diagram of a computer apparatus (non-standard device) according to embodiments;

Figure 7 is a schematic overview of a communication system according to embodiments; Figure 8 is a flow chart of the operation of a companion device and cloud services according to an embodiment;

Figure 9 is an example GUI dashboard on a companion device for user input;

Figure 10a is an example GUI dashboard on a companion device for scanning;

Figure 10b is another example GUI dashboard on a companion device for scanning;

Figure 11 is a flow chart of the operation of a non-standard device and cloud services according to an embodiment;

Figure 12 is an example of server hardware resource allocation for use with embodiments; Figure 13 is an example block diagram of the structure of the primary components of cloud services for VTCs.

Figure 14a is an example GUI dashboard on a non-standard device for starting/joining a VTC; Figure 14b is another example GUI dashboard on a non-standard device for starting/joining a VTC; and

Figure 14c is an example GUI for operation of a camera on a non-standard device.

Detailed Description

State of the Art

The term “non-standard device” in the context of this application may refer to computing devices equipped with at least a camera and a means to connect to a network (for example, the Internet) that may be used to take part in VTCs. Optionally, these non-standard devices further include display interfaces (to enable the user to view any other callees within the VTC), means of audio output (to enable the user to hear the audio content of the VTC), and means of audio input (to enable the user to contribute audio to the VTC). Suitable non-standard devices must also be capable of running software, for example in the form of applications. These non-standard devices do not typically however, allow the user to enter typed text.

Suitable non-standard devices may collectively be described as Extended Reality (XR) devices and include Augmented Reality (AR) devices, Immersive or Virtual Reality (VR) devices, Mixed Reality (MR) devices, Assisted Reality devices, etc. Suitable non-standard devices may not accept typed-text input. Many XR devices are examples of wearable technologies and are, for example, smart glasses or other head-mounted wearable displays. Commercial examples of suitable XR devices for methods of the present application include Realwear’s HMT-1 and HMT-1Z1 , Vuzix’s M-Series Smart Glasses and Blade® Upgraded Smart Glasses, Rokid’s X- Craft and Glass, Microsoft’s HoloLens, etc. Methods may also be suitable for telepresence robots that include camera and network functionalities, such as Double Robotics’ Double 2 and Double 3, and OhmniLabs’ Ohmni® Robot. Such telepresence robots provide users with a physical presence in an otherwise remote location (that is, the operator of the telepresence robot is located remotely). Methods may also be suitable for unmanned vehicles that include camera and network functionalities, including aerial drones, such as DJI’s Phantom, and underwater drones, such as Blueye’s Pioneer, etc.

Figure 1 demonstrates existing methods of connecting a non-standard device to a VTC, which require the user to authenticate directly onto the non-standard device before the user is allowed to join the VTC. The user may achieve this by either authenticating on a webpage and scanning a QR code with the non-standard device (webpage authentication) or by speaking their credentials into the non-standard device via voice command (direct authentication). Only once the authentication process is done may the user join the VTC.

For example, as demonstrated in Figure 1a, with existing webpage authentication methods (as offered in such commercial services as WebEx and Zoom), the user must first log in to their user profile of VTC software (service) on a separate device (such as a laptop), which may then be operated to generate a one-time quick response (QR) code. The user then scans the QR code using the camera functionality of the non-standard device to authenticate themselves on to the non-standard device. The user may then be called directly by other users who are using the same service, or they can dial out to other users directly, but must navigate the user interface of the non-standard device using voice controls.

As demonstrated in Figure 1b, with existing direct authentication methods (as offered by such commercial services as Microsoft Teams), the user is required to enter their username and password directly into the non-standard device using voice controls. The user may then be called directly by other users who are using the same service, or they can dial out to other users directly, but must navigate the user interface of the non-standard device using voice controls.

Existing methods enable the user to log in to their existing user accounts with a QR code. Embodiments of the present invention, conversely, enable the user to directly connect to VTCs by scanning a QR without prior authentication and without requiring user account sign-in, thereby making the user experience significantly more streamlined. Methods

Figure 2 is a flow chart depicting a computer-implemented method of accessing a VTC using a companion device according to aspects of embodiments of the present invention.

At step S20, the companion device accepts input of meeting identification information into a GUI of the companion device. For example, the user of the companion device may input the meeting alias (also known as the meeting ID or meeting room name) and the meeting PIN required for access to the VTC meeting.

At step S22, the companion device retrieves an access status over a first communication network. The access status is an indicator to the companion device if, for example, the VTC exists or if the requesting user has permission to access the VTC or has entered the correct meeting identification information for VTC.

At step S24, when the access status is positive, the companion device displays a scannable meeting access code on the GUI of the companion device.

Figure 3 is a flow chart depicting a computer-implemented method of accessing a VTC using a teleconference device according to aspects of embodiments of the present invention.

At step S30, the teleconference device scans the scannable meeting access code using a camera of the teleconference device. The camera may, optionally, be accessible using a GUI operable on the teleconference device. In this way, the user of the teleconference device may initiate operation of the camera and capture the scannable access code when desired.

At step S32, the teleconference device decodes the scanned meeting access code to retrieve the meeting identification information.

At step S34, the teleconference device accesses the VTC over a second communication network using the decoded meeting identification information. The second communication network may be the same communication network as that discussed above in respect of the method for accessing a VTC using a companion device (S22). For example, both devices may be connected to the Internet via the same Wi-Fi network. Alternatively, the two networks may be different networks: for example, the first communication network may be an LTE network and the second communication network may be a Wi-Fi network.

Cloud services Figure 4 is a block diagram of a computing device 400, which may be used to implement aspects of the methods for accessing VTCs, as described herein. Specifically, the hardware shown may be a cloud apparatus (cloud services). The computing device 400 comprises a processor 402, and memory 404. Optionally, the computing device 400 also includes a network interface 410 for communication with other computing devices, for example with computing apparatus 500 (companion device) and computing apparatus 600 (non-standard device), described below.

For example, an embodiment may be composed of a network of such computing devices. Optionally, the computing device 400 also includes one or more input mechanisms such as keyboard and mouse 408, and a display unit such as one or more monitors 406. The components are connectable to one another via a bus 412. In preferred embodiments, computing device 400 is a server, which may be accessed by the user remotely (for cloud based computing).

The memory 404 may include a computer readable medium, a term which may refer to a single medium or multiple media (e.g., a centralised or distributed database and/or associated caches and servers) configured to carry computer-executable instructions or have data structures stored thereon. Computer-executable instructions may include, for example, instructions and data accessible by and causing a general-purpose computer, special purpose computer, or special purpose processing device (e.g., one or more processors) to perform one or more functions or operations. Thus, the term “computer-readable storage medium” may also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methods of the present disclosure. The term “computer-readable storage medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical media and magnetic media. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media, including Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Compact Disc Read-Only Memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state memory devices).

The processor 402 is configured to control the computing device 400 and to execute processing operations, for example executing code stored in the memory 404 to implement the various different functions of accessing a VTC, as described here and in the claims. The memory 404 may store data being read and written by the processor 402, for example data from applications executing on the processor 402, used to provide companion devices 500 with VTC access status on request. As referred to herein, a processor 402 may include one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. The processor may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor 402 may also include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. In one or more embodiments, a processor 402 is configured to execute instructions for performing the operations and steps discussed herein.

The network interface (network l/F) 410 may be connected to a network, such as the Internet, and is connectable to other computing devices via the network. The network l/F 410 may control data input/output from/to other apparatus via the network.

Methods embodying aspects of the present invention may be carried out on a computing device 400 such as that illustrated in Figure 4. Such a computing device 400 need not have every component illustrated in Figure 4 and may be composed of a subset of those components. A method embodying aspects of the present invention may be carried out by a single computing device in communication with one or more data storage servers via a network or by a plurality of computing devices operating in cooperation with one another. Cloud services implementing computing devices may be deployed, for example, using Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP) cloud platforms, as well as in any hybrid combination.

Companion device 500 and non-standard device 600

Figure 5 depicts a data processing computer apparatus 500 (companion device) according to an aspect of embodiments, arranged to allow a user to input meeting identification information and to provide, to the user, a generated scannable meeting access code. The companion device 500 includes a network interface 502, a processor 504, a storage unit 506, means of user input 508, and a display unit 510.

The processor 504 may be configured to run a GUI, stored on storage 506, with user input means 508 and display unit 510. The input means 508 may include a touchscreen also acting as the display 510 and/or a keyboard/mouse and/or other local or remote means. In one arrangement, the processor 504 may be configured to process user-entered meeting identification information, which may be temporarily stored locally on storage 506, and control the network interface 502 to communicate with (transmit data to and receive data from) cloud services (for example, with computing device 400).

In an alternative arrangement, the processor 504 may be configured to process references to other resources that include meeting identification information, which may be retrieved using the network interface 502. For example, the user may access a URL provided on the companion device 500 (in the contents of an email invitation to join a VTC, for example), which directs the user to a web resource including the meeting identification.

The GUI may present a dashboard including user input means 508 to the user via display unit 510 and also, for example, display a scannable meeting access code to the user. Various configurations of such a dashboard are provided by embodiments and are discussed further below.

Figure 6 depicts a data processing computer apparatus 600 (non-standard device) according to an aspect of embodiments, arranged to allow a user to input a scannable meeting access code and access a VTC. The non-standard device 600 includes a network interface 602, a processor 604, a storage unit 606, means of user input 608, and a display unit 610.

The processor 604 may be configured to run a GUI, stored on storage 606, with user input means 608 and display unit 610. The input means 608 may include, for example, a microphone. The input means 608 additionally includes a camera peripheral 6080, arranged to capture images.

In one arrangement, the processor 604 may be configured to process user-entered commands (for example, voice commands) to operate the camera peripheral 6080 and scan a meeting access code provided external to the non-standard device 600. For example, the scannable access code may be provided on companion device 600. The processor 604 controls the network interface 602 to communicate with (transmit data to and receive data from) cloud services (for example, with computing device 400) to join the VTC for which access information was included within the scannable access code.

The GUI may present a dashboard to the user via display unit 610 to enable the user to selectively operate the camera peripheral 6080. In arrangements, the user may be presented with a live feed of the image data acquired by the camera peripheral 6080, to enable the user to position themselves and/or the non-standard device 600 appropriately prior to accessing the VTC. Various configurations of such a dashboard are provided by embodiments and are discussed further below.

Figure 7 depicts communication system 700, which, at a high level, demonstrates the interoperability between computing device 400 (cloud services), first computer apparatus 500 (companion device), and second computer apparatus 600 (non-standard device). Various embodiments of companion device 500, including laptop 500-1 and smartphone 500-2, may communicate with computing device 400 to send meeting identification information and receive a scannable meeting access code. Various embodiments of non-standard device 600, including head-mounted display unit 600-1, telepresence robot 600-2, and aerial drone 600-3, may scan scannable meeting access code, presented on companion device 500. Using the scannable meeting access code, the non-standard device 600 may then join the VTC meeting via cloud services 400. VTCs may occur in VMRs, which are hosted on conferencing nodes (not illustrated), which may be cloud-based or on a local server.

VTC QR code generation

Figure 8 is a schematic diagram of the operation of the companion device 500 in methods according to an embodiment. In this example, the user, on receiving an invitation to join a VTC meeting or on being supplied with meeting identification information (for example, on the companion device), navigates to the appropriate screen of the companion device and enters the meeting identification information - the meeting alias (meeting ID) and, if the meeting has been configured to have a meeting PIN, the meeting PIN. The user then uses the companion device to request the generation of a scannable meeting access code, for example a 2D QR code. This request may not be an explicit request on behalf of the user, but rather, could also be an implicit request by accessing a URL.

The companion device 500 transmits the request to cloud services 400, which thereby acquires the meeting alias and, if the meeting has been configured to have a meeting PIN, the meeting PIN. The cloud services 400 encrypt the meeting PIN so as to ensure security of the private meeting identification information. The encryption may use, for example, 256-bit AES encryption, but of course any other suitable means of encryption is possible.

A cloud-based API node acts as an intermediary between the companion device 500 and an HTTPS server (cloud-based). All communications between the device sending the meeting PIN and the HTTPS server may be encrypted by HTTPS as standard. Request information may be parsed from the device input and then encrypted before transport to the server. Any device attempts to connect to services may be required to use HTTPS.

In an example, the HTTPS server may contain a database holding the up-to-date meeting PIN for every associated or existing meeting alias. The meeting PIN may be encrypted at rest. The HTTPS server may then perform a lookup to check the meeting PIN provided against the meeting PIN that is stored together with the meeting alias that it is intended to be used with. If the user-input meeting PIN and meeting alias match the stored meeting PIN and meeting alias, the HTTPS server may allow connection.

Additionally, the HTTPS server may perform a check to establish if the requesting party (that is, the companion device 500) has the necessary privileges (granted by a system administrator) to generate and utilise a scannable meeting access code. For example, a check to establish if the user has any required licences may be performed. As above, this may be performed by a lookup on a database contained on the HTTPS server.

The HTTPS server confirms that the meeting alias corresponds to a meeting alias that exists in the HTTPS database. If the meeting exists, the HTTPS server may, via the network, transmit a positive access status (a confirmation) to the companion device 500. For example, the access status may be transmitted to the companion device 500 and the QR code, encoding the meeting identification information, may then be rendered locally at the companion device 500 using the user-input meeting identification information. In an alternative example, the meeting identification information may be transcoded and rendered into a QR code at the HTTPS server and the rendered QR code image (scannable meeting access code) may be communicated (as an example of access status) to the companion device 500.

The skilled reader will appreciate that the meeting identification information could be transcoded into a scannable meeting access code of any form of 1 D or 2D barcode, including into the barcode formats UPC-A and UPC-E, EAN-8 and EAN-13, Code 39, Code 93, Code 128, ITF, Codabar, RSS-14, RSS Expanded, QR Code, Data Matrix, Aztec, PDF 417, MaxiCode, etc.

Optionally, if the meeting does exist - indicating, for example, that the input meeting alias does correspond to a meeting alias that exists in the HTTPS database - but the input meeting PIN is incorrect or no meeting PIN is input, scannable access code may still be provided to the companion device 500. In this case, the scannable access code may enable the user to begin accessing a VTC but require that the host of the VTC (or another callee) give the user access. This may be implemented by omitting the meeting PIN from the scannable access code and/or transmitting an indicator (as part of the access status, for example), which causes the companion device 500 to render a scannable access code that contains a pointer to a command, prompting the host of the VTC (or other callee) to give the user access.

If the meeting does not exist - indicating, for example, that the user has entered an incorrect meeting alias as part of the input meeting identification information - no scannable meeting access code is provided to the companion device 500 and, optionally, the companion device 500 presents the user with a corresponding message such as an indication that an error has occurred.

In examples, where the companion device 500 is a mobile smartphone running an application, the QR code may be rendered using QR. Flutter - a dedicated library for use with the open- source Ul software development kit Flutter. In other examples, where the companion device 500 is a device running a browser, the QR code may be rendered using node-qrcode - an open-source Node.js package.

The scannable meeting access code is then received in an application or on a browser on the companion device 500 and presented to the user on the companion device 500 display. This scannable meeting access code gives the non-standard device 600 access straight into the VTC meeting as a participant, by instantly joining through a scan (in the same way as conventional devices might click a link to join the VTC instantly).

To summarise, the companion device 500 may be used to make a request to the HTTPS server and the database to check for meeting PIN and meeting alias details. The companion device 500 may then use these details to create a QR code. Of course, via conventional access methods, the companion device 500 may also use the same details to dial in directly to a call.

Figure 9 depicts an example GUI dashboard on a companion device 500. The dashboard provides, to the user, input fields in which the user may manually enter the meeting ID (meeting alias) and, optionally, the meeting PIN. Of course, more input fields may be provided to accommodate for other pieces of meeting identification information, such as, for example, the user’s name. The dashboard also provides to the user a button “Generate QR Code”, which - on clicking - causes the meeting identification information (ID & PIN) to be transmitted to the cloud services 400 and a scannable meeting access code (or instructions to render a scannable meeting access code) to be returned to the companion device 500. In this example, the GUI dashboard is a component of a standalone software application running on a mobile phone.

Additionally, or alternatively, there may not be a specific GUI dashboard presented to the user, but, instead, a URL may be provided to the user (in the body of an email invitation to attend the VTC, for example), which - on accessing - causes the meeting identification information (ID & PIN) to be transmitted to the cloud services 400. This may be in addition to the usual link which allows the user to join directly from the companion device.

Figure 10a depicts another example GUI dashboard displayed on a companion device 500. Following receipt of a scannable meeting access code (or instructions to render a scannable meeting access code), the companion device 500 presents the transcoded scannable meeting access code within a standalone application in the form of a QR code (rendered on the companion device 500 or rendered remotely) to the user. In this example, the GUI dashboard is a component of a standalone software application running on a mobile phone.

Figure 10b depicts another example GUI dashboard on a companion device 500. In this example, the companion device 500 presents the transcoded, scannable meeting access code to the user within a web browser window. This example GUI dashboard may be presented to the user after having accessed a URL provided to the user, as described above.

VTC access

Figure 11 is a schematic diagram of the operation of the non-standard device 600 in methods according to an embodiment. The user operates the non-standard device 600 to scan the QR code from the companion device 500. In an example, the user may instruct the non-standard device 600 to open and initiate the camera on the non-standard device 600 using a verbal command such as “join new meeting”. Where the non-standard device 600 is a wearable head- mounted display device, the user simply needs to look at the QR code such that the camera is able to capture the QR code.

The non-standard device 600 transcodes the QR code to acquire the meeting alias and meeting PIN. The non-standard device 600 transmits the meeting alias and meeting PIN to the HTTPS server on a cloud-based server, via an API, via the network. Optionally, as with the communication between the companion device 500 and the cloud services 400 (described above with reference to Figure 7), the cloud services 400 encrypt the meeting PIN so as to ensure security of the private meeting identification information. All communications between the device sending the meeting PIN and the HTTPS server may be encrypted by HTTPS as standard. Request information is parsed from the device input and then encrypted before transport to the server. Any device attempts to connect to services may be required to use HTTPS.

The HTTPS server confirms to the non-standard device 600 that the meeting alias transcoded from the QR code corresponds to a meeting alias that exists. As described above, this check may be performed by the HTTPS server using a lookup. Additionally, if a meeting PIN transcoded from the QR code corresponds to a correct meeting PIN (that corresponds to the meeting alias), the QR code may allow the non-standard device 600 to use the meeting PIN in a dial string.

Optionally, if the meeting does exist - indicating, for example, that the input meeting alias does correspond to a meeting alias that exists in the HTTPS database - but the QR code indicates that an input meeting PIN was incorrectly input or no meeting PIN was input, the VTC may initiate but require that the host of the VTC (or another callee) give the user full access (e.g. allow the user into the VMR).

If the meeting alias does not exist - and therefore, for example, the user has scanned an incorrect QR code - the VTC does not initiate and, optionally, the non-standard device 600 presents the user with an indication that an error has occurred.

Any suitable existing method of establishing/joining a VTC from the non-standard device 600 may be implemented herein. In this example, after receiving confirmation that the meeting alias corresponds to a meeting alias that exists, the non-standard device 600 then prepares a dial string including the meeting alias and the meeting PIN to send to the management node of the cloud services. Depending on the preconfigured video codec for use in the VTC, this dial string may include details of the protocol for the VTC. For example, the dial string may indicate that the VTC is to be encoded with SIP, H323, RTMP, WebRTC, etc.

The non-standard device 600 then sends a request to start/join the VTC session to the management node via a proxy server (if proxy is in use).

The proxy server (if in use) routes this request to a management node. The management node authenticates the request and confirms that the meeting alias exists and (if provided) that the meeting PIN is correct. In this example, commands transmitted from the non-standard device 600 to the cloud services 400 to initiate and manage connections are authenticated with a token. The token has a validity lifetime, before the end of which it must be refreshed. The token may be presented in a HTTP header on every HTTP request.

The non-standard device 600 requests and receives a token from the management node, initiating a connection to a transcoding node and starting a media session.

The management node encrypts and passes/routes the VTC data (audio, video, shared screen content, etc.) from the non-standard device 600 to a transcoding node via a call routing engine to manage VTC data. The transcoding node passes the VTC data to a proxy server, which provides a secure, encrypted connection to the VTC (not pictured in Figure 11). For example, the camera peripheral and a microphone of the non-standard device 600 may capture video and audio data, respectively, which is provided to other callees on the VTC. A display unit and a speaker output unit of the non-standard device 600 may provide, to the user, video and audio data, respectively, from other callees on the VTC.

Multiple transcoding nodes may be provided, optionally in geographically diverse locations so as to enable the management node to decide the most appropriate transcoding node for a particular user. For example, a user based in America wishing to access a VTC will experience minimal latency delay if the transcoding node chosen for their VTC is based locally rather than based, say, in Europe. Domain name lookup by address resolution based on geographical location of the client is performed, in examples, using the BIND patch GeoDNS, which is applied at the domain level. GeoDNS is configured and managed in examples within a DNS service.

The active transcoding node (that is, the transcoding node used for the VTC) may connect to VTC via a perimeter network where the VTC uses a commercial proprietary video platform. In one example, the proxy server provides a secure encrypted connection to a Microsoft DMZ (demilitarized zone) or perimeter network - an Azure hosted virtual network comprising a Microsoft Teams Connector. The proprietary Microsoft Teams Connector provides a secure encrypted gateway for the user into a Microsoft Teams call. In another example, the proxy server provides a secure encrypted connection to a Google Cloud based perimeter network, providing a secure encrypted gateway into a Google Meet call (using third-party solution Google Interoperability, for example). In another example, with WebRTC encoded video for use in a browser, the proxy server provides a secure encrypted connection to the browser. Thus, the proxy server allows connection into a system for a device that is not native to that system, providing interoperability.

Hence, the connection to the VTC may pass through or utilise a third-party cloud video interoperability solution, such as Microsoft’s Cloud Video Interop or Pexip for Google Meet. In this way, the non-standard device 600 may join Microsoft Team or Google Meet VTCs, respectively, as if the non-standard device 600 were a native client.

Figure 12 provides an example server hardware resource allocation. In this example, all endpoints of the VTC are connecting directly to transcoding conferencing nodes. The depicted server hardware resource allocation provides means for a single gateway call via a proxying edge node (standards-based endpoint) where there is a proxying node in location A and a transcoding node in location B. Both transcoding node and proxying node may be contained within the cloud services 400 as depicted, for example, in Figure 11. A gateway call is placed from a standards-based endpoint connected to the transcoding node to a VTC (via the backplane). The call is routed from the non-standard device 600 to the recipient client(s) via the proxying node. Alongside conventional audio and video content (“call” data), where appropriate, the non-standard device may also send and receive “presentation” data, for example the shared screen of a VTC participant.

In a case where the endpoint is a Microsoft Teams client (or clients), the non-standard device uses the SIP or H.323 video protocol and the VTC is routed via the proxying node and a Teams Connector application (installed on a virtual machine).

The skilled person will recognise that variations to this example server hardware resource allocation are possible: for example, one may provide multiple gateways at the transcoding node to support multiple distributed gateway calls via a proxying edge node (mixed endpoints to the same meeting).

The management node continues to pass (security) tokens to (and receive tokens from) the non-standard device and session until the VTC terminates.

In the above example, Pexip client REST API and/or and PexRTC JavaScript client API are used to initiate or connect to VTCs hosted on the Pexip Infinity platform, but the skilled person will appreciate that any available alternative means of initiating or connecting to a VTC may be used. For example, Cisco® Meeting Server could alternatively be used. To summarise, the non-standard device 600 uses the VTC meeting identification information that the companion device 500 has embedded in the QR code. The non-standard device 600 scans the QR code from the companion device 500 and uses the details within the QR code to complete the details required for a dial string to dial into a VTC. These missing variable details are the meeting alias and the meeting PIN, for either guest or host access to the VTC. All devices connecting to VTCs that make a connection to the management node are then routed to a transcoding node to continue a VTC for its duration. This applies to any device that is supported and/or is using methods according to embodiments.

Figure 13 is a schematic diagram of an example structure of the primary components of the cloud services 400 for starting/joining VTC meetings/calls. The proxy server is a Virtual Machine (VM), upon which sits a Linux distribution. The management node is also a VM, upon which sits a Linux distribution. The call routing engine in preferred examples sits inside the management node. Each transcoding node is also a VM, upon which sits a Linux distribution. In example cloud services, all nodes/VMs are hosted using the Microsoft Azure infrastructure.

Figure 14a depicts an example GUI dashboard on a non-standard device 600. In this example, the dashboard is the menu interface presented to the user on the display of a head-mounted assisted reality (AR) device. The user navigates (for example, using physical controls on the non-standard device, using voice controls, or using an eye-gaze sensor) to the appropriate software application installed on the non-standard device 600 (here, the highlighted application 12, “SIMPLY VIDEO”).

Figure 14b depicts another example GUI dashboard on a non-standard device 600. When the AR device executes the appropriate software application (see Figure 14a), the user navigates to the application option configured to initiate the operation of the camera peripheral of the non-standard device 600 and to expect to receive QR input (here, the highlighted option “Join New Meeting”).

Figure 14c depicts a further example GUI dashboard on a non-standard device 600. When the AR device initiates operation of the camera peripheral, the AR device displays a live-view of the acquired video feed. The AR device detects a QR code in the frame of the image using the positioning functional patterns of the QR code (here, detected on an example companion device 500 in the form of a smartphone). In this example QR code, the positioning functional patterns of the QR code are highlighted at the top left, top right, and bottom left. Additionally, the AR device may align the QR code using any alignment functional patterns in the QR code (highlighted at the lower right in the example QR code) for processing. The AR device decodes the QR code using conventional means and identifies the encoded meeting identification information. In this example, the meeting identification information is encoded in the QR code in plain text: “{“room”:”george”,”name”:”g”}”, where the meeting alias (“room”) takes the value of “george”. Additionally, the meeting identification information here includes the value “g” for the “name” of the user.

Optionally, the live-view of the acquired video feed includes a smaller frame, which identifies to the user of the AR device the active area in which the AR device can reliably scan any QR code. In this example, the inactive area in which the AR device cannot reliably scan any QR code is indicated with a darker, transparent mask.