U.S. patent application number 10/984361 was filed with the patent office on 2005-05-19 for data translation architecture.
Invention is credited to Odom, Greg, Sjollema, Mark.
Application Number | 20050108412 10/984361 |
Document ID | / |
Family ID | 31981102 |
Filed Date | 2005-05-19 |
United States Patent
Application |
20050108412 |
Kind Code |
A1 |
Sjollema, Mark ; et
al. |
May 19, 2005 |
Data translation architecture
Abstract
An architecture in which data outputs from an application
program into a communication interface are diverted, by changing
their address to a reserved address, and then are processed further
by an added program which is invisible to the application
program.
Inventors: |
Sjollema, Mark; (Hampton
Hill, GB) ; Odom, Greg; (Grand Prairie, TX) |
Correspondence
Address: |
GROOVER & HOLMES
BOX 802889
DALLAS
TX
75380-2889
US
|
Family ID: |
31981102 |
Appl. No.: |
10/984361 |
Filed: |
November 9, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10984361 |
Nov 9, 2004 |
|
|
|
10334684 |
Dec 31, 2002 |
|
|
|
6826627 |
|
|
|
|
60408096 |
Sep 3, 2002 |
|
|
|
Current U.S.
Class: |
709/230 ;
709/245 |
Current CPC
Class: |
H04L 69/08 20130101;
H04L 29/06 20130101; H04L 61/35 20130101; H04L 29/12783 20130101;
H04L 29/12009 20130101 |
Class at
Publication: |
709/230 ;
709/245 |
International
Class: |
G06F 015/16 |
Claims
What is claimed is:
1. A system, comprising: a communications interface module which
transmits data over a communication channel according to an
addressing protocol which includes one or more reserved addresses
which are not freely available for external communication, and also
includes non-reserved addresses; at least one active program which
sends first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications to said interface module using ones of said reserved
addresses; and an additional module which a) detects ones of said
second communications, b) modifies data in ones of said second
communications, and c) transmits results of said operation b).
2. The system of claim 1, wherein said additional module is a
software module.
3. The system of claim 1, wherein said additional module is a
software module, running on the same processor as said active
program.
4. The system of claim 1, wherein said protocol is TCP/IP.
5. The system of claim 1, wherein said additional module transmits
results of said operation b) through said interface module to a
non-reserved address.
6. The system of claim 1, wherein said additional module separates
protocol-related header portions of said transmission from data
content portions thereof, and performs data translation operations
on said data content portions without operating on said header
portions.
7. The system of claim 1, wherein said processing step b) is
performed only conditionally, in dependence on information in the
header of the transmission as received.
8. A system, comprising: a communications interface module which
transmits data over a communication channel according to an
addressing protocol which includes non-reserved addresses and also
one or more reserved loopback addresses which are not freely
available for external communication, and which echoes back data
addressed to one of said reserved addresses; at least one active
program which sends first communications into said channel through
said interface module, using non-reserved addresses, and which also
sends second communications through said interface module using
ones of said reserved loopback addresses; and an additional module
which a) detects ones of said second communications, b) modifies
data in ones of said second communications, and c) transmits
results of said operation b).
9. The system of claim 8, wherein said additional module is a
software module.
10. The system of claim 8, wherein said protocol is TCP/IP.
11. The system of claim 8, wherein said additional module transmits
results of said operation b) through said interface module to a
non-reserved address.
12. The system of claim 8, wherein said processing step b) is
performed only conditionally, in dependence on information in the
header of the transmission as received.
13. The system of claim 8, wherein said additional module separates
protocol-related header portions of said transmission from data
content portions thereof, and performs data translation operations
on said data content portions without operating on said header
portions.
14. A system, comprising: a communications interface module which
transmits data over a communication channel according to an
addressing protocol which includes one or more reserved addresses
which are not freely available for external communication, and also
includes non-reserved addresses; at least one active program which
sends first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved addresses; and an additional module which a) detects ones
of said second communications, b) modifies data content portions
thereof but not protocol-related header portions thereof, and c)
transmits results of said operation b).
15. The system of claim 14, wherein said additional module is a
software module.
16. The system of claim 14, wherein said additional module is a
software module, running on the same processor as said active
program.
17. The system of claim 14, wherein said additional module
separates protocol-related header portions of said transmission
from data content portions thereof, and performs data translation
operations on said data content portions without operating on said
header portions.
18. The system of claim 14, wherein said protocol is TCP/IP.
19. The system of claim 14, wherein said additional module
transmits results of said operation b) through said interface
module to a non-reserved address.
20. The system of claim 14, wherein said processing step b) is
performed only conditionally, in dependence on information in the
header and/or content of the transmission as received.
21. A system, comprising: a communications interface module which
transmits data over a communication channel according to an
addressing protocol which includes one or more reserved addresses
which are not freely available for external communication, and also
includes non-reserved addresses; at least one active program which
sends first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved addresses; and an additional module which a) detects ones
of said second communications, b) modifies data in ones of said
second communications, and c) transmits results of said operation
b); and which also d) intercepts and modifies at least some
incoming transmissions directed to said active program.
22. The system of claim 21, wherein said additional module is a
software module.
23. The system of claim 21, wherein said additional module is a
software module, running on the same processor as said active
program.
24. The system of claim 21, wherein said protocol is TCP/IP.
25. The system of claim 21, wherein said additional module
transmits results of said operation b) through said interface
module to a non-reserved address.
26. The system of claim 21, wherein said processing step b) is
performed only conditionally.
27. The system of claim 21, wherein said processing step d) is
performed only conditionally, in dependence on information in the
content of the transmission as received.
28. The system of claim 21, wherein said additional module
separates protocol-related header portions of said transmission
from data content portions thereof, and performs data translation
operations on said data content portions without operating on said
header portions.
29. A system, comprising: a communications interface module which
transmits data over a communication channel according to an
addressing protocol which includes one or more reserved addresses
which are not freely available for external communication, and also
includes non-reserved addresses; at least one active program which
sends first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved addresses; and an additional module which a) detects ones
of said second communications, b) selectively modifies data in only
some ones of said second communications, and c) transmits results
of said operation b).
30. The system of claim 29, wherein said additional module is a
software module.
31. The system of claim 29, wherein said additional module is a
software module, running on the same processor as said active
program.
32. The system of claim 29, wherein said protocol is TCP/IP.
33. The system of claim 29, wherein said additional module
transmits results of said operation b) through said interface
module to a non-reserved address.
34. The system of claim 29, wherein said processing step b) is
performed only conditionally.
35. The system of claim 29, wherein said processing step d) is
performed only conditionally, in dependence on information in the
content of the transmission as received.
36. A system, comprising: a communications interface module which
transmits data over a communication channel; at least one active
program which sends communications into said channel through said
interface module; and an additional software module which a)
monitors at least some ones of said communications, b) selectively
modifies data in only some ones of said second communications, and
c) transmits results of said operation b) through said interface
module.
37. The system of claim 36, wherein said additional module is a
software module.
38. The system of claim 36, wherein said additional module is a
software module, running on the same processor as said active
program.
39. The system of claim 36, wherein said protocol is TCP/IP.
40. The system of claim 36, wherein said additional module
transmits results of said operation b) through said interface
module to a non-reserved address.
41. The system of claim 36, wherein said processing step b) is
performed only conditionally.
42. The system of claim 36, wherein said processing step d) is
performed only conditionally, in dependence on information in the
content of the transmission as received.
43. A computer, comprising: a network interface module which
transmits and receives data over a communication channel according
to an addressing protocol which includes non-reserved addresses and
also one or more reserved addresses which are not freely available
for external communication; at least one active program, running on
a CPU of said computer, which sends first communications into said
channel through said interface module, using non-reserved
addresses, and which also sends second communications through said
interface module using ones of said reserved addresses; and an
additional module, running on a CPU of said computer, which a)
detects ones of said second communications, b) modifies data in
ones of said second communications, and c) transmits results of
said operation b).
44. The computer of claim 43, wherein said module is a software
module.
45. The computer of claim 43, wherein said module is a software
module, and is running on the same hardware as said active
program.
46. A macro-system, comprising: multiple complex systems following
respective instruction streams; and at least one network linking
said multiple complex systems; wherein multiple ones of said
complex systems each comprise: a communications interface module
which transmits data over said network according to an addressing
protocol which includes non-reserved addresses and also one or more
reserved addresses which are not freely available for external
communication; at least one active program which sends first
communications into said network through said interface module,
using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved addresses; and an additional module which a) detects ones
of said second communications, b) processes data in ones of said
second communications, and c) transmits results of said operation
b).
47. The macro-system of claim 46, wherein said module is a software
module.
48. The macro-system of claim 46, wherein said module is a software
module, and is running on the same hardware as said active
program.
49. The macro-system of claim 46, wherein said additional module
separates protocol-related header portions of said transmission
from data content portions thereof, and performs data translation
operations on said data content portions without operating on said
header portions.
50. A modular expandable software architecture, comprising: an
application program which performs at least one class of interface
operations by looking up, in a configuration file, a network
address which is used for said interface operations; said
configuration file containing a reserved address, which does not
correspond to any externally routable address, in place of the
network address expected by said application program; and a
functional module which, when said application program attempts to
send data to said reserved address, performs data translation on
said data, and retransmits said data, as modified by said data
translation, to an externally routable network address.
51. The architecture of claim 50, wherein said module is a software
module.
52. The architecture of claim 50, wherein said module is a software
module, and is running on the same hardware as said active
program.
53. A method, comprising the steps of: (a.) from an application
program, sending out a packet, which is intended for a real
destination, to a first reserved address which cannot correspond to
any real destination; and (b.) in a translation program, looking up
a second address, corresponding to said real destination in a table
in memory, and transforming the data of said packet, and rerouting
said packet thereafter to said second address.
54. A software structure in a storage medium, comprising
instructions which, when activated by at least one processor, will
direct the processor to perform operations to implement the method
of claim 53.
55. A method for adding a data conversion function to a third-party
software program, comprising the steps of: in a configuration file,
replacing at least one target address with a respective
non-routable address; and adding a functional module which, when
the third-party program attempts to send a packet to said reserved
address, performs data translation on the content of the packet
according to stored algorithms, and retransmits the content, as
modified by said data translation, to an externally routable
address.
56. A method for adding data translation functions to a third-party
e-mail program, comprising the steps of: in a configuration file,
substituting a reserved address, which does not correspond to any
externally routable address, for the correct e-mail upload address;
and adding an functional module which, when the e-mail program
attempts to send a packet to said reserved address, performs data
translation on the content of the packet according to stored
algorithms, and retransmits the content to the correct e-mail
upload address.
57. A software structure in a storage medium, comprising
instructions which, when activated by at least one processor, will
direct the processor to perform operations to implement the method
of claim 55.
58. A software structure in a storage medium, comprising
instructions which, when activated by at least one processor, will
direct the processor to perform operations to implement the method
of claim 56.
Description
CROSS-REFERENCE TO OTHER APPLICATION
[0001] This application claims priority from U.S. Provisional
Application 60/408,096 filed Sep. 3, 2002, which is hereby
incorporated by reference.
BACKGROUND AND SUMMARY OF THE INVENTION
[0002] The present application relates to computer architecture,
and particularly to techniques for interfacing added modules into
existing e-mail programs.
[0003] Background: Computer Communications
[0004] "Computer communications" was regarded as a specialized area
in the 1960s or so, but now most communication is converging to a
paradigm of data communication. The endpoints of data communication
are not necessarily computers, but can be audio, video, or image
interfaces, sensors, switches, control units, or many kinds of
"smart" devices. Thus the established engineering principles of
computer networks are becoming applicable to a wide range of
applications.
[0005] Background: Networks, Packets, and Protocols
[0006] Computer network structure and operation is one of the basic
areas of computer science, and a vast amount of literature has been
published. One of the basic ways to structure communications over a
network is to use packets of data, as in the pioneering
"packet-switched" ARPANET which evolved into the Internet.
[0007] Background: Data Translations Generally
[0008] There are many types of transformations which can be useful
to perform on a stream or packet of data. One very common example
is compression, discussed below. Another very simple example is
hashing. Another common example is encryption and decryption, where
data is converted from a "plain" text (which can be read directly
with the appropriate application) to and from an encrypted text
(which cannot be easily read without knowledge of the secret "key"
data).
[0009] Background: Data Compression
[0010] In general, random (unpredictable) data cannot be compressed
without loss of precision. However, many types of commonly-used
data blocks are not perfectly random. To the extent that the data
is not perfectly random, it can be compressed.
[0011] A wide variety of techniques have been developed for data
compression. A popular, and very simple, algorithm is known as
"RLL" (run-length-limited) compression. This algorithm achieves
significant compression of any data stream which contains long
chains of repeated bytes, and has the advantage that it will not
produce a compressed output which is significantly longer than the
input (as some algorithms will).
[0012] Compression does not have to be lossless, but can also be
lossy. Many image compression algorithms do not permit the full
original data to be recovered exactly, and such algorithms are not
lossless.
[0013] Data compression can be particularly important when
streaming video is sent over the Internet, as is increasingly
common.
[0014] Background: Hashing
[0015] One of the simplest types of data translation is "hashing,"
where data is reversibly transformed in a way which randomizes the
statistical distribution of bytes. Hashing can be a useful way to
disarm viruses and/or provide a more nearly stochastic distribution
of data. (Equalizing symbol distribution can help in increasing S/N
ratio of data transmission.)
[0016] Background: Filtering
[0017] A special kind of data translation is filtering, where data
is transformed conditionally depending on a certain test. "Packet
filtering" is a more specific term for content-dependent routing.
Any router performs address-dependent routing, but filtering
implies that the data in the packet is analyzed in some fashion to
affect routing. (For example, packets in which a virus signature is
found may be discarded.)
[0018] Background: Digital Signature and Identification
[0019] Public-key algorithms (RSA etc.) can be useful for
authenticating digital documents. An extension of this is for
identification of the specific human who has chosen to authenticate
the document. There are many circumstances where it would be useful
for persons communicating over the Internet (or over a network) to
be able to identify themselves reliably. For example, in
arm's-length Internet sales, it can be useful to definitely
identify the other party. For another example, electronic
publishing over the internet becomes much more practical if working
access can be limited to only those users who have paid for it. For
another example, some users would like to filter incoming email to
exclude mailings (such as spam) which are not tagged with a
reliable certificate of origin.
[0020] Keys used for digital signatures are a very long series of
bits, which can be represented as long series of alphanumeric
characters. Unlike Personal Identification Numbers (PINs), it is
simply not feasible for individuals to remember them. For access
control, such key data is typically stored in a chip (or other
electronic memory), which can be embedded in a plastic card, or in
another physical object such as a ring.
[0021] Background: Interfacing to Programs
[0022] In the past decade it has become increasingly difficult to
introduce innovative business software products for the personal
computer market. Such products must be able to interface to the
widely used software application packages, and this is not always
easy. In particular, it is important for communications-related
software to be able to interface to Outlook, Notes, and GroupWise,
and none of these are easy to program for. (The documentation
provided to third-party developers is unclear and difficult to
use.)
[0023] Computer communications are a somewhat unusual area of
software development, in that many functions may need to be
combined. A user's full-range email program should be able to
handle (using calls to other programs as needed) various
compression or authentication formats, various image formats,
various audio formats, various HTML or XTML extensions, various
drawing formats, various special fonts, virus-checking, and other
new functions as they come up. (For example, the secure
communications capabilities of PGP were integrated into some email
programs, such as Eudora, long before PGP was available in other
email programs.) As this list indicates, the boundary between
browser functions and email functions has blurred somewhat in the
last decade, and this trend may continue. Thus, since email
handling necessarily involves so many different data types and data
operations, smooth integration is particularly important.
[0024] Background: Dongles
[0025] A recurrent theme in the software industry has been the
desire to find some way to make copied software unusable. One of
the earliest ways to do this was the "dongle," in which a physical
package containing an electronic key was attached to a port of the
computer.
[0026] Data Translation Architecture
[0027] The present application describes a new system architecture
for adding in functionality, and particularly for adding data
translation functions between a communications program and its
target (e.g. the outside world). The preferred embodiment achieves
this without any need to intrude on management of the TCP/IP stack;
instead, data for communication is simply addressed to a reserved
(preferably loopback) address, and is snooped by a "translation
agent" (software routine or hardware) either when it is being sent
to the network interface unit or when it is echoed back. The
translation agent can provide authentication, privacy, data
reformatting, or other such functions. In alternative embodiments
these ideas can be used in digital systems which are not computers,
or can be used as part of a firewall or gateway, or to interface
between networks using different protocols, or used in other
analogous ways.
[0028] The disclosed innovations, in various embodiments, provide
one or more of at least the following advantages:
[0029] simple interface into existing software;
[0030] added IP address uses without added stack handling;
[0031] good invisibility to viruses;
[0032] easy integration, even with undocumented e-mail
programs;
[0033] can secure all non-protocol-level data on any TCP/IP
port;
[0034] transparent to applications which use TCP/IP;
[0035] device, platform and operating system independent;
[0036] independent of any specific methodology for securing
data;
[0037] recipient-dependent email modifications are easy.
BRIEF DESCRIPTION OF THE DRAWING
[0038] The disclosed inventions will be described with reference to
the accompanying drawings, which show important sample embodiments
of the invention and which are incorporated in the specification
hereof by reference, wherein:
[0039] FIG. 1 shows a generic overview of the
translation-assistant.
[0040] FIG. 2 shows an example of implementation of the Translation
Agent into an existing application environment.
[0041] FIG. 3 shows a generic TCP/IP session.
[0042] FIG. 4 shows a client server environment using some of the
disclosed inventions.
[0043] FIG. 5 shows an environment whereby TA secures the
transmission between two TA client applications without Server
interdiction.
[0044] FIG. 6 shows secure data transmission in a peer-to-peer
environment.
[0045] FIG. 7 shows the client to server secure relationship,
and
[0046] FIG. 8 shows the server to client relationship.
[0047] FIG. 9 is a flowchart for the TA examining and processing
for transmitting data.
[0048] FIG. 10 is a flowchart for the TA examining and processing
of received data.
[0049] FIG. 11 is a sample of the devices that can be secured with
TA.
[0050] FIG. 12 illustrates the interface between Translation Agent
and application software in a device.
[0051] FIG. 13 gives an overview of the installation process.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0052] The numerous innovative teachings of the present application
will be described with particular reference to the presently
preferred embodiment (by way of example, and not of
limitation).
[0053] Translation Agent (TA) is an architecture for modifying
(e.g. securing data in the Telecommunications Control Protocol and
Internet Protocol (TCP/IP) data stream. TA is platform, operating
system and device independent. TA is independent of any specific
technology for securing or otherwise modifying the data.
[0054] TA utilizes the TCP/IP "loopback" address 127.0.0.2 and/or
other class A addresses in that range to implement a procedure
whereby TA can become a pseudo-server on and within the physical
device.
[0055] TA is then able to monitor all or specific ports on the
device and secure the data as it is transmitted or unsecure the
data as received.
[0056] TA is independent of specific protocols such as SMTP
("Simple Mail Transport Protocol"), POP3 ("Post Office Protocol
3"), FTP, HTTP etc. TA examines the data, passing protocol level
information without modification and secures the data portion of
the transmission.
[0057] TA processes and secures the data based on the requirements
and capabilities of the specific method used for securing the
data.
[0058] TA is designed to be transparent to other applications and
virus checking applications.
[0059] The TA architecture provides an open framework into which
many different algorithm implementations can be inserted as
modules. For example, for converting unsecured data to secure data
and vice versa, the TA architecture can support insertion of e.g.
LZW, DES, DES-3, Rijndael, Blowfish, TwoFish, PGP, RSA, etc.
Algorithms used can be, for example, streaming or block-oriented,
symmetric or asymmetric.
[0060] The Translation Agent architecture is modular to the extent
that a wide variety of existing encryption (or other) algorithms
can be "plugged in" to the Translation Agent. This means that any
existing or later-developed algorithm or system can be used if any
sizeable group of users demands it. The amount of administrative
overhead created by these systems is reduced, since the activities
performed within the Translation Agent module are unseen by the
user. This is particularly beneficial in corporate IT departments,
where a considerable amount of support is usually necessary to make
this systems function properly.
[0061] FIG. 1 shows a generic overview of the TA's function in a
device 101 using TCP/IP. (The device 101 can be, for example, a
personal computer, or alternatively can be a variety of other
device types as discussed below.) The configuration of a software
application 100 is modified to send and/or receive TCP/IP packets
using a reserved (e.g. "loopback") TCP/IP address 102 in place of
its original TCP/IP settings. TA module 103 is configured to listen
on the reserved address 102 specified for this application. (Note
that multiple reserved addresses can be specified for multiple
applications.) TA module 103 then initiates sessions, using the
application's data, on another TCP/IP connection 106. (The TA
module 103 retains the application's original TCP/IP address and
Port configuration data, in order to transmit and receive the
data.) For widely used applications, configuring the application
settings would be an automated installation process. In most cases,
modifications or enhancements by the application vendors should not
be required.
[0062] As denoted in FIG. 1, the configuration for the application
100 is changed to use the "loopback" address 102, and TA will then
communicate with the application 100 as though TA were the intended
destination. TA 103 will examine and modify the data as necessary,
and will forward the modified (e.g. secured) data to the intended
destination through connection 106. In the other direction, TA 103
will receive data for the application 100 from connection 106,
examine the data and unsecure it when necessary, and forward it to
the application 100 through connection 102. Thus TA 103 allows the
application 100 to be secure in transmitting and receiving its data
without modification to the application's software.
[0063] Sample Implementation: SMTP/POP3 E-Mail Client Interface
[0064] FIG. 2 is a more specific example of implementing TA into an
existing application environment. Again, the example shown is based
on a device 101, e.g. a personal computer or PDA, with TCP/IP
connectivity. The E-Mail client 100' in this example is
reconfigured so that its SMTP/POP3 interfaces send and receive on
the "loopback" TCP/IP address 127.0.0.2. Specifically, the SMTP
target address saved (with many other parameters) in system
configuration data file 108 (e.g. a Windows registry file) has been
changed to 127.0.0.2, and the POP3 address has also been changed to
127.0.0.2.
[0065] In this example the TA module 103' listens on 127.0.0.2 on
the "Well known" port 25. When the SMTP interface 100A sends an
E-Mail message and/or attachments, TA 103' intercepts the
messages.
[0066] The protocol level data is preferably be passed through
intact, but the message content (indicated by the appropriate SMTP
body tags etc.) can be transformed by the TA module 103'. That is,
the TA module 103' preferably "parses" the SMTP transmission, to
the limited extent needed to identify the message body and/or
attachments, and then (depending on is programming) performs a data
translation operation on these portions. The possibly-transformed
body and attachment data, combined with the untransformed protocol
data, is then sent along, through connection 106, to the SMTP
server that was originally specified by the application.
[0067] Correspondingly, the TA module 103' will listen on the
reserved address (in this example 127.0.0.2 on Port 110) for the
application to initiate a POP3 session. Thereafter TA 222 will
monitor the session, and if secured data is encountered for this
application/user, then the TA module 222 will unsecure the data.
Otherwise the TA module 103' can simply pass the clear data through
to the POP3 interface 100B.
[0068] Both the SMTP and POP3 data securing and unsecuring
processing are transparent to the application and virus scans
implemented at the device.
[0069] Installation of TA
[0070] FIG. 13 gives an overview of the installation process
(which, as noted, is preferably automatic.) In the presently
preferred embodiment, TA (or its installation program) initially
examines the windows registry 108 for e-mail client configurations.
(The actual entry locations and data will vary depending on the
versions of the E-Mail client and possibly the Windows operating
system.) TA extracts the client configuration (steps 1310 and 1330)
and saves the information in its own configuration file.
[0071] TA (or the installation program) then updates the windows
registry 108 with POP3 (step 1340) and SMTP (step 1320)
configurations set to a reserved address, e.g. a loopback address
127.0.0.x.
[0072] The TA module is then configured (step 1360) with logical
relations which will cause it to load whatever translation
algorithms are desired. (For example, hashing might be used for
outbound messages to some addresses, or encryption for others.
[0073] Once the TA module itself has been set up to launch
automatically, the unit can be restarted (step 1390).
[0074] TA then starts a listening function for POP3 and SMTP on the
loopback address at the well known ports for POP3 and SMTP.
[0075] When the e-mail client starts, it obtains the e-mail server
configuration from the windows registry, and is not aware of the
changes made by TA.
[0076] When the e-mail client initiates a POP3 or SMTP request, it
actually connects with TA on the same device.
[0077] TA then initiates the same type connection with the actual
POP3 or SMTP server.
[0078] TA then monitors the information, receiving from the e-mail
client and forwarding to the server and visa versa.
[0079] If e-mail is being sent (SMTP), then TA looks for the
recipient information, both primary and carbon copies. If any
recipients are in the list of registered secured recipients for the
encryption technology implemented then TA will wait for the actual
text and attachments and secure the information. If there are no
secure recipients then TA simply continues to pass the
information.
[0080] If a POP3 session is initiated then TA simply checks the
information to determine if it is in a secure format, and unsecures
the information if necessary, before passing it to the e-mail
client. If TA is not able to decrypt the information, e.g. because
the recipient is not the authorized recipient, then the information
is passed to the email client in its as-received format.
[0081] When TA is uninstalled, the uninstallation program
preferably resets the registry entries back to their original
configuration.
[0082] Preferably TA performs a test for integrity at startup. (For
example, a checksum derived from the updated registry entries can
be stored where TA can read it and check it.)
[0083] The same general interface should function for Lotus Notes
and IMAP with minor changes for these protocols.
[0084] The example refers to the windows registry, but the specific
client application may use some other form for saving its
configuration information, such as an ".ini" file, and in this case
the minimal access to registry described above is merely performed
on the appropriate .ini file or other location.
[0085] Non-E-Mail Applications
[0086] FIG. 3 shows a generic TCP/IP session with a non-email
application 100", which can include but is not limited to FTP, VPN,
HTTP, video conferencing and peer-to-peer applications. By
configuring the application 100" to send and receive using the
"loopback" addressing scheme, TA is able to secure an application's
data without modification to the application's software. TA can
secure all data or selected data based on configuration parameters.
TA can be configured using its secured configuration manager to use
a different TCP/IP port on the device or for the destination.
[0087] TA's mechanics of operation in this configuration are
similar to those of the e-mail configuration of FIG. 2. The
application's configuration data is preferably altered so that its
send routines 100A' use a non-routable address 102A (preferably a
loopback address), and its receive routines 100B' use a
non-routable address 102B (also preferably a loopback address). The
translation agent 103" is set up to capture accesses to these
reserved addresses, and to perform data translation operations on
the content of the transmissions as described above. Note however
that the retransmission functions performed by translation agent
103" can be slightly more complicated than those performed by email
translation agent 103', since the ultimate target address is not
necessarily static. Where the target address is unpredictable (as
in http: or ftp: accesses), the TA 103" is preferably configured
either to snoop and divert all communications, or else to access
dynamic routing data from inside the application 100".
[0088] Secure Communication to Interdicting Server
[0089] FIG. 4 shows a sample implementation in a client-server
environment whereby the Server requires the data to be unsecured
upon arrival. In this example an application 410, running on a
physical device 101A (e.g. a workstation), is backed up by a local
TA 420A which secures some or all of the communications over
connection 106 (e.g. a LAN or WAN routing). A corresponding
server-side TA 420S provides a complementary data translation
interface between channel 106S and a server 430. An example of this
environment could be organization with a central E-Mail server
where the client 410 secures all data to the server (in this case
E-Mail messages and attachments), and the E-Mail server 430
unsecures the data to perform a Server level virus scan.
[0090] The reverse process can also be employed, where the client
410 only receives data that has been secured by the Server even
when the originator did not have the capability. An example of this
is shown in FIG. 7, where an application 710 on a remote device
101C can communicate with the application 410, but all
communication must be routed through client-server channel 106S
which is protected by TA modules 420A and 420S. Thus in this
example the server 430 can be programmed (for example) to perform
firewall and gateway functions needed for interface to the outside
world.
[0091] FIG. 8 shows a different implementation, where client-server
communications over local channel 106L are not necessarily mediated
by TA modules, but communications which must pass over a more
exposed channel 106W are secured by TA modules 420A and 420S. Note
that this diagram is very similar to FIG. 4, except that the
channel assignments are different; in the embodiment of FIG. 8 the
local network is assumed to be protected by (e.g.) physical
security precautions, and the problem addressed is that of
providing secure communications with remote workstations.
[0092] Peer-to-Peer Implementations
[0093] FIG. 6 shows an example where data transmission can also be
secured in a peer-to-peer environment. In this example processes
610A and 610B, running on two different physical devices 101A and
101B, have their communications mediated by the complementary
operations of respective translation agents 103. Note again that
the physical devices 101 do not have to be computers, but can be,
for example, components of a computing system. Thus, for example,
in a large computing system which uses an array of asynchronous
processors to form a "compute farm," or an array of storage devices
to form a "server farm," the TA modules can be added in to modify
peer-to-peer communications. Note, however, that this modification
is not as attractive for applications where latency in
communications is a high concern.
[0094] FIG. 5 shows a different version of this, where a server 520
links one subnetwork 106C, on which an application 100C is running
on a physical device 101A, to another subnetwork 106D, on which
another application 100D is running on a physical device 101B. The
complementary operations performed by the TA modules 103 do not
disturb routability, but can be used, as described above, for
symbol equalization, hashing, or encryption/decryption
operations.
[0095] Sample Software Implementation of Translation Agent
[0096] FIGS. 9 and 10 are a complementary pair of flow charts which
show an example of implementation of the Translation Agent module
in software.
[0097] FIG. 9 shows how the TA, in this sample embodiment, handles
data transmitted by an application (to a reserved address).
[0098] Initially the TA routine simply listens to a particular
address and port for transmissions by the application program
(state 9A), and loops in this state until matched incoming data is
detected (branch 9B).
[0099] When matched incoming data is detected, the protocol portion
of it is extracted for unmodified retransmission (branch 9C). If
data translation is conditional (which it may not be), the logical
evaluations are done to see whether data modification is to be
performed (branch 9D). (Note that test 9D can be performed before
or after test 9C.) If data modification is to be performed, step 9E
determines what subroutines are to be called for securing or
otherwise translating the data, and step 9F calls the appropriate
subroutines (typically third-party modules). Finally (step 9G), the
reassembled packet (e.g. unmodified header plus modified body and
attachments) is transmitted on to an external address.
[0100] FIG. 10 shows how the TA, in this sample embodiment, handles
inbound data for an application. This example shows the particular
case when TA is used for decryption, but of course similar testing
and translation operations would apply to other uses of TA.
[0101] Initially the TA routine simply listens for transmissions to
a particular address and port (state 10A), and loops in this state
until matched incoming data is detected (branch 10B).
[0102] When matched incoming data is detected, the protocol portion
of it is extracted for unmodified retransmission (branch 10C).
[0103] The data portion of the packet is then tested to see whether
it has been secured (branch 10D), and if so the application then
determines what algorithm or algorithms must be called to unsecure
the data (step 10E). The appropriate program calls are then made
(step 10F), and the modified data, plus the unmodified
protocol-related header, are then transmitted to the IP address and
port being watched by the application.
[0104] Software Interface with Translation Agent
[0105] FIG. 12 illustrates the interface between Translation Agent
and application software in a device.
[0106] TA does not interface directly with any application
software. The interface is through a loopback address with
TCP/IP.
[0107] In the communications loop, the application software does
not even have to know that TA exists. The application simply
continues to communicate with other devices using the TCP/IP
interface. TA intercepts the transmission within the device and
takes the appropriate action.
[0108] If TA is used to secure information within a device then the
same loop interface exists, but TA loops the transmission back to
the application after having taken the appropriate action (encrypt
or decrypt).
[0109] The arrows on the document are meant to show flow of the
information. In actuality the information is normally a two way
exchange over the one connection between the software. In other
words the application probably sends and receives over one TCP/IP
connection for one function and likewise TA sends and receives over
the one connection.
[0110] Adaptation to Mobile Systems
[0111] FIG. 11 is a sample of the devices that can achieve secure
communication, using the TA, through the Internet (or other large
network). This diagram is not an exhaustive list at all, but does
give some idea of the range of applications of TA technology. The
illustrated devices, which can be connected through the Internet or
some other TCP/IP or analogous network, include without limitation:
Windows.TM. computers; Unix/Linux computers; MacIntosh.TM.
computers; PDA devices; digital cell phones; other digital devices;
mainframe computers; servers; videoconferencing stations;
Windows-CE.TM.devices; minicomputers; IP telephones; Bluetooth
devices; satellites; digital cameras; and laptop or notebook
computers.
[0112] A particularly attractive contemplated use of the disclosed
inventions is in handheld mobile internet devices. Such devices
(such as the Blackberry, or other SIM-enabled PDAs) are
increasingly coming to include substantial memory and processing
power, and are often designed for easy installation of software
applications and accessories. It is contemplated that the modular
add-on capability of a "translation agent" as described above can
be particularly advantageous for updating such systems to include
user-selected translation operations as described above.
[0113] The Blackberry, for example, uses a Java.TM. operating
system, and therefore the above functionality implies a slight
modification to the "JVM" (the "Java Virtual Machine," which any
Java-capable computer must be able to emulate). That is, Java
instructions are assumed to be executed by the Java virtual
machine, and any particular computer must be equipped with software
drivers to implement the JVM. Typically Java midlets sit on the
Blackberry to perform encryption and related functions.
[0114] XDA is a competitor to Blackberry, which uses Windows CE,
and the disclosed inventions can be similarly adapted to the
XDA.
[0115] Other implementations (in Java, embedded Linux, PalmOS, or
other system software) can similarly be ported to Epoc or other
machines, including but not limited to any "3G" or "2.5G"
phone.
[0116] In the special case of routing e-mail into PDAs (or
telephones or other mobile information appliances), the TA can also
be set up for formatting functions, e.g. for selective stripping of
attachments and/or images. This function is a normal part of
low-bandwidth wide-area wireless network communication, but the
ability to include it in the TA, where it is performed
transparently to the devices and applications involved, provides a
new capability.
[0117] Two-Translation-Agent Methods
[0118] In one class of embodiments, communications between two
Translation Agents (or more precisely, between two TA-mediated
devices) can be structured to introduce modifications (e.g. for
security) even when using protocols (such as FTP) which are
inherently unsecure. Thus TA's capabilities are not limited to
securing data in transit. TA's in combination can also implement or
enhance security and authentication functions, within the
communication architecture, which are virtually impossible to
achieve without changes in basic internet standards and/or massive
changes in software and servers.
[0119] In such embodiments, the TA's which jointly control a
communication channel can be programmed to jointly introduce
non-standard enhancements to standard protocols.
[0120] According to various disclosed embodiments of the present
invention, there is provided: A system, comprising: a
communications interface module which transmits data over a
communication channel according to an addressing protocol which
includes one or more reserved addresses which are not freely
available for external communication, and also includes
non-reserved addresses; at least one active program which sends
first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications to said interface module using ones of said reserved
addresses; and an additional module which a) detects ones of said
second communications, b) modifies data in ones of said second
communications, and c) transmits results of said operation b).
[0121] According to various disclosed embodiments of the present
invention, there is provided: A system, comprising: a
communications interface module which transmits data over a
communication channel according to an addressing protocol which
includes non-reserved addresses and also one or more reserved
loopback addresses which are not freely available for external
communication, and which echoes back data addressed to one of said
reserved addresses; at least one active program which sends first
communications into said channel through said interface module,
using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved loopback addresses; and an additional module which a)
detects ones of said second communications, b) modifies data in
ones of said second communications, and c) transmits results of
said operation b).
[0122] According to various disclosed embodiments of the present
invention, there A system, comprising: a communications interface
module which transmits data over a communication channel according
to an addressing protocol which includes one or more reserved
addresses which are not freely available for external
communication, and also includes non-reserved addresses; at least
one active program which sends first communications into said
channel through said interface module, using non-reserved
addresses, and which also sends second communications through said
interface module using ones of said reserved addresses; and an
additional module which a) detects ones of said second
communications, b) modifies data content portions thereof but not
protocol-related header portions thereof, and c) transmits results
of said operation b).
[0123] According to various disclosed embodiments of the present
invention, there is provided: A system, comprising: a
communications interface module which transmits data over a
communication channel according to an addressing protocol which
includes one or more reserved addresses which are not freely
available for external communication, and also includes
non-reserved addresses; at least one active program which sends
first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved addresses; and an additional module which a) detects ones
of said second communications, b) modifies data in ones of said
second communications, and c) transmits results of said operation
b); and which also d) intercepts and modifies at least some
incoming transmissions directed to said active program.
[0124] According to various disclosed embodiments of the present
invention, there is provided: A system, comprising: a
communications interface module which transmits data over a
communication channel according to an addressing protocol which
includes one or more reserved addresses which are not freely
available for external communication, and also includes
non-reserved addresses; at least one active program which sends
first communications into said channel through said interface
module, using non-reserved addresses, and which also sends second
communications through said interface module using ones of said
reserved addresses; and an additional module which a) detects ones
of said second communications, b) selectively modifies data in only
some ones of said second communications, and c) transmits results
of said operation b).
[0125] According to various disclosed embodiments of the present
invention, there is provided: A system, comprising: a
communications interface module which transmits data over a
communication channel; at least one active program which sends
communications into said channel through said interface module; and
an additional software module which a) monitors at least some ones
of said communications, b) selectively modifies data in only some
ones of said second communications, and c) transmits results of
said operation b) through said interface module.
[0126] According to various disclosed embodiments of the present
invention, there is provided: A computer, comprising: a network
interface module which transmits and receives data over a
communication channel according to an addressing protocol which
includes non-reserved addresses and also one or more reserved
addresses which are not freely available for external
communication; at least one active program, running on a CPU of
said computer, which sends first communications into said channel
through said interface module, using non-reserved addresses, and
which also sends second communications through said interface
module using ones of said reserved addresses; and an additional
module, running on a CPU of said computer, which a) detects ones of
said second communications, b) modifies data in ones of said second
communications, and c) transmits results of said operation b).
[0127] According to various disclosed embodiments of the present
invention, there is provided: A macro-system, comprising: multiple
complex systems following respective instruction streams; and at
least one network linking said multiple complex systems; wherein
multiple ones of said complex systems each comprise: a
communications interface module which transmits data over said
network according to an addressing protocol which includes
non-reserved addresses and also one or more reserved addresses
which are not freely available for external communication; at least
one active program which sends first communications into said
network through said interface module, using non-reserved
addresses, and which also sends second communications through said
interface module using, ones of said reserved addresses; and an
additional module which a) detects ones of said second
communications, b) processes data in ones of said second
communications, and c) transmits results of said operation b).
[0128] According to various disclosed embodiments of the present
invention, there is provided: A modular expandable software
architecture, comprising: an application program which performs at
least one class of interface operations by looking up, in a
configuration file, a network address which is used for said
interface operations; said configuration file containing a reserved
address, which does not correspond to any externally routable
address, in place of the network address expected by said
application program; and a functional module which, when said
application program attempts to send data to said reserved address,
performs data translation on said data, and retransmits said data,
as modified by said data translation, to an externally routable
network address.
[0129] According to various disclosed embodiments of the present
invention, there is provided: A method, comprising the steps of:
(a.) from an application program, sending out a packet, which is
intended for a real destination, to a first reserved address which
cannot correspond to any real destination; and (b.) in a
translation program, looking up a second address, corresponding to
said real destination in a table in memory, and transforming the
data of said packet, and rerouting said packet thereafter to said
second address.
[0130] According to various disclosed embodiments of the present
invention, there is provided: A software structure in a storage
medium, comprising instructions which, when activated by at least
one processor, will direct the processor to perform operations to
implement the method of claim 42.
[0131] According to various disclosed embodiments of the present
invention, there is provided: A method for adding a data conversion
function to a third-party software program, comprising the steps
of: in a configuration file, replacing at least one target address
with a respective non-routable address; and adding a functional
module which, when the third-party program attempts to send a
packet to said reserved address, performs data translation on the
content of the packet according to stored algorithms, and
retransmits the content, as modified by said data translation, to
an externally routable address.
[0132] According to various disclosed embodiments of the present
invention, there is provided: A method for adding data translation
functions to a third-party e-mail program, comprising the steps of:
in a configuration file, substituting a reserved address, which
does not correspond to any externally routable address, for the
correct e-mail upload address; and adding an functional module
which, when the e-mail program attempts to send a packet to said
reserved address, performs data translation on the content of the
packet according to stored algorithms, and retransmits the content
to the correct e-mail upload address.
[0133] Definitions:
[0134] Following are short definitions of the usual meanings of
some of the technical terms which are used in the present
application. (However, those of ordinary skill will recognize
whether the context requires a different meaning.) Additional
definitions can be found in the standard technical dictionaries and
journals.
[0135] The term "network" is used very generally in the present
application, to include wireless as well as wired, optical as well
as electrical, local area networks (LANs) and wide area networks
(WANs), the Internet, and closed networks (such as that used by the
banking system).
[0136] "TCP/IP" is a network addressing protocol dating back to
ARPANET, and now in very wide use. The "IP" addresses used by
TCP/IP have the format of four numbers, each less than 2{circumflex
over ( )}8, separated by periods. (Each of these numbers
corresponds to two bytes of data, i.e. 8 bits.)
[0137] A "packet" is a block of data, in a defined format, which
can be routed independently of other packets; standard rules permit
a stream of data to be converted to or from packets.
[0138] A "port" is a local destination designator: TCP/IP packets
include a two-byte port designation in addition to the eight bytes
of IP address. Of the 64K possible port designations, a few (mostly
within the first 1K) have standard assignments--see
http://www.faqs.org/ftp/rfc/rfc1340.txt, which is hereby
incorporated by reference. For example, port 110 is normally
reserved for POP3, 25 for SMTP, 80 for HTTP, and 23 for telnet.
(One of these standard assignments is specifically referred to,
confusingly, as the "well-known" port.)
[0139] A "reserved address" is an address which cannot be routed
over the Internet. In TCP/IP these include the loopback addresses
discussed above, and a few other blocks of "non-routable" or
"unresolvable" addresses (all 10.x.x.x addresses; all 90.x.x.x
addresses; 172.16.x.x through 172.31.x.x; and 192.168.x.x).
[0140] "Virtual private networks" (VPNs) are network-type
communication schemes which embed limited-access constraints within
communications over the Internet (or other open or less-secure
network). Some common examples of these are referred to as
extranets.
[0141] A "hub" is a hardware device which echoes packets from one
physical network connection into others.
[0142] A "router" is a programmable hub which is normally used to
echo packets from a local network into the Internet, and vice
versa. A router can be programmed, for example, for
address-dependent transmission, address translation, port-mapping,
and "firewall" and other such higher-level functions.
[0143] A "firewall" is a special network interface function which
performs authorization checking, refuses unauthorized connections,
and may also do address translation, port-mapping packet filtering,
and other high-level functions. Firewall functions are commonly
integrated with router hardware, but can be implemented
separately.
[0144] "Packet filtering" is content-dependent routing. Any router
performs address-dependent routing, but filtering implies that the
data in the packet is analyzed in some fashion to affect routing.
(For example, packets in which a virus signature is found may be
discarded.)
[0145] "Packet sniffing" is an operation which extracts the
contents of packets and (possibly depending on contents, addresses
or both) saves them elsewhere.
[0146] SMTP (Simple Mail Transport Protocol) and POP3 (Post Office
Protocol 3) are commonly-used e-mail protocols (one for outgoing,
one for incoming). SMTP implementations in which extra functions
have been added are sometimes referred to as "ESMTP."
[0147] GSM is a cell phone standard--see e.g.
http://www.iec.org/online/tu- torials/gsm/ and links therein, all
of which are hereby incorporated by reference. "SMS" (standard
Short Message Protocol) and "GPRS" (Global Packetized Radio
Service) are also defined by the GSM standard.
[0148] "JVM" is the "Java Virtual Machine" which any Java-capable
computer must be able to emulated. That is, Java instructions are
assumed to be executed by the Java virtual machine, and any
particular computer must be equipped with software drivers to
implement the JVM.
[0149] Modifications and Variations
[0150] As will be recognized by those skilled in the art, the
innovative concepts described in the present application can be
modified and varied over a tremendous range of applications, and
accordingly the scope of patented subject matter is not limited by
any of the specific exemplary teachings given.
[0151] Translation Agent modules are capable of being daisy chained
for special functions. In a circumstance such as an environment
with multiple encryption technologies, a primary TA would receive
and interrogate the data. If it found data it could recognize as
another encryption technology or a recipient who is configured for
receiving in another supported encryption technology, then TA could
open a connection using a loopback address and predetermined port
and pass then information to that TA processor. The secondary TA
would not necessarily know that the information was routed from a
primary TA rather than any other TCP/IP stream.
[0152] While the invention is particularly advantageous with TCP/IP
address protocols, it can also be used with IPX, NetBEUI, NetBIOS,
SMB (used for file and print sharing in MS Network) or other
protocols, as long as there is a reserved address which can be used
for internal communications (intra-chassis or intra-system).
[0153] As noted, the disclosed inventions are particularly useful
for adding capability to third-party application programs. Some of
the programs which are expected to benefit particularly from this
are Notes, Eudora, Outlook, Outlook Express, Groupwise, but of
course other commercial software packages can also benefit.
[0154] An important security benefit is that, in many embodiments,
the data translation into a secure format occurs totally inside the
system box. This provides an interesting synergy with computers (or
other devices) where the CPU itself controls opening of the box, by
a "hoodlock" mechanism. (See e.g. U.S. Pat. No. 6,307,738, which is
hereby incorporated by reference.) In such cases the TA's
resistance to hacking combines advantageously with the hoodlock's
protection against physical intrusion.
[0155] In an alternative and less preferred class of embodiments,
reserved addresses which are not loopback addresses can be used
instead. In this case the TA can merely snoop communications, and
grab packets which are directed to the particular reserved
address(es) it recognizes.
[0156] In another alternative and less preferred class of
embodiments, addresses can used for TA interception which are not
defined as "reserved" within the protocol. In this case the
addresses assigned for TA interception must be ones which will not
be the target of any legitimate address generated by application
software. For example, when Network Address Translation is being
used, it is possible to define the rules so that some
otherwise-permissible IP addresses should not appear at some points
within the network topology. In this case such addresses can be
used to define a "hidden call" to a TA routine at a gateway or
router. Here too the TA can merely snoop communications, and grab
packets which are directed to the particular reserved address(es)
it recognizes.
[0157] In another alternative and less preferable class of
embodiments, the TA can be used in high-speed networks, such as are
used in computation clusters or server farms. Here too the
disclosed architecture provides a simple way of adding an overlaid
structure into an existing network interface architecture. However,
in this environment the TA module should of course have a
throughput which is high enough not to impose a bottleneck into the
communications channel.
[0158] Note that multiple different functions can optionally be
assigned to different reserved (loopback) addresses: e.g. FTP,
locking functions (dongles), secure email, https:, VPN (of whatever
configuration) and others can each be assigned to its own loopback
address. This allows multiple different routines to be called
merely by specifying an appropriate TCP/IP reserved address, or
alternatively different routines can each snoop data content of
messages sent to some (but not all) of the reserved addresses.
[0159] In one alternative class of embodiments, the TA module can
include biometric identification functions. In such embodiments the
processing performed by the TA module can be made dependent on
various authentication components, such as voice recognition, face
recognition, input from a portable electronic key, manual entry of
a password or PIN, etc. The sensors and interfaces needed for
finger-print or retinal identification are not currently part of a
normal personal computer, and the input for facial recognition is
not on all computers, so a hardware security module which
implements securitization with the TA interface can include
dedicated sensor input connections, or even dedicated sensors. For
added security these authentications can be combined with required
GPS or time relations.
[0160] The present application refers to the "TA module" where it
is not necessary to specify whether the described functions are
implemented in hardware or in software (or both). There are
advantages to be gained in either case; an implementation with
separate hardware has the potential to be more secure, but is more
cumbersome to install.
[0161] The disclosed inventions are believed to be particularly
advantageous for wireless networks, which are inherently insecure.
(Where the intended RF or IR interfaces have omnidirectional
antennas, an eavesdropper's the antenna gain is a potential extra
margin which can make the insecure area much larger than the useful
area.) For similar reasons, the disclosed inventions can be
particularly useful for WANs, where extensive signal routing
outside the premises may be necessary.
[0162] Typically the data sent out onto a network will have
originated in a CPU, but in the present application this term is to
be construed broadly to cover anything with computing
capacity--e.g. a gate array, microcontroller, mainframe, etc.
[0163] In one alternative embodiment the TA module can include
dedicated routines and/or hardware for video and graphics
decompression and buffering, to facilitate handling of streaming
video.
[0164] Where the disclosed TA is used with a multiprocessor
computer, the CPU which is sending communications requests may not
be the same one executing translation routines.
[0165] References to digital data do not preclude later adaptation
of the disclosed innovative teachings to analog or multi-bit
data.
[0166] One contemplated class of alternatives requires the
router/firewall to have packet filtering capability. In this case
the router can be programmed so that NO packets go out unless they
include (or are preceded by) a signature from the TA. Where this
degree of firewall blockade is available, it is not necessary to
divert packet addresses coming out of the application; instead the
TA can merely snoop outgoing traffic, and retransmit with
authentication only packets of translated data, and packets which
do not need to be translated.
[0167] Additional general background, which helps to show the
knowledge of those skilled in the art regarding the system context,
and of variations and options for implementations, may be found in
the following publications, all of which are hereby incorporated by
reference: Mark Nelson, "The Data Compression Book" (2.ed.) (ISBN
1558514341); Gilbert Held, "Personal Computer File Compression"
(ISBN 0442017731); Arturo Trujillo, "Translation Machines:
Techniques for Machine (ISBN 1852330570); Tim Kientzle, "Internet
File Formats" (ISBN 188357756X); Gunter Born, "The File Formats
Handbook" (ISBN 1850321175); Bob Quinn and Dave Shute, "Windows
Sockets Network Programming" (ISBN 0201633728); Peter Loshin, "Big
Book of World Wide Web RFCs" (ISBN 0124558410); Ralph Droms, "DHCP
(Dynamic Host Configuration Protocol)" (ISBN 1578701376); and Eric
Hall, "Internet Core Protocols--The Definitive Guide" (ISBN
1565925726).
[0168] None of the description in the present application should be
read as implying that any particular element, step, or function is
an essential element which must be included in the claim scope: THE
SCOPE OF PATENTED SUBJECT MATTER IS DEFINED ONLY BY THE ALLOWED
CLAIMS. Moreover, none of these claims are intended to invoke
paragraph six of 35 USC section 112 unless the exact words "means
for" are followed by a participle. Moreover, the claims filed with
this application are intended to be as comprehensive as possible:
EVERY novel and nonobvious disclosed invention is intended to be
covered, and NO subject matter is being intentionally abandoned,
disclaimed, or dedicated.
* * * * *
References