Sélection de la langue

Search

Sommaire du brevet 2390817 

Énoncé de désistement de responsabilité concernant l'information provenant de tiers

Une partie des informations de ce site Web a été fournie par des sources externes. Le gouvernement du Canada n'assume aucune responsabilité concernant la précision, l'actualité ou la fiabilité des informations fournies par les sources externes. Les utilisateurs qui désirent employer cette information devraient consulter directement la source des informations. Le contenu fourni par les sources externes n'est pas assujetti aux exigences sur les langues officielles, la protection des renseignements personnels et l'accessibilité.

Disponibilité de l'Abrégé et des Revendications

L'apparition de différences dans le texte et l'image des Revendications et de l'Abrégé dépend du moment auquel le document est publié. Les textes des Revendications et de l'Abrégé sont affichés :

  • lorsque la demande peut être examinée par le public;
  • lorsque le brevet est émis (délivrance).
(12) Demande de brevet: (11) CA 2390817
(54) Titre français: METHODE DE TRANSMISSION MODEREMENT SECURISEE DU COURRIER ELECTRONIQUE
(54) Titre anglais: METHOD FOR THE MODERATELY SECURE TRANSMISSION OF ELECTRONIC MAIL
Statut: Réputée abandonnée et au-delà du délai pour le rétablissement - en attente de la réponse à l’avis de communication rejetée
Données bibliographiques
(51) Classification internationale des brevets (CIB):
  • H4L 51/48 (2022.01)
  • H4L 9/36 (2006.01)
(72) Inventeurs :
  • WARRIS, RON W. (Canada)
  • WOYNARSKI, SCOTT P. (Canada)
  • RAE, DONNA M. (Canada)
(73) Titulaires :
  • RON W. WARRIS
  • SCOTT P. WOYNARSKI
  • DONNA M. RAE
(71) Demandeurs :
  • RON W. WARRIS (Canada)
  • SCOTT P. WOYNARSKI (Canada)
  • DONNA M. RAE (Canada)
(74) Agent:
(74) Co-agent:
(45) Délivré:
(22) Date de dépôt: 2002-06-28
(41) Mise à la disponibilité du public: 2003-12-28
Licence disponible: S.O.
Cédé au domaine public: S.O.
(25) Langue des documents déposés: Anglais

Traité de coopération en matière de brevets (PCT): Non

(30) Données de priorité de la demande: S.O.

Abrégés

Abrégé anglais


Software and process that provides a moderately secure, easy to use, fully
automatic and transparent
means of sending and receiving electronic mail ("email") via the Internet
using public-key
cryptography and peer-to-peer ("P2P") networking, without the need for the
user to change the
software or processes that they currently use to retrieve, read, compose and
send email, and without the
use of a centralized control process or store and forward system. The
invention includes: a central
database and server that contains informs ion about which computers are
currently using the solution; a
proxy that provides message encryption and decryption services and manages the
process of
establishing a P2P connection between the sending and receiving systems. and;
a validation process
that provides reasonable assurance that the sender and receiver of an email
message has the authority to
send and receive email messages using the email addresses contained in the
header of the message.

Revendications

Note : Les revendications sont présentées dans la langue officielle dans laquelle elles ont été soumises.


METHOD FOR THE MODERATELY SECURE TRANSMISSION OF ELECTRONIC MAIL
We claim:
1. A method for the moderately secure transmission of email using a system
comprising of: a central
database and server that contains information about which computers are secure
Peer-To-Peer
(P2P) email enabled; an email proxy or service that provides message
encryption and decryption
services; a process that allows sending and receiving systems to exchange
public encryption keys
via a secure P2P connection, and; a validation process that provides
reasonable assurance that the
sender and receiver of an email message has the authority to send and receive
email messages using
the email addresses contained in the header portion of the email message.
2. A method for automatically and asynchronously establishing a secure P2P
connection between two
systems by using standard Internet email services to exchange symmetrically
encrypted computer
IP information.
3. The method of claim 1 comprising a centralized database that records and
reports the current status
of email proxy software or services that have been enabled to send and receive
secure email
messages via a P2P connection.
4. The method of claim 1 wherein email proxy software or other service
intercepts email sent to and
from an email service and provides encryption and decryption services of
incoming and outgoing
email messages using public key cryptography.
5. The method of claim 1 wherein email proxy software or other service is used
to establish a P2P
connection between the sender's computer and the recipient's computer.
6. The method of claim 1 wherein public encryption keys are securely and
automatically exchanged
using a P2P connection established between the sender's email proxy software
or other service, and
the recipient's email proxy software or other service
7. The method of claim 1 comprising of a process that validates each email
address by requiring a user
to register their email address with a central service
8. The method of claim 3 wherein email proxy software or other service can
automatically route email
via standard Internet email if the recipient does not have P2P email proxy
software or service
installed, and if the sender has configured the email proxy software or other
service to
automatically route email via standard Internet email when a secure P2P
connection cannot be
established with the recipient.

9. The method of claim 3 wherein email proxy software or other service
establishes a secure
connection to a central service to report and query the status of other email
proxies by email
address.
10. The method of claim 1 wherein a process validates the senders email
account at the time of
installation of the email proxy software or other service
11. The method of claim 10 wherein a process will execute at the time of
installation which will
generate a globally unique string that will identify the workstation that the
email proxy software or
other service is installed on.
12. The method of claim 10 wherein a process is executed the first time the
email proxy software or
other service is run and of claim 7 to which the user's input is acquired to
obtain the email address
that they wish to send secured email from, and where the email proxy software
or other service will
not send secured email until a verification process has been completed
13. The method of claim 12 wherein the email proxy software or other service
submits the email
address the user enters with the installation unique identifier to the email
security service and the
email security service generates a random alpha-numeric code which is
associated with the email
account and installation unique identifier then emails the email address the
random code.
14. The method of claim 12 wherein the user must enter the random code emailed
to their email
account into the email proxy software or other service which sends the code
and installation unique
identifier to the email security service to verify that the code came through
the correct email box. If
the email security service receives a matching code, the email address is
noted as being validated
and a success response is returned to the email proxy software or other
service that then allows it to
send secured email messages.
15. The method of claim 4 wherein messages that are waiting to be delivered to
the recipient are stored
in a symmetrically encrypted method on the user's computer or other device
until a connection is
made to the recipient's email proxy software at which time messages are
decrypted and then
asymmetrically encrypted with the recipients public key.
16. The method of claim 4 wherein message that have been received from a
sender are stored in a
symmetrically encrypted form on the users computer or other device until the
user's email software
makes a connection to the email proxy software at which time the messages are
decrypted prior to
delivery.

Description

Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.


BACKGROUND OF THE INVENTION
Electronic mail (more commonly referred -to as "email") has introduced an
extremely low cost means
15 far people to communicate with others around the world using the Internet,
and has become the
preferred means of electronic communications for individuals, businesses, and
governments throughout
the world. However email suffers from a distinct lack of privacy in that
messages sent via email are not
unlike postcards sent using the traditional postal service where anyone
involved in the delivery of the
postcard is able to read the message. Likewise an email message is typically
in a format that can easily
20- ~be read ~by anyone with a connputer~ This problem is further exacerbated
by the method that an email
message is routed from the sender to the receiver. In many cases the route
taken during message
delivery can involve numerous computers and systems receiving and forwarding
the message and even
caching copies of the message while one system waits for another system to
take delivery, thereby
further exposing the contents of the message to anyone familiar with email
delivery protocols.
25 In addition to a lack of privacy, the growing problem of address theft
threatens the very integrity of
email, as the current open standard that ; most email systems comply with
makes it trivially easy for
anyone to enter any email address that they want in the "From" field of the
message header, making it
appear that the message was sent by someone else. More and more "spammers"
(people who send

CA 02390817 2002-06-28
Unsolicited Commercial Ernail ("UCE"); more commonly referred to as "spam")
are now 'stealing'
30 and using the addresses of others in order to 'hide their real identity and
shift. the blame for the spam
that they send to sorrieone else who ends up being labeled a spammer,
resulting in their email addresses
being blocked by spare control software and: services. Governments,
:businesses and even individuals
are often the victims of damaging and disparaging email messages from people
who impersonate others
by stealing and using their email address:
35 Consequently; there is a need for an effective, low cost, and very easy to
use method that provides a
moderately secure means of sending and receiving email messages via the
Internet, with reasonable
assurance that the sender and receiver of an mail message has the authority to
send and receive email
to and from the email addresses that are contained in the header of the
message:
DESCRIPTION OF -PRIOR ART . . ..
40 With respect to the secure delivery and receipt of email there are
currently two commonly used
approaches. The first is secure electronic mail ("secure entail") and the
second is the use of Secure
Socket Layer ("SSL") based deliveries using a website for uploading and
downloading of email.
However, neither of these delivery miethods is fully satisfactory with respect
to both ease of use and
security.
45 Secure email works in the ' ame manner as unsecured email does; except that
the email messages are
encrypted: before they are sent: With unsecured email, the sender transmits
his message to the recipient
in an unencrypted state. Anyone who bas access to the systems that transmits
the message will be able
,.
.. ,:
-_~ , ,
to'~reed 'e a a
t~ m ss ge ' vvitli~ 'Iitfle or rio difficulty. With' secure 'eimail' "the
sender° 'eiici ylils the 'message
using an encryption key before it is sent to; the recipient. In this way if
the message is intercepted while
50 in transit, it will be unreadable since (presumably) only the sender andlor
receiver will have the key
required to decrypt .the message. By limiting access to the decryption method
and keys, the sender can
limit who is able to read an encrypted message. By , encrypting the message
before transmitting, the
message is protected during transmission.
However, very few people actually use secure email as they find it too
complicated to install and
55 configure, confusing to use, and only marginally useful due to the lack of
adoption for any one secure
email standard by other email users.

CA 02390817 2002-06-28
In addition to the problems that users experience when they try to use secure
email is the fact that a
secure email message is sent from the sender to the receiver using the same
infrastructure as unsecured
email, with mail being routed through unsecured and open systems that allows
anyone to intercept the
60 message and with sufficient 'skills ~ and resources even decrypt the
message using any number of
techniques and cracking processes openly available on the Internet: Further,
there is still a loss in
privacy in that while the email raessage itself may be -encrypted, the message
headers remain un-
encrypted, revealing who the sender is; who they are sending email to, when
and how often they send
messages to various recipients, and what the subject is of the messages they
do send.
65 The second common approach to sending and receiving secure email messages
is the use of the
Internet's Secure Socket Layer Protocol ("SSL") for the secure transmission of
ernail messages. In this
. approach, a..website .will..use its .digital certificate to authenticate
itself to the sender using the SSL
protocol. Once the website is authenticated, a secure connection is set
up'between'the sender's browser
and the website: The message or document is then sent from the sender's
browser to the website via the
70 secure connection and stored by the website until the recipient connects to
the web site using SSL and
downloads the message or document to their computer via the same type of
secure connection.
This web based store and forward approach has many drawbacks: For example, SSL
only secures the
delivery channels, the message typically remains in unencrypted state while it
is temporarily stored by
the website. If the website is attacked and a thirdparty is able to gain
access to the site, then the third
75 party will be able to read the unencrypted email. In addition; if the
website is untrustworthy or
employees untrustworthy employees, a~ email stored on the site will be
vulnerable.
To~ address t ~ ,. .
his weakness. there are SSL-based services that provide optiorial=password
encryption of
the email that is uploaded o them. However like secure email these systems are
di~cult to use since
they require the sender and receiver to agree on the password used to encrypt
the message before they
8U can use the service.
To address the security risks of optional password protection of email there
are other' SSL-based
services that provide optional encryption of the documents using certificates.
These systems provide
the best in email security, but are even more difficult to use because users
must use an out of band
process to obtain, manage-and exchange keys before they can exchange encrypted
email.

CA 02390817 2002-06-28
85 Secure email and SSL-based delivery services have been available for a
relatively long period of time,
but neither has been widely adopted as they remain difficult to use ~d are non-
transparent. Therefore,
it is the objective of he present invention to provide a mvderatelyl secure
email delivery system that: 1:)
is completely transparent to the user; 2:) does not require the user to modify
how they create, send,
receive or read email; 3.) provides reasonable assurance that the sender and
receiver have the authority
90 fo send and receive email with the ernail addresses used in the header of
the message; 4.) does not
require the user to configure or maintain-complex software, 5.) does not
require a centralized control
system to manage the process of sending or receiving secure ernail, and; 6.)
does not handle or store
any portion of email messages on third party computers.
SUMMARY OF THE INVENTION
95 In accordance .with the present invention,vthe'person who wishes ~o send or
receive secure email installs
an email security proxy (the 'proxy") '(102, 302) onto their computer. During
the installation process
the user validates the email addresses) they wish to use to send and receive
email using an email based
validation process (204) wherein the user enters the email addresses) they
wish to validate into a
validation web page on a website hosted by a Security Service, (201) and
wherein the proxy (102, 302)
100 installation process generates and includes a unique GUID ("Globally
Unique Identifier") that uniquely
identifies the proxy, (102; 302) and wherein,a validation process (204)
records the email addresses)
provided by the user along with-the proxy GUID, and wherein he validation
process (204) emails a
randomly generated validation ID code to each address provided by the user,
and wherein the user
enters each randomly generated ID code for each email address that they
submitted to the validation
105.,. . process..(2!04)aintoahe.proxy,(L.02;,.3Q2)..,eo~g that the user has
the .authority to send and receive
email messages with the addresses) they provided to the validation process.
(204) Once the user has
entered a valid code into the proxy (102, 3Q2) for an email address, and the
code has been validated by
the Security Service, (200) the users validated email address is then added to
he Address Validation
Server (202) as an address that has been validated to send and receive secure
email using the process
110 described herein.
Email messages are sent in a secure manner using public-key cryptography
thereby requiring the user
to generate a pair of encryption/decryption keys that will be used to
automatically encrypt and decrypt
email that is sent and received using the proxy (FU2, 302). Key generation is
completed during software
_4-
_ ~~ -~ """",~~,~", _._.......

CA 02390817 2002-06-28
installation using a step-by: step wizard style process wherein- the user 'is
instructed to provide a
115 randomized data set by simply moving their computer mouse in a-random
fashion until a sufficiently
large enough set of random characters are generated that can be used by the
Eneryption/Decryption
Module (105, 305) to generate the users unique public and private key pair.
Once the user has installed the proxy (102; -302j onto their computer,
generated heir unique
encryption/decryption key pair, and have validated at least one ~email address
that can be used to send
120 and receive secure ernail, the user is then able to send and receive
secure email using their preferred
email software (101) to and from any other user who has installed the proxy
(302) onto their computer
and have validated their email address with the Security Service. (200).
The sender creates email messages using'their preferred email software. (101)
When the user sends the
;._email message the prosy (102) intercepts (1) the outgoing message and
parses aut:the email addresses
125 for each person that the message is destined to. The proxy (1Q2) then
cheeks with the' Address
Validation Server ("AVS") (202) to determine if any ' of the addresses that
the email message is
destined too have been validated with the Security Service: (200) Email that
is destined to addresses
that have not been validated with the Security Service (200) is sent to the
addressees) in an unsecured
manner using conventional email transmission protocols: Exnail that is
destined to addresses that have
130 been validated with the Security: Service, (2U0) are encrypted by the
sender's Encryption/Decryption
Module ( 105) with the sender's personal encryption key and placed in the
Outbound Message Queue
"OlVIQ") (104) on the sender's computer. (1U0) The Peer-To-Peer ("P2P")
Connection Module (106)
then initiates the process of establishing a P2P connection between the sender
and tha receiver for
email that ~s,to be sent in a secure manner by using axi out of band rocess
wherein a conventional
.. , . ~.. "p".:~,..;., "~ .. ,~...:,..........v.,
I35 email message is generated by the sender's proxy (1U2) and sent to the
receiver's proxy (302) using
conventional email protocols: (2) The generated message includes a proxy ID
code in the subject line
and the sender's symmetrically encrypted IP address. The proxy ID code in the
subject line of the
message tells the receiver's. proxy (302) that: 1) the entail message was sent
by another proxy; 2.) the
sending proxy ( 102) wants to establish a secure P2P connection between itself
and the receiver's proxy,
140 (302) and; 3.) to decrypt and use the IP address o establish a P2P
connection between the sender's
proxy (I02) and the receiver's proxy. (302)
-5_

CA 02390817 2002-06-28
The receiver's P2P Connection lVlodule (106) decrypts the IP :address using
it's built-in symmetrical
key and establishes a secure connection between the sender's proxy ( 102) and
the receiver's proxy
(302). The sender's EncryptionlDecryption lVlodule (105) then decrypts all of
the messages in the
145 send'er's OIVIQ (104) that are destined to. the receiver using the
sender's personal decryption lcey. The
sender's Encryption/Decryption Module (105) then re-encrypts each message
using the receiver's
public key and transmits each message to the .receiver's proxy (302) via the
secure channel established
between the sender's P2P Connection Module (1;06) and the receiver's P2P
Connection Module (306).
The receiver's Encryption/Deeryption Module (305) then decrypts each message
using the receiver's
150 private decryption key and confirms to the sender's proxy ( 102) that it
has successfixlty received each
message. Once all messages have been transmitted, the receiver's P2P
Connection Module (306)
terminates the secure connection between he sender and receiver. The sender's
proxy (102) finishes by
securely deleting the sent messages from the sender's OMQ, ( 104) and the
sender's public encryption
key. The receiver's proxy (302) finishes by forwarding (3) the decrypted email
messages to the inbox
155 of the receivers preferred evil software: (301)
BRIEF DESCRIPTION QF THE DRAWINGS
FIG: 1 is a schematic diagram showing ',the main components of the present
invention;
FIG. 2 is a schematic diagram that shows the functionality of the present
invention;
FIG. 3 is a functional block diagram of the preferred embodiment of the
present invention;
I60 FIG. 4, 5 & 6 are- flow diagrams that describe the installation of the
proxy software onto the users
computer and the process used by the user to validate heir email address(es);
FIG. 7 is a flow diagram that describes the preferred embodiment of validating
an email address, and;
FIG. 8 to 13 are flow diagrams that descn'bes how secure email is sent and
received in accordance with
preferred embodiment of the invention:
165
_6-

CA 02390817 2002-06-28
165 DESCRIPTION OF TI3E PREFERRED EMBODIlI!IENT
Before turning to the figures; it will be useful to review the basic
principles of cryptography. Cxenerally
speaking there are two classes : of cryptographic algorit>~ms: symmetric key
cryptography and
asymmetric key cryptography. The keys themselves are typically large numbers
generated from
complex mathematical algorithms: These keys are used to encrypt and/or decrypt
messages:
170 Symmetric key cryptography uses a single key to both encrypt and decrypt a
message. A message
encrypted with a symmetric key can only be decrypted by that same key. For
example, if a sender
encrypts. a message with a symmetric key and sends the encrypted message to a
recipient, the recipient
can decrypt the message only if he possesses the same key that the sender used
to encrypt the message.
Asymmetric key encryption, more commonly called public-keys encryption,
involves a pair of keys - a
175 public key and a private key. Once a user has generated a key pair, the
user typically keeps the private
key secret but publishes the corresponding public key. The public key and the
private key are
mathematically related so that one key can decrypt a message encrypted by the
other key. However, the
mathematical relationship between the keys is su~ciently complex that it is
computationally infeasible
to derive one key given the other., Thus, if a sender wants to send a message
to a recipient in a manner
180 such that only the recipient can read the message, the sender can encrypt
the message with the
recipient's public key. Since only the recipieixt's private key can decrypt
the message, the sender can be
assured that only the recipient can read the message; assuming that the
recipient is the only one with
access to the private key.
Turning no'w t6 the figures; FIG. 1 is a schematic diagraiii representing the
three' main components of
185 the fully functional; moderately secure; non-centralized email
transmission and address validation
process, including the sender (I00) the email Security Service (200) and the
receiver (300). The sender
( 100) wants to send email in a secure and, private manner and wants
reasonable assurance that the
person who receives the message is the person the email was sent to. The
receiver (300) wants
reasonable assurance that the email they receive has not been read by anyone
else and that the message
190 is from the owner of the email address that the message was sent from. The
email Security Service
(200) provides validation of email ;addresses used by the sender (100) and
receiver (300), and
information about what users have a validated email address:

CA 02390817 2002-06-28
It should be noted that the role of the sender ( 100) and receiver (300) may
be reversed. In addition
senders and receivers could represent individuals or other entities such as a
business, Internet': Service
195 Providers ("ISP") or Exnail Service Providers ("ESP"). It should also be
noted that the sending or
receiving systems may be a Personal Computer ("PC") or a server used to queue,
send, receive and
hold email. It should also be noted that there may be one-to-one, one-to-many
and many-to-one
relationships between sending and receiving systems.
FIG: 2 is schematic diagram that provides ~ overview of how email addresses
are validated and how
200 email is sent using a secure P2P connection and public key cryptography.
Lets begin with the sender
(100) who wishes to send an email message to the receiver.' (300) The sender
composes and sends
email messages in the usual manner using their preferred email software. (10i)
The sender's proxy
. , . :( 102) .intercepts. the outgoing .email message and parses :,out all of
the exnail addresses in the To, CC;
and BCC fields and submits a: query via the Internet (4; 8) for each ema;il
address to the Addresses
205 Validation Server ("AVS") (202) to determine which addresses have been
validated by the address
owner using the email validation process ,(204). The AVS (202) sends a reply
(9, 5) to the sender's
proxy (102) that includes all email addresses that have been validated. The
sender's proxy (102)
prepares and sends a conventional email message via an ESP (4, 7, 6, 12) to
each validated email
address that includes the sender's Symmetrically encrypted IP address. The
receiver's proxy (302)
210 receives the email message and decrypts the IP address arzd uses the IP
address to establish a secure, bi-
directional P2P connection between the sender's proxy (102) and the receiver's
proxy (302). ( 13; 5, 4,
12) Once a direct connection is established between the sender's proxy ( 102)
and the receiver's proxy,
(302) the receiver's proxy (302) sends the receiver's public key to the sender
via the secure channel.
.. ~..: . , _ ... w (1~,.=s~ Th$: sender's.~roxy.(502) then.uses«the
receiver's public~key to enc- tall-,of the messa es~~
rfP g
215 destined to the receiver: The encrypted email messages are then sent to
the receiver via the secured
channel. (4, 12) The receiver's proxy (302) decrypts the received messages)
using the receiver's
private decryption key and conf~rrns the successful receipt and decryption of
the messages to the
sender's proxy. (102) (13, 5) The receiver's proxy (302) then closes the P2P
connection between the
sender and receiver, ( 13, 5; 4; 12). arid forwards the decrypted messages to
the receiver's preferred
220 email software. (301)
Email addresses are validated using an email based validation process wherein
the user validates each
email address that they wish to send secure eW ail with by connecting (4, 11)
to the email security

CA 02390817 2002-06-28
service's {200) email validation web page (201) and entering the ernail
address they wish to have
validated. In addition to the email address entered by the user,;the users
proxy (102) also provides it's
225 encrypted GUID (which is, generated v~hen the user installs the proxy
software onto their computer) to
the email validation process (204) via the validation webpage. (201) The email
validation process then
validates the email address by generating a validation code and emailing it
using conventional email
protocols to the email address that was entered into the email validation
webpage. (10; 7, 6, 5) When
the user receives the email message they are instructed to enter the code into
their proxy ( 102)
230 whereupon the proxy (102) sends the entered code and it's GUID to the
email validation process (204)
{4, 14) to confirm the validity of the code and validate that the user has the
authority to send and
receive email messages using the email address.: The process concludes when
the email validation
process (204) sends (15} the validated email address to the AVS. (202) ,
FIG: 3 is'a functional block diagrarri of the preferred embodiment of the
system as shown in FIG. 1 and
235 2. In this embodiment each of the Sending ( 100) and Receiving (300)
systems includes a Configuration
Module (103, 303); Outbound Message Queue ("OMQ°') (104;.304),
EncryptionlDeeryption Module
( 105, 305), and a Peer-To-Peer Connection Module ( l Ob, 306), all of which
may communicate with
each other within the proxy software. In the preferred embodiment each of the
modules are
implemented as software, but can also be implemented as hardware and/or
firmware. Examples of
240 sending and receiving systems ( 100, 300) may include; but are not limited
to desktop computers,
portable computers, servers, PpAs, wireless devices and other digital devices.
The Email Security Service (200) includes a Security Service Website (201),
Email Validation Module
(204), Proxy Registration Module (205), Administration Module 202), Validation
Database 203 and
...,~F ,....,::. . =,. .. ~ , .,(
~ ;F4~:~ .., , , ,. , ..,~ y, ,. ,
Address Validation Server ("AVS") (202). All of which may communicate with
each other. In the
245 preferred embodiment, each of the modules are implemented as software, but
can also be implemented
as hardware and/or firmware. An example of an implementation of an Email
Security Service (200)
would include server software running on LTNI~, Linux, Windows NT/20UU/XP or
Sun Solaris
systems.
The system. outlined in Fig. 3 generally operates in a manner described by the
flow charts illustrated in
250 Fig. 4 to Fig 13, which will be described below.

CA 02390817 2002-06-28
Turning now to Fig 4., the process begins with a user vvho wants to send and
receive secure email.
They may learn about this new email security system from friends and
acquaintances that have already
installed the proxy onto their personal computers, or from an email message
asking the user ao install
the proxy so that they, can receive a secure message from a user that already
has the proxy installed. As
255 a result, they decide that they want to install the proxy and download the
software from any one of the
many software distribution hubs on the Internet, or directly from the email
Security Service's own
website. '
During installation a GUID is generated (404) that uniquely identifies the
proxy (1o2, 302) installation.
The process embeds the encrypted GUID into a URL ("UniformResource Locator")
(408), launches
260 the users browser with the URL direeting the user to an email vaiidation
webpage (406) hosted by the
._ . _.. . ~ _ ._ _ Seourityn Servace: _(200)_. The. user.enters..the.:email
address that:.they wish to. validate .into the validation.
webpage and submits the page to the Security Service. {200): (420) The users
email address and the
encrypted GUID are submitted to the address validation module (204) and a
validation request
confirmationrnessage is displayed in the users browser,telling the user to
expect an email message with
265 a validation code for the email: address that they provided. (412) The
user is then provided with the
option to validate additional exnaal addresses. (414) Jumping forward to Fig:
7 now, the Email
Validation module decrypts the QUID (505) and randomly generates an email
address validation code.
(510) The module saves the validation code, email address and GUID to the
validation database (203).
(515) The module generates and sends an email message to the email address
that was submitted for
270 validation that includes the validation code and instructions for
installing the code into the proxy. ( 102,
302) (520) If the validation email message bounces (returned as an invalid
address) (525), then the
. . ;. ;,:,,. p~a~s~>updates- he entry=in-the~validation-
.database(203).ao.:indieaxe~that the emarl address was invalid. _,
(530)
Continuing now with Fig. 5 the install process continues with the user
registering their software with
275 the Security Service. (200) (418) Once the proxy ( 102; 3U2) has been
installed and registered,' (420) the
process continues with the user being provided with the option (422) 'to
configure the software using a
step-by-step wizard style configuration process, (424) or an advanced;
dialogue based configuration
process: (432) During the configuration process the user is asked if they base
received their email
address validation eode(s). (426) If not, they are told that while they can
complete the installation, they
280 will not be able to send or receive secure email messages until hey enter
at least one validation code.
10_

CA 02390817 2002-06-28
(434) If they have received their validation cot~e(s) they are instructed to
enter the validation codes into
the proxy. (102, 302) (428) The proxy (102, 302) in turn sends each entered
validation code along with
the proxy's GUID to the email Security Serviee. (2UU) (430) The email
Validation Module (204)
submits a query to the validation database (2U3) to determine if the submitted
code and: proxy GUID
285 matches the information contained in the database: (436) If there is a
matching code and corresponding
matching GLJID in the validation database (203); (438; 440) then the
Validation Module adds the
validated email address to the AVS (202) (442) and ends a validation-accepted
message to the proxy
(102, 302) (444) whereupon the proxy (102, 302) enables the validated email
address allowing
authorized users to send and receive secure: email messages using the address.
(446, 448) If there is no
290 match for the submitted code and/or GUIDE the Validation Module (204)
notifies ,the proxy ( 102, 302)
that the entered codes) were invalid and the proxy (1U2, 302) advises the user
that the codes they
.. ~ h v."li . _._
added vvilt riot Work: ~' (450, 52) The user is t en o~'ered the ;option to
try' and a date ~ariotlier einail
address. (454)
Moving now to Fig. 8 we will now describe how email is sent and received in a
secure manner using
295 the preferred embodiment of~fhe invention. The user (the "sender")who
wishes to send a secure email
message prepares and sends their message using their preferred email software.
(602) If the-proxy ( 102)
has been enabled to send secure email, (604) it will monitor all outbound
email traffic intercepting each
outbound message and parsing out all of the email addresses contained in the
From, To, CC, and BCC
fields. (606) The proxy (102) then determines if the email address in the From
field has been validated:
300 (608) If it has not, then the sender is asked if they want to validate the
email address so that the
message can be sent in. a secure manner. (61:8) If the ender does not wish to
validate the email address,
:,, ~. ..
c .3n*: ..
C
vL _
:_~~.:x~.,
f
thenal~messa evis=~s~nt:.x~,.all~,:ofahe~~addr~essees~.usin :corrventlanal-
email; rot~eols:. 6~6E~~ f- e< t, :,.-,,;~
g g p ( ) I th sender
wants to validate the email address so that the message is sent in a secure
manner; then the proxy ( 102)
encrypts the message with the sender's personal encryption key; (to protect
the confidentiality of the
305 message while the proxy (102) validates :the sender's email address and
prepares the message for
transmission) and stores the encrypted message on the sender's computer. (100)
At the same time the
proxy (102) creates an entry for each addressee that the message is destined
to in the OMQ. (104) (621)
The proxy (102) then launches the email validation process and the sender
completes the validation
process as previously described. (622)
_11_

CA 02390817 2002-06-28
310 If the email address in the From :field has been validated then the proxy
( 102) encrypts the message
with the sender's personal encryption key (to protect the confidentiality of
the message while the proxy
( 102) prepares the message , for transmission) and stores he encrypted
message on the sender's
computer: ( 100) At the same time the proxy ( 102) creates an entry for each
addressee that the message
is destined to in the OMQ. ( L04) (610)
315 The proxy (102) then sends a request to the AVS (202) to determine the
validation status of the
addresses in the To, CC and BCC fields. (612) If there are any addresses that
have not been validated,
(614) and if the sender has configured the proxy (102) to automatically send
email messages to un-
validated addresses in an unsecured manner; (624) hen the proxy (102) decrypts
a copy of the message
using the sender's personal decryption key (623) and sends the message to all
non-validated addressees
.. .. .. : 320 . . using. con~rentional .:,emait ..piotoeols.: (616) The .
proxy (102). then :.updates . each ,address in the . QMQ
( 104) to indicate that what'addresses the message was sent to using
conventional email. (615)
If the sender has configured the proxy (102) to notify them when there are
messages destined to. non-
validated addressees; then the proxy ( 102) displays a message, to the sender
advising them that there are
messages for non-validated addresses in the OMQ. (104) (638) The sender
reviews the addressees in
325 he OMQ (104) and flags messages that may be sent in an unsecured manner.
(64.0) The proxy (102) in
turn regularly monitors the OlVIQ ( 104) for messages that have been reviewed
by the sender. If the
sender has flagged messages that can be sent in an unsecured manner, ,(642)
then the proxy ( 102)
decrypts the message using the sender's personal decryption key (630) and
sends the message to all of
the flagged addressees using conventional email protocols: (632)
< r _ ;,.~"" .
... ~. . .
s;:. -..~.,
Y M. ~ v .
s ~
r~ 4~.
330 ~ 'If the sender ~ lia's fla '~ ed~ ad ~ s th t u~ t ~ s t '
gg dyes es a m s be en m' a secure niaiuier,~ (~44~ ; then the proxy ( 102)
uses a pre-defined message template that was created by the sender when they
installed the proxy ( 102)
software onto their computer to generate and send a conventional email message
that advises the
receiver that the sender wants to send them a secure xriessage and in order to
receive the message they
must install and configure the proxy (302) and validate their email address.
(646, 648) The proxy (102)
335 then begins to regularly monitor the AVS (202) for the receiver's
validated email address. (649) If the
message sent to the receiver bounces, (650) the proxy ( 102) updates the entry
in the OMQ ( 104) to
indicate that the receivers email address is invalid and discontinues
monitoring the AVS (2Q2) for the
receiver's address: (660)
-12-

CA 02390817 2002-06-28
If the sender has specified that the message should be sent in an unsecured
manner and if the receiver
340 has not responded to.the proxy installation and validation, reqpest after
a preset period of time, (654)
then the proxy (102) will discontinue monitoring the pMQ (104) for the
receivers validated ernail
address, (662) decrypt (663) and send the message to the receiver using
conventional email protocols,
(664) and updates the OMQ (104) to indicate that the receiver never validated
their email address and
that the message was sent in an unsecured manner using conventional email.
(665) If the sender
345 specified than the rriessage must be sent in a secure manner, then the
proxy ( 102) simply continues to
monitor the AVS (202) for an indefinite period of time for the receiver to
validate their email address.
(658)
If the receiver's email address is added to the AVS (202)' indicating that the
receiver has installed and
.... eonfigured,the:groxyr,(3.02) hen the ender's proxy.(102) dueries the
operating ystem for it's currently .
350 assigned IP address:' (626) The IP address is ,then encrypted by the proxy
,(102) using a built in
symmetrical encryption algorithm and encryption key. (628) The proxy (102)
then generates a
conventional email message (666) that includes: 1:) a proxy ID code in the
subject line that is used by
the receivers proxy (302) to intercept messages intended- for the proxy (302)
(668); 2.) The sender's
symmetrically encrypted IP address, and (670); 3:) a human readable message in
the body of the email
355 that explains what the emaii is about in case the receivers proxy (302)
fails to intercept the message, or
in case the receiver has- removed the proxy (302) from their computer. (672)
The proxy ( 102) then
sends fhe email message to the receiver's proxy (302) using conventional email
protocols: (674);
The receiver's proxy (302) monitors each incoming email message for an ID code
in the Su>;ject field
that tells the proxy (302) that the message was sent by anther proxy. (676) If
the subject field contains
360 a proxy ID code, then the receiver's proxy (302) intercepts the message,
preventing it from being
forwarded to the receivers normal email software. (680) The receiver's proxy
(302) then parses the
message and decrypts the IP address using its built in symmetrical decryption
algoritlun and decryption
key. (683) The receiver's proxy (302) then attempts to establish a secure P2P
connection with the
sender's proxy (102) using the IP address provided by the sender's proxy.
(i02) (684) If the receiver is
365 unable to establish a secure connection with the sender's proxy, (102)
(686) the receiver's, proxy (302)
composes 'and sends a conventional email message .that contains a proxy 'ID
code in the subject line,
asking the sender's proxy (102) tore-send it's current IP address. (694) This
process will be repeated
until the receiver's proxy (302) is able to establish a secure connection with
the sender's proxy; (102)
_13_

CA 02390817 2002-06-28
or until the number of iterations reaches a value established by the sender
whereupon the ender's
370 proxy (102) will either send the message in an unsecured manner, or flags
the message in the ender's
OMQ ( 104) as not sent due to P2P connection failure. Once a secure P2P
connection has been
established between the receiver's proxy (3U2) and the sender's proxy, ( 102)
the receiver's proxy (302)
transmits the r~eiver's current public encryption key to the sender's proxy
(102) (688) : and the
sender's proxy ( 102) confirms receipt of the receiver's -public key. (690)
The sender's proxy ( 102) then
375 decrypts all email messages that are destined to the r~eiver using the
sender's private. decryption key,
(692) and then re-encrypts each message destined to the receiver with the
receiver's public encryption
key. (696) The sender's proxy (102) then transmits all encrypted messages o
the receiver's proxy (302)
via the secure P2P channel: (698) The receiver's proxy (302) then decrypts
each received message
using the receiver's private decryption key (740) and confirms the successful
delivery of each message
..,~..~. ..~.... , .
380-_ .:_;~o...he~.>:. .d s . ,
t sen er -proxy. ('102) (704) Tfa message~vi!as notauccessf"'ully recei~ed~and
neeiypted;'(702) then
the receiver's proxy (3U2) will send a request to the sender's proxy (102) via
the secure P2P channel; to
re-transmit the message. (710) Once all of the messages have been successfully
transmitted and
decrypted, the receiver's proxy (302) closes the P2P connection (712) and pass
all of the decrypted
email messages on to the receivers preferred email software. (714) Once the
P2P connection has been
385 closed-by the receiver's proxy (302), the sender's proky (102) updates
each-entry in the Q1VIQ (104)
indicating what messages were successfully sent in a secure manner to the
receiver. (706) The sender's
proxy (102) then securely deletes the receiver's public keyfrom the sender's
computer. (?08)
- 14-

Dessin représentatif
Une figure unique qui représente un dessin illustrant l'invention.
États administratifs

2024-08-01 : Dans le cadre de la transition vers les Brevets de nouvelle génération (BNG), la base de données sur les brevets canadiens (BDBC) contient désormais un Historique d'événement plus détaillé, qui reproduit le Journal des événements de notre nouvelle solution interne.

Veuillez noter que les événements débutant par « Inactive : » se réfèrent à des événements qui ne sont plus utilisés dans notre nouvelle solution interne.

Pour une meilleure compréhension de l'état de la demande ou brevet qui figure sur cette page, la rubrique Mise en garde , et les descriptions de Brevet , Historique d'événement , Taxes périodiques et Historique des paiements devraient être consultées.

Historique d'événement

Description Date
Inactive : Symbole CIB 1re pos de SCB 2022-01-01
Inactive : CIB du SCB 2022-01-01
Inactive : CIB expirée 2022-01-01
Inactive : CIB expirée 2022-01-01
Inactive : CIB expirée 2022-01-01
Inactive : CIB expirée 2013-01-01
Inactive : CIB de MCD 2006-03-12
Inactive : CIB de MCD 2006-03-12
Inactive : Lettre officielle 2005-08-09
Demande non rétablie avant l'échéance 2005-06-28
Le délai pour l'annulation est expiré 2005-06-28
Réputée abandonnée - omission de répondre à un avis sur les taxes pour le maintien en état 2004-06-28
Inactive : Lettre officielle 2004-01-12
Inactive : Incomplète 2004-01-02
Inactive : Page couverture publiée 2003-12-28
Demande publiée (accessible au public) 2003-12-28
Inactive : Conformité - Formalités: Réponse reçue 2003-12-15
Inactive : Correspondance - Formalités 2003-12-15
Inactive : Demandeur supprimé 2003-09-24
Inactive : Inventeur supprimé 2003-09-24
Inactive : Inventeur supprimé 2003-09-24
Inactive : Correspondance - Formalités 2003-09-18
Inactive : CIB attribuée 2002-08-22
Inactive : CIB attribuée 2002-08-22
Inactive : CIB en 1re position 2002-08-22
Inactive : Certificat de dépôt - Sans RE (Anglais) 2002-08-02
Demande reçue - nationale ordinaire 2002-08-01

Historique d'abandonnement

Date d'abandonnement Raison Date de rétablissement
2004-06-28

Historique des taxes

Type de taxes Anniversaire Échéance Date payée
Taxe pour le dépôt - petite 2002-06-28
2003-12-15
2005-07-14
Titulaires au dossier

Les titulaires actuels et antérieures au dossier sont affichés en ordre alphabétique.

Titulaires actuels au dossier
RON W. WARRIS
SCOTT P. WOYNARSKI
DONNA M. RAE
Titulaires antérieures au dossier
S.O.
Les propriétaires antérieurs qui ne figurent pas dans la liste des « Propriétaires au dossier » apparaîtront dans d'autres documents au dossier.
Documents

Pour visionner les fichiers sélectionnés, entrer le code reCAPTCHA :



Pour visualiser une image, cliquer sur un lien dans la colonne description du document (Temporairement non-disponible). Pour télécharger l'image (les images), cliquer l'une ou plusieurs cases à cocher dans la première colonne et ensuite cliquer sur le bouton "Télécharger sélection en format PDF (archive Zip)" ou le bouton "Télécharger sélection (en un fichier PDF fusionné)".

Liste des documents de brevet publiés et non publiés sur la BDBC .

Si vous avez des difficultés à accéder au contenu, veuillez communiquer avec le Centre de services à la clientèle au 1-866-997-1936, ou envoyer un courriel au Centre de service à la clientèle de l'OPIC.


Description du
Document 
Date
(yyyy-mm-dd) 
Nombre de pages   Taille de l'image (Ko) 
Dessin représentatif 2002-09-08 1 10
Page couverture 2003-12-01 2 48
Description 2002-06-27 14 1 121
Revendications 2003-12-14 2 109
Dessins 2002-06-27 13 476
Abrégé 2002-06-27 1 38
Revendications 2004-07-27 2 109
Certificat de dépôt (anglais) 2002-08-01 1 173
Demande de preuve ou de transfert manquant 2003-07-01 1 101
Avis de rappel: Taxes de maintien 2004-03-29 1 118
Courtoisie - Lettre d'abandon (taxe de maintien en état) 2004-08-22 1 174
Deuxième avis de rappel: taxes de maintien 2004-12-29 1 117
Avis de rappel: Taxes de maintien 2005-03-29 1 119
Correspondance 2002-08-04 1 37
Correspondance 2002-08-04 1 33
Correspondance 2003-07-01 1 49
Correspondance 2003-09-17 5 114
Correspondance 2004-01-01 1 24
Correspondance 2003-12-14 3 135
Correspondance 2004-01-11 1 16
Correspondance 2004-03-29 1 52
Correspondance 2004-08-22 1 42
Correspondance 2004-12-29 1 56
Correspondance 2005-03-29 1 70
Correspondance 2005-08-08 1 19
Taxes 2005-07-13 2 41