 |
Description  |
|
|
FIELD OF INVENTION
This invention relates in general to electronic calendaring methods, which
provide a reminder at a predetermined time prior to the scheduled time of
a calendared event and in particular to a method in which the remainder
"floats" with the calendared event.
CROSS-REFERENCES TO RELATED APPLICATIONS
1. Co-pending application Ser. No. 008,033 filed concurrently herewith,
entitled "Method For Developing Automatic Replies in an Interactive
Electronic Calendaring System," and assigned to the assignee of the
present application is directed to an electronic calendaring method in
which a calendar owner can respond automatically to requests for
participation in events being calendared by another person. The nature of
the reply is based on an analysis of the parameters set forth in the
request and an algorithm employing a set of prioritized criteria that the
calendar owner has established to provide the automatic response.
2. Co-pending application Ser. No. 008,034 filed concurrently herewith,
entitled "Method For Concurrently Displaying Entries From a Plurality of
Different Electronic Calendars Based on Interactively Entered Criteria,"
and assigned to the assignee of the present application is directed to an
electronic calendaring method in which a calendar owner can display a set
of calendar entries which have been selected based on one or more
criteria, from different calendars within a time span that has been
established by a calendar owner who is requesting a specific "view" of
calendars on the systems.
3. Co-pending application Ser. No. 008,249 filed concurrently herewith,
entitled "Method For Automatically Reconciling Entries on Two Copies of
Independently Maintained Electronic Calendars," and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner who keeps a detached personal copy of his
master calendar can automatically reconcile the calendar entries that have
been made independently on each calendar since the reconciliation, and
interactively resolve any calendar event conflicts.
4. Co-pending application Ser. No. 008,038 filed concurrently herewith,
entitled "Electronic Calendaring Method Which Provides for Automatic
Assignment of Alternates In Requested Events," and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner, who receives a request to participate in
a calendared event originated by another calendar owner, can assign an
alternate to the event that will be designated in the automatic response
which reflects the assignment of an alternate to the event. The assignment
of the alternate is based on the relationship of the information that
accompanies the request and criteria that the calendar owner has
pre-established for each potential alternate.
5. Co-pending application Ser. No. 008,036 filed concurrently herewith for
Cree, et al, entitled "Electronic Calendaring Method for Automatic
Confirmation of Resource Availability During Event Calendaring," and
assigned to the assignee of this application is directed to an electronic
calendaring method in which a calendar owner, when calendaring an event
such as a meeting, which requires, in addition to a meeting room, such
resources as a projector, video conferencing equipment, etc.,
automatically receives confirmation that the requested articles are
available and reserved for the calendared meeting event.
BACKGROUND ART
The prior art has disclosed a number and variety of interactive electronic
calendaring systems and method. The objective of all of these systems is
primarily to assist the person who, for a number of different reasons,
maintains a calendar of future events containing various information about
the events at entry points on the calendar which relate to the time of the
event.
The increase of personal computers and intelligent workstations in recent
years has made it possible for calendar owners to establish and maintain
these calendars on these interactive type data processing systems. Hence,
the term "electronic calendaring systems."
Two general types of interactive electronic calendaring systems have thus
evolved in the art. In one type of calendaring system, the owner of the
calendar is generally also the user of the workstation and that
workstation is generally not part of a larger network. Generally, in these
type of systems, the calendar function involves presenting a screen to the
user which represents a day calendar format divided into a number of time
periods. Each period is capable of displaying a limited amount of text
that the user enters. In some systems, the day calendar can scroll
vertically to present more time periods and/or horizontally to permit
longer text entries. The operator can "page" forward or backward and, in
most arrangements, can display a requested date. These calendaring methods
generally do not limit the type of event that is calendared nor the
terminology employed at any of the entry points and, to that extent,
function in the same manner as conventional manner calendars or
appointment books.
Electronic calendars do possess an advantage over manual entry calendars,
however, in that the calendar owner can, in many systems, enter an alarm
type entry which places a reminder message on the display screen at a
predetermined time and date. The message may also be accompanied by an
audio signal in order to get the user's attention. In most cases, the
message is a reminder of some subsequent calendared event that the
calendar owner has entered.
Another advantage of the electronic calendaring systems is that they often
permit the calendar owner to scan a large number of calendar entries
covering an extended period of time to find a specific defined entry. This
latter function is achieved generally in a manner of seconds.
In general, while this type of electronic calendaring system is an
improvement over the manual approach to maintaining a calendar, it does
have its limitations. For example, the alarm function, when it is used as
a reminder, is completely independent of the event for which the alarm is
established. As a result, if the event is cancelled or the time of the
event is changed, then a new alarm entry must be created by the user, and
the old entry deleted or moved.
The other type of calendaring arrangement that has developed in the prior
art involves multi-user environments having a large number of terminals or
workstations which are generally part of a larger communication network
that has been established to permit the users to interact with each other
and with data maintained on the system. In this environment, a user at a
terminal or workstation can send a message to one or more of the other
users on the network and is notified when the addressee has received and
read the meassage. In most of these environments, each user generally
maintains a calendar, and in many of these environments the reason for the
system interconnections among workstations is dictated by the need of
these users to interact. Further, the nature of such interaction generally
involves reference to respective calendars.
A considerable amount of time is therefore spent in many organizations,
with people checking and rearranging their calendars to accommodate
various events such as meetings, presentations, etc. In this environment,
the electronic calendaring systems and method have progressed to the point
where a person who is calling a meeting can at least view the calendars of
a number of users that he intends to invite to a meeting, to determine a
common available time for the meeting. See for example U.S. Pat. No.
4,626,836 filed 11/4/83 entitled "Method of Scheduling Meetings". See also
the cross-referenced application Ser. No. 008,034 which describes an
improved method of finding a meeting time.
However, in each of those systems, once the meeting time is set and the
prospective participants notified of the date, time, and subject of the
meeting, each participant must update his own electronic calendar and also
reply to the meeting request. While the system can facilitate the request
and reply message process, it is sometimes less frustrating to merely use
the telephone to arrive at a mutually convenient time.
Co-pending cross-referenced application Ser. No. 008,033 discloses an
electronic calendaring method in which replies to meeting requests are
developed automatically for the calendar owner, based on criteria that the
user has established or a set of default criteria that the system has
established. This method is a vast improvement over prior art
non-automatic systems. However, in the automatic method, each participant
in the meeting must provide an entry into his own calendar to be reminded
of the meeting that was automatically calendared for him. This is the same
awkward position that the calendar owner who is not attached to a network
is in, that is, if the meeting is changed or cancelled, the responsibility
for managing the alarm for the calendared event is the receivers'
responsibility. The invitee must therefore individually cancel the
reminder or move it to the new time if the meeting time has been changed.
These functions generally involve programming complexities that are costly
and time-consuming.
Electronic calendaring systems also permit calendar owners to enter notes
into the system to remind them to do certain things prior to a scheduled
event, such as obtaining a current printout of the latest sales figures
just before the meeting. If the owner is away from the system at the time
the note is triggered by a reminder, there may not be sufficient time to
obtain the printout at the time the owner remembers to order the printout.
The present invention provides an electronic calendaring method in which
the above-defined problems of the prior art are eliminated. In accordance
with this new method, if the calendar owner changes a calendar event entry
to a different time, any alarm-type message that the owner entered in
connection with the original entry may be automatically changed when its
related event is changed.
In a network environment in which calendar entries are created
automatically in response to requests by one owner for the other owner's
participation in the event, the new method may automatically duplicate for
the other calendar owners, any alarm-type messages that the originator has
established on his own calendar and can insure that these messages are
moved or modified if the time of the event is moved or the event
cancelled. The new method also allows an external process that is related
to a calendered event to be started automatically at a preset time and
float with the related event.
SUMMARY OF THE INVENTION
The present invention is directed to a method for assisting a calendar
owner in maintaining an electronic calendar on an interactive type
terminal such as an intelligent workstation or a standalone personal
computer system. The method involves creating a calendar object data
structure of the type described in cross-referenced application Ser. No.
008,034, in which information of a predetermined nature concerning an
event that is being calendared is stored, as the data is being entered
into the system interactively by the calendar owner in response to
displayed prompts for the various pieces of data.
In accordance with the improved method, a new data structure, referred to
as the "Trigger data structure" is established for use by the system. A
trigger data structure comprises a set of attributes that causes the
system to take some action at a predetermined time. The attributes include
a relative date and time for the trigger or an absolute date and time. The
owner/user can also specify the trigger type which depends on the
technology supported by the system hardware and may include an audio
alarm, a visual indication on the display screen, or even the name of a
process (i.e., an application program) to be started.
The method involves the step of presenting to the user/owner, a display
screen in the process of calendaring an event that requests data for the
Trigger function. As the data is entered by the user/owner, it is stored
at the appropriate field positions of the trigger data structure.
The method then automatically establishes the correct time for the trigger
to be activated from the data entered and the calendar system then
compares the system clock to the automatically established trigger time at
present clock intervals. If the comparison indicates a match, the
identified trigger is activated and the user or users are notified, or the
external process identified is dispatched.
In the situation where the calendar event is distributed to other
owners/users in the network to update their calendars with the
corresponding entry, the method also automatically establishes the time
for the trigger to be activated for the other calendar owners.
Since the trigger data structure includes a field to identify the event
being calendared, if the time of the event is changed or the event is
cancelled, the method also automatically modifies the time the trigger was
to be actuated. This latter step occurs automatically for the other users
when they are notified of the change in the time of the calendared event.
It is therefore an object of the present invention to provide an improved
electronic calendar method.
Another object of the present invention is to provide a method to assist
the operator of an interactive data processing type workstation to
maintain an electronic calendar that can alert the user a predetermined
time before the scheduled time of a calendar event.
A further object of the present invention is to provide a method to assist
the operators of interactive type data processing terminals that are
interconnected through one or more communications links to maintain their
respective electronic calendars in a manner that permits an event that has
been automatically calendared on more than one calendar, to also
automatically generate a reminder to the respective calendar owners, a
predetermined time before the event is to occur.
A still further object of the present invention is to provide an electronic
calendaring method in which a calendar owner may specify a time for a
reminder when an event is being calendared and the time for the reminder
is automatically modified in response to any change in the time of the
calendared event.
Objects and advantages other than those mentioned above will become
apparently from the following description when read in connection with the
drawing.
DESCRIPTION OF THE DRAWING
FIG. 1 is a block diagram of an interactive data processing terminal in
which the electronic calendaring method of the present invention may be
advantageously employed.
FIG. 2 is a block diagram of a network of terminals of the type shown in
FIG. 1.
FIGS. 3a through 3c illustrate display screens that are presented to a
calendar owner during the event calendaring process.
FIG. 4 is a flowchart, illustrating various detailed steps involved in the
improved electronic calendaring method.
BRIEF DESCRIPTION OF THE PREFERRED EMBODIMENT
FIG. 1 illustrates the functional components of an interactive type data
processing terminal on which the electronic calendaring method of the
present invention may be advantageously employed. The terminal comprises a
processing unit 11 which includes a microprocessor block 12, a
semiconductor memory 13, and a control block 14 which functions to control
input/output operations in addition to the interaction between the
microblock processor block 12 and the memory unit 13.
The terminal further includes a group of conventional peripheral units
including a display device 16, a keyboard 17, a printer 18, a disk storage
unit 19, and a modem 20. Since the details of the above-described
functional blocks form no part of the present invention and can be found
in the prior art, only a brief functional description of each block is set
forth, along with a description of their interactions, sufficient to
provide a person of ordinary skill in the art with a basis of
understanding applicants' improved electronic calendaring method.
Processing unit 11 corresponds to the "system unit" of a personal computer
system such as the IBM XT or IBM AT type systems. Unit 11 is provided with
an operating system program which may be one of the many versions of DOS
(Disk Operating System) which is normally employed to run the systems. The
operating system program is stored in memory 13 along with one or more
application programs that the user has selected to run. Depending on the
capacity of memory 13 and the size of the application programs, portions
of these programs, as needed, may be transferred to memory 13 from the
disk storage unit 19 which may include, for example, a 30 megabyte hard
disk drive and a diskette drive. The basic function of the disk storage
unit is to store programs and data that are employed by the system and
which may readily be transferred to the memory unit 13 when needed. The
function of the diskette drive is to provide a removable storage function
for entering programs and data into the system, and a vehicle for storing
data in a form that is readily transportable for use on other terminals or
systems.
Display device 16 and keyboard 17 together provide for the interactive
nature of the terminal, in that in normal operation, the interpretation
that the system gives to a specific keystroke by the operator depends, in
substantially all situations, on what is being displayed to the operator
at that point in time.
In some situations, the operator, by entering commands into the system,
causes the system to perform a certain function. In other situations, the
system requests the entry of certain data, generally by displaying a
prompt type of menu/message screen. The depth of the interaction between
the operator and the system varies by the type of operating system and the
application program, but is a necessary characteristic of terminals on
which the method of the present invention may be employed.
The terminal shown in FIG. 1 further includes a printer 18, which functions
to provide hard copy output of data developed or stored in the terminal.
Lastly, the modem 20 functions to transfer data from the terminal of FIG.
1 to a host system through one or more communication links which may be a
commercial type link or a dedicated communication link.
FIG. 2 illustrates a network 21 of interactive type workstations of the
type shown in FIG. 1. As illustrated, the network includes a plurality of
terminals which are interconnected with each other and to a host central
processing unit 23, which in turn is connected via communication link 24
to a second host processing unit 25, which also connects to another
network 26 of interactive workstations. Functionally, the system operates
to allow one terminal to communicate to one or more other terminals using
established communication protocols, so that the various serially
connected communication links are transparent to the operator. Such
systems are well known in the art, and are currently in extensive
commercial use. Since these communication links per se are not part of the
present invention, only those details that are necessary for an
understanding of the calendaring method of the present invention will be
described. It should therefore be assumed in the following description,
that each workstation on the network has a system node address and a "post
office" address, and that to simplify the description, there is only one
individual assigned to each node on the network. It should further be
assumed that conventional communication services are provided by the
system, such as directory listings of individual calendar owners and
shareable resources such as meeting rooms, etc., which require scheduling.
The system shown in FIG. 2 processes information as various types of data
objects such as text data objects, graphic data objects, and calendar data
objects. Each of these data objects are represented by a datastream which
comprises a series of structured fields.
A calendar object datastream has the following sequence of structures.
______________________________________
Begin Document (BDT)
Begin Page (BPG)
Begin Calendar Data (BCL)
Calendar Data Descriptor (CDD) (Optional)
Calendar Data SF (CAD)
Calendar Structures (COCA)
End Calendar Data (ECL)
End Page (EPG)
End Document (EDT)
______________________________________
The format of the datastream for other type data objects contain the begin
document, begin page, end page, and end document data structures.
Structured fields corresponding to those listed above for a calendar
object are also employed for other type objects.
A structured field is a self-describing entity which contains related
groupings of parameter values and triplets. The structure field, as shown
below, has two parts: the Structured Field Introducer and the Structured
Field Content.
##STR1##
The structured field begins with a Structured Field Introducer. The syntax
and semantics of the Structured Field Introducer are defined by the
architecture which governs the datastream in which the structured field is
found. The Structured Field Introducer contains as the first two bytes a
parameter which defines the length of the structured field. It also
contains an identification code which uniquely identifies the structured
field.
The Structure Content portion of each structured field contains structures
and triplets, which give the structured field its meaning. Parameters in
the triplets define the attributes of the Calendar Object. Every parameter
has a value either explicitly appearing in a triplet, inherited from a
control structure in the datastream's hierarchy, or implicitly defined as
a default. This default may also be the alternate action value.
Every structure is either required or optional. A required structure
appears in the object because the function of that structure is required
and for proper performance of the function an value is necessary.
An optional structure need not appear in the object either because the
function of that structure is not required or because the function is
required, but default values are acceptable for all parameters.
As shown above, a calendar data (CAD) structured field (SF) precedes the
actual calendar data. A calendar data descriptor (CDD) SF can precede the
CAD SF to provide formatting information for the data that follows.
Calendar data comprises named data structures and named triplets which are
composed of parameters. A parameter is a variable to which a value is
assigned. Parameters can be optional or required. Parameters are also
classified as terminal or non-terminal. A terminal parameter is merely the
last parameter in a string of parameters.
A parameter can have one of three types of values assigned.
1. NUM--This is a number or a numerical value.
2. COD--This is a code assigned a specific meaning.
3. BST--This is a bit string of binary elements, each of which is usually
independent of the other.
In the following discussion it will be assumed that a byte comprises 8 bit
positions numbered 0-7 from left to right, with position 0 being the high
order position. Bit position 0 represents 2**7 (2 to the 7th power), while
bit 7 represents 2**0 (2 to the 0 power).
The various calendar structured fields and calendar triplets are defined by
the following type of table.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
n-m name type v x www
______________________________________
In the figure:
BYTES refers to the position, indexed on zero.
NAME is the name by which reference is made to the parameter.
TYPE denotes the syntax of the parameter by "type," The architected types
NUM, COD, and BST were described earlier.
LGTH denotes the length of the field in terms of the exact number of bytes
or the maximum number of bytes permitted.
OPT refers to the optionality of the parameter's appearance in the
structure or triplet:
O means that the parameter is optional.
R means that the parameter's appearance is required.
If a required parameter is missing, an exception condition exits. The
alternate action is to ignore the structure, self-defining field, or
triplet to which the missing parameter belongs.
Syntactically descriptive material below the figure indicates what
additional restrictions apply to the structure or triplet defined by the
figure.
Calendar structures and calendar triplets which are relevant to the present
invention will be described using the above-described format. After the
structures are described, the display screens that are presented to
calendar owners by the system in order to solicit information when a
calendar owner wants to perform a calendaring function will be described.
A flow chart setting forth the detailed steps of the method of the present
invention will then be described in connection with the program listing of
pseudocode that will assist persons skilled in programming interactive
terminals to implement the method of the present invention.
Since the "Floating Trigger function" is used in connection with a
calendared event, it is necessary to describe in detail the data
structures that are employed by the system in the process of an owner
calendaring an event on his calendar. In the preferred embodiment,
calendar entries are classified into a number of different types. Since
the system contemplates interchanging calendar data throughout the system,
including terminals that are remotely connected, such as thoes shown in
FIG. 2, entry types and presentation language are controlled by a defined
architecture. While the same display screen may be employed to solicit the
data for a number of different event types, the data structures and
triplets, required or optional, will vary by event type.
While some of the structures to be described and the triplets associated
with these structures are not directly involved in the view select
function, they have been described in order to provide background for the
reader and a basis for a comprehensive understanding of the claimed
process and its relationship to the processes described and claimed in the
cross-referenced application.
The various calendar object data structures to be described are preceded by
a calendar data structure shown below.
__________________________________________________________________________
CALENDAR DATA (CAD) STRUCTURE FIELD (SF)
BYTES
NAME TYPE
MIN MAX LGTH
OPT
__________________________________________________________________________
0-1 Structured Field Length
NUM 8 32767
2 R
2 Structured Field Type1
COD X`D3`
X`D3`
1 R
3 Structured Field Type2
COD X`EE`
X`EE`
1 R
4 Structured Field Type3
COD X`5B`
X`5B`
1 R
5 Flags BST 0 0 1 R
6-7 Segment Sequence Number
NUM 0 32767
2 R
8-7+n
Calendar Data * * n R
__________________________________________________________________________
*Values depend on the Calendar Object structure and triplet specification
The Calendar Data SF (CAD) identifies the data as calendar data and
specifies the length of the calendar data. The Calendar Data SF contains,
for example, up to 32767 bytes of calendar structures and calendar
triplets (called "Calendar Data"). Calendar data varies with the function
employed by the generator of the object.
MAJOR CALENDAR STRUCTURES DESCRIPTION
This section describes the major structures that are involved in the
present invention. The structures consist of a mixture of calendar
triplets. The triplets are described in the Calendar triplets Description
section that follows this section.
The calendar structures are preceded by the Calendar Data structured filed
(CAD). Parameter values specified by the system can be overridden by
parameters specified in calendar data. For example, the Code Page of
Symbols for Displaying and Printing Data.
In the structure description, bits are consecutively numbered from left to
right starting with zero.
The format for all of the structures is the same. The format is shown
below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 LENGTH NUM R
2-3 TYPE COD R
4-n TRPLT1 to R
TRPLTn
______________________________________
where
LENGTH=A two-byte value of the number of bytes in this structure including
byte zero.
TYPE=A two-byte binary number that designates a specific structure
function.
TRPLT1 TO TRPLTn=Calendar Structure Triplets.
The length of structures can vary depending on the number of triplets
included.
If the length excludes all or part of an optional parameter in a triplet,
then the value for that parameter and any parameters that follow are not
changed; that is, the LENGTH field is used as specified.
If a structure is invalid or unsupported, an exception is raised. If the
length field excludes a required parameter or triplet, an exception is
raised. If a structure contains an invalid or unsupported parameter or
triplet, an exception is raised.
MEETING (MTG) STRUCTURE
The meeting structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure NUM * 32767 2 R
Length
2 Structure COD X`D3` X`D3` 1 R
Type1
3 Structure COD X`85` X`85` 1 R
Type2
4-3+n Meeting Trip- * n R
lets
______________________________________
*Values depend on the triplet specification.
The MTG structure provides the fields necessary to interchange meeting
information, the scheduling of meetings and requests for meeting
information. It also provides a specific search classification to allow
building a composite calendar for a specified list of calendar owners.
The Valid MTG Triplets are listed below and defined in detail in the
following section.
ERROR ACTION (EAC)--An EAC triplet may occur in any sequence and is
optional.
STRUCTURE ID (SID)--The SID specifies the ID for the meeting. An optional
SID may be included to identify a Trigger (TRG) associated with the
meeting.
DATA AND TIME (DTT)--The DTT triplet provides the meeting time(s) and
date(s) and is required. DTT triplets must occur in ascending time(s) and
date(s). A meeting that occurs at non-sequential times can be scheduled by
using more than one DTT triplet specifying the required times.
NAME (NME)--Network Address (NAD), Postal Addresses (PAD) and User Status
(UST) triplets may be used to provide user status and addresses for a
named item. NME triplets and associated NAD, PAD and UST triplets may be
included for both the CALLER (meeting owner) and the ARRANGER (meeting
arranger). The Name Status byte specifies whether or not NAD, PAD and UST
triplets follow the Name triplet which is optional.
USER STATUS (UST)--The UST triplet provides the role and status for the
person named in the NME triplet. This triplet is only valid when it
follows a NME triplet and is optional.
NETWORK ADDRESS (NAD)--The NAD triplet provides the network address for the
person named in the NME triplet and is optional.
POSTAL ADDRESS (PAD)--The PAD triplet provides the the mailing address for
the person named in the NME triplet and is optional.
EVENT STATUS (EVS)--The EVS specifies the meeting status and is optional.
TIME STAMP (TMS)--Only one TMS triplet is allowed in the MTG structure and
it is optional.
ENTRY SECURITY (ESL)--If this control is omitted the security level is
PUBLIC. Only one ESL triplet is allowed in the MTG structure and it is
optional.
SET CODED GRAPHIC CHARACTER SET GLOBAL ID (SCG)--The SCG selects the
character set and code page for characters contained in the triplets that
follow the SCG in the calendart structure. The Network Address character
set and code page are not affected by the SCG. The active code page is
restored automatically at the end of the calendar structure.
SUBJECT (SBJ)--The SBJ triplet contains character data describing the
meeting subject. One SBJ triplet is allowed in each MTG structure and it
is optional.
PLACE (PLC)--The PLC triplet contains character data describing the meeting
location. One PLC triplet is allowed in each MTG structure and is
optional.
DETAIL (DTL)--The DTL triplet contains character data describing the
meeting. If the Code Page or character Set is changed in the meeting
description, the DTL triplet must be ended, a SCG triple inserted, and
another DTL triplet built. It is optional.
RSVP (RVP)--The RVP specifies the need for an attendance response from the
meeting invitee and it is optional.
If a MTG structure is received without all required triplets, an exception
exists. The default action is to skip the structure and continue
processing. If a MTG structure contains an unsupported or invalid triplet,
an exception exists. The default action is to skip the triplet and
continue processing. If a MTG structure contains a DTT triplet with dates
and times not in ascending order or if the optional SCG triplet occurs at
a position that does not immediately precede a triple with text data (DTL,
SBJ, PLC), an exception exists. The default action, in both cases, is to
ignore the triplet and continue processing.
NAMES LIST (NML) DATA STRUCTURE
The names list data structure is shown below.
______________________________________
BYTES NAME TYPE MIN MAX LGTH OPT
______________________________________
0-1 Structure NUM * 32767 2 R
Length
2 Structure COD X`D3` X`D3` 1 R
Type1
3 Structure COD X`8A` X`8A` 1 R
Type2
4-3+n NML * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The NML structure provides the fields to support a name, associated
addresses and status. The NML may contain a list of items, such as an
invitees list, by concatenating Name (NME), Address (ADR) and User Status
(UST) sequences. The list may include one or more than one name and
associated information.
The following Valid NMR Triplets for the NML DS were described in
connection with the MTG structure.
ERROR ACTION, STRUCTURE ID, TIME STAMP, ENTRY SECURITY, SET CGCSGID, NAME,
USER STATUS, NETWORK ADDRESS and POSTAL ADDRESS.
The Date and Time (DTT) triplet is not valid.
The following triplet, however, is optional for the Names List data
structure.
NAMES LIST TYPE (NLT--Only one NLT triplet is allowed in the Names List
structure. The NLT triplet specifies the type of data contained in the
Names List. If the NLT is not specified, the list contains a list of names
and or status and/or addresses that are not necessarily in one of the
categories defined by the NLT triplet.
If a NML structure is received without a Structure ID triplet, an exception
exists. The default action is to skip the structure and continue
processing. If a NML structure contains an unsupported or invalid triplet,
an exception exists. The default action is to skip the triplet and
continue processing. Each sequence of the Names List structure triplets
must occur in the listed order.
Optional triplets may be omitted from any sequence. If a NML structure is
received with a triplet out of sequence, an exception exists. The default
action is to skip the structure and continue processing. The
above-described processing for handling exceptions is standard for most
structures and therefore can be assumed for the following items.
TRIGGER(TGR) DATA STRUCTURE
The Trigger data structure is shown below.
__________________________________________________________________________
BYTES
NAME TYPE
MIN MAX LGTH
OPT
__________________________________________________________________________
0-1 Structured Field Length
NUM * 32767
2 R
2 Structured Field Type 1
COD X`D3`
X`D3`
1 R
3 Structured Field Type 2
COD X`8F`
X`8F`
1 R
4 Trigger Type
BST * * 1 R
5-48 Meeting ID COD * * 44 O
49-64
Process ID COD * * 16 O
65-Max
Tgr Triplets
__________________________________________________________________________
The TGR structured field specifies a time that a notification will occur
and or a process will begin.
MEETING ID=Fourty four byte identifier that selects the invitee list
associated with a meeting. The selected list will be notified at the
trigger time.
PROCESS ID=Sixteen byte identifier that selects the process to be started
at trigger time. If the meeting ID is also present the selected list will
be notified at the trigger time.
TRIGGER TYPE=Specifies whether the trigger is a message, audio tone, audio
message, process or a combination trigger. Any combination of the
following trigger types is allowed.
BIT
0=Message Trigger--A message will be circulated to the selected list at the
selected time (DEFAULT)
1=Audio Trigger--An audio tone will be circulated to the selected list at
the selected time.
2=Audio Message Trigger--An audio message will be circulated to the
selected list at the selected time.
3=Process Trigger--A Process will start at the selected time.
The Triplets that are valid in a TGR structure are:
TMS (OPTIONAL), ESL (OPTIONAL), DTT (REQUIRED), SGC (OPTIONAL), DTL
(OPTIONAL), SID (OPTIONAL), EAC (OPTIONAL)
VIEW SELECT (VSL) DATA STRUCTURE
The View Select data structure is shown below.
______________________________________
B | | |
