Prior Art on US Pat. 5,265,261 [=FTP?]

[David Maurus]

I've sent this mail to the main samba list today - after some more
digging I assume that it is better directed to this list (the jCIFS list
seems to also be mainly used for user questions). Sorry for
crossposting. At least I've corrected some spelling errors since...

-------- Original Message --------
From: David Maurus <lists at mailbag.de>
Subject: [Samba] Prior Art on US Pat. 5,265,261 [=FTP?]
To: samba at lists.samba.org

As you might be aware, Microsoft explicitly mentions US patents
5,265,261 and 5,437,013 in its new CIFS license. Below is my shot at an
analysis of the main claim of pat 5,265,261.

Here is a link to patent 5,265,261 [long, might need reassembly when
line-wrapped!]
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5,265,261'.WKU.&OS=PN/5,265,261&RS=PN/5,265,261

IMHO the described methodology resembles the FTP protocol as published
in RFC 959 in October 1985 (there were even earlier versions before -
starting at around 1971).

I'll dissect the main claim into little pieces and show how they IMHO
relate to the FTP protocol (in brackets). I read the main claim as
follows:

> 1. A computer implemented method in a computer system for
> transmitting data from a server computer to a consumer computer
> connected by a virtual circuit
In plain English: we have a client, a server, a virtual circuit (e.g. a
TCP/IP session, like a FTP Control Connection from the client to the
server's port 21), and we use this setup to transmit data from the
server to the client...

> the consumer computer having an application program requesting
> a read from the server computer, having a redirector, and having
> a transport, the application program having access to a data
> buffer allocated by the application program, comprising the steps of:
The client runs an application (FTP command line client frontend)
requesting a read from the server computer (FTP "GET" command), having
subsystems we call "redirector" and "transport" (the latter being a ftp
client library). The client application has allocated a data buffer...

> allocating and initializing a receive network control block for
> directing the transport to store the next data it receives directly
> in the data buffer;
The client opens a listen socket ["initializing a receive network
control block"] (in FTP this would be listening on port 20 for incoming
data connections) and tells its "transport" component (ftp client
library) to store the next data received directly into the previously
allocated buffer. (this is done via a call to the library - further
parameters - besides the buffer - will be passed to the lib, as detailed
in the following lines)

> transmitting from the redirector to the transport a read request
> to read data from the server
Then the client transmits via the redirector (?) to the transport the
read request (by calling a corresponding function in the FTP library
that will retrieve a file via the FTP "GET" command) that will tell the
server to send some data

> and said receive network control block for directing the transport
> to store the read data directly in the data buffer,
and the client also gives the "transport" component (again, for this
exercise, a ftp client library) the socket handle and the allocated data
buffer where the data is to be stored directly.

> the read request indicating that the read data should be transmitted
> without a header;
It should be possible to deduct from the read request that the data
should be sent without a header (I am not extremely familiar with the
FTP protocol, but in FTP this would be the default meaning of the "GET"
command, unless other transfer modes or file structures are set,
specifically one needs to use "Stream Mode" as transfer mode and "File"
as File Structure, which are both the default values according to RFC
959)

> in response to the step of transmitting, sending the read request from
> the transport to the server computer;
the "transport" component sends the read request to the server computer
(our library sends "GET filename" to the ftp server via the control
connection)

> examining and recognizing that the read request indicates that the
> read data should be transmitted without a header;
and the server - as has been mentioned a lot of times now - can see from
the command that it should not send a header with the data

> storing the read data in a data block without the header;
The server reads the data and stores it in a data block, as requested
without header (like any simple ftp server that mallocs some memory and
fopens and freads the requested file - there are also no headers
involved here)

> transferring the data block from the server computer to the transport
> in response to the step of sending the read request;
Now the datablock is transferred from the server to the client (using
the FTP protocol, this would be opening the FTP Data Connection from any
port on the server computer e.g. to port of the client computer, and
sending the data) 

> and in response to the read request and the receive network control
> block and in response to the step of transferring, storing the data
> block directly from the transport into the data buffer.
The client (more specifically in my FTP analogy, the ftp client library)
subsequently stores the received data in the previously allocated data
buffer


CONCLUSION: In my eyes this resembles the FTP protocol very closely, not
to mention that I cannot see any invention here that any average
programmer wouldn't be able to come up with within some hours. The minor
nit-picks like "data is transferred WITHOUT header" should not matter
IMHO, but I think FTP would even match this. (Disclaimer: IANAL)

This is my point of view, I hope I haven't missed something.

Best Regards,
David Maurus