+

WO2002001374A1 - Logiciel de courrier electronique avec composant modulaire integre de creation et de lecture - Google Patents

Logiciel de courrier electronique avec composant modulaire integre de creation et de lecture Download PDF

Info

Publication number
WO2002001374A1
WO2002001374A1 PCT/US2001/020349 US0120349W WO0201374A1 WO 2002001374 A1 WO2002001374 A1 WO 2002001374A1 US 0120349 W US0120349 W US 0120349W WO 0201374 A1 WO0201374 A1 WO 0201374A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
component
electronic mail
authoring
email
Prior art date
Application number
PCT/US2001/020349
Other languages
English (en)
Inventor
Michelle Baker
Original Assignee
Intellinet, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/604,428 external-priority patent/US7444374B1/en
Application filed by Intellinet, Inc. filed Critical Intellinet, Inc.
Priority to AU2001271494A priority Critical patent/AU2001271494A1/en
Publication of WO2002001374A1 publication Critical patent/WO2002001374A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/18—Commands or executable codes

Definitions

  • the invention relates to an electronic mail program. More particularly, the invention relates to an electronic mail program having modular integral authoring/reading applications whereby documents created with the modular integral authoring/reading applications are seamlessly sent and received by the mail program and which provides different kinds of interactivity with and different kinds of access to electronic mail messages depending on user types or roles.
  • the original Internet mail system as defined in 1982 with RFC (Request for Comments) 821 and 822 had a number of important limitations.
  • the system was not designed to carry large quantities of arbitrary data in an email message.
  • the 1982 SMTP (Simple Mail Transport Protocol) standard required that an email message consist of a single message containing only ASCII characters in lines of 1000 characters (blocks of 32k) or less.
  • some implementations of SMTP or other mail transport systems (such as UUCP) restricted message lengths to some allowed maximum number of bytes. Lengthy messages passing through a mail gateway using one of these implementations were likely to be truncated.
  • MIME Multipurpose Internet Mail Extensions
  • the MIME standard describes how an email message should be formatted in order to be considered MIME compliant.
  • MJ E defines a set of message header fields and a set of message encoding standards that are designed to overcome the limitations of RFC 822 message formats and still be transportable through any of the numerous legacy mail transport systems in use on the Internet.
  • MIME message header fields extend those defined in RFC 822 and describe the content and encoding type of the email message.
  • Encoding schemes allowed in the MIME standard include "quoted-printable", and "base64”. In addition, three unencoded data types are allowed. These are labeled "8bit”, "7bit", or "binary”.
  • the receiver's email program should automatically apply the appropriate decoding to the attached binary file and produce a file which is identical to the file which was attached to the email by the sender.
  • the recipient may receive a file which must be decoded by the recipient using a separate decoding program.
  • the receiver of the file Even after the file is properly received and decoded, it is often difficult for the receiver of the file to open the file.
  • the receiver of the file might expect that "clicking" on the file icon will open the file. However, clicking on the file icon will often not open the file. It may result in an error message like "application not found” or, worse, it may result in the file being opened by an inappropriate apphcation thereby displaying "gibberish".
  • the receiver of the file must have a program capable of reading (opening) the file. For example, if one attaches a spreadsheet file to an email message, the receiver of the file must have a spreadsheet program in order to open the file. Technically, it is not necessary that the receiver of the file have the same brand program as that which created the file.
  • Electronic mail is used by vendors to advertise goods and such electronic mail may typically include a hyperlink which, if clicked on, will cause the mail recipient's computer to launch a web browser and connect to the vendor's website where the goods may be purchased.
  • Electronic mail is also used by online vendors to provide customer support by answering questions sent to the vendor via electronic mail and to confirm online purchases by sending electronic mail to the purchaser.
  • My previously incorporated parent apphcation discloses electronic mail software which includes a main email component and a number of installable components.
  • the installable components include authoring/reading components for creating/reading different kinds of documents and mailbox components for listing different kinds of messages or for listing messages in different styles.
  • the main email component provides an underlying graphical user interface for functions directly associated with the storage and transfer of electronic mail messages, and also handles all data bundling and unbundling required to transform a message created by an authoring component into a MIME compliant message.
  • the authoring/reading components act like applications embedded within the email program and allow specific types of documents such as spreadsheets, graphics, databases, etc. to be created from within the email program and emailed directly.
  • the authoring/reading components also allow received documents to be read without the difficulties traditionally associated with attaching binary files to an email letter.
  • the authoring components of the invention pass data to the main email component which packages the data as a MIME compliant message. When the message is received, the main email component concatenates (as needed) and decodes the MIME message and sends the data to the authoring/reading component associated with the MTME type.
  • the . electronic mail software also includes modular integrated authoring/reading software wherein the functionality of the authoring/reading software is controlled by the "role" of the user when participating in an exchange of messages.
  • "roles" given in the parent apphcation was that of teacher and student. Another example was that of a puzzle encoder and a puzzle decoder.
  • VBS Visual Basic Scripts
  • API application programming interface
  • the electronic mail software includes a main email component and a number of installable components which communicate bidirectionally with the email component through an apphcation programming interface (API).
  • the installable components include authoring/reading components as well as at least one mailbox browser/editor component.
  • the main email component provides an underlying graphical user interface (GUI) for functions directly associated with the storage and transfer of electronic mail messages.
  • GUI graphical user interface
  • the main email component provides menu items which allow the user to SEND, READ, REPLY, FORWARD, DELETE, SAVE, and PRINT, for example.
  • the main email program also handles all data bundling and unbundling that may be required to transform a message created by an authoring component into a fully MIME compliant message.
  • the main email component includes "hooks" (an apphcation programming interface or API) for the attachment of the installable components.
  • the authoring/reading components each provide functionahty which is particular to the type of document the component is designed to create/display.
  • some modular components have assigned "roles" whereby senders and recipients of certain email documents are provided different kinds of access to the documents.
  • the vendor component allows a vendor to create an order form which appears in an email message read by the customer.
  • the customer component allows the customer to fill in the form and mail back the filled-in data to the vendor or the vendor's database.
  • a database component automatically reads the order data from the customer email and transfers this data to bilhng and fulfillment software.
  • Other modular components having assigned roles include bidder/auctioneer, doctor/patient, attorney/client, etc.
  • the authoring/reading components interface with the main email component via designated "MIME types".
  • MIME data standard allows developers to define MIME types using the label "x-" ⁇ string> in the data header where ⁇ string> is any ASCII string excluding space, control characters and other special characters.
  • the MIME data standard also allows developers to define MIME subtypes using an extension to the label that appends the character "/" and a string to the MIME type. For example a Kidcode Rebus message might be identified with the content-type header set as "Content-Type: x-KidCode/Rebus". Further, the MIME standard allows developers to include parameters within the contents of the "Content-Type" header field.
  • the authoring components of the invention pass data to the main email component which packages the data as a MIME compliant message with the label "x-" ⁇ application> in the message header, where ⁇ application> identifies the authoring/reading component which created or can display the message.
  • the main email component concatenates and decodes the MIME message, reads the MIME type, sends the data to the component associated with the MIME type, and waits for a user event or a callback from the component.
  • This bidirectional communication between the main email component and the authoring/reading components provides a totally seamless operation wherein the user may send and receive complex documents without any knowledge of attaching files, downloading, decoding, etc.
  • enhanced functionahty is achieved through installable components. Only after the appropriate component has been installed can an "active" email message call upon the component to execute.
  • Figure 1 is a very high level schematic diagram of the architecture of the email software of the invention.
  • FIG. 2 is a somewhat lower level schematic diagram of the architecture of the email software of the invention.
  • Figure 3 is a screen shot of an email message created with a vendor authoring component and displayed by a generic authoring/reading component which can control the generation of new messages for other authoring/reading components;
  • Figure 4 is a screen shot of an uncompleted email message template generated by a customer reading/authoring component in response to the email message shown in Figure 3;
  • Figure 5 is a screen shot of the completed template of Figure 4.
  • Figure 6 is a screen shot of an interactive template created by an auctioneer authoring component and displayed by a bidder/seller authoring/reading component displayed in the bidder role;
  • Figure 6a is a screen shot of an interactive template created by an auctioneer authoring component and displayed by a bidder/seller authoring/reading component displayed in the seller role;
  • Figure 7 is a screen shot of a doctor reading/authoring component
  • Figure 8 is a screen shot of a patient reading/authoring component
  • Figure 9 is a state diagram illustrating how roles are automatically assigned.
  • Figure 10 is a state diagram illustrating the changes in role in an authoring/reading component. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • the email client includes a main client 10, having a main client API 12, and one or more authoring/reading components 14, each having a component API 16.
  • the authoring/reading components each include a message handler 18 having an API and preferably an installable mailbox handler 20 having an API.
  • installable components may be made up of either message handlers, mailbox handlers, or both.
  • the main email chent 10 includes functionahty for message transport 22, message encoding/decoding 24, message storage and retrieval 26, basic GUI to mail services 28, user administration 30, component installation 32, and special services 34.
  • the main email chent 10 also includes an API 12 for communicating with authoring/reading components 14a, 14b, 14c, each of which have an API 16a, 16b, 16c for communicating with the main email chent 10.
  • a separate installable mailbox browser/editor 14d may be provided, having its own API 16d for communication with the API 12 of the main email client 10.
  • An example of a specialized mailbox browser/editor component is disclosed in previously incorporated parent application [BAK-006].
  • the main email chent 10 performs all of the usual functions of an electronic mail chent. These include message transport, message storage and retrieval, message encoding and decoding, user administration (including user preferences). In addition, the main email chent includes unique functionality required to enable installable components and special server-based services.
  • the message transport functionahty 22 of the main email chent 10 handles all functions traditionally associated with sending (SMTP) and receiving (POP, EVIAP) email messages. This includes finding and verifying network addresses, and sending and receiving mail messages to other servers on a network.
  • the main email chent 10 handles all data bundhng and unbundling that may be required to transform the message data used by a message authoring component into a fully MIME comphant message type via the message encoding/decoding module 24. This way each message authoring component handles data in a format most convenient to it and all MIME parsing and details associated with protocol compliance are centralized in the main email chent 10.
  • the only requirement for the message data passed between a message authoring/reading component and the main email chent is that the message body data be formatted either as an ASCII string or in a binhex format.
  • the main mail chent 10 maintains its user mailbox files locally.
  • the storage and retrieval module 26 implements all functionahty required for reading and writing messages and mailboxes to/from permanent storage.
  • the main email client 10 also includes a GUI 28 for user control of those functions that are directly associated with storage, display, and transfer of electronic mail messages and mailboxes.
  • the main email client interface includes buttons and/or menu items that allow a user to send a message, reply to a message, open a message or a mailbox, delete/trash messages or mailboxes, save a message to an alternative mailbox, and print a message.
  • the main email chent user interface operates simultaneously with the user interface of an authoring/reading component in the sense that both are active on the screen at the same time and present the "look and feel" of a single application.
  • Figures 6-8 show authoring reading components for an auction bidder, a doctor, and a patient respectively.
  • each of the authoring/reading components has its own interface which permits the user to interact with the component in a manner particular to the component.
  • the authoring/reading component interface is generally provided in a separate menubar or integrated within the space of a window. Nevertheless, the main mail chent interface is still provided, for example at the main menubar where the File, Edit, Message, Transfer... functions are always accessible.
  • the authoring/reading component handles the user event. However, when a user selects a function from the main email chent, the main email client intercepts and handles the event.
  • a user event in the main program will require an API call to the message handler component in order to fully execute the user invoked action.
  • the main program intercepts the send request and makes a call to the API function msh_sendMessage (described in more detail below) in the active message handing component.
  • the msh_sendMessage function passes a valid message body back to the main program or, if for example, a valid message body has not yet been defined, passes a FAIL code back to the main program.
  • the user administration module 30 provides functionality for management of user information such as the user's POP mail account, SNMP server, etc.
  • the user administration module includes administrative functions and a user interface to add and modify information for more than one user.
  • the module maintains a data structure consisting of all relevant user information for each user in the system.
  • the module also manages files that are required for permanent storage of user information, if necessary.
  • the component installer module 32 handles the installation of installable components (authoring/reading, mailbox, etc.) and maintains a data structure of component information for each installable component.
  • installable components authorized/reading, mailbox, etc.
  • the component installer module 32 maintains a data structure of component information for each installable component.
  • the following information is made accessible to the main mail chent via the component installer: MIME type of message handled by the component, component name and type, location and file name of program executable code for the component, location(s) of icon image data for the component, and description of the resources that need to be installed into the main chent, e.g. buttons, menu items etc.
  • the implementation of the component installer is dependent upon the programming environment within which the system is built and meant to operate. In order for installable components to operate properly, it is necessary for the main client program to be able to execute the new component's program code and make function calls to that code. It is not sufficient to execute the code as a completely separate program module because function calls and data must be passed between the main program and the component.
  • an installable component might be made up of one or more DLL's (dynamic link libraries) and one or more resource or ini files.
  • DLL's dynamic link libraries
  • MIAW movingie in a window
  • the component installer should also be capable of editing data structures in the main program that manage the display of relevant user interface controls.
  • the component installer for the KIDCODE® client (described in previously incorporated serial number 09/209,162) adds a new button with the component icon to the main screen as well as making an icon available to the mailbox display component. It is also generally desirable to add entries for the new component to menus in the main chent program.
  • An important part of the design of the component installer is a specification document that describes the format and type of information that must be provided by each installable component in order to have that information installed into the main chent program.
  • the special services module 34 allows the UMB ANET mail chent to communicate with UMB ANET servers on the Internet in order to provide specialized services such as component downloads, message tracking and accounting, recipient mail capabihty verification, PKI security and certification, etc.
  • the UMB ANET chent uses TCP/IP and a proprietary protocol to communicate with UMB ANET servers. Once a TCP IP connection has been established with an UMB ANET server, the chent registers with the server. Thereafter, the chent and server exchange information using the UMB ANET protocol.
  • the mailbox and the authoring/reading components are preferably "installable".
  • the invention prescribes that mailbox components are used to display, edit, and browse mailboxes.
  • Different kinds of users and different types of messaging applications e.g. fax, traditional email, internet voice
  • Installable mailbox components make it possible to upgrade, select from multiple viewing formats, utilize different mailbox viewer/editors for different users, and in general increase the range of functionahty that can be achieved within one basic messaging apphcation program.
  • the message authoring/display (message handler) components make it possible to handle an unlimited number of message types.
  • Each message handler component is designed to deal with a specific MIME type of message.
  • the MIME data standard has been designed so that apphcation developers can define new MIME types as needed by labeling these with the "x-" ⁇ string> prefix.
  • a message handler component can be any program that defines a message MIME type of data that it handles, implements the callback API functions described below, and matches the requirements imposed by the component installer module. API callback functions allow the main email chent to obtain information about the message handlers and allow the message handlers to respond to standard mail commands such as Send or Reply, that have been issued by a user through the main email interface.
  • some of the types of message handler components contemplated by the present invention are those which can be thought of as creating "roles" among senders and recipients of mail messages.
  • either the message handler or the message created by it can estabhsh the "roles" of the recipients and the authors such that recipients and authors are each permitted to interact with the message in certain different predefined ways.
  • This function is normally called by a mailbox handhng component.
  • Mailbox handhng components may use temporary files to hold mailbox contents but they preferably never access the users mailbox files. All access to these files should be obtained through the main email program.
  • the input to this function is (dt_MailBoxName) and the output is dtJvlailboxData.
  • the main email program maintains all user information and handles user administration functions.
  • the main program also communicates with external mail servers which may contain other user information.
  • the input to this function is (dt_UserName) and the output is dt_UserData.
  • This function is used by installable components to explicitly pass control back to the main email program. This function is necessary for the present implementation which uses MACROMEDIA DIRECTOR LINGO code. It is not a requirement for alternative implementations.
  • the function has the argument (dt_ComponentType).
  • This function is used by an installable component to inform the main email program that it is preparing to terminate. This allows the main program to free any memory and/or data structures that have been allocated to the component. emh passMessage
  • This function is used primarily by mailbox components to pass a message to the main program so that it can be displayed by the appropriate message handhng component.
  • the main program takes the message arguments (em_MailData) or (emJVIessageAction).
  • the former looks up the Mimetype of the message, and invokes the appropriate message handler to display the message.
  • the latter is used with #open, #print, #send,...etc.
  • This function returns the message (emJVIailData) with Number MessageNumber from the MailboxName of the current user. It can be used by installable components to retrieve specific messages from the user's mailboxes. If this is called with the messageNumber set to 0, the main email assumes the typeOrBoxName argument is a mimetype and returns a new message structure. Message handhng components should call emh_getMessage with the number set to 0 and the mimetype whenever a new message is started. Normally this should be done whenever an active message is trashed.
  • This is the same list of users that appears in the logon hstbox when the program is started up. It may be used by installable components to create listboxes for filling address fields in messages or for checking whether a particular address is external to the system.
  • This function may be used with an argument that specifies a MIME type. When so used, the function will return a hst of users who are authorized to receive (or capable of displaying) messages of the specified MIME type.
  • the indications of the authorizations or capabihties of users may be stored on a local server, on a remote server (via the Internet), or may be stored locally on a user's computer.
  • the main email client sends a message with the argument (emJVIailData) by either forwarding it to an external mail server or, if it is a registered email chent user, writing the message to the user's incoming mail mailbox.
  • emh_saveMessage a message with the argument (emJVIailData) by either forwarding it to an external mail server or, if it is a registered email chent user, writing the message to the user's incoming mail mailbox.
  • the main email chent saves a message with the argument (em_MailData) for the currently logged on user by writing the message to the user's "notes in progress" mail mailbox.
  • the main email program controls the state of all the buttons available to users to access message handhng of the main program.
  • This function can be used to request that the main email program disable the button specified by the argument, ButtonName. If the button is disabled, whether it was already disabled or is disabled as a result of this function call, this function will return TRUE, otherwise it will return FALSE. The calling component should check whether the function call succeeded and proceed accordingly.
  • the ButtonNames are #reply, #send, #print, #trash, etc.
  • this function is used carefully. Normally, the main email program controls the state of all the buttons available to users to access message handhng of the main program. This function can be used to request that the main email program enable the button specified by the argument, ButtonName. If the button is enabled, whether it was already disabled or is disabled as a result of THIS function call, this function will return TRUE, otherwise it will return FALSE. The calling component should check whether the function call succeeded and proceed accordingly.
  • This function is used by the main email program to tell an installable component to start. This function will execute prior to initialization of the component's data structures, which should only be initialized after the component receives the emc_initWindow call from the main email program. This function is necessary for the MACROMEDIA DIRECTOR LINGO code implementation and may not be needed for other implementations. emc_initWindow
  • This function is used by the main email program to tell an installable component to initialize its data structures and prepare its graphical display.
  • the component is passed the username of the current user. If the component requires additional user information in order to initialize, it can call emh_getUserlnfo within its implementation of this function.
  • This function is used by the main email program to tell an installable component to free all memory that it has used, close its window, and shut down.
  • This function is used by the main email program to get required information such as componentName, componentlD, etc. from an installable component. This function should not be called until the component window is fully open.
  • This function is used by the main email program to get the message number of the currently selected message in the mailbox browser. If no message is selected, the hst should be empty.
  • This function is used by the main email program to get the message data structure of the message with emJVIessageNumber from the mailbox currently displayed in the mailbox browser. If the function fails, e.g. if there is no message with the given message number, the function returns an empty list.
  • This function is used by the main email program to tell the mailbox component that it has received a trash event (e.g. user pressed trash button).
  • a trash event e.g. user pressed trash button.
  • the component should identify which messages have been indicated by the user and return these messages in a hst data structure. If no messages have been indicated by the user or if the component wishes to cancel the operation it should return an empty hst.
  • the mailbox component will update its display and its data structures to delete messages that have been indicated by the user.
  • This function is used by the main email program to tell the mailbox component to display the mailbox passed in the argument (dtjvlailbox).
  • This function is used by the main email program to tell a message handhng component to pass back a fully completed message data structure so that it can be sent to the recipient specified in the message's address field.
  • the message handhng component should update its display as appropriate for a message that has been sent. It should also change its state to display mode because a message that has already been sent should not be editable. If the function fails, e.g. if a fully completed message cannot be constructed (for example, if the user has not specified a message recipient), the function returns an empty hst.
  • the message handhng component will normally control all dialogs with a user that pertain to a message under construction. For example, to alert the user that a message recipient must be specified. However, if the message handling component fails to pass back a properly formatted, completed message data structure, (or an empty hst acknowledging failure), the main email program will detect the error and alert the user about the field or fields that have not been specified.
  • This function is used by the main email program to pass a message data structure to a message handling component so that it can be displayed.
  • the message handhng component should display the message in the specified mode (e.g. either #author or #display). If the emJVlode argument is #display the message should not be editable. Otherwise the message should be opened so that it can be edited. If the function fails, e.g. if an error is detected in the message body, the message handler returns FALSE, otherwise the message handler returns TRUE.
  • This message is used by the main email program to inform a message handhng component to display the currently active message for editing as a reply.
  • the message handing component will generally create a new message with the mode set to #author. If the function fails, e.g. if an error is detected in the message body, the message handler returns FALSE, otherwise the message handler returns the messageBody which may have been modified.
  • This function is used by the main email program to inform a message handling component that the current message should be cleared from the display and from the message handhng component's data structures. This function is used, for example, when the user indicates they want to trash the current message by clicking on the "trash" button in the main email program GUI. If the function fails, the message handler returns FALSE. Otherwise the message handler returns TRUE.
  • This function is invoked when the main email program receives a save event, e.g. the user presses the "Save” button.
  • the message handler should pass the messageBody back to the main email program to be saved.
  • the message handler should maintain its state when this function is called because the user may want to continue editing the message.
  • This function is used by the main email program to inform a message handling component that a message should be printed. This function is used, for example, when the user indicates they want to print the current message by clicking on the "print" button in the main email program GUI.
  • the argument, em_mailData is an empty list
  • the message handler component should print the currently active message. Otherwise the message handler component should print the message argument.
  • the main email program will call this function with an empty hst for an argument.
  • the function may also be used by the main email program to have a message handler print a message even though the message handler component has not been fully initialized and displayed in a window.
  • this will occur if an active mailbox component receives a print request from the main email program for a message that has been selected in the mailbox browser.
  • the main email program will send a request to the appropriate message handler component to print the message without fully starting it up and initializing its window.
  • the message handler should implement the msh_printMessage function so that the following sequence of function calls succeeds emc_startMeUp, msh_printMessage(message). If the function fails, the message handler returns FALSE. Otherwise the message handler returns TRUE.
  • This function is used by the main email program to tell a message handler component that it has received a trash event (e.g. user pressed trash button).
  • the component should do whatever is appropriate and return its currently open message data structure.
  • a component may want to display a dialog box to verify the trash operation before proceeding, (e.g. emh_alertUserToTrash) If the component wishes to cancel the operation, it should return an empty hst.
  • a message handhng component will update its display and its data structures to clear the trashed message from its display.
  • message handling components may be created for different user roles and/or messages may be assigned certain role information which controls how the recipient(s) of the message interacts with the message.
  • certain message handhng components can provide different levels of authoring and different levels of readership based on "roles.”
  • Figure 3 illustrates an email message 40 which was created by a "vendor” component (or an authoring/reading component in a "vendor” role).
  • Figure 3 shows the message as it appears on the recipient's computer screen. As shown the message appears to be a simple plain text email message with a hot link 42 to the vendor's web page (the underhned sentence "Chck here to Go to Our Web Page for more Details.”).
  • the second hot link 44 in this message invokes special functionahty of the reading/authoring component installed in the recipient's email program.
  • the "customer” message handling component causes a new outgoing email message 46 to be created as shown in Figure 4.
  • the new mail message is pre-addressed and the body contains information relating to the order which will be placed when the new message is sent.
  • the body of the message is actually a template which was created from information contained (though hidden from display) in the email message 40 received from the vendor. This information was not displayed in the original message shown in Figure 3, but was made known to the message handhng component for use in creating the template 46 shown in Figure 4 if the user clicked on the second hot link 44 in Figure 3.
  • the customer role assigned to this outgoing email message 46 allows the user to make only hmited additions to this template. Specifically, the user may enter a number of items in the blank 48 and a choose a size using the "radio buttons" 50, then chck on the send mail icon 52.
  • This template is interactive and controlled by the message handhng component so that as soon as the user selects a number to order, the purchase price is displayed in the field 54 as shown in Figure 5.
  • the purchase price is preferably charged to an account already set-up with the vendor. This mode of operation also maximizes the security of the transaction.
  • the user can click on the send mail icon 52 once the form is filled in.
  • the send mail icon 52 will remain "grayed out” until the user completes ah of the information required by the form. If the user changes his/her mind about placing the order, s/he may simply close this window without sending the message. If the user clicks on the send icon 52, the mail is sent back to the vendor, preferable with an assigned role of "order fulfillment", for example.
  • the message may also be preferably addressed to an automatic mail handler which will automatically extract information from the order and from the customer database and process the order.
  • Figure 3 shows what looks hke a standard HTML message but is used to open a customer reading/authoring component displayed in Figures 4 and 5.
  • the screen shot of Figure 3 doesn't show what the vendor authoring component would look hke since it is displayed from the point of view of the customer.
  • the message can be used to start a new message in the "customer" component.
  • Figures 3-5 There are different scenarios that could be depicted by Figures 3-5.
  • Figure 3 shows a message displayed in a customer component with the "customer” role.
  • the new message with the "vendor” role is displayed in the customer component is shown in Figure 4.
  • This is an interpretation that matches closely to the operation of the code included in the parent apphcation.
  • the invocation of the new message is normally done by hitting the "reply" button in the main interface rather than a field displayed on the incoming message.
  • This functionality is useful if it is necessary for a message author (e.g. a vendor) to control the assignment of role information associated with various types of replies on an individuahzed basis. For example, if it wanted certain types of customers to have access to the online customer service and wanted to encode this in the message body itself. In this case, some customers would receive a message looking similar to the one displayed in Figure 3 with an additional line that says “Click here to request customer support” in which case a new message with a role assigned to be "Saleslnfo" would be created in the Sales authoring/reading component.
  • Figure 3 shows a message displayed in a "controller” component that is capable of responding to an input pair (message data + user action) by opening new messages in other components.
  • the "controller” component opens a new message in author mode (perhaps tagged with the "customer” role) in the "customer” component.
  • This scenario could be implemented by sending an HTML-like message with a message MIME type set up to identify the controller component, e.g. "x-ControllerMsg” whose body consists of a set of data pairs (display_string/associated component to open/ data parameters for component).
  • Figure 6 shows another similar example of a message handhng component/role is used in e-commerce.
  • Figure 6 shows an email message 60 which was generated by an "auctioneer” component (or an authoring/reading component in auctioneer mode).
  • Figure 6 shows the message as it appears on the computer screen of a "bidder".
  • This message contains several graphic components 62, 64, three text message fields 66, 68; 70, and an input template 74.
  • the message 60 is a combination incoming/outgoing template.
  • the bidder fills in the appropriate parts of the template 74 and chcks on the "reply" button 76.
  • the bidder's authoring/reading component composes an appropriate message to the auctioneer and sends it automatically and transparently.
  • the user will see the message 60 disappear and preferably see a dialog box or window notice saying "Message Sent" or the like.
  • the concept of role may be associated with a particular component or with a message created by the component.
  • the non-auctioneer component have at least two modes of operation, one being the role of bidder and the other being the role of seller.
  • the bidder role is illustrated with reference to Figure 6 described above.
  • the seller role is illustrated with reference to Figure 6a which shows a message template 61 which is created when the user chooses to post a for sale message.
  • the template 61 includes a title field 63, a category field 65, a description field 67 and an option checklist 69.
  • the concept of role is associated with the message and authoring/reading components are capable of creating and reading messages having different roles.
  • the role of the message is contained within the body of the message.
  • the role of the message is encoded in the MIME type, subtype, a parameter in the "Content_Type" header, or in the subject header.
  • the processing of a message with a specified role may be carried out either by an authoring/reading component designed specifically to handle messages with the specified role or by an authoring/reading component that is built to handle all messages of a specified MIME type.
  • the authoring/reading component handles all messages of a given MIME type it includes within it the logic necessary to process messages with different roles differently.
  • the message role is encoded in the message body and is handled entirely by the authoring/reading components.
  • This has advantages over an alternative that records the message role in a message header field because the mail email client can be independent of any knowledge of roles and does not need to be encumbered with role handhng logic that is best left to component designers.
  • this places a restriction on the design of authoring/reading components. If role information is embedded in the message body, it is not advisable to allow the creation of authoring/reading components specialized to handle certain roles. To do so would require that the main mail chent software be capable of parsing the message body in order to find the role information and, thereby invoke the proper authoring/reading component for a given message.
  • a solution that enables both the development of authoring/reading components specialized to handle particular roles and guarantees data separation as described above is to encode role information as a subtype of the MIME type in the "Content-type" header field.
  • the main email client would properly invoke the correct authoring/reading component in the case that an independent authoring/reading component has been constructed for handhng a specified message role.
  • Another alternative is to encode role information in the parameter that may be optionally included in the "Content-type" header as defined by the MJVJE standard.
  • the main email client maintains data separation with respect to the message body but is required to parse the Content-Type parameter. The additional complexity necessary in the main mail client software causes this to be an inferior solution.
  • Figures 7 and 8 illustrate authoring/reading components having the roles of "doctor” and "patient”.
  • Figure 7 illustrates a message template 80 for use by a doctor.
  • the message template is divided into three main parts 82, 84, 86.
  • the first part 82 presents the doctor with pop up menus for selecting, for example, patient name, prescription number, test provider, test number, etc. Radio buttons are also used to enter information about prescription refills, generic substitution, etc.
  • the second part 84 is a text editor window where the doctor may compose a personal message to the patient.
  • the third part 86 is a text entry template HMO information, consultation charge, etc. After the doctor fills out the message template 80 and sends it, the authoring/reading component prepares a message to the patient and a message to the HMO.
  • Figure 8 illustrates the message 90 received by the patient as a result of the doctor filling in the template 80 ( Figure 7).
  • the message 90 presents the role of patient and organizes information in a manner useful to the patient.
  • the message 90 includes a text field 92 which displays the text message composed by the doctor and entered into the text field 84 in Figure 7 and several check box fields 94, 96, 98.
  • Field 94 allows the patient to request information about a medical condition.
  • Field 96 allows the patient to select certain parameters regarding the filling of a prescription and to request a copy of diagnostic test results.
  • Field 98 allows the patient to purchase and obtain information about vitamins.
  • Figure 8 also illustrates a pop-up dialog box 100 which alerts that patient regarding to the bilhng information entered by the doctor in field 86 of Figure 7.
  • the patient component automatically sends emal to the pharmacy with only the information needed by the pharmacy to fill the prescription.
  • the attorney and chent roles may be implemented in a manner similar to the doctor and patient roles.
  • the roles of organization members have different security clearances can be implemented in a manner whereby a message created by someone with the highest security clearance is classified in different ways so that only those with the proper clearance can read it. For example, it is possible to create a message where some parts of the message are highly classified and other parts of the message are given lower classifications. Readers with high security clearance will be able to read all or most of the message. Readers with low clearance will only be able to read parts of the message.
  • the role information associated with each message is assigned to the message when it is created or when it is sent.
  • a role can often be automatically assigned to a message by the authoring/reading component used to author the message.
  • the role given to a message may be based on many factors including the state of a previous message (or sequence of messages), information selected by a message author, and information associated with the message recipient and/or the message author.
  • the authoring/reading components built for children's educational games automatically assign a role to a message on the basis of the state of a previous message.
  • Figure 9 shows the state diagram used to determine how roles are automatically assigned to KidCode® messages.
  • the KidCode® coder/decoder games when a user starts a new message at 110 by pressing the message authoring button in the main client program, the message is tagged as a "new" message and treated as a "coder" message.
  • the message role is set to "decoder” at 112 because the message recipient will play the role of decoder of the puzzle.
  • the decoder sends the reply to the message the role of the outgoing message is set to "coder” at 114.
  • Figure 10 elaborates on the manner in which messages are displayed by the KidCode® Rebus and Grid message handling components. Whereas Figure 9 describes transitions undergone by a message (or message descendants), Figure 10 shows the transitions of the state of an authoring/reading component.
  • This Figure provides a more complete picture of how an authoring/reading component can use the message role and the message display mode (a property of the authoring/reading component that normally takes one of the two values, "display” or "author”) to determine how a message should be displayed and what tools are available to the message author or reader.
  • the component On start 116, the component has three options. One option is to create a new message in the coder role (component author mode) 118.
  • Another option is to open a message in the decoder role (component display mode) 120 in order to view a puzzle created by another. Still another option is to open a message in the coder role (component display mode) 122. This option would be used to view a response by a decoder to a coded message created by the current user. If the user chooses to reply to this message, the message role is changed to decoder (component author mode) 124.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne un logiciel de courrier électronique comprenant un composant principal de courrier électronique (10) et un certain nombre de composants pouvant être installés communiquant de façon bidirectionnelle avec le composant de courrier électronique via une interface de programmation d'application (API) (12). Les composants installables (12) comprennent des composants de création et de lecture (14a, 14b, 14c), ainsi qu'au moins un composant de navigateur et d'éditeur de la boîte aux lettres. Le courrier électronique principal utilise une interface utilisateur graphique sous-jacente (GUID) destinée à une fonction directement associée au stockage et au transfert de messages de courrier électronique. Plus précisément, le composant principal de courrier électronique met en place des objets de menu permettant à l'utilisateur d'ENVOYER, DE LIRE, DE REPONDRE, DE TRANSMETTRE, D'EFFACER, DE SAUVER, D'IMPRIMER, par exemple. Le programme principal de courrier électronique traite également toutes les compilation et décompilation des données requises pour transformer un message créé par un composant de création en un message adapté MIME. De plus, le composant de courrier électronique comprend des « crochets » (API) destiné à la fixation des composants installables. Chaque composant de création et de lecture met en place une fonctionnalité qui est particulière au type de document que le composant permet, par sa conception, de créer et d'afficher.
PCT/US2001/020349 2000-06-27 2001-06-20 Logiciel de courrier electronique avec composant modulaire integre de creation et de lecture WO2002001374A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001271494A AU2001271494A1 (en) 2000-06-27 2001-06-20 Electronic mail software with modular integrated authoring/reading component

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/604,428 2000-06-27
US09/604,428 US7444374B1 (en) 1998-12-10 2000-06-27 Electronic mail software with modular integrated authoring/reading software components including methods and apparatus for controlling the interactivity between mail authors and recipients

Publications (1)

Publication Number Publication Date
WO2002001374A1 true WO2002001374A1 (fr) 2002-01-03

Family

ID=24419563

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/020349 WO2002001374A1 (fr) 2000-06-27 2001-06-20 Logiciel de courrier electronique avec composant modulaire integre de creation et de lecture

Country Status (2)

Country Link
AU (1) AU2001271494A1 (fr)
WO (1) WO2002001374A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8499044B2 (en) 2006-12-07 2013-07-30 Microsoft Corporation Formatted message processing utilizing a message map
CN112579061A (zh) * 2020-12-17 2021-03-30 青岛以萨数据技术有限公司 一种安卓组件间数据传递方法、设备、系统及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5752059A (en) * 1992-12-29 1998-05-12 Apple Computer, Inc. Apparatus and method for representing electronic mail
US5826062A (en) * 1996-05-30 1998-10-20 International Business Machines Corporation Method and apparatus for converting and displaying a multimedia document at a client
US5917489A (en) * 1997-01-31 1999-06-29 Microsoft Corporation System and method for creating, editing, and distributing rules for processing electronic messages
US6088696A (en) * 1997-09-29 2000-07-11 Ericsson Inc. Mailing/filing system for congruently categorizing different types of electronic mail resources received through a messaging system
US6189026B1 (en) * 1997-06-16 2001-02-13 Digital Equipment Corporation Technique for dynamically generating an address book in a distributed electronic mail system
US6205432B1 (en) * 1998-06-05 2001-03-20 Creative Internet Concepts, Llc Background advertising system
US6249807B1 (en) * 1998-11-17 2001-06-19 Kana Communications, Inc. Method and apparatus for performing enterprise email management

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5752059A (en) * 1992-12-29 1998-05-12 Apple Computer, Inc. Apparatus and method for representing electronic mail
US5826062A (en) * 1996-05-30 1998-10-20 International Business Machines Corporation Method and apparatus for converting and displaying a multimedia document at a client
US5917489A (en) * 1997-01-31 1999-06-29 Microsoft Corporation System and method for creating, editing, and distributing rules for processing electronic messages
US6189026B1 (en) * 1997-06-16 2001-02-13 Digital Equipment Corporation Technique for dynamically generating an address book in a distributed electronic mail system
US6088696A (en) * 1997-09-29 2000-07-11 Ericsson Inc. Mailing/filing system for congruently categorizing different types of electronic mail resources received through a messaging system
US6205432B1 (en) * 1998-06-05 2001-03-20 Creative Internet Concepts, Llc Background advertising system
US6249807B1 (en) * 1998-11-17 2001-06-19 Kana Communications, Inc. Method and apparatus for performing enterprise email management

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8499044B2 (en) 2006-12-07 2013-07-30 Microsoft Corporation Formatted message processing utilizing a message map
CN112579061A (zh) * 2020-12-17 2021-03-30 青岛以萨数据技术有限公司 一种安卓组件间数据传递方法、设备、系统及存储介质

Also Published As

Publication number Publication date
AU2001271494A1 (en) 2002-01-08

Similar Documents

Publication Publication Date Title
US7444374B1 (en) Electronic mail software with modular integrated authoring/reading software components including methods and apparatus for controlling the interactivity between mail authors and recipients
AU723705B2 (en) E-mail program capable of transmitting, opening and presenting a container having digital content using embedded executable software
US6360221B1 (en) Method and apparatus for the production, delivery, and receipt of enhanced e-mail
US7346552B1 (en) System and method for the enablement of electronic commerce in a content network
US20020070978A1 (en) Dynamically configurable graphical user environment
US20020055968A1 (en) Distributed application interface and authentication process
US7797431B2 (en) Enhanced data exchange and functionality control system and method
WO2000034852A1 (fr) Courrier electronique auteur a composants modulaires
US20050177575A1 (en) System and method of co-branding pages over a network
US20020051017A1 (en) Notification device for a graphical user environment
US20070157320A1 (en) Software, systems, and methods for processing digital bearer instruments
US20060069736A1 (en) Content formatting and installation techniques
US20020065947A1 (en) Software application agent interface
EP1032899A2 (fr) Procede et systeme d'adaptation aux besoins des clients de services de marketing dans des reseaux de communication par conventions de reference d'hypertexte
WO1998034168A9 (fr) Procede et systeme d'adaptation aux besoins des clients de services de marketing dans des reseaux de communication par conventions de reference d'hypertexte
US20160048812A1 (en) Software, systems, and methods for processing digital bearer instruments
Couch et al. Java 2 enterprise edition bible
JP2002536767A (ja) メッセージ送信アーキテクチャ
US6704771B1 (en) Electronic message payload for interfacing with text contained in the message
US20190295051A1 (en) Software, systems, and methods for processing digital bearer instruments
US7840639B1 (en) Method and article of manufacture for an automatically executed application program associated with an electronic message
WO2002001374A1 (fr) Logiciel de courrier electronique avec composant modulaire integre de creation et de lecture
WO2000052551A2 (fr) Procede et appareil de communication de donnees graphiques entre une source et un destinataire sur un reseau
US7814409B2 (en) System and method for configuring a document
US7451400B2 (en) System and method for improved user information management

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CO CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载