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

[David Maurus]

First of all, sorry if this is the wrong list for comments like this, I
haven't found a more suitable one.

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 reasstmbly 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 as published 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 relate
to the FTP protocol (IMHO). 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 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" (ftp client library
functions). The ftp client program 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.

> 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
reqd request (by calling a corresponding function in the FTP library
that will retrieve a file via the FTP "GET" command) that would 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 can be seen 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
(STRU), 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 to port 20 [this is the default] 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. (Disclaimer: IANAL)

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

Best Regards,
David Maurus