WO2002013469A2 - Recipient-specified automated processing in a secure data file delivery system - Google Patents

Recipient-specified automated processing in a secure data file delivery system Download PDF

Info

Publication number
WO2002013469A2
WO2002013469A2 PCT/US2001/024995 US0124995W WO0213469A2 WO 2002013469 A2 WO2002013469 A2 WO 2002013469A2 US 0124995 W US0124995 W US 0124995W WO 0213469 A2 WO0213469 A2 WO 0213469A2
Authority
WO
WIPO (PCT)
Prior art keywords
package
recipient
data
computer
readable medium
Prior art date
Application number
PCT/US2001/024995
Other languages
French (fr)
Other versions
WO2002013469A3 (en
Inventor
Jean-Christophe Bandini
John Kenneth Beer
Jean-Sebastian T. Neveu
Jeffrey C. Smith
Original Assignee
Tumbleweed Communications Corp.
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
Application filed by Tumbleweed Communications Corp. filed Critical Tumbleweed Communications Corp.
Priority to AU2001281218A priority Critical patent/AU2001281218A1/en
Publication of WO2002013469A2 publication Critical patent/WO2002013469A2/en
Publication of WO2002013469A3 publication Critical patent/WO2002013469A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21Monitoring or handling of messages
    • H04L51/214Monitoring or handling of messages using selective forwarding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols

Definitions

  • the invention relates to data transfer through computer networks and, in particular, to a mechanism by which packages to be delivered to a recipient are automatically processed in a manner specified by the recipient.
  • the Internet has grown tremendously in recent years, both in terms of number of users and the amount of data transferred through the Internet. Originally, the Internet was a data transfer medium for academia. Eventually, engineers and private users increasingly used and became more familiar with the Internet. More and more, the Internet is becoming an acceptable communication medium for business. However, business users demand more confidentiality and traceability of communication than do private users engaging in personal correspondence.
  • a server interacts with a sender to form a package which can include one or more attached data files to be sent to one or more recipients, and the server automatically processes the package in a manner specified by the recipient of the package. Since the server both forms the package through interaction with the sender and processes the package as specified by the recipient, automated processing on behalf of the recipient can be interactive with the sender in a way not previously achieved. For example, the sender can be immediately notified that the recipient is temporarily unavailable during an interactive session with the server. As a result, the sender can modify the package immediately in response to any automatically generated, synchronous response, e.g., to direct the package to an alternate recipient.
  • the server is accessible through HTTP/HTTPS and the World Wide Web.
  • the recipient can specify automated package processing from any computer system coupled to the ubiquitous network — including a computer at the recipient's office, a computer at the recipient's home, a publicly available computer at a public library, a rented computer at a copy/printing service center, or publicly installed Internet kiosks (e.g., >STREETSPACE kiosks — http://www.streetspace.com). Therefore, at practically any time the recipient decides a change should be made to automated processing on the recipient's behalf, the recipient can access and modify the profile of the recipient which specifies such processing.
  • automated processing in accordance with the present invention is available notwithstanding unavailability of the computer through which the recipient retrieves the package.
  • filtering can only be performed when the receiving computer is running and e-mail is retrieved. Any messages sent during the night or a weekend or while the recipient is vacationing, for example, cannot be filtered until the recipient boots the receiving computer and connects to the network for access to e-mail messages.
  • the server described herein is intended to execute continuously, regardless of whether the receiving computer is currently running and accessible. Accordingly, automated processing on behalf of the recipient can proceed notwithstanding inaccessibility of the receiving computer. Such is particularly useful in time-based conditional processing described more completely below.
  • the server delivers the package to the one or more intended recipients.
  • delivery by default includes sending notification to each recipient and including in such notification package identification data, e.g., a URL by which the package can be retrieved.
  • each recipient can specify an alternative delivery mechanism within a profile associated with the recipient. For example, the recipient can specify that packages meeting certain criteria are discarded or redirected such that no notification is sent. Similarly, notification can be omitted for low priority packages such that the recipient will only get such packages when the recipient checks all incoming packages.
  • each recipient submits the package identification data of the received notification to the server and, in response thereto, the server presents to the requesting recipient the opportunity to retrieve the package.
  • the notification message can be sent as e-mail via SMTP, and the package identification can be received by the server as a URL through HTTP.
  • the profile of the recipient which specifies the processing of packages can be represented as a list of associations between one or more conditions and one or more actions to be carried out upon satisfaction of the associated conditions.
  • Each condition includes a boolean expression involving one or more sender attributes, recipient attributes, package attributes, and/or environmental attributes.
  • Sender and recipient attributes can include regular expressions involving e-mail addresses by which each is specified or can include attributes of user records specifying each.
  • User record attributes can be particularly useful in categorizing the sender and the recipients as belonging to particular groups or classifications, although it is appreciated that e-mail addresses can sometimes provide similar information.
  • Such user record attributes can be retrieved from user records maintained by the server or from databases external to the server such as directories according to the X.500 standard or similar lightweight directory access protocols.
  • Package attributes include message attributes, delivery attributes, post delivery attributes, and attributes of attached data files.
  • Message attributes include a subject and a message body. Conditions involving message attributes can be used to detect unwanted commercial solicitations and/or offensive or inappropriate content such as sexually explicit language for example.
  • Delivery attributes include such things as package delivery priority, security options, and delivery timing. Conditions involving delivery attributes can detect packages using options which indicate a level of priority or security of a particular package. Accordingly, recipient-specified processing can be based upon the level of priority or security of a particular package.
  • Post delivery attributes specify actions a recipient can take with respect to the received package including replying to the sender of the package, replying to the sender of the package at the expense of the sender, forwarding the package to one or more other recipients, saving the package to local persistent storage, and printing the contents of the package.
  • Each post delivery attribute can limit the type of automated processing available to the recipient. Accordingly, conditions can be configured to automatically detect specific uses of post delivery attributes. However, in one embodiment, post delivery attributes of a package are not directly accessible by the recipient and conditions involving post delivery attributes of a message are not permitted. Attached data files can include confidential information, can include inappropriate material, can be excessive in size, and can include malicious computer instructions in the form of viruses or Trojan horses for example. Conditions can detect specific conditions of data files attached to the package.
  • Environmental attributes include the current day, date, and time, time relative to an event, a state specified by the recipient, the recipient's scheduled state at a particular time.
  • actions associated with conditions which are satisfied by a particular package are performed automatically. Such actions can interrupt delivery of the package, distribute the package, or modify the package. Examples of interrupting actions include discarding the package and redirecting the package. Distribution actions can include, for example, sending copies of, or notification messages regarding, the package to other recipients or to the same recipient at another address.
  • Modification actions can modify the package by changing the subject, the message, delivery attributes, post -delivery attributes, and the attached data files. For example, all attached data files can be removed or only those attached data files which satisfy a particular set of conditions can be removed.
  • a modification action can place the package in a specific folder on behalf of the recipient.
  • FIG. 1 is a block diagram of a delivery system in accordance with the present invention.
  • Figure 2 is a block diagram of the package and account datastore of Figure- 1 in greater detail.
  • FIG 3 is a block diagram of the server of Figure 2 in accordance with the present invention.
  • FIG 4 is a logic flow diagram of the implementation of profiles by the server of Figure 2 in accordance with the present invention.
  • Figure 5 is a block diagram of a profile in accordance with the present invention.
  • Figure 6 is a block diagram of a rule of the profile of Figure 5 in greater detail.
  • Figure 7 is a block diagram of a package of Figure 2 in greater detail.
  • Figure 8 is a block diagram of a recipient profile processing module of Figure 3 in greater detail.
  • Figure 9 is a block diagram illustrating interrelationships of conditions through boolean operators.
  • Figure 10 is a block diagram showing an action of the rule of Figure 6 in greater detail.
  • Figure 11 is a block diagram showing an alternative embodiment of the action of the rule of Figure 6.
  • Figure 12 is a block diagram showing a user record in greater detail.
  • packages sent to a recipient through computer network 110 in a secure and traceable package delivery system are automatically processed in a manner specified by the recipient.
  • the package is transferred by a sender to a server 108 for temporary storage in a datastore 120.
  • Server 108 processes the package in a manner described more completely below in accordance with polices specified by the recipient.
  • server 108 sends an e-mail notification through a computer network 110 to the recipient at computer system 104.
  • the recipient retrieves the package from server 108 through computer network 110.
  • the notification to the recipient is a default setting in this illustrative embodiment and the behavior of sending notification to the recipient can be modified by the recipient.
  • the recipient can specify that discarded and low-priority packages do not result in notification of the recipient.
  • automated processing on behalf of the recipient is performed by server 108.
  • a sender sends a package which can contain a message and can also include one or more data files from a computer 102, through computer network 110 to a computer 104 through which the recipient ultimately receives the package.
  • automated processing is available notwithstanding unavailability of computer 104 of the recipient.
  • filtering can only be performed when the receiving computer is running and e-mail is retrieved. Any messages sent during the night or a weekend or while the recipient is vacationing, for example, cannot be filtered until the recipient boots the receiving computer and connects to the network for access to e-mail messages.
  • server 108 is intended to execute continuously, regardless of whether computer 104 is currently running and accessible. Accordingly, automated processing on behalf of the recipient can proceed notwithstanding inaccessibility of computer 104. Such is particularly useful in time-based conditional processing described more completely below.
  • server 108 performs dual functions, namely, interaction with the sender in creating the package and processing of that package on behalf of the recipient. Accordingly, the sender can be immediately notified in accordance with the automated processing. For example, any automatic reply, such as indicating the recipient is out of the office, can be immediately delivered to the sender and the sender can act accordingly, perhaps trying to reach an associate of the recipient. Similarly, any viruses detected in data files included in a package can be immediately reported to the sender and the sender can take measures to stop further spread of the detected virus.
  • the recipient can configure server 108 through a wide area network such as the Internet such that automated processing on behalf of the recipient can be specified from numerous locations throughout a very large geographical area.
  • a data file can contain any type of computer-readable data such as text, graphical images, motion video, audio signals, database records, etc.
  • Data files can be stored in any of a number of computer-readable storage media and can be transported through a computer network such as computer network 110.
  • Computer network 110 can be either a local area network or a wide area network. In one illustrative example, computer network 110 is the Internet.
  • Datastore 120 stores packages to be delivered according to package delivery system 100.
  • Datastore 120 is shown in greater detail in Figure 2.
  • Datastore 120 includes a number of user records, each representing an entity capable of using package delivery system 100 ( Figure 1).
  • user record 204 ( Figure 2) can represent the intended recipient of a package such as package 206.
  • a user of system 100 can be either a human user or a computerized user.
  • a computerized user is all or part of one or more computer processes and can send and/or receive packages through server 108 and computer network 110. It should be understood that, like the recipient, the sender and any other recipients described in this illustrative embodiment can be either human users or computerized users.
  • Package delivery system 100 in this illustrative embodiment is sender-centric.
  • a sender establishes an account with server 108 and initiates and controls the package delivery in the manner described in U.S. Patent 5,790,790 to Smith et al. and that description is incorporated herein by reference.
  • user records 204 ( Figure 2) typically represent potential senders of packages and such packages can be sent to recipients who are not represented by user records within package and account datastore 120. Automated processing of packages addressed to a particular user can be limited to those users for whom accounts are established within server 108. Alternatively, a user who otherwise has no account within server 108 can be provided with a simple account.
  • Such an account can initially be for the sole purpose of linking the user's specified automated processing with packages addressed to the user and can be created as part of a delivery to the user in a manner described in U.S. Patent Application S/N 09/387,444 by Jeffrey C. Smith and Jean-Christophe Bandini for "Solicited Authentication of a Specific User” filed August 31, 1999 and that description is incorporated herein by reference.
  • Each user record e.g., user record 204
  • Each profile record 208 represents a number of rules to be applied to packages addressed to the user represented by the associated user record 204. The manner in which rules are applied is described more completely below.
  • each profile record e.g., profile record 208
  • profile records can be associated with groups of users, and the groups of users can be organized hierarchically such that profiles are inherited but can be superseded by profiles associated with lower levels of the user group hierarchy.
  • a user can create one or more packages for delivery to another user, e.g., the recipient.
  • Each such package is represented individually within datastore 120.
  • Package 206 is an example of such a package.
  • the profiles represented by profile records 208 are applied to all packages addressed to the user of user record 204.
  • Server 108 is shown in greater detail in Figure 3 and includes a package manager 302, a delivery queue 304, a delivery manager 306, and a recipient profile processor 308. It should be noted that, while server 108 is shown as a single computer system coupled to computer network, server 108 can be several computer systems which cooperate with one another, perhaps through computer network 110, to provide the services described herein. Connectivity of such distributed processes is conventional and known and can be implemented using such standard and conventional techniques as sockets, pipes, remote procedure call (RPC), Common Object Request Broker Architecture (CORBA), Distributed Object Component Model (DCOM), and Java Remote Method Invocation (Java RMI).
  • RPC remote procedure call
  • CORBA Common Object Request Broker Architecture
  • DCOM Distributed Object Component Model
  • Java RMI Java Remote Method Invocation
  • each of package manager 302, delivery manager 306, and recipient profile processor 308 can be implemented within a separate respective computer system or collection of computer systems. However, to provide the services described herein in an efficient manner, it is preferred that package manager 302, delivery manager 306, and recipient profile processor 308 interact through relatively quick, efficient channels, e.g., with low latency and relatively high bandwidth.
  • the sender accesses package manager 302 through computer network 110 — typically after the sender is authenticated.
  • the sender accesses package manager 302 through a web browser and package manager 302 interacts with the user through a web server, e.g., using HTML forms.
  • Web browsers, web servers, and HTML (HyperText Markup Language) forms are known computer and/or software components used currently in conjunction with the well-known World Wide Web of the Internet.
  • HTML HyperText Markup Language
  • the sender creates a package through a web browser interface
  • U.S. Patent Application S/N 08/957,986 by Jeffrey C. Smith, Jean-Christophe Bandini, and Randy Shoup for "Method and Apparatus for Delivering Documents over an Electronic Network” on October 2, 1997 and that description is incorporated herein by reference.
  • a package created by the sender as represented by package 206 is described in greater detail below in conjunction with Figure 7. Briefly, the package includes address data specifying one or more recipients, subject and message data, delivery and post handling specification data, and can include one or more attached data files.
  • package manager 302 places the completed package or, alternatively, a reference to the completed package on delivery queue 304 for delivery to the one or more recipients specified in the completed package.
  • delivery manager 306 retrieves packages from delivery queue 304 and sends those packages to recipients specified in each package.
  • delivery manager 306 effects such delivery by forming and sending a notification message, by SMTP (Simple Mail Transfer Protocol) for example, to each recipient.
  • notification messages include package retrieval data, in the form of a private universal resource locator (PURL) in this illustrative example, by which each recipient can retrieve the package through the World Wide Web according to the HyperText Transfer Protocol (HTTP), for example.
  • PURL private universal resource locator
  • HTTP HyperText Transfer Protocol
  • the recipient can specify that discarded packages are really transferred to a "trash" folder which can later be emptied and can specify the redirected packages are really transferred to the "trash" folder while a copy is forwarded to the party to which the package is to be redirected.
  • recipient profile processor 308 is coupled to both package manager 302 and delivery manager 306. In alternative embodiments, recipient profile processor 308 can be coupled to either package manager 302 or delivery manager 306 alone. In interacting with package manager 302, recipient profile processor 308 can apply profiles synchronously with sending the package by the sender. In interacting with delivery manager 306, recipient profile manager 308 can apply profiles asynchronously with the sending of the package, avoiding blocking the sender during application of profiles which are time consuming. In this illustrative embodiment, recipient profile processor 308 applies profiles which include time-consuming rules or actions through interaction with delivery manager 306 and applies all other profiles through interaction with package manager 302.
  • any automated reply messages can be immediately reported to the sender during interaction between the sender and package manager 302. Accordingly, the sender can immediately take action in response to the automatic reply message. For example, if an automatic reply message indicates that the recipient is unavailable for a considerable amount of time, the sender can immediately forward the original package to an alternative recipient without waiting for the automated reply message some time later.
  • recipient profile processor 308 is conducted on behalf of the recipient in an interactive session of package generation with the user.
  • the session is interactive since the sender submits the package, e.g., by pressing a "SUBMIT" button in a graphical user interface (GUI), and continues to monitor responses from package manager 302 until an acknowledgment message is received.
  • Such an acknowledgment message can indicate, for example, that the package has successfully been submitted for delivery.
  • recipient profile processor 308 can cause package manager 302 to include an automatically generated reply message with the acknowledgment to the sender if the profile of the recipient so dictates.
  • the immediacy of such feedback allows the sender to take corrective action, e.g., by resubmitting the package for delivery to an alternative recipient before the sender has terminated interaction with package manager 302 to go perform other tasks.
  • the package and/or any data files attached to the package can be encrypted after submission by the sender.
  • processing e.g., to scan for malicious computer instructions or specific text
  • the package manager 302 e.g., if the package is encrypted with a one-time password. Processing the package synchronously with submission of the package allows such processing to be preformed to the package while the package is still in cleartext form.
  • server 108 performs such encryption and, if recipient-specified processing in conjunction with delivery manager 306 is desirable, can decrypt the package and/or attached data files for such processing and re-encrypt the package and/or attached data files after such processing.
  • recipient-specified processing requires substantial processing resources and is therefore time-consuming.
  • One example of such processing is the scanning of attached data files for viruses, Trojan horses, and/or other forms of malicious computer instructions.
  • Another example includes rules which require access to external directories or databases. Requiring the sender to idly wait for such processing during an interactive session with package manager 302 may be unacceptable to the sender. Therefore, recipient profile processor 308 also interacts with delivery manager 306 to perform asynchronous recipient-specified processing upon packages queued for delivery.
  • Recipient profile processor 308 performs recipient-specified processing in conjunction with either package manager 302 or delivery manager 306 as illustrated by logic flow diagram 400 ( Figure 4). Recipient profile processor 308 ( Figure 3) performs such recipient-specified processing for each recipient of the package independently of other recipients of the package. In test step 402, recipient profile processor 308 determines whether any profiles exist for the recipient. In particular, recipient profile processor 308 determines the recipient either from data specified by the sender when interacting with package manager 302 ( Figure 3) or from the package itself, e.g., package 206 ( Figure 2). In addition, recipient profile processor 308 ( Figure 3) retrieves the recipient's user record 204 ( Figure 2). User record 204 can include pointers to one or more profile records such as profile record 208 or, alternatively, nil to indicate that no profiles are established for the recipient.
  • Loop step 406 and next step 412 define a loop in which each rule of each profile is processed according to steps 408-410.
  • Each profile includes one or more rules.
  • profile record 208 ( Figure 2 and shown in greater detail in Figure 5) includes one or more rule records 502.
  • Each rule record, e.g., rule record 502 includes one or more condition records 602 ( Figure 6) and one or more action records 604.
  • the rule processed according steps 408- 410 is referred to herein as the subject rule.
  • recipient profile processor 308 determines whether the conditions represented by the condition records of the subject rule are collectively met by the subject package.
  • each condition e.g., condition record 602 ( Figure 6)
  • attributes of a package are described in greater detail below. Briefly, such attributes can include the sender, one or more recipients, the subject, the message body, delivery attributes, post handling procedures, and one or more attached files.
  • Package-independent attributes include, for example, date/time, time since or before an event, and recipient-specified state variables such as 'on vacation' and 'traveling on business.
  • ' Boolean expressions involving the sender and/or recipients of a package can specify all or part of e-mail addresses, for example using a regular expression.
  • One possible use of e-mail addresses in a condition would be to distinguish recipients within an organization of which the sender is a member from recipients outside such an organization.
  • Boolean expressions involving textual attributes such as subject and message body and textual content of attached data files can be used to search for inappropriate terms which can be offensive to the recipient or which indicate that the package is an unwanted solicitation or can indicate an urgent matter requiring immediate attention.
  • Boolean expressions involving delivery attributes and post delivery handling procedures can be used to direct the package to an appropriate destination device. For example, packages for which hardcopy printing is permitted can be selectively routed to a printer. Boolean expressions involving attached data files can be used to detect the spread of malicious programs and to discriminate between professional and personal correspondence.
  • FIG. 9 shows a tree structure 900 in which a number of conditions, e.g., conditions 602 and 602B-E, are related to one another by boolean operators 902-908.
  • boolean operator 902 specifies a logical "OR" relation between conditions 602 and 602B-C
  • boolean operator 904 specifies a logical "AND" relation between conditions 602D-E
  • boolean operator 906 specifies a logical negation of the intermediate result of boolean operator 904
  • boolean operator 908 specifies a logical "AND” relation between the intermediate result of boolean operator 902 and the intermediate result of boolean operator 906.
  • recipient profile processor 308 determines that the conditions of the subject rule, collectively in accordance with logical relations to one another, are not satisfied by the subject package, processing transfers from test step 408 ( Figure 4) to next step 412, skipping step 410, and the next rule is processed according to the loop of steps 406-412. Conversely, if recipient profile processor 308 ( Figure 3) determines that the conditions of the subject rule, collectively in accordance with logical relations to one another, are satisfied by the subject package, processing transfers from test step 408 ( Figure 4) to step 410.
  • recipient profile processor 308 ( Figure 3) adds all actions for the subject rule to a list of actions for the subject package. This list is initialized to be empty upon initiation of processing according to logic flow diagram 400 ( Figure 4) and at least prior to processing according to the loop of steps 406-412. While performance of actions of the list is postponed in this illustrative embodiment until conditions of all rules of a profile have been tested, such actions are performed immediately in an alternative embodiment.
  • processing transfers to next step 412 and the next rule is processed according to the loop of steps 406-412. Once all rules of all profiles of the recipient have been processed according to the loop of steps 406-412 ( Figure 4), processing transfers to step 414.
  • recipient profile processor 308 orders the actions of the list of actions according to priority. Some actions work better if performed before other actions. For example, if an action modifies the body of a message of a package and another action forwards a copy of the package to a predetermined recipient, it is preferred that the copy include the modified body. In other words, it is preferred that the modification action precedes the forwarding action.
  • Figure 10 shows action 604 in greater detail.
  • Action 604 includes an action body 1002 which specifies the specific action to be taken when performing action 604, and a priority 1004.
  • Priority 1004 is established by the recipient and, in step 414 ( Figure 4), recipient profile processor 308 ( Figure 3) sorts actions of the list such that higher priority actions are performed before actions of lower priority.
  • Figure 11 shows an action 604B in accordance with an alternative embodiment.
  • Action 604B includes action data 1102 and a reference 1104 to an action definition 1106.
  • Action data 1102 specifies data relevant to the action represented by action 604B. For example, if action 604B specifies that a copy of the package is to be forwarded, action data 1102 can specify an e-mail address to which the copy is forwarded.
  • Action definition 1106 specifies the details of the action to be taken and includes a priority 1108.
  • Priority 1108 is established by the recipient and, in step 414 ( Figure 4), recipient profile processor 308 ( Figure 3) sorts actions of the list such that higher priority actions are performed before actions of lower priority.
  • step 416 processing transfers to step 416.
  • the list of actions to be performed with respect to the subject package can contain duplicate, redundant actions. For example, a single package can satisfy more than one set of conditions thereby potentially adding identical actions to the list of actions. Accordingly, recipient profile processor 308 ( Figure 3), in step 416 ( Figure 4), removes duplicate actions from the list of actions to perform with respect to the subject package. Thus, each action is performed only once for the subject package.
  • steps 414-416 are not important.
  • step 416 can be performed before step 414.
  • actions associated with satisfied conditions are performed in step 410 above in an alternative embodiment as described above.
  • steps 414-422 are obviated.
  • Loop step 418 and next step 422 define a loop in which recipient profile processor 308 ( Figure 3) performs each of the actions of the list of actions in step 420 ( Figure 4) for the subject package.
  • Actions performed by recipient profile processor 308 ( Figure 3) in step 420 ( Figure 4) and specified by action record 604 ( Figure 6) generally affect the delivery of the subject package. While there are many types of actions which can affect delivery of the subject package, three (3) major categories are particularly useful in conjunction with the illustrative embodiment described herein. In particular, actions can (i) direct delivery of the package, (ii) distribute information regarding the package, and/or (iii) modify the package.
  • Actions in the first category include discarding the package, selecting a folder into which to place the package, and automatically replying to the sender of the package.
  • a package can be discarded by directing that the package be placed in a folder designated as "trash.”
  • Folders are collections of received packages — and perhaps copies of sent packages — organized in a manner specified by the recipient.
  • Recipient profile processor 308 ( Figure 3) can discard a package by deleting the package record representing the discarded package, e.g., package 206.
  • recipient profile processor 308 can discard a package by placing the package in a folder designated "trash.”
  • Recipient profile processor 308 places a package in a folder by storing a reference to the package, e.g., package 206, in a folder record representing the folder or, alternatively, by storing data in package 206 identifying the folder.
  • Recipient profile processor 308 automatically replies to the sender by sending a package to the sender with a message body previously specified by the recipient.
  • recipient profile processor 308 While a package can be used to automatically reply to the sender, more immediate feedback can be presented to the sender if recipient profile processor 308 interacts with package manager 302. For example, if recipient profile processor 308 is performing recipient-specified processing through interaction with package manager 302, it is likely that the sender is still engaged in an interactive session with package manager 302 and is waiting for some feedback regarding processing of the package. In this situation, recipient profile processor 308 can automatically reply to the sender by causing package manager 302 to including the automatic reply in feedback to the sender, perhaps by presenting an HTML page which includes the substance of the automatic reply. Since such occurs during an interactive session with the sender, the sender has the opportunity to immediately take corrective action such as sending a similar package to another recipient.
  • Actions by recipient profile processor 308 which distribute information regarding a package include redirecting the package to a different recipient, sending a copy of the package to a different recipient, and notifying a different recipient of the existence of the package.
  • Recipient profile processor 308 redirects a package by substituting a new recipient for the original recipient. The package is then delivered to the new recipient and the original recipient of the package never receives the package. Such is useful if the original recipient has shed a responsibility assumed by another. Packages pertaining to such a responsibility, e.g., handling vacation requests withing a department of a company, can be redirected to the person currently handling that responsibility without cluttering the in-box of the original recipient.
  • Recipient profile processor 308 can send a copy of a package to a predetermined entity, e.g., at a predetermined e-mail address.
  • the e-mail address can correspond to a third party interested in the type of package received or can be an alternate e-mail address for the recipient, e.g., an alphanumeric pager.
  • Notification of a package is similar to sending a copy of the message except that the notification can include less than the entirety of the package, e.g., the subject only or the subject and message with no attached data files, or can contain no text of the package itself.
  • the notification can be a previously specified textual message indicating that a package has been received.
  • the notification message can include some information regarding the received package such as the sender of the package and the priority of the package. As with sending a copy of a package, the notification message can be sent to an e-mail address of an interested third party and/or an alternative e-mail address of the original recipient, e.g., to an alphanumeric pager, wireless telephone with text messaging capability such as Short Message Service (SMS) or Wireless Application Protocol (WAP), printer, fax machine, etc.
  • SMS Short Message Service
  • WAP Wireless Application Protocol
  • Recipient profile processor 308 can perform actions which modify the package. Actions which modify the package modify one or more of the fields of the package. For example, an action can prepend or append text to the message body of the package, can remove all attached data files or those attached data files which satisfy the conditions of the rule, and can modify parameters of the package such as the package's priority. In addition, actions can modify the package by removing malicious computer instructions from one or more attached data files, can compress or decompress one or more attached data files, and can initiate execution one or more computer processes while supplying one or more attached data files to the one or more computer processes as input data. The latter action allows new actions to be developed subsequently and used to process attached data files without requiring creation of new actions recognized by and applied by recipient profile processor 308 ( Figure 3).
  • recipient profile processor 308 ( Figure 3) determines whether the subject package is ready to be delivered. In this illustrative embodiment, all packages which are not discarded or redirected are ready to be delivered. If the subject package is discarded or redirected, processing transfers to terminal step 428 ( Figure 4) in which processing accordmg to logic flow diagram 400 terminates and the subject package is not delivered. Conversely, if the subject package is ready to be delivered, processing transfers to terminal step 426 in which processing according to logic flow diagram 400 terminates and delivery of the subject package in the manner described above continues.
  • packages are addressed from a sender to one or more recipients and can include a message and one or more attached data files.
  • profile conditions include boolean expressions involving attributes of a package, and application of a rule can modify a package.
  • a package e.g., package 206 ( Figure 2), is shown in greater detail in Figure 7.
  • Package 206 includes a sender field 702.
  • a condition such as condition 602 ( Figure 6) can include boolean expressions involving sender field 702 ( Figure 7).
  • condition 602 can include a regular expression which can match one or more e- mail addresses. Regular expressions are well-known and are not described herein. Regular expressions are considered a type of boolean expression in which a matching condition is equivalent to a "true" boolean value and a non-matching condition is equivalent to a "false" boolean value.
  • Condition 602 can also include a boolean expression involving an attribute of a user record, e.g., user record 204, corresponding to the sender specified in sender field 702.
  • package and account datastore 120 includes data mapping various e-mail addresses to corresponding user records such as user record 204 in one embodiment.
  • recipient profile processor 308 ( Figure 3) can access data representing one or more characteristics of the sender from an external directory 122 ( Figure 1) which is accessible through computer network 110.
  • Directory 122 is an external directory accessible according to a database access protocol such as the X.500 Standard or a similar directory service such as Lightweight Directory Access Protocol (LDAP), NetWare Directory Service (NDS), and Active Directory.
  • LDAP Lightweight Directory Access Protocol
  • NDS NetWare Directory Service
  • Active Directory information regarding the sender can be obtained from external databases which are not traditionally considered user directories.
  • Directories are databases which are intended to be read more often than written such that data stored therein is relatively stable and unchanging. Similar data can be stored in a regular database as well.
  • Recipient profile processor 308 ( Figure 3) is configured to retrieve data representing one or more characteristics of the sender from a database in which data in sender field 702 ( Figure 7) is directly or indirectly associated with data representing the sender.
  • databases can include, for example, human resources databases, customer care and support databases, and enterprise resource planning (ERP) databases such as that provided by SAP AG (see, e.g., http://www.sap.com on the World Wide Web).
  • ERP enterprise resource planning
  • Such databases include information about users and provide some mechanism for accessing such information — typically an Applications Programming Interface (API).
  • API Application Programming Interface
  • User record 204 can include classification data which is useful in determining membership of the sender in any of a number of groups.
  • a condition can include a boolean expression which determines whether the sender is in the legal department or sales department of the same company as the recipient or works in a specific office of the company, e.g., a Japanese branch office.
  • the recipient profile processor 308 can apply different rules to various senders.
  • User record 204 is shown in greater detail in Figure 12. Each of the fields of user record 204 can be used in a condition such as condition 602 ( Figure 6) to identify packages from a particular sender or a particular class of senders.
  • User record 204 ( Figure 12) includes a name field 1202, an e-mail address 1204, a group field 1206, a title field 1208, an organization field 1210, an account field 1212, a database identifier 1214, a schedule pointer 1216, user-defined state variables 1218, and public key 1220.
  • Name field 1202 specifies the name of the user represented by user record 204, referred to as the subject user in the context of Figure 12.
  • E-mail address 1204 specifies the e-mail address of the subject user.
  • Group 1206 specifies one or more groups or departments to which the subject user belongs.
  • Title field 1208 specifies the title or position held by the subject user.
  • Organization field 1210 specifies an organization or company of which the subject user is a member or employee, respectively. It should be appreciated that user record 204 is merely illustrative and can include additional or different fields. It should also be appreciated that the fields of user record 204 can be user-customizable in some embodiments.
  • Account field 1212 references an account 1222 by which the subject user is granted access to package delivery system 100 ( Figure 1). By conditioning processing of a package upon aspects of the account of the sender, the recipient can be mindful of sending large automated reply messages to a sender for whom package storage is a significant cost issue.
  • Database identifier 1214 identifies the subject user within directory 122, thereby enabling the recipient to specify processing contingent on one or more attributes of the sender as stored in directory 122.
  • Schedule pointer 1216 and user-defined state variables 1218 are described more completely below. Briefly, schedule pointer 1216 references a schedule data file 1226 which represents an appointment calendar or similar schedule for the subject user, and user-defined state variables 1218 store data representing aspects of the state of the subject user, e.g., on vacation, traveling on business, extended leave of absence, etc. Alternatively, the subject user's schedule can be represented by a scheduling system which is accessible through an API. In such an alternative embodiment, schedule pointer 1216 identifies the scheduling system and can include zero or more access parameters of the scheduling system rather than a data file.
  • Package 206 ( Figure 7) includes recipients field 704.
  • Recipients are specified in a number of sub-fields, namely, TO sub-field 706, CC sub-field 708, and BCC sub-field 710 which specify, respectively, direct recipients, carbon-copied recipients, and blind carbon- copied recipients.
  • recipients specified in BCC sub-field 710 are not determinable by other recipients of package 206 and therefore cannot be the subject of any conditions specified by a recipient.
  • Recipients specified in either recipients field 704 itself or any sub-field thereof except BCC sub-field 710 — can be included in conditions such as condition 602 ( Figure 6) in a manner analogous to that described above with respect to sender field 702 ( Figure 7).
  • recipients can be specified as matching a regular expression or by matching an attribute of a user record, e.g., user record 204 ( Figure 2), corresponding to the recipient field or sub-field.
  • actions e.g., as represented by action record 604 ( Figure 6), which send copies of a package do so in this illustrative embodiment by duplicating package 206 ( Figure 7) and changing contents of TO sub-field 706 to specify the recipient to whom the copy is sent.
  • the body of the message as represented in body field 714 described below can be modified to identify the copy as such. Testing for recipients is useful since the recipient can make certain actions conditional upon other recipients to whom the package is sent or upon whether the subject recipient is identified in TO field 706 or CC field 708. Conditions can apply to recipients in the manner described above with respect to senders including, for example, use of regular expressions and X.500 or similar directories.
  • Subject field 712 ( Figure 7) of package 206 specifies a textual subject of the package for convenience in categorizing and handling of the package.
  • Body field 714 of package 206 stores the substantive content of the message of the package represented by package 206.
  • Conditions e.g., condition record 602 ( Figure 6)
  • Rules can match a subject or body using a boolean expression and/or a regular expression.
  • Rules such as rule record 502 can use such conditions to detect terms or phrases in subject field 712 ( Figure 7) and/or body field 714. which indicate priority (e.g., "urgent,” "important,” or "ASAP"), which indicate an unwanted commercial solicitation, or which are offensive to the recipient.
  • priority e.g., "urgent,” "important,” or "ASAP”
  • Body attributes field 716 of package 206 specifies characteristics of the body represented in body field 714.
  • Such attributes can include, for example, the particular format of the body, e.g., text, rich text format (RTF), or HTML, and the particular character set of which the body is composed.
  • a condition involving body attributes can be used, for example, to detect packages with HTML bodies, and an associated action can convert the HTML body to a text or RTF body, thereby eliminating active components of HTML content such as javascript elements.
  • Delivery attributes 718 specify the manner in which package 206 is delivered.
  • delivery attributes 718 can specify a relative priority of the package, whether a receipt notification is to be sent to the sender, a time at which to deliver the package, a time at which the package expires, and a code for billing purposes.
  • delivery attributes 718 can include security attributes specifying, for example, whether a secure connection though computer network 110 ( Figure 1) is required, whether package 206 ( Figure 7) and attached data file records 750 are to be encrypted while stored in datastore 120 ( Figure 1), whether a sender-specified password is required to retrieve the package, and whether an account password is required to retrieve the package.
  • An account password is the password by which a particular user is authenticated as a prerequisite for access to system 100.
  • the account password of the sender is specified in user record 204 ( Figure 2).
  • Conditions such as condition record 602 can specify specific delivery attributes. For example, packages with relatively high priority can cause the recipient to be notified, e.g., by an e-mail address directed to an alphanumeric pager or wireless telephone with text messaging capability such as SMS or WAP.
  • Actions of rules can modify the delivery attributes of a package. For example, a recipient can increase the relative priority of packages whose expiration approaches. Such a rule would be the equivalent of "if this package expires in less than two days, increase the priority of this package.”
  • Post delivery handling procedures 720 specify the types of actions recipients of package 206 can take with respect to package 206 once received.
  • Post delivery handling procedures are described, for example, in U.S. Patent Application S/N 09/475,608 filed December 30, 1999 by Jean-Christophe Bandini and Dmitri Dolinsky for "Sender- Controlled Post Delivery Handling of Digitally Delivered Documents" and that description is incorporated herein by reference.
  • the sender can allow recipients to handle — e.g., reply to, forward, print, and save — a received package.
  • rules can be established with conditions which include boolean expressions involving post-delivery handling procedures 718 to use apre-paid reply for automated reply messages if pre-paid replies are permitted by the sender or to automatically print or save the package if printing or saving is respectively permitted.
  • server 108 ( Figure 1) makes post delivery handling procedures 720 inaccessible to the recipient. As a result, recipient-specified conditions involving post delivery handling procedures 720 are not permitted in this alternative embodiment.
  • Custom attributes 722 can be used to specify characteristics of package 206 other than those specified in the other fields of package 206.
  • custom attributes 722 include a list of associated name/value pairs. In each pair, a name identifies the particular attribute and the value specifies the particular value of that attribute for package 206.
  • Custom attributes 722 make package 206 extensible since attributes which are not conceived at the time system 100 is implemented can be added and represented in custom attributes 722.
  • Package 206 can also include keywords 724 which indicate significant portions of the content of package 206. Similar to subject field 712, keywords 724 provide a summation of the content of package 206 and can be used by the recipient to determine the nature of package 206 for appropriate processing.
  • Package 206 can include one or more attached data files.
  • package 206 includes attached data file records 726 each of which references a respective data file which is considered attached to package 206.
  • Attached data file 750 is such an attached data file.
  • attached data files such as attached data file 750 are included within package 206 in an encoded form.
  • Attached data file 750 includes a name 752, a MIME (Multipurpose Internet Mail Extension) type 754, a size 756, custom attributes 758, and substantive content 760.
  • Name 752 specifies a name of attached data file 750.
  • MIME type 754 specifies a type of data file. For example, MIME type 754 can specify that attached data file 750 is a Microsoft Word document or a text document or a JPEG image.
  • Size 756 specifies the size of attached data file 750.
  • Custom attributes 758 represent subsequently defined attributes in a manner analogous to that described above with respect to custom attributes 722. For example, custom attributes 758 can include a number of attribute names and associated respective attribute values.
  • Conditions involving data file names as specified by name 752 can be used to detect specific files to detect packages which include data files of specific types.
  • Conditions involving data file types as specified by MIME type 754 can be used to detect packages to which data files of specific types are attached. If a name of an attached data file does not accurately indicate the type of data file, MIME type 754 is likely to accurately indicate the type.
  • the sender can change the name of a data file or convert the data file from one type to another to circumnavigate such rules
  • automatic execution of certain data files containing malicious computer instructions depends upon recognition of certain data file types by the operating system of the recipient. Accordingly, detection of data file types which can carry such malicious computer instructions is effective since attempts to defeat such detection will likely also defeat any automatic execution of the malicious computer instructions.
  • Conditions involving size 756 can be used to limit the size of attached data files of a package or the total size of a package.
  • the recipient can limit the size of attached data files and/or the size of the entire package or can specify actions to be performed upon such a package having a certain total size or having attached data files of a certain size.
  • Conditions involving content 760 can examine the substantive content of attached data file 750. Such conditions typically require more processing resources than are required for conditions involving other attributes of attached data files and of package 206. Accordingly, conditions involving content 760 are typically enforced by recipient profile processor 308 ( Figure 3) through delivery manager 306 rather than through package manager 302. As a result, the sender receives relatively quick acknowledgment of submission of package 206 ( Figure 7) and can go on to perform other tasks while recipient profile processor 308 ( Figure 3) and delivery manager 306 asynchronously examine content 760 ( Figure 7) of attached data file 750 of package 206.
  • Such conditions can determine whether words and/or phrases which are present in the substantive content of the attached data file indicate that the attached data file is an unwanted commercial solicitation or is offensive to the recipient or otherwise is of particular interest to the recipient.
  • such conditions can scan the substantive content for malicious computer instructions such as Trojan horses or viruses.
  • recipient profile processor 308 can determine whether an attached data file is executable, i.e., capable of execution within a computer.
  • Recipient profile processor 308 can similarly determine, by reference to the type or content of attached data files, whether an attached data file is capable of including macros — a collection of computer instructions embedded in otherwise non-executable data files. Conditions based on whether an attached data file is executable or is capable of including macros provide a useful means to determine the degree to which security is compromised by accepting a package including such an attached data file.
  • Such attached data files can be scanned for malicious computer instructions such as viruses or Trojan horses and, if detected, can have those malicious computer instructions removed or such attached data files can be removed entirely from the package. If the recipient determines that security is so compromised that virus scanning is not to be relied upon, the entire attached data file can be removed or the entire package can be discarded.
  • the sender can be sent an automatic reply message indicating that the malicious computer instructions were found, perhaps identifying the data file in which the malicious computer instructions were found. Similarly, the sender can be sent an automatic reply message indicating that executable data files or data files containing macros are not accepted by the recipient.
  • attached data file 750 can be an archive of one or more data files compressed in accordance with the known and ubiquitous ZIP compression format.
  • Recipient profile processor 308 therefore extracts embedded data files from any attached data files 750 and performs recipient-specified processing to each of the extracted files and extracts any embedded data files from the extracted data files in a recursive fashion.
  • recipient-specified processing cannot be avoided by merely compressing an attached data file which would otherwise be singled out for processing in accordance with the profile established by the recipient.
  • rule 502 can include conditions 602 which are independent of the contents or parameters of a particular package.
  • One such condition is the time at which the package is to be delivered.
  • Recipient profile processor 308 ( Figure 3) has access to a clock or time server within server 108 and can determine current date and time in a conventional manner. Accordingly, conditions can detect attempted delivery of a package at certain predetermined times such as non-business hours and weekends and holidays. For example, the recipient can have packages forwarded to a home e-mail address of the recipient if delivery of the package is attempted during non-business hours or days. By combining such a condition with a condition detecting high priority packages, the recipient can specify that only high priority packages are forwarded to the recipient's home e-mail address during such non-business hours and days, for example.
  • the recipient can also specify conditions related to time before or since an event.
  • Such an event can be, for example, submission of a package, attempted delivery notification of the recipient, access of the package or one or more attached data files by the recipient, and expiration of the package.
  • Example usages of such conditions include, for example, (i) incrementing priority of the package and forwarding a copy of the package to a third party recipient if an amount of time has elapsed since delivery of the package is attempted without access to the package from the recipient (e.g., "forward this message to Joanne if I do not access this package within five days of its attempted delivery"); (ii) discarding a package a predetermined amount of time after the package and all attached data files are accessed successfully by the subject recipient; and (iii) incrementing priority of a package and notifying the recipient by alternative means (e.g., an alphanumeric pager or wireless telephone with text messaging capability) if a package will expire within a predetermined amount of time and the package has not yet been accessed
  • recipient profile processor 308 determines a time at which evaluation of the condition should be performed and schedules such evaluation at that time. For example, if a condition is based upon five days after attempted delivery of the package, recipient profile processor 308 determines the time of the attempted delivery of the package, adds five days to that time to determine a condition time, and schedules a task which evaluates the condition to execute at the condition time. At the condition time, the scheduled task of the package processing module executes and evaluates the condition — by determining whether the package has been accessed by the recipient for example.
  • recipient profile processor 308 can determine the overall boolean value of the boolean expression to thereby determine whether to perform the associated actions of the rule, e.g., rule 502 ( Figure 6).
  • Recipient profile processor 308 can also process a package conditionally upon the schedule of the recipient as represented in schedule data file 1226 ( Figure 12).
  • server 108 implements a web-based calendar system similar to the web-based calendar system implemented by Netscape Communications Corporation and accessible through the World Wide Web at http://calendar.netscape.com .
  • Recipient profile processor 308 can query schedule data file 1226 to determine if the recipient is scheduled to be in a meeting and, if so, with whom.
  • the recipient can specify, for example, that notification messages are sent to an alphanumeric pager of the recipient (i) if the recipient is in a meeting, (ii) only if the recipient is not in a meeting, or (iii) if the recipient is in a meeting and the package in question has a high priority or is from a specific sender.
  • schedule data file 1226 can indicate holidays and processing can be conditioned upon whether a particular day is a holiday.
  • the recipient's schedule can be specified in a scheduling system in which the recipient's schedule can be determined through an API.
  • user-defined state variables 1218 specify user-defined aspects of a user's state.
  • Recipient profile processor 308 can use user-defined state variables 1218 ( Figure 12) to condition processing of received packages in accordance with the recipient's state.
  • the recipient can specify that aspects of the recipient's state can include "on vacation” and "traveling on business.”
  • the recipient can thereafter toggle such aspects of the recipient's state on and off.
  • the recipient can set an "on vacation” flag as the recipient begins a vacation. Accordingly, any processing of incoming packages is performed in the context of the recipient's updated state, namely, in the context of the fact that the recipient is on vacation.
  • the recipient can reset the "on vacation” flag to false to indicate that the recipient is no longer on vacation.
  • Recipient profile processor 308 is shown in greater detail in Figure 8.
  • Recipient profile processor 308 includes a profile editor 802, a profile store manager 804, and a profile processor 806, each of which is all or part of one or more computer processes executing within server 108 ( Figure 1).
  • Profile store manager 804 stores profile records, e.g., profile record 208 ( Figure 2), in datastore 120 and associates the profile records with user records, e.g., user record 204, to which the profile records pertain.
  • each user record includes a reference to a list of all profile records which pertain to the user, and each profile record includes a reference to the one or more user records representing the users to which the profile record pertains.
  • profile records stored by profile store manager 804 can be in any format convenient for profile processor 806.
  • profile records can represent profiles in any of the textual formats described below or in a binary representation in which similar information is stored.
  • Profile records can be stored as one or more flat data files, as a relational database, or as an object oriented database. Flat data files, relational databases, and object oriented databases are known and are described further herein.
  • Profile processor 806 ( Figure 8) includes logic which implements profiles of a recipient in the manner described above with respect to logic flow diagram 400 ( Figure 4).
  • Profile editor 802 interacts with the recipient through computer system 104 ( Figure 1) and computer network 110 to define one or more profiles, e.g., profile record 208 ( Figure 2), which are applicable to packages sent to the recipient.
  • Profile editor 802 can interact with the recipient in any of a number of ways. For example, the recipient can submit a textual data file specifying a profile and profile editor 802 can parse the textual data file, form a profile record such as profile record 208 ( Figure 2) and submit the profile record to profile store manager 804 ( Figure 8) for storage in datastore 120. Possible textual formats for profiles are described more completely below.
  • profile editor 802 can provide an interactive interface by which the recipient can add, delete, and modify rules of a profile.
  • the interface provides mechanisms by which the recipient can add, delete, and modify conditions and actions of a specific rale when adding or modifying a rule of the profile.
  • the recipient is prompted for (i) a parameter of a package or other package-independent parameter, (ii) a relation, and (iii) a data value.
  • Parameters include, for example, those described above with respect to package 206 in Figure 7 and those package-independent parameters described above, and the recipient can be presented with a list of such parameters from which to select a parameter.
  • Relations can include such relations as "contains,” “is equal to,” “is greater than,” “is less than,” and negations of each such relation, and the recipient can select such a relation from a list of available relations.
  • the recipient specifies a data value by entering the value.
  • Profile editor 802 ( Figure 8) in this illustrative embodiment verifies that the entered data value conforms to any validity constraints imposed upon the selected package parameter. For example, if the selected package parameter of the condition is a date, profile editor 802 ensures that the condition data value entered by the recipient is a valid date in the same manner that the package parameter is verified to be a valid date.
  • the interactive interface of profile editor 802 is implemented as a set of one or more HTML forms. HTML forms are known and are not described further herein.
  • the interactive interface is implemented by all or part of one or more computer processes executing within computer system 104 ( Figure 1) which converts the profiles specified by the recipient to one or more data files representing the profiles in a format which is recognized by profile editor 802 ( Figure 8).
  • the format can be any of the textual formats described below.
  • profile editor 802 recognizes profiles in a standard format, such as textual; conventional editors executing within computer system 104 ( Figure 1) can be used by the profile authority to specify a profile which is submitted through computer network 110 to server 108 and profile editor 802 ( Figure 8).
  • a standard format such as textual
  • conventional editors executing within computer system 104 Figure 1
  • Figure 8 profile editor 802
  • the NOTEPAD and WORDPAD programs available from Microsoft Corporation of Redmond, Washington in conjunction with their WINDOWS® family of operating systems can be used to edit profiles in the textual formats described below.
  • a rule list Two illustrative formats for profile specification are described herein: a rule list and a scripting language. Each can be represented textually, e.g., in the known ASCII and XML formats, or as binary data.
  • the rule list format is a simple list of rules, each of which is a pairing or association of a list of one or more conditions with a list of one or more actions.
  • EventAttribute ExternalAttribute CurrentTime OR CurrentDate OR RandomNumber OR
  • CustomAttribute(AttributeName) OR etc.
  • FileAttribute has a recursive definition since some file formats include a list of embedded files. For example, compressed data formats such as the popular and known ZIP compressed data format embeds a number of files within a compressed file. In addition, each embedded file can also have embedded files, e.g., can be a compressed data file in the ZIP format.
  • the scripting language format represents processing performed on behalf of the recipient in the form of a scripting language.
  • a number of predefined objects express conditions in the known ECMA-262 scripting language of the European Computer Manufacturers Association (ECMA).
  • ECMA-22 (sometimes referred to as ECMAscript or JavaScript) is known and is not described further herein.
  • actions are represented by predefined methods in the ECMA-262 scripting language.
  • the following objects are illustrative examples of objects which can represent parameters: sender.directoryLookup(directory, attributeName), recpient.directoryLookup(directory, attributeName), package.subject, package.body, package.sendDate, package.deliveryTime, package.priority, package.securityOption, package.file[index], package.file[index].
  • package.file.scanText("regular expression") current.time, current.date, timeSince(event), timeBefore(event), recipient.schedule(time, date), and customAttribute(nanie).
  • actions can be represented as object properties which can be written in the scripting language. For example, "(URGENT)" can be appended to the subject by the script instruction:
  • a package can be directed to a particular folder by the script instruction:
  • the rules list format and script format can be combined. For example, conditions can be expressed in the rules list format while actions are expressed as scripts. Alternatively, conditions can be expressed as scripts while actions are expressed in the rules list format described above. Furthermore, these illustrative formats are exactly that: illustrative. Other formats are possible for specifying conditions and associated actions to be taken if the conditions are satisfied.
  • processing of a package can be automatically processed on behalf of the sender and/or a policy authority of the sender in a manner described in U.S. Patent Application S/N 09/540,023 filed March 31, 2000 by Jeffrey C. Smith and Jean- Christophe Bandini for "Policy Enforcement in a Secure Data File Delivery System" and that description is incorporated herein by reference.
  • any automated processing on behalf of the sender is performed first, followed by processing in a manner specified by a policy authority of the sender, and then followed by automated processing on behalf of the recipient.
  • the present invention is defined solely by the claims which follow and their full range of equivalents.

Abstract

A server interacts with a sender to form a package which can include one or more attached data files to be sent to one or more recipients, and the server processes the package in a manner previously specified by the recipient and represented in a profile. The server delivers the package to the one or more intended recipients by sending notification to each recipient and including in such notification package identification data, e.g., a URL by which the package can be retrieved. The profile of the recipient can be specified as a list of associations between one or more conditions and one or more actions to be carried out upon satisfaction of the associated conditions.

Description

RECIPIENT-SPECIFIED AUTOMATED PROCESSING IN A SECURE DATA FILE
DELIVERY SYSTEM
SPECIFICATION
This is a continuation-in-part of U.S. Patent Application S/N 09/540,023 filed March 31, 2000.
FIELD OF THE INVENTION
The invention relates to data transfer through computer networks and, in particular, to a mechanism by which packages to be delivered to a recipient are automatically processed in a manner specified by the recipient.
BACKGROUND OF THE INVENTION
The Internet has grown tremendously in recent years, both in terms of number of users and the amount of data transferred through the Internet. Originally, the Internet was a data transfer medium for academia. Eventually, engineers and private users increasingly used and became more familiar with the Internet. More and more, the Internet is becoming an acceptable communication medium for business. However, business users demand more confidentiality and traceability of communication than do private users engaging in personal correspondence.
Business users often communicate sensitive, confidential, and proprietary information and, accordingly, expect such communication to be secure from unauthorized eavesdropping. In addition, business users expect to be able to store records tracing correspondence. Accordingly, to provide a medium for business communication, Internet- based communication must be made secure and traceable.
While security and traceability of Internet-based communication is improving, many of the conveniences of conventional paper mail is still lacking in current Internet messaging systems. For example, a business person can instruct support staff to examine contents of the business person's in-box and forward any items from a particular party to another person for special attention. Current e-mail clients, whether web-based thin clients or thick clients, are generally limited to conditional processing based on textual analysis of the contents of the message and result in sorting the message into one of a number of folders. Such is generally inadequate to satisfy the ever increasing demands for information processing imposed upon today's businesses. In addition, such conventional e-mail clients typically provide inadequate package security and traceability.
What is needed is a secure, traceable data file delivery system in which automated processing of messages is supported.
SUMMARY OF THE INVENTION
In accordance with the present invention, a server interacts with a sender to form a package which can include one or more attached data files to be sent to one or more recipients, and the server automatically processes the package in a manner specified by the recipient of the package. Since the server both forms the package through interaction with the sender and processes the package as specified by the recipient, automated processing on behalf of the recipient can be interactive with the sender in a way not previously achieved. For example, the sender can be immediately notified that the recipient is temporarily unavailable during an interactive session with the server. As a result, the sender can modify the package immediately in response to any automatically generated, synchronous response, e.g., to direct the package to an alternate recipient.
An additional advantage is realized by a particular embodiment in which the server is accessible through HTTP/HTTPS and the World Wide Web. Specifically, the recipient can specify automated package processing from any computer system coupled to the ubiquitous network — including a computer at the recipient's office, a computer at the recipient's home, a publicly available computer at a public library, a rented computer at a copy/printing service center, or publicly installed Internet kiosks (e.g., >STREETSPACE kiosks — http://www.streetspace.com). Therefore, at practically any time the recipient decides a change should be made to automated processing on the recipient's behalf, the recipient can access and modify the profile of the recipient which specifies such processing.
As an additional advantage, automated processing in accordance with the present invention is available notwithstanding unavailability of the computer through which the recipient retrieves the package. In many thick client e-mail readers which perform filtering, such filtering can only be performed when the receiving computer is running and e-mail is retrieved. Any messages sent during the night or a weekend or while the recipient is vacationing, for example, cannot be filtered until the recipient boots the receiving computer and connects to the network for access to e-mail messages. In contrast, the server described herein is intended to execute continuously, regardless of whether the receiving computer is currently running and accessible. Accordingly, automated processing on behalf of the recipient can proceed notwithstanding inaccessibility of the receiving computer. Such is particularly useful in time-based conditional processing described more completely below.
In addition to forming the package through interaction with the sender, the server delivers the package to the one or more intended recipients. Such delivery by default includes sending notification to each recipient and including in such notification package identification data, e.g., a URL by which the package can be retrieved. However, each recipient can specify an alternative delivery mechanism within a profile associated with the recipient. For example, the recipient can specify that packages meeting certain criteria are discarded or redirected such that no notification is sent. Similarly, notification can be omitted for low priority packages such that the recipient will only get such packages when the recipient checks all incoming packages. Once notification with such package identification data is received, each recipient submits the package identification data of the received notification to the server and, in response thereto, the server presents to the requesting recipient the opportunity to retrieve the package. The notification message can be sent as e-mail via SMTP, and the package identification can be received by the server as a URL through HTTP.
The profile of the recipient which specifies the processing of packages can be represented as a list of associations between one or more conditions and one or more actions to be carried out upon satisfaction of the associated conditions. Each condition includes a boolean expression involving one or more sender attributes, recipient attributes, package attributes, and/or environmental attributes. Sender and recipient attributes can include regular expressions involving e-mail addresses by which each is specified or can include attributes of user records specifying each. User record attributes can be particularly useful in categorizing the sender and the recipients as belonging to particular groups or classifications, although it is appreciated that e-mail addresses can sometimes provide similar information. Such user record attributes can be retrieved from user records maintained by the server or from databases external to the server such as directories according to the X.500 standard or similar lightweight directory access protocols.
Package attributes include message attributes, delivery attributes, post delivery attributes, and attributes of attached data files. Message attributes include a subject and a message body. Conditions involving message attributes can be used to detect unwanted commercial solicitations and/or offensive or inappropriate content such as sexually explicit language for example. Delivery attributes include such things as package delivery priority, security options, and delivery timing. Conditions involving delivery attributes can detect packages using options which indicate a level of priority or security of a particular package. Accordingly, recipient-specified processing can be based upon the level of priority or security of a particular package. Post delivery attributes specify actions a recipient can take with respect to the received package including replying to the sender of the package, replying to the sender of the package at the expense of the sender, forwarding the package to one or more other recipients, saving the package to local persistent storage, and printing the contents of the package. Each post delivery attribute can limit the type of automated processing available to the recipient. Accordingly, conditions can be configured to automatically detect specific uses of post delivery attributes. However, in one embodiment, post delivery attributes of a package are not directly accessible by the recipient and conditions involving post delivery attributes of a message are not permitted. Attached data files can include confidential information, can include inappropriate material, can be excessive in size, and can include malicious computer instructions in the form of viruses or Trojan horses for example. Conditions can detect specific conditions of data files attached to the package.
Environmental attributes include the current day, date, and time, time relative to an event, a state specified by the recipient, the recipient's scheduled state at a particular time. Once defined by the recipient, actions associated with conditions which are satisfied by a particular package are performed automatically. Such actions can interrupt delivery of the package, distribute the package, or modify the package. Examples of interrupting actions include discarding the package and redirecting the package. Distribution actions can include, for example, sending copies of, or notification messages regarding, the package to other recipients or to the same recipient at another address. Modification actions can modify the package by changing the subject, the message, delivery attributes, post -delivery attributes, and the attached data files. For example, all attached data files can be removed or only those attached data files which satisfy a particular set of conditions can be removed. In addition, a modification action can place the package in a specific folder on behalf of the recipient.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram of a delivery system in accordance with the present invention.
Figure 2 is a block diagram of the package and account datastore of Figure- 1 in greater detail.
Figure 3 is a block diagram of the server of Figure 2 in accordance with the present invention.
Figure 4 is a logic flow diagram of the implementation of profiles by the server of Figure 2 in accordance with the present invention.
Figure 5 is a block diagram of a profile in accordance with the present invention.
Figure 6 is a block diagram of a rule of the profile of Figure 5 in greater detail.
Figure 7 is a block diagram of a package of Figure 2 in greater detail.
Figure 8 is a block diagram of a recipient profile processing module of Figure 3 in greater detail.
Figure 9 is a block diagram illustrating interrelationships of conditions through boolean operators.
Figure 10 is a block diagram showing an action of the rule of Figure 6 in greater detail. Figure 11 is a block diagram showing an alternative embodiment of the action of the rule of Figure 6.
Figure 12 is a block diagram showing a user record in greater detail.
DETAILED DESCRIPTION
In accordance with the present invention, packages sent to a recipient through computer network 110 in a secure and traceable package delivery system are automatically processed in a manner specified by the recipient. The package is transferred by a sender to a server 108 for temporary storage in a datastore 120. Server 108 processes the package in a manner described more completely below in accordance with polices specified by the recipient. In delivering the package to the recipient, server 108 sends an e-mail notification through a computer network 110 to the recipient at computer system 104. In response to the notification, the recipient retrieves the package from server 108 through computer network 110. It should be appreciated that the notification to the recipient is a default setting in this illustrative embodiment and the behavior of sending notification to the recipient can be modified by the recipient. For example, the recipient can specify that discarded and low-priority packages do not result in notification of the recipient.
In this illustrative embodiment, automated processing on behalf of the recipient is performed by server 108. A sender sends a package which can contain a message and can also include one or more data files from a computer 102, through computer network 110 to a computer 104 through which the recipient ultimately receives the package.
A number of advantages are provided by the automated package processing mechanism described herein. First, automated processing is available notwithstanding unavailability of computer 104 of the recipient. In many thick client e-mail readers which perform filtering, such filtering can only be performed when the receiving computer is running and e-mail is retrieved. Any messages sent during the night or a weekend or while the recipient is vacationing, for example, cannot be filtered until the recipient boots the receiving computer and connects to the network for access to e-mail messages. In contrast, server 108 is intended to execute continuously, regardless of whether computer 104 is currently running and accessible. Accordingly, automated processing on behalf of the recipient can proceed notwithstanding inaccessibility of computer 104. Such is particularly useful in time-based conditional processing described more completely below.
As a second advantage, server 108 performs dual functions, namely, interaction with the sender in creating the package and processing of that package on behalf of the recipient. Accordingly, the sender can be immediately notified in accordance with the automated processing. For example, any automatic reply, such as indicating the recipient is out of the office, can be immediately delivered to the sender and the sender can act accordingly, perhaps trying to reach an associate of the recipient. Similarly, any viruses detected in data files included in a package can be immediately reported to the sender and the sender can take measures to stop further spread of the detected virus.
As a third advantage, the recipient can configure server 108 through a wide area network such as the Internet such that automated processing on behalf of the recipient can be specified from numerous locations throughout a very large geographical area. These advantages are described more completely below in conjunction with various details of package delivery system 100.
A data file can contain any type of computer-readable data such as text, graphical images, motion video, audio signals, database records, etc. Data files can be stored in any of a number of computer-readable storage media and can be transported through a computer network such as computer network 110. Computer network 110 can be either a local area network or a wide area network. In one illustrative example, computer network 110 is the Internet.
As described briefly above, datastore 120 stores packages to be delivered according to package delivery system 100. Datastore 120 is shown in greater detail in Figure 2. Datastore 120 includes a number of user records, each representing an entity capable of using package delivery system 100 (Figure 1). For example, user record 204 (Figure 2) can represent the intended recipient of a package such as package 206. As used herein, a user of system 100 can be either a human user or a computerized user. A computerized user is all or part of one or more computer processes and can send and/or receive packages through server 108 and computer network 110. It should be understood that, like the recipient, the sender and any other recipients described in this illustrative embodiment can be either human users or computerized users. Package delivery system 100 in this illustrative embodiment is sender-centric. In particular, a sender establishes an account with server 108 and initiates and controls the package delivery in the manner described in U.S. Patent 5,790,790 to Smith et al. and that description is incorporated herein by reference. Accordingly, user records 204 (Figure 2) typically represent potential senders of packages and such packages can be sent to recipients who are not represented by user records within package and account datastore 120. Automated processing of packages addressed to a particular user can be limited to those users for whom accounts are established within server 108. Alternatively, a user who otherwise has no account within server 108 can be provided with a simple account. Such an account can initially be for the sole purpose of linking the user's specified automated processing with packages addressed to the user and can be created as part of a delivery to the user in a manner described in U.S. Patent Application S/N 09/387,444 by Jeffrey C. Smith and Jean-Christophe Bandini for "Solicited Authentication of a Specific User" filed August 31, 1999 and that description is incorporated herein by reference.
Each user record, e.g., user record 204, is associated with one or more profile records 208. Each profile record 208 represents a number of rules to be applied to packages addressed to the user represented by the associated user record 204. The manner in which rules are applied is described more completely below. In addition, each profile record, e.g., profile record 208, can be associated with more than one user. For example, a single user can have multiple e-mail addresses and can specify that all profiles are to be applied to all e-mail addresses of the user. In addition, profile records can be associated with groups of users, and the groups of users can be organized hierarchically such that profiles are inherited but can be superseded by profiles associated with lower levels of the user group hierarchy.
A user, referred to as the sender, can create one or more packages for delivery to another user, e.g., the recipient. Each such package is represented individually within datastore 120. Package 206 is an example of such a package. The profiles represented by profile records 208 are applied to all packages addressed to the user of user record 204.
Server 108 is shown in greater detail in Figure 3 and includes a package manager 302, a delivery queue 304, a delivery manager 306, and a recipient profile processor 308. It should be noted that, while server 108 is shown as a single computer system coupled to computer network, server 108 can be several computer systems which cooperate with one another, perhaps through computer network 110, to provide the services described herein. Connectivity of such distributed processes is conventional and known and can be implemented using such standard and conventional techniques as sockets, pipes, remote procedure call (RPC), Common Object Request Broker Architecture (CORBA), Distributed Object Component Model (DCOM), and Java Remote Method Invocation (Java RMI). As one example of distributing server 108 among multiple computers, each of package manager 302, delivery manager 306, and recipient profile processor 308 can be implemented within a separate respective computer system or collection of computer systems. However, to provide the services described herein in an efficient manner, it is preferred that package manager 302, delivery manager 306, and recipient profile processor 308 interact through relatively quick, efficient channels, e.g., with low latency and relatively high bandwidth.
To create a package, the sender accesses package manager 302 through computer network 110 — typically after the sender is authenticated. In this illustrative example, the sender accesses package manager 302 through a web browser and package manager 302 interacts with the user through a web server, e.g., using HTML forms. Web browsers, web servers, and HTML (HyperText Markup Language) forms are known computer and/or software components used currently in conjunction with the well-known World Wide Web of the Internet. As a result, the sender can create a package from any computer system which is capable of accessing the World Wide Web through a web browser.
The interaction by which the sender creates a package through a web browser interface is described more completely in U.S. Patent Application S/N 08/957,986 by Jeffrey C. Smith, Jean-Christophe Bandini, and Randy Shoup for "Method and Apparatus for Delivering Documents over an Electronic Network" on October 2, 1997 and that description is incorporated herein by reference. A package created by the sender as represented by package 206 is described in greater detail below in conjunction with Figure 7. Briefly, the package includes address data specifying one or more recipients, subject and message data, delivery and post handling specification data, and can include one or more attached data files.
When a package is complete, package manager 302 places the completed package or, alternatively, a reference to the completed package on delivery queue 304 for delivery to the one or more recipients specified in the completed package. At the scheduled delivery time for the package, delivery manager 306 retrieves packages from delivery queue 304 and sends those packages to recipients specified in each package. By default in this illustrative embodiment, delivery manager 306 effects such delivery by forming and sending a notification message, by SMTP (Simple Mail Transfer Protocol) for example, to each recipient. Such notification messages include package retrieval data, in the form of a private universal resource locator (PURL) in this illustrative example, by which each recipient can retrieve the package through the World Wide Web according to the HyperText Transfer Protocol (HTTP), for example. Such notification and retrieval using PURLs is described more completely in U.S. Patent Application S/N 09/353,164 by Jeffrey C. Smith and Jean-Christophe Bandini for "Electronic Document Delivery System in which Notification of Said Electronic Document is Sent to a Recipient Thereof on July 14, 1999 and that description is incorporated herein by reference. Notification of the recipient is the default, and the recipient is free to specify other processing in the recipient's profile. For example, the recipient is typically not notified of discarded or redirected packages, although the recipient can specify otherwise. If the recipient wishes to maintain copies of discarded or redirected packages, the recipient can specify that discarded packages are really transferred to a "trash" folder which can later be emptied and can specify the redirected packages are really transferred to the "trash" folder while a copy is forwarded to the party to which the package is to be redirected.
In this illustrative example, recipient profile processor 308 is coupled to both package manager 302 and delivery manager 306. In alternative embodiments, recipient profile processor 308 can be coupled to either package manager 302 or delivery manager 306 alone. In interacting with package manager 302, recipient profile processor 308 can apply profiles synchronously with sending the package by the sender. In interacting with delivery manager 306, recipient profile manager 308 can apply profiles asynchronously with the sending of the package, avoiding blocking the sender during application of profiles which are time consuming. In this illustrative embodiment, recipient profile processor 308 applies profiles which include time-consuming rules or actions through interaction with delivery manager 306 and applies all other profiles through interaction with package manager 302.
One advantage of synchronous profile application through interaction with package manager 302 is that any automated reply messages can be immediately reported to the sender during interaction between the sender and package manager 302. Accordingly, the sender can immediately take action in response to the automatic reply message. For example, if an automatic reply message indicates that the recipient is unavailable for a considerable amount of time, the sender can immediately forward the original package to an alternative recipient without waiting for the automated reply message some time later.
In this way, automated processing by recipient profile processor 308 is conducted on behalf of the recipient in an interactive session of package generation with the user. The session is interactive since the sender submits the package, e.g., by pressing a "SUBMIT" button in a graphical user interface (GUI), and continues to monitor responses from package manager 302 until an acknowledgment message is received. Such an acknowledgment message can indicate, for example, that the package has successfully been submitted for delivery. By interacting with package manager 302 to apply the profile of the recipient, recipient profile processor 308 can cause package manager 302 to include an automatically generated reply message with the acknowledgment to the sender if the profile of the recipient so dictates. The immediacy of such feedback allows the sender to take corrective action, e.g., by resubmitting the package for delivery to an alternative recipient before the sender has terminated interaction with package manager 302 to go perform other tasks.
In addition, by immediately applying recipient-specified processing during an interactive session with the sender enables such processing before a package is encrypted for secure delivery. For security and confidentiality of the package during delivery, the package and/or any data files attached to the package can be encrypted after submission by the sender. Once the package and/or attached data files are encrypted, such processing — e.g., to scan for malicious computer instructions or specific text — can be impossible depending on the encryption techniques used by the package manager 302 (e.g., if the package is encrypted with a one-time password). Processing the package synchronously with submission of the package allows such processing to be preformed to the package while the package is still in cleartext form. In this illustrative embodiment, server 108 performs such encryption and, if recipient-specified processing in conjunction with delivery manager 306 is desirable, can decrypt the package and/or attached data files for such processing and re-encrypt the package and/or attached data files after such processing.
As described briefly above, some recipient-specified processing requires substantial processing resources and is therefore time-consuming. One example of such processing is the scanning of attached data files for viruses, Trojan horses, and/or other forms of malicious computer instructions. Another example includes rules which require access to external directories or databases. Requiring the sender to idly wait for such processing during an interactive session with package manager 302 may be unacceptable to the sender. Therefore, recipient profile processor 308 also interacts with delivery manager 306 to perform asynchronous recipient-specified processing upon packages queued for delivery.
Recipient profile processor 308 performs recipient-specified processing in conjunction with either package manager 302 or delivery manager 306 as illustrated by logic flow diagram 400 (Figure 4). Recipient profile processor 308 (Figure 3) performs such recipient-specified processing for each recipient of the package independently of other recipients of the package. In test step 402, recipient profile processor 308 determines whether any profiles exist for the recipient. In particular, recipient profile processor 308 determines the recipient either from data specified by the sender when interacting with package manager 302 (Figure 3) or from the package itself, e.g., package 206 (Figure 2). In addition, recipient profile processor 308 (Figure 3) retrieves the recipient's user record 204 (Figure 2). User record 204 can include pointers to one or more profile records such as profile record 208 or, alternatively, nil to indicate that no profiles are established for the recipient.
While a simple, direct association between the recipient and profiles applicable to the recipient is shown, it is appreciated that more complex associations can be implemented. One example is a hierarchical grouping of users such that profiles associated with groups are inherited by members of the group or subgroups thereof. In such an embodiment, profiles can be specified for individual members or for subgroups such that inherited profiles are superseded. Many other mechanisms can be used to associate profiles directly or indirectly with individual recipients.
If no profiles are established for the recipient, e.g., if user record 204 includes nil data to indicate no such profiles are established, processing by recipient profile processor 308 (Figure 3) transfers to terminal step 404 (Figure 4) in which the sending of the subject package is resumed and processing accordmg to logic flow diagram 400 terminates.
If one or more profiles are established for the recipient, processing transfers to loop step 406. Loop step 406 and next step 412 define a loop in which each rule of each profile is processed according to steps 408-410. Each profile includes one or more rules. For example, profile record 208 (Figure 2 and shown in greater detail in Figure 5) includes one or more rule records 502. Each rule record, e.g., rule record 502, includes one or more condition records 602 (Figure 6) and one or more action records 604. During a particular iteration of the loop of steps 406-412 (Figure 4), the rule processed according steps 408- 410 is referred to herein as the subject rule.
In test step 408, recipient profile processor 308 (Figure 3) determines whether the conditions represented by the condition records of the subject rule are collectively met by the subject package. As described in greater detail below, each condition, e.g., condition record 602 (Figure 6), specifies a boolean expression involving an attribute of a package or a package-independent attribute. Various attributes of a package are described in greater detail below. Briefly, such attributes can include the sender, one or more recipients, the subject, the message body, delivery attributes, post handling procedures, and one or more attached files. Package-independent attributes include, for example, date/time, time since or before an event, and recipient-specified state variables such as 'on vacation' and 'traveling on business.' Boolean expressions involving the sender and/or recipients of a package can specify all or part of e-mail addresses, for example using a regular expression. One possible use of e-mail addresses in a condition would be to distinguish recipients within an organization of which the sender is a member from recipients outside such an organization. Boolean expressions involving textual attributes such as subject and message body and textual content of attached data files can be used to search for inappropriate terms which can be offensive to the recipient or which indicate that the package is an unwanted solicitation or can indicate an urgent matter requiring immediate attention. Boolean expressions involving delivery attributes and post delivery handling procedures can be used to direct the package to an appropriate destination device. For example, packages for which hardcopy printing is permitted can be selectively routed to a printer. Boolean expressions involving attached data files can be used to detect the spread of malicious programs and to discriminate between professional and personal correspondence.
The conditions of a rule, e.g., all condition records 602 of rule record 502, are related to one another through boolean operators. Figure 9 shows a tree structure 900 in which a number of conditions, e.g., conditions 602 and 602B-E, are related to one another by boolean operators 902-908. In this illustrative example, (i) boolean operator 902 specifies a logical "OR" relation between conditions 602 and 602B-C, (ii) boolean operator 904 specifies a logical "AND" relation between conditions 602D-E, (iii) boolean operator 906 specifies a logical negation of the intermediate result of boolean operator 904, and (iv) boolean operator 908 specifies a logical "AND" relation between the intermediate result of boolean operator 902 and the intermediate result of boolean operator 906.
If recipient profile processor 308 (Figure 3) determines that the conditions of the subject rule, collectively in accordance with logical relations to one another, are not satisfied by the subject package, processing transfers from test step 408 (Figure 4) to next step 412, skipping step 410, and the next rule is processed according to the loop of steps 406-412. Conversely, if recipient profile processor 308 (Figure 3) determines that the conditions of the subject rule, collectively in accordance with logical relations to one another, are satisfied by the subject package, processing transfers from test step 408 (Figure 4) to step 410.
In step 410, recipient profile processor 308 (Figure 3) adds all actions for the subject rule to a list of actions for the subject package. This list is initialized to be empty upon initiation of processing according to logic flow diagram 400 (Figure 4) and at least prior to processing according to the loop of steps 406-412. While performance of actions of the list is postponed in this illustrative embodiment until conditions of all rules of a profile have been tested, such actions are performed immediately in an alternative embodiment. After step 410, processing transfers to next step 412 and the next rule is processed according to the loop of steps 406-412. Once all rules of all profiles of the recipient have been processed according to the loop of steps 406-412 (Figure 4), processing transfers to step 414.
In step 414, recipient profile processor 308 (Figure 3) orders the actions of the list of actions according to priority. Some actions work better if performed before other actions. For example, if an action modifies the body of a message of a package and another action forwards a copy of the package to a predetermined recipient, it is preferred that the copy include the modified body. In other words, it is preferred that the modification action precedes the forwarding action.
Figure 10 shows action 604 in greater detail. Action 604 includes an action body 1002 which specifies the specific action to be taken when performing action 604, and a priority 1004. Priority 1004 is established by the recipient and, in step 414 (Figure 4), recipient profile processor 308 (Figure 3) sorts actions of the list such that higher priority actions are performed before actions of lower priority.
Figure 11 shows an action 604B in accordance with an alternative embodiment. Action 604B includes action data 1102 and a reference 1104 to an action definition 1106. Action data 1102 specifies data relevant to the action represented by action 604B. For example, if action 604B specifies that a copy of the package is to be forwarded, action data 1102 can specify an e-mail address to which the copy is forwarded. Action definition 1106 specifies the details of the action to be taken and includes a priority 1108. Priority 1108 is established by the recipient and, in step 414 (Figure 4), recipient profile processor 308 (Figure 3) sorts actions of the list such that higher priority actions are performed before actions of lower priority.
After step 414 (Figure 4), processing transfers to step 416. The list of actions to be performed with respect to the subject package can contain duplicate, redundant actions. For example, a single package can satisfy more than one set of conditions thereby potentially adding identical actions to the list of actions. Accordingly, recipient profile processor 308 (Figure 3), in step 416 (Figure 4), removes duplicate actions from the list of actions to perform with respect to the subject package. Thus, each action is performed only once for the subject package.
It is appreciated that the relative order of steps 414-416 is not important. For example, step 416 can be performed before step 414. In addition, actions associated with satisfied conditions are performed in step 410 above in an alternative embodiment as described above. In this alternative embodiment, steps 414-422 are obviated.
Loop step 418 and next step 422 define a loop in which recipient profile processor 308 (Figure 3) performs each of the actions of the list of actions in step 420 (Figure 4) for the subject package. Actions performed by recipient profile processor 308 (Figure 3) in step 420 (Figure 4) and specified by action record 604 (Figure 6) generally affect the delivery of the subject package. While there are many types of actions which can affect delivery of the subject package, three (3) major categories are particularly useful in conjunction with the illustrative embodiment described herein. In particular, actions can (i) direct delivery of the package, (ii) distribute information regarding the package, and/or (iii) modify the package.
Actions Specified by the Recipient
Actions in the first category include discarding the package, selecting a folder into which to place the package, and automatically replying to the sender of the package. A package can be discarded by directing that the package be placed in a folder designated as "trash." Folders are collections of received packages — and perhaps copies of sent packages — organized in a manner specified by the recipient. Recipient profile processor 308 (Figure 3) can discard a package by deleting the package record representing the discarded package, e.g., package 206. Alternatively, recipient profile processor 308 can discard a package by placing the package in a folder designated "trash." Recipient profile processor 308 places a package in a folder by storing a reference to the package, e.g., package 206, in a folder record representing the folder or, alternatively, by storing data in package 206 identifying the folder. Recipient profile processor 308 automatically replies to the sender by sending a package to the sender with a message body previously specified by the recipient.
While a package can be used to automatically reply to the sender, more immediate feedback can be presented to the sender if recipient profile processor 308 interacts with package manager 302. For example, if recipient profile processor 308 is performing recipient-specified processing through interaction with package manager 302, it is likely that the sender is still engaged in an interactive session with package manager 302 and is waiting for some feedback regarding processing of the package. In this situation, recipient profile processor 308 can automatically reply to the sender by causing package manager 302 to including the automatic reply in feedback to the sender, perhaps by presenting an HTML page which includes the substance of the automatic reply. Since such occurs during an interactive session with the sender, the sender has the opportunity to immediately take corrective action such as sending a similar package to another recipient.
Actions by recipient profile processor 308 which distribute information regarding a package include redirecting the package to a different recipient, sending a copy of the package to a different recipient, and notifying a different recipient of the existence of the package. Recipient profile processor 308 redirects a package by substituting a new recipient for the original recipient. The package is then delivered to the new recipient and the original recipient of the package never receives the package. Such is useful if the original recipient has shed a responsibility assumed by another. Packages pertaining to such a responsibility, e.g., handling vacation requests withing a department of a company, can be redirected to the person currently handling that responsibility without cluttering the in-box of the original recipient. Recipient profile processor 308 can send a copy of a package to a predetermined entity, e.g., at a predetermined e-mail address. The e-mail address can correspond to a third party interested in the type of package received or can be an alternate e-mail address for the recipient, e.g., an alphanumeric pager. Notification of a package is similar to sending a copy of the message except that the notification can include less than the entirety of the package, e.g., the subject only or the subject and message with no attached data files, or can contain no text of the package itself. For example, the notification can be a previously specified textual message indicating that a package has been received. The notification message can include some information regarding the received package such as the sender of the package and the priority of the package. As with sending a copy of a package, the notification message can be sent to an e-mail address of an interested third party and/or an alternative e-mail address of the original recipient, e.g., to an alphanumeric pager, wireless telephone with text messaging capability such as Short Message Service (SMS) or Wireless Application Protocol (WAP), printer, fax machine, etc.
Recipient profile processor 308 can perform actions which modify the package. Actions which modify the package modify one or more of the fields of the package. For example, an action can prepend or append text to the message body of the package, can remove all attached data files or those attached data files which satisfy the conditions of the rule, and can modify parameters of the package such as the package's priority. In addition, actions can modify the package by removing malicious computer instructions from one or more attached data files, can compress or decompress one or more attached data files, and can initiate execution one or more computer processes while supplying one or more attached data files to the one or more computer processes as input data. The latter action allows new actions to be developed subsequently and used to process attached data files without requiring creation of new actions recognized by and applied by recipient profile processor 308 (Figure 3).
After all actions of the list of actions have been performed by recipient profile processor 308 (Figure 3) in the loop of steps 418-422 (Figure 4), processing transfers to test step 424. In test step 424, recipient profile processor 308 (Figure 3) determines whether the subject package is ready to be delivered. In this illustrative embodiment, all packages which are not discarded or redirected are ready to be delivered. If the subject package is discarded or redirected, processing transfers to terminal step 428 (Figure 4) in which processing accordmg to logic flow diagram 400 terminates and the subject package is not delivered. Conversely, if the subject package is ready to be delivered, processing transfers to terminal step 426 in which processing according to logic flow diagram 400 terminates and delivery of the subject package in the manner described above continues.
Conditions Based on Package Structure
As described above, packages are addressed from a sender to one or more recipients and can include a message and one or more attached data files. In addition, profile conditions include boolean expressions involving attributes of a package, and application of a rule can modify a package. A package, e.g., package 206 (Figure 2), is shown in greater detail in Figure 7.
Package 206 includes a sender field 702. A condition such as condition 602 (Figure 6) can include boolean expressions involving sender field 702 (Figure 7). For example, condition 602 can include a regular expression which can match one or more e- mail addresses. Regular expressions are well-known and are not described herein. Regular expressions are considered a type of boolean expression in which a matching condition is equivalent to a "true" boolean value and a non-matching condition is equivalent to a "false" boolean value.
Condition 602 can also include a boolean expression involving an attribute of a user record, e.g., user record 204, corresponding to the sender specified in sender field 702. To detect such a condition, package and account datastore 120 includes data mapping various e-mail addresses to corresponding user records such as user record 204 in one embodiment. In addition, recipient profile processor 308 (Figure 3) can access data representing one or more characteristics of the sender from an external directory 122 (Figure 1) which is accessible through computer network 110. Directory 122 is an external directory accessible according to a database access protocol such as the X.500 Standard or a similar directory service such as Lightweight Directory Access Protocol (LDAP), NetWare Directory Service (NDS), and Active Directory. In addition, information regarding the sender can be obtained from external databases which are not traditionally considered user directories.
Directories are databases which are intended to be read more often than written such that data stored therein is relatively stable and unchanging. Similar data can be stored in a regular database as well. Recipient profile processor 308 (Figure 3) is configured to retrieve data representing one or more characteristics of the sender from a database in which data in sender field 702 (Figure 7) is directly or indirectly associated with data representing the sender. Such databases can include, for example, human resources databases, customer care and support databases, and enterprise resource planning (ERP) databases such as that provided by SAP AG (see, e.g., http://www.sap.com on the World Wide Web). Such databases include information about users and provide some mechanism for accessing such information — typically an Applications Programming Interface (API).
User record 204 (Figure 2) or external user databases can include classification data which is useful in determining membership of the sender in any of a number of groups. For example, a condition can include a boolean expression which determines whether the sender is in the legal department or sales department of the same company as the recipient or works in a specific office of the company, e.g., a Japanese branch office. By testing for particular senders and/or classes of senders, the recipient profile processor 308 can apply different rules to various senders.
User record 204 is shown in greater detail in Figure 12. Each of the fields of user record 204 can be used in a condition such as condition 602 (Figure 6) to identify packages from a particular sender or a particular class of senders. User record 204 (Figure 12) includes a name field 1202, an e-mail address 1204, a group field 1206, a title field 1208, an organization field 1210, an account field 1212, a database identifier 1214, a schedule pointer 1216, user-defined state variables 1218, and public key 1220. Name field 1202 specifies the name of the user represented by user record 204, referred to as the subject user in the context of Figure 12. E-mail address 1204 specifies the e-mail address of the subject user. Group 1206 specifies one or more groups or departments to which the subject user belongs. Title field 1208 specifies the title or position held by the subject user. Organization field 1210 specifies an organization or company of which the subject user is a member or employee, respectively. It should be appreciated that user record 204 is merely illustrative and can include additional or different fields. It should also be appreciated that the fields of user record 204 can be user-customizable in some embodiments.
Account field 1212 references an account 1222 by which the subject user is granted access to package delivery system 100 (Figure 1). By conditioning processing of a package upon aspects of the account of the sender, the recipient can be mindful of sending large automated reply messages to a sender for whom package storage is a significant cost issue. Database identifier 1214 identifies the subject user within directory 122, thereby enabling the recipient to specify processing contingent on one or more attributes of the sender as stored in directory 122.
Schedule pointer 1216 and user-defined state variables 1218 are described more completely below. Briefly, schedule pointer 1216 references a schedule data file 1226 which represents an appointment calendar or similar schedule for the subject user, and user-defined state variables 1218 store data representing aspects of the state of the subject user, e.g., on vacation, traveling on business, extended leave of absence, etc. Alternatively, the subject user's schedule can be represented by a scheduling system which is accessible through an API. In such an alternative embodiment, schedule pointer 1216 identifies the scheduling system and can include zero or more access parameters of the scheduling system rather than a data file.
Package 206 (Figure 7) includes recipients field 704. Recipients are specified in a number of sub-fields, namely, TO sub-field 706, CC sub-field 708, and BCC sub-field 710 which specify, respectively, direct recipients, carbon-copied recipients, and blind carbon- copied recipients. However, in this illustrative embodiment, recipients specified in BCC sub-field 710 are not determinable by other recipients of package 206 and therefore cannot be the subject of any conditions specified by a recipient. Recipients — specified in either recipients field 704 itself or any sub-field thereof except BCC sub-field 710 — can be included in conditions such as condition 602 (Figure 6) in a manner analogous to that described above with respect to sender field 702 (Figure 7). For example, recipients can be specified as matching a regular expression or by matching an attribute of a user record, e.g., user record 204 (Figure 2), corresponding to the recipient field or sub-field. In addition, actions, e.g., as represented by action record 604 (Figure 6), which send copies of a package do so in this illustrative embodiment by duplicating package 206 (Figure 7) and changing contents of TO sub-field 706 to specify the recipient to whom the copy is sent. In addition, the body of the message as represented in body field 714 described below can be modified to identify the copy as such. Testing for recipients is useful since the recipient can make certain actions conditional upon other recipients to whom the package is sent or upon whether the subject recipient is identified in TO field 706 or CC field 708. Conditions can apply to recipients in the manner described above with respect to senders including, for example, use of regular expressions and X.500 or similar directories.
Subject field 712 (Figure 7) of package 206 specifies a textual subject of the package for convenience in categorizing and handling of the package. Body field 714 of package 206 stores the substantive content of the message of the package represented by package 206. Conditions, e.g., condition record 602 (Figure 6), can match a subject or body using a boolean expression and/or a regular expression. Rules such as rule record 502 can use such conditions to detect terms or phrases in subject field 712 (Figure 7) and/or body field 714. which indicate priority (e.g., "urgent," "important," or "ASAP"), which indicate an unwanted commercial solicitation, or which are offensive to the recipient.
Body attributes field 716 of package 206 specifies characteristics of the body represented in body field 714. Such attributes can include, for example, the particular format of the body, e.g., text, rich text format (RTF), or HTML, and the particular character set of which the body is composed. A condition involving body attributes can be used, for example, to detect packages with HTML bodies, and an associated action can convert the HTML body to a text or RTF body, thereby eliminating active components of HTML content such as javascript elements.
Delivery attributes 718 (Figure 7) specify the manner in which package 206 is delivered. For example, delivery attributes 718 can specify a relative priority of the package, whether a receipt notification is to be sent to the sender, a time at which to deliver the package, a time at which the package expires, and a code for billing purposes. In addition, delivery attributes 718 can include security attributes specifying, for example, whether a secure connection though computer network 110 (Figure 1) is required, whether package 206 (Figure 7) and attached data file records 750 are to be encrypted while stored in datastore 120 (Figure 1), whether a sender-specified password is required to retrieve the package, and whether an account password is required to retrieve the package. An account password is the password by which a particular user is authenticated as a prerequisite for access to system 100. For example, the account password of the sender is specified in user record 204 (Figure 2).
Conditions such as condition record 602 (Figure 6) can specify specific delivery attributes. For example, packages with relatively high priority can cause the recipient to be notified, e.g., by an e-mail address directed to an alphanumeric pager or wireless telephone with text messaging capability such as SMS or WAP.
Actions of rules, e.g., action record 604, can modify the delivery attributes of a package. For example, a recipient can increase the relative priority of packages whose expiration approaches. Such a rule would be the equivalent of "if this package expires in less than two days, increase the priority of this package."
Post delivery handling procedures 720 specify the types of actions recipients of package 206 can take with respect to package 206 once received. Post delivery handling procedures are described, for example, in U.S. Patent Application S/N 09/475,608 filed December 30, 1999 by Jean-Christophe Bandini and Dmitri Dolinsky for "Sender- Controlled Post Delivery Handling of Digitally Delivered Documents" and that description is incorporated herein by reference. Briefly, the sender can allow recipients to handle — e.g., reply to, forward, print, and save — a received package. As an example, rules can be established with conditions which include boolean expressions involving post-delivery handling procedures 718 to use apre-paid reply for automated reply messages if pre-paid replies are permitted by the sender or to automatically print or save the package if printing or saving is respectively permitted. In an alternative embodiment, server 108 (Figure 1) makes post delivery handling procedures 720 inaccessible to the recipient. As a result, recipient-specified conditions involving post delivery handling procedures 720 are not permitted in this alternative embodiment.
Custom attributes 722 can be used to specify characteristics of package 206 other than those specified in the other fields of package 206. In this illustrative embodiment, custom attributes 722 include a list of associated name/value pairs. In each pair, a name identifies the particular attribute and the value specifies the particular value of that attribute for package 206. Custom attributes 722 make package 206 extensible since attributes which are not conceived at the time system 100 is implemented can be added and represented in custom attributes 722.
Package 206 can also include keywords 724 which indicate significant portions of the content of package 206. Similar to subject field 712, keywords 724 provide a summation of the content of package 206 and can be used by the recipient to determine the nature of package 206 for appropriate processing.
Package 206 can include one or more attached data files. In particular, package 206 includes attached data file records 726 each of which references a respective data file which is considered attached to package 206. Attached data file 750 is such an attached data file. Alternatively, attached data files such as attached data file 750 are included within package 206 in an encoded form.
Attached data file 750 includes a name 752, a MIME (Multipurpose Internet Mail Extension) type 754, a size 756, custom attributes 758, and substantive content 760. Name 752 specifies a name of attached data file 750. MIME type 754 specifies a type of data file. For example, MIME type 754 can specify that attached data file 750 is a Microsoft Word document or a text document or a JPEG image. Size 756 specifies the size of attached data file 750. Custom attributes 758 represent subsequently defined attributes in a manner analogous to that described above with respect to custom attributes 722. For example, custom attributes 758 can include a number of attribute names and associated respective attribute values.
Conditions involving data file names as specified by name 752 can be used to detect specific files to detect packages which include data files of specific types. Conditions involving data file types as specified by MIME type 754 can be used to detect packages to which data files of specific types are attached. If a name of an attached data file does not accurately indicate the type of data file, MIME type 754 is likely to accurately indicate the type. While it is appreciated that the sender can change the name of a data file or convert the data file from one type to another to circumnavigate such rules, automatic execution of certain data files containing malicious computer instructions depends upon recognition of certain data file types by the operating system of the recipient. Accordingly, detection of data file types which can carry such malicious computer instructions is effective since attempts to defeat such detection will likely also defeat any automatic execution of the malicious computer instructions.
Conditions involving size 756 can be used to limit the size of attached data files of a package or the total size of a package. The recipient can limit the size of attached data files and/or the size of the entire package or can specify actions to be performed upon such a package having a certain total size or having attached data files of a certain size.
Conditions involving content 760 can examine the substantive content of attached data file 750. Such conditions typically require more processing resources than are required for conditions involving other attributes of attached data files and of package 206. Accordingly, conditions involving content 760 are typically enforced by recipient profile processor 308 (Figure 3) through delivery manager 306 rather than through package manager 302. As a result, the sender receives relatively quick acknowledgment of submission of package 206 (Figure 7) and can go on to perform other tasks while recipient profile processor 308 (Figure 3) and delivery manager 306 asynchronously examine content 760 (Figure 7) of attached data file 750 of package 206. Such conditions can determine whether words and/or phrases which are present in the substantive content of the attached data file indicate that the attached data file is an unwanted commercial solicitation or is offensive to the recipient or otherwise is of particular interest to the recipient. In addition, such conditions can scan the substantive content for malicious computer instructions such as Trojan horses or viruses.
Through either determining the type of attached data files or by examining the substantive content of attached data files, recipient profile processor 308 (Figure 3) can determine whether an attached data file is executable, i.e., capable of execution within a computer. Recipient profile processor 308 can similarly determine, by reference to the type or content of attached data files, whether an attached data file is capable of including macros — a collection of computer instructions embedded in otherwise non-executable data files. Conditions based on whether an attached data file is executable or is capable of including macros provide a useful means to determine the degree to which security is compromised by accepting a package including such an attached data file. Such attached data files can be scanned for malicious computer instructions such as viruses or Trojan horses and, if detected, can have those malicious computer instructions removed or such attached data files can be removed entirely from the package. If the recipient determines that security is so compromised that virus scanning is not to be relied upon, the entire attached data file can be removed or the entire package can be discarded. The sender can be sent an automatic reply message indicating that the malicious computer instructions were found, perhaps identifying the data file in which the malicious computer instructions were found. Similarly, the sender can be sent an automatic reply message indicating that executable data files or data files containing macros are not accepted by the recipient.
It should be noted that some data files include one or more embedded data files. For example, attached data file 750 can be an archive of one or more data files compressed in accordance with the known and ubiquitous ZIP compression format. Recipient profile processor 308 therefore extracts embedded data files from any attached data files 750 and performs recipient-specified processing to each of the extracted files and extracts any embedded data files from the extracted data files in a recursive fashion. As a result, recipient-specified processing cannot be avoided by merely compressing an attached data file which would otherwise be singled out for processing in accordance with the profile established by the recipient. Package-Independent Environmental Conditions
In addition to those conditions described above, rule 502 (Figure 6) can include conditions 602 which are independent of the contents or parameters of a particular package. One such condition is the time at which the package is to be delivered. Recipient profile processor 308 (Figure 3) has access to a clock or time server within server 108 and can determine current date and time in a conventional manner. Accordingly, conditions can detect attempted delivery of a package at certain predetermined times such as non-business hours and weekends and holidays. For example, the recipient can have packages forwarded to a home e-mail address of the recipient if delivery of the package is attempted during non-business hours or days. By combining such a condition with a condition detecting high priority packages, the recipient can specify that only high priority packages are forwarded to the recipient's home e-mail address during such non-business hours and days, for example.
The recipient can also specify conditions related to time before or since an event. Such an event can be, for example, submission of a package, attempted delivery notification of the recipient, access of the package or one or more attached data files by the recipient, and expiration of the package. Example usages of such conditions include, for example, (i) incrementing priority of the package and forwarding a copy of the package to a third party recipient if an amount of time has elapsed since delivery of the package is attempted without access to the package from the recipient (e.g., "forward this message to Joanne if I do not access this package within five days of its attempted delivery"); (ii) discarding a package a predetermined amount of time after the package and all attached data files are accessed successfully by the subject recipient; and (iii) incrementing priority of a package and notifying the recipient by alternative means (e.g., an alphanumeric pager or wireless telephone with text messaging capability) if a package will expire within a predetermined amount of time and the package has not yet been accessed by the recipient (e.g., "if the package will expire in less than two days and I have not yet accessed the package, notify me on my alphanumeric pager, at my work e-mail address, and at my home e-mail address").
To test such a condition, recipient profile processor 308 determines a time at which evaluation of the condition should be performed and schedules such evaluation at that time. For example, if a condition is based upon five days after attempted delivery of the package, recipient profile processor 308 determines the time of the attempted delivery of the package, adds five days to that time to determine a condition time, and schedules a task which evaluates the condition to execute at the condition time. At the condition time, the scheduled task of the package processing module executes and evaluates the condition — by determining whether the package has been accessed by the recipient for example.
As such time-based conditions are resolved at respective condition times, those conditions are replaced within a boolean expression such as boolean expression 900 (Figure 9) with the respective boolean values to which those conditions resolve. When no time-based conditions of a boolean expression remain unresolved, recipient profile processor 308 (Figure 3) can determine the overall boolean value of the boolean expression to thereby determine whether to perform the associated actions of the rule, e.g., rule 502 (Figure 6).
Recipient profile processor 308 (Figure 3) can also process a package conditionally upon the schedule of the recipient as represented in schedule data file 1226 (Figure 12). In this first illustrative embodiment, server 108 implements a web-based calendar system similar to the web-based calendar system implemented by Netscape Communications Corporation and accessible through the World Wide Web at http://calendar.netscape.com . Recipient profile processor 308 (Figure 3) can query schedule data file 1226 to determine if the recipient is scheduled to be in a meeting and, if so, with whom. The recipient can specify, for example, that notification messages are sent to an alphanumeric pager of the recipient (i) if the recipient is in a meeting, (ii) only if the recipient is not in a meeting, or (iii) if the recipient is in a meeting and the package in question has a high priority or is from a specific sender. In addition, schedule data file 1226 can indicate holidays and processing can be conditioned upon whether a particular day is a holiday. As described above with respect to an alternative embodiment, the recipient's schedule can be specified in a scheduling system in which the recipient's schedule can be determined through an API.
As described briefly above, user-defined state variables 1218 (Figure 12) specify user-defined aspects of a user's state. Recipient profile processor 308 (Figure 3) can use user-defined state variables 1218 (Figure 12) to condition processing of received packages in accordance with the recipient's state. For example, the recipient can specify that aspects of the recipient's state can include "on vacation" and "traveling on business." The recipient can thereafter toggle such aspects of the recipient's state on and off. For example, the recipient can set an "on vacation" flag as the recipient begins a vacation. Accordingly, any processing of incoming packages is performed in the context of the recipient's updated state, namely, in the context of the fact that the recipient is on vacation. When the recipient returns to work, the recipient can reset the "on vacation" flag to false to indicate that the recipient is no longer on vacation.
Recipient Profile Processor 308
Recipient profile processor 308 is shown in greater detail in Figure 8. Recipient profile processor 308 includes a profile editor 802, a profile store manager 804, and a profile processor 806, each of which is all or part of one or more computer processes executing within server 108 (Figure 1).
Profile store manager 804 stores profile records, e.g., profile record 208 (Figure 2), in datastore 120 and associates the profile records with user records, e.g., user record 204, to which the profile records pertain. In this illustrative embodiment, each user record includes a reference to a list of all profile records which pertain to the user, and each profile record includes a reference to the one or more user records representing the users to which the profile record pertains.
The profile records stored by profile store manager 804 (Figure 8) can be in any format convenient for profile processor 806. For example, profile records can represent profiles in any of the textual formats described below or in a binary representation in which similar information is stored. Profile records can be stored as one or more flat data files, as a relational database, or as an object oriented database. Flat data files, relational databases, and object oriented databases are known and are described further herein.
Profile processor 806 (Figure 8) includes logic which implements profiles of a recipient in the manner described above with respect to logic flow diagram 400 (Figure 4).
Profile editor 802 (Figure 8) interacts with the recipient through computer system 104 (Figure 1) and computer network 110 to define one or more profiles, e.g., profile record 208 (Figure 2), which are applicable to packages sent to the recipient. Profile editor 802 (Figure 8) can interact with the recipient in any of a number of ways. For example, the recipient can submit a textual data file specifying a profile and profile editor 802 can parse the textual data file, form a profile record such as profile record 208 (Figure 2) and submit the profile record to profile store manager 804 (Figure 8) for storage in datastore 120. Possible textual formats for profiles are described more completely below.
Alternatively, profile editor 802 can provide an interactive interface by which the recipient can add, delete, and modify rules of a profile. Similarly, the interface provides mechanisms by which the recipient can add, delete, and modify conditions and actions of a specific rale when adding or modifying a rule of the profile. In specifying — by addition or modification — a condition, the recipient is prompted for (i) a parameter of a package or other package-independent parameter, (ii) a relation, and (iii) a data value. Parameters include, for example, those described above with respect to package 206 in Figure 7 and those package-independent parameters described above, and the recipient can be presented with a list of such parameters from which to select a parameter. Relations can include such relations as "contains," "is equal to," "is greater than," "is less than," and negations of each such relation, and the recipient can select such a relation from a list of available relations. The recipient specifies a data value by entering the value. Profile editor 802 (Figure 8) in this illustrative embodiment verifies that the entered data value conforms to any validity constraints imposed upon the selected package parameter. For example, if the selected package parameter of the condition is a date, profile editor 802 ensures that the condition data value entered by the recipient is a valid date in the same manner that the package parameter is verified to be a valid date.
In one embodiment, the interactive interface of profile editor 802 is implemented as a set of one or more HTML forms. HTML forms are known and are not described further herein. In an alternative embodiment, the interactive interface is implemented by all or part of one or more computer processes executing within computer system 104 (Figure 1) which converts the profiles specified by the recipient to one or more data files representing the profiles in a format which is recognized by profile editor 802 (Figure 8). For example, the format can be any of the textual formats described below.
If profile editor 802 recognizes profiles in a standard format, such as textual; conventional editors executing within computer system 104 (Figure 1) can be used by the profile authority to specify a profile which is submitted through computer network 110 to server 108 and profile editor 802 (Figure 8). For example, the NOTEPAD and WORDPAD programs available from Microsoft Corporation of Redmond, Washington in conjunction with their WINDOWS® family of operating systems can be used to edit profiles in the textual formats described below.
Two illustrative formats for profile specification are described herein: a rule list and a scripting language. Each can be represented textually, e.g., in the known ASCII and XML formats, or as binary data.
The rule list format is a simple list of rules, each of which is a pairing or association of a list of one or more conditions with a list of one or more actions. The following grammar illustrates the rule list format: Profile = list of Rule Rule = Conditions Actions Conditions = a boolean expression using zero or more instances of Condition Actions = list of Action
Condition = Delivery Attribute or ExternalAttribute Delivery Attribute = PackageAttribute OR SenderAttribute
OR RecipientAttribute OR EventAttribute ExternalAttribute = CurrentTime OR CurrentDate OR RandomNumber OR
CustomAttribute(AttributeName) OR etc. PackageAttribute = Subject OR Body OR TimeOfDelivery OR DeliverySecurityAttribute OR CustomAttribute(AttributeName) OR list of FileAttribute FileAttribute = FileName OR MIMEType OR FileSize OR FileTextualContent OR CustomAttribute(AttributeName) OR list of FileAttribute SenderAttribute = SenderEmailAddress OR
SenderAttributeFromDirectoryLookup(AttributeNam e) OR CustomAttribute(AttributeName) RecipientAttribute = RecipientEmailAddress OR
RecipientAttributeFromDirectoryLookup(AttributeN ame) OR CustomAttribute(AttributeName) OR ScheduleLookup(date, time) OR RecipientStateVariable(VariableName) EventAttribute = TimeBefore(Event) OR TimeSince(Event) Event = SubmissionOfPackage OR ExpirationOfPackage OR
DeliveryNotification OR PackageRetrieval OR etc. Action = Discard OR AutoReply(ReplyPackage) OR
Redirect(recipient) OR SendCopyTo(recipient) OR Notify(recipient) OR MoveTo(folder) OR RemoveAllAttachments OR RemoveAttachmentsMatchingCondition OR AppendToBody OR PrependToBody OR ModifyDeliveryOption(Option, NewValue) OR ConvertAttachmentFormat(NewFormat) OR CompressAttachment OR RunProgramForAttachment(ProgramName) OR CleanVirasFromAttachment OR etc. FileAttribute has a recursive definition since some file formats include a list of embedded files. For example, compressed data formats such as the popular and known ZIP compressed data format embeds a number of files within a compressed file. In addition, each embedded file can also have embedded files, e.g., can be a compressed data file in the ZIP format.
The scripting language format represents processing performed on behalf of the recipient in the form of a scripting language. In one embodiment, a number of predefined objects express conditions in the known ECMA-262 scripting language of the European Computer Manufacturers Association (ECMA). ECMA-22 (sometimes referred to as ECMAscript or JavaScript) is known and is not described further herein. In this embodiment, actions are represented by predefined methods in the ECMA-262 scripting language.
The following objects are illustrative examples of objects which can represent parameters: sender.directoryLookup(directory, attributeName), recpient.directoryLookup(directory, attributeName), package.subject, package.body, package.sendDate, package.deliveryTime, package.priority, package.securityOption, package.file[index], package.file[index]. length, package.file[index].name, package.file[index] .mimeType, package, file [index] .hasVirus(), package.file[index] .isExecutable(), package.file[index] .hasMacrosQ, package.file.scanText("regular expression"), current.time, current.date, timeSince(event), timeBefore(event), recipient.schedule(time, date), and customAttribute(nanie).
The following methods are illustrative examples of methods which can represent actions: package.discardQ, package. AutoReplyfl am on vacation but will be back in the office on Tuesday."), package.redirect("e-mail address"), package.sendCopyTo("e-mail address"), package.move("Folder"), package.body.append("This message is privileged as Attorney/Client communication."), package.files.removeAt(index), and package.submitForProcessingC'Program"). In addition, actions can be represented as object properties which can be written in the scripting language. For example, "(URGENT)" can be appended to the subject by the script instruction:
package.subject += "(URGENT)"
Similarly, a package can be directed to a particular folder by the script instruction:
package.folder = "Personal Correspondence"
The rules list format and script format can be combined. For example, conditions can be expressed in the rules list format while actions are expressed as scripts. Alternatively, conditions can be expressed as scripts while actions are expressed in the rules list format described above. Furthermore, these illustrative formats are exactly that: illustrative. Other formats are possible for specifying conditions and associated actions to be taken if the conditions are satisfied.
The above description is illustrative only and is not limiting. For example, it should be appreciated that processing of a package can be automatically processed on behalf of the sender and/or a policy authority of the sender in a manner described in U.S. Patent Application S/N 09/540,023 filed March 31, 2000 by Jeffrey C. Smith and Jean- Christophe Bandini for "Policy Enforcement in a Secure Data File Delivery System" and that description is incorporated herein by reference. In this illustrative embodiment, any automated processing on behalf of the sender is performed first, followed by processing in a manner specified by a policy authority of the sender, and then followed by automated processing on behalf of the recipient. Specifically, the present invention is defined solely by the claims which follow and their full range of equivalents.

Claims

What is claimed is:
1. A method for processing a package to be delivered from a sender to a recipient and zero or more other recipients through a computer network, the method comprising: receiving package data which is generated by the sender and which specifies the package; processing the package in accordance with profile data which is provided by the recipient and which specifies one or more conditional actions to be performed; delivering the package to the recipient by sending notification to the recipient wherein the notification includes package identification data and including retrieval data which is sufficient to provide the recipient with access to the package.
2. The method of Claim 1 further comprising: determining in accordance with the profile data whether the recipient is to be notified with respect to the package; and wherein delivering the package includes sending the notification only upon a condition in which the recipient is to be notified.
3. The method of Claim 1 wherein delivering further comprises: receiving the package identification data from the recipient; and sending the package to the recipient in response to the package identification data.
4. The method of Claim 1 wherein applying a profile comprises: determining that the package satisfies one or more conditions; and if the package satisfies the one or more conditions, performing one or more actions which are associated with the one or more conditions.
5. The method of Claim 4 wherein the one or more actions discard the package.
6. The method of Claim 4 wherein the one or more actions redirect the package to another recipient.
7. The method of Claim 4 wherein the one or more actions send a predetermined reply message to the sender.
8. The method of Claim 4 wherein the one or more actions send a predetermined notification message to a predetermined notification recipient.
9. The method of Claim 8 wherein the notification recipient is an alternative address of the recipient.
10. The method of Claim 8 wherein the notification message includes a subject of the package.
11. The method of Claim 8 wherein the notification message includes at least a part of a message body of the package.
12. The method of Claim 4 wherein the one or more actions send a copy of the package to another recipient.
13. The method of Claim 4 wherein the one or more actions establish a folder into which the package is ultimately stored.
14. The method of Claim 4 wherein the one or more actions initiate execution of a computer program to process the package.
15. The method of Claim 4 wherein the one or more conditions include a boolean expression involving data related to the sender.
16. The method of Claim 4 wherein the one or more conditions include a boolean expression involving data related to one or more of the recipients.
17. The method of Claim 4 wherein the one or more conditions include a boolean expression involving data related to one or more attributes of the package.
18. The method of Claim 1 wherein the package data is generated by the sender through a web browser.
19. The method of Claim 18 wherein the package data is HTML form data.
20. The method of Claim 1 wherein the profile data is received from the recipient through a computer network.
21. The method of Claim 20 wherein the computer network is the Internet.
22. The method of Claim 1 wherein the notification is sent to the recipients as an SMTP e-mail message.
23. The method of Claim 1 wherein the notification is sent to the recipients according to a wireless access protocol.
24. The method of Claim 1 wherein the notification is sent to the recipients according to a short message service.
25. The method of Claim 1 wherein the package identification data is a URL.
26. The method of Claim 1 wherein sending the package to the selected recipient in response to the package identification data comprises: sending the package in accordance with HTTP.
27. The method of Claim 1 further comprising: retrieving data representing one or more characteristics of the sender from a database according to data identifying the sender; wherein the profile includes one or more conditions based upon the one or more characteristics.
28. The method of Claim 27 wherein the database is accessed according to a lightweight directory access protocol.
29. The method of Claim 27 wherein the database is accessed according to an X.500 directory access protocol.
30. The method of Claim 1 further comprising: retrieving data representing one or more characteristics of a selected one of the other recipients from a database according to data identifying the sender; wherein the profile includes one or more conditions based upon the one or more characteristics.
31. The method of Claim 30 wherein the database is accessed according to a lightweight directory access protocol.
32. The method of Claim 30 wherein the database is accessed according to an X.500 directory access protocol.
33. The method of Claim 1 further comprising: determining that one or more delivery security parameters are specified in the data package; wherein the profile includes one or more conditions based upon the one or more delivery security parameters.
34. The method of Claim 1 further comprising: determining that delivery of the data package is subject to a delivery schedule; wherein the profile includes one or more conditions based upon the delivery schedule.
35. The method of Claim 1 wherein the profile includes one or more conditions based upon one or more times relative to one or more events.
36. The method of Claim 35 wherein the one or more relative times include a time before an associated event.
37. The method of Claim 35 wherein the one or more relative times include a time since an associated event.
38. The method of Claim 35 wherein the one or more events include submission of the data package for delivery to the selected recipient.
39. The method of Claim 35 wherein the one or more events include attempted delivery of the data package to the selected recipient.
40. The method of Claim 35 wherein the one or more events include sending of notification of the data package to the selected recipient.
41. The method of Claim 35 wherein the one or more events include expiration of the data package.
42. The method of Claim 1 wherein the profile includes one or more conditions based upon one or more elements of a state defined by the selected recipient.
43. The method of Claim 42 further comprising: receiving state data from the selected recipient wherein the state data represents at least one of the elements of the state; and setting the state in accordance with the state data such that subsequently received messages addressed to the selected recipient are processed in accordance with the state so set.
44. The method of Claim 1 wherein the profile includes one or more conditions based upon a schedule of the selected recipient.
45. The method of Claim 44 wherein processing comprises: determining a time associated with the data package; and retrieving data representing the schedule of the selected recipient at the time from a calendar system.
46. A computer readable medium useful in association with a computer which includes a processor and a memory, the computer readable medium including computer instructions which are configured to cause the computer to process a package to be delivered from a sender to a recipient and zero or more other recipients through a computer network by: receiving package data which is generated by the sender and which specifies the package; processing the package in accordance with profile data which is provided by the recipient and which specifies one or more conditional actions to be performed; delivering the package to the recipient by sending notification to the recipient wherein the notification includes package identification data and including retrieval data which is sufficient to provide the recipient with access to the package.
47. The computer readable medium of Claim 46 wherein the computer instructions are configured to cause the computer to process the package by also: determining in accordance with the profile data whether the recipient is to be notified with respect to the package; and wherein delivering the package includes sending the notification only upon a condition in which the recipient is to be notified.
48. The computer readable medium of Claim 46 wherein delivering further comprises: receiving the package identification data from the recipient; and sending the package to the recipient in response to the package identification data.
49. The computer readable medium of Claim 46 wherein applying a profile comprises: determining that the package satisfies one or more conditions; and if the package satisfies the one or more conditions, performing one or more actions which are associated with the one or more conditions.
50. The computer readable medium of Claim 49 wherein the one or more actions discard the package.
51. The computer readable medium of Claim 49 wherein the one or more actions redirect the package to another recipient.
52. The computer readable medium of Claim 49 wherein the one or more actions send a predetermined reply message to the sender.
53. The computer readable medium of Claim 49 wherein the one or more actions send a predetermined notification message to a predetermined notification recipient.
54. The computer readable medium of Claim 53 wherein the notification recipient is an alternative address of the recipient.
55. The computer readable medium of Claim 53 wherein the notification message includes a subject of the package.
56. The computer readable medium of Claim 53 wherein the notification message includes at least a part of a message body of the package.
57. The computer readable medium of Claim 49 wherein the one or more actions send a copy of the package to another recipient.
58. The computer readable medium of Claim 49 wherein the one or more actions establish a folder into which the package is ultimately stored.
59. The computer readable medium of Claim 49 wherein the one or more actions initiate execution of a computer program to process the package.
60. The computer readable medium of Claim 49 wherein the one or more conditions include a boolean expression involving data related to the sender.
61. The computer readable medium of Claim 49 wherein the one or more conditions include a boolean expression involving data related to one or more of the recipients.
62. The computer readable medium of Claim 49 wherein the one or more conditions include a boolean expression involving data related to one or more attributes of the package.
63. The computer readable medium of Claim 46 wherein the package data is generated by the sender through a web browser.
64. The computer readable medium of Claim 63 wherein the package data is HTML form data.
65. The computer readable medium of Claim 46 wherein the profile data is received from the recipient through a computer network.
66. The computer readable medium of Claim 65 wherein the computer network is the Internet.
67. The computer readable medium of Claim 46 wherein the notification is sent to the recipients as an SMTP e-mail message.
68. The computer readable medium of Claim 46 wherein the notification is sent to the recipients according to a wireless access protocol.
69. The computer readable medium of Claim 46 wherein the notification is sent to the recipients according to a short message service.
70. The computer readable medium of Claim 46 wherein the package identification data is a URL.
71. The computer readable medium of Claim 46 wherein sending the package to the selected recipient in response to the package identification data comprises: sending the package in accordance with HTTP.
72. The computer readable medium of Claim 46 wherein the computer instructions are configured to cause the computer to process the package by also: retrieving data representing one or more characteristics of the sender from a database according to data identifying the sender; wherein the profile includes one or more conditions based upon the one or more characteristics.
73. The computer readable medium of Claim 72 wherein the database is accessed according to a lightweight directory access protocol.
74. The computer readable medium of Claim 72 wherein the database is accessed according to an X.500 directoiy access protocol.
75. The computer readable medium of Claim 46 wherein the computer instractions are configured to cause the computer to process the package by also: retrieving data representing one or more characteristics of a selected one of the other recipients from a database according to data identifying the sender; wherein the profile includes one or more conditions based upon the one or more characteristics.
76. The computer readable medium of Claim 75 wherein the database is accessed according to a lightweight directory access protocol.
77. The computer readable medium of Claim 75 wherein the database is accessed according to an X.500 directory access protocol.
78. The computer readable medium of Claim 46 wherein the computer instractions are configured to cause the computer to process the package by also: determining that one or more delivery security parameters are specified in the data package; wherein the profile includes one or more conditions based upon the one or more delivery security parameters.
79. The computer readable medium of Claim 46 wherein the computer instructions are configured to cause the computer to process the package by also: determining that delivery of the data package is subject to a delivery schedule; wherein the profile includes one or more conditions based upon the delivery schedule.
80. The computer readable medium of Claim 46 wherein the profile includes one or more conditions based upon one or more times relative to one or more events.
81. The computer readable medium of Claim 80 wherein the one or more relative times include a time before an associated event.
82. The computer readable medium of Claim 80 wherein the one or more relative times include a time since an associated event.
83. The computer readable medium of Claim 80 wherein the one or more events include submission of the data package for delivery to the selected recipient.
84. The computer readable medium of Claim 80 wherein the one or more events include attempted delivery of the data package to the selected recipient.
85. The computer readable medium of Claim 80 wherein the one or more events include sending of notification of the data package to the selected recipient.
86. The computer readable medium of Claim 80 wherein the one or more events include expiration of the data package.
87. The computer readable medium of Claim 46 wherein the profile includes one or more conditions based upon one or more elements of a state defined by the selected recipient.
88. The computer readable medium of Claim 87 wherein the computer instructions are configured to cause the computer to process the package by also: receiving state data from the selected recipient wherein the state data represents at least one of the elements of the state; and setting the state in accordance with the state data such that subsequently received messages addressed to the selected recipient are processed in accordance with the state so set.
89. The computer readable medium of Claim 46 wherein the profile includes one or more conditions based upon a schedule of the selected recipient.
90. The computer readable medium of Claim 89 wherein processing comprises: determining a time associated with the data package; and retrieving data representing the schedule of the selected recipient at the time from a calendar system.
91. A computer system comprising : a processor; a memory operatively coupled to the processor; and a package processing module (i) which executes in the processor from the memory and (ii) which, when executed by the processor, causes the computer to process a package to be delivered from a sender to a recipient and zero or more other recipients through a computer network by: receiving package data which is generated by the sender and which specifies the package; processing the package in accordance with profile data which is provided by the recipient and which specifies one or more conditional actions to be performed; delivering the package to the recipient by sending notification to the recipient wherein the notification includes package identification data and including retrieval data which is sufficient to provide the recipient with access to the package.
92. The computer system of Claim 91 wherein the package processing module causes the computer to process the package by also: determining in accordance with the profile data whether the recipient is to be notified with respect to the package; and wherein delivering the package includes sending the notification only upon a condition in which the recipient is to be notified.
93. The computer system of Claim 91 wherein delivering further comprises: receiving the package identification data from the recipient; and sending the package to the recipient in response to the package identification data.
94. The computer system of Claim 91 wherein applying a profile comprises: determining that the package satisfies one or more conditions; and if the package satisfies the one or more conditions, performing one or more actions which are associated with the one or more conditions.
95. The computer system of Claim 94 wherein the one or more actions discard the package.
96. The computer system of Claim 94 wherein the one or more actions redirect the package to another recipient.
97. The computer system of Claim 94 wherein the one or more actions send a predetermined reply message to the sender.
98. The computer system of Claim 94 wherein the one or more actions send a predetermined notification message to a predetermined notification recipient.
99. The computer system of Claim 98 wherein the notification recipient is an alternative address of the recipient.
100. The computer system of Claim 98 wherein the notification message includes a subject of the package.
101. The computer system of Claim 98 wherein the notification message includes at least a part of a message body of the package.
102. The computer system of Claim 94 wherein the one or more actions send a copy of the package to another recipient.
103. The computer system of Claim 94 wherein the one or more actions establish a folder into which the package is ultimately stored.
104. The computer system of Claim 94 wherein the one or more actions initiate execution of a computer program to process the package.
105. The computer system of Claim 94 wherein the one or more conditions include a boolean expression involving data related to the sender.
106. The computer system of Claim 94 wherein the one or more conditions include a boolean expression involving data related to one or more of the recipients.
107. The computer system of Claim 94 wherein the one or more conditions include a boolean expression involving data related to one or more attributes of the package.
108. The computer system of Claim 91 wherein the package data is generated by the sender through a web browser.
109. The computer system of Claim 108 wherein the package data is HTML form data.
110. The computer system of Claim 91 wherein the profile data is received from the recipient through a computer network.
111. The computer system of Claim 110 wherein the computer network is the Internet.
112. The computer system of Claim 91 wherein the notification is sent to the recipients as an SMTP e-mail message.
113. The computer system of Claim 91 wherein the notification is sent to the recipients according to a wireless access protocol.
114. The computer system of Claim 91 wherein the notification is sent to the recipients according to a short message service.
115. The computer system of Claim 91 wherein the package identification data is a URL.
116. The computer system of Claim 91 wherein sending the package to the selected recipient in response to the package identification data comprises: sending the package in accordance with HTTP.
117. The computer system of Claim 91 wherein the package processing module causes the computer to process the package by also: retrieving data representing one or more characteristics of the sender from a database according to data identifying the sender; wherein the profile includes one or more conditions based upon the one or more characteristics.
118. The computer system of Claim 117 wherein the database is accessed according to a lightweight directory access protocol.
119. The computer system of Claim 117 wherein the database is accessed according to an X.500 directory access protocol.
120. The computer system of Claim 91 wherein the package processing module causes the computer to process the package by also: retrieving data representing one or more characteristics of a selected one of the other recipients from a database according to data identifying the sender; wherein the profile includes one or more conditions based upon the one or more characteristics.
121. The computer system of Claim 120 wherein the database is accessed according to a lightweight directory access protocol.
122. The computer system of Claim 120 wherein the database is accessed accordmg to an X.500 directory access protocol.
123. The computer system of Claim 91 wherein the package processing module causes the computer to process the package by also: determining that one or more delivery security parameters are specified in the data package; wherein the profile includes one or more conditions based upon the one or more delivery security parameters.
124. The computer system of Claim 91 wherein the package processing module causes the computer to process the package by also: determining that delivery of the data package is subject to a delivery schedule; wherein the profile includes one or more conditions based upon the delivery schedule.
125. The computer system of Claim 91 wherein the profile includes one or more conditions based upon one or more times relative to one or more events.
126. The computer system of Claim 125 wherein the one or more relative times include a time before an associated event.
127. The computer system of Claim 125 wherein the one or more relative times include a time since an associated event.
128. The computer system of Claim 125 wherein the one or more events include submission of the data package for delivery to the selected recipient.
129. The computer system of Claim 125 wherein the one or more events include attempted delivery of the data package to the selected recipient.
130. The computer system of Claim 125 wherein the one or more events include sending of notification of the data package to the selected recipient.
131. The computer system of Claim 125 wherein the one or more events include expiration of the data package.
132. The computer system of Claim 91 wherein the profile includes one or more conditions based upon one or more elements of a state defined by the selected recipient.
133. The computer system of Claim 132 wherein the package processing module causes the computer to process the package by also: receiving state data from the selected recipient wherein the state data represents at least one of the elements of the state; and setting the state in accordance with the state data such that subsequently received messages addressed to the selected recipient are processed in accordance with the state so set.
134. The computer system of Claim 91 wherein the profile includes one or more conditions based upon a schedule of the selected recipient.
135. The computer system of Claim 134 wherein processing comprises: determining a time associated with the data package; and retrieving data representing the schedule of the selected recipient at the time from a calendar system.
PCT/US2001/024995 2000-08-08 2001-08-08 Recipient-specified automated processing in a secure data file delivery system WO2002013469A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001281218A AU2001281218A1 (en) 2000-08-08 2001-08-08 Recipient-specified automated processing in a secure data file delivery system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US63480700A 2000-08-08 2000-08-08
US09/634,807 2000-08-08

Publications (2)

Publication Number Publication Date
WO2002013469A2 true WO2002013469A2 (en) 2002-02-14
WO2002013469A3 WO2002013469A3 (en) 2002-09-06

Family

ID=24545247

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/024995 WO2002013469A2 (en) 2000-08-08 2001-08-08 Recipient-specified automated processing in a secure data file delivery system

Country Status (2)

Country Link
AU (1) AU2001281218A1 (en)
WO (1) WO2002013469A2 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1560112A1 (en) * 2004-01-30 2005-08-03 Microsoft Corporation Detection of files that do not contain executable code
US7359947B2 (en) 2003-07-31 2008-04-15 International Business Machines Corporation Autonomic e-mail processing system and method
US7694128B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for secure communication delivery
US7693947B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for graphically displaying messaging traffic
US7779466B2 (en) 2002-03-08 2010-08-17 Mcafee, Inc. Systems and methods for anomaly detection in patterns of monitored communications
US7870203B2 (en) 2002-03-08 2011-01-11 Mcafee, Inc. Methods and systems for exposing messaging reputation to an end user
US7900254B1 (en) 2003-01-24 2011-03-01 Mcafee, Inc. Identifying malware infected reply messages
US7903549B2 (en) 2002-03-08 2011-03-08 Secure Computing Corporation Content-based policy compliance systems and methods
US8042181B2 (en) 2002-03-08 2011-10-18 Mcafee, Inc. Systems and methods for message threat management
US8132250B2 (en) 2002-03-08 2012-03-06 Mcafee, Inc. Message profiling systems and methods
US8160975B2 (en) * 2008-01-25 2012-04-17 Mcafee, Inc. Granular support vector machine with random granularity
US8578480B2 (en) 2002-03-08 2013-11-05 Mcafee, Inc. Systems and methods for identifying potentially malicious messages
US10050917B2 (en) 2007-01-24 2018-08-14 Mcafee, Llc Multi-dimensional reputation scoring

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060015942A1 (en) 2002-03-08 2006-01-19 Ciphertrust, Inc. Systems and methods for classification of messaging entities
US8763114B2 (en) 2007-01-24 2014-06-24 Mcafee, Inc. Detecting image spam

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2328110A (en) * 1997-08-01 1999-02-10 Mitel Corp Dialable filtering profile for mixed media stored messages
WO1999006929A2 (en) * 1997-08-03 1999-02-11 At & T Corp. An extensible proxy framework for e-mail agents

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2328110A (en) * 1997-08-01 1999-02-10 Mitel Corp Dialable filtering profile for mixed media stored messages
WO1999006929A2 (en) * 1997-08-03 1999-02-11 At & T Corp. An extensible proxy framework for e-mail agents

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PALME J ET AL: "Issues when designing filters in messaging systems" COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, NL, vol. 19, no. 2, 1 February 1996 (1996-02-01), pages 95-101, XP004032392 ISSN: 0140-3664 *

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7903549B2 (en) 2002-03-08 2011-03-08 Secure Computing Corporation Content-based policy compliance systems and methods
US8578480B2 (en) 2002-03-08 2013-11-05 Mcafee, Inc. Systems and methods for identifying potentially malicious messages
US7694128B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for secure communication delivery
US7693947B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for graphically displaying messaging traffic
US8132250B2 (en) 2002-03-08 2012-03-06 Mcafee, Inc. Message profiling systems and methods
US8069481B2 (en) 2002-03-08 2011-11-29 Mcafee, Inc. Systems and methods for message threat management
US7779466B2 (en) 2002-03-08 2010-08-17 Mcafee, Inc. Systems and methods for anomaly detection in patterns of monitored communications
US7870203B2 (en) 2002-03-08 2011-01-11 Mcafee, Inc. Methods and systems for exposing messaging reputation to an end user
US8042181B2 (en) 2002-03-08 2011-10-18 Mcafee, Inc. Systems and methods for message threat management
US7900254B1 (en) 2003-01-24 2011-03-01 Mcafee, Inc. Identifying malware infected reply messages
US7711784B2 (en) 2003-07-31 2010-05-04 International Business Machines Corporation Autonomic e-mail processing system and method
US7359947B2 (en) 2003-07-31 2008-04-15 International Business Machines Corporation Autonomic e-mail processing system and method
EP1560112A1 (en) * 2004-01-30 2005-08-03 Microsoft Corporation Detection of files that do not contain executable code
US7721334B2 (en) 2004-01-30 2010-05-18 Microsoft Corporation Detection of code-free files
US10050917B2 (en) 2007-01-24 2018-08-14 Mcafee, Llc Multi-dimensional reputation scoring
US8160975B2 (en) * 2008-01-25 2012-04-17 Mcafee, Inc. Granular support vector machine with random granularity

Also Published As

Publication number Publication date
AU2001281218A1 (en) 2002-02-18
WO2002013469A3 (en) 2002-09-06

Similar Documents

Publication Publication Date Title
US6826609B1 (en) Policy enforcement in a secure data file delivery system
US5862325A (en) Computer-based communication system and method using metadata defining a control structure
US6345288B1 (en) Computer-based communication system and method using metadata defining a control-structure
US6779022B1 (en) Server that obtains information from multiple sources, filters using client identities, and dispatches to both hardwired and wireless clients
US6954934B2 (en) Management of links to data embedded in blocks of data
US6044205A (en) Communications system for transferring information between memories according to processes transferred with the information
US7222157B1 (en) Identification and filtration of digital communications
JP3168756B2 (en) Email management method of email system
US9479638B2 (en) Methods and systems for dispatching messages to mobile devices
US6430601B1 (en) Mobile document paging service
US7487550B2 (en) Methods, apparatus and computer programs for processing alerts and auditing in a publish/subscribe system
US6643684B1 (en) Sender- specified delivery customization
WO2000029988A1 (en) Method and apparatus for performing enterprise email management
JP2005535013A (en) Mass communication process using multiple delivery media
WO2002013469A2 (en) Recipient-specified automated processing in a secure data file delivery system
GB2347053A (en) Proxy server filters unwanted email
WO2002013489A2 (en) Recipient-specified automated processing in a secure data file delivery system
US6151623A (en) Agent activity report via object embedding
WO2002013470A2 (en) Recipient-specified automated processing of electronic messages
CA2247498C (en) An automated communications system and method for transferring informations between databases in order to control and process communications
EP1059598A2 (en) Web-based document exchange
WebLogic Integration

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC 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 MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

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 GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
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