Real-time meeting object extensibility

A system and method for sharing and installing customized meeting objects into an ongoing electronic meeting is disclosed. An object module, which defines the customized meeting object is loaded onto a server hosting the ongoing electronic meeting. Client-side portions of the object module are then downloaded to each of the clients that are participating in the electronic meeting. While the meeting is ongoing, the meeting player installs the client-side portions of the object module and displays the customized meeting object, at least, to a meeting presenter. Once displayed to a meeting presenter, the presenter may use the customized meeting object during the meeting and display such object to the meeting participants when desired.

TECHNICAL FIELD

The present invention relates, in general, to collaborative electronic meeting space, and, more specifically, to providing real-time extensibility of meeting objects.

BACKGROUND OF THE INVENTION

The first Internet was a communications system funded and built by researchers for military use. This Internet, originally known as ARPANET, was embraced by the research and academic communities as a mechanism for scientists to share and collaborate with other scientists. This collaborative network quickly evolved into the information superhighway of commerce and communication. The Internet explosion was due, in part, to the development of the World Wide Web (WWW) and graphically-based Web browsers, which facilitated a more graphically-oriented, multimedia system that uses the infrastructure of the Internet to provide information in a graphical, visual, and interactive manner that appeals to a wider audience of consumers seeking instant gratification.

As the technology underlying transmission bandwidth has grown in conjunction with the accessibility to such increasing transmission bandwidth, a new paradigm for the old idea of Internet collaboration is emerging that takes advantage of the modern graphical, visual world. This new paradigm is also driven by the advance in real-time or time-sensitive data transmission technology, such as Voice over Internet Protocol (VoIP) technology, and the like. Non-Internet videoconferencing, which has generally never been able to completely supplant teleconferencing as a viable means for reliable communications, is slowly fading away in favor of Internet-driven technology, such as collaborative electronic meetings. Services, such as WEBEX COMMUNICATIONS, INC.'S, WEBEX™ electronic meeting or collaboration services offer the ability for users to connect, at least initially, across the Internet to share voice, video, and data in real time for meetings, presentations, training, or the like.

In such collaborative meeting environments, a virtual meeting room typically is made up of several meeting objects which are generally containers for presentation information, such as slides, video, audio, documents, computer applications, and the like, that are themselves contained within the container of the meeting room. Other meeting objects may contain and display information concerning the meeting, such as the meeting participants, text communications made by the meeting participants, or the like. In current electronic meeting applications, these meeting objects are usually pre-existing segments of computer code that are statically placed onto a form virtual meeting room. Except for the possibility of showing and hiding predefined objects, or of being capable of moving a meeting object to a different location on the virtual meeting room during an actual electronic meeting, customization of meeting objects is typically performed well in advance and installed into the electronic meeting application architecture with the help of the application owner. Moreover, existing electronic meeting applications offer no means for new meeting objects to be created and implemented during a live meeting. This lack of control reduces the flexibility of the modern electronic meeting applications.

BRIEF SUMMARY OF THE INVENTION

The various embodiments of the present invention are directed to a system and method for sharing customized meeting objects into a real-time electronic meeting. Pod developers may create a new meeting object or pod that performs a desired task or set of features or functions or display desired information. A pod or meeting object is a display sub-module that is displayed on the meeting interface. Each pod or object may display various different types of information, such as a video, slides, text, notes, and the like, and may also include logic to perform specific functions. These meeting objects or pods may be designed to look a particular way or be a particular size or even perform any variety of different functions. Because a meeting object or pod will be used not only on each of the meeting participant's computers or meeting interface units, but also on the server that is hosting the electronic meeting, the pod developers create a client-side meeting object module and a server-side meeting object module. The client-side modules are written in a file format that may be used by the client-side electronic meeting application. Conversely, the server-side modules are also written in a file format that may be run by the host server. The function of each local pod playing on the electronic meeting application may be directed or fed with information or data flowing from or being produced by the server-side pod application running on the host server. In the case of an online meeting, this information or data may originate on the client computer of a meeting presenter and/or viewer or meeting participant. However, the originating information would then be communicated to the host server, which disseminates it to the other participating client units.

In representative embodiments of the present invention, the pod developers may package both the client-side module and server-side module into a single archive file which may then be uploaded to the host server. After unpacking the archive file, the server installs the server-side module and signals each of the participating clients that a new meeting object is available. Each client would then signal to download the client-side module. The electronic meeting application operating on the participating client receives and installs the server-side module during an ongoing electronic meeting. As soon as the module is installed and the new meeting object establishes communication with the server-side module, the new meeting object may appear to the meeting participants on the electronic meeting canvas in real-time or, at least, become available to a meeting presenter for immediate display on the meeting canvas.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1is a block diagram illustrating collaborative electronic meeting space10configured according to one embodiment of the present invention. Electronic meeting space10is implemented over Internet100. Each of participating clients101-105accesses electronic meeting space10through Internet100and establishes a connection with host server106. The users at any one of participating clients101-105may be a presenter or merely a meeting participant. Each one would run an instance of an electronic meeting application which displays the meeting canvas and meeting objects or pods to the users. The meeting objects displayed on participating clients101-105receive data and information from host server106. The data may originate from a meeting presenter or viewer/participant either by way of a pre-existing presentation file that the presenter uploads to host server106or by live data from the meeting presenter's screen in a screen share function. The data may also originate from host server106, such as a list of participants, results of a poll or quiz, or the like.

In the embodiment depicted inFIG. 1, participating client101may be a meeting presenter, for example. The user at participating client101develops a customized meeting object to be added to the ongoing meeting within electronic meeting space10. The presenter uploads the new meeting object or pod from participating client101to host server106via Internet100. Host server106installs the server-side portion of the new meeting object and then pushes the client-side portion of the new meeting object to each of participating clients102-105. Once installed by the electronic meeting application operating on participating clients102-105, the new meeting object appears on the meeting canvas for each of the users to see and interact with.

FIG. 2Ais a screenshot illustrating electronic meeting canvas20displayed as a part of an electronic meeting application configured according to an embodiment of the present invention. Electronic meeting canvas20includes a number of meeting objects or pods, such as slides pod200, camera and voice pod201, attendee pod202, chat pod203, and notes pod204. Electronic meeting canvas20operates much like an interactive multimedia runtime container (iMRC), such as MACROMEDIA INC.'s MACROMEDIA FLASH™ player, or a media player, such as MICROSOFT CORPORATION's WINDOWS™ MEDIA PLAYER, and the like. The meeting shell or canvas may also be implemented in a general purpose programming environment, such as SUN MICROSYSTEM INC.'S JAVA™, MICROSOFT CORPORATION'S WINDOWS 32™, and .NET™ CLR. Each of the pods is represented by a software module that is played by electronic meeting canvas20to display the visual makeup of the pod or meeting object along with its display data.

It should be noted that when implemented in iMRC technology, such as a MACROMEDIA FLASH™ player, electronic meeting canvas20may be displayed on one instance of an iMRC, while each of the contained meeting objects or pods may be rendered as independent objects on the same instance of the iMRC. This implementation allows for separate and independent communication streams to be established between each iMRC instance and an interactive multimedia communication server (iMCS), such as MACROMEDIA, INC.'s FLASH COMMUNICATION SERVER™ (FCS).

It should be noted that in some embodiments of the present invention, the code for interface components, such as buttons, check boxes, scroll bars, and the like may be excluded from the actual pod module or file, relying, instead on a run-time shared library (RSL) to supply the component code. The pod module or file would, therefore, contain references or calls to the RSL in order to generate the defined interface components. Additional or alternative embodiments of the present invention, however, may include the interface component code within the actual pod or meeting object module.

FIG. 2Bis a screenshot illustrating electronic meeting canvas20having a new meeting object installed during an ongoing electronic meeting. For purposes of the description of the embodiment illustrated inFIG. 2B, the hypothetical electronic meeting is a meeting between an insurance agent and a potential insured. Application pod205was developed in order to assist an insured fill out a particular insurance form. The meeting presenter in this example scenario would be the insurance agent. When the agent receives the new meeting object module, he or she may first install it during an actual live electronic meeting with a potential insured. For purposes of this example, a meeting may have begun, as depicted inFIG. 2A, between the insured and the insurance agent. The insurance agent, now having the new meeting object of application pod205, uploads the meeting object module to the host server, such as host server106(FIG. 1). The host server installs the server-side code for the new meeting object and pushes the client-side code for application pod205to the potential insured's computer. In push technology, a server typically issues a signal to a client that data on the server is available for download. Once the client receives this message, the client sends a download request to the server for that particular data. This signaling is typically implemented in the processing of the application. Therefore, a user is generally unaware that such signaling is occurring.

During the meeting, the insurance agent may be broadcasting voice and video through camera and voice pod201and possibly sending chat messages through chat pod203. The underlying electronic meeting application running electronic meeting canvas20and each of the displayed meeting objects installs the code for application pod205. Once installed, application pod205is available for the insurance agent to bring onto electronic meeting canvas20, as it is shown inFIG. 2B. As application pod205is brought onto electronic meeting canvas20, the information and data being shared in camera and voice pod201, attendees pod202, chat pod203, and notes pod204continues to be shown without interruption.

The hypothetical functionality of application pod205allows both the insurance agent and the potential insured to fill out an insurance form together, even though both may be in locations remote to each other. This functionality would be useful for each such electronic meeting for this insurance product or insurance company. Therefore, in additional or alternative embodiments of the present invention, once the server-side code for the new meeting object has been installed and a copy of the client-side code saved onto the host server, every other meeting established by this particular insurance company may access application pod205for future meetings. Thus, the new object module is installed once in order to be available for future electronic meetings.

FIG. 3is a block diagram illustrating an additional embodiment of the present invention for sharing new meeting objects in live electronic meeting30.FIG. 3shows a single connection between participant client31and hosting server32over Internet300. Additional clients may be in communication with hosting server32in order to attend a multiparty electronic meeting. However, for purposes ofFIG. 3, only the connection between participant client31and hosting server32is shown. The electronic meeting application running on participant client31and hosting server32manage live electronic meeting30. On the client-side, electronic meeting application includes shell301, which is the backbone of the electronic, online meeting system. Shell301handles all the windowing, the loading of the various pods or meeting objects, and manages all of the client-to-server communication. Similarly, on the server side, shell305manages the same types of features and functions on the server side of the meeting.

The electronic meeting application comes with a variety of pre-built pods, pods309, which represent normal, generic meeting objects or pods, such as slides pod200(FIG. 2A), camera and voice pod201(FIG. 2A), and the like. The generic meeting objects are installed as pods309on the client-side of the electronic meeting application, participant client31, and as pods310on the server-side, hosting server32. One consideration that is made in allowing custom meeting objects into live electronic meeting30is security. If no security considerations are made, it may be possible for a custom meeting object module to be created that disrupts or crashes the meeting, or, worse, possibly infect the clients and servers with a virus or other such undesirable software. The embodiment of the present invention shown inFIG. 3is constructed with security measures taken to insulate the inner workings of live electronic meeting30from a custom meeting object, such as custom pod304(on participant client31) and its server-side counterpart, custom pod308.

Instead of installing custom pod308directly into the electronic meeting application on participant client31, a new pod type is defined within the electronic meeting application to interact specifically with customized pods. This custom pod type, pod shell302, acts as a container for custom pod304and limits custom pod304's communication with shell301and the electronic meeting application on hosting server32. Pod shell302acts like an isolation interface, isolating the processing activities of custom pod304. Pod shell302maintains two-way communications with shell301for managing the calls to hosting server32and the server-side counter part, custom pod308.

When a new, custom pod is uploaded, shell301causes a new instance of the new pod type to be formed, pod shell302. Pod shell302creates an intermediary object, presentation object303, which accepts API calls from custom pod304, but which is controllable by pod shell302should custom pod304become unstable or attempts to disrupt the meeting. Custom pod304is installed within the container of pod shell302and is able to make application programming interface (API) calls only to presentation object303. Presentation object303is also limited to make API calls only to pod shell302. In turn, pod shell302may make API calls directly to custom pod304. With this architecture, custom pod304is sufficiently isolated from the inner workings of the electronic meeting application running live electronic meeting30on participant client31.

In operation, the meeting participant may activate some interface component on the new meeting object defined by custom pod304. Shell301communicates this API call to pod shell302. Pod shell302makes the API call directly on custom pod304. Custom pod304makes the API call to presentation object303, which, in turn, calls on pod shell302. Pod shell302makes a server call to shell301, which communicates the call over Internet300to server-side shell305. Server-side shell305makes its API call on pod shell306, which makes an API call on the server-side counterpart, custom pod308. When the processing of custom pod308returns responsive data, or a result, the data or result is communicated to presentation object307, which communicates the data to pod shell306. Pod shell306communicates the data to server-side shell305, which transmits the data over Internet300to shell301. Shell301may either render the data onto the new meeting object directly or may deliver the data to custom pod304through pod shell302. If processing is done at custom pod304, the results may be delivered back to shell301for rendering, through presentation object303and pod shell302. Thus, custom pod304is isolated from direct communication with the main components of the electronic meeting application. If custom pod304attempted to make an invalid API call to presentation object303, presentation object303would not understand the call, which would go unanswered. Similarly, because custom pod304is only allowed to make API calls on presentation object303, if a call were attempted on pod shell302or shell301from custom pod304, it would similarly go unanswered.

It should be noted that various embodiments of the present invention may implement live electronic meeting30using existing iMCS technology, such as MACROMEDIA, INC.'s FCS, and existing iMRC technology, such as the MACROMEDIA FLASH™ player. When created using such FCS and MACROMEDIA FLASH™ player technology, it should be noted that custom pod304would be a Small Web File (SWF) format, which is the native format for the MACROMEDIA FLASH™ player. Custom pod308would then be an ActionScript for Communication (ASC) file format, which is one of the native formats for the FCS. Other technologies with similar functionality, such as a dynamic link library (DLL) file, a JAVA™ class file, and/or a CLR assembly, may be used to implement the various embodiments of the present invention.

FIG. 4is a block diagram illustrating a packaging system in an electronic meeting application configured according to another embodiment of the present invention for packaging server-side and client-side meeting object modules into a single meeting object module for a host server. In order to develop a new or customized meeting object or pod, a developer codes server-side module401, which contains the server script or code to communicate the functionality of the new meeting object to each of the participating clients, and client-side module400, which contains the code for defining the appearance and functional interface of the new object. For example, if operating using the systems noted above, server-side module401may be an ASC file type to be run on an FCS server. Similarly, client-side module402may be a SWF file format to play on a presentation canvas implemented using an instance of the MACROMEDIA FLASH™ player. The new meeting object will not operate unless server-side module401is installed onto the host server and client-side module400is installed on each of the participating clients. Instead of uploading each of server-side module401and client-side module400separately to the host server, the embodiment of the present invention depicted inFIG. 4creates meeting object extension403that combines server-side module401and client-side module400into a single file.

A meeting object developer may input client-side module400and server-side module401into packing utility402. Packing utility402compresses client-side module400into compressed client-side module405and compresses server-side module401into compressed server-side module406. Compressed modules405and406are then wrappered into an extension file with the addition of module instructions404. Module instructions404is a set of server instructions that direct the host server what to do with meeting object extension403, including how to unpack and install server-side module401.

It should be noted that in additional and/or alternative embodiments of the present invention, meeting object extension403may not include module instructions404. In such embodiments, the server automatically knows how to handle the other objects within meeting object extension403.

After the host server installs unpacked server-side module401, a signal may be sent by the host server to each participating client indicating that a new meeting object is available. This signal is sent to the electronic meeting application running on each participating client system. A user is unaware that any such signaling occurs with the host server regarding a new meeting object. The electronic meeting application for each of the participating clients then requests to download the client-side module400from the host server. Once client-side module400is downloaded, electronic meeting application begins running the client-side code for implementing the new meeting object on the presentation screen. The electronic meeting application maintains an open connection to the host server and is able to begin running a presentation instance for the new meeting object at the same time that the rest of the meeting is still running.

A related technology that utilizes a packaged set of files for installation onto a server is SUN MICROSYSTEMS, INC.'s JAVA™ ARCHIVE (JAR) files. The JAR file format consolidates multiple files into a single archive file, which contains JAVA™ classes and other auxiliary files, such as property files. These multiple files are compress using a ZIP compression algorithm. The compression of the files assists in distributing applications across a network. However, while this style of archiving, as in the JAR files, has been practiced, the selected embodiments of the present invention which utilize the packaging system is distinctive. Because JAR files are intended to run with JAVA™-based application servers, which run with a Web browser, the client cannot utilize the application and information within the JAR file without first refreshing the page. In contrast, the embodiments of the present invention that utilize a packaging technique operate in real-time, such that as the electronic meeting is operating, the server and clients may download and install the packaged files or applications.

FIG. 5is a flowchart illustrating example steps executed in implementing an embodiment of the present invention. In step500, an object module is uploaded to a host server, wherein the object module defines the new meeting object. The object module may come from a meeting participant who is a presenter in the electronic meeting or from a mere participant. In step502, the new meeting object is installed at each one of the participating clients in communication with the host server. The new meeting object is displayed in step503within the collaborative electronic meeting running on the participating clients.

FIG. 6is a flowchart illustrating example steps implementing an additional embodiment of the present invention. In step600, an object module, that has at least a server-side sub-module and a client-side module, is uploaded to a host server, wherein the object module defines the new meeting object. The server-side sub-module and the client-side sub-module are unpacked from the object module upon receipt of the object module by the host server, in step601, wherein the client-side sub-module may be stored on the host server for use in future electronic meetings. The server-side module is then installed on the host server in step602. The client-side sub-module is downloaded, in step603, and installed, in step604, to each of the participating clients in communication with the host server. The processing activities of the installed new meeting object are restricted to an isolation interface, in step605, wherein the isolation interface transmits signals for implementing functionality of the new meeting object to the collaborative electronic meeting. In step606, the new meeting object is displayed within the collaborative electronic meeting running on the participating clients.