FAX OVER INTERNET
The present application claims priority of U.S. Provisional patent application serial no. 60/036,814 filed February 3, 1997.
Field of the Invention
The present invention relates to a facsimile communication system of the type in which a sending facsimile machine transmits to a local server which, in turn, sends the facsimile transmission data via a data network to a remote server at a destination, which in turn transmits the facsimile data to a destination facsimile machine.
Related Prior Art
A known prior art system is disclosed in U.S. Patent 4,905,273 to Gordon et al., published in 1990. This patent discloses a discrete device which is placed between a facsimile machine and a public switched telephone network (PSTN), which transmits the calls to a long distance receiver. This differs substantially from the invention of the present application, which is directed to an entire system linking a caller fax machine to a destination fax machine. The invention of this application further distinguishes from the prior art reference to Gordon et al. in that it includes feedback for account authorization and transmission.
Summary of the Invention
It is an object of the present invention to provide a facsimile communication system which facilitates ease of connection of a user's facsimile machine to the system. It is a further object of the present invention to provide a facsimile communications system which provides improved reporting of facsimile transmissions to the user.
According to a first broad aspect of the present invention, there is provided a facsimile communication system comprising a facsimile communications system comprising: at least one fax modem means including DTMF decoding means; account authorization means connected to the fax modem means for identifying a caller and authorizing receipt and forward of a facsimile transmission; means connected to the DTMF decoding means for obtaining a desired destination facsimile number from the caller; means connected to the fax modem means for storing a facsimile transmission sent by the caller, along with the desired destination facsimile number; and data network communications means for sending a data file containing the stored facsimile transmission and the number over a data network.
Preferably, the system further comprises means connected to the data network communications means for receiving a transmission report from a remote server means located near to the desired destination facsimile number and connected to the data network for receiving the data file; and means for communicating to the caller at least a failure of the stored facsimile transmission from successfully being transmitted to the destination number . Also preferably, the system further comprises a remote server means located • near to the desired destination facsimile number and connected to the data network for receiving the data file; and remote facsimile transmission means for connecting to the desired destination facsimile number over a telecommunications network, and for transmitting the stored facsimile transmission to a facsimile machine at the desired destination facsimile number.
Further preferred features of the present invention are set out in the appended claims.
Brief Description of the Drawings
The invention will be better understood by way of the following detailed description of a preferred embodiment with reference to the appended drawings in which:
Figure 1 is a schematic block diagram of the facsimile communication system according to the preferred embodiment ;
Figure 2 is a schematic process diagram of the preferred embodiment; and
Figure 3 is a flow diagram of the steps according to the method of the preferred embodiment.
Detailed Description of the Preferred. Embodiment As shown in Figure 1, the facsimile communication system has a plurality of fax modems connected to a first local telephone network to which a caller fax machine and a caller telephone can connect. The fax modems in the preferred embodiment are Hayes Optima external modems (Model 08-02752) which include DTMF decoding capability, voice generation capability and Caller ID data communication ability. The account authorization means, which is part of the "VGetty" process, receives the Caller ID data from one of the fax modems and looks up in a client database whether this telephone number corresponds to that of an existing customer ' s telephone number and answers the call. The account authorization means sends the appropriate data to the fax modem to generate a suitable voice greeting welcoming the caller. If the telephone number corresponds to the telephone number of an existing client, the caller is then prompted to enter an authorization code similar to a PIN.
The account authorization means then receive the DTMF codes decoded by the appropriate fax modem and confirms that the code is correct. If the code given is incorrect, then a voice prompt to re-enter the correct code is given until a maximum number of tries has been
exhausted after which the fax modem is signaled to hang up and the account authorization means records in the client database that further attempts to use the customer's account are to be frozen until an operator confirms the correct authorization code with the customer. Once the correct code has been given and the account authorization means authorize the receipt and forward of a facsimile transmission from the caller, the account authorization means sends to the fax modem the data required to generate a voice prompt requesting the caller to enter the destination telephone number.
The destination number detector is signaled by the account authorization means to record the subsequent telephone number detected by the DTMF decoding means in the fax modem. If the destination number can be determined to be an invalid number, then the destination number detector sends the appropriate data for a voice prompt informing the caller that the number dialed is incorrect and prompts the caller to redial the number. Upon receipt of a complete destination number, the destination number detector sends the appropriate data to the fax modem to prompt the user to send the fax.
The facsimile transmission is stored by the fax storage unit and when complete, the fax storage unit signals the data file sender to prepare a data file containing the desired destination facsimile number, the facsimile data file (preferably in TIFF format) along with a job ID identifying the transmission. The data file sender then determines which remote server is best located to handle re transmission of the facsimile transmission. The data file is then sent through the data network (for example the INTERNET) to the remote server.
The remote server stores the data file received and commands one of its fax modems to place a local or intermediate distance long distance telephone call over a telephone network near to the destination fax machine so
that the facsimile image can be sent from the remote server to the destination fax machine.
A remote transmission reporter creates a transmission report from the information concerning the events taking place, and the transmission report is sent from the remote server through the data network back to the originating data file sender which then stores the transmission report in a log storer. If the transmission report indicates a failure, the transmission reporter local to the caller generates a facsimile transmission report page and sends it over one of the fax modems and the local PSTN to the caller's facsimile machine. If the transmission was a success, then a log reporter includes the transmission result in a daily log which is sent on a daily basis to the caller's fax machine. At the stage of account authorization, a caller may press a code indicating a request for an immediate log of all facsimile transmissions and the log reporter may be prompted to prepare and transmit an interim log report to the caller's fax machine.
As can be appreciated, the local server system can be provided by the appropriate software in a general purpose computer. In the preferred embodiment, the software which receives and sends the fax information is "HylaFax" software which is shareware software available from the Internet at "http://www.vix.com/flexfax/".
Local IFX servers are installed on the Internet at points of presence to form a global network. Each IFX server provides service in its own defined local area. The routing over the Internet between the IFX servers is controlled from a central location which is constantly updated. The central location also handles the accounting, billing, administration, management and revenue sharing between the Service Points. Subscribers to the service do not need any special equipment or software to use the service and take advantage of the cost savings.
The steps carried out according to the preferred embodiment are illustrated in Figure 3.
Example A customer or subscriber in Bombay (sender) wants to send a fax to Tokyo (recipient). The user calls (accesses) from his fax machine the Bombay IFX server, is automatically identified, dials the number of the recipient in Tokyo and starts the fax. The Bombay IFX server accepts the message, forwards it to the Tokyo IFX server. The Tokyo IFX server delivers the fax by dialing the fax designated by the local Tokyo number. In the event of a delivery problem the sender will receive notification thereof. Long distance charges are eliminated since calls are local at both sending and receiving ends The service can therefore be offered to the user at a much lower cost. The recipient need not be a subscriber. The recipient can be a fax or any equipment that operates like a fax e.g. computer with fax capability.
The following table illustrates the process.
"Rcvd" Process Combines and gets destination Forwarding and transmits phone # from follow-up of fax information to "Vgetty" transmission Local Hylafax gets info on over the Client. received fax : Job Internet ID, rate, format, becomes filename reliable and decides to which easy. Remote Hylafax Server to send the fax job
Local Hylafax Transmits fax Client over IP Network to remote Hylafax Server
Remote "Hylafax Receives fax Server" information
Remote "Hylafax Delivers fax to Server" destination #
Remote "Hylafax Sends email to Server" "Notify21og" process on local fax server
End customer Receives his fax
10 "Notify21og" Terminates the receives & follow-up of fax process on local fax analyses email transmission fax server transmission updates forwarding over "accountlog" Internet and faxes notification final delivery to sender in event becomes of problem with automated, delivery generates a basis for accounting and billing database automation of subscriber notification of delivery
VGETTY Process Description
The process is invoked by the local HylaFax fax server with two arguments :
Device ID • Caller ID
The VGETTY process first checks the second argument, the Caller ID, on a list of authorized phone numbers . If a match is not found, VGETTY plays a voice message asking for a fax number to send info on the service. The number consequently entered by the user is captured by the process using DTMF decoding. After a thank you voice message, the process hangs up. If the captured number is valid, information on how to join the Service is forwarded to the user by fax.
If, on the other hand, the Caller ID is authorized, a different voice message is played asking the subscriber to enter the destination fax number. Any time during or after the voice message, the process can capture the destination fax number using DTMF decoding. The captured number is stored in a file which is retrieved later by the RCVD process.
Once captured the fax number is converted to the canonical form : +<country codeXlocal part>
A subprocess, CANONIZE, is then started to determine to which remote server the incoming fax should be forwarded. This subprocess can return one of the following three results. • The remote server can be determined, and the destination number is stored in a file.
If the destination cannot be reached because the destination is not within our service area, A voice message indicating that the location cannot be reached is played and the call is terminated.
• The last case is when the captured phone number has an invalid format, and the call is terminated.
When terminated, the process returns control to the local HylaFax fax server.
RCVD Process Description
RCVD is a customized process that runs on the fax server computer. It is invoked by the fax server after a fax has been received and stored in a queue, in the TIFF format. A list of arguments are passed to this process including, the file name of the TIFF fax file duration time of receiving the fax protocol • connection rate error message device
TSI (transmitter subscriber identification) caller ID After all the above information is organized, four more pieces of information are processed, the destination number is retrieved from a file stored by VGETTY and converted to the canonical format "+<countrycode><local part>" by the subprocess CANONICAL the number of fax pages received is determined by examining the TIFF file using the FAXINFO subprocess. and thirdly, the sender's phone number is also be converted into canonical form. The RCVD process then invokes the ROUTE subprocess to determine the name of the .destination fax server. ROUTE processes the destination number by looking up the H0ST2PH0NE mapping table and returns with one of the following results : • no host can be mapped to the destination number - an error is returned. destination number is invalid - an error is returned, a mapping is found - the remote server is returned.
The last step of this process is to direct a fax client process to transmit the fax to the predetermined server and terminating with creating a log entry containing the information including the job ID,
destination server, date and time, caller ID, TSI, duration time of receiving the fax, number of pages in the fax document, the destination number, and the status SND which is updated later by the N0TIFY2L0G process after the outgoing fax job has been delivered to the fax machine at the final destination.
N0TIFY2L0G Process Description
N0TIFY2L0G is invoked when an email has been received by the local fax server from the remote fax server. This email contains three piece of important information required to determine the final status of an outgoing fax job, i.e. at the delivery
• Job Identification Number, • Name of the remote server that processes the outgoing job,
• Status of the delivery of the fax.
N0TIFY2L0G analyzes the email using the subprocess SETSTAT to parse and extract information contained in the email. One of the following three results is reported after the email is analyzed, the email contains no job ID - the email is discarded and N0TIFY2L0G terminates.
• a parsing error occurs (email format not recognized), the email is discarded and N0TIFY2L0G terminates. all three pieces of information are successfully extracted from the email and SETSTAT proceeds to find an entry in the log that matching the job ID and server name. The status field of the entry is updated to the status extracted from the email.
In the last case, the updated status can be, OK - fax delivered to destination successfully ERR - general error occurred BSY - the line was busy. Tried but did not get through • NAW - no answer to that number
NCR - no carrier. May be a voice number.
Any status other than "OK" invokes the subprocess FAXRESULT to return to the sender a fax with the reason why the fax could not be delivered.