US20150180821A1

US20150180821A1 - Systems and methods for generating electronic meeting invitations in video communications and other services

Info

Publication number: US20150180821A1
Application number: US14/639,642
Authority: US
Inventors: Ofer Shapiro; Ran Sharon; Alexandros Eleftheriadis
Original assignee: Vidyo Inc
Current assignee: Vidyo Inc
Priority date: 2012-09-11
Filing date: 2015-03-05
Publication date: 2015-06-25
Also published as: CA2884761C; EP2896202A2; EP2896202A4; US9467412B2; AU2013315660B2; US20140071224A1; CA2884761A1; WO2014043165A2; JP2015534676A; AU2013315660A1; WO2014043274A3; WO2014043274A2; WO2014043165A3; CN104769938A; CN104769938B

Abstract

A method and related apparatus for generating electronic meeting invitations in video communication and other services is described, including using an agent to automatically respond to electronic meeting invitations generated by users such that the response includes the generated connection information that will allow the intended participants to access the video communication or other service.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT/US13/059313, filed Sep. 11, 2013, and which claims priority to U.S. Provisional App. Ser. No. 61/699A65, titled, “System and Method for Agent-Based Integration of Instant Messaging and Video Communication Systems,” filed Sep. 11, 2012, the disclosures of which are incorporated herein by reference in their entireties.

FIELD

The disclosed subject matter relates to electronic services that involve two or more participants and which require scheduling so that all participants are available to participate. Examples include video and audio communication systems.

BACKGROUND INFORMATION

The disclosed subject matter relates to electronic services that involve two or more participants and which require scheduling so that all participants are available to participate. Examples include video and audio communication systems.
This may be accomplished by traditional means, such as calling each user on the telephone. Today, with the ubiquitous availability of electronic email and other messaging systems, it is much easier to simply send an email to all participants.
Certain electronic messaging systems, such as Microsoft's Outlook/Exchange, Apple's Mail/Calendar, and others, offer the capability to create an electronic calendar invitation that is sent to the intended participants via email. The invited users are given the option of accepting the invitation, either definitely or tentatively, or rejecting the invitation, possibly adding their own comments to the reply. The reply is emailed back to the originator of the invitation, where it can be read as an email message. Replies are also automatically processed and are available in the calendar application, so that the originator can easily see how many of the invitees have responded and how.
While the above mechanism may resolve the scheduling problem, one practical consideration is that any additional information that may be required for the application through which the users will be engaged has to be manually inserted by the originator. This may involve the user accessing a web page of the service, or some other document (e.g., a document or database that the user maintains for his/her own use), finding the relevant information, and copying-and-pasting it in the invitation. This may be cumbersome and error prone.
There are also instances where the information may not be available in advance. For example, consider a free conferencing service offered to all users. It would be desirable for users to be able to access the service without having to spend any configuration or set up time.
Commonly assigned International Patent Application No. PCT/US10/58801, “System and method for combining instant messaging and video communication systems,” incorporated herein by reference in its entirety, describes mechanisms for integrating Instant Messaging (IM) systems and video communication systems by using URLs placed by users in the IM system's chat window. Users who are not registered on, or logged in to, the videoconferencing system can click on the URL to join a session. The system described therein can use a plug-in to be installed alongside the IM client software to enable communication between the two system components. It would be desirable to offer the same level of seamless integration not just during the operation of a service, but also for scheduling access to the service in the first place.

SUMMARY

Systems and methods for generating electronic meeting invitations for activities or services where more than one person may be involved and which require additional configuration information that may not be known a priori are disclosed herein. In one embodiment of the disclosed subject matter, a user sends an electronic meeting invitation that includes in the list of invitees a special user that represents the activity or service.
The invitation to the special user is processed by the system and another invitation is generated for the same list of invitees as the original, where any additional configuration information required for the activity or service is included. In another embodiment, the processing of the original invitation generates an updated invitation that supersedes the original invitation, if the electronic calendaring system allows such operation.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features, the nature, and various advantages of the disclosed subject matter will be more apparent from the following detailed description and the accompanying drawings in which:

FIGS. 1 and 1B is a schematic illustration of an exemplary videoconferencing system;

FIGS. 2A and 2B provides exemplary screen snapshots during the process of creating a room URL;

FIG. 3 is a schematic illustration of an exemplary system for generating an electronic invitation for an exemplary videoconferencing system in accordance with the principles of the disclosed subject matter;

FIG. 4 is a schematic illustration of the client system architecture in accordance with the principles of the disclosed subject matter;

FIG. 5 depicts a screen snapshot from an exemplary meeting invitation; and

FIG. 6 shows an exemplary computer system in accordance with an embodiment of the disclosed subject matter.

The Figures are incorporated and constitute part of this disclosure. Throughout the Figures the same reference numerals and characters, unless otherwise stated, are used to denote like features, elements, components or portions of the illustrated embodiments. Moreover, while the disclosed subject matter will now be described in detail with reference to the Figures, it is done so in connection with the illustrative embodiments.

DETAILED DESCRIPTION

The disclosed subject matter describes a system that allows the generation of electronic meeting invitations for applications or services that involve two or more people. The application or service may require the simultaneous presence of the participants, as is the case, for example, in video and audio conferencing, interactive webinars, etc. Although the description of the disclosed subject matter uses video and audio conferencing as an example, the disclosed subject matter is similarly applicable to any service or activity that requires scheduling and which requires additional configuration information for users to be able to participate.
FIG. 1( a) depicts the architecture of an exemplary videoconferencing system 100. The system includes one or more VC Servers 120 and one or more VC Clients 110. Three such clients are shown in the figure (A, B, and C), with a single VC Server for purposes of illustration—the disclosed subject matter can be directly used in the case where multiple VC Servers 120 are present, and with any number of VC Clients. The VC Clients 110 and the VC Server 120 are connected via network connections 118 (A through C). In an embodiment, the IP protocol is used for the underlying network. The VC Client 110 may be a standalone system such as a computer-based system with a camera and one or more displays, or it can be software that is downloaded and run on a user's computer. The VC Client 110 can also be a web page that is loaded from the VC Server 120 (or another server) onto a user's browser (e.g., when the browser supports WebRTC).
FIG. 1( b) depicts the architecture of the VC Server 120. The server can include two components, a Portal 130 and a Core 140. In an embodiment, the Portal 130 is a web-based registration service, where users log in and through which they can initiate, receive, or control videoconferencing calls. The VC Server 120 also can include the Core 140 module, which is the component that receives, processes, and forwards media. As shown in the figure, the information carried over network connection 118 can be split between the Portal 130 and the Core 140, with media data flowing to/from the Core 140, and user/session management data flowing to/from the Portal 130.
The Portal 130 and Core 140 may communicate through a connection 158. Although the VC Server is shown as a single unit, the Portal 130 and Core 140 can be hosted on distinct systems that may even be physically in different locations. In that case, the connection 158 can be over the network, rather than being an internal connection within a single system.
In an embodiment, the VC Server Core is a Scalable Video Communication Server (SVCS), as described in part in commonly assigned U.S. Pat. No. 7,593,032, incorporated herein by reference in its entirety. Alternative VC Server Core architectures include the traditional switching Multipoint Control Unit (MCU) or the transcoding MCU, among others.
When the VC Clients 110 wish to use the services of the VC system, they all should be connected to the VC Server 120, at the same time, and with appropriate access configuration. Services that allow users to interact may provide an appropriate conceptual model for the interaction. In videoconferencing systems the abstract concept of a virtual “room” is used, paralleling the process of a physical meeting that occurs with participants being in the same room in the same time.
In certain systems, logged in users are allowed to start up videoconferencing calls and invite guest users to join them, even if they do not have log in privileges on the videoconferencing system portal. These users can utilize a special URL generated by the portal for the particular user that is conducting the videoconferencing call. The URL may be associated with the user's virtual room. Rooms may be freely accessible to registered users, unless protected by a PIN or password. In some videoconferencing systems, users may not be associated with fixed rooms, and room (or meeting place in general) associations may be created on demand by the server or portal hosting the conference. Accessing the room (or equivalent location-identifying) URL can enable anyone to log in as “guest” into the system, install the VC client software if not already installed and running, and connect to the conference call of the particular user. This can further enable registered users to conduct conference calls with any user, whether he is registered on the VC system or not. Of course, URLs can also be created that allow only registered users to access the service. The URL may also be associated with a particular time slot, with a particular set of participating users, etc. Any such rules may be asserted at the VC Server 120 (for the videoconferencing system example) when the URL is accessed by a VC Client 110.
The process of creating a room URL is shown in FIGS. 2( a) and (b) where the “My Account” page is shown as produced by an exemplary portal; in FIG. 2( a) there is no URL yet created, whereas in FIG. 2( b) the URL has been created and is available for use.
The client software can automatically be provided through the portal, so that the users do not have to pre-install software in advance of making a call. The user may be prompted to download the software after connecting to the portal through the URL, if the software is not already available and running on the user's computer.
We now describe the process of generating an electronic invitation to access a videoconferencing service such the one depicted in FIG. 1. FIG. 3 depicts an exemplary configuration with two users. The system can work in an identical way if more than two users are involved. The system of FIG. 3 shows two Clients 310A and 310B that wish to access the services of the VC Server 330 over corresponding network connections 318A and 318B. In order to schedule a meeting the Clients 310 use the services of a messaging and calendaring system, such as Microsoft Outlook or Apple Mail and Calendar. The messaging service is represented in the figure by the Messaging/Calendaring Server 320. Although a single messaging server is shown, several servers may involve in the relaying of messages as, for example, in Internet email systems.
Messaging/Calendaring Server 320 over corresponding network connections 315A and 315B, respectively. The network connections may be over the same network as the ones providing access to the VC Server 330 (e.g., over the public Internet), or they may be over a separate network. Examples include a private IP network, the text messaging system offered by mobile telephone carriers (SMS), the BlackBerry Messenger service, etc., Apple's iMessage, etc.
FIG. 4 shows the Client system architecture in accordance with an aspect of the disclosed subject matter. The Client 400 contains a Messaging/Calendaring Client module 450 and a VC Client module 490. The VC Client module 490 can operate as a VC Client in the same way as the VC Client(s) shown in FIG. 1. The Messaging/Calendaring Client module 450 may be any messaging/calendaring application or set of applications, such as Microsoft Outlook/Exchange or Apple Mail/Calendar.
Notice that the Messaging/Calendar Client module 450 can communicate with the Messaging/Calendar Server via the connection 415, whereas the VC client module 490 can communicate with the VC Server via the connection 418. The VC Server interface through the connection 418 in an embodiment where the system is used is SOAP-based. Although the VC Client module 490 is shown here as part of the Client 400, it is noted that this is only a logical association. The VC Client module 490 could be in the same computer system as the Messaging/Calendaring Client 450, or it could be in a different system, possibly even at a different physical location. That the VC Client module 490 communicates with the rest of the system through connection 418 can make the actual physical location of the VC Client module 490 irrelevant. The VC Client module 490 could be a standalone videoconferencing system. In this case, the videoconference would run on a separate computer system than the IM Client 450, but the process of generating the electronic meeting invitation, as disclosed below, can be identical.
With reference to FIG. 3, when one of the Clients 310, for example Client 310A, wishes to schedule a conference call, it creates a calendar invitation which it then sends to all intended participants via the messaging system. The calendar invitation contains the list of participants and their emails (needed by the messaging system in order to route the messages), the day and time of the meeting, as well as any additional information that the initiating user may wish to include.
In order to avoid having the initiating user obtain the needed information in order to insert it to the meeting invitation, the VC System provides an Agent 350. The Agent 350 communicates with the VC Server 330 but it is also connected to the messaging system. FIG. 3 depicts the Agent 350 connected to the Messaging/Calendaring Server 320 over a network connection 315VC. The Agent 350 is identified in the messaging system as any other user. For example, in a system that uses Internet email it may have its own email address such as “video@abc.com”.
The initiating client Client 310A will include the messaging system identification of the Agent 350 into the invitation. In the Internet email case, it can include the Agent 350′s email address in the calendar invitation. The invitation will be received by all intended participants, such as Client 310B, but it will also be received by Agent 350. The Agent 350 can examine the invitation and, in coordination with the VC Server 330, can respond to the meeting invitation as any other participant, but including all information that is needed by the participants to access the service.
The meeting invitation includes all relevant information for allocating service resources: the number of users, their email address and their names, as well as the time and day of the meeting. If the initiating user is registered to the VC Server 330, the Agent 350 may generate a room URL associated with the particular user. If the initiating user is not registered on the VC Server 330, and if the VC Server 330 offers its services for free, then the Agent 350 can allocate a specific URL for the particular meeting.
As mentioned earlier, the generated room URL may encode any number of information, including a list of participants, the time and day of the meeting, etc. This information may be encoded in such a way that it is not human-readable, and may also feature tamper-detection information (e.g., CRC digits) to avoid arbitrary modification by a user.
After the Agent 350 and the VC Server 330 create the appropriate room URL, the Agent 350 can respond to the invitation in a number of ways. If the messaging system allows updates of the original invitation, the Agent 350 may respond by accepting the invitation and providing its connection information as updated comments. The updated comments may include the room URL information and any other connection information. but also information messages such as “Thank you for using our services. For support call the following number.”, etc. FIG. 5 shows a screen snapshot from an exemplary meeting invitation (generated from Microsoft Outlook for Mac 2011). The response may be sent only to the originator, or to all intended participants, depending on the capabilities of the messaging/calendaring system.
If the messaging system does not allow updates of the original invitation, the Agent 350 may respond by accepting the invitation, and by emailing the connection information to the meeting originator, or to all intended participants. The originator may then have to copy and paste the information to his or her calendar entry and send an update to all intended participants.
If, for some reason, the Agent 350 does not authorize access to the VC Server 330 (due to lack of capacity, access credentials, etc.), it can simply reject the invitation by sending the appropriate meeting invitation response. As an example, the VC Server 330 can track the projected load based on the number of scheduled sessions and the number of users, and decide if it has the capacity to provide additional service for the day and time requested.
Since the meeting invitation may contain the URL generated by the Agent 350, any future updates of the meeting invitation, such as a change of day or time, or participants, should contain the original URL. The Agent 350 can parse incoming meeting invitations to see if they already contain its own generated URLs. If the invitation does include such a UAL, the Agent 350 may use the information encoded in the URL to identify the originally allocated session, examine if the modification is acceptable, and respond accordingly. The Agent 350 may also track unique identifiers provided by the Messaging/Calendaring System for the same purpose. It may also insert its own unique identifiers as well.
The methods for generating electronic meeting invitations in video communication and other services, described above, can be implemented as computer software using computer-readable instructions and physically stored in computer-readable medium. The computer software can be encoded using any suitable computer languages. The software instructions can be executed on various types of computers. For example, FIG. 6 illustrates a computer system 600 suitable for implementing embodiments of the present disclosure.
The components shown in FIG. 6 for computer system 600 are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure. Neither should the configuration of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of a computer system. Computer system 600 can have many physical forms including an integrated circuit, a printed circuit board, a small handheld device (such as a mobile telephone or PDA), a personal computer or a super computer.
Computer system 600 includes a display 632, one or more input devices 633 (e.g., keypad, keyboard, mouse, stylus, etc.), one or more output devices 634 (e.g., speaker), one or more storage devices 635, various types of storage medium 636.
The system bus 640 link a wide variety of subsystems. As understood by those skilled in the art, a “bus” refers to a plurality of digital signal lines serving a common function. The system bus 640 can be any of several types of bus structures including a memory bus, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, Enhanced ISA (EISA) bus, the Micro Channel Architecture (MCA) bus, the Video Electronics Standards Association local (VLB) bus, the Peripheral Component Interconnect (PCI) bus, the PCI-Express bus (PCI-X), and the Accelerated Graphics Port (AGP) bus.
Processor(s) 601 (also referred to as central processing units, or CPUs) optionally contain a cache memory unit 602 for temporary local storage of instructions, data, or computer addresses. Processor(s) 601 are coupled to storage devices including memory 603. Memory 603 includes random access memory (RAM) 604 and read-only memory (ROM) 605. As is well known in the art, ROM 605 acts to transfer data and instructions uni-directionally to the processor(s) 601, and RAM 604 is used typically to transfer data and instructions in a bi-directional manner. Both of these types of memories can include any suitable of the computer-readable media described below.
A fixed storage 608 is also coupled bi-directionally to the processor(s) 601, optionally via a storage control unit 607. It provides additional data storage capacity and can also include any of the computer-readable media described below. Storage 608 can be used to store operating system 609, EXECs 610, application programs 612, data 611 and the like and is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. It should be appreciated that the information retained within storage 608, can, in appropriate cases, be incorporated in standard fashion as virtual memory in memory 603.
Processor(s) 601 is also coupled to a variety of interfaces such as graphics control 621, video interface 622, input interface 623, output interface 624, storage interface 625, and these interfaces in turn are coupled to the appropriate devices. In general, an input/output device can be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, or other computers. Processor(s) 601 can be coupled to another computer or telecommunications network 630 using network interface 620. With such a network interface 620, it is contemplated that the CPU 601 might receive information from the network 630, or might output information to the network in the course of performing the above-described method. Furthermore, method embodiments of the present disclosure can execute solely upon CPU 601 or can execute over a network 630 such as the Internet in conjunction with a remote CPU 601 that shares a portion of the processing.
According to various embodiments, when in a network environment, i.e., when computer system 600 is connected to network 630, computer system 600 can communicate with other devices that are also connected to network 630. Communications can be sent to and from computer system 600 via network interface 620. For example, incoming communications, such as a request or a response from another device, in the form of one or more packets, can be received from network 630 at network interface 620 and stored in selected sections in memory 603 for processing. Outgoing communications, such as a request or a response to another device, again in the form of one or more packets, can also be stored in selected sections in memory 603 and sent out to network 630 at network interface 620. Processor(s) 601 can access these communication packets stored in memory 603 for processing.
In addition, embodiments of the present disclosure further relate to computer storage products with a computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code can be those specially designed and constructed for the purposes of the present disclosure, or they can be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as optical disks; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. Those skilled in the art should also understand that term “computer readable media” as used in connection with the presently disclosed subject matter does not encompass transmission media, carrier waves, or other transitory signals.
As an example and not by way of limitation, the computer system having architecture 600 can provide functionality as a result of processor(s) 601 executing software embodied in one or more tangible, computer-readable media, such as memory 603. The software implementing various embodiments of the present disclosure can be stored in memory 603 and executed by processor(s) 601. A computer-readable medium can include one or more memory devices, according to particular needs. Memory 603 can read the software from one or more other computer-readable media, such as mass storage device(s) 635 or from one or more other sources via communication interface. The software can cause processor(s) 601 to execute particular processes or particular parts of particular processes described herein, including defining data structures stored in memory 603 and modifying such data structures according to the processes defined by the software. In addition or as an alternative, the computer system can provide functionality as a result of logic hardwired or otherwise embodied in a circuit, which can operate in place of or together with software to execute particular processes or particular parts of particular processes described herein. Reference to software can encompass logic, and vice versa, where appropriate. Reference to a computer-readable media can encompass a circuit (such as an integrated circuit (IC)) storing software for execution, a circuit embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software.
While this disclosure has described several exemplary embodiments, there are alterations, permutations, and various substitute equivalents, which fall within the scope of the disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods which, although not explicitly shown or described herein, embody the principles of the disclosure and are thus within the spirit and scope thereof.

Claims

What is claimed is:

1. A system for generating electronic meeting invitations to access a service over a network, the system comprising:

one or more messaging clients;

one or more messaging servers coupled to the one or more messaging clients over a messaging network;

one or more servers providing the service;

an agent coupled to the one or more servers over the network and coupled to the one or more messaging servers over the messaging network;

wherein the agent is configured to respond to an electronic meeting invitation received from one of the one or more messaging clients by either: generating connection information, placing the generated connection information in an electronic meeting invitation acceptance, and sending the electronic meeting invitation acceptance, if the service can be provided; or sending an electronic meeting invitation rejection, if the service can not be provided.

2. The system of claim 1, wherein the messaging network and the network are the same network,

3. The system of claim 1, wherein the electronic meeting invitation acceptance or electronic meeting invitation rejection is sent to the one of the one or more messaging clients from which the electronic meeting invitation was received.

4. The system of claim 1, wherein the electronic meeting invitation acceptance or electronic meeting invitation rejection is sent to all messaging clients identified in the electronic meeting invitation.

5. The system of claim 1, wherein the agent is further configured to send the generated connection information to the messaging clients identified in the electronic meeting invitation by placing the generated connection information in a regular message and sending it to the messaging clients identified in the electronic meeting invitation.

6. The system of claim 1, wherein the agent is further configured to send the generated connection information to the messaging client from which the electronic meeting invitation was received by placing the generated connection information in a regular message and sending it to the messaging client from which the electronic meeting invitation was received.

7. The system of claim 1, wherein the agent is further configured to parse the electronic meeting invitation in order to detect if it already contains connection information generated by it and, if it does, to combine the contained connection information with the information provided by the electronic meeting invitation, prior to deciding if the service can be offered and prior to generating the connection information.

8. A method for generating electronic meeting invitations to access a service over a network using messaging clients coupled with one or more messaging servers over a messaging network, the method comprising:

providing an agent to the one or more servers and one or more messaging servers;

receiving, at the agent, an electronic meeting invitation;

at the agent, deciding if the service can be provided and, if not, sending an electronic meeting invitation rejection; whereas if the service can be provided, generating connection information, placing the generated connection information in an electronic meeting invitation acceptance, and sending the electronic meeting invitation acceptance.

9. The method of claim 8, wherein the messaging network and the network are the same network.

10. The method of claim 8, wherein the electronic meeting invitation acceptance or electronic meeting invitation rejection is sent to the one of the one or more messaging clients from which the electronic meeting invitation was received.

11. The method of claim 8, wherein the electronic meeting invitation acceptance or electronic meeting invitation rejection is sent to all messaging clients identified in the electronic meeting invitation.

12. The method of claim 8, wherein the agent is further configured to send the generated connection information to the messaging clients identified in the electronic meeting invitation by placing the generated connection information in a regular message and sending it to the messaging clients identified in the electronic meeting invitation.

13. The method of claim 8, wherein the agent is further configured to send the generated connection information to the messaging client from which the electronic meeting invitation was received by placing the generated connection information in a regular message and sending it to the messaging client from which the electronic meeting invitation was received.

14. The method of claim 8, wherein the agent is further configured to parse the electronic meeting invitation in order to detect if it already contains connection information generated by it and, if it does, to combine the contained connection information with the information provided by the electronic meeting invitation, prior to deciding if the service can be offered and prior to generating the connection information.

15. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 8.

16. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 9

17. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 10.

18. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 11.

19. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 12.

20. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 13.

21. A non-transitory computer readable medium comprising a set of executable instructions to direct a processor to perform the method of claim 14.