 |
Description  |
|
|
FILED OF THE INVENTION
This invention relates to a system for text communications between a
plurality of terminals.
DESCRIPTION OF THE BACKGROUND ART
It is known to transmit messages using a telex. In telex communication,
coded digits are transmitted from one terminal to another, which is
dialled up using a number found from a publicly available directory. The
receiving terminals signals back to indicate that contact has been made,
and acknowledge receipt of a message. The message is printed at the
receiving terminal.
It is also known to communicate messages by facsimile. In facsimile
transmission, a document is scanned and encoded using image compression
coding. The encoded image (not the text it represents) is transmitted to a
facsimile receiver, where it is printed out.
Text may also be transmitted using electronic mail systems, in which a
transmitting terminal dials up a central message storage computer and
transmits a message to be stored under a designated mailbox therein. The
intended recipient of the message will then later dial the central
computer and read his message. Similar text communication systems include
bulletin board systems, in which messages are stored in a bulletin board
computer and subsequently read by the intended recipient.
The above systems may thus be divided into point to point systems (telex
and facsimile) in which messages are transmitted direct to the recipient,
and stored and collect systems (electronic mail) in which a message is
deposited in a mailbox and then subsequently read.
SUMMARY OF THE INVENTION
The invention provides a communication system comprising a plurality of
terminals, each of which comprises a computer connected through a modem to
a public telecommunications network, each terminal being arranged to
receive messages whilst unattended and to transmit back an acknowledgement
that the message has been received, and to store the message in electronic
form. Each terminal is arranged also to be able to transmit messages, and
to keep a number of messages ready for transmission, and upon a failure to
successfully transmit a message, to keep retrying.
The system therefore provides a flexible text communications system
enabling a user to "post" a text message into the system, secure in the
knowledge that it will eventually be dispatched to the intended recipient
and its receipt will be acknowledged.
Very preferably, the system includes a high level check that the message
has been received intact; for instance, the file size of the message to be
transmitted may also be transmitted, and after receipt the receiving
station may check the size of the file received. The acknowledgement in
this case is made conditional upon the received file size matching that
transmitted.
The system according to preferred embodiments of the invention can be
operated by office staff with a minimal knowledge of computers or
telecommunications. The invention is particularly suitable for use for
communication between the offices of law firms, or between law firms and
Courts, or between law firms and clients, because it provides a relatively
high degree of certainty that the message has arrived uncorrupted,
together with acknowledgement by the recipient that the message has
arrived, and preferably the date and time of receipt. The use of point to
point text transmission also involves the transmission of only a fraction
of the data involved in facsimile transmission, and is correspondingly
much cheaper.
Further, a received document can be edited using standard word processing
software, and retransmitted back immediately. This is of particular value
in drafting complex and lengthy legal documents.
Still further, in a preferred embodiment, the analogy to electronic post is
extended by ensuring that once a copy of the message is transmitted, the
original is deleted from the transmitting station so that only a single
copy of the message is in existence. This would not generally be possible
in the prior art, without the inventive features of acknowledgement and
checking of messages provided herein. This provides the advantage that
multiple copies of a single document do not simultaneously exist; the
problems caused by the simultaneous existence of a single document in
various stages of editing will be familiar to the reader.
This invention relates to a system which permits one or more terminals to
communicate by means of a communications channel (at any one time for each
link possible between terminals only 2 terminals may be in communication
to the exclusion of any other terminal wishing to communicate with them on
the same link for the duration of that session) permitting the automatic
response to a communications link request, negotiation of link and session
parameters and transfer of data files from a transmitting terminal to a
receiving terminal under automatic operation and with capability to
automatically resume execution of data file transfer requests
notwithstanding any loss of operational power to the terminals or loss of
the communications link by extraneous causes, without requiring identity
verification of the terminal requesting to transfer data files either by
means of no verification being required or by means of a universal
verification of identity for all like terminals.
The invention in its elements is illustrated by the attached state
diagrams, one for the "TX" mode and one for the "RX" mode, dealing with
transmission requested functions of the invention and received
transmissions functions respectively.
In a preferred implementation of the invention the terminal system will be
capable of operating in receive transmissions mode only, such that,
notwithstanding the existence of any stored action datafile which would
otherwise require execution by the transmission functions, only reception
of transmissions from other terminals will be transacted until such time
as a change of this state is effected, under user or system control by
reference to external parameters, such as time or other events occurring.
For example, to allow stored action data files specifying transfers to be
executed only after a certain local time to make best use of
telecommunications service charging rates differentiated by usage within
certain time periods.
Whereas there exists in prior art implementations of systems comprising
similar functions requiring that communications links may only be
established with another terminal, but appropriate identification
verification information is supplied prior to any access to the call
recipient system being made available, this invention makes no such
requirement and thereby greatly facilitates the automated transfer of data
files between such terminals as have the need for identities to be known
and verification information disseminated, the only identification
information being required by any user of such terminal being the
communications node identifier of the desired recipient terminal (such as
a telephone number).
Whereas in prior art systems exist which provide communications links for
automated file transfer, this invention does not permit any incoming data
file to be transmitted into the store of the receiving terminal other than
into a holding area wholly under the control of the software arranged to
implement the system, thereby permitting the system to operate to
implement the avoidance of data file name clashing and by means of the
aspects to be described below to permit unique identification and
verification of the received files through transfer logs maintained by the
system. Whereas this invention also entails that, on the completion of any
data file transfer the receiving terminal makes verification through the
store or disk operating system local to it against the integrity checking
data previously supplied by the transmitting terminal corresponding to the
data file just sent. This independent check is carried out after
completion of the execution of the file transfer protocol and provides a
second program independent level of verification and data integrity
checking which goes to the verification that no errors have occurred in
the process of storing of the data file just transferred. In addition, for
evidential purposes, as acknowledgement is made by the receiving terminal
after verification, the invention by means of the maintenance of a
transfer log data file on the sending and receiving terminals (which
record the fact of acknowledgement by independent verification of the
integrity parameters of the data file sent in a manner that requires no
user intervention) this invention thereby facilitates use of the transfer
log record as evidence for legal purposes of the fact of the full and
complete receipt of the datafile transfer completed.
In a preferred implementation where content verification is required at a
higher level, this invention permits the automatic archiving of a copy of
the transferred data file to uneraseable store within the transmitting
terminal.
Whereas the invention requires use of discrete logical areas for storage of
all received data files by reference to identification data supplied by
the transmitting terminal, the invention permits the operation of a secure
system for receipt of data files without risk of overwriting existing data
files on the receiving terminal's store and thereby automatically
implementing methods for avoiding data file name clashing and automatic
unattended reception insofar as the constraints of the receiving
terminals' local store capacity permit.
The invention's use of logical areas discreet to its operation permits the
implementation of a terminal with logical areas for reception which are
also linked to logical areas for collection by other terminals (upon
supply of identification data for such collection logical area) to the
effect that data files therein contained may be retransmitted to a
receiving terminal for such a connected logical reception and collection
area pair. The same aspect of this invention is for the purposes of
non-coincident transmission and collection by different terminals of the
same data files without requirement for identity verification (although in
a preferred implementation identity verification may be implemented by the
operator).
The invention's operation of discreet collection areas permits the
"polling" by a remote terminal initiating a request to a terminal for
transmission to it of any files held in a logical data area by reference
to the logical data area name alone and without requirement of
identification of any data file names or content thereof.
The invention's operation of such logical areas permits the establishment
of logical areas having attributes which are for collection one time only
on multiple occasions dependent on operator preference. Such facility
allows the implementation of multiple remote collections of data files in
the manner previously described for collection one time only. All of these
facilities provide a means of securely regulating the retrieval by remote
terminals of data files from an unattended terminal by automatic operation
of the system.
Other preferred aspects and embodiments of the invention are as described
and claimed hereafter.
BRIEF DESCRIPTION OF DRAWINGS
The invention will now be illustrated, by way of example only, with
reference to the accompanying drawings, in which:
FIG. 1 shows schematically a terminal according to a preferred embodiment
of the invention connected to a public telecommunications network;
FIG. 2 shows schematically two terminals in text communication;
FIG. 3 shows schematically a display upon a terminal having received a
message;
FIG. 4 shows schematically the arrangement of programs within the terminal;
FIGS. 5A and 5B form a single FIG. 5 comprising a state diagram showing the
operation of the SFTI program on receiving a message;
FIGS. 6A and 6B form a single diagram comprising a state diagram showing
schematically the operation of the STFI program on transmitting a message;
FIG. 7A is a diagram showing transaction queue management; and
FIG. 7B is a diagram showing a transfer log.
DESCRIPTION OF PREFERRED EMBODIMENTS
Referring to FIG. 1 a terminal station 1 for use in a system according to a
preferred embodiment of the invention comprises a CPU (central processor)
10 coupled to a memory section 20 (typically comprising program, read only
memory or ROM and working read-write or random access memory RAM), a
keyboard 30 for manual data input, a VDU (visual display unit) 40 such as
a cathode ray tube or liquid crystal display, a disk drive or other mass
storage unit 50 (for example, a hard disk drive, typically of the
Winchester type) and a modem 60 connectable to a telephone line or other
communication channel. A floppy disk drive may also or alternatively be
provided, to allow text files to be transferred in or out on disk.
The whole terminal 1 may be typically provided by a personal computer (PC)
for example of the IBM (TM) compatible type, expanded to include the hard
disk 50 and modem 60.
For example, in one embodiment the CPU 10, memory 20, keyboard 30, VDU 40
and disk drive 50 may all be provided as an IBM PC80 or XT compatible such
as the NEC PC. It is preferred that the memory 20 should include 640K
read-write memory, and that the hard disk 50 should have a capacity of at
least 1.5 megabytes.
The modem 60 employed in the invention needs to have the capacity to
provide automatic answering (auto-answer) and is preferably "smart" modem.
Suitably, the modem is arranged to employ the control codes developed by
Hayes (i.e. is Hayes compatible). Examples of suitable modems are the
Miracom Courier HST 9600 modem operating at 960 baud employing
international standard V22 bis 2400, V22 1200, and V21 300 transmission
protocols, providing MNP 1-5 error correction data encoding; the Miracom
Quad 2400 (four speed) modem operating at 2400 baud, V22 vis 2400, V22
1200, V21 300 or V23 1200/75 rates employing the same error correction as
above; or the Miracom 2400E (three speed) modem which offers the
facilities of the Quad 2400 except V23 transmission rates.
The modem 60 may be connected to a standard IBM compatible PC providing the
CPU 10 via the RS232 socket thereon.
Referring to FIG. 2, where a message is to be transmitted from a first
station 1A to a second station 1B, the message is typically input by a
user via the keyboard 30A and stored as a file (typically a word processor
file) on the disk drive 50. The user will then instruct the CPU 10A to
cause the transmission of the file, by issuing, an appropriate command via
the keyboard 30A (or, alternatively, using some other form of input device
such as a mouse). The user inputs the destination to which the file is to
go, and the CPU 10A provides a phone number and causes the modem 60A to
seize the telephone line 70 to which it is connected, generate appropriate
tone or pulse dialling signals to dial the required number, establish the
link and transmit the message.
At the receiving station, 1B, the modem 60B detects the ringing signal and
answers the incoming call. Typically, the modem will at this point sense
the speed of the incoming signal and set its receiving rate accordingly,
if it is a multi-rate or standard modem. The text data is transmitted by
the modem to the CPU 10B, and stored as a file on the received station
disk drive 50B.
When the message is received, the CPU 10B of the receiving station 1B
generates an acknowledgement message which is transmitted back via the
telephone line 70 through the receiving modem 60B to the transmitting
modem 60A, and is logged and stored by the transmitting station CPU 10A.
To indicate that a message has been received, the VDU 40B of the receiving
station displays an envelope icon 401 corresponding to the received
message, preferably, as shown, with an indication of the identity of the
intended recipient as shown in FIG. 3.
It will be noted, in connection with the above description, that
transmission is direct from one station to the other and not via a central
mail computer. It will further be noted that each station, when acting as
the receiving station 1B, will answer a call without a password checking
stage; the object of the invention is that each terminal should, like a
facsimile receiver, accept any message directed to it.
FIG. 4 shows generally a schematic arrangement of the software held in the
memory 20 under control of which the CPU 10 operates to embody the
invention. A user interface program, typically of the WINDOWS(TM) type
developed by is provided, for handling inputs from the keyboard 30 or
other input device (e.g. mouse) and screen displays on the VDU 40. An
operating system communicates with the hard disk 50; for example, the disk
operating system (DOS) provided by Microsoft for operation with the IBM
PC.
A word processing program 130 is arranged to receive inputs and generate
outputs via the user interface 110 and to handle text files via the disk
operating system 120. A user may thus create a text file for storage on
the hard disk 50, or within random access memory 20.
As different terminals may employ different word processors 130, preferably
a word processing format conversion program 140 is provided for
translating between the character formats and control codes used by
different word processing files. Thus, an incoming message in one format
may be converted to be readable by another, or a text file generated using
a given word processor may be converted to the format of another for
transmission (or, indeed to plain ASCII).
By way of example, the format conversion program may be the Software Bridge
(TM) product which is commercially available. The conversion program 140
may be arranged to detect the format in which a document to be converted
is, and effect format conversion automatically; for instance, when a
received document is found to be in Wordperfect (TM) format and the word
processor is in another predetermined format, the WP format converter 140
converts from Wordperfect (TM) to the predetermined format automatically.
Optionally, a document comparison program 150 may be provided such as the
Docucare (TM) product; products of this kind are arranged to compare two
files (for example a received file as a subsequently edited file) and to
display differences between the two (for example, by highlighting). This
is particularly useful when preparing complex legal documents.
A communications package 160 (for example the Odyssey (TM) package
mentioned above) is connected to the modem 60 by the serial port and
controls reading files from and writing files to the modem 60.
A compression and decompression package 170 receives a text file and
produces a compressed text file, and vice versa; the compression may be
the PKZIP/UNZIP package, for may execute any suitable
compression/decompression (for example, Lempel-Zir).
Controlling the overall communications process is the secure file transfer
interface program 180 forming an important part of the present invention.
The SFTI 180 is arranged to respond to user commands via the user
interface 110, to control the receiving and acknowledging of messages, and
the transmitting of messages.
It is also possible for a user to command a terminal to interrogate another
terminal to collect a message already received by that other terminal, and
correspondingly for an interrogated terminal to deliver a received
message. Whilst sending and receiving messages requires no password, and
is open to any member of the public, collecting a message does require a
password. A terminal will not deliver a message when remotely interrogated
by another unless the correct password is employed. Likewise, it may be
provided that whilst a message may be received by a receiving terminal, it
can only be read (i.e. displayed on the VDU 140 or filed off onto a disk)
upon typing in a password via the keyboard 30.
The SFTI 180 is arranged to be a "state machine"; that is, to pass between
clearly define states in limited and clearly defined transitions. This
provides a particular advantage that the current state may be recorded on
non-volatile store (e.g. hard disk 50) so that if power is lost
temporarily the terminal 1 upon recovering power can read the present
state from the hard disk and return to the same operation where it left
off.
The SFTI 180 maintains a list of the text sending and text retrieving
operations which it must perform. The present operation which it is
performing is likewise stored on a non-volatile store (e.g. the hard disk
50) and thus, upon recovering, the SFTI 180 can establish which job it was
processing and resume the operation after power loss.
The list or queue of jobs in hand is continually reviewed; once one job is
completed, the next in the queue is processed.
The jobs or transactions in the list or queue may all be for immediate
execution or may have times of execution specified so that the SFTI 180
may be left to transmit a document at a particular time.
Optionally, other programs may also be resident. For example, a database
access program may be provided to enable access to selected databases and
downloading of files therefrom; for example, for use in a lawyer's office,
legal precedent or case law databases such as Lexis (TM) may be accessed.
A file of passwords for such access may therefore be stored on the hard
disk 50.
Likewise, programs to allow text conferencing via access to a central host
computer may be provided; this allows several users to edit and process
the same document in conference simultaneously, from different sites
around the world.
The SFTI 180 maintains a logged file indicating each major event or task
which it performs. Thus, each file transmitted and each file received are
logged, together with the date and time. This provides a valuable record
of messages transferred to and from.
The SFTI is very preferably arranged to control the operating system 120
such that when a file is successfully transmitted and acknowledged as
being received from the distant terminal, it is deleted from the disk
drive 50. Thus, only one copy of a message is in existence at a given
time; this increases the security of the system and prevents confusion
between multiple files with the same name having different text, or the
same text.
DESCRIPTION FOR THE SFTI 180
The LIX SFTI is implemented as a program module within a number of modules
compiling the current LIX application software for IBM compatible PC's
running Microsoft Corp USA's (Microsoft) disk operating systems (DOS)
versions 3.0 and above.
The SFTI and other modules for LIX application program are implemented in a
combination of the programming language of a communications application
program known as ODDYSEY, Copyright Skyro Software Limited and Micropack
Limited both of Aberdeen, Scotland in the United Kingdom and of which the
only individual author is Don Milne also of Aberdeen, Scotland in the
United Kingdom; compiled executable program code and Microsoft's DOS batch
command language.
The LIX application software integrates commercially available compression
software being the programs known as PKZIP AND PKUNZIP published by PK
Ware Inc. USA, current version No. 1.1. This compression software is
utilised by the SFTI module to ensure the avoidance of datafile name
collision in received files in named mailboxes, by the device of
compressing all files received during a transmission (which are received
into a temporary holding area on the processor's store) into one
compressed data file which is given a unique holding name.
In the option of the transmitting, operator files selected for transmission
may be compressed by the same compression software prior to transmission
into a file whose name is generated to have a unique name for practical
purposes (in that the incremented code using Alpha numeric characters
forming part of the datafile name does not repeat in under 10,000
iterations makes the probability of the same sender transmitting over
10,000 compressed data files to the same recipient and the same mailbox
name without the recipient opening any of the received data files and
removing any from the mail box, is regarded to be beyond practical concern
for this implementation).
The SFTI module determines whether a received data file is already in
compressed form at the time of receipt and will not further compress if
so. All received data files are, once in compressed form, copied from the
holding area of the machine's store to the logical area within the machine
store corresponding to "mailbox names" designated by the sending operator
as the recipient's name. This is implemented by, within Microsoft DOS,
creating a directory which is a sub-directory of the relevant global
mailbox directory with the name of the recipient as designated by the
transmitting terminal during the SFTI session.
TRANSMISSION OF FILES BY THE SFTI MODULE
In the current implementation the SFTI processes action files created by
the main user interface module 110 by virtue of interaction with the user
setting up desired transfers to be executed by the SFTI module. These
action files are processed in a "queue" and have their contents
individually processed by means of a temporary file during the execution
of transmission sessions to the effect that the SFTI is for most practical
purposes capable of resuming any transmission session automatically,
notwithstanding any interruption due to power supply failure to the
transmitting terminal or communications link loss, from the point after
the last successful action executed by the SFTI during the previously
abortive session. To enable this automatic resumption to operate the
relevant terminal's software and data files are arranged to automatically
invoke the LIX program upon power being restored to the CPU and store, by
means of the automatic execution batch file of the Microsoft DOS. The SFTI
module, by making a datafile record of its state on the machine's store is
able to ensure that the SFTI module is reinvoked in the event of such an
abortive interrupted session in send and receive mode (as opposed to
receive only mode which normally would be invoked if the LIX software were
invoked without the previous occasion of running having been an
interrupted execution of the SFTI module in send/receive mode).
COLLECTION MAILBOXES
By means of the LIX user interface module 110 of the LIX software, the user
operator is enabled to select data files for placing into a logical area
of the store of the machine so that the same data files may be available
for collection automatically by a remote LIX terminal. By virtue of stored
datafiles containing data supplied by the user operator the same logical
areas of the store may have access restricted by way of a password,
although this is not a requirement of the invention or the implementation.
The effect of this arrangement is that a remote LIX terminal may, in
executing a stored action data file containing data provided at the
instruction of the user operator, retrieve all the files held in such
logical area by reference to the name of such logical area and on
supplying the corresponding verification password for such area.
In the current implementation of the SFTI module the logical area
corresponds to a sub-directory of the global director for all "collection
mail boxes". Data files are copied into such sub-directories by the LIX
user interface module on the completion of a user specified collection
transaction.
As described in the SFTI invention technical description the implementation
in the current LIX software permits 3 kinds of collection logical areas,
or "mailbox".
SINGLE COLLECTION MAILBOX
The first is an ordinary collection mail box which has a name and may have
a password (the current version of the SFTI module will only make
collections by supplying a password for the desired mail box although it
is technically feasible within the invention for no password to be
required, this has not been implemented). On the SFTI receiving a call
when a request for collection is made the name of the desired mail box to
collect from is required and supplied by the remote terminal. Upon
verification that the mail box exists on the local terminal's store the
local terminal requires the provision of a password, if a password entry
is found in the relevant data file. In the single collection only mail box
implementation the first successful session via remote LIX terminal to
provide the appropriate name and any password will collect by transfer a
copy of all data files held at that time in the relevant mail box. The
special feature of the single collection mail box implementation is that,
on successful complete transfer of all data files to the remote terminal,
the local SFTI module deletes all copies of the data files from the
relevant mail box and removes the logical area or directory from the
terminal's store (for reasons of housekeeping). This allow LIX to
implement one of its particular features, namely that when the contents of
a collection mail box have been collected the mail box contents do not
remain (in the single collection implementation).
MULTIPLE COLLECTION MAIL BOX
In the multiple collection mail box implementation which is effected by
setting of user defined data in a data file operated upon by the SFTI
module, the SFTI operates in identical manner to the foregoing description
of the single collection mail box, except that by virtue of holding copies
of the data files contained in the relevant mail box in a temporary area
the LIX SFTI module restores all the data files that would otherwise be
deleted in the single collection implementation.
"THROUGH" MAIL BOX
The "through" mail box implementation is set by the user supplying relevant
data for a data file read by the SFTI a given mail box name is treated as
a "through mail box".
The effect of a "through mail box" is that all data files received into an
incoming mail box of that name are automatically copied, immediately after
a session in which they were received, to a collection mail box of the
same name. By virtue of the original incoming data file copies being
retained in the incoming mail box area the operator or user has the
opportunity to examine all data files received into a "through mail box"
notwithstanding that the contents of the outgoing mailbox "pair" may have
been cleared by virtue of a collection by another remote LIX terminal
before they are aware of the receipt.
"Through mail boxes" may also be designated, at user preference, multiple
collection mail boxes in which case the copies of the data files received
into the "pair" incoming mail box are restored to the collection mail box
by the SFTI module upon every complete transmission.
LINK ERROR CORRECTION
In the current implementation of the SFTI module, link error correction is
established, which is important to the operation of the SFTI at speeds in
excess of 1200 baud as otherwise data transmitted between terminals during
the automated session would be liable to line noise corruption, thereby
compromising the reliability of the automatic operation on the SFTI send
and receive functions. By way of data files recording the user's terminal
capabilities, the particular modem device connected to the terminal may be
designated as capable of providing link error correction itself. The SFTI
will optionally provide link error correction in software by means of the
Microcom Networking Protocol ("MNP") up to level 5 as published by
Microcom Inc., USA. The link negotiation being conducted in accordance
with the protocol and being capable of being established between the SFTI
communications program (ODYESSY) and any other LIX terminal, irrespective
of whether the link error correction in MNP is being provided by the
remote terminal's modem or SFTI module, subject to conformance in the case
of the modem with the published protocols.
In the current implementation of the SFTI module, where the SFTI module is
required to provide link error correction, by virtue of the settings
contained in the data files relevant to the settings of the program, any
call which does not establish an MNP error corrected link will be
automatically rejected prior to any SFTI session commencing.
FILE TRANSFER PROTOCOL
In the current implementation of the SFTI no negotiation of file transfer
protocol between the LIX terminals during a SFTI session is required,
notwithstanding the possibility arising out of the invention, as only one
file transfer protocol available in the ODYSEEY communications program is
best optimised for link error corrected communications, where the burden
of overall error correction in the communications chanel is best provided
by the link error correction in MNP. The file transfer protocol employed
is therefore the implementation of 2 modem as published by Chuck Forsberg
of, USA, but with the omission of any features in the 2 modem protocol not
required for simple file transfer or resumption of file transfer to an
existing file of the same name. This latter limitation is implemented in
order to provide security against unauthorised manipulation of the
operating system functions that would otherwise be available through Z
modem to a remote terminal operated otherwise than by a sending SFTI
module (e.g. a hacker).
MODEMS
In the current implementa | | |
