System and method for data transport

An integrated mail and file transfer (IMFT) system is a web-based data transport system including automatic and authenticated access mechanisms. The integrated mail and file transfer system includes an attachment filter, a message & file control server and data storage. The attachment filter receives emails, and for each email generates a metadata file and one or more content files. The metadata and content files are provided to the message & file control server for storage, indexing and further processing. The message & file control server includes a control module, an account creation module, a user interface module, an access control module, an attachment processing module, and a file store and database interaction module. These modules operate on the message & file control server to provide the functionality for automatically creating user accounts, automatically providing access to file, and automatically storing files and emails. The present invention also includes a number of novel methods including: a method for automatically creating an account and authentication, a method for accessing files via a web based transport system, a method for modifying the access to files, and method for processing emails and storing email bodies and attachments.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to systems and methods for sending and receiving files. In particular, the present invention relates to systems and methods for sending and receiving both electronic mails (emails) and files, and providing an integrated user interface for accessing email and files.

2. Description of the Background Art

Email and the web have flourished in the last decade and reached almost a billion users worldwide. In fact, these technologies have become a primary communication channel for many people. Over the last few years, email and web have substituted for regular mail as the official channel for many business, financial, and government communications and transactions. Even though email and the web have been widely used, these aging technologies have a number of limitations and problems. In particular, there are several problems with current email and web systems.

One problem in current email and web systems is the existence of multiple accounts and passwords. The creation of a web account, whether for a personal or corporate account, involves the definition of username, password and properties meant to identify the user. The result is that people end up with an unbounded list of usernames and passwords that are time consuming to manage, hard to remember, and cannot be recorded. Every computer or internet user knows that to have accounts on multiple systems and services, user must: have multiple different login names; be subject to different password rules; change passwords often according to system requirements, and not record or share a password. These restrictions coupled with multiple accounts results in additional problems including difficulty in remembering usernames and passwords, coping with repetitive, lengthy, and sometimes buggy account creation forms, dealing with complicated or lengthy password re-requests or re-activations, requirements for expensive system administration and security staff, and evaded or ineffective security when users are frustrated with security systems.

Another problem with email systems is the attachments used within the email systems. Most internet users and business services commonly attach files to emails, or create very large HTML messages. The attachments may result in email sizes that are orders of magnitude larger than a text email message. Email technology was originally intended only for short text messages. Attachments were not originally intended in the design of email systems and cause the problems because email servers have a low byte size limit compared to the file sizes that people today consider normal to communicate, each email server has different limitations on email and attachment sizes, and users' email boxes (POP) have limited storage capacity that can be exceeded by incoming messages.

As a result, emails may be bounced back to senders. In addition, the senders may not know whether a message is receivable at a destination email address before the email is actually sent making email unreliable for sending attachments. Some of the problems experienced by email users due to mailbox sizes and similar email limitations, include: unpredictable time to retrieve emails on slow connections, email bounces back (both at receiving and sending server), cluttered email client files that become corrupted, and replication of files between the PC file system and the email system. Furthermore, there are problems experienced by ISPs and corporations handling emails such as mail servers processing large emails that the users may not read, large emails bounce back and double file transfer costs, and missed communications occur and cause inefficiency and potential lost business.

File transfers of information across the web also include a number of problems. Some of the problems relate to web file uploading, links, and permissions. The web is an ideal place to post information, whether in the form or web pages or files. However, it continues to be very difficult to use personal web sites to do simple things like publishing information, notifying desired recipients, and providing them with web links.

While accessing attachments from a web site may be relatively easy, the process to setup restricted access on a personal web space is cumbersome and complicated, and beyond the ability of most users. First, the user must control the web space from which the attachments are downloadable. Second, the user must often do the following: manually upload the file to a web space, identify the correct URL for the file, copy the URL for the file into an email, set up a restricted web directory (.htaccess), place the files to be transferred in the web directory, create a password, and provide the password to the recipient. In addition, users do not have an easy way to upload files that are restricted to a user determined list of people. Portal accounts enable users to create directories to be shared with a list of other people. However, the restricted file sharing is done by directory of files and groups of people. The recipients generally need to have or create an account on that service (for instance, Yahoo Briefcase). Therefore, users who want to determine a limited list of people that can access a file on the web need to: make sure that the intended people have an account on the storage system, set up the list as a group of account IDs, set up a directory accessible to the group, and place a file in such directory. All of this is enormously cumbersome and limitative, and hinders people from sharing files. In other words, it is hard for an expert user to set file permissions for a selected list of people, and virtually impossible for the layman user.

Another problem related to web transfers of data is restrictive corporate intranets. Corporations have invested significantly over the last decade to deploy corporate intranets and file servers within the company's firewalls. This has been useful to define the boundaries of corporate information and sharing. However, employees normally have to communicate with external entities: therefore, corporations had to develop more costly features to enable restricted access and functionality to external customers and suppliers. In addition, corporate intranets need system administrators to enact special access requirements determined by employees' business and communication needs. This has resulted in additional IT development cost for low benefit. Technological constraints have been placed before business constraints, while complicating and slowing down information flow.

Because corporate intranets place a layer of system administration between people and information, employees avoid the boundaries of corporate intranets or email systems and often use other mechanisms for communication such as using email to exchange files that the intranet would disallow, using personal email accounts to conduct corporation business, using external free web file spaces (Xdrive, Yahoo, etc.), and using USB or flash memory cards to transfer files from laptop to laptop, thus evading any predefined control on file systems. The result of this flawed conception and implementation of corporate IT is that businesses deploy very costly intranet infrastructure and operations in the name of security, but this produces a work force that constantly evades the system because they cannot get certain jobs done.

Therefore, what is needed is a system and methods for an integrated mail and file transfer system.

SUMMARY OF THE INVENTION

The present invention overcomes the deficiencies and limitations of the prior art by providing an integrated mail and file transfer (IMFT) system. The IMFT system is a web-based data transport system including automatic and authenticated access mechanisms. In one embodiment, the integrated mail and file transfer system includes an attachment filter, a message & file control server and data storage. The attachment filter includes or is adapted to work with a conventional email server. The attachment filter receives emails, and for each email generates a metadata file and one or more content files. The metadata and content files are provided to the message & file control server for storage, indexing and further processing. The message & file control server is coupled to a conventional web server, the email server, the attachment filter and the data storage. In one embodiment, the message & file control server includes a control module, an account creation module, a user interface module, an access control module, an attachment processing module, and a file store and database interaction module. These modules operate on the message & file control server to provide the functionality for automatically creating user accounts, automatically providing access to file, and automatically storing files and emails.

The present invention also includes a number of novel methods including: a method for automatically creating an account and authentication, a method for accessing files via a web based transport system, a method for modifying the access to files, and method for processing emails and storing email bodies and attachments.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A system and methods for integrated mail and file transfer (IMFT) are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention. For example, the present invention is described primarily with reference to email addresses as unique identifiers. However, the present invention applies to any type of identifier specific to a communication channel such as a telephone number, a user name or other identification number.

Moreover, the present invention claimed below is operating on or working in conjunction with an information system or network. For example, the invention can operate on a local area network, an intranet, or the Internet depending on the configuration. Thus, the present invention is capable of operating with any information system from those with minimal functionality to those providing all the functionality disclosed herein.

System Overview

Referring now toFIG. 1, an embodiment of the data transport system100of the present invention is shown. In this embodiment, the system100comprises: an integrated mail and file transfer (IMFT) system102, a network104, and a plurality of client devices106a-n. As can be seen fromFIG. 1, a particular advantage of the IMFT system102of the present invention is that it requires no changes to the existing IT infrastructure. Users do not have to learn new applications or new technologies, they send their email messages and attachments using the same email clients, or with new intuitive web interfaces provided by the IMFT system102. The IMFT system102filters the attachments and stores them persistently as documents on cheaper file server storage instead of high-performance, expensive email storage. Attachments and the body of the email message are replaced by links in the email message. The IMFT system102controls messaging and the exchange of documents. Ownership and access control are determined by the globally unique email addresses of the sender and of the recipient(s). The time stamp of each document (i.e., attachment), once assigned, cannot be changed. The documents can then be retrieved at the recipient's end by clicking on the links embedded in the email message and downloading the file securely.

The present invention is directed to a device, the IMFT system102, capable of providing an integrated or converged paradigm for the user to send and receive emails, and send and receive files. The IMFT system102includes a message & file control server202, data storage204and an attachment filter206. The IMFT system102also includes a conventional web server208and an email server210. The IMFT system102is a device for processing emails and files, and making them accessible via the web server208. The IMFT system102is coupled by signal line108to the network104for communication and interaction with other devices. The IMFT system102is described in more detail below with reference toFIGS. 2 and 3. The IMFT system102includes the ability to filter and store the attachments, to control messaging and exchange of documents, to automatically create accounts and authenticate users, and to control access to documents.

The network104is preferably of a conventional type for interconnecting computing devices. The network104can be any one of a conventional type such as a local area network (LAN), a wide area network (WAN) or any other interconnected data path across which multiple computing devices may communicate.

One or more client devices106a-nare coupled to the network104by signal lines110a-n, respectively, for communication with the IMFT system102, and other devices (not shown). The client devices106a-ninclude conventional client processing capabilities, such as web browser for interaction with the IMFT system102. The client devices106a-nare adapted to enable communication with the IMFT system102so that the original files can be transferred between the IMFT system102and the client devices106a-nas requested. The client devices106a-ncan be personal computers, cellular telephones, pagers, personal digital assistants, or the like.

The present invention includes a number of novel features including passwordless accounts, automatic account generation, access control, and attachment filtering which are briefly summarized here, but will be described in more detail with reference to the flowcharts.

In one embodiment, the IMFT system102uses an email address or other messaging address as a unique ID. Account access is provided with a key or verification sent to the provided email address or messaging address. In other words, an electronic transport protocol is provided with a “passwordless” authentication scheme. As will be described in more detail below with reference toFIG. 6A-6E, the IMFT system102works as follows: a user provides an email address or messaging address; the user requests an entry key; the key is sent to the email address provided; the user receives the email with a link; clicking the link provides an authenticated entry in the system. Moreover, an account can be assigned based on providing a valid identification, such as an email address or an instant messaging address, thus eliminating the need for the creation of a username as well. The same authentication method can be extended to other unique IDs and related transport mechanisms such as instant messaging (IM ID+IM message containing web link); government issued ID (ID+postal message containing web link); SMS (Short Message Service for Wireless Phones); home (number+voice mail or SMS containing web link), etc. As a result, the IMFT system102provides an electronic service whereby any individual in possession of a valid and acceptable ID can validate into a system (without a previously issued password or key), by requesting a link or key to access the system, sent to the address associated to the ID.

In addition, the validation to the IMFT system102using the defined ID can automatically setup a web account for the user without the typical account setup and form filling procedures. In other words, a “Setupless account” is created for the end user. This means that an account separate from the ID account is not set up for individual access to the system. Technically, an account is set up, but it happens automatically. What makes it “Setupless” is that this happens transparently to the end user; and it is not necessary for the user to select a username and password before getting started. The IMFT system102allows a valid ID to be used in order to grant access files and to an account on the IMFT system102. The present system and method does not require the setup of an account that needs an independent login name and password. Account access can be provided with the authentication process described above using only a (ID or related address+related transport). The IMFT system102allows any individual in possession of a valid ID to be immediately granted an account. The individual is authenticated into the individual account with a key sent to the related address provided to the ID granting agency and the user can immediately access the account with the key received.

The access to files and data using web transport protocols currently uses the file permission method described above. Current file and data access control for information systems is provided at the system level. In addition, file permissions are based on account usernames. Permissions are based on IDs, not accounts. Access is dynamically granted to an account based on the IDs that have been associated with it (through consolidation). In one embodiment, the IMFT system102uses a token formed by encoding a hash key in the URL representing the list of IDs that are permitted to access such a file. The purpose of tokens is to provide authentication (like a password embedded in a link), not to control access. Tokens indicate who you are and how you proved it. The method of proof used can affect what you are potentially allowed to do, independent of what access controls have actually been set. In general, three things affect whether an action is allowed: first, how convincing the proof of identity was; second, the conveyed intentions of the controllers of the resources in question; and third, the conveyed intentions of the controllers of the information in question. The first corresponds to action-restricted tokens, the second corresponds to insider/outsider rules; and the third corresponds to access controls in the classic sense. The IMFT system102allows users to determine a set of people, in the form of a list of email addresses, which can download such file. This process is described in more detail below with reference toFIG. 8A. This allows an individual in possession of a file to determine a list of email addresses that identify the only authorized individuals to access such a file.

The present embodiment is a way for a user to grant limited and specific authorization for the use of a system that consumes storage and data communication resources, and hence that user is presumably paying for or subsidizing the storage system. Specific features of the present system may include permissions at object level (file), based on an ID (including email addresses); inheritance of permissions; and enabling permitted users to grant further permissions. In one embodiment, a patronization system is included for specifying an authorized message ID holder for a system's transaction and the message ID holder or user is sent en email containing a link to authorize the transaction. This link allows the user to either download or view information that is protected by a data server or web server. In addition, the IMFT system102includes a proactive authorization of a transaction on behalf of a certain ID.

Additional safeguards to control what a user can do with the link may also be provided. For instance, the IMFT system102can require further authentication to access a link, require further authentication after a defined amount of time has passed (e.g., days) or the link can be made to expire.

The IMFT system102includes an attachment filter206for decomposing emails into components and creating modified emails without attachments. The attachment filter206processes an email from a sender and determines the content components of the email message (such as a file attachment or HTML data, and message body). Then the attachment filter206replaces such components (attachments and message body) with links that make the components accessible as files through the web server208. In particular, the file can be saved in the IMFT system102with a hash link. Then the email being sent to the recipient for accessing the file will have the component replaced by the link. Components of an email message that can be selected and replaced with a link to a file include file attachments, HTML formatted message's file components, images or other files that are linked in the HTML content, and any other subset of the email message body. The sender of the email can also include an encrypted text link. This is done by allowing a message sender to specify selected text in an email to be encrypted. This selection can be done by using special text markers or by a graphical interface selection. Such selected text is then encrypted by the IMFT system102and placed in an encrypted file. The encrypted file can then be saved in the IMFT system102with a hash link. The email being sent has the to-be-encrypted text replaced with the link. Then the encrypted information can be accessed using the hash link and a secure web data link. An example of a secure web data link is SSL (Secure Socket Layer). Using SSL (HTTPS) for the link guarantees that whoever clicks the link will have a secure session, since anyone trying to snoop the connection would need the server's private key that matched its public certificate. It should be understood to those skilled in the art that 1) once the session is initiated, it cannot be snooped; 2) the session can be initiated by anyone who can read the email, however their IP address will be is logged by the system, and it will be viewable by the sender; and 3) sending a link is more secure than sending the text, because once the information in the text is out there, it's out there, and it can be intercepted based on keywords, but the link is generic and can be changed to require further authentication at any later time if so desired.

Integrated Mail and File Transfer (IMFT) System102

Referring now toFIG. 2, a block diagram of a first embodiment of the IMFT system102A according to the present invention is shown in more detail. The IMFT system102A comprises the message & file control server202, the data storage204, the attachment filter206, a web server208and an email server210. Although shown in block diagram form, those skilled in the art will recognize that these components may be integrated into a single device.

The message & file control server202is an apparatus for sending emails and sending documents to other devices; for storing uploaded files, and metadata files and content files generated from original emails; for generating user interfaces for accessing and interacting with the IMFT system102A; and for controlling access to the IMFT system102A. The message & file control server202includes a number of modules for performing these functions as will be described below in more detail with reference toFIGS. 4 and 5. The message & file control server202is coupled for communication and interaction with the data storage204. The message & file control server202has inputs and output coupled to bus212to communicate with the attachment filter206, the web server208and the email server210. The message & file control server202is coupled to the attachment filter206to receive metadata files and content files generated from original emails by the attachment filter206. The message & file control server202is coupled to the web server208to receive data input by users via web pages, provide web pages for presentation to the user, to receive files uploaded from the client devices106a-n, and to download files to the client devices106a-n. The message & file control server202is coupled to the email server210to send modified email messages. The message & file control server202is hardware capable of executing and performing routines to achieve the functionality described below with reference toFIGS. 6A,7A,8A and11.

The data storage204is a device such as a hard disk drive, disk array or other non-volatile storage media. The data storage204is shown as being coupled to the message & file control server202in this embodiment. The data storage204is used to store content files, metadata files, an index, tokens and web pages.

The attachment filter206has an input and outputs for removing attachments from emails. In one embodiment, the attachment filter206strips the attachments including the emails message body, and stores them as separate files persistently on cheaper file server storage instead of high-performance, expensive email storage. The attachment filter206is coupled to the network104by signal line108, and to the email server210by signal line214. The functionality of the attachment filter206will be described in more detail below with reference toFIGS. 3,9A,9B and10. The attachment filter206is hardware capable of executing and performing routines to achieve the functionality described belowFIGS. 9A and 9B.

The web server208is one of a conventional type and is a computer that is responsible for accepting HTTP requests from clients, which are known as Web browsers, and serving them Web pages, which are usually HTML documents and linked objects (images, etc.). The web server208is coupled to the network104by signal line108, and coupled to the bus212for communication with the message & file control server202.

The email server210is one of a conventional type and is for example a server running a Mail transfer agent (MTA) or system of MTAs used to route email and act as a mail server, by storing email and supporting client access (MUA) using Post Office Protocol (POP), Internet Message Access Protocol (IMAP) or other protocols. The email server210is coupled to the network104by signal line108, and coupled to the bus212for communication with the message & file control server202.

Referring now toFIG. 3, a block diagram of a second embodiment of the IMFT system102B according to the present invention is shown in more detail. In this embodiment, the IMFT system102B comprises a file store302with IMFT files, a database304with IMFT tables, a file store adapter306, filters308, a portlet container310with at least one IMFT portlet, an email server312, a mail adapter314, and a web server316with IMFT pages. As can be seen, the file store302and the database304collectively are the data storage204, and the file store adapter306, the mail adapter314and the portlet container310are collectively part of the message & file control server202. The present invention advantageously provides a way for users to interact with their files in a web browser using the web server316and email server312.

As noted above for web server208, the web server316is similarly a conventional type. The web server316includes IMFT pages. The IMFT pages provide the web-based user interface, send user actions directly to the portlet container310, and render portlet responses. The web server316is coupled by signal line108to the network104and by signal line334to the portlet container310.

The email server312is similarly a conventional type, and is similar to the email server210described above. The email server312is coupled by signal line108to the network104and by signal line332to the filter308.

The portlet container310includes at least one IMFT portlet. The IMFT portlet is the portlet backend responsible for controlling work flow, and translating user actions into requests for the file store adapter306and the mail adapter314to perform the necessary functions. The portlet container310is coupled by signal line334to the web server316, and by signal lines326and328, respectively, to the file store adapter306and the mail adapter314.

The mail adapter314is coupled to the portlet container310by signal line328and to the email server312by signal line330. The mail adapter314controls the transmission of modified emails by the email server312. When requested, the mail adapter314signals the mail server312to send emails on behalf of the user. These emails are modified to contain links that point to the file store302and will perform the requested file actions (such as downloading a file or viewing a file folder) when clicked by any recipient.

The file store302stores IMFT files and provides an interface, for example WebDAV, to all files stored in the IMFT system102B. The WebDAV is an open standard that allows many types of applications to use the file system if they have the necessary permissions. In particular, IMFT Portlet has these permissions. The file store302is coupled to the file store adapter306by signal line320, and sends and receives files and commands.

The file store adapter306controls the access to the database304and the file store302. The file store adapter306takes requests, for example in WebDAV, and translates them into actions on the file store302(which contains the IMFT files), and the database304(which stores file properties, such as permissions, in IMFT tables). The file store adapter306also communicates with filters308(attachment filtering software, system virus scanning software, and spam filtering software) in order to block unwanted or dangerous files. The file store adapter306is coupled to the database304by signal line322.

The filters308are similar to the attachment filter206described above. In one embodiment, the IMFT attachment filter308plugs into the mail server312or server cluster, and uses the mail server's virus scanning hooks in order to strip attachments out of incoming and outgoing emails. The attachments may be removed from the emails and sent to the file store adapter306. The attachments can be replaced with links that point back to the file store adapter306. Attachments can be removed based on predefined rules, such as a minimum size that triggers the removal (it may sometimes be unnecessary and even counterproductive to remove attachments of insignificant size). The IMFT attachment filter308implements the functionality that is described below with reference toFIGS. 9A,9B and10.

Message & File Control Server202

FIG. 4is a block diagram of an embodiment of the message & file control server202in accordance with the present invention. The message & file control server202preferably comprises a control unit450, a display device410, a keyboard412, a cursor control device414, a network controller416and one or more input/output (I/O) device(s)418.

The control unit450comprises an arithmetic logic unit, a microprocessor, a general purpose computer, or some other information appliance equipped to provide electronic display signals to display device410. In one embodiment, control unit450comprises a general purpose computer having a graphical user interface, which may be generated by, for example, a program written in Java running on top of an operating system like WINDOWS® or UNIX® based operating systems. In one embodiment, one or more application programs are executed by control unit450including, without limitation, word processing applications, electronic mail applications, financial applications, and web browser applications.

Still referring toFIG. 4, the control unit450is shown including processor402, main memory404, and data storage device204/302, all of which are communicatively coupled to system bus408.

Processor402processes data signals and may comprise various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Although only a single processor is shown inFIG. 4, multiple processors may be included.

Main memory404stores instructions and/or data that may be executed by processor402. The instructions and/or data may comprise code for performing any and/or all of the techniques described herein. Main memory404may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, or some other memory device known in the art. The memory404is described in more detail below with reference toFIG. 5.

Data storage device302stores data and instructions for processor402and comprises one or more devices including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device known in the art. In an alternate embodiment, data storage302may be replaced by a connection to remote data storage204of the IMFT system102. Such a connection is made through a bus coupled to a drive controller that accesses other data storage204of the IMFT system102.

System bus408represents a shared bus for communicating information and data throughout control unit450. System bus408may represent one or more buses including an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, a universal serial bus (USB), or some other bus known in the art to provide similar functionality. Additional components coupled to control unit450through system bus408include the display device410, the keyboard412, the cursor control device414, the network controller416and the I/O device(s)418.

Display device410represents any device equipped to display electronic images and data as described herein. Display device410may be, for example, a cathode ray tube (CRT), liquid crystal display (LCD), or any other similarly equipped display device, screen, or monitor. In one embodiment, display device410is equipped with a touch screen in which a touch-sensitive, transparent panel covers the screen of display device410.

Keyboard412represents an alphanumeric input device coupled to control unit450to communicate information and command selections to processor402. The keyboard412can be a QWERTY keyboard, a key pad, or representations of such created on a touch screen.

Cursor control414represents a user input device equipped to communicate positional data as well as command selections to processor402. Cursor control414may include a mouse, a trackball, a stylus, a pen, a touch screen, cursor direction keys, or other mechanisms to cause movement of a cursor.

Network controller416links control unit450to a network104that may include multiple processing systems. The network104of processing systems may comprise a local area network (LAN), a wide area network (WAN) (e.g., the Internet), and/or any other interconnected data path across which multiple devices may communicate. The control unit450also has other conventional connections to other systems such as a network for distribution of files (media objects) using standard network protocols such as TCP/IP, http, https, and SMTP as will be understood to those skilled in the art. The connection of the message & file control server202to the web server208by signal line212is also shown inFIG. 4as passing through network controller416. However, those skilled in the art will recognize that the web server208and the attachment filter206could be coupled to the bus408for interaction with the message & file control server202in a variety of conventional ways.

One or more I/O devices418are coupled to the system bus408. These I/O devices may be part of other components in one embodiment and in another embodiment are part of the message & file control server202. For example, the I/O device418includes an image scanner for capturing an image of a document for uploading. The I/O device418may also include a printer or an audio input/output device equipped to receive audio input via a microphone and transmit audio output via speakers. Optionally, I/O audio device may contain one or more analog-to-digital or digital-to-analog converters, and/or one or more digital signal processors to facilitate audio processing.

It should be apparent to one skilled in the art that message & file control server202may include more or less components than those shown inFIG. 4without departing from the spirit and scope of the present invention. For example, message & file control server202may include additional memory, such as, for example, a first or second level cache, or one or more application specific integrated circuits (ASICs). Similarly, additional components input/output devices418may be coupled to control unit450. One or more components could also be eliminated such as cursor control414.

FIG. 5is a block diagram of one embodiment of the memory for the message & file control server202. The memory404for the message & file control server202preferably comprises: an operating system502, a control module504, an account creation module506, a user interface module508, an access control module510, an attachment processing module512, and a file store and database interaction module514. As noted above, the memory unit404stores instructions and/or data that may be executed by processor402. The instructions and/or data comprise code for performing any and/or all of the techniques described herein. These modules502-514are coupled by bus408to the processor402for communication and cooperation to provide the message & file control server202. Those skilled in the art will recognize that while the present invention will now be described as modules or portions of a memory unit404of a computer system, the modules or portions thereof may also be stored in other media such as permanent data storage device406and may be distributed across a network104having a plurality of different computers such as in a client/server environment.

The operating system502is preferably one of a conventional type such as, WINDOWS®, SOLARIS® or LINUX® based operating systems. Although not shown, the memory unit404may also include one or more application programs including, without limitation, word processing applications, electronic mail applications, financial applications, and web browser applications.

The control module504is used to control the other modules of the memory404. The control module504is adapted for communication with the account creation module506, the user interface module508, the access control module510, the attachment processing module512, and the file store and database interaction module514. The operation of the control module504will be apparent from the description ofFIGS. 6A-12Dbelow. While the control module504is shown as a separate module of the memory404, those skilled in the art will recognize that the control module504in another embodiment may be distributed as routines in the other modules506-514.

The account creation module506is used to automatically create new accounts, and provide authentication of users to the IMFT system102. In one embodiment, the account creation module506is software adapted for communication with the user via the user interface module508, and communication with the file store and database interaction module514. The creation module506automatically generates a user account in the IMFT system102in response to providing a unique ID such as an email address. Each user account can be associated with a plurality of unique IDs or email addresses. The account creation module506also performs authentication and generates tokens that can be provided to the user for access to files stored in the data storage204. The operation of the account creation module506is described in more detail below with reference toFIGS. 6A-6E.

The user interface module508is used to control the interaction with the user. In one embodiment, the user interface module508is software adapted for communication or operation upon the web server208. The user interface module508is responsible for serving different web pages to present information to the user and to receive user input and files. The user interface module508generates the user interface as depicted in figure is6B-12D. The user interface module508works in conjunction with the other modules,504,506,510,512and514to present information to the user, to receive information from the user, and to receive and send files the user as will be described below with reference toFIGS. 6A,7A,8A and11.

The access control module510is used to modify or set the access controls for files stored in data storage204. In one embodiment, the access control module510is software adapted for communication with the user interface module508and the control module504. In one mode, the access control module510automatically sets the access controls for files that are associated with emails being sent out the IMFT system102. In a second mode, the access control module510uses the user interface module508to communicate with the user. Based on input provided by the user, the access control module510will modify the access control settings for files which the user has uploaded or for which the user has permission to modify the access control settings. The access control module510is also responsible for performing the patronage operations of the present invention wherein a user who does not have permission to perform certain operations with regard to a file can generate a request and send it to the owner of the file or another user who has the ability to provide such permissions. With the present invention, the user advantageously need only select the file for patronage, and then the access control module510automatically performs the remaining steps, including contact the file owner to either obtain patronage or deny patronage. The operation of the access control module510is described in more detail below with reference toFIG. 8A.

The attachment processing module512is used to process content associated with emails so they may be replaced with hypertext links in the modify email format. In one embodiment, the attachment processing module512is software for processing content and metadata files. The attachment filter206decomposes received emails and creates a content file and a metadata file for the message body of the email. Similarly, the attachment filter206creates a content file and a metadata file for each attachment to the email. These content files and metadata files are placed by the attachment filter206in a temporary storage (not shown). The attachment processing module512is responsible for detecting the presence of new content files and metadata files that are placed in the temporary storage. Under the control of control module504, the attachment processing module512works with the file store and database interaction module514to persistently store the content and metadata files in the data storage204. The operation of the attachment processing module512is described below in more detail with reference toFIGS. 9A and 9B.

The file store and database interaction module514is used to store files, metadata files in another control and access information in the data storage204. In one embodiment, the file store and database interaction module514is adapted for communication with the account creation module506and the attachment processing module512to receive and send data files and metadata files, and modify access control information and tokens. The file store and database interaction module514is responsive to signals from the control module504. The operation of the file store and database interaction module514is described below with reference toFIGS. 6A,7A,8A and11.

Methods for Email and File Transmission and Storage.

A. Account Creation and Authentication.

One of the major advantages of the present invention is that it eliminates the requirement for passwords and automatically creates users accounts in the IMFT system102. Referring now toFIG. 6A, a first embodiment of the method for automatically creating a user account and authenticating the account is shown. The process begins in step602when the IMFT system102receives a request for an account page. For example, such a request is received when a user points his browser at the login page of the IMFT system102.

Next in step604, with interaction between the IMFT system102and the client device110, the method determines whether an IMFT cookie exists at the client device. If the user has previously accessed the IMFT system102, an option was presented which allowed the user to allow for automatic access to the system. For example, one of the web pages provided by the IMFT system102provides a selectable checkbox to “Remember me on this computer.” If user selected such an option during the prior session or access, the IMFT system102stored a non-expiring token in a cookie on the user's client device110. From now on, for any connections to IMFT system102started from the same client device110will find the token stored in the cookie, and if the token is valid, the system authenticates the user specified by the token. Instead of presenting the login screen, a session is immediately opened. In this step, the IMFT system102checks604whether such a cookie exists, if so the user is already authenticated, and the method proceeds to step626where the main page for the IMFT system102is presented. If such a cookie does not exist the method proceeds to step606.

In step606, the method sends an IMFT login page to the user's client device110. Referring now also toFIG. 6B, an exemplary graphical representation of a browser650with the IMFT login page652is shown. The IMFT login page652preferably provides a plurality of labels and fields including a field654for entering a unique ID (email address), a field658for entering a key or password, a “Send Me Key” button656for requesting a key to access the IMFT system102, and a “Login” button660for sending the data in the field654and field658as an address/password pair to the IMFT system102. Those skilled in the art will recognize that the unique ID may be any address the user has access to over a given communication channel. For example, if the communication channel is SMTP (email), then a communication address would be an email address that the user has access to. The user inputs data and then selects one of the buttons656,660to send the information to the IMFT system102. The information is received 608 by the IMFT system102. In an alternate embodiment from that described below, the user need only input their unique ID or email address in the IMFT login page652and select the login button660. In response, the IMFT system102generates a main page670that lists the files, if any, to which the user with the email address has access rights. This main page670is populated by searching the access control lists of each file in the IMFT system102, and determining whether the input address is present. If present, the user is permitted to access the file and it is selected for population on the main page670.

Next in step610, the method determines whether a key was requested610. This determination can be made if an identification of which button656,660was sent is provided in the information. Alternatively, if the user does not provide a value in the key field658, the IMFT system102assumes they are requesting a key.

If a key was not requested610, the user is trying to access the IMFT system102using a password. Referring now also toFIG. 6E, an exemplary graphical representation of a browser650with the IMFT login page652is shown. In this exemplary page, the user has input the address oscar.out@gmail.com in the field654for entering a unique ID, and a password in the field658for entering a key. The method continues in step612to compare the received unique ID (email address) and password received in step608to the account information stored in the IMFT system102. In step614, the IMFT system102determines whether the address password pair is valid. If so, the user is granted access, the IMFT system102opens up a session for the user, and the method proceeds to step626to present the main page. The session stays open until it times out due to inactivity, or the user logs out. If address password pair is not valid, the user is denied access and the process ends.

If a key was requested610, the user is trying to access the IMFT system102without a password (passwordless). The IMFT system102then generates 616 a token using the unique ID. This token preferably identifies this user and includes information about what level of access the user has. For example, it could be limited to accessing a single file, accessing an account or may include other rights. The IMFT system102generates 618 an email with a login link to the IMFT system102. The email generated in step618is sent620to the unique ID. Referring also now toFIG. 6C, an exemplary graphical representation of a browser650presenting such an email662is shown. When irene_in@chpc.utah.edu has clicked the “Send me Key” button656, then an email662is sent to that email address. As shown inFIG. 6C, the email662is from666the IMFT system102and addressed to668the email address input, irene_in@chpc.utah.edu, see alsoFIG. 6B. More importantly, the email662includes a link664that when selected will provide access to the IMFT system102.

Once the user receives and opens the email, the user clicks on the link. This causes the browser to send a request for the main page to the IMFT system102. The request for the main page associated with the web link is received622by the IMFT system102. If the matching token is still valid (hasn't expired), the IMFT system102performs the action encoded by the token, in this case opening up a session for the user. For example, the IMFT system102creates624a user account if one does not already exist for this email address and then dynamically populates the main page with information corresponding to the email address. The main page is then sent626to the user's browser. The user can interact628with the IMFT system102using the main page.

Referring now also toFIG. 6D, an exemplary graphical representation of a browser650presenting such a main page670is shown. The main page670associated with a user account contains the List Pane. The List Pane lists all the objects, files and email that the user has access to. From the main page670, specifically from the List Pane in most cases, the user can perform (or at least initiate) all the actions he/she is authorized to on all the objects he/she has access to: uploading, downloading, sending, or viewing files, assigning or revoking access rights to files for other users, performing searches, editing the contact list, changing account options, and so on. As shown inFIG. 6D, the main page670includes the user account, irene_in@chpc.utah.edu, in the upper right corner. The List Pane is divided into a first section672for listing files available for downloading, and a second section674list files that the user has uploaded to the IMFT system102. The downloads are files that others made available to Irene. In this case, the relevant information to show is the sender. The uploaded files are ones that Irene made available to other email addresses. In this case the file list indicates the list of email addresses that have access to this file which can be: private and only for the owner/sender, to one email, or to a plurality of emails. Within each of these sections there are columns for file name678,688, uploader680, downloader690, upload time682,692, and size684,694. The file names686for each file are specifically enumerated. It is important to notice that the timestamp of the files is permanent and multiple files with the same name can be in the file list. The view of files can also be changed to display uploads and downloads mixed, and sorted by time, or file name, etc. This main page670also includes buttons696,698for editing the access control for an uploaded file, and for emailing the file to another party using this integrated mail file system102. Finally, the main page670includes a navigation link area676for transitioning to other web pages for sending email, setting a key or logging out.

Referring now toFIG. 7A, the method for accessing the IMFT system102and files in accordance with the present invention will be described. The IMFT system102first tests702whether access to the IMFT system102is being accomplished by email or via the main page702. Access or viewing a file includes directly or indirectly downloading a file. If access to the IMFT system102is being accomplished by the main page, the method transitions to send704the main page the user, after which the method proceeds to step710where the user selects a link. On the other hand, if access to the IMFT system102is automatic because an email has been intercepted by the IMFT system102, the method proceeds to step706send an email including an IMFT link to the user. Next in step708, the user opens the email. In step710, the user selects a link in the email. Referring now also toFIG. 7B, an exemplary graphical representation of a browser650presenting such an email730is shown. The email730can by on any external email system such as Gmail in this exemplary case.FIG. 7Bshows an example of the email730sent in step706, opened in step708, and the link732selected by the user in step710.

In step712, the IMFT system102receives a specific link or address from the user. Then in step714, the IMFT system102retrieves the file corresponding to the link. The link typically also includes a token. The token is compared to table stored in the data storage204to ensure that the user is authorized to access the file. In one embodiment, the token is a key code that, in the IMFT system102, points to a set of authentication/authorization credentials, i.e., information specifying who can perform what action and when. Tokens can be expiring (they are only valid within a specified time range) or non-expiring (always valid). For example, an expiring token could point to the following information: “user A, currently logged in from IP address X, is allowed to download file Y as long as the user's request is received within 15 minutes from this token creation timestamp”. In another embodiment, tokens that have been used are no longer recognized as valid by the IMFT system102. Next in step716, the file is downloaded to the user's computer via a browser650. In yet another embodiment, if the IMFT system102has the capability to render the file to a format that is displayable by the browser650, the IMFT system102renders the file and sends the rendered files to the browser650of the user. For example, a spreadsheet file could be first be rendered by the IMFT system102as a bitmap, and then the bitmap is displayed in the user's web browser650. Finally, in step718, the user at the client device110can then open or save the file in a conventional manner such as when files are downloaded. The operating system on the client device110displays the “Open/Save to disk” dialog, allowing the recipient to download the file.

Referring now toFIG. 8A, an embodiment of a method for modifying access controls for a file in the IMFT system102is described. It is assumed that the user modifying the file access is the file owner. Changes to file access include granting access and revoking access. The process for modifying access controls for files and patronage begins in step802with the IMFT system102sending a main page670to the user. Next in step804, the main page670is displayed on the user's client device110. An exemplary main page670has been described above with reference toFIG. 6D. Then in step806, the user clicks the edit link698for a file686. The selection input by the user is sent808to the IMFT system102. The IMFT system102determines810the file corresponding to the selected link698and retrieves a list of the users authorized to download the file. The information from step810is used to populate a web page and an access control editing page830including the file name842and a list838of the current authorized users is sent812to the client device110. The access control editing page830is then displayed814to the user at the client device110. Referring now also toFIG. 8B, one embodiment for the access control editing page830is shown. The access control editing page830includes a field832for inputting additional IDs (email address) to grant access to the file, a window838listing IDs that already have access, an “add” button834for adding an ID, a “delete” button836for deleting an ID, and a “done” link840for indicating completion of modification of the file access. The user inputs data and commands using the access control editing page830, and this information is received816by the IMFT system102. The method next determines818whether the command indicating the user is “done” (editing the access controls) was selected. If the command indicating the user is “done” editing the access controls was selected, the method is complete and ends. However, if addition information other than the “done” command was input, the method continues to step820where the IMFT system102modifies access to the file and according to the received addition information input and stores the information in the data store204of the IMFT system102. After step820, the method loops to step812and sends the user an updated access control editing page830that now includes the modifications that the user input. Those skilled in the art will recognize that when a file is uploaded to the IMFT system102, similar web interfaces may be presented to the uploader to set the access control upon uploading. When a file is uploaded to the IMFT system102, the uploader becomes the root owner of that file. Moreover, it should be noted that the owner of file may implicitly and automatically revoke access to the file by deleting the file from the IMFT system102.

Referring now also toFIG. 8C, another method is illustrated where the access control for a file is automatically modified by the IMFT system102. In this example, a user is sending an email from the IMFT system102. The IMFT system102presents a web page interface as shown inFIG. 8C. Since the sender has an account in the IMFT system102and has attached a file “demo_file—2.doc”850, the IMFT system102, once this email is sent by the user automatically modifies the access control settings on the file “demo_file—2.doc”850to allow access by the addressee of the email, oscar.out@gmail.com. Thus, once the email is received by the addressees, it will include a link to the file, and this addressee will have access. If the file attached is not yet in the IMFT system102, the file is uploaded or added to the IMFT system102and the sender becomes the root owner of the file. Similarly, if the email is sent from a system outside the IMFT system102, but is detected by the email server210, the attachment filter206removes the attached file, replaces it with a web link in the email message, then passes the file and related metadata to message & file control server202which in turn makes the file available from the IMFT system102and grants the email sender and recipients access to the file. In this case, the email sender becomes the root file owner.

Referring now toFIGS. 9A and 9B, an embodiment of the method for filtering attachments is described. The method begins by monitoring902and scanning the email traffic (inbound, outbound, and internal to the local email server210). In one embodiment, the attachment filter206leverages existing technologies to unobtrusively monitor email traffic. For example, a virus scanner such as AMaViS is used as an adapter and an abstraction layer between the email server210and attachment filter206. The virus scanner interfaces with the email server210to extract the email messages from a queue. The virus scanner routes the messages to any number of processing utilities (other filters), and takes the processed messages from the last utility in the chain (attachment filter206) and injects them back into the queue. The attachment filter206is preferably positioned downstream in the chain of email processing utilities from any virus scanning or spam filtering modules to prevent the attachment filter206from becoming a security concern.

The method takes each email and performs the remaining method step on it. Next, the attachment filter206extracts904all addresses from the header of the email. Email message headers contain the sender address and up to three lists of recipient addresses. The “To:” list is always present, while the “CC:” and “BCC:” lists are optional.

Once the address information is extracted, the method extracts906metadata from email. The attachment filter206analyzes the email header and the meta-data contained in the MIME stream to extract information about each message component. Of all the possible component types, the subject+body and any attachments can be stored by the attachment filter206as files on the message & file control server202. Based on the meta-information extracted by the attachment filter206, the business logic in the message & file control server202determines the ACL of each file, aggregates the components of each message showing which file is a body and which files are attachments to that body, and authorizes users to access and manage files via web server208of the IMFT system102. The meta-information for each component combines meta-data from the message header and from the MIME stream, and includes: 1) a Unique Object ID which is used as the basename of the file on the web server208and also as the basename of the web link to the file. The Object ID is typically built as a hash of data that uniquely identifies the component, such as the ID of the email message it was part of, the message timestamp, the current system timestamp, a checksum, etc.; 2) a Message ID from the email header; 3) a Sender; 4) a Recipient(s)—“To:” list of recipients, “CC:” list of recipients and “BCC:” list of recipients; 5) a Message “Date:” field; 6) a System timestamp; 7) Object type of either Subject+body that is a list of all the Object IDs of all the attachments to this message so that the original message can be reconstructed, or an attachment that has an Object ID of the body of which this object was an attachment and an Original file name; 8) a Content type; 9) a File size; and 10) Full pathname where the file will be stored by the attachment filter206.

The method also determines908the stripping rules and preferences set by the administrator. For each matching address, the message & file control server202returns user-defined preferences controlling how the email message should be processed. More details on these user-defined settings as well as related admin rules and system defaults are provided below.

Next, the method determines910whether the email should be modified before it is sent. The attachment filter206evaluates the meta-information extracted from the MIME stream (whether attachments are present and, if they are, their type and size) and compares it with a combination of stripping rules set by the IMFT system102administrator and stripping preferences specified by the message sender and recipients. If, based on the information returned by the message & file control server202, the attachment filter206determines that no further processing is required for a message (send the message unmodified), the message is sent924on to the email server210for delivery, and the process continues to step912to record appropriate information. It should be understood that the stored appropriate information can be used for things like serving the file to the user from the web interface, even if the email was sent unmodified. On the other hand, if it is determined that the email should be sent modified, the method transitions directly from step910to step912.

In step912, the IMFT system102takes apart the email and puts it into content files. An important feature of the present invention is that the present invention converts the email message body into a content file. Similarly, any attachments to the email are converted into respective content files. In one embodiment, this step is performed using an existing software library written in Perl called MIME-Tools. Such existing libraries deal with all the lower-level details of the hierarchical structure, trees of different representations, encodings and differences in rendering the message body.

Next in step914, each of the content files is temporarily stored. Based on all the information received from the message & file control server202and the metadata extracted from the MIME stream, the message & file control server202determines which MIME segments should be processed further and ultimately be converted into files. For example, the attachment filter206could re-generate the native version of a document starting from its base64-encoded MIME segment. Once the native version is produced, all the other representations and encoded versions of that document that are stored in other MIME segments are ignored. The newly generated file is stored on the web server208for publishing, under the control of message & file control server202. The location of the file storage, the directory tree organization, and the file naming convention are configuration settings shared by all the IMFT system102subsystems.

Then in step916, the IMFT system102temporarily stores a corresponding metadata file for each content file. Using the information gathered in steps904,906and908, the attachment filter206generates a file of metadata for each of the content files stored on the web server208. The file with metadata is stored alongside the associated content file. A simple naming convention, where a content file and its associated metadata file share the same basename, allows the message & file control server202to correctly identify the files. This process allows the attachment filter206to transfer files to the message & file control server202unidirectionally, avoiding the overhead of a more complex handshaking protocol. In an alternate embodiment, the files are placed directly in their final locations in the data store, the handshaking protocol is more complex and uses a custom handshaking protocol to stream all the metadata.

In step918, the method determines whether additional content files exist and need to be temporarily stored. If so, the method proceeds to step920to retrieve the next content file. The method then proceeds to step914and step916to temporarily store the content file and the metadata file associated with the content file. This process is repeated for each content file associated with a particular email. Once there are no more content files to be temporarily stored, the method proceeds from step918to step922. It should be noted that the attachment filter206is responsible for extracting the content files, and the metadata files from the original email and placing them into temporary storage. Thereafter, from step922on, the method is largely performed by the message & file control server202. In step922, the message & file control server202detects the presence of temporary files. The message & file control server202next names926the files and stores926them in the IMFT system102. Next in step928, the method creates web links to the files stored in the IMFT system102in step926.

In step930, the message and file control server202creates930a new email with web links in place of the email components, in particular, the attachments and message body. The combination of administrative rules and user preferences determines which of the original message parts are retained in the modified email message and which ones are replaced by web links. If a message part is removed from a message, all its representations and encodings are removed from the MIME stream. When web links need to be inserted into a message body, the attachment filter206handles the several possible body formats. In a plain text format, the links are added to the body together with a standard text explaining what the links represent and what generated them. In generic HTML the following rules are followed to avoid damaging the message structure, formatting, and intended appearance. If the message only contains embedded images, don't strip anything. The images are most likely part of the message format and must be left untouched. Otherwise, a neutral-looking panel is added to the message, with the links represented nicely as icons matching the file type (zip, image, doc, . . . ). Depending on IMFT system's102ability to correctly render dynamic content, embedded scripts or styles may be scrubbed when the body is extracted and stored as a file. In proprietary formats, special features of customized formats, for example email messages generated by Outlook, can be exploited to make the web links look like regular attachments when viewed in the client's attachment pane or tab. Typically, the web links are inserted in the original body of the message. If the body was also removed, a new standard body is generated in two representations, plain text and HTML. The body will only contain the web links and some standard text explaining what the links represent and what generated them.

Then email logs which are maintained by the attachment filter206are updated932. The attachment filter206logs several pieces of information about each processed message for troubleshooting and tracking purposes. The logged information includes: 1) Message ID either generated internally or from the email header; 2) Sender; 3) Recipient(s):—To:” list of recipients, “Cc:” list of recipients and “Bc:” list of recipients; 4) Message “Date:” field; 5) System timestamp; 6) For each attachment an Original file name (from MIME metadata), a Content type (from MIME metadata), a File size and a Full pathname where the file was stored by the attachment filter206. The present invention is particularly advantageous in that an original copy of the email and its metadata are stored in a temporary log maintained by the attachment filter206. For increased service reliability, the whole MIME stream of each message is preserved on short-term storage. In case of corruption, message failure, or other unexpected circumstance, this log can be used to recreate the email and/or reprocess the email. If attachment filter206determines that the attachment delivery was acknowledged by message & file control server202, then the short-term copies of the MIME streams for the messages are discarded. Otherwise, the attachment filter206causes the messages to bounce back to the sender with a notification of failed delivery.

Next the method determines whether the unmodified email was sent in step934. If it was, the method is complete and ends. In this case, the steps ofFIG. 9Bare performed to ensure that a copy of the email is archived persistently on the IMFT system102. If the unmodified email was not sent, then the new/modified email is sent936and the method is complete and ends. In one embodiment, the email is sent by passing it back to AMaViS. Since the attachment filter206is the last link in the chain of email processing utilities, AMaViS puts the messages back in the email server queue.

In summary, the transfer process takes place in three phases. First, for each object to be delivered to the message & file control server202, the attachment filter206store two files on the server208: the actual content file and an associated file with metadata. Second, the message & file control server202detects the presence of metadata files and picks them up. Third, the attachment filter206detects that metadata files have been removed by the message & file control server202. This highly-decoupled process increases service availability, improves performance, and minimizes architectural dependencies between the two subsystems.

Yet another advantage of the present invention is that system administrators and users have the ability to fine-tune the attachment filter's behavior in a number of ways. Those skilled in the art will realize that the configurable aspects of the attachment filter206described below are not exhaustive and only provided by way of example. The system administrators using the attachment filter206can prescribe the 1) file type of attachments that must be replaced by a link; 2) size of attachments that must replaced by a link; 3) size limit for attachments; 4) user quota for file storage; and a 5) Verbosity level of logs with different levels are available for monitoring normal operation of for performance tuning or troubleshooting. Similarly, the users may set filtering options for inserting links such as using a web page that allows configuration. For example, the attachment filter206replace or not replace a portion of a message depending on the content type of a message part (subject+body or attachment) and different size ranges. Possible actions include: 1) do not replace content file with a link—the body or attachment is not processed by the attachment filter206. It is delivered to the recipients inside the email message and it's not added to the sender's file repository; 2) add a link to email—the subject+body or attachment is extracted from the email message and is added to the sender's file repository, but it's not removed from the message. The recipients will receive it via email as usual; and 3) replace content file with a link—the subject+body or attachment is extracted from the email message, it is added to the sender's file repository, and is also removed from the message. The only way for the recipients to get this item is to click on the web link that replaces the item in the email message. Moreover, the present invention provides a special Low resolution checkbox that determines whether a lower-resolution version of the image is sent and/or extracted. Image scaling and format conversion may be used to reduce the size of the images.

Attachment replacement rules are based on content type and file size, and are a combination of system-wide admin settings plus user preferences. Users can in some cases overrule any stripping rules in effect on a message-by-message basis.

Finally, the user can also set Link Style and Position Options. Links are inserted in the email message to replace the original body or an attachment can be customized in several ways: 1) Link position at the top or at the bottom of the message; 2) Link style inside an HTML body; 3) Plain text links or links represented by icons that match the document type (image, archive, multimedia, and so on); and 4) with explanation text, predefined or custom, added by the attachment filter206to briefly explain to the recipients what the web links represent and how they were inserted.

Referring now toFIG. 10, an exemplary embodiment1000for the attachment filter206is shown.FIG. 10illustrates the various data paths, control paths and metadata paths within the attachment filter206.FIG. 10also illustrates a variety of options for processing original emails according to a variety of different set parameters that may be set by the system administrator. In the exemplary embodiment1000, the attachment filter206operates in a manner similar to virus scanning in that a queue is provided for a stream of the incoming emails and a queue is provided for a stream of outgoing emails. The attachment filter,206is positioned between the two queues to process the emails in line. The process begins when an original email is received1002. The sender and recipient information for the email is extracted and sent1004to the message and file control server202. Then MIME metadata is used to break apart1006the message. The MIME parts are stored1008as files on the email server210. The message and file control server202, then determines1010the composition of format of a modified message and login information for the message. The message and file control server202then persistently stores1012the message and the file metadata in the data storage (not shown inFIG. 10). Then the file locations in the file storage of the email server210are used to build1014web links. The modified message is then ready1016for transmission in the outgoing mail stream. This exemplary embodiment1000also includes an emergency bypass selector1018for passing the email message out unmodified by the IMFT system102.

Referring now toFIG. 11, an integrated method for processing email with the IMFT system102and the attachment filter206is described. The process begins by determining1102whether the email is being created using the IMFT system102, or whether it is an email captured by the attachment filter206.

If the IMFT system102is processing an email captured by the attachment filter206, the method continues in step1104by authenticating the sender's ID. Since the email may be from a user outside the IMFT system102, the sender must first be authenticated. Next, a user account is created for the sender if one does not already exist. Creation of an account happens automatically as has been described above by the IMFT system102when a previously unseen email address is authenticated. After step1106, the method transitions to step1112and processing continues the same as if the message were created internal to the IMFT system102.

If the email was being created using the IMFT system102, the user already has established an account and been authenticated, so the method continues in step1108where the files and metadata forming an email are stored1108in the IMFT system102with the sender as the uploader. However, to ensure that only authorized person use the resources of the IMFT system102, the email must get patronized if necessary. In step1110, the IMFT system102determines whether patronization is necessary for this email. If patronization is necessary, the IMFT system102secures patronization and continues on to step1112. If the message cannot be patronized, the email is not sent in the method ends. Patronization provides control over the use of server resources. In particular, one exemplary default is that if the sender or at least one recipient is authorized to use the IMFT system102, the message does not need to be patronized. However, if the message is being sent from a sender that is not authorized to use the IMFT system102to at least one user that is not authorized to use the IMFT system102, then use of the server resources for sending emails and hosting files must be patronized or sponsored by another person authorized to use the IMFT system102. This rule ensures that outsiders cannot use the resources such as storage space and bandwidth unless they are communicating with an authorized user. The IMFT system102advantageously automatically generates messages and secures patronization by sending access control emails for approval by an authorized user. This process will be explained in more detail with reference toFIG. 12below. Those skilled in the art will recognize that a variety of other patronization configurations may be applied by the system administrator. For example, patronization may only be required when server resources such as available storage space and bandwidth become scarce beyond a particular threshold.

In step1112, the recipient addresses for the email are added to the IMFT system102if they do not already exist on the system. Next in step1114, the IMFT system102generates a token for each recipient address that does not already exist on the system. These tokens can be used to provide the users corresponding to the addresses with access to files. In step1116, the IMFT system102adds the recipient address to the access controls for the files that form the email. Finally in step1118, the IMFT system102composes and sends the email. This process is similar to that which was described above with reference toFIGS. 9A and 9B.

Referring now toFIGS. 12A-12D, the process described above will be explained in more detail. In particular,FIG. 12Ashows a graphical representation of a web page1200generated by the IMFT system102adapted for integrated functions. The web page1200allows the user to select and add a file for uploading to the IMFT system102, set the access control for the file, list email address that can access the file, send the email with a link to a file, and set an authorization for the email. This is the patronization component that allows an outsider of an organization to make a file available to another outsider. If an insider were either in the “From” or “To” fields, the patronization would not be needed, as the organization normally accepts outgoing or incoming file attachments included in the emails processed by the organizational email service. If this functionality was not implemented, anyone could send email to anyone, thus using organizational resources without control. However, there are many situations where outsider to outsider communication is acceptable and should be allowed. For example, consider two vendors working together to provide a company with services or goods. Once the “Send email” button1202is clicked on web page1200, the file list of oscar_out has said file as “Pending:”1222in the Uploads part of the file list as shown by the main page1220ofFIG. 12B. At the same time, an email1232is sent to the authorizer1234, irene_in@chpc.utah.edu, who receives the email1232requesting her to authorize the transaction and providing a link1236as shown in web page1230ofFIG. 12C. If and when, irene_in@chpc.utah.edu clicks the link1236to authorize, then the transaction is completed, and the file list as shown in the main page1240ofFIG. 12Dindicates the file as made available1222to otto_out@hotmail.com, while such recipient receives the email with the link.

APPENDIX A

Integrated Mail and File Transfer Feature List

File access control list where the IDs are email addresses

Separation of file for upload, access and notification

Viewing & downloading files available to email address without account creation

Email address holder requests all files available to him

Track who downloaded file

Upload multiple versions

Expiring file link

Encrypted file up/download

Authentication by token

Expiring authentication link

Control access by email

Email link of uploaded file

Download w/o account

Shared file list w/o account

File upload patronization

Notify file recipient

Sender attaches file in email client, recipient has link to file

Recipient can pull attachment sent by email client, from IMFT system.

Authorization Expiration

Address book integration