SERVER BASED DOCUMENT DISTRIBUTION
This invention relates to a method and apparatus for allowing access to information, in particular information which is stored on a server on the Internet and may be any type of online data including documents, pages, graphics, audio data audio visual data etc.
Many companies send mailshots' via email, which may be promotional material or business messages containing important information to • sets of email users (or recipients) . The email often contains links to information on the Internet which the company wishes the recipients to access. If a recipient has an Internet browser then he or she can access the information using such links, which define where the information is located. Conveniently the recipient may be able to access the information directly from the email client simply by clicking on the link.
Some problems with such known systems are that, without using a specialised mail server adapted for the purpose of email tracking, the sender of the mailshot has no definite confirmation that their information has reached the intended audience . They do not know whether a recipient has accessed the information. If the sender notices an omission or mistake in the body of the message, they cannot amend the content once it has been sent . It is not possible to have access to information restricted to particular date and times, or to only allow a particular number of accesses to the information.
According to the present invention there is provided a method of providing information access comprising the steps of : a) storing recipient data defining attributes
relating to information to be accessed, for one or more recipients; b) creating a message to send to a recipient, the message containing a link relating to information data defining one or more items of information to be accessed; and a recipient identifier for identifying the recipient; c) upon receipt of a request from the recipient via the link, accessing said information data and selecting items of information in dependence upon the stored recipient data; and d) allowing the recipient access to the selected one or more items of data.
In this way data is selected according to recipient data which is stored when the message is created. As the information is accessed via a link it is possible to change the information even after the message has been sent
If the stored recipient data defines a period of time during which the information may be accessed and a predetermined error item of information is selected at step c) if the request is received outside said period of time then it is possible to restrict access to the information to particular dates and times
If the stored recipient data defines an access limit for the information and when a recipient sends a request via the link an access is recorded and a predetermined error item of information is selected at step c) if the recipient has already recorded a number of accesses equal to the access limit then it is possible to limit the number of times a recipient is allowed to access the
information.
If the access is recorded along with a date and time of said access then it is possible for the sender to find out which recipients have accessed the information and when
Preferably the stored recipient data includes a privacy flag and in which a predetermined error item of information is selected at step c) if the privacy flag is set and if the request is received from a recipient having an originating platform which is different from the originating platform of a previous request from the recipient, thus preventing unauthorised forwarding of the message.
If at least one of the items of information transmitted to the recipient comprises a link relating to further information and the recipient identifier of the recipient such that further access data may be stored upon access of said further information, then it is possible to record the date and time of accesses to further information to which there are links in the original message.
Preferably, to aid the way in which the information looks when it is accessed, step c) further comprises identifying a type of browser from which the request is received, and the selecting sub-step includes the step of rendering the selected items of information in a form appropriate for the identified browser.
According to another aspect of the invention there is also provided an apparatus for providing information access comprising: a store for storing recipient data defining
attributes relating to information to be accessed, for one or more recipients; a message generator for creating a message to send to a recipient, such that the message contains a link relating to information data defining one or more items of information to be accessed; and a recipient identifier for identifying the recipient; means for receiving a request from a recipient; means for accessing said information data; means for selecting items of information in dependence upon the stored recipient data; and means for allowing the recipient access to the selected one or more items of data.
An embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:
Figure 1 shows a server according to the present invention connected to the Internet; Figure 2 is a flow chart illustrating the steps for providing information access according to the present invention;
Figure 3 illustrates stored data defining attributes relating to information to be accessed, for one or more recipients; Figure 4 is a flow chart illustrating how items of information are selected when a request is received from a recipient .
Referring to Figure 1, a server 3 embodying the present invention is connected to the Internet 1. Internet users 4, 5, 6, 7 can access data on the server 3 and, as is
conventional, such users can access data on other conventional servers such as those shown at 2'. User 7 has a requirement to provide information for access by users 4, 5 and 6 so users 4, 5 and 6 will from hereinafter be referred to as recipients .
Referring now to Figure 2, at step 10 the user 7 creates a document containing items of information intended for the recipients. The document is in the form of a web page, and may be created in Hypertext Markup Language (HTML) Wireless Markup Language (WML) Extensible Markup Language XML) or any other similar type of language. The document may be created using any conventional generator such as Macromedia™ Dream Weaver, Microsoft™ Office applications or other proprietary software. The document may contain any information, including textual information, graphical information, audio and audio visual information, and links to such information. The document may be stored on the server 3 or on other servers 2' .
At step 12 the user 7 stores recipient data 52 (figure 3) defining attributes relating to the created document. Each recipient has a recipient identifier 30 which is associated with the recipient's email address. Data 34 is stored defining the number of times the document may be accessed, data 36 is stored defining a period of time during which the document may be accessed and a privacy flag 38 is stored defining whether the document may be accessed by a recipient on more than one receiving platform (in practice, this is usually equivalent to whether the information may be accessed by another user who has had the message forwarded to them) . A list 32 of intended recipients for said item of information is also stored.
An access record 50 is also created which is used to store data relating to access to the document by recipients. Data 40 relating to the number of times each recipient has accessed the document is stored in the access record, and this access count is initially set to zero.
In this embodiment of the invention the recipient data stored relates to a particular document such that the stored recipient data (34, 36 and 38) defining a set of attributes is the same for each intended recipient of the particular document. In other embodiments, stored recipient data may define a set of attributes corresponding to each recipient of a document
At step 14 the user 7 then creates a message for sending to each of the intended recipients (4, 5, 6) . The message is effectively a message stub containing a link relating to an active page and a recipient identifier for identifying the intended recipient. In this description the term active page refers to an object, which upon receipt of an access request, performs functions according to a pre-programmed set of instructions, and usually involves providing access to information stored on the Internet. Active pages enable processing to take place on the server before the information is made available on the users machine .
The stub may also contain other information, for example information about other recipients, an indication of whether the message is encrypted or password protected, and information about whether forwarding is enabled, for example. All of the information contained in the message stub is available to the recipient even when the server hosting the active page is unavailable.
The link to the active page is supplied as what is known as an embedded page (referred to later as an embedded link) such that the recipient does not need to click on the link in order to access the active page. Microsoft™ Outlook™ supports such links. However, not all email clients do support such links (for example text only email clients such as Yahoo™ Messenger) , so a non-embedded link is also supplied to enable users of such email clients to access the active page using a conventional browser such as Internet Explorer™ or Netscape Navigator™.
The message is then sent to the intended recipients in a standard manner.
When a recipient views the message, if the email client of the recipient supports embedded links then the recipient automatically sends a request to the server 3 to access the active page to which the link relates. Other wise the request is not sent to the server 3 until the recipient actually clicks on the link in order to request access to the active page. In either case the result is ultimately the same .
In this embodiment of the invention active server pages (ASP's) which are supported by servers operating
Microsoft™ Windows are used to implement active pages
However, Common Gateway Interface (CGI) which is a standard for allowing external software to interface with information servers. Java™ Server Page (JSP) which is a technology for controlling the content or appearance of data accessed via the internet through the use of programs that are specified in the page, and run on the server, before information is sent to the user who requested it, could equally well be used.
Other software may also be used to enable ASP's to work on other server platforms including Unix™.
On receipt of an access request at step 16 the active page selects items of information to be accessed in dependence upon the stored recipient data 52 at step 18 according to the flow chart illustrated in Figure 4 and allows access to selected items of information at step 20 as follows:
The type of browser that the request originates from is identified at step 60 so that the document may be provided in an appropriate format suitable for the browser type and version. It is conventional for such information to be passed by the browser to allow identification of the type of browser from which such a request issues to be supplied to an active page.
In this embodiment of the invention, the browser is an instance of the recipient ■ s browser embodied within the recipient's email client, e.g. Internet Explorer™ embedded within an Outlook™ email, the recipient sees this as information embedded within an email, they may perceive the information as being a conventional email message when in fact they see integrated information provided by both the email client and the browser.
The recipient identifier is read at step 62 and checked against the stored recipient data at step 64 to make sure that the request for access is coming from a valid recipient. If it is not then the requester is provided with a document, in an appropriate format for the identified browser type, displaying a suitable error message at steps 66 and 84.
If the recipient identifier shows that the request is from
a valid recipient then at step 68 it is checked whether it is the first access by checking whether the access count 40 is equal to zero. If so a cookie is written to the originating client platform at step 70. A cookie is a message sent to a browser by a server. The browser stores the message in a text file. The message is then sent back to the server each time the browser requests a page from the server. The Internet protocol (IP) address of the originating client platform is stored at 42 in the access record 50 relating to the document.
If the access count 40 is not equal to zero, then a privacy check takes place at step 72 as follows. If the privacy flag stored at 38 indicates that the document should not be accessed by a single recipient from different originating platforms the presence of a cookie on the originating platform is checked and if no cookie is sent by the browser to the server then the IP address of the originating platform is compared with the IP address stored at 42. If these are different the requester is provided with a document, in the appropriate format, displaying a suitable error message at steps 74 and 84. In this way viewing the document on different machines is prevented. This document usually displays a different error message from the error message displayed at 66.
Checking the IP address serves to allow the recipient a second access from an originating platform if cookies have not been enabled on that originating platform. If cookies are disallowed then it will not have been possible to write a cookie to the platform on the first access by the recipient .
Next the date and time restrictions are checked at step 76. If an access time and date range has been stored at 36
then the current date and time (of receipt of the request) as read from the server is compared to the range which has been set. The fact that the current data and time is read from the server is important . The user cannot change his or her time and date settings to circumvent the access time and date range, and the data is unaffected by time zones .
If the current time is outside the defined time limits then access to the document is denied to the requester.
At step 80, if an access limit has been stored at 34 then the access count 40 is compared to the access limit. If the access count is equal to the access limit then access is denied.
In both cases if access is denied then the requester is provided with a document or message selected at step 78 and step 79 respectively, again in the appropriate format selected at step 84. These may be different documents or may be the same as each other .
If access is allowed then data is recorded at step 82 as follows. The access count 40 is increased by one for the validated recipient. The time of access 44 is also updated. (All times are the times according to the server for the reasons mentioned previously)
The document is then provided by the server 3 for access by the recipient. The document is provided at step 84 in the most appropriate form in dependence upon the recipient client browser type which was identified earlier.
The user 7 can check whether, when and how many times the document created at step 10 has been accessed by means of
the access record 50.
The email author can change the document on the server such that any subsequent access, either by recipients reading the email for the first time, or repeat access by viewers who have already read the document, relates to the newest version of the document . The recipient will receive snapshot including any changes made to any of the information after it has been sent, the recipient access data reveals which version of the document a recipient has viewed.
When the document is provided, any links to other documents on the web are converted such that they refer to an intermediary active page, and contain the recipient identifier and a link identifier.
In one embodiment of the invention, when the user 7 creates a message if any files or sets of files (for example, Word™ documents) are to be attached to the message, the user is asked whether those files should be uploaded to the server 3. If the user answers in the affirmative, then the files are stored on the server 3, and a link is created as described above and sent with the message stub instead of using a conventional mechanism for sending attachments.
Once the recipient requests access to the other documents which may be other documents on the web or documents 'attached' to the message (either by clicking on the link, or automatically if embedded links are supported) then a similar process to that described previously occurs; the recipient is validated and the recipient data is checked to determine whether access is allowed. If access is allowed then record the link identifier, IP address
recipient identifier and data and time of access in appropriate fields in a tracking table 54 (figure 3) to record that that linked document was accessed by a particular recipient at a particular time.
Also, it is possible to hide the actual source of the information which is addressed by the link as the information is accessed by use of the intermediary active page. In addition, subsequent links may be hidden by use of a frameless border, as supported by Internet Explorer™ and Netscape Navigator™.