Note: Descriptions are shown in the official language in which they were submitted.
CA 02396371 2003-11-21
w0 01/52081 PCT/uSO1101088
METHODS AND SYSTEMS TO MANAGE AND TRACK THE STATES OF
ELECTRONIC MEDIA
BACKGROUND
The present invention relates generally to communication networks, and more
particularly, to methods and systems to manage and track the states of
electronic media in such
networks.
Communication networks are used to share information. The information is
passed
between users of the network using a common medium. For example, many
individuals
communicate over the Internet using a medium such as electronic mail. As the
medium is
passed between users, the medium changes states. The change of the states may
occur quickly
and become too complex for the user to track and manage. Thus, to determine
the current or
actual state of the medium and its contents tends to cause confusion and lead
to a waste of a
user's time and resources.
1
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a simplified diagram of a sample network including participants of a
group connected to the network.
FIG. 2 illustrates a schematic diagram showing data flows of functional
components of the network of FIG. 1.
FIG. 3 illustrates an example electronic form to initiate a zaplet.
FIG. 4 is a diagram of a data structure for the zaplet having dynamic content.
FIG. 5 is an example of an image of a zaplet.
FIG. 6 is a flow chart illustrating a preferred method of the present
invention.
1 o FIG. 7 is a flow chart illustrating a preferred method of accessing the
zaplet by
parsing the data structure of FIG. 4.
FIG. 8 illustrates a flow chart describing a process for delayed sending of a
zaplet.
FIG. 9 illustrates a flow chart describing a process for shared authoring of a
zaplet.
FIG. 10 illustrates a flow chart describing a process for copying a zaplet.
FIG. 11 illustrates a flow chart describing a process for notifying a
participant
of a zaplet.
FIG. 12 illustrates a flow chart describing a process for blocking access to a
2o zaplet.
FIG. 13 illustrates a flow chart describing a process for controlling
responses
to a zaplet.
FIG. 14 illustrates a flow chart describing a process for notifying
participants
of changes to a zaplet.
2
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
FIG. 15 illustrates a flow chart describing a process for superseding a
zaplet.
FIG. 16 illustrates a flow chart describing a process for externalizing or
restoring a zaplet.
FIG. 17 illustrates a flow chart describing a process for archiving a zaplet.
FIG. 18 illustrates a flow chart describing a process for deleting a zaplet.
FIG. 19 illustrates a flow chart describing a process for displaying changes
in
content of a zaplet.
DETAILED DESCRIPTION
In general, the present invention is directed to methods and systems for
managing or tracking the change of states of one or more electronic media. An
electronic medium may have at least one dynamic content region that is stored
in a
database of a server. Input composed by participants of a group or other
external
sources is accepted by the server to update the dynamic content region of the
electronic medium in the server. The updating of the dynamic content region is
preferably performed asynchronously relative to the sending and receiving of
the
input from any of the participants or external sources. In this way, the
content of the
electronic medium is always current.
The information communicated between participants of the group is not
2o current when sent by any participant, but current when accessed or read by
a
participant. Information is not merely current when the medium was sent to a
receiving participant to communicate information; rather, the current content
from the
server of the electronic medium is retrieved, when the receiving participant
accesses
the electronic medium. This means that multiple virtual instances of the
electronic
3
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
medium can be reduced to a single thread. This also usefully reduces the
amount of
media, such as electronic mail messages carrying redundant static content that
is
communicated among the participants of the group. Collaboration of information
is
also more rapid and interactive among participants of the group.
The electronic medium can also be updated by a variety of external sources,
such as by an attached server containing stock quotes or news feeds. In this
way, the
electronic medium can be used to supply different types of information to the
participant in a fast, efficient, and flexible manner.
A suitable system is a communication network that is configured with
~ o participants that support a variety of protocols, such as those for
supporting electronic
mail ("e-mail") and the Internet. The electronic medium for communicating
information and that supports collaboration among participants in a group
connected
to the network will be referred to as a "zaplet". The zaplet contains static
content and
dynamic content regions. The term dynamic content can be defined as regions of
the
zaplet that are retrieved from the server, when the zaplet is accessed by a
participant
or external source. The term static content can be defined as regions of the
zaplet that
are not retrieved at the time the zaplet is accessed by a participant or
external source.
The dynamic content of the zaplet can be changed and updated by the
participants in
the group or by other external sources, such as an external server containing
the most
2o recent news feeds or stock quotes. The content of the zaplet can be stored
in a
database in a server of the network. The zaplet is also customizable and
programmable, containing various text and graphical regions to execute a
variety of
functions and applications. Preferably, each of the regions may be configured
by the
participants or the server in the network. When a participant performs an open
action
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
to access the zaplet, the zaplet may open and the server serves and displays
the then
current content in the database to a participant.
An "open action" can be defined as an action by any of the participants or the
server that causes the static and/or the dynamic content of the zaplet to be
retrieved
from the server. For example, an open action may occur when a user invokes the
File
Open command from a menu bar within an email reading program while an email
message containing a zaplet is selected. Alternatively, the server could
perform an
open action using, for example, push technology processes.
The term collaboration can be defined as an activity in which one or more
participants or services share information or points-of view with an intent of
reaching
a decision, making a choice, conducting a financial transaction, or sharing
knowledge.
The dynamic content can be represented in a dynamic content region in the
zaplet, and includes text or images, such as rich text HTML, based on mark-up
languages or image construction languages. Consequently, the zaplet can supply
all
the look and feel possibilities of the World Wide Web ("Web"), and also the
participants can experience interactions and collaborate with each other with
increased efficiently than in known e-mail systems.
Communication among a group of participants is simple. Preferably, the
server used to generate and manage the zaplet is scalable for a particular
2o implementation. Its scalability allows quick user response under heavy load
conditions on the server. Further, the zaplet can be easily accessed by the
participant,
such as from a desktop computer. Accordingly, the participant will have
constant
access to his or her zaplet at all times, and thereby can collaborate with
other
participants in the group quickly, simply, and efficiently. This means that
the
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
participant need not repeatedly type-in the URL of a portal web site to regain
access
to a particular application, such as a discussion; the zaplet may be easily
accessible
and open in an unobtrusive manner.
Unless otherwise defined, all technical and scientific terms used herein have
s substantially the same meaning as commonly understood by one of ordinary
skill in
the art to which the invention belongs. Although many methods and systems
similar
or equivalent to those described herein can be used in the practice of the
present
invention, suitable methods and systems are described below. Additionally, the
methods, systems, and examples described herein are illustrative only and not
~ o intended to be limiting.
Other features and advantages of the invention will be apparent from the
following detailed description, the drawings, and from the claims.
FIG. 1 illustrates a plurality of participants 1, 2, 3, and 4 of a group that
are
coupled to a network 5. Any number of participants may be connected to the
~ s network 5. The term participant can be defined as an entity or system that
is capable
of performing or executing a variety of functions on the zaplet as described
herein.
For simplicity, however, the following description will be made to
participants 1-4.
Each of the participants 1-4 may include any specific or general computer
system that
is equipped to receive or read e-mail messages using standard e-mail
protocols, such
2o as the Simple Mail Transfer Protocol (SMTP) and the Multipurpose Internet
Mail
Extensions (MIME), or navigate the Web. The computer may be, fox example, a
personal computer ("P.C."), an Apple Macintosh, a Unix workstation, or other
computing machine that runs a windows-based operating system. A suitable
computer may also include a modem, a monitor, a keyboard, a mouse, system
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
software including support for TCP/IP communication, and browser software.
Alternatively, the participants 1-4 may include other devices that are capable
of
transmitting or receiving e-mail messages, forms, or zaplets, such as Palm
computers
provided by 3Com Corporation, Windows CE-based devices, messaging enabled
cellular telephones, pagers, television set top boxes, e.g., Web T.V., or
portable
computers. The participants 1-4 may further include other devices that are
capable of
processing text or voice messaging.
The network 5 may be any local or global computer network. For example,
the network 5 may be the Internet, a telephone network, a wireless
communications
network, a satellite communications network, or other similar data networks.
For simplicity, the following description will be made using a systems and
methods configured to support any of the below listed e-mail protocols and
data
structures. Other configurations are also possible. For example, voicemail
using
interactive voice systems could be configured to provide voice messages as
current
~ s when heard dynamic content.
Each of the participants 1-4 is configured to support a variety of e-mail
protocols and mark-up languages, such as SMTP, MIME, Hypertext Mark-up
Language ("HTML"), Extensible Mark-up Language ("X1VV11,"), Standardized
Generalized Mark-up Language ("SGML"), or similar e-mail protocols and/or mark-
2o up languages.
FIG. 1 also shows a server 6 that is connected to the network 5. The server 6
is preferably configured to manage the dynamic content, routing, and updating
of
electronic forms, messages, or zaplets among the participants 1-4. The server
6 is
CA 02396371 2004-11-15
connected to a message database 7 that is used to manage the dynamic content
of
zaplets. Other data management resources may also be used.
FIG. 2 illustrates a simplified block diagram showing data flows of various
functional components of the server 6. The server 6 includes a database 10 The
database 10 may be a relational database, such as commercially available from
Oracle. The database 10 may include multiple physical databases and may be
implemented at a single site or distributed among many sites. The database 10
may
also be implemented using object-oriented databases, object-relational
databases; or
hierarchical file structures.
1o The database 10 may include information that is specific to any participant
or
electronic form, message, or zaplet. Contents of the database 10 may include
demographic data, participant credit card and payment information, participant
preference information, generic form, message, or zaplet information, such as
recipients or senders of the group, subject identifiers, or message specific
information, and usage statistics for the electronic forms, messages, and
zaplets
and/or a web site. The database 10 may also store electronic forms that act as
blanks
for the creation of the zaplets. The database 10 may also include images and
web
pages used in the creation of the zaplets and also used in the presentation of
any
dynamic region of the zaplet. The database 10 may also maintain a record of
the
2o history of changes that have been made to any dynamic content region of the
zaplet
discussed below. This record may also be propagated along with any dynamic
content to orie of the participants parsing the electronic message and zaplet,
as
discussed below. An example configuration for storing and processing various
content in the database 10 is illustrated in the attached Appendix A.
8
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
FIG. 2 also shows a data application server 12 is coupled to the database 10.
The server 12 is configured with, for example, a set of Java classes or any
other high
level programming language built using, for example, an Enhydra application
server
or any of a variety of other tools for object-relational translation. The data
application
server 12 is used for translating the content in the database 10 into Java
objects, for
use by a web application server 14. The data application server 12 may also be
configured to cache some data to reduce the load on the database 10.
A web server 16 is included in the server 6 to connect to the participants 1-4
and is connected to the web application server 14 and can be any commercially
available web server, such as an Apache server. The web server 16 is
configured to
manage requests from browsers at the participants 1-4, to manage session
information, to send and receive forms, or zaplets transmitted to or from the
participants 1-4, and to serve HTML data and static images to the participants
1-4.
The web application server 14 can be configured using a set of Java classes
built-on top of the data application server 12. The web application server 14
is
responsible for executing business logic associated with the electronic forms,
messages, and zaplets. For example, the web application server 14 may manage
message, form, and zaplet manipulation, deadlocks in the network 5, generate a
URL
and content associated with a specific zaplet or form, format the zaplet,
message, or
2o form, handle message authorizing, and handle participant record editing and
participant interaction with various zaplets, forms, and messages.
A web page formatter 18 is connected to the web application server 14. The
web page formatter 18 is used to handle the basic styles and layouts of
various
components of the zaplets, messages, or forms. Further details of the
preferred
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
business logic configured in pseudocode executable by a system and describing
a
method for initiating, sending, updating and displaying the zaplet, forms, and
messages can be found in attached Appendix A.
The web page formatter 18 may be configured to operate using a Java Server
Page ("JSP") construct.
FIG. 2 also shows that the server 5 includes a mail server 20 coupled to the
web application server 14 and the data application server 12. The mail server
20
handles the operations of the e-mail protocol necessary to support a variety
of zaplets,
forms, and messages. For a given message, form, or zaplet, the mail server 20
retrieves data associated with the medium from the data application server 12,
and
from any operations of the business logic of the web application server 14.
The mail
server 20 then formats the static content for the medium utilizing an
associated mail
formatter 24 including a command to retrieve the dynamic content. The mail
formatter 24 includes operations that can be used for the basic styles and
layouts of
the common elements of the zaplets, forms, or messages. Once the mail server
20 has
compiled the required information from the data application server 12 and web
application server 14, the mail server 20 may attach necessary header
information to
the zaplet, form, or message. For example, the header information may make an
e-
mail message compliant with the MIME standard. The mail server 20 then
transmits
2o the produced message to a mail transport server 22. The mail transport
server 22
routes the message through the network 5. The mail server 20 may also be
configured
to manage bounced and undelivered messages, forms, or zaplets, and also alert
the
appropriate participants of these conditions. The mail server 20 may also
communicate with the web application server to validate the addresses of the
various
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
participants. The mail server 20 may also receive responses via the
interaction region
225 discussed below from any participant who is not connected to the network
10 or
"off line" when reading the zaplet. In this configuration, the participant can
send
input back to the server 6 to be dynamically updated, after he or she is re-
connected to
the network 10. In this way, the participant can contribute to a zaplet even
in the
absence of the dynamic content and without having to get back to the zaplet
when
connected "on-line".
The mail formatter 24 may be implemented using a JSP construct.
The mail transport server 22 may use SMTP, and can be implemented using a
number of commercially available or open source e-mail servers, including
Sendmail
and the Exchange server.
The server 6 also includes an image server 28 that is used for connection to
the
participants 1-4. An image formatter 26 is connected to the image server 28.
The
image server 28 may be implemented using a web server (servlet). The image
server
~5 28 takes information from Hypertext Transfer Protocol ("HTTP") requests
from the
participants 1-4 and translates the information using predefined schemes into
human
viewable images that are encoded in a format compatible with known web
browsers.
The image server 28 may be configured separately from the web server 16, as
shown
in FIG. 2. This configuration may increase the scalability of the server 6.
2o Alternatively, the web server 16 and the image server 28 can be configured
together.
The image formatter 28 may be configured using a Java construct. The image
formatter 28 formats the image into a compliant standard, such as Graphical
Interchange Format ("GIF"), Joint Photographics Experts Group ("JPEG"), or
Portable Network Graphics ("PNG"), for the participants 1-4.
11
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
FIG. 3 illustrates an exemplary electronic form 100 that can be used to
compose and initiate a zaplet among the participants 1-4. The electronic form
may
be, for example, an HTML form. The electronic form 100 can be accessed via a
web
site sent by the server 6 to the participants 1-4, or may reside as a template
at the
participants 1-4.
The electronic form 100 can be stored in database 10, reside on a device of a
participant, such as in a memory of a computer, or can be sent to a
participant via a
communications protocol, such as e-mail. The electronic form 100 may be blank
or
partially completed. To partially complete the form, the server 6 may contain
prior
1 o knowledge of the use of the form using, for example, "cookies" or other
suitable
techniques.
The electronic form 100 includes a name field 101 that specifies the creating
participant's name and a network address field 102 that specifies a specific
address
associated with the creating participant, such as an e-mail address. The
electronic
form 100 can also include a network address field 103 that includes network
addresses of the participants that should receive the zaplet. The list of
network
addresses in the field 103 may include the network address of the creating
participant.
The list of network addresses may be explicitly inputted by the creating
participant
using a keyboard, imported from a folder or other file residing at the
creating
2o participant, or imported by the creating participant from a peripheral
device, such as a
Palm Pilot provided by 3Com. Alternatively, the creating participant can
provide the
list of network addresses to the server 6. In this configuration, the server 6
may input
the list of network addresses into the field 103, when the creating
participant accesses
the electronic form 100, as described below. This means that the field 103
will be
12
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
completed for the creating participant, when the electronic form 100 is
accessed. At
this stage, the creating participant may add or delete network addresses from
the list
provided by the server 6.
The electronic form 100 may also include a subject field 104 and any number
s of question, choice or comment fields 105. The creating participant may
describe the
subject matter of the zaplet in the subject field 104 and supply details
regarding the
zaplet, in the comment field 105. In one configuration, each of the fields
101, 102,
103, 104, and 105 are part of a static region. The electronic form 100 may
also
include other applicable fields, such as for a title of the zaplet, fields for
soliciting
information from the participant, such as his/her address, links to other
zaplets, a
description field to receive an input, such as a URL, an image or binary data
field, or
option fields to specify choices, such as a poll choice.
The electronic form 100 can be used to initiate a variety of zaplets for
different
applications, which are herein referred to as "zaplet processes". Once the
electronic
15 form 100 is created, it is sent to the server 6. The server 6 then sends an
e-mail
message to the participants listed in the network address field 103 to notify
the
receiving participants that a zaplet process has been initiated. The e-mail
message is
opened and parsed, and the zaplet is essentially immediately accessed from the
server
6 as described below.
2o FIG. 4 shows a suitable data structure for a zaplet process.
The data structure 350 can be based, for example, on HTML over SMTP using
MIME. The data structure 200 includes SMTP and MIME headers 300. These
headers 300 include an indication that the message is a multipart/alternative
type
according to the NN11ME standard. The multipart/alternative type specifies
that the
13
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
participant is configured to display one alternative format or content-type of
the
message selected from a segment 302 and a segment 304, depending on the
capability
of the software of the participant parsing the message.
The data structure 350 may define a transport envelope with region 300
s containing a plurality of network addresses, such as the e-mail address of a
sending
and receiving participant.
A MIME separator 301 may be inserted between headers 300 and segments
302 and also between segments 302 and 304.
The segment 302 may also include a plain text message that is displayed if the
participant does not have the capability to display regions 310 and 313 of
segment
304, described below, according to the multipart/alternative message type
indicated in
the headers 300. For example, the segment 302 can include a command
instructing a
participant that he or she may view a web page corresponding to the segment
304.
The segment 304 may include a rich text HTML document, including any
~5 number of dynamic regions 310, HTML forms 311, static HTML content regions
312, and IFRAME/ILAYER regions 313. The dynamic content region 310 can
include a command to dynamic content 320 of the zaplet, stored remotely such
as in
the database 10 of the server 6 on the network 5. The IFRAME/ILAYER region 313
may include a command to access dynamic content 321 of the zaplet, stored
remotely
2o such as in the database 10 or at the server 6 on the network 5. The dynamic
content
321 may be in the same location as the first dynamic content 320, or may be in
a
different location in database 10. Each dynamic content region 310 and 313 may
have content that includes more than one dynamically updated construct or
image.
14
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
The form 311 can be used to receive input from a participant, and the region
312 can be used to provide static information/processes that are independent
of the
current zaplet process.
The segment 304 may also include a region 330 that can be used to store a
command indicating a web page storing the content of the segment 304. This
configuration can be used when a participant attempts to forward the zaplet to
another
participant connected to a server that cannot support the segment 304. In this
way,
the participant can still view the content of segment 304, and is therefore
not dropped
from the group.
In FIG. 4, a MIME separator 305 is configured between the segment 304 and a
segment 306.
The segment 306 can include MIME encoded image data to be displayed in
the HTML message of segment 304. The image data may include images for logos
or
photos that can be accessed by the participant even if the server 6 is not
accessible.
The optional segment 306 is followed by a MIME separator 307.
The structure 350 can be used to provide a high quality of service to various
classes of participants based upon their e-mail client application
capabilities. Five
classes of "e-mail clients" include new P.C. e-mail clients, web e-mail
clients, older
P.C. e-mail clients, text e-mail clients, and America On-Line ("AOL") e-mail
clients.
2o The functionality in the segment 304 is provided to new P.C. e-mail clients
completely. Some web e-mail clients do not allow use of an IFRAME/ILAYER tag
to display dynamic content 321 of the dynamic content region 313. In this
case, the
participant gets a static message directing the participant to a web
representation, or a
dynamic image displaying the same up-to-date data is served by the image
server 28.
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
Many older P.C. e-mail clients, and all of the text e-mail clients cannot
display the
segment 304. These participants may receive an e-mail message with static
content,
and a URL identifying a web page at which the dynamic content may be accessed.
Current AOL clients support some of the HTML standard.
It has also been found that the server 6 can be configured to identify the
capability of a participant. For example, the server 6 can be configured to
automatically send the zaplet to the participant by recognizing the suffix
"aol.com" in
the participant's network address. Alternatively, the participant can specify
which e-
mail client to use by sending a request to the server 6.
FIG. 5 shows an example of an image of a zaplet 200 that is displayed to a
participant when the data structure 350 is parsed. The zaplet may include a
title field
201 that contains static content similar to the information inputted in fields
101, 102,
104, and 105. Preferably, the above static content is displayed each time the
zaplet
200 is accessed by a participant. The zaplet 200 may also include an
advertising
15 region 203. The content in region 203 can be static or dynamic content. The
content
in regions 201 and 203 can be configured and supplied by the business logic in
web
application server 14.
The zaplet 200 also includes a forwarding region 205 and a creation region
206 corresponding to segment 312 of the data structure 350. The region 205
allows a
2o participant to add an address of a potential participant that is not listed
in the address
field 103. This means that any participant listed in the address list of field
103 can
include any other potential participants not listed in the field 103. In other
configurations, the ability of a participant to add another participant can be
controlled
by the creating participant of the zaplet.
16
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
The creation region 206 is also included in zaplet 200 to allow a participant
to
create an electronic form similar to electronic form 100 to initiate another
zaplet
process.
The zaplet 200 also includes a dynamic content region 210 corresponding to
segment 310 of data structure 350 that receives the dynamic content 320. In
one
configuration, region 210 may include a graphical image, such as a pie chart,
or other
binary content including executable content. The content 320 of the region 210
can
be dynamically updated by the business logic residing in the web application
server
14.
1 o The zaplet 200 also includes an interaction region 225 corresponding to
segment 312 of the data structure 350. The interaction region can include
images,
such as check boxes, to select options created using the electronic form 100.
For
example, a poll can be initiated in electronic form 100 and the interaction
region 225
could contain boxes to select a poll choice. The interaction region also
contains a text
15 box 223 that allows a participant to add a text passage to the zaplet. The
interaction
region may also include the name of the responding participant and his or her
associated e-mail address.
A dynamic content region 213 corresponding to region 313 of data structure
350 is contained in zaplet 200 that receives the content 321. The content 321
can
2o include text passages that are entered by participants using the
interaction region 225.
The business logic at the web application server 14 manages the text passages
and
causes changes to the variables in database 10 to update the content 321 and
to
display the updated content in region 213, when the participant opens the
message.
17
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
The displayed content in region 213 may include visual images, a list of
participants
who have entered text passages, or any other relevant dynamic content.
FIG. 6 illustrates that initially one of the participants accesses a live
electronic
form 100 to begin a zaplet process (step 501). The requesting participant may
access
the form 100 from the database 10 via the web server 16, from a web site, or
other
resource as discussed above. To access the electronic form 100, the
participant may
specify a descriptor, such as a URL, associated with the electronic form 100.
Once
the electronic form 100 is displayed to the participant, the participant
completes the
fields 101, 102, 103, and 104. The participant may also complete field 105.
The
1 o participant then submits the form to the server 6 (step 502).
Next, a confirmation message is sent from the web server 16 indicating that
the content of the electronic form 100 was received, that the electronic form
100 was
sent to the addresses listed in field 103, and any other errors associated
with the
processing of the electronic form 100 (step 503). Alternatively, the creating
participant of the electronic form 100 may receive the e-mail message (step
504)
described below as an acknowledgement that the form 100 was successfully
received
by the server 6.
Each of the participants in the list in field 103 receives an e-mail message
associated with the zaplet (step 504) indicating that the zaplet process has
been
2o initiated. Next, a receiving participant opens the message (step 505). In
one
configuration, a receiving participant may be the creating participant. This
mechanism could allow a creating participant to create a "personal" zaplet
that only
he or she could update or retrieve. Once the receiving participant opens the e-
mail
18
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
message, the dynamic content of the zaplet 200 is served essentially at
viewing time
to the display of the participant as follows (step 506).
Referring to FIG. 7, the e-mail protocol residing at the participant begins by
parsing the received e-mail according to the MIME and SMTP header and
separators
300 (step 401). If the participant is capable of displaying the dynamic
content of the
zaplet in the segment 304, content is produced by parsing the HTML (step 402).
The
participant initially renders static components of the zaplet, such as in the
regions 311
and 312 (step 403). To render the dynamic content in region 310, a parsing
engine at
the participant issues a get command using, for example, a virtual URL
identified by a
tag field in the HTML (step 404). The server 6 includes logic, such as
business logic
in web application server 14, to map the virtual URL to an actual URL for the
dynamic content 320 of the dynamic content region 310, and returns a message
indicating the actual URL for the dynamic content 320 corresponding to the
virtual
URL, which is received at the participant site (step 405). A get command for
the
15 actual URL is then issued (step 406). A web page indicated by the
IFRAME/ILAYER region 313 of the data structure 350 can also be retrieved
similar
to steps 404-406 (step 407), and then the dynamic content 321 for the dynamic
content region 313 is rendered (step 408).
Referring again to FIG. 6, once the zaplet 200 is retrieved by the
participant,
2o he or she inputs data into the interaction region 225 (step 507). For
example, the user
may input a text passage. At this stage, the dynamic content region 213 will
include
concatenated text messages and a list of message recipients as discussed
above. The
participant then submits the updated zaplet to the server 6 (step 508). Next,
the
submitting participant receives an acknowledgement from the web server 16
19
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
indicating that the zaplet was received (step 509). The e-mail protocol
residing at the
client may then issue at any time a new get command for the dynamic content in
region 310 and/or region 313 to display the updated images and/or text content
in the
dynamic content regions 210 and 213 (step 510). Alternatively, after the
participant
submits his or her input (step 508), another instance of the zaplet could be
served that
includes the above acknowledgement, and also reflects the most recent dynamic
content including the submission at step 508. In another configuration, the
dynamic
content of the zaplet could be updated "in-place". This means that the regions
210
and 213 could be updated to reflect the most recent content in the server 6
including
the submission at step 508, as the participant is viewing the zaplet.
Subsequent
actions by any of the participants of the group to open a message will result
in the
display of the updated images and text content in the zaplet 200.
Participants collaborate efficiently. Each participant can send and receive
information that is current using dynamic regions 210 and 213. This means that
participants can accurately respond or opine to a zaplet process with the most
current
information at their disposal.
Privacy in communications in supported because the dynamic content can be
restricted to those specified in field 103. Further, content may be
dynamically
updated asynchronously relative to the sending of the documents or forms and
2o asynchronously relative to any processes used by any other participants
parsing the
electronic messages. In this way, the zaplets received by participants of the
group do
not become stale or outdated. Additionally, the updated content includes
dynamic
information identifying changes that have occurred since the message was last
viewed
by the viewing participant. This means that the viewing participant can track
the
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
opinions, suggestions, or other comments made by other participants in a
simple and
quick manner. The preferred method also allows participants to interact with
other
participants in a group without the daunting task of "surfing" the Web to find
the
discussion management tool that manages the discussion. The highest quality
service
based upon the participant's e-mail application capabilities are also
provided.
A zaplet 200 generally passes through states from the instant that the
initiating
participant (e.g., author) starts defining the electronic form 100 until the
zaplet 200 is
discarded or deleted. A state can be defined by the behavior of the zaplet 200
and
operations available to the author or recipient of the zaplet 200. This means
that the
1 o zaplet 200 can change states numerous times. Tracking and managing such
states
may be important to conserve network resources and provide enhanced
flexibility to a
participant.
FIGS. 8-19 describe various processes for tracking or managing zaplets 200.
The processes may be applied to one or more portions or types of content of
the
zaplet.
FIG. 8 illustrates a flow chart describing a process for delayed sending of a
zaplet. This process enables a participant to begin creating the zaplet 200 by
completing an electronic form 100 (Step 601), as described above. The
electronic
form 100, however, may not be completed at Step 601. Accordingly, a partially
2o completed electronic form 100 may be stored in the database 10 or in a
local folder
(Step 602). Thereafter, the initiating participant may exit, for example, a
web site
(Step 603). The initiating participant may then access the partially completed
electronic form 100 from the database 10 (Step 605) or from a folder e.g.
"MyZaplets" folder (Step 604). The electronic form 100 may subsequently be
21
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
completed (Step 605) and then sent to server 6 (Step 606) and processed, as
described
above. Finally, the initiating participant completes the authoring process
(Step 607).
FIG. 9 illustrates a flow chart describing a process for shared authoring of a
zaplet. This process allows multiple participants to create a zaplet 200 by
completing
an electronic form 100 (Step 701), as described above. The electronic form
100,
however, may not be completed at Step 701. After the electronic form 100 is
partially
completed (Step 702), the initiating participant may define a co-author list
to add
other participants to author the electronic form 100 (Step 703). The partially
completed electronic form 100 and the co-author list may be stored in the
database 10
or in a local folder (Step 703). Thereafter, the initiating participant may
notify the
other listed participants of the ability to author the electronic form 100
(Step 704).
Alternatively, the server 6 may notify the other listed participants. The
other listed
participants may then access the partially completed electronic form 100 from
the
database 10 (Step 706), from a folder e.g., "MyZaplet drafts" folder (Step
705), or a
link may be sent to allow the participant to access the form 100. The other
participants may then add to the electronic form 100 (Step 706), which is then
sent to
server 6 (Step 707) and processed, as described above. At Step 706, other
participants
can be notified and the process repeats from Step 704, until the electronic
form 100 is
completed. Finally, the authoring process is finished (Step 708).
2o FIG. 10 illustrates a flow chart describing a process for cloning a zaplet.
This
process allows a participant to copy or clone one or more portions of a
zaplet. This
leads to quick and efficient initiation or creation of a zaplet. An initiating
participant
can clone an existing zaplet 200 by using its static content, dynamic content,
and/or
network address list to generate a new zaplet. Initially, an initiating
participant may
22
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
select a button or link within an existing zaplet 200 to generate a new zaplet
(Step
801). The initiating participant is then prompted to copy or clone the
responses or
content in regions 310 and/or 313 (Step 802). If Step 802 is executed, the
information
is copied (808) and sent to the server 6 to initiate a new authoring process
e.g., to
s create a new electronic form 100 (Step 807). If Step 802 is not executed,
the initiating
participant is prompted to clone or copy the content from an electronic form
100 used
to create the zaplet 200 (Step 803). If Step 803 is executed, the content of
the
electronic form 100 is copied and sent to the server 6 (Step 804). After Step
804 or if
Step 803 is not executed, the initiating participant is prompted to clone the
network
address list of the zaplet 200 (Step 805). If Step 805 is executed, the
network address
list is copied and sent to the server 6 (Step 806). If Step 805 is not
executed, the
authoring process is executed at Step 807.
FIG. 11 illustrates a flow chart describing a process for notifying a
participant
of a zaplet. This process allows an initiating participant or other
participants to notify
~s others of changes to the zaplet 200 (Step 901). The participant may then
select to
identify all or some of the participants (Step 902). If all of the
participants are
selected, the participant describes the reason for the notification (Step
904). The
reason may also be automatically discernable by configuring the business logic
described above. If a subset of the participants is selected at Step 902, the
participant
2o selects a subset from, for example, the network address list of field 103
(Step 903).
Then, Step 904 is executed. The notification can also be prioritized (Step
905). The
notification is then sent by the server 6 (Step 906). The server determines
the type of
notification required by the participant (Step 907). For a client, a flag may
be set in
server 6 which may be polled for by the participant at some time interval and
the
23
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
content of the notification retrieved from server 6 (Step 908). For
participants using
e-mail, a new copy of the zaplet may be sent which also contains the
description and
priority of the notification (Step 909). Alternatively, a participant equipped
with a
facsimile machine may receive a new copy or version of the zaplet. A link may
be
. sent to participants equipped with instant messaging (Step 910). A link may
also be
sent to a pager, PDA, or other similar computing device. A time stamp for the
notification may be stored in database 10 for participants equipped with
instant
messaging and/or e-mail. A suitable time stamp mechanism is described at step
1210
below.
FIG. 12 illustrates a flow chart describing a process for blocking access to a
zaplet. This process allows a participant to temporarily block other
participants from
reading the dynamic content of a zaplet 200 or responding to a zaplet 200. The
participant initiates a command to block access to the zaplet (Step 1001).
Next, the
participant enters the management interface for this zaplet, which is located,
for
~ 5 example, in the server 6 (Step 1002). The participant then sets a flag in
the database
and describes the reason for the blocking (Step 1003). In one example, the
participant may block access to the dynamic content in regions 310, 313. Thus,
the
other participants only receive the static content and the reason for the
block (Step
1004). Once the reason for the block is resolved (Step 1005), the description
for the
2o block is deleted and the flag is cleared in the database 10 (Step 1006).
The zaplet is
then available for normal access (Step 1007).
FIG. 13 illustrates a flow chart describing a process for controlling
responses
to a zaplet. This allows an initiating participant to prevent or to allow
other
participants to respond to a zaplet 200. First, the initiating participant is
asked or asks
24
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
to close interaction to the zaplet 200 (Step 1101). The initiating participant
then
enters the management interface similar to Step 1002 above (Step 1102). The
initiating participant then specifies the reason for the closure and sets a
state of the
zaplet 200 in the database 10 (Step 1103). The receiving participants with a
current
s version of the zaplet 200 see the static content, the dynamic content, a
closed state
indicator, and the reason for the closure (Step 1104). The receiving
participants are
not permitted to respond to the zaplet. The participants receiving a prior
closed zaplet
200 may see the static content, some of the dynamic content is cast as static
content,
and at least one dynamic content region 310, 313 exists to deliver dynamic
content, if
1 o the zaplet is re-opened (Step 1104). The participants are then notified of
the closure
directly by the initiating participant or by the server 6 (Step 1105). The
initiating
participant has then drawn attention to the fact that the zaplet 200 is closed
(Step
1106).
A closed zaplet may be re-opened for further processing or interaction. To re-
15 open the zaplet 200, the initiating participant begins the re-opening
procedure (Step
1107). Step 1108 is then executed similar to Step 1102 above. Next, the reason
for
opening may be described and the state of the zaplet is set to open in the
database 10
(Step 1109). The receiving participants with a current version of the zaplet
200 see
the dynamic content, the static content, optionally an open state indicator,
and
20 optionally the reason for the opening (Step 1110). The participants are
permitted to
respond to the zaplet. The participants receiving a prior closed zaplet 200
see the
static content and at least one dynamic content region 310, 313 exists to
deliver
dynamic content, or a link to the dynamic content, when the zaplet is opened
(Step
1110). Instructions may be sent to retrieve the dynamic content. The
participants are
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
then notified of the opening directly by the initiating participant or by the
server 6
(Step 1111). The initiating participant has then drawn attention to the fact
that the
zaplet 200 is re-opened (Step 1106).
A participant may be notified of changes to zaplets of special interest. The
notifications may be timed to avoid sending a notification for every change.
In one
embodiment, a notification for every change is avoided by sending
notifications based
upon knowledge of when a participant has viewed any previous version of the
zaplet.
FIG. 14 illustrates a flow chart describing a process for notifying
participants
of changes to a zaplet. In one embodiment, the participant may desire to
change a
1o default notification for the zaplet 200 (Step 1201). The participant
responds to
receiving the zaplet 200 with notification preferences e.g., all responses,
important
events, resolution of the zaplet, no interest in special notification, or no
responses.
The preferences for this participant may be stored in the database 10, and the
zaplet
may then be dynamically updated to indicate the preference of this
notification state
(Step 1202).
In one example, an important response is received or an important event
occurs within a zaplet 200 and may be recorded within and displayed within a
zaplet
200 (Steps 1203-1204). A check is made to see if the participant has
previously
decided whether to track the important events or responses (Step 1205). If no,
a
2o check is made to see if the participant has previously asked to track all
responses
(Step 1206). Similarly, a normal response occurring in a zaplet 200 (Step
1207)
executes Step 1206. If the answer is yes at Step 1205 or Step 1206 when
executed,
the participant's chosen method for receiving the notifications is determined
(Step
1208). The participant may choose "Digest" (Step 1209), "Immediate" (Step
1213),
26
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
or "Interval" (Step 1211). Digest allows a participant to tag the zaplet 200
to be
delivered at a later time. This can be accomplished within a zaplet 200
containing a
list of other zaplets. Interval permits a time interval specified by the
participant to
elapse since the recipient last accessed the zaplet 200 before sending a
notification. If
Immediate or Interval is selected, the server 6 determines whether the
participant has
viewed the zaplet 200 since the most recent notification has been sent (Step
1210). If
no, the notification is not sent. This is because the participant may view new
content
that is part of this current notification, when as previous notification is
opened (Step
1212). On the other hand, if all prior notifications have been viewed, the
notification
is sent by the server 6 (Step 1214).
FIG. 15 illustrates a flow chart describing a process for superseding a
zaplet.
This process allows an initiating participant to supersede a zaplet 200 with a
different
zaplet. This may be due to an initiating participant having made an error in
the static
portion of the superseded zaplet. Initially, the initiating participant
invokes a
~5 command to supersede an existing zaplet (Step 1301). The participant then
enters the
management interface similar to Step 1102 above (Step 1302). The initiating
participant specifies the reason for the superseding (Step 1303) and then
selects a
method for the superseding (Step 1304). The participant may clone the zaplet
(Step
1305), as described above in FIG. 10. In this case, the authoring process is
started
20 (Step 1306) and finished (Step 1307) by the participant and the server 6.
Alternatively, the initiating participant can choose from a list of zaplets or
provide a
URL to that represents a zaplet 200 to replace the current zaplet 200 (Step
1308).
Next, the state of the current zaplet as superseded is set in the database 10.
The server
6 is configured to label the current zaplet 200 superseded, to describe the
reason that
27
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
the zaplet 200 has been superseded, to prevent further interaction with the
superseded
zaplet 200, and also provide a links to the new zaplet (Step 1309). The zaplet
is then
superseded (Step 1310).
FIG. 16 illustrates a flow chart describing a process for externalizing or
restoring a zaplet. The participant can externalize the state of a zaplet. The
participant first asks to externalize the state of the zaplet 200 (Step 1401).
Next, the
participant enters the management interface similar to Step 1102 above (Step
1402).
The participant may then pick an externalization format (Step 1403). For
example,
the participant may choose HTML. In this case, a page with dynamic content is
1 o rendered as static HTML (Step 1404). Thereafter, the participant may save
the page
to disk or the database 10 (Step 1405). Alternatively, the participant may
choose
XMI, at Step 1403. A page is then generated that has definition and data of
the zaplet
rendered as XML (Step 1406). The participant may then save the page to disk or
the
database 10 (Step 1408). Other formats of externalized zaplets may be used.
~5 To restore a zaplet, the participant is first prompted (Step 1407). The
participant then enters the management interface similar to Step 1102 above
(Step
1409). Subsequently, the XML definition is uploaded from the database 10 or
disk
(Step 1410). The current state of the zaplet represented by the XML definition
is then
restored within server 6 and database 10 (Step 1411). The participant may then
draw
2o special attention to the zaplet using a notification mechanism similar to
that described
above (Step 1412). Other formats of externalized zaplets may be used.
FIG. 17 illustrates a flow chart describing a process for archiving a zaplet.
The participant is first prompted to archive the zaplet 200 (Step 1501). Next,
the
participant enters the management interface similar to Step 1102 above (Step
1502).
28
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
Data may be formatted, compressed and moved into an archived storage in
database
or another database. Information may also be split between multiple databases.
The participant also sets an auto-restore flag or a read-only flag in the
database 10. A
reason for the archival may also be set. A state of the zaplet is set to
archived and a
5 prior state of the zaplet 200 is also stored. Moreover, participants may
only be able to
view the indication of the archived state and may also be able to view one or
more
portions of the non-archived content. Archived content may be viewed if the
auto-
restore flag is set to "on." (Step 1503). The participant may also externalize
the zaplet
similar to Steps 1406 and 1408 above (Step 1504 and Step 1505). This creates a
snapshot of the state of a zaplet 200without changing the status of the
zaplet.
To restore an archived zaplet, the participant is first prompted (Step 1506).
Next, the participant enters a management interface similar to Step 1102 above
and
then selects the archived zaplet from a list in database 10 (Step 1507). The
selected
zaplet is retrieved from the database, the compressed data is uncompressed,
and XML
or other suitable format is used to populate the database structure to
regenerate the
zaplet to an original state (Step 1508). Optionally, the auto-restore tags may
be
monitored (Step 1510). The participant may then draw special attention to the
zaplet
as described above (Step 1509).
FIG. 18 illustrates a flow chart describing a process for permanently deleting
a
2o zaplet. Initially, the initiating participant is prompted to delete a
zaplet (Step 1601).
Then, the participant enters the management interface as described in Step
1102 (Step
1602). Next, the zaplet is marked as deleted and the deleted zaplet may appear
on the
participant's "deleted" list. Other participants may be notified of the delete
status
once the server confirms this state (Step 1603). The participant may
explicitly finish
29
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
deleting the zaplet (Step 1605) or have the zaplet lapse over time (Step
1604). The
zaplet is ultimately removed from the database 10 (Step 1606). Other
participants
may also delete their own individual copies of the zaplet without affecting
other
copies of the zaplet stored in the database 10.
Changes that have been previously viewed may optionally be de-emphasized
using certain rendering techniques in favor of those to be viewed. Suitable
rendering
techniques may be based on color, font, face, graphics, size, saturation, and
position.
In one example, as shown in FIG. 19, the participant opens the zaplet (Step
1701).
While constructing the dynamic content of the zaplet 200 (Step 1702), newer
responses to the zaplet 200 can be highlighted, while older responses can be
de-
emphasized. The time of the responses can also be tracked to determine which
content has been previously viewed.
The methods and mechanisms described here are not limited to any particular
hardware or software configuration, or to any particular communications
modality,
~ 5 but rather they may fmd applicability in any communications or computer
network
environment.
The techniques described here may be implemented in hardware or sofiware,
or a combination of the two. Preferably, the techniques are implemented in
computer
programs executing one or more programmable computers that each includes a
2o processor, a storage medium readable by the processor (including volatile
and non-
volatile memory and/or storage elements), and suitable input and output
devices. The
programmable computers may be either general-purpose computers or special-
purpose, embedded systems. In either case, program code is applied to data
entered
with or received from an input device to perform the functions described and
to
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
generate output information. The output information is applied to one or more
output
devices.
Each program is preferably implemented in a high level procedural or object-
oriented programming language to communicate with a computer system. However,
the programs can be implemented in assembly or machine language, if desired.
In
any case, the language may be a compiled or interpreted language.
Each such computer program is preferably stored on a storage medium or
device (e.g., CD-ROM, hard disk, magnetic diskette, or memory chip) that is
readable
by a general or special purpose programmable computer for configuring and
operating
the computer when the storage medium or device is read by the computer to
perform
the procedures described. The system also may be implemented as a computer-
readable storage medium, configured with a computer program, where the storage
medium so configured causes a computer to operate in a specific and predefined
manner.
15 A number of embodiments of the present invention have been described.
Nevertheless, it will be understood that various modifications may be made
without
departing from the spirit and scope of the invention.
31
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
APPENDIX A
1 Deliver Electronic (Authoring) Form
get ZAPLET_TYPE, ZAPLET_STYLE from request
open file ELECTRONIC_FORM for writing
write Creating Participant_Input_Field(ZAPLET_TYPE, ZAPLET_STYLE) to
ELECTRONIC_FORM
write Creating Participant_Email_Input_Field(ZAPLET_TYPE, ZAPLET_STYLE)
to
ELECTRONIC_FORM
write Subject_Input_Field(ZAPLET_TYPE, ZAPLET_STYLE) to
ELECTRONIC_FORM
write Recipients_Input_Field(ZAPLET_TYPE, ZAPLET_STYLE) to
ELECTRONIC_FORM
write Zaplet_Specific_Data_Input_Fields(ZAPLET TYPE, ZAPLET_STYLE) to
ELECTRONIC FORM -
write Zaplet_Type Constant(ZAPLET_TYPE, ZAPLET_STYLE) to
ELECTRONIC_FORM
write Zaplet_Style_Constant(ZAPLET_TYPE, ZAPLET_STYLE) to
ELECTRONIC_FORM
2o write Static_Form_Content(ZAPLET_TYPE, ZAPLET_STYLE) to
ELECTRONIC FORM
open stream CLIENT for writing
write ELECTRONIC FORM to CLIENT
2 Receive Electronic (Authoring) Form Input and Send Mail
get CREATING_PARTICIPANT_NAME, CREATING_PARTICIPANT_EMAIL,
so SUBJECT,
ZAPLET_TYPE,
ZAPLET_STYLE, ZAPLET SPECIFIC_DATA, RECIPIENTS from request
set MESSAGE_ID = create unique id()
open file MESSAGE for writing
create (Message Record(MESSAGE_ID, CREATING_PARTICIPANT NAME,
CREATING_PARTICIPANT_EMAIL,
SUBJECT, ZAPLET_TYPE, ZAPLET STYLE,
ZAPLET_SPECIFIC_DATA, RECIPIENTS)) in
database
4o write MESSAGE_ID, CREATING_PARTICIPANT_NAME,
CREATING_PARTICIPANT_EMAIL,
SUBJECT, ZAPLET_TYPE, ZAPLET_STYLE,
ZAPLET_SPECIFIC_DATA, RECIPIENTS to
MES SAGE
if (User_Record(CREATING PARTICIPANT EMAIL) not_exists in database) ~
create User_Record(CREATING PARTICIPANT EMAIL,
CREATING PARTICIPANT NAME)
32
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
in database
for each (USER EMAIL in RECIPIENTS){
if (User Record(USER EMAIL) not_exists_in database) {
create User Record(LTSER EMAIL) in database
for each (QUESTION in request) {
set QUESTION_ID = create_unique_id()
1o get QUESTION CONTENT from request
write QUESTION_ID, QUESTION_CONTENT to MESSAGE in database
for each (CHOICE in QUESTION) {
set CHOICE_ID = create_unique_id()
write CHOICE ID, CHOICE to MESSAGE
open file MAIL for writing
write (Transport Headers(MESSAGE)) to MAIL
2o write ("From: " + Creating Participant(MESSAGE)) to MAIL
write ("To: " + Recipients(MESSAGE)) to MAIL
write ("Subject: " + Subject(MESSAGE)) to MAIL
write (Encoding Headers(MESSAGE)) to MAIL
write (ENCODING SEPARATOR) to MAIL
write (PLAIN TEXT ENCODING LABEL) to MAIL
write (Plain_Text_Static_Portion(MESSAGE)) to MAIL
write (URL(MESSAGE)) to MAIL
so write (ENCODING SEPARATOR) to MAIL
write (RICH TEXT ENCODING LABEL) to MAIL
write (Rich Text Static Portion(MES SAGE)) to MAIL
for each (QUESTION in MESSAGE) {
write (Interaction Form(QUESTION)) to MAIL
write (Static Portion(QUESTION)) to MAIL
write (Dynamic Image Portion(QUESTION)) to MAIL
write (IFRAME_ILAYER_Portion(QUESTION)) to MAIL
write (IFRAME ILAYER Alternative Portion(QUESTION)) to MAIL
write (ENCODING SEPARATOR) to MAIL
if (SUPPORT IMAGE DATA)
write (Image Data(MESSAGE)) to MAIL
open stream TRANSPORT_SERVER for writing
write MAIL to TRANSPORT SERVER
open file REPLY for writing
33
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
write Confirmation_Message(MAIL) to REPLY
open stream CLIENT for writing
write REPLY to CLIENT
3 Serve Dynamic Rich-Text Contents
get MESSAGE_ID from request
load MESSAGE by MESSAGE_ID from database
open file REPLY for writing
for each (QUESTION in MESSAGE) {
write (Format_Dynamic_Portion(QUESTION)) to REPLY
for each (RESPONSE in QUESTION) {
write (Format_Dynamic_Portion(RESPONSE)) to REPLY
open stream CLIENT for writing
write REPLY to CLIENT
4 Serve Dynamic Image Contents
get MESSAGE_ID, QUESTION_ID from request
load QUESTION by QUESTION_ID from database
open file IMAGE for writing
write (Format Image(QUESTION, Summarize(Responses(QUESTION)))) to
IMAGE
open stream CLIENT for writing
3o write IMAGE to CLIENT
5 Receive Response Form Input
get MESSAGE_ID, QUESTION_ID, RESPONDER NAME,
RESPONDER_EMAIL, COMMENT,
QUESTION_SPECIFIC_INFO from request
if (User Record(RESPONDER EMAIL) not_exists_in database) {
create User_Record(RESPONDER_EMAIL, RESPONDER_NAME) in
4o database
)
if (Allowed_To_Respond(RESPONDER_EMAIL, QUESTION) {
create or_update Response Record(MESSAGE_ID, QUESTION_ID,
RESPONDER EMAIL,
COMMENT, QUESTION SPECIFIC INFO) in database
) _ _
open file REPLY for writing
34
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
get MESSAGE by MESSAGE_ID from database
write (Confirmation View(MESSAGE)) to REPLY
open stream CLIENT for writing
write REPLY to CLIENT
6 Resend or Forward Message
get MESSAGE_ID, NEW RECIPIENT_EMAILS from request
for each (USER EMAIL in NEW_RECIPIENT EMAILS){
if (User Record(USER EMAIL) not_exists_in database) ~
1 o create User Record(USER EMAIL) in database
get MESSAGE by MESSAGE_ID from database
~5 set Recipients(MESSAGE) = Recipients(MESSAGE)+NEW RECIPIENT EMAILS
update Message Record(MESSAGE) in database
open file MAIL for writing
write (Transport Headers(MESSAGE)) to MAIL
write ("From: " + Creating Participant(MESSAGE)) to MAIL
2o write ("To: " + NEW_RECIPIENT_EMAILS) to MAIL
write ("Subject: " + Subject(MESSAGE)) to MAIL
write (Encoding Headers(MESSAGE)) to MAIL
write (ENCODING SEPARATOR) to MAIL
25 write (PLAIN TEXT ENCODING LABEL) to MAIL
write (Plain_Text_Static_Portion(MESSAGE)) to MAIL
write (URL(MESSAGE)) to MAIL
write (ENCODING SEPARATOR) to MAIL
3o write (RICH TEXT ENCODING LABEL) to MAIL
write (Rich_Text_Static_Portion(MESSAGE)) to MAIL
foreach (QUESTION in MESSAGE) {
write (Interaction Form(QUESTION)) to MAIL
write (Static Portion(QUESTION)) to MAIL
35 write (Dynamic Image_Portion(QUESTION)) to MAIL
write (IFRAME_ILAYER_Portion(QUESTION)) to MAIL
write (IFRAME ILAYER Alternative Portion(QUESTION)) to MAIL
write (ENCODING SEPARATOR) to MAIL
4o if (SUPPORT IMAGE DATA)
write (Image Data(MESSAGE)) to MAIL
open stream TRANSPORT_SERVER for writing
write MAIL to TRANSPORT SERVER
open file REPLY for writing
write Confirmation Message(MAIL) to REPLY
CA 02396371 2002-07-15
WO 01/52081 PCT/USO1/01088
open stream CLIENT for writing
write REPLY to CLIENT
10075143.doc
36
