JP4851515B2 - Distributed conference scheduling - Google Patents

Description

  The technologies described herein are generally aimed at communication systems, and more specifically, techniques for distributed conference scheduling.

  With the richness of computers and the advent of the Internet, real-time conversations between conversation participants via computer systems are becoming increasingly popular, particularly with the maturation of the World Wide Web (Web). These conversations take place virtually on a computer network and are therefore replacing the traditional face-to-face meeting.

  Web conferencing applications are increasingly being used to conduct these virtual meetings. As a typical example, a person who wants to conduct a meeting, also called a “presenter” in the meeting, schedules a meeting with a conference server that hosts the conference application that provides the conference service. ing. The conference server includes, among other components, a reservation system and a data store. When a person schedules a meeting with a conference server using a client application, the booking system coordinates the scheduling of the requested meeting and stores all meeting-specific data in the data store To do. Meeting-specific data includes meeting or conference scheduled times, attendee lists, privileges and rules, services requested during the scheduled meeting period (eg white boarding, audio / video, document sharing, etc. ) And other information. A disadvantage of conventional conferencing servers is that as the use of these virtual meetings continues to increase, the required reservation system has become more complex and the data store has become larger and larger.

  What is desired is a technique that allows scheduling, changing, and deleting virtual meetings without having to save meeting-specific information in a central store.

  When using a conference room endpoint facility (sometimes referred to as a “function”, “conference room endpoint”, or “meeting endpoint”), users receive conference-specific data. Conference room endpoint that allows you to schedule conferences directly (sometimes referred to as "meetings" below) and manage scheduled meetings asynchronously without having to save them in the central store Provides functionality. For each scheduled meeting, the meeting data is stored locally with each invited meeting attendee. At the time of joining a scheduled meeting, each participant presents their copy of the meeting data to the conference room endpoint function. The conference room endpoint function checks the validity of the meeting data and, after finishing the validity check of the meeting data, allows the proposed meeting participant to enter the meeting.

  In some embodiments, the meeting endpoint is implemented as a component of a conferencing server, where a meeting organizer schedules the meeting and authorized meeting attendees join the scheduled meeting. It has logic to authenticate and authorize. For example, a conference organizer who wants to schedule a conference can send a request to schedule the conference to the meeting endpoint using the client. The client also sends conference specific details to the endpoint. Upon receiving the request, the meeting endpoint places the conference specific details in a “blob”, also called a token. The meeting endpoint then signs the token and sends the signed token back to the client.

  In response, the conference organizer can send or forward the token along with the meeting invitation to all conference attendees. In some embodiments, the conference organizer uses a traditional calendaring software application, such as MICROSOFT OUTLOOK®, to communicate with the meeting endpoint and invite conference attendees. You can also. By incorporating communication with the meeting endpoint into the calendaring software application, communication from the end user can be abstracted.

  Each person (inviter) invited to the conference receives a meeting invitation and token from the conference organizer. In order to attend or attend the conference, each invitee presents a token to the meeting endpoint. Upon receiving the token, the meeting endpoint opens the token and checks the validity of the invitee who submitted the token. After completing the validity check of the invitee who submitted the token, the meeting endpoint allows the invitee to enter the conference as an attendee.

  In some embodiments, the meeting endpoint uses a “waiting area” such as a lobby to wait for an invitee if the designated conference has not yet begun. For example, a conference can start when a conference organizer or a participant nominated by the organizer joins the conference. When an invitee presents a token before the conference starts, the meeting endpoint places the invitee in a waiting area until the designated conference starts. When the designated conference starts, the meeting endpoint allows the invitee, for example, to enter the conference as an attendee.

  FIG. 1 is a block diagram illustrating selected components that are typically incorporated into at least some of the computer systems capable of implementing various embodiments of meeting endpoints. These computer systems 100 include one or more central processing unit CPUs 102 for executing computer programs, computers that store programs and data (including data structures) during their use. A memory 104, a persistent storage device 106 that permanently stores programs and data, such as a hard drive, and a program and data stored on a computer-readable medium, such as a CD-ROM drive Computer readable media drive 108 and network connection 110 for connecting the computer system to other computer systems, such as over the Internet, and for exchanging programs and / or data (including data structures). It can be equipped. As will be appreciated, the computer system 100 can be one or more display devices that display the output of the program, such as a video monitor or LCD, and a pointing device such as a keyboard, microphone, or mouse. It is also possible to equip one or more input devices for receiving user input.

  Embodiments of meeting endpoints include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, the above systems or It can be implemented in various operating environments including a distributed computing environment including any of the devices. The computer system can be a cell phone, personal digital assistant, smart phone, personal computer, programmable consumer electronics, digital camera, and the like.

  A meeting endpoint can be described in the general context of computer-readable instructions executed by computer system 100 or other device, such as a program module. In general, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Memory 104 and persistent storage 106 are computer readable media that may contain instructions that implement a meeting endpoint. As will be appreciated, the memory 104 and persistent storage 106 can contain a variety of other content in addition to the instructions for implementing the meeting endpoint.

  FIG. 2 is a block diagram illustrating an environment in which a meeting endpoint can operate. As shown, the environment includes a conferencing server 202 coupled to a plurality of clients 204 through a network 206. As used herein, the terms “connected”, “coupled”, or various expressions thereof, are either direct or indirect. Regardless, it means any connection or coupling between two or more elements, and the coupling of connections between these elements can be physical, logical or a combination thereof.

  In general, a conference server provides a conference service such as audio, video, data sharing, white boarding, and instant messaging. As shown in FIG. 2, the conference server includes a conference application 208 and a meeting endpoint 210. The conference application is a “host” for a conference session such as a virtual meeting and provides conference services to conference or meeting participants. The meeting endpoint acts as an authentication authority that authenticates and authorizes meeting organizers and attendees to schedule and attend meetings. In some embodiments, meeting endpoints issue and authorize tokens containing meeting specific information, and these tokens are distributed to clients to achieve decentralized conference scheduling and management.

  In general, a client is an application that connects to and provides access to a conference server, particularly a meeting endpoint. These applications utilize the various components of the conference server to perform the provided conference operations. In operation, a user connects to a conference server using a client and utilizes services provided by the conference server. For example, the client can be a web browser application or calendaring application, such as MICROSOFT OUTLOOK®, suitable for connecting to and communicating with a conference server and meeting endpoint. It can also be other interface applications.

  A network is, for example, a communication link that facilitates the transfer of electronic content between connected computers. In one embodiment, the network includes the Internet. As will be appreciated, a network can be one or more types, such as a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, etc. Network.

  In the following description, various embodiments of the meeting endpoint will be described in detail in connection with various example diagrams. As will be appreciated, embodiments of the meeting endpoint may be used in situations that differ significantly from these examples in various respects.

  FIG. 3 is a diagram illustrating elements of a master token 300 according to some embodiments. The meeting endpoint creates a master token that contains conference specific information for each scheduled conference. As shown in the figure, the conference-specific information stored in the master token includes a meeting ID 302, a meeting-specific information 304, a list of attendees and permissions 306, a start time 308, an end time 310, a meeting password 312, and recurrence information (recurrence information). ) 314 and a master token timestamp 316.

  The meeting ID is a unique identifier that identifies the meeting represented by a particular master token. Meeting-specific information includes the name of the meeting, a brief description of the meeting, a list of services requested for the meeting (eg, audio, video, data sharing, whiteboard, instant messaging, etc.) and others related to the meeting Can be specified. The list of attendees and permissions shows the list of people (eg, attendees) who are allowed to attend and participate in the meeting and the roles and permissions of attendees (if any). The meeting organizer can assign roles and permissions to one or more attendees in the list who are allowed to join the meeting when scheduling and / or modifying the meeting. For example, at the time of scheduling a meeting, the meeting organizer may grant only “forward” permission to one or more attendees in the list. Attendees with this permission are allowed to forward the meeting request to other meeting attendees, ie invite additional participants to the meeting. Similarly, the meeting organizer can grant “change conference” permission to one or more attendees in the list. Attendees with this permission are allowed to modify the scheduled meeting. The meeting organizer can also assign roles (eg, presenters, attendees, etc.) to attendees in the list.

  The start time indicates the time when the meeting is scheduled to start. The end time indicates the time when the meeting is scheduled to end. The meeting password is optional and, when present, specifies the password required to obtain permission for the meeting. For example, a meeting organizer may specify a password to schedule and conduct a secure, password-protected meeting when scheduling and / or modifying a meeting. The meeting endpoint requires the attendee to provide a password with the master token to join the meeting. In some embodiments, the meeting endpoint encrypts the password before placing the password in the master token. In some embodiments, the meeting password can be a password hash.

  The repeat information is arbitrary and, when present, specifies that the meeting schedule is repeated. For example, a meeting organizer can schedule a meeting that repeats over a period of time (eg, every Friday from 10 am to 11 am), and the meeting endpoint specifies the repeating schedule in the recurring information . The master token time stamp indicates the time when the meeting endpoint created the master token. The meeting endpoint uses the contents of the attendee list and the master token timestamp to allow attendees to enter the meeting. In some embodiments, in addition to being included in the attendee list, the meeting endpoint may include a timestamp (contained in a token submitted by the meeting organizer or other meeting attendees authorized to start the meeting ( Meeting only those attendees who have submitted a token that contains a time stamp that is the same as either the master token time stamp or the forward token time stamp (for example, either the master token time stamp or the forward token time stamp) Allow to enter. The transfer token and transfer token time stamp will be described in detail below.

  In some embodiments, the meeting endpoint uses timestamps to prevent possible misuse of old tokens. For example, when a person presents an old token, the meeting endpoint initiates a meeting attendee (eg, a meeting organizer or meeting) with a new token (ie, a token whose timestamp is after the old token's timestamp). The person can be left in the meeting waiting area until the other attendees who are allowed to join or start the meeting. At that point, the meeting endpoint can take appropriate action on the person who submitted the old token. For example, the meeting endpoint can remove the person who submitted the old token from the waiting area. In other embodiments, the meeting endpoint allows one or more people who submitted the old token to attend the meeting specified by the old token.

  As will be appreciated by those skilled in the art, one or more of the above-described elements are omitted from the master token. Furthermore, the master token can include other elements than the above-described elements.

  FIG. 4 is a diagram illustrating elements of a transfer token 400 according to some embodiments. The meeting endpoint creates a transfer token that is used by authorized meeting attendees to invite other participants to the scheduled meeting. As shown, the transfer token includes a master token and transfer information 402, and the transfer information includes a list of attendees 404 to be transferred and a transfer token timestamp 406. The transferred attendee list shows a list of additional attendees who are allowed to join the meeting. The transferred list of attendees, if any, can also identify additional attendee roles and permissions. The transfer token time stamp indicates the time when the meeting endpoint created the transfer token. The transfer token time stamp indicates a time after the master token time stamp. In the case of transfer tokens, in addition to being included in the list of attendees to be transferred, the meeting endpoint may: (1) store a transfer token time stamp after the master token time stamp stored in the transfer token. Contains a transfer token, and (2) a master token time stamp that is the same as the master token time stamp contained in the token submitted by the meeting organizer or other attendee authorized to initiate the meeting Allow attendees who have submitted a transfer token to enter the meeting. The meeting endpoint can create a transfer token for the scheduled meeting by appending the transfer information to the master token corresponding to the scheduled meeting.

  In some embodiments, the meeting endpoint signs a token (ie, a master token and a transfer token) using a symmetric key and then submits the token to, for example, a conference organizer or Return it. By signing the token, the meeting endpoint can, for example, have created and issued the token originally when the token was submitted with a request to join the meeting, and the token has been modified. It can be verified that there is not. The meeting endpoint can periodically refresh the key used to sign the token. In some embodiments, the meeting endpoint can encrypt the token using any of a variety of well-known encryption techniques. The meeting endpoint can also encrypt other information contained in the token. For example, the meeting endpoint can encrypt a meeting password (or password hash) for a password-protected meeting.

  FIG. 5 is a diagram illustrating an interaction between an end user and a meeting endpoint to schedule and join a meeting according to some embodiments. By way of example, user A uses a client to send a request to the meeting endpoint to schedule a meeting with user B as an authorized attendee (stage 1). User A has other meeting-specific information such as the time of the meeting, the duration of the meeting, the conferencing service requested for the meeting, any password if the meeting is password protected, any role or permission, etc. Can be sent to the meeting endpoint. The meeting endpoint checks to determine if the meeting can be scheduled as requested. If the meeting can be scheduled, the meeting endpoint creates a master token for the requested meeting, signs the master token, and returns the signed master token to user A (stage 2).

  Upon receiving the master token, user A sends an invitation to attend the meeting and a master token to user B (stage 3). For example, user A sends an email to user B with a master token as an attachment and invites user B to attend the meeting. If the meeting is password protected, User A can call or otherwise communicate the required password to the user. In other embodiments, user A may have other forms of communication, such as instant messaging, telephone, face-to-face, text messaging, and other forms of in-band and out-of-band (out-band). User-B can be invited to attend the meeting using of-band communication. User A can give a master token when inviting user B, or can give a master token to user B in another communication. In some embodiments, User A can publish this token at a well-known location, so that when publishing, anyone can go to that well-known location and join the meeting using the token. This is convenient when used in a “public meeting”. For example, if a marketing wants to demonstrate the characteristics of a product at a meeting, it may want to allow everyone interested to participate. In this case, the token can be flagged to indicate that anyone who presents the token is allowed to join the meeting. For example, when user A requests to schedule a meeting, user A requests to incorporate this feature, eg, this flag.

  At about the time of the scheduled meeting, User B uses the client to present the master token to the meeting endpoint and request to join the meeting (stage 4). The meeting endpoint opens a master token and verifies that User B is on the attendee list and is therefore allowed to join the requested meeting (stage 5). The meeting endpoint checks to determine if the requested meeting has already started, that is, whether the meeting is in progress. If it is determined that the requested meeting has not yet started, the meeting endpoint allows user B to enter the designated waiting area of the requested meeting (step 6).

  In other embodiments, for example, in an embodiment where no waiting area is provided, the meeting endpoint allows user B to enter the requested meeting. In some cases, User B may be the only participant in this meeting if there are no other attendees requesting to join this meeting. For example, the meeting organizer (user A) may have changed the meeting, for example, by removing user B from the meeting attendee list and obtained a new master token with a new meeting ID. Here, the person with the master token with the old meeting ID can still participate in the specific meeting, but is in a different meeting from the person who received the new master token. Therefore, if user A removes user B from the meeting and redistributes new tokens to users C and D when joining, users A, C and D will join the meeting with one meeting ID, User B will be in the meeting with the old meeting ID, all of which will be done by himself. Therefore, even if User B obtains a master token illegally and gets permission to the meeting, as a result of the meeting organizer changing the meeting, it acquires a new master token with a new or different meeting ID, As long as the desired attendee is notified of the change, that is, as long as a new master token is issued to the desired attendee, the security of the meeting is not compromised.

  User A then uses the client to request to join the meeting by presenting the master token to the meeting endpoint (stage 7). The meeting endpoint opens a master token and verifies that user A is included in the attendee list and is therefore allowed to join the requested meeting (stage 8). The meeting endpoint also determines that user A is a meeting organizer, for example, from the assigned role, and starts the requested meeting (stage 9). The meeting endpoint checks the waiting area and determines that User B is waiting for the meeting to start. The meeting endpoint verifies that User B's master token time stamp is the same as User A's (eg, the meeting organizer) master token time stamp and allows User B to enter the meeting from the waiting area. To do.

  In other embodiments, the meeting endpoint can authenticate a user requesting to join the meeting, eg, an attendee, to verify that the user is the intended person. For example, the meeting endpoint can use any of a variety of well-known authentication techniques, such as Kerberos, to verify that the user is the intended person and not a fraudster. Alternatively, authentication specific information can be stored in a token.

  In one embodiment, if token size is an issue, the token signature can be distributed and stored by the client. The client can then create a token upon joining, for example, and present the created and signed token along with the signature to the meeting endpoint. In response, the endpoint validates the token for validity by matching the token against the signature. In some embodiments, tokens can be compressed using any of a variety of well-known compression techniques.

  As will be appreciated by those skilled in the art, in the above and other processes, interactions and methods disclosed herein, the functions performed in these processes, interactions and methods are in a different order. Can be realized. Furthermore, the steps outlined are merely exemplary, and some of these steps can be optional, combined to reduce or increase steps, without departing from the essence of the invention. It is.

  FIG. 6 is a diagram illustrating an interaction between an end user and a meeting endpoint to obtain a transfer token in accordance with some embodiments. By way of example, User A uses a client to send a request to a meeting endpoint to schedule a meeting with User B, User C, and User D as authorized attendees, where the user D is allowed to invite other attendees to the meeting (stage 1). In response, the meeting endpoint checks to determine if the meeting can be scheduled as requested, and if the meeting can be scheduled, the meeting endpoint determines the master token for the requested meeting. Is signed, the master token is signed, and the signed master token is returned to the user A (stage 2).

  Upon receipt of the master token, user A sends an invitation to attend the meeting and a master token to each of users B, C and D (stage 3). Later, when user D wants to invite another attendee, ie, user E, to the meeting, user D presents the master token to the meeting endpoint, and user E is allowed to attend the meeting. Request to be included (stage 4). The meeting endpoint opens a master token and verifies that user D is allowed to invite other attendees to the meeting, for example from the attendee and role list (stage 5). The meeting endpoint creates a transfer token for the requested meeting, signs the transfer token, and returns the signed transfer token to user D (stage 6). In some embodiments, the transfer token indicates that user E is an authorized attendee for the meeting, for example in the transferred attendee list. In other embodiments, the transferred attendee list in the transfer token may indicate all authorized attendees of the meeting, for example, User A, User B, User C, User D, and User E. it can.

  Upon receipt of the transfer token, user D sends an invitation to attend the meeting and a transfer token to user E (stage 7). Then, for example, at approximately the time of the scheduled meeting, each of users A, B, and C can present a master token to the meeting endpoint and request to join the meeting with user D Each of E can present a transfer token to the meeting endpoint and request to join the meeting.

  FIG. 7 is a diagram illustrating an interaction between an end user and a meeting endpoint to change a scheduled meeting in accordance with an embodiment. By way of example, user A uses a client to send a request to a meeting endpoint to schedule a meeting with user B, user C, and user D to a meeting endpoint, where user A is allowed to change the meeting (stage 1). The meeting endpoint checks to determine if the meeting can be scheduled as requested, and if the meeting can be scheduled, the meeting endpoint creates a master token A for the requested meeting; The master token A is signed, and the signed master token A is returned to the user A (stage 2).

  Upon receiving master token A, user A sends an invitation to attend the meeting and master token A to each of users B, C, and D (stage 3). Later, when user A wants to change the scheduled meeting, user A presents master token A to the meeting endpoint and decides to change the scheduled meeting, ie, the meeting represented by master token A. Request. Specifically, User A deletes User D as an authorized attendee and requests to change the scheduled meeting to include User E as an authorized attendee of the meeting (stage 4). ). The meeting endpoint opens master token A and verifies that user A is allowed to change the meeting, for example from attendees and role lists. After verifying that User A is authorized to change the meeting, the meeting endpoint creates a new master token B for the changed meeting, signs master token B, and signs the signed master token. B is returned to user A (stage 5). Upon receiving master token B, user A sends an invitation to attend the changed meeting and master token B to each of users B, C and E (stage 6). User A can notify users B, C, and E that a previously scheduled meeting has changed. User A can also notify user D that the originally scheduled meeting represented by master token A has already been canceled and will not be conducted.

  Then, for example, at approximately the time of the scheduled meeting, each of users A, B, C, and E can present the master token B to the meeting endpoint and request to join the meeting. . If user D presents master token A to the meeting endpoint and requests to join the meeting, i.e., the meeting represented by master token A, the meeting endpoint is that user D is the only participant You can create a meeting that is Here, user D is represented by a meeting different from the meeting represented by user A, B, C, and E, ie, the meeting represented by master token B, ie, master token A. Placed in a meeting.

  For example, in other embodiments where the meeting endpoint uses a waiting room, user D can be placed in the waiting room. The meeting endpoint can later remove user D from the waiting room if, for example, the requested meeting does not start within a predetermined amount of time.

  As will be appreciated by those skilled in the art, the role or authority of meeting changes is not limited to meeting organizers, but can be granted to any one or more authorized meeting attendees.

  In some embodiments, the meeting endpoint may maintain a limited data store to provide some resource management and reservation-based booking. For example, the meeting endpoint may store free / busy information to avoid “double booking” of the meeting in one time slot. In another example, the meeting endpoint can store configuration information, such as bandwidth optimization, network traffic, and the like. For example, a conference server administrator can configure a conference server to conduct up to 10 meetings at any time, or to have up to 100 attendees at any given time. . The meeting endpoint can store this configuration information in its data store to verify that the conferencing server is operating according to that particular configuration.

  In some embodiments, the use of the meeting endpoint function facilitates the integration of various calendaring functions. For example, using this function, it is possible to incorporate a “propose new time” function, such as MICROSOFT OUTLOOK (registered trademark), which is provided in calendaring applications. This can be simply incorporated into this feature as a meeting change request, and all attendees will be granted permission to propose a new time for the scheduled meeting by default.

  As will be appreciated by those skilled in the art, the number of users shown in the above example of interaction, for example, the number of meeting attendees, has been simplified and facilitated solely to explain the actual number of meeting attendees. Without limitation, the number of meeting attendees can vary. Also, as will be appreciated by those skilled in the art, the number of transfer token requests and / or meeting changes shown in the above example of exchange are simply simplified and facilitated and may be performed. Without limiting the number of transfer token requests and / or meeting changes, the number of transfer token requests and / or the number of meeting changes can be different.

  As will be understood from the above description, the embodiments of the present invention have been described for the purpose of illustration, and various modifications can be made without departing from the spirit and scope of the present invention. Accordingly, the invention is not to be restricted except in accordance with the elements explicitly recited in the claims.

FIG. 6 is a block diagram illustrating selected components that are generally incorporated into at least some of the computer systems that can implement various embodiments of the meeting endpoint. FIG. 6 is a block diagram illustrating an environment in which a meeting endpoint can be operated. FIG. 4 illustrates elements of a master token according to some embodiments. FIG. 4 illustrates elements of a transfer token according to some embodiments. FIG. 4 illustrates an interaction between an end user and a meeting endpoint to schedule and join a meeting according to some embodiments. FIG. 6 illustrates an interaction between an end user and a meeting endpoint to obtain a transfer token according to some embodiments. FIG. 6 illustrates an interaction between an end user and a meeting endpoint to change a scheduled meeting in accordance with some embodiments.

Claims (11)

A computer-readable recording medium having stored thereon computer-executable instructions , wherein the computer-executable instructions, when executed by a computer, cause the computer to perform a method for scheduling a meeting, the method comprising:
Receiving from the meeting organizer an initial request to schedule a meeting, the initial request having meeting-specific information specific to the meeting, wherein the meeting-specific information is Including a list of attendees and the attendee's authority to indicate whether the attendee can change the meeting-specific information ;
In response to receiving the initial request, generating an initial token corresponding to the meeting and including the meeting-specific information ;
Signing the first token;
Do not save the meeting-specific information to the computer, and sending back the first of the token, which is the signature to the organizer of the meeting,
Receiving a change request to change the meeting from attendees of the meeting, the change request including changed meeting-specific information and the first token;
Determining whether the received first token is signed;
Determining whether the attendee can modify the meeting with reference to the attendee's rights in the received first token;
Generating a modified token corresponding to the modified meeting if the first token is signed and it is determined that the attendee can modify the meeting, the modification comprising: A modified token includes the modified meeting-specific information included in the modification request;
Signing the modified token;
Returning the signed modified token to the attendee without saving the modified meeting-specific information to the computer;
Receiving a request to join including a token from an attendee requesting to join the meeting;
If the received token is the first token and the attendee is in the attendee list of the received token, the attendee joins the meeting specified in the first token. A step of allowing
If the received token is the modified token and the attendee is in the list of attendees of the received token, the attendance at the modified meeting specified in the modified token 're a step that allows to join, only attendees with the modified token, you can read the computer, characterized in comprising the steps that are allowed to participate in the altered meetings Recording medium.   2. The computer-readable recording medium according to claim 1, wherein the meeting specific information includes a meeting password. The computer readable recording medium of claim 1, allow the meeting specific information, at least one of the attendees in the list of the attendees to invite other attendees to the scheduled meeting A computer-readable recording medium characterized by indicating authorized to.   The computer-readable recording medium according to claim 1, wherein the meeting specific information includes a time stamp indicating a time when the token is generated.   The computer-readable recording medium according to claim 1, wherein the meeting specific information includes recurrence information. Computing system, a method of scheduling a meeting, the method comprising,
Receiving an initial request for scheduling a meeting from a meeting organizer, the initial request having meeting specific information specific to the meeting, wherein the meeting specific information is the attendance of the meeting A list of attendees and the attendee's authority to indicate whether the attendee can change the meeting specific information;
In response to receiving the initial request, generating an initial token corresponding to the meeting and including the meeting-specific information;
Signing the first token;
Returning the signed first token to the meeting organizer without saving the meeting-specific information to the computing system;
Receiving a change request to change the meeting from attendees of the meeting, the change request including changed meeting-specific information and the first token;
Determining whether the received first token is signed;
Determining whether the attendee can modify the meeting with reference to the attendee's rights in the received first token;
Generating a modified token corresponding to the modified meeting if the first token is signed and it is determined that the attendee can modify the meeting, the modification comprising: A modified token includes the modified meeting-specific information included in the modification request;
Signing the modified token;
Returning the signed modified token to the attendee without saving the modified meeting-specific information to the computing system;
Receiving a request to join including a token from an attendee requesting to join the meeting;
If the received token is the first token and the attendee is in the attendee list of the received token, the attendee joins the meeting specified in the first token. A step of allowing
If the received token is the modified token and the attendee is in the list of attendees of the received token, the attendance at the modified meeting specified in the modified token Allowing a participant to join, wherein only attendees with the modified token are allowed to participate in the modified meeting. how to. The method of claim 6, wherein the meeting specific information, wherein the containing meeting password required to participate in the meeting. 7. The method of claim 6 , wherein the meeting specific information includes a time stamp indicating the time when the token was generated . The method of claim 6, wherein the meeting specific information, wherein in that it comprises at least one service that is required for the meeting. 7. The method of claim 6 , wherein the meeting specific information includes IDs of attendees allowed to invite other participants to the meeting . 7. The method of claim 6 , wherein the meeting specific information includes IDs of attendees authorized to change the meeting .

Images