EXCLUSIVE: 1995 Newsgroup posting proposing VoIP predates Verizon, Sprint patents

This one's quite a story. I am not a patent attorney, but I would think that this info would be useful to all the players involved in the VoIP patent infringement cases between Vonage and Verizon, and Vonage and Sprint.
Written by Russell Shaw, Contributor

This one's quite a story. I am not a patent attorney, but I would think that this info would be useful to all the players involved in the VoIP patent infringement cases between Vonage and Verizon, and Vonage and Sprint.

Dan Connor, who runs the Vonage Forum, has just found a 1995 Usenet Newsgroup (remember them?) post that appears to describe elements of a VoIP network. He thinks the post could be held up as a depiction of prior art.

Prior art often negates patent claims, and sometimes the patent itself. Taking that into account, the relevance of what I am going to cite here to the Vonage-Verizon and Vonage-Sprint cases to be decided next week is obvious. 

Keep in mind that VoIP- and most of the companies we know of today that offer this tech- weren't even a gleam in their VC Daddy's eye back then.

The post was submitted to TELECOM Digest on September, 22, 1995 by Jack Decker. Here's the post:

I would like to offer up a suggestion for a product, or perhaps I should say a technology. This is an idea that I had that is really an extension of existing products, but I want to go on record as proposing this now so that when someone gets the bright idea in a few months or years, I canpoint to this as "prior art" (the Telecom Archives ARE permanent, aren't they?). 

The idea is this: At some point on the Internet you have a server that connects to the telephone network. It can detect ringing and seize (answer) the line, or it can pick up the line and initiate outdialing. So far all of this can be done using existing products (modems, forexample). But what I would then propose for this new technology is to take the audio from the phone line and convert it into an audio data stream that can be sent to another location on the Internet. In a similar manner, this product should be able to accept an audio stream from the Internet and send it out to the phone line.

On the user (client) end, a companion product (designed to work with the server) would operate similar to IPhone or another two-way voice over Internet product, except that when the server receives a ringing signal from the telephone line, it would sent a data packet to the user's program that would cause an audible (or other) signal to sound or appear on the video display of the user's computer.

The user could then take some action to "answer the phone" by causing the server to take the phone line offhook and start the audio streams flowing, and the computer user would then be able to hold a conversation with the telephone caller. Or, if the user wished to make an outgoing call, they could enter a number to be called and then take some action (keypress, mouse click, etc.) that would cause information to be transmitted via the Internet that would cause the server to take the line offhook, dial the requested number using touch tones or dial  pulses, and then start the audio data streams flowing, permitting the user to converse with a called party.
In this situation, the telephone line would come into one location that is connected to the Internet, and the user of the line could be almost anywhere else on the Internet. They'd be able to answer an incoming call, or place an outgoing one, and then talk using an IPhone or similar type interface. Depending on the user's hardware (sound card) and preference, the connection could be half duplex (either "press a key/button to talk" or VOX type operation), or nearly
full-duplex (I say "nearly" because there would be a slight delay inherent in sending audio streams via the Internet).

For those familiar with amateur radio phone patches, this would be a similar type of connection, except that instead of connecting a telephone line to a radio transceiver, it would connect to a device that converts digital audio data streams sent via the Internet to and from analog signals compatible with the telephone line.

I would expect that there would be some sort of authentication between the client and server sides, probably in the form of a password required to use the server (which would be sent automatically any time a command was sent to pick up the line). And care would have to be taken that once a connect was initiated, no other user could "break in" and grab the open line.

On the other hand, the server should be capable of accepting connections from more than oneclient (and multiple passwords, in case more than one user should be allowed to have accessto the server, and you want to have an accounting of which user was connected at any particular time).
The uses should be obvious ... any time you want to answer a phone line or place a call from a remote location that has an internet connection, and don't care about a slight time delay (whichmight be pretty minimal on some connections), this technology could be used. Assuming decent connectivity, the connection (from the telephone side) should sound no worse than, say, a patched call from a two-way radio (or even from some cellular phones!).
Basically, this would be the equivalent of an "off premises extension" using the Internet. One possible application, given sufficently well connected sites, would be to allow people to take calls coming into a call center from another off-premises location, using the technology I have proposed to carry the audio while they use some other software (either local software or another net application) to actually look up information, enter orders, etc. You'd probably need an ISDN line or other high capacity "pipe" to the off-premises location to get audio quality and transmission speed sufficient to make this work.
Please, no flames about whether this SHOULD be done, how much "bandwidth" it will consume, etc. Both regulations and the capacity of Internet connections vary from place to place. What is illegal or a drain on bandwidth in one place may be quite legal, and consume only a fraction of a percent of available bandwidth in another place. And as we all know, regulations prohibiting bypass of the phone company are being lifted in many places (if they're not gone already) and
higher capacity "pipes" are being constructed all the time (just as a side note, I mentioned the bandwidth issue regarding audio streams to a friend who works at an ISP. He said that these would hardly be noticed on their network, but they have a relative large "pipe" to the backbone. YMMV. especially with a smaller provider).

The main ideas I want to have on record as "prior art", in case nobody's tried to patent them yet (I hope), are:

1) The idea of taking a unidirectional or bidirectional digital audio stream from the Internet and converting it to analog and sending it to or from a telephone line,
2) The idea of using client software at a user's site on the Internet to remotely control another device on the net that can initiate a call or answer a call (this is prior art anyway, as folks have used remote modems on the internet for over a decade, but this may be the first
time this has been proposed in connection with a device that would send real-time audio streams to and from the line).

3) The idea of using authentication with such a system, so that whenever a command is sent that would take the phone line off hook, the command string would include a password or other mechanism that would be verified by the server to insure that the user actually has authority to remotely control the line.

4) And just to cover all the bases, I'll also suggest that an adapation of this idea would allow someone to call into the Internet using a server, have the call transported some distance over the Internet as digital audio streams, and then sent back out into the public switched telephone system at a distant point. I'm not suggesting this would work well, would be legal, or should be done, but I want to go on record as saying it would be possible with the right hardware and software.
Note that although I make reference to the Internet at several points above, this technology could work in a similar manner on a private or corporate network. One final comment: It would be nice if perhaps a later version of this technology would offer conference call capability (for example, one or more users on the Internet and one or more "off-net" users connected via phone lines, all taking turns on a voice conference).
It will be interesting to see how long it will be before someone comes up with this technology. It's not a question of "if", it's a question of "when", IMHO. I'd like to see it offered sooner rather than later, and at a low enough price that companies and individuals can afford
Well, that's my idea, as sent to the TELECOM Digest on September 15, 1995. If anyone's already come up with something like this, I'm not aware of it, so please let me know. On the other hand, if anyone decides to proceed with building this technology as a result of this article, I'd be happy to help beta test the result (from the user side, of course!)

It will be interesting to see how much weight this 1995 posting is given. 

Editorial standards