Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
EMAIL MANAGEMENT AND CONTROL SYSTEM
Document Type and Number:
WIPO Patent Application WO/2016/156858
Kind Code:
A1
Abstract:
A server and method for using a pseudo-mailbox email address as an intermediary between a sender inbox and a recipient inbox, each with respective email addresses. The method comprises, in a server, receiving a first email from a sender, the first email being directed towards the pseudo-mailbox, the email comprising a header and a body, the header comprising a to-address indicating the email address of the pseudo-mailbox and a from-address indicating the email address of the sender; and sending a second email comprising the body of the first email and a header comprising a to-address indicating the email address of the recipient inbox and a from-address indicating the email address of the pseudo-mailbox.

Inventors:
TEES, Gordon (10 Middleton Place, London Greater London W1W 7TG, W1W 7TG, GB)
Application Number:
GB2016/050916
Publication Date:
October 06, 2016
Filing Date:
March 31, 2016
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
TEES, Gordon (10 Middleton Place, London Greater London W1W 7TG, W1W 7TG, GB)
International Classes:
H04L12/58
Foreign References:
EP0899918A21999-03-03
US20020087641A12002-07-04
US20120117239A12012-05-10
Other References:
None
Attorney, Agent or Firm:
GRANLEESE, Rhian (90 Long Acre, London Greater London WC2E 9RA, WC2E 9RA, GB)
Download PDF:
Claims:
CLAIMS

1. A method of using a pseudo-mailbox email address as an intermediary between a sender inbox and a recipient inbox, each with respective email addresses, the method comprising, in a server:

receiving a first email from a sender, the first email being directed towards the pseudo-mailbox, the email comprising a header and a body, the header comprising a to-address indicating the email address of the pseudo-mailbox and a from-address indicating the email address of the sender; and

sending a second email comprising at least part of the body of the first email and a header comprising a to-address indicating the email address of the recipient inbox and a from-address indicating the email address of the pseudo-mailbox.

2. A method according to claim 1 wherein sending the second email is based on a set of one or more rules.

3. A method according to claim 2 wherein the set of one or more rules defines a period during which the second email may not be sent. 4. A method according to claim 3 wherein, if the first email is received during the period, the sending of the second email is delayed until the period expires.

5. A method according to claim 3 wherein, if an email directed towards the pseudo-email address is received during the period, the email is deleted and no further email comprising the body of the email is sent.

6. A method according to one of claims 4 or 5 wherein, if an email is received during the period, a notification email is sent to the sender to notify them that the second email has not been sent during the period.

7. A method according to one of claims 4 or 5 wherein, if an email is received during the period, no notification is sent to the sender alerting them of the set of one or more rules.

8. A method according to any of claims 3-7 wherein the period is defined based on dissociating the pseudo-mailbox email address from the email address of the recipient inbox for the duration of the period of time. 9. A method according to any preceding claim wherein the second email comprises the email address of the sender.

10. A method according to any preceding claim wherein the second email comprises a display name associated with the pseudo-mailbox email address.

1 1. A method according to any preceding claim wherein the pseudo-mailbox email address is associated with the recipient inbox and the email address of the recipient inbox is predefined. 12. A method according to any of claims 1-10 wherein the pseudo-mailbox email address is associated with the email address of the sender inbox and the email address of the recipient inbox is determined from content of the first email.

13. A method according to claim 12 wherein:

the method further comprises, in the server, removing the email address of the recipient inbox from the content of the first email to produce modified content of the first email; and

the second email comprises the modified content. 14. A method according to any preceding claim wherein:

the method further comprises, in the server, searching content of the first email for any occurrences of a given email address and obfuscating each occurrence of the given email address to form modified content; and

the second email comprises the modified content.

15. A method according to claim 14 wherein, if the first email is received from an email address associated with the pseudo-mailbox email address, the given email address is the email address of the sender and the obfuscation involves replacing the email address of the sender with the email address of the pseudo-mailbox email address.

16. A method according to claim 15 wherein, if the first email contains information identifying the first email as a reply to the email address of the recipient, the method further comprises, the server, prior to replacing the email address of the sender with the email address of the pseudo-mailbox email address:

searching the content of the first email for any occurrences of the pseudo- mailbox email address; and

replacing each occurrence of the pseudo-mailbox email address in the content with the email address of the recipient.

17. A method according to claim 14 wherein, if the first email is received from an email address which is not associated with the pseudo-mailbox email address, the given email address is the pseudo-mailbox email address and the obfuscation involves changing a character of the given email address to a different symbol.

18. A server for using a pseudo-mailbox email address as an intermediary between a sender inbox and a recipient inbox, each with respective email addresses, the server comprising a controller configured to:

receive a first email from a sender, the first email being directed towards the pseudo-mailbox, the email comprising a header and a body, the header comprising a to-address indicating the email address of the pseudo-mailbox and a from-address indicating the email address of the sender; and

send a second email comprising at least some of the body of the first email and a header comprising a to-address indicating the email address of the recipient inbox and a from-address indicating the email address of the pseudo-mailbox.

19. A method of setting up an email account, the method comprising:

providing a number of domains for an email address;

receiving a selection of one of the domains, along with a selection of an email address of the domain;

determining whether the email address is already being used; and

if the email address is not already being used, assigning the email address to the user,

wherein the domains are provided based on historical usage data for each domain.

20. A method according to claim 19 wherein domains which have previously experienced usage above a predefined limit are not provided for selection.

21. A server for setting up an email account, the server comprising a controller configured to:

provide a number of domains for an email address;

receive a selection of one of the domains, along with a selection of an email address of the domain;

determine whether the email address is already being used; and

if the email address is not already being used, assign the email address to the user,

wherein the domains are provided based on historical usage data for each domain.

Description:
Email Management and Control System FIELD Embodiments described herein relate generally to electronic mail or email, and more particularly toward the provision of tools for the management and control of email.

BACKGROUND Email rules are applied within the inbox Email users can set up rules in their Mail User Agent (MUA) or inbox (a combination of mail client and mail server) to manage their email. Rules are actions that an inbox runs automatically on emails, based on conditions the inbox owner has specified. A defining feature of rules is that they are applied when an email is in a user's inbox. Current systems offer no mechanism to create, customise and apply rules to an email before it arrives in an inbox, or after it has left the inbox. An example of where this becomes a problem is a user experiencing a deluge of unwanted emails that renders their inbox unusable. The user cannot create a rule to prevent the emails from reaching their inbox in the first place.

Lack of control over the timing of email delivery Email users cannot schedule the delivery time of the emails they receive. Emails typically arrive in a user's inbox within seconds of being sent by the sender. Important and unimportant emails arrive constantly throughout the day. This creates distractions, interruptions and the annoyance of emails arriving at times when they are unwanted by the recipient. For example, 'live traffic alert' emails may arrive at times when they are irrelevant, such as during the working day, instead of when they are relevant, such as in the morning before the user leaves for work.

Email senders can hide their email address

The email address of an email sender can be obfuscated by the use of the 'Display Name' which is a standard feature of email systems. There is no way to extract and view the email address that is obscured by the Display Name without first accepting the email into your inbox and then interrogating it. Any interrogation of the email is undesirable because, for example, the email might contain malware which could be triggered by the interrogation.

The poor reputation of 'Unsubscribe'

The presence of an unsubscribe URL link within an email provides the ability for the email recipient to remove themselves from that the sender's mailing list. This should prevent them from receiving further emails from the sender.

Many email users are wary of the unsubscribe link. Unsubscribe relies on someone else's integrity and the reliability of their processes and systems to remove the address from their mailing list. The unsubscribe link is also abused by spammers to confirm the existence of an address and thus allow them to charge more for a 'verified' email address.

Even in the event that the unsubscribe link works, the control it provides is crude, i.e.: the user is being offered the option to permanently unsubscribe. Unsubscribe provides no capability to temporarily suspend subscription or to prevent delivery of emails for a specific time period.

Fear of loss of control over email addresses

An individual giving their email address to a person or organisation has to trust that person or organisation to safeguard and deal ethically with their email address. There is no way to prevent their email address from being given to third parties. Even if the person or organisation is ethical, circumstances beyond their control (eg: hacking and data theft) may result in the email address being obtained by third parties. This loss of control over what happens to an email address after using it, for example, to register on a website, prevents many people from giving out their address in the first place. This is a rational fear as many people have had their email address stolen or passed on to a third party without their permission.

The inherent difficulties of managing two or more inboxes Many email users have more than one inbox. For example, they may have a work inbox and a personal inbox. Each inbox will have its own email address. A user who wishes to receive emails from a sender at two different email addresses has a number of different choices. They can register multiple times with the sender (once for each inbox address), or they can manually forward the received emails from the first inbox to their other inbox(es), or they can set up a rule on the first inbox to forward the email automatically to the other inbox(es).

These options are inefficient. For example: two separate registrations mean double the management and double the potential privacy issues; while forwarding manually is prone to human error such as forgetting to forward or replying from the wrong inbox address. Re-use of the same password

Faced with the problem of creating and remembering myriad passwords, people will often re-use the same 'username plus password' combination over-and-over again for their online activity such as website registrations, newsletters, offers and other 'signups'. This means their sign-in details are not unique to each website.

Hackers who have compromised a website's security and stolen usernames and passwords will try this stolen identity combination (username+password) at many other popular websites in the hope that it is not unique and will allow the hacker access to other of the user's accounts. Disposable Email Alias providers

'Disposable Email Addresses', 'Email Alias Forwarders' and 'Email Redirection' services allow a user to create a temporary email alias that redirects to the user's inbox address. Such services require either some level of pre-planning or an interruption to the signup/registration process. For example, the user must either have already created their email alias, or they must interrupt the registration process to visit another website and create the alias before returning to the registration process.

The difficulty of changing one's email address Once an email address has been used for numerous registrations, changing away from that address is very difficult and time consuming. A person would have to re-visit every site they registered with and hope they are allowed to change their registration address to that of the new address.

Email alias systems, such as but not limited to Disposable Email Addresses, Email Alias Forwarders and Email Redirection services, do not solve this problem. They require the user to provide a fixed destination email address (typically the user's private inbox address) which cannot later be changed.

A reluctance to register for useful services and information

Email users are becoming increasingly reluctant to sign-up with websites, even when such registrations might be of value to them. This is partly due to security worries. It is also due to a feeling of being overwhelmed by the sheer volume of email from friends, websites and businesses that already have their email address. This reluctance is a major issue for legitimate email and online marketers who are finding it increasingly difficult to get people to sign up for their information and services. Spam Filters

Some email hosting companies apply spam filters to email before it arrives in an inbox. This is a crude blanket method for controlling delivery of email to an inbox and does not, for example, allow the user to tailor the spam filter settings by sender. Consequently mail that is not spam can be incorrectly trapped by such systems and, as a result, may never reach the intended recipient. Even when spam-filtering is implemented within an inbox (i.e.: on emails that have already arrived in the inbox) there is room for error.

One email address used for all online activity

The use of a single email address for all of a user's online activity leaves them open to abuse. If the address is compromised, it is impossible to know where the breach originated. Consequently it is impossible for the address owner to make a judgement on what other information might have fallen into unwanted hands. For example, was the address stolen from a company who also have the user's home address or credit card details and have these details also been stolen or was the address stolen from a company who hold none of this private and sensitive information. Some users have a second (or third or more) email address which they give out to people, websites and companies that they deem to be 'less important'. Nonetheless the issue remains the same. By giving the same contact email address to multiple contacts it is impossible to know precisely where any breach has originated. Complications arising from disabled and deleted inboxes

Inboxes can become inactive, either temporarily or permanently. Typically this occurs as a result of the inbox owner's direct action (for example, by intentionally deleting their account) or after a breach of the terms and conditions of use (for example, a period of non-use).

When an inbox becomes inactive, emails sent to it are 'bounced' back to the sender with a message stating that the account no longer exists. Reputable senders will remove 'bouncing' email addresses from their address book or distribution list. This removal is often automatic. Thus even if an inbox becomes active again at a later date, there is no way of knowing which email senders have deleted the inbox address from their records (apart from waiting to see who doesn't send emails anymore!).

Where the inbox was deleted intentionally, the inbox address will eventually become available for re-use by a new owner. The issue here is that inbox will receive email intended for the original owner from email senders who did not remove the address from their address book / mailing list. This is a privacy and security risk for the original owner of the inbox as mail intended for them is now being received by someone else.

Difficulty of permanently blocking specific senders

It is possible to set up rules to automatically delete email arriving from a specific sender but any such rules can never, by definition, be infallible. For example, deleting email from a specific sender's email address works only if that sender continues to send from the same address. If they send from a new address, a new rule will have to be created. Indeed, spammers deliberately send from thousands of different email addresses to prevent the success of such rules. Difficulty of creating multiple addresses and inboxes on a single domain

It is possible for anyone to purchase a domain name from any one of myriad domain registrars. However if a domain owner wishes to create multiple email addresses at that domain they will be forced to navigate complex technology interfaces, for example a tool called cPanel. This can be daunting for a skilled technologist, and for a person unskilled in the use of technology it can be an impossibility. Once the email addresses, inboxes and associated passwords have been created, it is then still necessary for the individual to install and configure a mail user agent (MUA) and connect it to the mail server for each email address created.

One inbox, one outgoing 'Display Name'

Display Names (also known as Friendly Names) are a convenience to allow email users to better identify themselves. A Display Name is associated with an email address. When a sender sends an email, the Display Name dictates how the sender's 'from' address will display when it arrives in a recipient's inbox. For example, the email address "john.smith@domain.com" might have the display name "John". When a recipient receives an email from this sender it will display in the recipient's inbox as: "John <john.smith@domain.com>" or simply "John".

An outgoing Display Name dictates how the 'from' name of the sender of an email will appear in a recipient's inbox. An inbox can have only one active outgoing Display Name and this Display Name is applied to all email sent from that inbox. No flexibility is given to the inbox user to vary their Display Name on a case-by-case basis. The Display Name will be the same whether the email is being sent to a family member, a best friend, a business colleague or a stranger.

SUMMARY OF INVENTION

The object of the invention is to provide email users with new features in email control and management as well as privacy and security not currently available to them through the use of pseudo-mailbox addresses which are defined as email addresses with no associated structured storage space for emails. Accordingly, pseudo-mailbox email addresses do not have an associated inbox in which emails may be stored and accessed by the user. Instead, pseudo-mailbox email addresses provide a means of redirecting emails to a final inbox associated with a user's email address. According to a first aspect of the invention there is provided a method of using a pseudo-mailbox email address as an intermediary between a sender inbox and a recipient inbox, each with respective email addresses, the method comprising, in a server, receiving a first email from a sender, the first email being directed towards the pseudo-mailbox, the email comprising a header and a body, the header comprising a to-address indicating the email address of the pseudo-mailbox and a from-address indicating the email address of the sender; and sending a second email comprising at least part of the body of the first email and a header comprising a to-address indicating the email address of the recipient inbox and a from-address indicating the email address of the pseudo-mailbox.

Through the provision of an intermediary pseudo-mailbox email address, the final email address of the user may be kept hidden from the sender. As the email is redirected from the pseudo-mailbox to the user's inbox (associated with the final email address) the "To" and "From" sections of the email header are replaced with the final email address and the pseudo-mailbox respectively. This allows the user to more easily filter received emails by pseudo-mailbox email address (where multiple pseudo-mailbox email addresses redirect email to a single inbox) allowing more efficient storage.

The embodiments described herein also provide a more secure means of utilising emails. By providing a pseudo-mailbox email address as an intermediary, the user is safe to provide the pseudo-mailbox address to someone without fear of receiving malicious or unwanted emails. If the user begins to receive unwanted emails, they are free to disconnect the pseudo-mailbox address from their inbox. This blocks emails from reaching the user's inbox entirely. This is advantageous over traditional filters which are applied in an inbox as the email never reaches the inbox and therefore has no opportunity to harm the user (should the email be dangerous) or to take up storage space in the user's inbox.

Moreover, the user is safe to provide the pseudo-mailbox email address to another party in the knowledge that disconnecting the pseudo-mailbox email address completely prevents the other party from contacting them. Traditional filters applied in an inbox for a single email address are usually applied to block a given email address or domain. This does not stop the other party from emailing the user from a different email address or domain. By utilising a pseudo-mailbox address as an intermediary, the party may be completely prevented from emailing the user by disabling the pseudo- mailbox email address. As the party does not have knowledge of the email address associated with the user's inbox, they are prevented from sending unwanted or malicious emails to the user. The second email may be a modified version of the first email. Alternatively, some or all of the first email may be copied and included in the second email.

In one embodiment, the method is implemented in a system which manages the pseudo-mailbox, for instance, a server. The to-address contains information relating to the recipient. More particularly, the to-address contains the intended recipient's email address. The from-address contains information relating to the sender. More particularly, the from-address contains the email address of the sender of the email.

The methods of redirection described herein work for both sending and receiving emails. Accordingly, when a user sends an email via the pseudo-mailbox email address, the user's original email address is hidden. The "To" and "From" sections of the email header are changed to the email address of the intended recipient and the pseudo-mailbox email address respectively. This hides the users original email address, presenting the final email as if it had originated directly from the pseudo- mailbox and as if the pseudo-mailbox email address was a normal email address with an associated inbox. This therefore provides better security and privacy for the user by keeping the user's email address secret. Use of the pseudo-mailbox email address as an intermediary, allows the pseudo-mailbox email address to be given out to people and companies more readily without the worry that knowledge of the email address will be abused. Should a person or company begin to send unwanted email addresses, the pseudo-mailbox email address can be easily disabled without losing the inbox account.

According to one embodiment, sending the second email is based on a set of one or more rules. Accordingly, the whole of a single pseudo-mailbox email address may be associated with one or more rules thereby allowing more control over sending and receiving emails. This provides greater security (as emails are intercepted before they reach the user's inbox) and more efficient use of email storage (as unwanted emails are not stored in the user's inbox). Moreover, as the rules are applied according to the pseudo-mailbox email address (and not according to sender), this prevents spammers or other parties from avoiding the rules by sending emails from new email addresses. It also allows the sending of emails to be prevented for a given period of time. This greater control is useful, for instance, for parents who may wish to limit their child's email usage to a given time (e.g. preventing emails from being sent during school- time).

According to a further embodiment the set of one or more rules defines a period during which the second email may not be sent. In one embodiment, if the first email is received during the period, the sending of the second email is delayed until the period expires. This allows emails to be queued until their receipt is desired. This applies to both the situation where the user is receiving emails and wishes to delay emails until a certain time, or to the situation where the user is sending emails and wishes them to be delayed until a certain time. Queuing may involve repeatedly sending the first email, the second email or information relating to either email (for instance, separate body and header information) to another server which is configured or directed to send the email back to the invention server. By bouncing this information between the two servers, the second email is prevented from being delivered to the recipient during the period; however, it is not stored at the server and is therefore not accessible. This provides a more secure, private and safe form of queuing emails.

Alternatively, the first email, the second email, or information relating to either email (for instance, separate body and header information) may be stored until the second email may be sent. For privacy and efficiency, the stored information is not accessible via an inbox and therefore the pseudo-mailbox does not have its own structure storage. The stored information is merely buffered until the server is able to send the second email.

In an alternative embodiment, if an email directed towards the pseudo-email address is received during the period, the email is deleted and no further email comprising the body of the email is sent. This prevents emails from being redirected if they are received during a given time period. The period may have a start and an end, or may be any time following a certain time. The latter period allows the pseudo-mailbox email address to be decommissioned without opening the email address up to other users. In one embodiment, if an email is received during the period, a notification email is sent to the sender to notify them that the second email has not been sent during the period. For instance, when a received email is deleted and no further email comprising the body of the email is sent, a bounce email may be sent to the sender to alert the sender that the email was not received by the user.

In an alternative embodiment, if an email is received during the period, no notification is sent to the sender alerting them of the set of one or more rules. Such an alert may be anything which informs the sender that the received email has not been redirected to the intended recipient (either through deletion or queuing) or that alerts the sender to the fact that a pseudo-mailbox email address is being used according to a set of rules. Accordingly, no bounce email may be sent thereby preventing senders from being alerted to the rule(s). This allows received emails to be deleted without initially taking up space in a user's inbox, whilst also preventing the sender from being alerted of this fact and possibly removing the user from any subscriptions of which the pseudo- mailbox email address may be a member. This is advantageous as it allows the pseudo-mailbox email address to be decommissioned for a period of time but later used without having lost possible future emails through being removed from mailing lists or subscription lists.

In one embodiment, the period is defined based on dissociating the pseudo-mailbox email address from the email address of the recipient inbox for the duration of the period of time. Where the period has no end (i.e. the pseudo-mailbox email address is decommissioned until further notice) this may be achieved by deleting the email address of the inbox so that no further emails may be sent to the inbox.

Naturally, a first rule may be set up to queue received emails during a first period and a second rule may be set up to delete received emails during a second period. In an alternative embodiment, which operates much like the above embodiments in terms of queuing or deleting emails, the one or more rules define a period during which the second email may be sent and emails received by the server outside of the defined period are queued or deleted as discussed above. In one embodiment, the second email comprises the email address of the sender. This may be included in a subject field of the header, may be included in the body of the second email, or may be otherwise provided in the second email (for instance, as an attachment). In one embodiment, the email address of the sender is denoted by some indicating symbols, for instance, square brackets.

In one embodiment, the second email comprises a display name associated with the pseudo-mailbox email address. This allows emails being sent via the pseudo-mailbox email address to be presented with a display name unique to the pseudo-mailbox address. This protects the user's privacy by hiding the display name of the email address of the inbox. The same applies to emails being received via the pseudo- mailbox address. This allows ease of sorting and filing by providing display names for each pseudo-email address which redirects emails to the inbox. According to one embodiment, the pseudo-mailbox email address is associated with the recipient inbox and the email address of the recipient inbox is predefined. This allows emails to be received via the pseudo-mailbox and forwarded on to the user's inbox. According to an alternative embodiment, the pseudo-mailbox email address is associated with the email address of the sender inbox and the email address of the recipient inbox is determined from content of the first email. This allows a user of the pseudo-mailbox to send an email via the pseudo-mailbox and have it appear to the recipient as being sent from the pseudo-mailbox as if the pseudo-mailbox has its own corresponding inbox. The address of the intended recipient is contained in the body of the first email. Alternatively, it may be included in the header of the first email and removed from the header before the second email is sent.

According to a further embodiment the method further comprises, in the server, removing the email address of the recipient inbox from the content of the first email to produce modified content of the first email. The second email comprises the modified content. This allows the body of the text to be modified to obfuscate any email address information for improved privacy. Content of the first email may be any part of the first email including the body and/or the subject field of the first email. According to a further embodiment, the method further comprises, in the server, searching content of the first email for any occurrences of a given email address and obfuscating each occurrence of the given email address to form modified content; and the second email comprises the modified content.

According to one embodiment, if the first email is received from an email address associated with the pseudo-mailbox email address, the given email address is the email address of the sender and the obfuscation involves replacing the email address of the sender with the email address of the pseudo-mailbox email address. Accordingly, any email sent by the user of the pseudo-mailbox is scanned so that the email address of the user may be replaced with the email address of the pseudo- mailbox. This hides the user's email address and presents the email as if the pseudo- mailbox itself had its own email address. If the first email contains information identifying the first email as a reply to the email address of the recipient, the method further comprises the server, prior to replacing the email address of the sender with the email address of the pseudo-mailbox email address searching the content of the first email for any occurrences of the pseudo- mailbox email address; and replacing each occurrence of the pseudo-mailbox email address in the content with the email address of the recipient. This ensures that the second email contains a coherent set of email addresses which are presented to the recipient as if the user's email address had not been used. Whilst this replacement may occur in the content of the first email, it may also be performed on a copy of the content of the first email to form the modified content prior to the obfuscation of each occurrence of the pseudo-mailbox email address. The information identifying the first email as a reply may be a tag in the header or the body of the email which provides the email address of the recipient.

According to a further embodiment, if the first email is received from an email address which is not associated with the pseudo-mailbox email address, the given email address is the pseudo-mailbox email address and the obfuscation involves changing a character of the given email address to a different symbol. This allows the pseudo- mailbox email address to be obfuscated for privacy purposes (in the event that the received email may be forwarded on or replied to). The different symbol may be any character, such as an asterisk. According to an aspect of the invention there is provided a method of setting up an email account. The method comprises providing a number of domains for an email address; receiving a selection of one of the domains, along with a selection of an email address of the domain; determining whether the email address is already being used; and, if the email address is not already being used, assigning the email address to the user. The domains are provided based on historical usage data for each domain.

This allows the distribution of email addresses to be set according to a load balancing scheme. Email traffic across a number of different domains (as opposed to one domain) leads to increased reliability of email processing and avoids potential bottlenecks during periods of intense email activity. The email address which is set up may be a pseudo-mailbox email address or an email address with its own inbox. Determining whether the email address is already being used comprises determining whether the email address has already been assigned to a user. In addition, this method allows email traffic to be distributed evenly across a number of servers. This provides a more cost efficient method of hosting domains as it is more expensive to host a high volume of traffic on a single high specification server than it is to spread traffic across multiple low specification servers.

According to an embodiment domains which have previously experienced usage above a predefined limit are not provided for selection. This limit may be a predefined number of email addresses assigned to the domain. The limit may be a limit for the amount of traffic for the domain for all users. This limit may be a predefined amount of traffic over a given period of time (for instance, a day) or may be a predefined average amount of traffic over a given period.

All methods described herein may be implemented on a device comprising a controller configured to act out the steps of the methods. This may be a server or other computing device capable of receiving and sending emails. Such a device may store computer readable code to enable the controller to enact the method steps.

According to a further aspect of the invention there is provided a server for using a pseudo-mailbox email address as an intermediary between two inboxes with respective email addresses, the server comprising a controller configured to receive a first email from a sender, the first email being directed towards the pseudo-mailbox, the email comprising a header and a body, the header comprising a to-address indicating the email address of the pseudo-mailbox and a from-address indicating the email address of the sender; and send a second email comprising at least some of the body of the first email and a header comprising a to-address indicating the email address of the inbox and a from-address indicating the email address of the pseudo-mailbox.

According to an additional aspect of the invention there is provided a server for setting up an email account, the server comprising a controller configured to provide a number of domains for an email address; receive a selection of one of the domains, along with a selection of an email address of the domain; determine whether the email address is already being used; and if the email address is not already being used, assign the email address to the user. The domains are provided based on historical usage data for each domain.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with drawings in which:

Figure 1 shows an email address and a pseudo-mailbox email address;

Figure 2 shows a typical email journey from originator to recipient; Figure 3 shows an email journey from originator to recipient via a server according to an embodiment;

Figure 4a shows how an email is processed by the server when an email originates from an email address other than that of the end user;

Figures 4b shows further details of how emails are processed by the server; Figure 4c shows how the server processes display names of received emails; Figure 4d shows how emails are processed by the server to obfuscate email addresses in a received message;

Figure 4e shows how emails are processed by the server to allow a user to reply from an inbox via a pseudo-mailbox email address;

FIG.4f shows how the server processes display names of emails being sent by the user; Figure 5 shows how an email is processed by the server when an email originates from the email address of the end user;

Figure 6 shows how the end user accesses a user interface of an embodiment; Figure 7 shows how a notification email is sent when an email is received and the pseudo-mailbox email address has been disabled;

Figure 8 shows how an email is processed when a pseudo-mailbox email address has been silently disabled;

Figure 9a shows scheduled email delivery to a user with discard outside of scheduled hours;

Figure 9b shows scheduled email delivery to a user with queuing of emails outside of scheduled hours;

Figure 10a shows scheduled email delivery from a user with discard outside of scheduled hours; Figure 10b shows scheduled email delivery from a user with queuing of emails outside of scheduled hours;

Figure 11 shows the process of switching pseudo-mailboxes from one inbox to another; Figure 12 shows the process of auto-replying to a received email and discarding the received email;

Figure 13 shows routing a pseudo-mailbox to multiple inboxes simultaneously;

Figure 14 shows a server according to an embodiment.

DETAILED DESCRIPTION

In order to help a skilled person better understand the technical solution, the present disclosure is hereinafter described in detail with reference to the embodiments and accompanying drawings. FIG.1 shows an email address and a pseudo-mailbox email address. This shows a visual representation of the fundamental difference between an inbox which is an email address (1.1.1) plus a facility for structured storage of emails (1.1.2) to allow access to the emails via an inbox, and a pseudo-mailbox address which is a stand-alone email address (1.2.1) with no facility for structured storage of emails (1.2.2). Accordingly, the pseudo-mailbox does not provide the user with access to emails addressed to the pseudo-mailbox email address. Instead, as discussed below, the emails directed to the pseudo-mailbox are redirected to a designated inbox.

FIG.2 shows a typical email journey from originator to recipient. The email originator (2.1) is the sender of the email (2.2). The originator can be an individual, a company, a website or an automated process. The email enters the internet (2.3) where it is routed to the recipient via a network of email servers. The email comprises a 'to' address (2.4) which is the email address of the recipient, a 'from' address (2.5) which is usually the email address of the originator and a 'message' (2.6) which could include a title, text, images and attachments. The 'message' (2.6) forms the body of the email, whilst any information related to the routing of the email is stored in the header of the email, including the 'to' address (2.4) and the 'from' address (2.5). The email is routed to the 'to' address and is received by the Mail User Agent (MUA) of the recipient (2.7). FIG.3 shows an email journey from originator to recipient via a server according to an embodiment. This illustrates how the journey of an email sent to a user of the invention differs from that of a typical journey as illustrated in FIG.2. The email originator (3.1) is the sender of the email (3.2). The email enters the internet (3.3) where it is routed to the invention server (3.4). The invention server (3.4) is a server in which the processes of embodiments of the present invention are enacted. The invention server alters the email and sends the altered email (3.5) to the user of the invention where it is received by the user's Mail User Agent (3.6). FIG.4a shows how an email is processed by the server when an email originates from an email address other than that of the end user. This illustrates how the invention server alters the email sent by the originator to a user of the invention. The email originator (4.1) is the sender of the email (4.2). The email that is sent by the originator has a 'to' address (4.3), a 'from' address (4.4) and a 'message' (4.5). The 'to' address is a pseudo-mailbox address which is routed to the invention server (4.6). The invention server replaces the pseudo-mailbox 'to' address (4.3) with the invention user's email address (4.8). The invention server replaces the 'from' address (4.4) with the pseudo-mailbox address (4.9). The invention server adds the 'from' email address supplied by the originator to the message (4.10). This allows the originator of the email (4.2) to be identified by the user. The altered email (4.7) is then sent by the invention server to the invention user where it is received by their chosen Mail User Agent (4.1 1). By changing the "from" address (4.9) to the email address of the pseudo-mailbox, it is clear to the user the means by which the altered email (4.10) was received. This provides a simple means of sorting emails into categories (for instance, if one pseudo- mailbox email address is provided to multiple providers of a single service).

As shall be explained below, the process of swapping the 'to' and 'from' addresses allows the user to send emails via the pseudo-mailbox which appear to originate from the pseudo-mailbox email address. This is different from traditional forwarding email addresses, which do not allow emails to be sent from the pseudo-mailbox email address.

FIG.4b shows further detail of how emails are processed by the server. A sender (4b.1) sends an email (4b.2) to a pseudo-mailbox address (4b.8). The Invention Server (4b.12) identifies the Invention User (4b.17) who created the pseudo-mailbox address. The following process is then executed:

• 'To' field (4b.3): The pseudo-mailbox email address (4b.8) is replaced by the inbox email address of the invention user (4b.14).

• 'From' field (4b.4): The inbox email address of the sender (4b.9) is replaced by the pseudo-mailbox email address (4b.8).

· 'Title' field (4b.4): The reply-to address of the sender (4b.6) is appended to the email subject text (4b.10) resulting in subject text (4b.15). The appended address is tagged with marker text; for example, two square brackets:

"[[name@domain.com". If there is no reply-to address then the inbox email address of the sender (4b.9) is appended to the email subject text (4b.10). The modified email (4b.13) comprising the message (4b.16) and the above fields is then sent to the MUA of the user (4b.17).

The received email (4b.2) may be copied in the above process, with the relevant fields changed as described thereby forming the modified email (4b.13), or the message (4b.1 1) may be copied into a new email (4b.13) with the relevant fields added.

FIG.4c shows how the server processes display names of received emails. The sender (4c.1) sends an email (4c.2) to the pseudo-mailbox address (4c.3). The sender has chosen a Display Name for their email address (4c.4). The Invention Server (4c.5) receives the email and identifies the invention user (4c.9) that created pseudo-mailbox address. The Server replaces the sender's email address and Display Name with the pseudo-mailbox email address and its associated Display Name (4c.8) which is predefined by the Invention User. The email (4c.6) is redirected to the Invention User's inbox address (4c.7) and arrives in the Invention User's inbox (4c.9) where the Invention User's chosen Display Name (for the pseudo-mailbox) is shown in place of the sender's chosen Display name. This allows emails to be labelled according to the pseudo-mailbox as they are received so that emails may be easily sorted. As with many of the embodiments, this method may be implemented for sending emails. Accordingly, the user becomes the sender (4c.1) and the intended recipient receives an email (4c.6) from the pseudo-mailbox email address with a Display Name associated with the pseudo-mailbox email address. This allows the user to send emails without alerting the recipient to their own Display Name. This allows the user to hide the fact that a pseudo-mailbox is being used and present the pseudo-mailbox email address as a normal email address with a corresponding inbox. The sending of emails via the pseudo-mailbox email address shall be discussed below in more detail (see Figures 4e and 4f).

FIG.4d shows how emails are processed by the server to obfuscate email addresses in a received message. A sender (4d.1) sends an email (4d.2) to a pseudo-mailbox email address (4d.3). The Invention Server (4d.6) receives the email and identifies the Invention User (4d.10) that created the pseudo-mailbox address. The Invention Server identifies that this email (4d.2) is not coming from an inbox address that is registered to the Invention User's (4d.10) account.

In addition to changing the header information, as discussed above, the email body message (4d.5) is searched for any and all occurrences of the pseudo-mailbox email address (4d.3). All occurrences are obfuscated; for example, by replacing some or all of the characters of the pseudo-mailbox email address with asterisks. The resultant body message (4d.9) is forwarded to the Invention User's inbox address (4d.8).

This process allows the successful outcome of the text replacement process when an Invention User (4d.10) is replying from their inbox using a pseudo-mailbox address (see FIG.4e). It also allows the pseudo-mailbox address to be obfuscated in the event that the email is forwarded to someone who the user (4d.10) does not wish to know the pseudo-mailbox address. As shall be described below, when a user sends an email via their pseudo-mailbox email address, the body is scanned to determine whether the Prevents erroneous replacement of pseudo-mailbox address with the wrong address. FIG.4e shows how emails are processed by the server to allow a user to reply from an inbox via a pseudo-mailbox email address. A sender (4e.1) sends an email (4e.2) to a pseudo-mailbox address (4e.6). Step 1 : Identification that an Invention User is replying to an email received via the Invention Server.

• The (reply) email arrives at the Invention Server (4e.10) which identifies the Invention User (4e.1) who created the pseudo-mailbox address.

• The Server identifies that the sender's inbox email address (4e.7) is

registered to the account of the Invention User who created the pseudo- mailbox address.

• The Server finds the email address of the intended recipient (4e.12) in the subject text (4e.8) which was tagged by the Server with marker text on the inbound journey.

· The marker text might, for example, be two square brackets:

"[[name@domain.com".

Step 2 : The following process is then executed:

• To' field (4e.3): The pseudo-mailbox email address (4e.6) is replaced by the inbox email address of the recipient (4e.12);

• 'From' field (4e.4): The inbox email address of the Invention User (4e.7) is replaced by the pseudo-mailbox email address (4e.6);

• Title' field (4e.5): The inbox address of the recipient (4e.12) and any

associated marker text is removed from the email subject text (4e.8) resulting in title text (4e.13);

• Body (4e.9): The message (4e.9) is searched for any and all occurrences of the pseudo-mailbox email address (4e.6) which are replaced by the inbox email address of the recipient (4e.12). Once this has been done, the email body message (4e.9) is searched for any and all occurrences of the Invention User's inbox address (4e.7) and its associated Display Name. All occurrences are replaced respectively by the pseudo-mailbox address (4e.6) and its associated Display Name resulting in message (4e.14).

Thus the email arrives at the intended recipient (4e.15) with all traces of the Invention User's inbox address removed and as if it had come from an inbox with the pseudo- mailbox as its address. This allows the user (4e.1) to present the pseudo-mailbox email address as a normal email address with a corresponding inbox.

As any received emails would have already been edited to obfuscate the pseudo- mailbox email address within the body of the email (see discussion relating to FIG.4a), these obfuscated email addresses are not changed by the server (4e.10) when the user (4e.1) replies to such an email. This is because the obfuscated pseudo-mailbox email addresses do not match the pseudo-mailbox address (4e.6) which the server (4e.10) replaces with the email address (4e.12) of the recipient (4e.15). Accordingly, when replying to via the pseudo-mailbox, an email (4e.1 1) is sent to the recipient (4e.15) which contains the recipient's email address (4e.12) in the body (4e.14) (instead of the pseudo-mailbox email address (4e.6)) for all instances where the pseudo-mailbox email address (4e.6) results from the user (4e.1) sending emails, whilst all instances of the pseudo-mailbox email address (4e.6) in the body (4e.9) which result from the receipt by the user (4e.1) of an email remain in the body (4e.14) (albeit in an obfuscated form). This presents a coherent email chain to the recipient (4e.15) which appears as if the recipient (4e.15) were exchanging emails only with the pseudo-mailbox email address (4e.6) with no redirection by the server (4e.10).

This also allows the user (4e.1) to hide their own email address to avoid the recipient (4e.15) from learning this email address and bypassing the pseudo-mailbox.

In an alternative embodiment, instead of replacing each instance of the user's email address with the pseudo-mailbox email address, each instance of the user's email address is partially or fully obfuscated, for instance, by replacement of one or more characters with one or more asterisks, or is deleted.

In one embodiment, the email (4b.2) from the user (4b.1) is a reply to an email that was previously processed and forwarded to the Invention User's inbox via the Invention Server. This may have been obfuscated as described with reference to FIG.4d.

The above embodiments relating to searching the body of a message sent to or from a user may also be applied to search the header of the email and replace or obfuscate email addresses as discussed above. FIG.4f shows how the server processes display names of emails being sent by the user. The Invention User (4f.1) sends an email (4f.2) to a pseudo-mailbox address (4f.3). The Invention User's inbox has an associated Display Name (4f.4). The Invention Server (4f.5) receives the email and identifies the invention user (4f.9) who created pseudo-mailbox address and set its associated Display Name. The Server replaces the Invention User's email address and Display Name with the pseudo- mailbox email address and its associated Display Name (4f.8). The email (4f.6) is forwarded to the Invention User's inbox address (4f.7) and arrives in the Invention User's inbox (4f.9) where the Invention User's chosen Display Name is shown in place of the Display Name of the Invention User's inbox.

FIG.5 shows how an email is processed by the server when an email originates from the email address of the end user. This illustrates the email journey when an invention user replies to an originator's email. The user (5.1) replies to the email using their Mail User Agent and is therefore the sender of the email. The originator (5.1 1) of the email that is being replied to is now the recipient. The reply email (5.2) is routed to the invention server (5.6) with a 'to' address (5.3), the 'from' address supplied by the user's MUA (5.4) and 'content' (5.5). The invention server (5.6) receives the email (5.2) and alters it. The invention server replaces the pseudo-mailbox 'to' address (5.3) with the originator's email address (5.8) which is held in encoded or un-encoded format in the 'content' of the email (5.5). The invention server replaces the 'from' address (5.4) with the pseudo-mailbox address (5.9). The invention server removes any and all occurrences of the invention user's email address from the content of the email. The altered email (5.7) is then sent by the invention server to the originator (5.11) where it is received by their chosen Mail User Agent.

The 'content' of the email (5.5) may be the body of the email (5.2) or may be contained in the header of the email (5.2), for instance, in a subject field.

FIG.6 shows how the end user accesses a user interface of an embodiment. This illustrates how a user (6.1) of the invention can gain access to the invention's user interface which can be located on the invention server (6.2). The user interface provides the user access to their management console and configuration settings. The user can access the invention by a web browser, a mobile application or a local executable program file (6.3) running on any suitable device such as a PC, laptop, tablet or smartphone.

FIG.7 shows how a notification email is sent when an email is received and the pseudo-mailbox email address has been disabled. This illustrates the 'hard bounce' (the permanent disabling) feature of the present embodiment. The email originator (7.1) sends an email (7.2) to the pseudo-mailbox address of a user of the invention. The invention server (7.3) receives the email. The user has configured email sent to this address to 'hard bounce' by disabling the address. This means that the server returns the email (7.4) to the originator with a message stating that the address used does not exist. The user's Mail User Agent (7.5) never receives the email and the originator is aware of this.

Accordingly, an email sent to a non-existent email address at a mail server will 'bounce'; ie: the sender will receive an email from the mail server stating that the address they have used does not exist.

In Figure 7, the pseudo-mailbox email address (7.6) has been deleted from the Invention Server's (7.3) mail server records. A sender (7.1) of an email (7.2) will receive a standard 'bounce' email (7.8) to the sender's email address (7.7) from the mail server's email address (7.8). This may alternatively be implemented via a rule, with the association between the user's email address and the pseudo-mailbox email address being maintained. This may be implemented for a predefined period of time as specified by the rule.

The user is therefore able to maintain ownership of the pseudo-mailbox email address after disabling it. This prevents another person from later taking ownership of the address with the inherent security risks that this might present. For example a new owner of the address might start receiving email intended for the old owner of the address.

As the pseudo-mailbox address had been deleted and no longer exists, it would normally be available for re-use. However, the invention server (7.3) retains a record that the pseudo-mailbox address (7.6) was created by the Invention User (7.5) and ensures that it cannot be re-used by anyone except that User. FIG.8 illustrates the 'silent bounce' feature of an embodiment of the invention. The email originator (8.1) sends an email (8.2) to a recipient who is a user of the invention. The invention server (8.3) receives the email. The user has configured email sent to this address to 'silent bounce'. This means that the server discards the email (8.4) by deleting it and not forwarding it on to the invention user. The user's Mail User Agent (8.5) never receives the email and the originator is unaware of this. This 'silent bounce' may is similar to the 'hard bounce', except that no notification email is sent to the sender.

FIG.9 shows scheduled email delivery to a user with discard outside of scheduled hours. This illustrates the scheduled delivery of email to an invention user where emails sent outside the scheduled delivery hours are discarded. The email originator (9a.1) sends an email (9a.2) to an invention user's pseudo-address which arrives at the invention server (9a.3). The server recognises that the email (10a.2) originates from an email address not associated with the pseudo-mailbox, and therefore applies the rule(s) for delivering emails to the user. The user has configured email sent to this address to be delivered to them during certain time periods only, for example between 9am and 5.30pm (9a.4). Email sent by the originator during these hours (9a.5) is sent on by the invention server to the invention user's Mail User Agent (9a.6). Email sent by the originator outside these hours, for example before 9am and after 5.30pm (9a.7) is discarded (9a.8) by the invention server and never reaches the invention user's Mail User Agent (9a.6). FIG.9b shows scheduled email delivery to a user with queuing of emails outside of scheduled hours. Emails sent outside the scheduled delivery hours are queued for delivery during the scheduled hours. The email originator (9b.1) sends an email (9b.2) to an invention user's pseudo-mailbox address which arrives at the invention server (9b.3). The server recognises that the email (10a.2) originates from an email address not associated with the pseudo-mailbox, and therefore applies the rule(s) for delivering emails to the user. The user has configured email sent to this address to be delivered to their inbox during certain time periods only, for example between 9am and 5.30pm (9b.4). Email sent by the originator during these hours (9b.5) is immediately sent on by the invention server to the invention user's Mail User Agent (9b.6). Email sent by the originator outside these hours, for example before 9am and after 5.30pm (9b.7) is queued by the invention server until the scheduled hours, for example 9am (9b.8), when queued email is sent on by the invention server to the invention user's Mail User Agent (9b.6). FIG.10a shows scheduled email delivery from a user with discard outside of scheduled hours. This is much the same as scheduled email delivery to a user, with the corresponding steps of FIG.10a being numbered similarly to FIG.9a. The user (10a.1) sends an email (10a.2) to the pseudo-mailbox email address which arrives at the invention server (10a.3). The server recognises that the email (10a.2) originates from the email address associated with the pseudo-mailbox, and therefore applies the rule(s) for sending emails from the user. The user has configured email sent to this address to be sent during certain time periods only, for example between 9am and 5.30pm (10a.4). Email sent by the user during hours (10a.5) is sent on by the invention server to the intended recipient (10a.6). Email sent by the user (10a.1) outside these hours, for example before 9am and after 5.30pm (10a.7) is discarded (10a.8) by the invention server and never reaches the intended recipient (10a.6).

FIG.10b shows scheduled email delivery from a user with queuing of emails outside of scheduled hours. This is much the same as scheduled email delivery to a user, with the corresponding steps of FIG.10b being numbered similarly to FIG.9b. Emails sent outside the scheduled delivery hours are queued for delivery during the scheduled hours. The user (10b.1) sends an email (10b.2) to the pseudo-mailbox address which arrives at the invention server (10b.3). The server recognises that the email (10b.2) originates from the email address associated with the pseudo-mailbox, and therefore applies the rule(s) for sending emails from the user. The user has configured email sent by them to this address to be sent during certain time periods only, for example between 9am and 5.30pm (10b.4). Email sent by the user during these hours is immediately sent on (10b.5) by the invention server to the specified recipient (10b.6). Email sent by the originator outside these hours, for example before 9am and after 5.30pm (10b.7) is queued by the invention server until the scheduled hours, for example 9am (10b.8), when queued email is sent on by the invention server to the invention user's Mail User Agent (10b.6).

FIG.11 shows the process of switching pseudo-mailboxes from one inbox to another. This illustrates the redirection of one pseudo-mailbox address from one of the user's inboxes (1 1.5) to another (1 1.6). The same methodology applies to the redirection multiple pseudo-mailbox addresses at a time.

The originator (11.1) sends an email to the user's pseudo-mailbox address (1 1.2). The invention server (1 1.3) alters and routes this email (1 1.4) to the inbox that the user has selected for this pseudo-mailbox address (1 1.5). Using the invention's user interface, the user can change the inbox address for one or more of their pseudo-mailbox addresses (1 1.6). In the figure, the user has changed their selected inbox from Inbox A (1 1.5, Before) to Inbox B (1 1.6, After).

FIG.12 shows the process of auto-replying to a received email and discarding the received email. This illustrates the auto-reply and discard feature of embodiments of the invention. An email originator (12.1) sends an email (12.2) to a pseudo-mailbox address. The invention server (12.3) receives the email. The invention user has configured the invention server to send an automatic reply email (12.4) to all originators of emails sent to pseudo-mailbox address on the server. The originators email (12.5) is discarded by the invention server and never reaches the invention user's Mail User Agent (12.6). FIG.13 shows routing a pseudo-mailbox to multiple inboxes simultaneously. This illustrates the routing of an email sent to a pseudo-mailbox address to more than one inbox. An email originator (13.1) sends an email (13.2) to a pseudo-mailbox address. The invention server (13.3) receives the email. The invention user has configured the invention server to redirect this email to two inboxes. The first redirection email (13.4) is sent to the invention user's first Mail User Agent A (13.6), the second redirection email (13.5) is sent to the invention user's second Mail User Agent B (13.6).

Figure 14 shows a server according to an embodiment. The methods disclosed herein may be implemented in on a server (14.1). The server (14.1) comprises a controller (14.2), memory (14.3) and an input/output interface (14.4). The input/output interface (14.4) is configured to connect to the internet and to receive and send emails. The input/output interface (14.4) is connected to the controller (14.2) which is configured to implement the method disclosed herein to redirect emails received from a sender email address to a recipient email address. The controller (14.2) is connected to memory (14.3) which stores computer readable code to dictate the functions of the controller (14.2). Rules, as discussed above, may be stored in the memory (14.3) to dictate how emails are redirected. The memory (14.3) is also configured to temporarily buffer emails in a queue according to one or more rules until the emails are scheduled or permitted to be sent to the recipient email address.

The advantages of embodiments of the invention are described below.

Interception of emails on route to-and-from the user's inbox

Emails pass through the invention server prior to arrival in the invention user's inbox. They also pass through the server on their journey from the user's inbox. This allows the one or more of the ultimate email addresses to be hidden and rules to be applied to the redirecting of emails. Whilst rules may be applied within an inbox, this risks malicious emails being opened, takes up space within the user's inbox and results in a greater computing strain on the server hosting the end user's inbox.

The end user can simultaneously redirect emails addressed to pseudo-mailbox addresses to as many inboxes as they wish.

Embodiments conquer the fear of registering for services or information providers by providing tools such as scheduling, suspension and permanent blocking of emails from selected senders. The end user can create a unique 'to' address for each sender by providing them with a unique pseudo-mailbox email address. By disabling the relevant 'to' address for a particular sender (the relevant pseudo-mailbox email address), that sender's email can never reach the invention user's inbox, regardless of where they are sending their mail from. Embodiments of the invention extract and clearly display the originating email address of the sender without the need for interrogation and do so before the email arrives in the recipient's inbox.

Embodiments of the invention allow the user to know immediately which sender (individual, website or company) has had their security compromised. This provides the user with tools to take specific and immediate blocking action against any further emails from the unwanted sender and it enables the user to create a new and uncompromised email address for use with the original sender if desired. Rules applied before an email arrives in an invention user's inbox

Rules are applied to a user's incoming (received) mail prior to the email's arrival in the user's inbox. This is possible because the invention server hosts and intercepts the pseudo-mailbox addresses of all users.

Embodiments of the invention route incoming and outgoing email via an intermediate server, the invention server, and allows an end user to accomplish tasks such as delaying or discarding (either temporarily or permanently) email before it arrives in a user's inbox.

Rules may be set for specific individual senders so, for example, mail from a friendly sender will never be trapped or discarded.

Embodiments of the invention allow the user to temporarily disable a pseudo-mailbox address without sending a bounce message to the senders of email. As desired, the email itself is discarded and does not reach the inbox of the invention user while removing the risk of automatic deletion from address books / mailing lists.

Embodiments of the invention also allow the user to permanently disable a pseudo- mailbox address while retaining Ownership' of the address. This means the address is not made available for use by anyone else in the future.

A simple interface is provided that allows unlimited pseudo-mailbox addresses to be created. These addresses can be immediately redirected to existing inboxes (MUAs) removing all configuration requirements.

Embodiments allow the invention user to have a unique outgoing Display Name for each pseudo-mailbox address.

Rules applied after an email leaves an invention user's inbox Rules are applied to a user's outgoing (sent) mail after the email has left the user's inbox. This is possible because the invention server hosts and intercepts the pseudo- mailbox addresses of all users. Embodiments of the invention allow the user to schedule the arrival time of emails from any or all senders.

Email management and control

Management and control of emails passing through the invention server, such as auto- replying and discarding of emails and scheduling of email delivery, is carried out by the invention server.

Tools for creating, redirecting and disabling pseudo-mailbox addresses

The invention server provides, for example, the ability to create multiple pseudo- mailbox addresses and redirect associated emails to any or all of a user's inboxes. This allows users to create a different email address for every registration. In the event that a user's email address is misused, for whatever reason, embodiments provide a simple process to shut down a pseudo-mailbox address and permanently stop any emails sent to that address from reaching the user's inbox.

Point-of-need generation of pseudo-mailbox addresses The capability to create a new pseudo-mailbox address exactly when it is needed without pre-planning or interruption to workflow, for example, in a store or at the point of registration on a website. This does not require the user to visit a website to create an email address alias either before, during or after the registration process. Interruptions and the need for pre-planning are eliminated. Provision of features associated with inboxes to pseudo-mailbox addresses

Pseudo-mailbox addresses have no email storage capability. Embodiments provide, for example, the ability to reply to any email received at a pseudo-mailbox address from any inbox and have the reply come from the pseudo-mailbox address not the inbox address. Management and control tools available for use with user-owned domain names

In addition to domains provided by embodiments to create pseudo-mailbox addresses (eg: @our-domains.com), users can apply features of the embodiments to domain names that they own (eg: @user-owned-domain. co.uk) thus enjoying the full range of tools provided by the embodiments while maintaining full ownership of their pseudo- mailbox addresses. Inbox independence

Inbox independence is achieved by the separation of the given pseudo-mailbox address from the address of the receiving inbox combined with the ability to redirect any given pseudo-mailbox address to any inbox. For example, this removes the time- consuming difficulty of changing from one inbox email address to another (for instance, moving from a Gmail address to a Hotmail address) and means that an invention user is no longer tied to their inbox provider. Re-visiting the sites where registration took place is not necessary. Moreover, embodiments allow the creation, management and use of multiple pseudo- mailbox addresses. A user can create a unique email address for each registration, thus guaranteeing that their username+password combinations are never duplicated.

Scheduling of Email Delivery Embodiments of the invention provide the user with the ability to schedule the delivery of emails from any sender. For example, scheduling may be configured so that emails from a specific sender arrive only between 09:00 and 17:00 on weekdays. Emails sent after 17:00 are queued until 09.00 on the next weekday when they are released to arrive in the invention user's inbox.

In another embodiment, the invention user has the ability to permanently discard any emails that are sent outside the scheduled delivery hours so that these emails never arrive in their inbox. This feature is possible because the scheduling rules are implemented on the invention server before emails have reached an invention user's inbox. Existing email systems cannot implement this feature because their rules are applied after an email has reached the inbox.

This feature is illustrated in Figures 9 and 10. Auto-reply and Discard

A user can send an automated reply ('auto-reply') in response to email from any chosen sender without the need to first receive the email in their inbox. The email itself is deleted by the invention server and never arrives in the invention user's inbox.

Existing email systems cannot implement this feature because it is the arrival of the email in the inbox that triggers the auto-reply. The received email then accumulates in the inbox, potentially resulting in an unmanageable number of emails. To achieve the same result, the traditional email user would have to set up a number of inbox rules to delete specific emails after arrival but this is complicated, time-consuming and prone to error.

This feature is described in Figure 12.

Changing Destination Inbox A user can change the destination of any or all of their pseudo-mailbox addresses from one inbox to another instantly and with no inconvenience or adverse impact to themselves or those sending email to them.

Thus the user is no longer tied to a specific provider's inbox because of the complications of changing inbox which is a time-consuming process that involves notifying every relevant person/company/website of the new inbox address and, if possible, setting up auto-replies and forwarding rules on the old inbox to redirect desired email to the new inbox. This embodiment provides inbox relocation within seconds and with no need for notification, auto-replies or forwarding.

This feature is described in diagram 11.

Compose, Schedule and Send email from a Pseudo-Mailbox Address A user can compose, schedule and send emails from any of their pseudo-mailbox addresses. The email can be composed, for example, via a browser-based user interface or via a mobile application. The email will be sent at the designated time regardless of whether the user is still signed-in to the application or user interface. The recipient of the scheduled email sees the pseudo-mailbox address in both the 'from' and 'reply-to' address of the email. If the recipient replies to the email their reply is routed via the invention server to the inbox of the invention user.

By definition pseudo-mailbox addresses have no capability to store sent emails. The invention user has the option to receive a 'bcc' (blind carbon copy) of the sent email should they wish to have a record of it.

Silently disable Pseudo-Mailbox Addresses

A user can choose to disable any or all of their pseudo-mailbox addresses without informing the sender of the mail that the pseudo-mailbox is disabled. Any email sent to a disabled pseudo-mailbox address is deleted by the invention server and never reaches the user's inbox. The originator of the email that was discarded does not receive notification that delivery was unsuccessful (hence the use of 'silently').

This feature is described in diagram 8. Permanently disable Pseudo-Mailbox Addresses while Retaining Ownership

A user can disable one or more of their pseudo-mailbox addresses and deliver a 'hard bounce' message to the sender. A 'hard bounce' is email terminology for a message sent from a mail server to the originator of an email informing them that the email address used no longer exists.

While providing the appearance of a deleted email address, this feature makes it possible for an invention user to retain 'ownership' of their pseudo-mailbox address and ensure that it isn't later acquired by someone else. In another embodiment, the permanent disable feature can be utilised when it is suspected that a pseudo-mailbox address has been compromised, perhaps because spam emails are being received via the address. All mail addressed to that pseudo- mailbox address can be permanently prevented from reaching the user's inbox by permanently disabling the address.

This feature is described in diagram 7. Simultaneous Redirection to Multiple Inboxes

It is possible for a user to forward any or all pseudo-mailbox addresses to more than one inbox. For example, the invention user could at any time choose to redirect emails sent to a pseudo-mailbox address to all of their inboxes. This means that it would not matter which inbox the invention user was viewing when an email arrived because the email would arrive in all inboxes simultaneously.

Features can be used with any domain

The features described herein can be used with any domain. A user can purchase their own private domain and use all of the features described herein for the creation, management and control of pseudo-mailbox addresses at that private domain. Create Pseudo-Mailbox Addresses by Email

Fully functioning pseudo-mailbox addresses can be created via email. The process involves a user sending an email from one of their verified inbox addresses to the email address of the automatic creation facility. The user includes the desired pseudo- mailbox address in the title of the email. The validity and availability of the requested pseudo-mailbox address is checked by the server. If it is available, it is immediately created and an email is sent from the server to the user confirming creation. If the request is unsuccessful, an email is sent to the user informing them of the reason for the failure. The user requires access to their inbox, perhaps via a smartphone for example, and they can create pseudo-mailbox addresses at any time from any location. The benefit to the user is that they do not need access to the user interface to create a pseudo- mailbox. Provision of Statistics and History for individual Pseudo-Mailbox Addresses

A user can see statistics and history for individual pseudo-mailbox addresses. It is also possible to aggregate statistical information for selected groups of pseudo-mailbox addresses into trend data.

Data gathered include: number of emails received, number of emails sent, number of replies sent, date and time of emails, email titles and all 'to', 'from' and 'cc' addresses on the emails. All data are stored and presented in a searchable, sortable and filterable database format. This gives the user insight into the sender and provides an easily searchable historic record of key information even after the actual emails have been deleted.

Point-of-Need Creation of Pseudo-Mailbox Addresses

A user can right-click in an email field on a web page and gain access to the server. This is achieved via a browser plug-in (also called an add-on or extension), for example, within Google Chrome or Mozilla Firefox. The plug-in allows the user to create a fully-functioning pseudo-mailbox address immediately and without leaving the current web page. Using this method, the user can create a customised pseudo-mailbox address or they can select from their existing pseudo-mailboxes addresses or they can generate a random pseudo-mailbox address. Once a pseudo-mailbox address is created, selected or randomly generated in this manner, it is automatically entered into the email field on the web page.

Pseudo-mailboxes created this way, including randomly generated pseudo-mailboxes, are immediately fully-functional. Any emails sent to them will be redirected by the invention server to the user's inbox. A user does not have to interrupt their workflow to supply or create an email address to a website that requires one. There is no need for the user to either pre-create pseudo- mailbox addresses or to leave the web page to create a pseudo-mailbox address before returning to use it. Reply from Pseudo-Mailbox Address via Inbox

A user can reply to an email received at a pseudo-mailbox address from their inbox. This reply will be from the pseudo-mailbox address and not the inbox address. The reply is routed via the server where the pseudo-mailbox address is replaced with the relevant recipient address and the user's inbox address is replaced by the pseudo- mailbox address (see Figure 5). All traces of the user's inbox address within the email content are also removed and replaced with the pseudo-mailbox address. The email is then sent onwards to the recipient who receives the email which appears as if it was sent from the pseudo-mailbox address.

The recipient has no way of knowing or discovering the address of the inbox from which the reply originated. Thus the privacy of the user's inbox address is guaranteed.

Set the outgoing 'Display Name' for each pseudo-mailbox address The outgoing Display Name can be set for each individual pseudo-mailbox address. When an invention user sends or replies-to an email using the pseudo-mailbox address, the unique Display Name appears as the 'from' name in the recipient's inbox. The benefit to the invention user is that each Display Name can be tailored to the circumstances or relationship with the person or organisation to whom the pseudo- mailbox address was given.

Set the incoming 'Display Name' for each pseudo-mailbox address

The incoming Display Name can be set for each individual pseudo-mailbox address. Traditionally, when an email user receives email from a sender, the sender's chosen Display Name is shown in the recipient's inbox. The recipient has no control over the sender's Display Name.

The invention server replaces the sender's Display Name with the one chosen by the invention user. Thus the Display Name shown in the invention user's inbox is the one chosen by the invention user and not the one that was chosen by the sender. This can help to avoid spammers who may provide a misleading Display Name to trick the user into opening the email or clicking on a link or attachment contained in the email. Collection of pseudo-mailbox address metadata

Embodiments of the invention store metadata about the creation of each pseudo- mailbox address (for example, the date, time and location) for aggregation, analysis and presentation. Labelling ('tagging') of pseudo-mailbox addresses

Individualised custom labels (ie: 'tags') can be created by the invention user. These tags can be applied to pseudo-mailbox addresses to allow the user to categorise and better understand, manage and control their pseudo-mailbox addresses. For example, the user might create tags like 'important', 'financial', 'marketing', 'job related' or 'research project #1 ' and use these tags to categorise their pseudo-mailbox addresses. The relationship of tags to pseudo-mailbox addresses is many-to-many. One tag can be used on multiple pseudo-mailbox addresses and one pseudo-mailbox address can have many tags. Using tags, the user can aggregate and view data across related pseudo-mailboxes. Tags also make it easy to configure the settings for similar pseudo-mailboxes.

Management Dashboard and Bulk Actions

A user interface is provided for the management of all settings and parameters of individual pseudo-mailbox addresses such as enabling, disabling, auto-replies, scheduling of delivery times and display names.

It is possible to select multiple (ie: "bulk" select) pseudo-mailbox addresses and simultaneously alter the parameters for all those selected. This is particularly powerful when combined with the invention's pseudo-mailbox address tagging feature. Rules Applied Before an Email Arrives

Rules are applied to a user's incoming email prior to the email's arrival in the user's inbox. This is possible because the invention server hosts the pseudo-mailbox addresses of all users, thus all emails pass through the server on route to their final destination.

One benefit of this method of applying rules is that email can be prevented from ever reaching the user's inbox. Another benefit is that email can be delayed on its journey to the user's inbox. For example, if a specific pseudo-mailbox address is receiving emails that are irrelevant to the user, the pseudo-mailbox address can be disabled on the server which prevents the irrelevant emails from ever reaching the user's inbox. This feature is illustrated in Figure 3. Rules Applied After an Email is Sent

Rules are applied to a user's outgoing email after the email has been sent from the user's inbox. This is possible because all emails pass through the server on route to their final destination.

One benefit of this method of applying rules is that email can be sent from any of an user's inboxes without the requirement for the same rule to be set up on each and every of those inboxes. This feature is illustrated in Figure 5.

Load-balancing by Pseudo-Mailbox Address domain

Load-balancing is defined as the distribution of workload across multiple computing resources to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource.

Domain names are provided to users for the creation of their pseudo-mailbox addresses. The provided domain names are shared by invention users and limits can be set on the number of pseudo-mailbox addresses that can be created on each shared domain. When these limits are reached, the domain is made unavailable for the creation of further pseudo-mailbox addresses and a new replacement domain is made available.

This ability to distribute pseudo-mailbox addresses and, hence, email traffic across a number of different domains leads to increased reliability of email processing and avoids potential bottle-necks during periods of intense email activity. A unique Pseudo-Mailbox Addresses given to each sender

A user can create a unique pseudo-mailbox address for each and every person or organisation with whom they interact. This one-to-one relationship between the person/organisation and the supplied pseudo-mailbox address means that it is easy to identify the origin of any email received by the invention user.

If the content of an email obviously does not come from the expected sender, it indicates that the sender has had their address book or mailing list hacked and the invention user can take appropriate action to protect themselves. Extraction and display of sender's email address

A user can easily view the sender's email address. Often the sender's email address is masked by a Display Name. The invention extracts the email address from the email's 'headers' (headers are a mandatory part of all emails that identify particular routing information of the message, including the sender) and displays it prominently on the title line or in the body of the email.

According to any and all embodiments explained above a more private and secure means of sending and receiving emails is provided. While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and devices described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.




 
Previous Patent: FLOW LINE CONNECTOR ASSEMBLY

Next Patent: AN INTERACTIVE BOOK