Patent Application
20070271337
The same numbers are used throughout the disclosure and figures to reference like components and features.
The following document describes tools capable of enabling participants in a real-time, collaborative electronic meeting to know when the meeting productively starts. To do so, the tools may build a quorum of events that need to occur before the meeting may productively start and notify participants when all of those events have occurred. These tools may do so in distributed, centralized, or combined communication topologies.
An environment in which the tools may enable these and other actions is set forth below in a section entitled Exemplary Operating Environment. This is followed by another section describing one exemplary way in which the tools may act to build a quorum and is entitled Building an Exemplary Quorum. Another section follows and describes using the built quorum in a central communication topology to notify participants when the meeting productively starts and is entitled Example in a Central Communication Topology. A final section describes these and other embodiments and manners in which the tools may act in a centralized, distributed, or combined communication topology and is entitled Other Embodiments of the Tools. This overview, including these section titles and summaries, is provided for the reader's convenience and is not intended to limit the scope of the claims or the entitled sections.
Before describing the tools in detail, the following discussion of exemplary operating environments is provided to assist the reader in understanding some ways in which various inventive aspects of the tools may be employed. The environments described below constitute examples and are not intended to limit application of the tools to any one particular operating environment or communication topology. Other environments and topologies may be used without departing from the spirit and scope of the claimed subject matter.
The environment also has a communications network 114, such as a company intranet or a global internet (e.g., the Internet) and in some cases has access to a server 116. The participants' devices may be capable of communicating directly to the network (e.g., a wireless-Internet enabled laptop, PDA, or a Tablet PC, a wired Internet-enabled desktop computing device, or VoIP-enabled telephone or cellular phone wired or wirelessly connected to the Internet) or indirectly (e.g., the telephone connected to the phone-to-network device). The meeting may be enabled through a distributed (e.g., peer-to-peer) or central network topology (or a combination of these). Exemplary distributed and central network topologies are illustrated in
The server 116 and/or any of these devices, including the phone and the phone-to-network device, may be a computing device having one or more processor(s) 118 and computer-readable media 120 (each device and the server marked with “◯” to indicate this possibility). The processor(s) are capable of accessing and/or executing the computer-readable media. The computer-readable media comprises meeting software 122 and a quorum module 124.
The meeting software and the quorum module may be integral (not shown) or separate. The module is capable of building and/or using the quorum to notify participants (or others) that a meeting has productively started. The quorum module comprises, indicates, or has access to a quorum 126 with quorum events related to one or more of participants 128, resources 130, and others 132. Note that the term “participants” is sometimes used interchangeably herein with the communication device used by the participants, as will be apparent by the context.
Here the meeting software acts as a central manager that manages the meeting, keeps track of participants in a roster, receives uploaded documents and distributes them to participants, and other actions of conferencing software applications know to those skilled in the art. The meeting software in this central communication topology interacts with a client application 202 on each of the participant's computing devices (shown comprised by participant B's device but comprised by each of the participant's devices). The client applications may each interact with the meeting software on the server to send and receive media and documents, make notifications (e.g., those ordered by the quorum module), present a user interface for the meeting having media and documents, and in other manners known to those skilled in the art.
In this section elements of
At arrow 1, the quorum selector selects quorum events. The selector may submit quorum events or indicate existing parameters of an existing meeting as quorum events (shown with arrow 1 passing through parameters 404). Here a person named Andrew (e.g., Participant A through device 102) selects the following events to be quorum events:
Participants:
Resources:
Others:
Here we assume that the meeting was already set up with seven invitees (i.e., permitted participants) and the meeting time. Andrew selected to make the meeting time a quorum event so that the quorum would not be met and thus the participants not notified until at least 11 a.m. on October 10th. This was to insure that even if everything was ready before 11 a.m. that the meeting would not be notified as productively starting until then.
Andrew also selected that three of the seven invitees be present, perhaps because a vote needs to be made during the meeting and requires this number present for a valid vote. Andrew also selected Eugene Smith, one middle manager, and one technologist be participating in the meeting before the quorum is met. Note that here this means that either Bill Tincam or Steve Phaka needs to be present and that both Joe Smith and Andrew Aggarwall must be present (Andrew because he is the only technologist invited, not because he is also the quorum selector).
Andrew selected these quorum events by indicating that these meeting parameters are to be made quorum events, such as by clicking on the text for the meeting time, Joe Smith, Middle Manager, Technologist, and noting that three of the seven are required. Here the existing meeting parameters are presented by the meeting software in conjunction with the quorum module.
For the other quorum events Andrew defined the events by entering the particular event, here executable demonstration software (Demo Software), a particular PowerPoint™ document (one named “meeting10Oct05.ppt”), an agenda (not a particular one), and that a data-entry field in the agenda be filed out:
Also at arrow 1, all of these quorum events are received by quorum module 124. At arrow 2, the quorum module builds a quorum for the meeting. Here the quorum events are arranged into participants 128, resources 130, and others 132, all of which are shown in
To do so, the quorum module adds an XML element “<quorum>” to a conference/meeting description element “<conference-description>”, which references all of the quorum events in the quorum. This quorum element contains a list of references (e.g., XPath expressions) referring to invitees (e.g., with elements named “<users>”) or resources and others (e.g., both with elements named “<resources>”).
At arrows 1 through 6, Andrew, Bill, and Eugene join the meeting hosted by the MCU server. Here doing so involves (through their devices and the meeting software) sending an invite, receiving an okay, and sending an acknowledgement in response to the okay. Here it also involves subscribing to the meeting through a subscription protocol (at arrows 2, 4, and 6).
When Andrew joins, two of the quorum events of the example in
Participants:
Resources:
Others:
The two met when Andrew joins include the one requiring that a technologist participate (here only Andrew qualifies) and the one requiring the meeting time of 11 a.m. on Oct. 10, 2005. As Andrew joined at 11:01 a.m., these two quorum events are met. These are marked in italics above.
The quorum module may indicate to Andrew or any non-participating invitees (or others) that two of the quorum events are met and/or which are still needed. This can be through the meeting software (to Andrew) or through other manners, such as an email to the other invitees. While not shown in the graph, here the quorum module interacts with an email server (e.g., Microsoft® Outlook™) to send emails to all of the other invitees telling them that Andrew has joined and which quorum events are still needed for the meeting to productively start. This may be useful in reminding other invitees about the meeting and what they may need to upload or other actions needed to meet the quorum.
When Bill joins at arrows 3 and 4 and Eugene joins at arrows 5 and 6, three more quorum events are met. These are also marked with italics in the example quorum below:
Participants:
Resources:
Others:
When Bill joined, the “one middle manager” quorum event is met as both he and Steve Phaka are defined as being of that class of participant. When Eugene joined, the quorum event requiring that he specifically be participating was met. A third quorum event is also met, that of having three of the seven invitees present (Eugene represents the third invitee to participate). In this case this quorum event is redundant, as Bill or Steve, Eugene, and Andrew are all needed anyway. In many other cases it would not be redundant (e.g., requiring four participants).
At arrows 7 and 8 Andrew uploads various resources to the meeting software on the server. Andrew uploads the demo software, the PowerPoint™ document, and the agenda. These three uploads meet all of the resource quorum events, as noted above, but one last quorum event may still be needed. Here company policy requires that the Goal Field in the agenda be filled out and thus, that every meeting quorum has this filled out if that meeting has an agenda in its quorum. Here Andrew added a quorum event requiring this field to be filled out when he added an agenda to the quorum, though not explicitly.
At this point the quorum module analyzes the agenda to determine if that data-entry field is void or not. If not, the quorum event is met. The quorum module may do so in manners known in the art, such as by parsing a hierarchical data tree (e.g., eXtensible Markup Language data tree) for the agenda to find out if a node of the tree related to the data-entry field is null or filled out. The quorum module determines that this field is filled out with “Rundown of Software Bugs Found in Beta Testing” (not shown).
At arrows 9, 10, and 11, the quorum module (here through the software on the server) notifies each of the participants that the meeting has productively started. Andrew, Bill, and Eugene now know to focus on the meeting. The notification here is either through an audio indicator generated by each participant's device voicing: “Eleven AM meeting is now ready to start” and a visual indicator generated by each device's client application 202 flashing its meeting user interface or visual and audio indicators similar to those currently used to alert persons about a newly received email or instant message. The quorum module may also notify other invitees, such as Steve Phaka, Cate Stephens, Sylvia Turney, and Donny Barrett (see
The above section describes manners in which the tools may act to notify participants of a real-time, collaborative electronic meeting arranged in a central communication topology that a meeting is productively starting. Below these and other embodiments of the tools are provided that may be implemented in a centralized, distributed, or combined communication system.
These exemplary embodiments are described as part of two processes 600a and 600b of
These processes 600a and 600b are separated by a dashed line through which remote entities communicate over a communication network, such as network 114 of
Prior to or concurrent with block 602, someone sets up the meeting. This person may set up the meeting by deciding when it starts, who is invited (i.e., the permitted participants), uploading documents or noting documents that are desired to be uploaded at some point, and uploading an agenda or template for an agenda to be filled out later. In response the tools may send an email to those people that are invited, which may include a hyperlink to join the meeting or otherwise interact with the meeting software (e.g., by uploading a document). Parameters used in setting up the meeting may also be quorum events, as noted above.
At block 602 a person defines one or more quorum events. These quorum events are those that must occur for a real-time, collaborative electronic meeting to productively start. The person may define the quorum events by entering them or with indicia of already listed events, for example. Events recorded for a meeting, such as a list of all invitees or to-be-uploaded documents, for example, may be defined as quorum events by selecting indicia associated with these events. The person may also indicate which quorum events are to be exposed to the participants. Thus, the person may indicate that participants or invitees (or some of them) should be notified about some quorum events not having been met but not others. Andrew in the above example in
Quorum events may include, by way of example: a particular person of a set of persons permitted to participate in the meeting; a number of persons participating in the meeting of the set of persons permitted to participate in the meeting; a person of a class of persons permitted to participate in the meeting; a particular document or type of document (e.g., an agenda for the meeting); and a scheduled meeting time of the meeting, to name just a few. Note some examples of these quorum events are mentioned in the above exemplary embodiments, such as a particular person (“Eugene Smith”), a person of a class of persons (one middle manager of two possible middle managers), or a particular document (the demo software or the PowerPoint™ document).
Block 604 receives one or more quorum events. In the illustrated example of
Block 606 builds the quorum. This quorum comprises quorum events and is usable to later notify persons that a meeting is productively starting or has productively started. The tools may build the quorum using the quorum module, such as in manners described in the illustrated examples above. The tools may later use the quorum during a realtime collaborative electronic meeting to determine when all of the quorum events have occurred.
At block 608 a person or entity causes an event to occur. For example, a person may join the meeting or upload a document. Or an entity may indicate that a meeting time is met (e.g., a clock).
Block 610 receives an indication that the event has occurred. This indication may be direct or indirect, such as when the quorum module receives an indication from the meeting software that a person permitted to participate in a meeting is now participating. Blocks 610, 612, 614, 616, and/or 618 may, in some embodiments, be performed automatically and without user interaction. Once an event has occurred, the tools may act to automatically notify participants when the quorum is met (or is not met).
Block 612 determines if an event is a quorum event. If it is not, the tools wait to receive another event and thus proceed to block 608. If it is, the tools proceed to block 614. Block 612 may compare the event to quorum events in the quorum. For example, if instead of Bill joining at arrows 3 and 4 of
Block 614 determines if all of the quorum events of the quorum are met. If they are not, the tools proceed to block 616 (and/or 608). If they are met, the tools proceed to block 618. The tools may keep track of prior quorum events met and know which events are remaining. If the last remaining quorum event is met, then the quorum is complete. In the illustrated example above, the last quorum event met was a data-entry field not null in an agenda.
Block 616 notifies participants and/or others that a quorum event has occurred and/or that other quorum events are still needed. For the embodiments of
Participants:
Resources:
Others:
The tools may also notify at regular intervals (e.g., every five minutes), when a person joins, or when a person or entity inquires. Following block 616, at block 620 a person or entity receives the notification from the tools, such as the above listing of quorum events met and not met.
Block 618 notifies participants and/or others that the meeting has productively started or is ready to productively start. The notification may be through a user interface associated with the meeting, such as through audio or visual manners noted in the example corresponding to
At block 622 the person or entity receives the notification that the meeting has productively started.
The above-described tools enable participants in a real-time, collaborative electronic meeting or other persons or entities to know when the meeting productively starts. The tools may do so in various types of communication topologies and permit participants of a meeting, for example, to focus on things other than the meeting until the meeting productively starts. Although the tools have been described in language specific to structural features and/or methodological acts, it is to be understood that the tools defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the tools.
