U.S. patent application number 11/618241 was filed with the patent office on 2008-07-03 for system and method for secure and/or interactive dissemination of information.
This patent application is currently assigned to Ceelox Inc.. Invention is credited to DONALD R. PETERSON, ERIX PIZANO.
Application Number | 20080162527 11/618241 |
Document ID | / |
Family ID | 39585462 |
Filed Date | 2008-07-03 |
United States Patent
Application |
20080162527 |
Kind Code |
A1 |
PIZANO; ERIX ; et
al. |
July 3, 2008 |
SYSTEM AND METHOD FOR SECURE AND/OR INTERACTIVE DISSEMINATION OF
INFORMATION
Abstract
An interactive information dissemination system includes a media
server (210) for receiving a plurality of media elements and
storing the media elements in a database. A sender client (200)
enables a first user to identify message data, a recipient
identifier, and a media element from the database of media
elements. A recipient client (202) presents the media element to a
second user associated with the recipient identifier. The recipient
client (202) further presents the message data to the second user
when the second user performs a predetermined action, such as
submitting authentication information or requesting the message
data, to receive the message data. The message data may be secured
by requiring sender and recipient authentication, and by encoding
the data using a private encoding key and data package identifier
managed by a main server (206) and a key server (208).
Inventors: |
PIZANO; ERIX; (TAMPA,
FL) ; PETERSON; DONALD R.; (LEAWOOD, KS) |
Correspondence
Address: |
HOVEY WILLIAMS LLP
10801 Mastin Blvd., Suite 1000
Overland Park
KS
66210
US
|
Assignee: |
Ceelox Inc.
|
Family ID: |
39585462 |
Appl. No.: |
11/618241 |
Filed: |
December 29, 2006 |
Current U.S.
Class: |
1/1 ;
707/999.102; 707/E17.005 |
Current CPC
Class: |
G06Q 30/0251 20130101;
G06Q 10/107 20130101; G06F 21/335 20130101; G06Q 20/3674 20130101;
G06F 21/6209 20130101; G06Q 40/00 20130101; G06Q 20/382 20130101;
G06Q 30/02 20130101; G06Q 30/0273 20130101; G06F 21/10 20130101;
H04L 51/063 20130101 |
Class at
Publication: |
707/102 ;
707/E17.005 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method of providing an information dissemination service
comprising: receiving a plurality of media elements from a first
user and storing the plurality of media elements in a computer
database; receiving instructions from a second user selecting one
of the plurality of media elements; receiving message data from the
second user; presenting the selected media element to a third user;
presenting the message data to the third user only after presenting
the selected media element to the third user and only after the
third user performs a predetermined action; and charging a fee to
the first user.
2. The method as set forth in claim 1, further comprising charging
a fee to the first user when the second user selects one of the
plurality of media elements received from the first user.
3. The method as set forth in claim 1, each of the plurality of
media elements being chosen from the group consisting of an image,
an audio element, and a video element.
4. The method as set forth in claim 1, further comprising hiding
the message data in the selected media element, communicating the
combined message data and media element to the third user, and
presenting the combined message data and media element to the third
user.
5. The method as set forth in claim 4, further comprising
extracting the message data from the media element only after
presenting the combined message data and media element to the
second user and only after the second user performs the
predetermined action.
6. The method as set forth in claim 1, the predetermined action
involving requesting to view the message data.
7. The method as set forth in claim 1, further comprising
collecting information about the third user and providing the
information about the third user to the first user.
8. The method as set forth in claim 7, further comprising charging
a fee to the first user for the information about the third
user.
9. A method of providing a secure data transfer service comprising:
receiving transfer data and a recipient identifier from a first
user; creating an encoding key, encoding the transfer data using
the key, and associating the encoded transfer data with a secure
package identifier; receiving a user identifier and a secure
package identifier from a second user; providing the key to the
second user only if the user identifier matches the recipient
identifier and if the secure package identifier received from the
second user matches the secure package identifier associated with
the encoded data; and charging a fee to one of the first user and
the second user.
10. The method as set forth in claim 9, further comprising charging
a fee to the first user each time transfer data is received from
the first user.
11. A method of providing an information dissemination service
comprising: receiving a first plurality of media elements from a
first user and storing the first plurality of media elements in a
computer database; receiving a second plurality of media elements
from a second user and storing the second plurality of media
elements in the computer database; receiving instructions from a
third user selecting a media element from the first plurality of
media elements or the second plurality of media elements; receiving
message data and a plurality of recipient identifiers from the
third user, the plurality of recipient identifiers identifying a
plurality of recipients; presenting the selected media element to
each of the plurality of recipients; for each of the plurality of
recipients, presenting the message data to the recipient only after
presenting the selected media element to the recipient and only
after the recipient performs a predetermined action; charging a fee
to the first user when the third user selects one of the first
plurality of media elements received from the first user; and
charging a fee to the second user when the third user selects one
of the second plurality of media elements received from the second
user.
12. The method as set forth in claim 11, each of the plurality of
media elements being chosen from the group consisting of an image,
an audio element, and a video element.
13. A method of providing an information dissemination service
comprising: receiving instructions from a first user selecting one
of a plurality of media elements; receiving message data from the
first user; presenting the selected media element to a second user;
presenting the message data to the second user only after
presenting the media element to the second user and only after the
second user performs a predetermined action; and charging a fee to
the first user.
14. The method as set forth in claim 13, each of the plurality of
media elements being chosen from the group consisting of an image,
an audio element, and a video element.
15. The method as set forth in claim 13, further comprising hiding
the message data in the selected media element, communicating the
combined message data and media element to the second user, and
presenting the combined message data and media element to the
second user.
16. The method as set forth in claim 15, further comprising
extracting the message data from the media element only after
presenting the combined message data and media element to the
second user and only after the second user performs the
predetermined action.
17. The method as set forth in claim 13, the predetermined action
involving requesting to view the message data.
Description
RELATED APPLICATION
[0001] The present application is a nonprovisional patent
application and relates to earlier-filed U.S. nonprovisional patent
application titled "SYSTEM AND METHOD OF SECURE ENCRYPTION FOR
ELECTRONIC DATA TRANSFER", Ser. No. 11/538,867, filed Oct. 5, 2006.
The identified earlier-filed application is hereby incorporated by
reference into the present application.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] Embodiments of the present invention relate to the field of
interactive and secure dissemination of information. More
particularly, embodiments of the present invention involve a system
and method of associating message data with a media element, such
as an advertisement, communicating the message data and the media
element to a designated recipient, and presenting the message data
to the recipient only after the media element has been presented to
the recipient.
[0004] 2. Description of Prior Art
[0005] Providing secure transfers of encoded data over the Internet
and other communications networks has become increasingly
important. One method of securing data transfers involves
encrypting the transfer data using either symmetric (private
key/private key) or asymmetric (public key/private key)
architectures. While data encryption can be an effective method of
securing data communicated via the Internet, prior art encryption
systems suffer from various problems and limitations.
[0006] Symmetric encryption uses a single, unique encryption key to
encrypt and decrypt each secure data package. However, symmetric
encryption requires the sender to communicate the encryption key to
the recipient electronically, which can compromise the security of
the transaction, or by a non-electronic method, which is too
cumbersome for practical use.
[0007] Asymmetric encryption, in contrast, requires the use of both
a public key and a private key, wherein multiple secure data
packages are encrypted using the same public key. This architecture
can compromise the security of encrypted data because if an
unintended user discovers the private key used to decrypt an
encrypted data package, the user will also be able to decrypt all
of the data packages encrypted using the public key, which may be a
large number of data packages, including previously-sent data
packages as well as data packages created in the future.
[0008] Furthermore, systems that employ robust asymmetric or
symmetric encryption are often difficult for end user's to learn or
require users to dedicate a substantial amount of time and effort
to encrypting and decrypting each message, resulting in systems
that are inefficient for practical use. Such systems also require
users to commit to a single, particular mode of data communication
or even to a particular software application, whether online or
offline, synchronous or asynchronous, web-based or
client-based.
[0009] Advertizing via electronic communication mediums, such as
the Internet and wireless telephone networks, has become
increasingly important as these communication mediums have grown in
popularity and use. Unfortunately, some advertising practices have
diminished the effectiveness of advertising over these mediums.
Mass mailings of advertisements via electronic mail ("email"),
sometimes referred to as junk email or "SPAM," for example, have
been used so extensively that many people ignore the
advertisements. Consequently, companies who may otherwise benefit
from using email advertisements have sought other forms of
advertizing.
[0010] Accordingly, there is a need for an improved system of
secure data transfer and information dissemination that does not
suffer from the problems and limitations of the prior art.
SUMMARY OF THE INVENTION
[0011] The present invention provides a system and method for
enabling an interactive information dissemination system. The
information dissemination system is operable to enable a first user
to identify message data, a recipient identifier, and a media
element. The media element is presented to a second user associated
with the recipient identifier. The second user performs a
predetermined action, such as submitting authentication information
or requesting the message data, to receive the message data. The
message data is presented to the user after the user performs the
predetermined action.
[0012] A plurality of media elements may be stored in a database
and associated with one or more sponsors. The first user identifies
a media element from the database, and a fee may be charged the
sponsor associated with each media element selected by a user.
Because the media element is associated with a message to the
recipient, the media element may be communicated to recipients via
email with greater effectiveness than simple advertisements. Thus,
companies unwilling to use mass email advertising (SPAM) campaigns
may be willing to advertize according to principles of the present
teachings.
[0013] An exemplary method of associating a message with a media
element involves the use of steganography, or hiding a first
message within a second, larger one in such a way that others can
not discern the presence or contents of the first message.
Traditionally, steganography involves hiding a message within an
image by, for example, changing the least significant bits of the
image data to be the message bits. The present invention
contemplates a broader range of implementations including, for
example, associating messages with various types of media elements
including images, audio files, video files, animations, and so
forth.
[0014] These and other important aspects of the present invention
are described more fully in the detailed description below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] An embodiment of the present invention is described in
detail below with reference to the attached drawing figures,
wherein:
[0016] FIG. 1 is an exemplary computer network operable to
implement a computer program embodying principles of the present
invention;
[0017] FIG. 2 is a block diagram illustrating an exemplary
architecture of the computer program of FIG. 1, wherein the
architecture comprises various software components including a
sender client, a recipient client, a main server, and a key
server;
[0018] FIG. 3 is a flow diagram of exemplary steps performed by the
sender client of FIG. 2;
[0019] FIG. 4 is a flow diagram of exemplary steps performed by the
recipient client of FIG. 2;
[0020] FIG. 5 is a diagram illustrating an exemplary protocol
executed by the software components of FIG. 2;
[0021] FIG. 6 is a diagram illustrating an exemplary data structure
created and maintained by the key server of FIG. 2, wherein the
data structure links a secure package identifier with various
attributes of a corresponding secure data package;
[0022] FIG. 7 is a diagram illustrating in more detail a portion of
the data structure of FIG. 6;
[0023] FIG. 8 is a diagram illustrating a first alternative
architecture of the computer program of FIG. 1;
[0024] FIG. 9 is a diagram illustrating a second alternative
architecture of the computer program of FIG. 1;
[0025] FIG. 10 illustrates a user interface of a conventional email
application presenting an interface element corresponding to either
the sender client or the recipient client of FIG. 2;
[0026] FIG. 11 is an interface of a conventional computing
environment presenting a window with a text field and an icon
corresponding to either the sender client or the recipient client
of FIG. 2;
[0027] FIG. 12 is the user interface of FIG. 11 illustrating
highlighted text in the text field and presenting a context menu
associated with the icon;
[0028] FIG. 13 is the user interface of FIG. 11 presenting a window
for prompting a user to submit identification and authentication
information;
[0029] FIG. 14 is the user interface of FIG. 12 presenting a window
for enabling a user to select one or more recipients of transfer
data;
[0030] FIG. 15 illustrates a user interface of a conventional
computing environment illustrating a third embodiment of the sender
client and recipient client of FIG. 2 wherein the environment
presents a canvas for receiving an image file and a data transfer
file and wherein the environment presents an icon pertaining to the
sender client or recipient client of FIG. 2;
[0031] FIG. 16 is the user interface of FIG. 15 illustrating the
image file and the data transfer file placed within the canvas such
that the image file is visible within the canvas;
[0032] FIG. 17 is a block diagram illustrating a second exemplary
architecture of the computer program of FIG. 1, wherein the
architecture comprises various software components including a
sender client, a recipient client, a sponsor client, a main server,
a key server and a media server;
[0033] FIG. 18 is an exemplary user interface associated with the
media server of the architecture of FIG. 17;
[0034] FIG. 19 illustrates a plurality of exemplary data packages
created using the system architecture of FIG. 17; and
[0035] FIG. 20 illustrates a user interface of a conventional email
application presenting a two interface elements, each corresponding
to either the sender client or the recipient client of FIG. 17, a
first interface element associated with secure encryption and
transfer of information and a second interface element associated
with interactive dissemination of information.
DETAILED DESCRIPTION
[0036] FIG. 1 illustrates an exemplary computer network operable to
implement a computer program incorporating principles of the
present invention. The present invention relates to a system and
method of secure transfer and/or interactive dissemination of
information. The secure transfer involves encoding data and
associating the encoded data with an authorized recipient or group
of recipients, wherein only an authorized recipient is provided a
key for decrypting the message, and wherein both the sender and the
recipient must submit valid authentication information, such as
biometric information, before accessing the system. The interactive
dissemination involves associating message data with a media
element (such as an advertisement) and communicating the message
data and media element to a recipient such that the recipient is
exposed to the media element and must perform some action to
retrieve the message.
[0037] The present invention is especially well-suited for
implementation on a computer or computer network, such as the
computer 10 illustrated in FIG. 1 that includes a keyboard 12, a
processor console 14, a display 16, and one or more peripheral
devices 18, such as a biometric sensor, scanner, or printer. The
computer 10 is preferably part of a computer network, such as the
computer network 20 that includes one or more client computers
10,22 and one or more server computers 24,26 interconnected via a
communications system 28. The present invention may also be
implemented, in whole or in part, on a wireless communications
system including, for example, a network-based wireless transmitter
30 and one or more wireless receiving devices, such as a hand-held
computing device 32 with wireless communication capabilities. The
device 32 includes an input element 34, such as a biometric sensor,
touchscreen, or a keypad.
[0038] The present invention will thus be generally described
herein as a computer program. It will be appreciated, however, that
the principles of the present invention are useful independently of
a particular implementation, and that one or more of the steps
described herein may be implemented without the assistance of a
computing device.
[0039] The present invention can be implemented in hardware,
software, firmware, or a combination thereof. In a preferred
embodiment, however, the invention is implemented with a computer
program. The computer program and equipment described herein are
merely examples of a program and equipment that may be used to
implement the present invention and may be replaced with other
software and computer equipment without departing from the scope of
the present invention.
[0040] The computer program of the present invention is stored in
or on a computer-usable medium, such as a computer-readable medium,
residing on or accessible by a plurality of host computers for
instructing the host computers to implement the method of the
present invention as described herein. The host computers
preferably include one or more server computers, such as server
computer 24, and two or more network client computers, such as
computer 10. Portions of the program of the present invention
preferably run on each of the different computers, as explained
below. The computer program preferably comprises an ordered listing
of executable instructions for implementing logical functions in
the host computers and other computing devices coupled with the
host computers. The computer program can be embodied in any
computer-usable medium for use by or in connection with an
instruction execution system, apparatus, or device, such as a
computer-based system, processor-containing system, or other system
that can fetch the instructions from the instruction execution
system, apparatus, or device, and execute the instructions.
[0041] The ordered listing of executable instructions comprising
the computer program of the present invention will hereinafter be
referred to simply as "the program" or "the computer program." It
will be understood by those skilled in the art that the program may
comprise a single list of executable instructions or two or more
separate lists, and may be stored on a single computer-usable
medium or multiple distinct media. The program will also be
described as comprising various "code segments," which may include
one or more lists, or portions of lists, of executable
instructions. Code segments may include overlapping lists of
executable instructions, that is, a first code segment may include
instruction lists A and B, and a second code segment may include
instruction lists B and C.
[0042] A "computer-usable medium" can be any means that can
contain, store, communicate, propagate or transport the program for
use by or in connection with the instruction execution system,
apparatus, or device. The computer-usable medium can be, for
example, but is not limited to, an electronic, magnetic, optical,
electromagnetic, infrared, or semi-conductor system, apparatus,
device, or propagation medium. More specific, although not
inclusive, examples of computer-usable media would include the
following: an electrical connection having one or more wires, a
portable computer diskette, a random access memory (RAM), a
read-only memory (ROM), an erasable, programmable, read-only memory
(EPROM or Flash memory), an optical fiber, and a portable compact
disk read-only memory (CDROM). The computer-usable medium could
even be paper or another suitable medium upon which the program is
printed, as the program can be electronically captured, via for
instance, optical scanning of the paper or other medium, then
compiled, interpreted, or otherwise processed in a suitable manner,
if necessary, and then stored in a computer memory.
Secure Encryption for Electronic Data Transfer
[0043] The flow charts of FIGS. 3 and 4 and the diagram of FIG. 5
illustrate the functionality and operation of various elements of
an implementation of the present invention in more detail. In this
regard, some of the blocks of the flow charts may represent a code
segment of the program of the present teachings which comprises one
or more executable instructions for implementing the specified
logical function or functions. In some alternative implementations,
the functions noted in the various blocks may occur out of the
order depicted. For example, two blocks shown in succession may in
fact be executed substantially concurrently, or the blocks may
sometimes be executed in the reverse order depending upon the
functionality involved.
[0044] FIG. 2 illustrates an architecture of a first embodiment of
the present teachings implemented, for example, on the exemplary
computer network of FIG. 1. The embodiment illustrated in FIG. 2
broadly comprises the interaction of four separate software modules
including a sender client 36, a recipient client 38, a main server
40, and a key server 42. The sender client 36 and the recipient
client 38 are separate software applications running on separate
computers. However, the sender client 36 and the recipient client
38 are functionally identical, or substantially functionally
identical, and therefor each is operable to send as well as receive
transfer data. In other words, the sender client 36 is operable to
function as a recipient client when receiving a secure data
package, and the recipient client 38 is operable to act as a sender
client when sending a secure data package. Therefore, when
reference is made herein to the "client," the "clients," the
"sender client 36," or the "recipient client 38," it will be
understood that such reference applies to both the sender client 36
and the recipient client 38.
[0045] The sender client 36 of FIG. 2 may run on the computer 10 of
FIG. 1 and the recipient client 38 of FIG. 2 may run on the
computer 22 of FIG. 1, or vice versa. Alternatively, one of the
sender client 36 or the recipient client 38 may run on the wireless
handheld device 32, wherein a user may submit biometric information
via a biometric sensor 34 integral with or attached to the device
32. Furthermore, the main server 40 may correspond to the server
24, and the key server 42 may correspond to the server 26, or vice
versa.
[0046] FIG. 3 illustrates various steps performed by the sender
client 36 and FIG. 4 illustrates various steps performed by the
recipient client 38. FIGS. 3 and 4 illustrated various general
steps performed by the clients, while particular embodiments of the
sender client 36 and the recipient client 38 will be described
below in greater detail.
[0047] With particular reference to FIG. 3, the sender client 36
receives identification and authentication information from a
sender, as depicted in block 44. The identification information may
include a user name, an email address, or both and the
authentication information may include a password, biometric
information, or both. Biometric information is communicated to the
sender client 36 by a user in a convention manner, such as via a
biometric sensor 18 associated with the computer 10 or a biometric
sensor 34 associated with the wireless hand-held device 32. The
biometric information may include, but is not limited to,
fingerprint data, voice print data, retinal scan data, iris scan
data, facial characteristics, and behavioral characteristics, such
as signature data, captured and analyzed using conventional
hardware and processes known in the art. Furthermore, the biometric
data used by the claimed invention may be any combination of one or
more types of such biometric data.
[0048] The sender client 36 generates a key as depicted in block
46. The key is used to encode and decode transfer data, as
explained below in greater detail. Such encoding may take the form
of encryption, steganography, or both. For purposes of simplicity,
the encoding will be referred to herein as encryption, and the key
will be referred to as an encryption key. The sender client 36
generates a unique encryption key for each transaction, thereby
reducing the risk of compromising the contents of a large volume of
encrypted data.
[0049] As used herein, "transfer data" refers to data communicated
from one computer to another, such as from the sender client 36 to
the recipient client 38. Transfer data thus may be any type of data
including, for example, text, graphics, computer code, or files
associated with any type of computer application.
[0050] The sender client 36 assembles a list of recipients, as
depicted in block 48. The list includes identification information
corresponding to each recipient, such as an email address,
recipient name, or other recipient identifier such as a social
security number, anonymous number, or any combination thereof. The
sender client 36 may assemble list of recipients substantially
automatically by, for example, reading the contents of a "TO" field
of an email application. Alternatively, the sender client 36 may
prompt a user to submit a number of recipients to include in the
list, such as where the user selects a list of recipients from a
list or directly types each recipient into a data field. The "list"
of recipients may include any number of recipients, including as
few as one recipient or a very large number of recipients.
[0051] The sender client 36 communicates the sender identification
information, sender authentication information, encryption key, and
list of recipients to the main server 40, as depicted in block 50.
The sender client 36 receives a secure package identifier from the
main server 40, as depicted in block 52. As explained below in
greater detail, the main server 40 may generate the secure package
identifier, or may work in cooperation with the key server 42 to
generate the secure package identifier. The secure package
identifier is an alpha-numeric value that uniquely identifies the
transfer data the sender client 36 communicates to the recipient
client 38.
[0052] The sender client 36 encodes the transfer data using the
encryption key, as depicted in block 54. The sender client 36 uses
a symmetrical encryption scheme such that a single, unique key is
associated with each secure data package and the key used by the
sender client 36 to encrypt the transfer data is also the key used
by the recipient client 38 to decrypt the data. As explained below
in greater detail, the main server 40 and/or the key server 42
regulate the distribution of the encryption key to eliminate or
reduce the risk of an unauthorized person obtaining the encryption
key.
[0053] The sender client 36 combines the encrypted transfer data
and the secure package identifier to form the secure data package,
as depicted in block 56. Thus the secure data package includes not
only the encrypted transfer data but also the secure package
identifier, which is used by the recipient client 38 to request the
encryption key from the main server 40.
[0054] With reference now to FIG. 4, the recipient client 38
receives identification information and authentication information
from the recipient, as depicted in block 58. This step is
substantially the same as step 44, described above, wherein the
sender client 36 receives identification and authentication
information from the sender. The recipient client 38 identifies the
secure package identifier in the secure data package, as depicted
in block 60. Because the secure package identifier is not encrypted
with the transfer data, the recipient client 38 can read and remove
the secure package identifier without decrypting the transfer data.
This may be done, for example, by placing the secure package
identifier in a heading of the secure data package.
[0055] The recipient client 38 communicates the identification
information, the authentication information, and the secure package
identifier to the main server 40, as depicted in block 62. The main
server verifies the recipient identification information and
authentication information, and uses the secure package identifier
to obtain and communicate the correct encryption key to the
recipient client 38. Thus, the recipient client 38 receives the
encryption key from the main server 40, as depicted in block 64.
Finally, the recipient client 38 decrypts the encrypted transfer
data using the encryption key, as depicted in block 66. It is
possible that a user interacting with the recipient client 38 is
not a valid recipient of the secure data package, in which case the
main server 40 or the key server 42 prevents the user from
receiving the key.
[0056] The sender client 36 may encrypt the sender identification
and authentication information, the key, and the list of recipients
in layers before communicating these to the main server 40. For
example, the sender client 36 may first combine the sender
identification and authentication information to form a first
bundle and encrypt the first bundle, then combine the encrypted
first bundle with the key to form a second bundle and encrypt the
second bundle, and then combine the encrypted second bundle with
the list to form a third bundle and encrypt the third bundle.
Likewise, the recipient client 38 is operable to decrypt these
items in the layers they were encrypted in.
[0057] As explained above, both the sender client 36 and the
recipient client 38 are each operable to function as a sender
client and as a recipient client. Thus, the sender client 36
executes the steps illustrated in FIG. 3 when used to create and
send a secure data package, and executes the steps illustrated in
FIG. 4 when used to receive and decrypt a secure data package.
Likewise, the recipient client 38 executes the steps illustrated in
FIG. 3 when used to create and send a secure data package, and
executes the steps illustrated in FIG. 4 when used to receive and
decrypt a secure data package.
[0058] Referring again to FIG. 2, the main server 40 communicates
with the key server 42, the sender client 36, and the recipient
client 38. The main server 40 retains authentication records and
performs authentication in a conventional manner. Authentication
may include, for example, comparing a user name and a password
received from a user with a user name and a password stored in an
authentication database to verify the identity of the user
submitting the user name and password. The main server 40 may also
maintain a biometric authentication database, wherein the main
server 40 compares biometric information, such as fingerprint data,
with biometric information stored in the database.
[0059] The main server 40 communicates with the key server 42 to
enable the key server 42 to create a secure package identifier and
associate the secure package identifier with a secure data package.
The main server 40 further requests verification of each recipient
requesting an encryption key. The main server 40 is further
operable to perform an encoding algorithm on each recipient
identifier included in the list of recipients submitted by a sender
via the sender client 36. In one embodiment, the encoding algorithm
involves hashing each recipient identifier to generate a number
corresponding to the recipient identifier. Such encoding enables
the present invention to hide the actual name and other sensitive
personal information relating to each user by discarding the
information and storing only the encoded identifier. While a single
main server 40 is illustrated in FIG. 2, it will be appreciated by
those skilled in the art that a plurality of main servers may be
employed in the present invention wherein the sender client 36 uses
a first main server and the recipient client 38 uses a second main
server. This alternative configuration is illustrated in FIG. 8 and
described in greater detail below.
[0060] The key server 42 stores secure data package identification
records wherein each record associates a secure package identifier
with a list of recipients, a key, an encryption record, and other
information. The key server 42 also regulates the disbursement of
encryption keys stored thereon. More specifically, the key server
42 receives a secure package identifier and a recipient identifier
from the main sever 40, confirms the recipient identifier is
associated with the secure package identifier in a secure data
package identification record, and communicates the encryption key
to the main server 40 only if the recipient identifier matches a
recipient identifier associated with the secure package identifier.
This process is described in greater detail below.
[0061] It should be noted from FIG. 2, that the key server 42
communicates only with the main server 40, and does not communicate
directly with the sender client 36 or the recipient client 38. This
configuration enables the key server 42 to work with a plurality of
main servers 40 and provides an extra layer of security.
[0062] FIG. 5 illustrates an exemplary protocol for implementing
the present teachings in the sender client 36, the recipient client
38, the main server 40, and the key server 42. The operations
performed by the sender client 36 and the recipient 38 are
illustrated in FIG. 3 and FIG. 4 respectively, and were described
above. Therefore, the steps taken by the sender client 36 and the
recipient 38 will not be discussed in detail here.
[0063] The first interaction between the computers illustrated in
FIG. 2 occurs when the sender client 36 communicates sender
identification information, sender authentication information, an
encryption key, and a list of recipient identifiers to the main
server 40, as depicted in box 68. The main server 40 creates a
server/user identifier (SUID), which is a combination of the user
identifier and an identifier of the main server 40. The main server
40 also encodes each recipient identifier received from the sender
client 36, as explained above. A preferred method of encoding the
recipient identifiers involves hashing the identifiers to generate
a unique numeric hash value corresponding to each recipient
identifier. The encoding scheme preferably generates a unique
encoded value for each recipient identifier, therefore the
recipient identifiers received from the sender client 36 can be
discarded and replaced with the anonymous encoded recipient
identifiers, thus preserving the privacy and anonymity of the
recipients. The main server 40 or the key server 42 may obtain the
original recipient identifier corresponding to an encoded value by
performing the hashing algorithm in reverse.
[0064] The second communication in the protocol illustrated in FIG.
5 occurs when the main server 40 communicates the sender SUID, the
encoded (anonymous) recipient identifiers, and the key to the key
server 42, as illustrated in box 70. Referring to FIG. 6, the key
server 42 creates a secure package identifier 86 and a transaction
record 92, and associates the secure package identifier 86 with the
sender SUID 90, the encoded recipient identifiers 88, the key 94,
and the transaction record 92. The key server 42 updates the
transaction record 92 each time the key server 42 communicates the
key 94 to the main server 40 in response to a request from the main
server 40. Thus, the record 92 indicates to which recipient of the
list of recipients 88 the encryption key 94 was communicated. This
may be advantageous, for example, for billing records.
[0065] FIG. 7 illustrates a specific implementation of a portion of
the data structure of FIG. 6. Various secure package identifiers
are stored in a column 96 of a table of FIG. 7, including secure
package identifiers 102 and 104. A second column 98 includes a
plurality of SUIDs associated with each of a plurality of
recipients. A plurality of additional columns 100 include encoded
recipient identifiers each associated with a recipient SUID of the
column 98. For example, in the top row of the table of FIG. 7, the
secure package identifier 102 is the number "573." The dotted line
extending from secure package identifier 102 to the second row of
the table indicates the sender SUID corresponding to number "1562"
is the sender of the transfer data associated with the secure
package identifier 102. Furthermore, the encryption package
identifier in cell number 102 is linked to three separate recipient
identifiers, as illustrated by the three solid-line arrows. In this
case, the secure package identifier 102 is associated with the
recipient SUID corresponding to the number "1479," to the recipient
SUID corresponding to the number "2519," and to the recipient SUID
corresponding to number "7536."
[0066] Each of the recipient SUIDs corresponding to the secure
package identifier 102 includes a plurality of encoded recipient
identifiers. Thus, when the key server 42 receives any of the
encoded recipient identifiers corresponding to one of the recipient
SUIDs linked to the encryption package identifier 102, the key
server 42 can confirm that the recipient associated with the
encoded recipient identifier is a valid recipient of the key 94.
There may be multiple recipient identifiers associated with a
single recipient, where, for example, a user has multiple email
addresses such as a work address and a home address. In that case,
whether the recipient is requesting the key 94 from a work email
account or a home email account, the key server 42 will recognize
the encoded recipient identifier received from the user via the
main server 40 as pertaining to the recipient SUID.
[0067] It should be noted that in FIG. 7 the column 98 includes
multiple SUIDs and does not distinguish between a sender SUID and a
recipient SUID. In a first secure data package identification
record, an SUID may correspond to the sender, while in a second
secure data package identification record, the same SUID may
correspond to one of the recipients.
[0068] Once the key server 42 creates the secure package identifier
86 and associates the secure package identifier 86 with the encoded
recipient identifiers 88, the sender SUID 90, the key 94, and the
record 92, the key server 42 communicates the secure package
identifier 86 to the main server 40 as depicted in box 72 of FIG.
5. The main server 40 then communicates the secure package
identifier 86 to the sender client 36 as depicted in box 74. At
this point, the sender client 36 has everything it needs to create
the secure data package, which includes the secure package
identifier 86 and encrypted transfer data.
[0069] The sender client 36 creates the secure data package by
using the key 94 to encrypt the transfer data. The encrypted
transfer data is then associated with the secure package identifier
86 to create the secure data package. As explained above, the
secure package identifier 86 is not encrypted along with the
transfer data, but rather is bundled with the encrypted transfer
data such that the recipient client 38 is able to read the secure
package identifier 86 without the key 94. Once the sender client 36
creates the secure data package, the secure data package is
transferred to the recipient client 38, as depicted box 76. This
transaction occurs in a manner that is substantially conventional.
For example, the sender client 36 may communicate the secure data
package to the recipient client 38 via conventional email
communication channels, as an email attachment or in the body of an
email text.
[0070] It should be noted that the particular manner of
communicating the encryption package from the sender client 36 to
the recipient client 38 is not important to the present invention,
and that the secure data package need not be transferred to the
recipient client 38 via electronic means at all. Once the sender
client 36 creates the secure data package, a user may store the
secure data package on a physical data medium such as, for example,
a compact disc or a portable hard drive, and physically carry the
storage medium to the recipient client 38. Furthermore, the sender
client 36 may or may not include a code segment for transferring
the secure data package to the recipient client 38. The sender
client 36 may create the secure data package, for example, and
place the secure data package into an email as text or as an
attachment, wherein a conventional email application provides the
computer code for transferring the secure data package to the host
computer of the recipient client 38. Furthermore, the recipient
client 38 may not receive the secure data package immediately upon
arrival of the package at the recipient client's host computer, but
may enable a user to submit information identifying the secure data
package, wherein the recipient client 38 processes the package.
[0071] When the recipient client 38 receives the secure data
package, the recipient client 38 identifies the secure package
identifier 86 and prompts the recipient to submit identification
and authentication information. The recipient client 38 may prompt
the user to submit the identification and authentication
information in a substantially conventional manner by presenting,
for example, one or more pop up windows with text fields for
receiving a user name and a password, or for receiving a user name
and biometric information. When the recipient client 38 has
identified the secure package identifier 86 and has received the
recipient identification and authentication information, the
recipient client 38 communicates the secure package identifier 86
and the recipient identification and authentication information to
the main server 40, as depicted in box 78. The main server 40 then
creates a recipient SUID that identifies both the requesting
recipient as well as the main server 40. In this case, the server
identifier associated with the sender SUID will be the same as the
server identifier associated with the recipient SU I D, because
both the sender and the recipient are using the same main server
40. It will be appreciated, however, that if the sender client 36
uses a first main server and the recipient client 38 uses a second
main server (see FIG. 8), the server portion of the sender SUID
will be different than the server portion of the recipient
SUID.
[0072] The main server 40 communicates the secure package
identifier 86 and the recipient SUID to the key server 42. The key
server 42 determines whether the secure package identifier received
from the main server 40 matches a secure package identifier in
column 96 of the data structure illustrated in FIG. 7. If so, the
key server 42 compares the recipient SUID received from the main
server 40 with each of the SUIDs in column 98 that are associated
with the secure package identifier received from the main server
40. If the secure package identifier received from the main server
40 is linked to an SUID that matches the recipient SUID received
from the main server 40, the key server 42 communicates the key 94
to the main server 40, as depicted in box 82. The main server 40
then communicates the key 94 to the recipient client 38, as
depicted in box 84. The recipient client 38 uses the encryption key
94 to decrypt the encrypted transfer data that it received in the
secure data package.
[0073] The present invention thus uses various layers of security
to protect data that is transferred from the sender client 36 to
the recipient client 38. First, the sender client 36 encrypts the
data using a single encryption key and the recipient client 38
decrypts the data using the same encryption key in a symmetrical
encryption architecture. Use of the symmetrical encryption scheme
reduces the necessity to make available a public key associated
with each of various secure transactions. Thus, if a third party
happens to obtain an encryption key associated with a secure data
package, the third party will not be able to use the key to access
unrelated secure data packages. Second, the sender client 36
requires the sender to submit not only sender identification
information but also sender authentication information in the form
of a password or biometric information to verify the sender's
identity. Third, the recipient client 38 requires the recipient to
submit identification information and authentication information in
the form of a password or biometric information to verify the
sender's identity.
[0074] While the protocol of FIG. 5 has been illustrated and
described as using a single main server 40 it will be understood
that a plurality of main servers may be used instead of a single
main server. This is illustrated in FIG. 8, wherein the sender
client 36 communicates with a first main server 106 and the
recipient client 38 communicates with a second main server 108 and
wherein both main servers 106,108 communicate with the key server
42. The embodiment illustrated in FIG. 8 may be desirable where,
for example, the sender client 36 and recipient client 38 are at
geographically remote physical locations and therefore must
communicate with different main servers.
[0075] In the embodiment shown in FIG. 8, the protocol illustrated
in FIG. 5 is substantially similar although the operations
performed by the main server in FIG. 5 are divided up between the
first main server 106 and the second main server 108 in FIG. 8. For
example, the first main server 106 of FIG. 8 receives the sender
identifier and the sender authentication information, the
encryption key and the list of recipient identifiers from the
sender client 36, encodes the recipient identifiers, and creates
the sender SUID, and communicates the sender SUID, the encoded
recipient identifiers and the encryption key to the key server 42.
The key server 42 then communicates the encryption package
identifier 86 to the first main server 106, which communicates the
encryption package identifier to the sender client 36.
[0076] Likewise the recipient client 38 communicates the encryption
package identifier and the recipient identification information and
the recipient authentication information to the second main server
108. The second main server 108 creates the recipient SUID and
communicates the recipient SUID and the encryption package
identifier to the key server 42. The key server 42 communicates the
encryption key 94 to the second main server 108 which communicates
the encryption key to the recipient client 38.
[0077] In yet another embodiment illustrated in FIG. 9, a single
server 110 performs the functions and operations of the main server
40 and the key server 42 illustrated in FIG. 5 and described above.
While the embodiment illustrated in FIG. 9 is not preferable, the
server 110 performs the same functions as the main server 40 and
the key server 42 of FIG. 5 and therefore is functionally
equivalent. The embodiment illustrated in FIG. 9 may be preferable,
for example, where the heightened security associated with separate
main and key servers is not necessary.
[0078] In each of the above embodiments, security may be enhanced
by maintaining the key only in the key server 42 (or equivalent)
and not retaining a copy of the key in any of the other computers.
When the sender client 36 creates and communicates the key to the
main server 40, for example, the sender client 36 destroys or
discards the key upon communicating the key to the main server 40.
In other words, the sender client 36 communicates the key to the
main server 40 and then removes any indication or record of the key
from memory and storage associated with the sender client 36.
Likewise, the main server 40 destroys the key upon communicating
the key to the key server 42, and then again upon communicating the
key to the recipient client 38. The recipient client 38 also
destroys the key after using the key to decrypt the encrypted
transfer data. While maintaining the key only on the key server 42
enhances security in some situations, it is not necessary and the
present invention may be otherwise implemented.
[0079] As explained above, each of the sender client 36 and the
recipient client 38 may be presented in one of four embodiments. In
a first embodiment, the client software is a "plugin" associated
with a traditional email application such as MICROSOFT OUTLOOK.TM.
or LOTUS NOTES.TM.. These are but two examples, and those skilled
in the art will recognize that any conventional or known email or
other messaging application may be used including, for example,
instant messaging.
[0080] FIG. 10 illustrates a user interface 112 of a conventional
email application, in this case MICROSOFT OUTLOOK.TM.. The user
interface 112 is substantially conventional except that the
interface 112 includes an interface element 114 associated with the
client 36. To use the client 36 with the interface 112, the user
composes a new email message in a conventional manner and, before
sending the email message, selects the user interface element 114
associated with the client 36. When the user selects the interface
element 114 the client prompts the user to submit a user name as
well as authentication information. This may be done, for example,
by presenting a pop-up window with text fields for a user name and
a password, or a text field for a user name and a button for
requesting submission of biometric information. Such a pop-up
window may be similar to window 122 of FIG. 13.
[0081] The client 36 then generates the encryption key and
assembles the list of recipients. In this case, the client 36 may
assemble the list of recipients simply by reading recipient
information from the "TO" field of the newly composed email
message. The client 36 communicates the sender identification and
authentication information, the key, and the list of recipient
identifiers to the main server 40, and receives the encryption
package identifier 86 from the main server 40. When the client 36
receives the secure package identifier 86 it encrypts the data in
the body of the email and displays the encrypted text in the body
of the email instead of the plain text. The client 36 then places
the secure package identifier 86 in the email, such as in the title
of the email message or in another location where it can be easily
retrieved by the recipient client 38. The user then sends the email
message in a convention manner to the intended recipient or list of
recipients.
[0082] When the recipient client 38 receives the email message with
the secure data package, the email message will appear in a
conventional email application interface such as that of FIG. 10.
The difference will be that the body of the text will appear in
encrypted form, and the email application interface will present an
interface element 114 associated with the recipient client 38. When
the recipient attempts to open the email message, the recipient
client 38 prompts the recipient to submit user identification and
authentication information, as explained above in relation to the
sender client 36. The recipient client 38 identifies the encryption
package identifier 86 in the secure data package and communicates
both the secure package identifier 86 and the user identification
and authentication information to the main server 40. The recipient
client 38 receives the key 94 from the main server 40, and decrypts
the encrypted transfer data. When the recipient client 38 decrypts
the encrypted transfer data, the decrypted (plain text) data will
appear in the body of the email in a conventional manner.
[0083] In a second embodiment, the sender client 36 and recipient
client 38 are not plugins associated with a preexisting email
application, but rather are stand alone applications. In the second
embodiment, the client 36 is operable to work with a native data
buffer to use onscreen text or other data to encrypt the data in
preparation for creating an encryption package. An example of the
second embodiment of the client 36 is illustrated in FIGS.
11-14.
[0084] FIG. 11 illustrates a conventional computing environment
wherein a text processor such as MICROSOFT NOTEPAD.TM. is visible
in the computing environment, such as the desktop of the MICROSOFT
WINDOWS.TM. operating system. While the illustrated window 116 is a
word processor, it will be appreciated that substantially any
application that is compatible with the host operating environment
and operable to transfer data to the data buffer may be used with
the second embodiment of the client 36. As illustrated in FIG. 12,
the user selects or highlights the portion of the data that he or
she wishes to encode. In the window 116 of FIG. 12 the entire body
of text is highlighted. The user then selects the user interface
element 118 which is, in this case, present in the notification
area of the WINDOWS.TM. task bar. Selecting the interface element
118 causes the client 36 to present a context menu 120. The user
selects the text option to enable the client 36 to encode the
user-selected text and move it to a buffer as explained below.
[0085] When the user selects the text option of the context menu
120, the client 36 prompts the user to move the highlighted text to
the buffer by "cutting" the highlighted text. In this case, the
buffer is the WINDOWS.TM. clipboard and the cutting operation is
performed by the user in a conventional manner, such as, for
example, selecting the hot key combination CTRL+X on the keyboard.
Cutting the highlighted text in the window 116 removes the text
from the window 116 and places it in the data buffer. When the text
is placed in the buffer, the client 36 prompts the user to submit
identification and authentication information with a dialog box
122, as illustrated in FIG. 13. Wherein the user submits a user
name, password and/or biometric information, the client 36 prompts
the user to submit recipient information via a second dialog box
124, as illustrated in FIG. 14. When the user has submitted the
recipient information, the program creates an encryption key. The
sender client 36 communicates the sender identification
authentication information, the encryption key and the list of
recipient identifiers to the main server 40, as explained
above.
[0086] When the sender client 36 receives the secure package
identifier 86 from the main server 40, the client 36 encrypts the
data that is in the buffer (the transfer data) using the key and
creates a secure data package by associating the secure package
identifier with the encrypted transfer data. The client 36 then
prompts the user to move the secure data package from the buffer to
an application, such as the application from which the original
transfer data was removed. Placing the encryption package in the
application may involve, for example, selecting the "paste" option
in the windows operating environment. The secure data package may
then be communicated to the host computer of the recipient client
38 by, for example, storing the secure data package in a data file
and attaching the data file to an email, by pasting the secure data
package directly into the body of an email or of a text message, or
by saving the secure data package to a file on a removeable data
storage medium and physically transporting the data storage medium
to the recipient client 38.
[0087] Once the recipient client 38 identifies the encryption
package, it goes through a process similar to that described above
for the plugin embodiment of the client to decrypt the transfer
data in the secure data package. The user moves the secure data
package, which in this case includes text, to the data buffer of
the host computing environment by highlighting the encrypted text
and selecting "copy" option in the windows operating environment.
The client 38 prompts the user to submit authentication information
in substantially the same way that the sender client 36 prompted
the user to submit the authentication information. When the
recipient is authenticated, the client 38 decrypts the data using
the key it received from the main server 40, and when the
decryption is complete the program launches a viewer window into
which the decrypted text is placed. The decrypted data also remains
in the data buffer for the user to place in another application if
so desired.
[0088] In a third embodiment the client 36 encodes the transfer
data by merging the transfer data with a separate file using
conventional steganography techniques. This embodiment of the
client 36 is illustrated in FIGS. 15 and 16. As illustrated in FIG.
15, a conventional computing environment presents a canvas 126, a
user interface element 118 associated with a sender client 36, an
image file 128, and a transfer data file 130. The transfer data
file 130 is encoded or encrypted in the separate image file 128 (in
this case, an image file) when both the transfer data file 130 and
the separate image file 128 are placed in the canvas 126. For
example, the user first selects the separate data file 128 and
places it in the canvas 126 using a conventional drag-and-drop or
cut-and-paste operation.
[0089] The user then places the transfer data file 130 into the
canvas in the same way. The program prompts the user to submit
identification and authentication information, creates an
encryption key, prompts the user to submit recipient identification
information and communicates with the main server in the manner
described above. When the client 36 receives the encryption package
identifier 86 from the main server 40, the sender client 36 then
completes the encryption package by associating the encryption
package identifier 86 with the image carrying the encrypted
transfer data 130. The client 36 then prompts the user to save the
newly-created secure data package as a separate file. When the
recipient client 38 identifies the secure data package, it presents
a canvas similar to the canvas 126 of FIGS. 15-16, and prompts the
recipient to place the file containing the encoded data package
into the canvas or, alternatively, automatically places the file
into the canvas. The client 38 then prompts the recipient to submit
authentication and identification information, as explained above,
and goes through the process depicted in the flowchart of FIG.
4.
[0090] In a fourth embodiment, the client 36 enables the user to
indicate an existing data file by, for example, selecting the file
in MICROSOFT WINDOWS EXPLORER.TM. or a similar utility, and
selecting the "Attach" option of the context menu 120 (see FIG.
12). The client 36 presents an interface similar to the canvas 126
of FIG. 15, and prompts the sender to place the file in the
interface or automatically places the file in the interface. The
client 36 then goes through the steps of FIG. 3, described above,
and creates a secured data package including data contained in the
user-selected file. The client 36 then prompts the user to save the
secured data package as a new file, wherein the user can transfer
the secured data package to the recipient client 38 electronically,
such as via email, or in another manner, including physically
transferring a storage medium containing the secured data
package.
[0091] The system described above may be implemented as a service
wherein fees are assessed and charged to system users. A first
person, company, or other entity may maintain the main server 40
and the key server 42, for example, and charge users a fee based on
use of the main server 40, the key server 42, or both. Fees may be
charged, for example, based on the number of secure package
identifiers 86 a user creates, based on the number of secure
packages sent by a user, and so forth. Alternatively, a flat fee
may be charged, such as a monthly or annual fee.
Interactive Information Dissemination
[0092] The present invention also provides a system and method for
interactive dissemination of information. The system and method for
interactive dissemination of information enables a user to
associate a message, such as a message personalized to a particular
recipient or a non-personal message intended for a large group of
recipients, with a media element, such as an advertisement, such
that the media element is presented to a message recipient with the
message.
[0093] More particularly, a sender creates a data package by
identifying one or more recipient identifiers, a message, and a
media element. The data package is then communicated to one or more
recipients corresponding to the one or more recipient identifiers,
where the media element is presented to each recipient and the
message is presented to each recipient only after the media element
is presented to the recipient and after the recipient performs an
action to retrieve the message. The system may involve a sponsor
who generally provides one or more media elements, a sender who
creates and sends the data package, a recipient who receives the
data package, and a host who provides the service. It will be
appreciated that a single party may fill two or more of these
roles, such as, for example, where a company hosts the service,
provides one or more media elements as a sponsor, and creates and
sends data packages as a sender. Furthermore, there may be multiple
sponsors, senders, and/or recipients.
[0094] The sponsor may be any person or entity seeking to
disseminate information. By way of example, the sponsor may be a
company seeking to promote or advertise a product or service,
seeking to enhance the company's image, or soliciting applicants
for employment; an artist seeking to promote or advertise artistic
works such as music, paintings, or sculptures; an author seeking to
promote or advertise literary works; a government office or agency
seeking to promote a particular service or soliciting applicants
for employment; a politician seeking publicity or soliciting
campaign assistance; an educational or non-profit organization
seeking to educate a target audience; etcetera. These are but a few
examples, the sponsor may be virtually any person or entity seeking
to disseminate information.
[0095] The sender is a person or entity who wishes to communicate a
message to a target recipient or target recipient group. If the
sender is an individual primarily interested in communicating a
personalized message to the recipient, for example, the sender may
choose to associate the message with a media element so that the
sponsor providing the media element bears the cost of encoding the
message via an encoding service. Alternatively, if the sender is a
company primarily interested in disseminating information through
use of the media elements, it may choose a message that is not
personal to the recipient but that is of interest to the recipient,
such as where the message is the result of a contest or the release
date of a highly-anticipated product.
[0096] The host is a person or entity that provides the services
that enable interaction between the sender, sponsor, and the
recipient. The host may provide and maintain, for example,
computers and computer software for receiving and storing media
elements submitted by the host, for creating and sending messages
from the sender, and for receiving and presenting messages to a
recipient. The host may charge a fee to sponsors, senders,
recipients, or any combination of these parties.
[0097] FIG. 17 illustrates an exemplary architecture for
implementing the interactive information dissemination system,
wherein the architecture may be implemented on a computer network
similar to that of FIG. 1. The architecture illustrated in FIG. 17
broadly comprises the interaction of six separate software modules
including a sender client 200, a recipient client 202, a sponsor
client 204, a main server 206, a key server 208, and a media sever
210. The sender client 200 and the recipient client 202 are
substantially similar to the sender client 36 and the recipient
client 38 described above, except that the sender client 200 and
the recipient client 202 are operable to communicate with the media
server 210 and work with media elements, as explained below. The
main server 206 and the key server 208 may be identical to the main
server 40 and the key server 42 described above. Two or more of the
software modules illustrated in FIG. 17 may be combined or
implemented on a single computer. The key server 208 and the main
server 206, for example, may be implemented on a single machine, as
explained above in relation to the main server 40 and the key
server 42. Likewise, the media server 210 may be implemented in the
main server 206, or even the key server 208.
[0098] The media server 210 receives media elements from one or
more sponsors via the sponsor client 204 and stores the media
elements in a database, such as a database stored on or accessible
by the media server 210. The media server 210 also allows senders
to access the database via the sender client 200 to view the media
elements and choose a media element with which to associate a
message. The media server 210 may also manage user accounts,
including assigning fees to users. The sponsor client 204 provides
an interface for enabling each sponsor to access the media server
210 to submit media elements, to update account information, and so
forth. The sponsor client 204 may include, for example, a web page
maintained on the media server and executed by a web browser in
communication with the media server 210 via a computer network,
wherein the web browser may be running on a computer workstation, a
laptop or notebook computer, or a handheld computing device.
[0099] In an exemplary scenario, a sender submits identification
and/or authentication information, identifies message data, and
selects recipient identifiers in a manner substantially similar to
that described above in relation to the sender client 36.
Additionally, the sender selects a media element by accessing the
media server 210, viewing or browsing a list of possible media
elements, and selecting a media element from the list. An exemplary
user interface 212 for assisting a user in selecting a media
element is illustrated in FIG. 18, wherein the interface 212
presents various user interface elements 214,216,218. A first
element 214 may correspond to a movie or animation file, a second
element 216 may correspond to an audio file, and a third element
218 may correspond to an image file. A sender client employing
principles of the interactive information dissemination service of
the present teachings may perform all or substantially all of the
steps set forth in FIG. 3 and, in addition, may perform one or more
of the step of providing a list of media elements to the sender for
the sender to browse through and choose a media element to be
associated with the message data.
[0100] The sender client 200 creates a data package including the
recipient identifier, the message, and the media element. Various
exemplary data packages are illustrated in FIG. 19. A first
exemplary data package 220 includes one or more recipient
identifiers 222, message data 224, and a media element 226. A
second exemplary data package 228 is similar to the first exemplary
data package 220, except that in the second exemplary data package
228 the message data 230 is embedded in the media element 232. This
may be done, for example, using steganography or similar techniques
known in the art.
[0101] A third exemplary data package 234 is similar to the first
data package 220, except that the third data package 234 includes a
link 236 to an external media element 238, instead of including the
media element itself. The external media element 238 may be stored
on the media server 210. A fourth exemplary data package 240 is
similar to the third exemplary data package 234, except that the
fourth exemplary data package 240 includes a second link 242 to an
external message 244, instead of including the message data itself.
Thus, in the fourth exemplary data package 242, neither the media
element 238 nor the message 244 is included in the package 240.
Each link 236,242 may be, for example, an HTTP link. It will be
appreciated that providing links to a media element and/or to
message data may reduce the amount of data being sent via email,
instant messaging, or similar protocols.
[0102] The system may authenticate the sender and secure the
message data using the main server 206 and the key server 208 in a
manner similar to that explained above and illustrated in FIG. 5.
Alternatively, the sender client 200 may communicate the message
data, recipient identifier, and the media element to the recipient
client 202 without authenticating the sender or securing the data.
In the latter scenario, the main server 206 and the key server 208
would not be used and, therefore, would not be necessary.
Furthermore, the sender client 200 may not communicate the data
package to the recipient client 202, but may store the data on a
portable storage medium to be physically transported to the
recipient client 202.
[0103] The recipient client 202 identifies the data package and
presents the media element to the recipient. The system may
authenticate the recipient and obtain a key for decoding the data
using the main server 206 and the key server 208 in a manner
similar to that described above and illustrated in FIG. 5.
Alternatively, the system may display the media element without
authenticating the recipient and present the message when the
recipient performs some action, such as selecting a user interface
element to request the message.
[0104] The host may implement any of a variety of fee structures.
The host may charge a sponsor each time a media element submitted
by the sponsor is used. This fee structure may be used, for
example, where the media element selected is an advertisement
submitted by the sponsor. The host may charge a sender each time
the sender uses a media element. This fee structure may be used,
for example, where the media element is a song or video that the
sender desires to share with the recipient. In this scenario, all
or a portion of the fee collected from the sender may be paid to
the sponsor who submitted the media element.
[0105] The present teachings contemplate providing users with two
or more service options. FIG. 20 illustrates the user interface 112
and interface element 114 of a conventional email application and
described above. The user interface 112 may further include a
second interface element 246. The interface element 114 enables
users to invoke the secure data transfer system and protocol as
explained above in the section titled "Secure Encryption for
Electronic Data Transfer," and the second interface element 246
enables users to invoke the interactive information dissemination
system. By way of example, if a user desires to communicate data to
a recipient via a secure data transfer system and is willing to pay
a fee, the user may choose the interface element 114.
Alternatively, if the user desires to shift the cost of the
communication to a sponsor, the user may select the second
interface element 246, wherein the user would be required to choose
a media element to be associated with the message, the media
element would be presented to the recipient, and the sponsor
associated with the media element would be charged a fee.
[0106] Although the invention has been described with reference to
the preferred embodiments illustrated in the attached drawings, it
is noted that equivalents may be employed and substitutions made
herein without departing from the scope of the invention as recited
in the claims. It will be appreciated, for example, that email is
not the only means of electronically communicating a secured data
package from the sender client 36 to the recipient client 38, and
that other forms of electronic communication may be used including
the hyper-text transfer protocol (HTTP) and the file transfer
protocol (FTP).
[0107] Having thus described a preferred embodiment of the
invention, what is claimed as new and desired to be protected by
Letters Patent includes the following:
* * * * *