Browse Prior Art Database

Enterprise Meeting Notice Architecture

IP.com Disclosure Number: IPCOM000107976D
Original Publication Date: 1992-Apr-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 9 page(s) / 298K

Publishing Venue

IBM

Related People

Keller, RS: AUTHOR [+4]

Abstract

Disclosed here is a mechanism for calendaring systems to exchange documents through mail such that when a meeting is created, deleted, or changed on any of the participating calendaring systems, it can generate a meeting notice that can be interpreted unambiguously by any of the other participating calendaring systems. ARCHITECTURE OVERVIEW

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 35% of the total text.

Enterprise Meeting Notice Architecture

       Disclosed here is a mechanism for calendaring systems to
exchange documents through mail such that when a meeting is created,
deleted, or changed on any of the participating calendaring systems,
it can generate a meeting notice that can be interpreted
unambiguously by any of the other participating calendaring systems.
      ARCHITECTURE OVERVIEW

      This invention is called the Enterprise Meeting Notice
Architecture - Type 1.  By defining a common architecture, all
systems participating in the architecture will be able to
unambiguously and efficiently exchange information about meetings.

      The architecture defines self-defining structures (stored in
the document content portion of the document) that describe the
request that the meeting notice represents, the calendars (people and
resources) that are invited to the meeting, the dates and times of
the meeting, and the details of the meeting (i.e., the subject,
place, purpose, security, etc.)

      The requests that are supported by the architecture are:
      -  Add a new meeting(s) to the system
      -  Change information about an existing meeting
      -  Delete an existing meeting
      -  RSVP to a meeting

      To RSVP to a meeting notice means that the invitee to the
meeting has the ability to respond to the meeting notice and indicate
whether or not he/she is attending the meeting. This capability is
not allowed by current office systems. The RSVP document will also
comply with this architecture and will be represented with the same
structures that are used for any other meeting notice request.

      The structures that make up the document content are:
      -  Request (information about the function that the meeting
notice is representing)
      -  Item (information about the meeting that applies to all
occurrences of the meeting)
      -  Text list (all text that is associated with the meeting,
such as subject, place, purpose, purpose text not added to the
calendar, etc.)
      -  Invitee list (all invitee that are invited to the meeting;
this structure also supports an invitee RSVPing to a meeting with an
indication of whether the invitee is going to attend the meeting or
not)
      -  Time list (a list of the occurrences of this meeting)
      -  Resource list (a list of the resources that will be needed
to hold the meeting, i.e., projectors, conference rooms, etc.)
      ARCHITECTURE GOALS

      The goal of this architecture is primarily to provide
information in the document content such that, when a meeting is
created, deleted, or changed on any of the participating calendaring
systems, it can generate a meeting notice that can be interpreted
unambiguously by any of the other participating calendaring systems.

      To meet this goal, this architecture will provide the
following:
      -  Define the structures...