 |
Description  |
|
|
FIELD OF INVENTION
This invention relates in general to electronic calendaring methods, and in
particular, to a calendaring method in which the availability of resources
to support an event being calendared is confirmed automatically at the
time the event is being calendared.
CROSS-REFERENCES TO RELATED APPLICATIONS
1. 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 from different calendars which have an
interrelationship that the user defines by data that is entered into the
system interactively.
2. Co-pending application Ser. No. 008,039 filed concurrently herewith,
entitled "Electronic Calendaring Method to Establish Calendar Floating
Triggers for Calendared Events and Processes" and assigned to the
assignee of this application is directed to an electronic calendaring
method in which a calendar owner can selectively trigger a predefined
action in response to detecting one or more criteria related to the
calendar event that has previously been defined and entered into the
system.
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 on each calendar copy, independently of the other since the last
time the detached copy was made and interactively resolve calendar event
conflicts.
4. 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.
5. 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 ownere who receives a request to participate in
a calendar event originated by another calendar owner, and currently being
calendared by that owner, can establish an automatic response which
reflects the assignment of an alternate to the event based on the
relationship of the information that accompanies the request and criteria
that the calendar owner has pre-established for each potential alternate.
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 event 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
their calendars on these interactive type data processing 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 a part of a larger network. Generally, in
these types of systems, the calendar functions involve presenting a screen
to the user representing a day calendar divided into a number of time
periods or time slots.
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 to the user or horizontally to present longer text
entries. The operator can generally "page" forward or backward and, in
most arrangements, can display a requested date. These calendaring
arrangements 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 manual calendars or
appointment books. The electronic calendaring method and systems do have
an advantage over the prior art manual calendaring of events in that the
user generally has the ability to scan a time span involving a large
number of days and identify calendared events quite rapidly.
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 data processing 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
addressees has received and read the message.
In most of these environments, each user generally maintains a calendar,
and in many of these environments the reason for the interaction with each
other quite often 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 calendar systems and method have progressed to the
point where a person who is calling a meeting can at least review within
the constraints that the security system dictates, the calendars of other
users on the system that he intends to invite to a meeting, to determine
whether a given time period is available on the respective calendars of
the perspective attendees. However, 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
reply to the meeting request. While the system can facilitate the request
and reply message process, it is sometimes less frustrating when a
negative reply has to be transmitted to merely use the telephone to arrive
at another mutually convenient time. As a result, a considerable amount of
time and effort is spent by calendar owners replying to requests for
participation in events that are being calendared by other persons.
The cross referenced applications describe various improvements to
electronic calendaring methods for increasing productivity and making the
overall system more appealing to the calendar owner by providing functions
that the calendar owner came to expect and rely on when his calendar was
being kept manually.
In many situations it is desirable that the individual calendar owner have
the ability to reserve resources that he intends to use at the event that
he is calendaring. While some electronic calendaring systems permit the
calendar owner to request a meeting place such as a conference room, the
availability of the conference room and the resources associated with the
conference room are not provided at the time the event is being
calendared. An iterative process therefore results where the meeting time
has to be changed because no conference room is available and the one or
more of the previous confirmed invitees cannot attend because of a prior
commitment. Similar situations arise when for example the meeting
originator needs special equipment for the meeting such as a slide
projector, a video player and monitor, or tele-conferencing units only to
be informed shortly before the meeting that they are broken or not
available for a number of valid reasons. The present invention overcomes
the above described problems and limitations of prior art electronic
calendaring methods by providing a method in which a calendar owner can
request resources to support an event that is being calendared at the time
the event is being calendared and receive a confirmation at that time that
the facilities and resources will be available.
SUMMARY OF THE INVENTION
In order to minimize the time and effort involved by calendar owners in
calendaring events that require facilities and recourses, provision is
made in the electronic calendaring method for an automatic confirmation of
the availability of the requested facilities at the time and place
indicated in the meeting notice.
The method establishes a Resource data structure for storing data that is
used by the system to automate the response for meeting facilities and
equipment to a calendar owner calendaring a meeting and dispatching a
meeting notice through the system to other calendar owners. A pair of
triplet type data structures are also established for use by the system in
connection with the Resource data structure to allow a definition of the
meeting place and the equipment that is available at the scheduled meeting
time with the requested resources.
The Automatic Response function of the electronic calendaring system that
is described in cross-referenced application Ser. No. 008,033 is modified
to accommodate the development of an automatic reply from a node on the
system which is assigned to the conference room. The caller of the meeting
is presented a screen as part of the process of calendaring a meeting type
of an event, which permits the caller to identify the conference room that
he wants, the time period that it will be in use and the equipment he
would like reserved for use at the meeting. The meeting notice is sent to
the conference room node prior to or contemporaneously with notices sent
to the meeting invitees.
On receipt of the notice at the conference room node the request is
analyzed and if the room is available, a confirmation is sent back to the
caller advising that the room is reserved for him. The list of requested
equipment is also analyzed against available equipment and an indication
is provided for each item that it is reserved for that meeting period. An
indication is also provided when the item that was requested is not
available.
If there are similar meeting rooms in the immediate vicinity of the
requested room, an alternate room can be assigned automatically if it
meets the request, much like the operation in the cross-referenced
application Ser. No. 008,033 which permits an owner to send an alternate
to a meeting to which the owner was invited. The caller of the meeting
therefore is aware of what room is reserved and whether of not all of the
equipment that he will need is reserved.
It is therefore an object of the present invention to provide an improved
electronic calendaring method.
A further object of the present invention is to assist owners of electronic
calendars in scheduling calendared events which involve facilities and
equipment that may not be available at the time of the meeting.
A further object of the present invention is to provide an improved
electronic calendaring method in which a reply to a request for use of a
common facility and common equipment to support an event being calendared
can reflect the fact that a specific requested item is or is not
available.
A still further object of the present invention is to provide an electronic
calendaring method in which an automatic reply to a calendar owner that
has requested equipment or facilities to support a meeting, can specify an
alternate location that meets all of the elements of the request or in
which the nature and content of the reply reflects that the suggested
alternate location comes closer to fulfilling the request than the
location originally specified.
Objects and advantages, other than those mentioned above, will become
apparent from the following description when read in connection with the
drawing.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 is a block diagram of an interactive data processing terminal in
which the method of the present invention may be advantageously employed.
FIG. 2 is a block diagram of the network of terminals of the type shown in
FIG. 1.
FIGS. 3a-3c illustrate display screens that are employed with the method of
the present invention for entering information interactively into the
system during the calendaring of an event.
FIGS. 4a-4b illustrate display screens that are employed where a request
for a conference room is entered along with a request to reserve specific
equipment for the scheduled meeting.
FIG. 5 illustrates a display screen that is employed by the person
responsible for conference room scheduling and equipment inventory and
automatic replies.
FIGS. 6a-6b are flow charts illustrating various detailed steps of the
improved electronic calendar method involved in developing a reply that
reflects the availability of requested facilities and equipment.
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 micro
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 structured 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 actual 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 exists. 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 such as reserving a
conference room and equipment will be described. A flow chart setting
forth the detailed steps of the method of the present invention will then
be described and will assist persons skilled in programming interactive
terminals to implement the method of the present invention.
Since the Automatic Response function operates in response to an invitation
to an event being calendared by another calendar owner, 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 those 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 "Automatic
Response" function, and conference room replies 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 NUM 8 32767 2 R
Field Length
2 Structured COD X'D3' X'D3' 1 R
Field Type1
3 Structured COD X'EE' X'EE' 1 R
Field Type2
4 Structured COD X'5B' X'5B' 1 R
Field Type3
5 Flags BST 0 0 1 R
6-7 Segment NUM 0 32767 2 R
Sequence
Number
8-7+n Calendar * * n R
Data
______________________________________
*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 field
(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.
APPOINTMENT (APP) STRUCTURE
The appointment 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'70' X'70' 1 R
Type2
4-3+n Appointment * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The APP structure provides the fields necessary to interchange appointment
information, the scheduling of appointments and requests for appointment
information.
CALENDAR COMMENTS (CMT) STRUCTURE
The calendar comment 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'75' X'75' 1 R
Type2
4-3+n CMT Triplets * * n R
______________________________________
*Values depend on the triplet specification.
The CMT structure provides the fields necessary to interchange calendar
comments. The structure supports calendar comments associated with a date
and time and calendar comments not associated with a date and time.
ENTRY SELECT (ENS) STRUCTURE
The ENS 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'7F' X'7F' 1 R
Type2
4-3+n ENS Triplets * * n R
______________________________________
*Values depend on the triplet specification.
The ENS structure supports interchange for entries VACATION, HOLIDAY,
OFFSITE and NOT NORMAL WORK HOURS calendar comments.
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 * * n R
Triplets
______________________________________
*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.
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
invitee's 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.
TRIGGER (TGR) STRUCTURE
The Trigger 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'8F' X'8F' 1 R
Type2
4-3+ n TGR * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The TGR structure specifies a time that a notification will occur and or a
process will begin.
VIEW SELECT (VSL) DATA STRUCTURE
The View Select 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'95' X'95' 1 R
Type2
4-3+ n VSL * * n R
Triplets
______________________________________
*Values depend on the triplet specification.
The VSL structure provides a way to request calendar views for specific
category(s) and timespan(s).
CALENDAR PROFILE (CPL) DATA STRUCTURE
The Calendar Profile 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'77' X'77' 1 R
Type2
4-3+ n Calender * * n R
Profile
Triplets
______________________________________
*Values depend on the triplet specification.
The CPL structure provides the fields necessary to interchange calendar
profile information. The calendar Profile contains information that
describes the associated calendar.
DATE AND TIME MAP (DTM) DATA STRUCTURE
The Date and Time Map 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'7A' X'7A' 1 R
Type2
4-3+ n DTM * * n R
Triplets
______________________________________
The DTM structure provides an efficient way to pass date and time slot
usage between calendar users. It is used to build a combination
(composite) calendar from Date and Time Map responses from several users.
It supports the selection of calendar entry category(s) and timespan(s)
for the Date and Time Map requests and responses.
AUTO RESPONSE (ARS) DATA STRUCTURE
The Auto Response 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'72' X'72' 1 R
Type2
4-3+ n Auto * * n R
Response
Triplets
______________________________________
The ARS structure provides the fields necessary to interchange automatic
response information. It allows the use of a network address(NAD), A
Meeting or Appointment Structure ID (SID), A Priority (UDF) or a User
Defined Field (UDF) specification to initiate an automatic response.
RESOURCE (RSR) DATA STRUCTURE
The Resource 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'78' X'78' 1 R
Type2
4-3+n Resource * * n R
Triplets
______________________________________
The RSR structure provides the fields necessary to interchange conference
room information. It contains information describing a conference room or
confer | | |
