[comp.org.usenix] How come include file patent isn't mentioned in position paper?

smb@ulysses.att.com (Steven Bellovin) (05/09/91)

In article <NIX.91Apr29140634@valis.asd.sgi.com>, nix@asd.sgi.com (Sold to the highest Buddha) writes:
> dc@caveat.berkeley.edu (Dave Cottingham) writes:
> 
>    Is this include file patent a hoax,
> 
> I posted the same question several months ago and got nothing back in
> the way of references.  As far as I'm concerned it's a net.legend.

The patent number is 4,674,040, issued on June 16, 1987 to Barbara Barker,
Irene Hernandez, and Rex McCaskill, and is assigned to (blare of trumpets)
IBM.  RMS kindly provided me with the number a few weeks ago; I just
got a copy of the patent.

The essence of what they're saying is new is that they keep a
back-pointer to the include file.  If you take the merged file, and run
it through some formatter, and then edit the result, the changes are
fed back to the included files.

That said, they are trying to claim more or less the #include
directive.  Well, not exactly -- to quote their Claim 1 precisely, they
claim

	A method for merging a portion of one document into another
	document, said method comprising:
	  (a) including a reference to said another document to said
	  portion; and
	  (b) causing said portion to be merged with said another
	  document and displayed in merged form.

So to violate their patent, one would have to have a facility that let
you specify just a *portion* of a file to be included...  Big change,
right?  Not obvious to ``one skilled in the art''?

Subsequent claims mention that the merged document must be in editable
form, that it must include the back pointers, that changes are
propagated back (the real thing they did, or think they did), and
another claim I'm having trouble translating from the legalese.

Other sins in the patent include using ``cursor'' as a verb.

I confess -- I disagree with Stallman about the concept of software
patents.  We've had our email discussions on the subject.  But I think
we can all agree that abuses of the patent system are another matter
entirely.


		--Steve Bellovin

jbuck@janus.Berkeley.EDU (Joe Buck) (05/09/91)

>> dc@caveat.berkeley.edu (Dave Cottingham) writes:
>>    Is this include file patent a hoax,

In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
>The patent number is 4,674,040, issued on June 16, 1987 to Barbara Barker,
>Irene Hernandez, and Rex McCaskill, and is assigned to (blare of trumpets)
>IBM.  RMS kindly provided me with the number a few weeks ago; I just
>got a copy of the patent.

In that case (unless it took the Patent Office 10 years or more to process
the application), clearly there is no danger of gcc or g++ being found
in violation of the patent, since the first C compiler that used #include
as it is now used is far, far, older than 1987, and court decisions have
made it clear that using prior art is never a violation of a patent,
even if the patent is found to be valid (IBM's patent would then be
restricted to be much narrower in scope, covering only the specific
application it was filed for).

Still, the patent clearly should not be granted, because it claims things
that had been in common use for years.

I was concerned that this might be a much older patent, in which case there
really would be a danger.
--
Joe Buck
jbuck@janus.berkeley.edu	 {uunet,ucbvax}!janus.berkeley.edu!jbuck	

guest@geech.ai.mit.edu (Guest Account) (05/09/91)

In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:

   I confess -- I disagree with Stallman about the concept of software
   patents.  We've had our email discussions on the subject.  But I think
   we can all agree that abuses of the patent system are another matter
   entirely.

OK one more time.  This is your brain (o).  This is your brain on
patents (*).  Ssssssssss.   Just say no.

---BARBARA BUSH

barmar@think.com (Barry Margolin) (05/10/91)

In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
>So to violate their patent, one would have to have a facility that let
>you specify just a *portion* of a file to be included...  Big change,
>right?  Not obvious to ``one skilled in the art''?
>
>Subsequent claims mention that the merged document must be in editable
>form, that it must include the back pointers, that changes are
>propagated back (the real thing they did, or think they did), and
>another claim I'm having trouble translating from the legalese.

This sounds much fancier than the standard #include file mechanism.  Most
#include facilities don't have any way to specify portions of files, only
whole files.  An #include mechanism in a programming language
implementation doesn't have to provide a way to save or display the merged
document, although it may be useful for debugging purposes.  And I've never
heard of one that automatically propogates changes in the merged document
back into the include file.

I suspect they're describing something from DCA (IBM's Document Content
Architecture, I think) or DISOSS (their DCA-based OA system).  Who claims
that #include in any C compiler infringes on this patent?

>Other sins in the patent include using ``cursor'' as a verb.

Any noun can be verbed.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

dricejb@drilex.UUCP (Craig Jackson drilex1) (05/11/91)

In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
[In response to an article asking about the "include file patent".
>
>The patent number is 4,674,040, issued on June 16, 1987 to Barbara Barker,
>Irene Hernandez, and Rex McCaskill, and is assigned to (blare of trumpets)
>IBM.  RMS kindly provided me with the number a few weeks ago; I just
>got a copy of the patent.
>
>The essence of what they're saying is new is that they keep a
>back-pointer to the include file.  If you take the merged file, and run
>it through some formatter, and then edit the result, the changes are
>fed back to the included files.

Interesting...

The only product which I've used which has that capability is Microsoft
Word for Windows.  Of course, they have all sorts of cross-license
agreements with IBM.

However, my reaction to seeing it was, "Gee, somebody finally went to the work
of doing that."  I suspect that in software there is a fine line between
a new idea, and an idea that everybody has thought of but which seemed too
expensive in implementation time.  If somebody really comes up with a way
to do it in 10 lines of code, maybe they should get a 7-year patent on it or so.
However, if a large company merely throws programmer time at something
and implements something brute-force that should not be patentable.

Claimer: I disagree with RMS on software patents, but feel that 17 years
is a longer monopoly than necessary.  This probably holds true for many
other fields, too.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

bzs@world.std.com (Barry Shein) (05/11/91)

From: barmar@think.com (Barry Margolin)
>This sounds much fancier than the standard #include file mechanism.  Most
>#include facilities don't have any way to specify portions of files, only
>whole files.

Sure they do:

File A:

	#define USESTUFF
	#include <junk.h>

junk.h:

	...whatever...
	#ifdef USESTUFF
	...more whatever...
	#endif /*USESTUFF*/

I know, sounds silly, but who knows once the lawyers start making
claims. That it's not slick doesn't deny its existence. It's fully
general. But I don't think this is the issue.

>I suspect they're describing something from DCA (IBM's Document Content
>Architecture, I think) or DISOSS (their DCA-based OA system).

I agree.

I doubt C compilers would be in trouble as that's definitely prior
art. If anything I think that's the point here.

In fact, the C '#include' is almost an exact clone of PL/1's
'%include' facility (note the name similarity!)

Which IBM might own.

Hmm.

(Anyone know if the PL/1 pre-processor was part of the original VDL
specification? It should be fairly easy to look up. Do other PL/1
compilers generally implement this pre-processor? Is any of this
relevant to the issue?)
-- 
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD

sef@kithrup.COM (Sean Eric Fagan) (05/12/91)

In article <GUEST.91May9010033@geech.ai.mit.edu> guest@geech.ai.mit.edu (Guest Account) writes:
>OK one more time.  This is your brain (o).  This is your brain on
>patents (*).  Ssssssssss.   Just say no.
>---BARBARA BUSH

Oooh.  Such a compelling argument.  Carries about as much validity as the
drug commercial so grossly parodied.

And so brave of you, too, to use your real name.  I can see how convinced
you are of your position.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

marc@dumbcat.sf.ca.us (Marco S Hyman) (05/12/91)

In article <BZS.91May10200405@world.std.com> bzs@world.std.com (Barry Shein) writes:
 > 
 > From: barmar@think.com (Barry Margolin)
 > >This sounds much fancier than the standard #include file mechanism.  Most
 > >#include facilities don't have any way to specify portions of files, only
 > >whole files.
 > 
 > Sure they do:

 [[ description of #define method of partial file inclusion deleted ]]

Some compilers provided support for partial file inclusion, too. The
Burroughs algol (and derivative) compilers had a compiler command named:

    $ include <file option> <start option> <stop option>

You could do things like

    $ include "filename" 100 500    % include lines 100 - 500 from "filename"

and then later in the code say

    $ include			% includes the remainder of the last file.

I just refreshed my memory from a book published in '77.  The idea could be
much older than that.  Certainly it's nothing new.

 > Is any of this relevant to the issue?)

Don't know.

// marc
-- 
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc

drake@drake.almaden.ibm.com (05/12/91)

In article <27383@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
>                                   If somebody really comes up with a way
>to do it in 10 lines of code, maybe they should get a 7-year patent on it or so.
>However, if a large company merely throws programmer time at something
>and implements something brute-force that should not be patentable.

Hmm, I disagree with this on 2 levels.

First, what you said seems to boil down to:

	If I invest $20.00 in an idea, I should get fully exclusive 
	use of it for 7 years.
	If I invest $1,000,000 in an idea, I should get nothing in return.

Come again?  

If what you really meant was that short, elegant algorithms should get
preferential treatment over expensive, ugly ones, well, they do.  If I
figure out an expensive way to do something, I can patent it.  If you
then come out with an elegant and cheap way to do it, you can patent THAT.
My guess is that your patent will be more in demand than mine.

Second, I don't see how programmer time relates to whether something's
patentable.  To get a patent I don't have to have a working (coded)
system...just a new idea.

Standard disclaimers go here.


Sam Drake / IBM Almaden Research Center 
Internet:  drake@ibm.com            BITNET:  DRAKE at ALMADEN
Usenet:    ...!uunet!ibmarc!drake   Phone:   (408) 927-1861

scs@iti.org (Steve Simmons) (05/13/91)

From: barmar@think.com (Barry Margolin)
>This sounds much fancier than the standard #include file mechanism.  Most
>#include facilities don't have any way to specify portions of files, only
>whole files.


If memory server, the MTS file system has always provided the
feature.  It worked something like

  $CONTINUE WITH <filename>[line#][line#]

Given the extreme variation mts files were allowed in line numbering,
it could get quite pathological.
-- 
"SPAM is a registered trademark of a pork product
 packed only by Geo. A Hormel & Co. Corp."
     -- Sun Technical Bulletin, March 1991, pg ii

dricejb@drilex.UUCP (Craig Jackson drilex1) (05/14/91)

In article <740@rufus.UUCP> drake@drake.almaden.ibm.com writes:
>In article <27383@drilex.UUCP> dricejb@drilex.UUCP (Me) writes:
>>                                   If somebody really comes up with a way
>>to do it in 10 lines of code, maybe they should get a 7-year patent on it or so.
>>However, if a large company merely throws programmer time at something
>>and implements something brute-force that should not be patentable.
>
>Hmm, I disagree with this on 2 levels.
>
>First, what you said seems to boil down to:
>
>	If I invest $20.00 in an idea, I should get fully exclusive 
>	use of it for 7 years.
>	If I invest $1,000,000 in an idea, I should get nothing in return.
>
>Come again?  

That is one possible interpretation.  My meaning was:

If I invest $20.00 in a really new idea, I should have the priviledge
of spending some more money to patent it, so as to get fully exclusive use
of it for 7 years.

If I invest $1,000,000 to do finally implement an idea that was thought of years
ago, that doesn't make it a new, patentable idea.

Example: A number of {people, governments} would love to have a way of
of factoring the product of large primes.  I've got an idea of how to do it:
you try each possible factor by division, until you reject all possible numbers.
This isn't a very good idea; it would take a lot of computing power to
use this idea on large primes.  It is also an idea that is taught in
every algebra textbook.  I hereby dedicate this idea to the public domain.

Now say that IBM develops (at presumably large expense) a general-purpose
computer that is 1,000,000 times faster than it has today.
Assume, for the moment, that this increase of speed makes my idea
feasible for a given set of candidates.  This fact, in and of itself,
should not be grounds for patenting trial-and-error as a method for
factoring large numbers.

>If what you really meant was that short, elegant algorithms should get
>preferential treatment over expensive, ugly ones, well, they do.  If I
>figure out an expensive way to do something, I can patent it.  If you
>then come out with an elegant and cheap way to do it, you can patent THAT.
>My guess is that your patent will be more in demand than mine.
>
>Second, I don't see how programmer time relates to whether something's
>patentable.  To get a patent I don't have to have a working (coded)
>system...just a new idea.

The emphasis here is should be on *new*.

The "obvious to one practiced in the art" should be a major exclusion.
Certainly, this argument is overused in the software patent controversy:
in software, like many other fields, new ideas seem obvious once they've
been thought up.  However, my point is that merely implementing something
that hasn't been implemented before does me that you've thought of something
that hasn't been thought of before.

>Sam Drake / IBM Almaden Research Center 
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

mdb@ESD.3Com.COM (Mark D. Baushke) (05/15/91)

On 13 May 91 13:17:32 GMT, scs@iti.org (Steve Simmons) said:

Steve> From: barmar@think.com (Barry Margolin)
>This sounds much fancier than the standard #include file mechanism.  Most
>#include facilities don't have any way to specify portions of files, only
>whole files.

Steve> If memory server, the MTS file system has always provided the
Steve> feature.  It worked something like

Steve>   $CONTINUE WITH <filename>[line#][line#]

Close. The syntax was:

	$CONTINUE WITH [<login>:]filename[(start#[,end#[,inc#]])]

where login 	was the four character login id, 
      filename 	was the up to 14 character filename (case insensitive)
      start#
      end# 	were each allowed to be expressions which yeilded a
		line number. *F was short hand for the first line
		number in the file (which could be negative)
		*L was the short hand for the last line number in the
		file.
      inc#	was the increment to be added to the current start# to
		get the subsequent lines.

	The default value for start# is 1. The default value for end#
	is *L. The way to append to the end of a file was FILE(*L+1).
	I have fogotten the default value of inc#, but I have some
	circa 1979 manuals at home if anyone really want to know.

Internally line numbers were stored as a 32 bit integer. Externally,
they were displayed as if they had been divided by 1000. Line number
1.000 therefore had an internal representation of 1000.

The maximum length of one line in the file was 32768 bytes.

It was also possible to give a list of files on the $CONTINUE WITH
line:

	$CONTINUE WITH 1F23:DATA(1,*L)+*SOURCE*(1,1)+1F23:DATA(-1,0.099,0.001)

which would let the program read all of the lines from the user
account 1F23:DATA starting at line 1 through the end of file followed
by reading from the moral equivalent of stdin for one line followed by
reading the lines between -1 and 0.099 of DATA. Any of those lines
could in turn contain $CONTINUE WITH lines.

Steve> Given the extreme variation mts files were allowed in line numbering,
Steve> it could get quite pathological.

Yup. The Michigan Terminal System was actually very nice to use. The
only problem was that it did not have a hierarchical filesystem beyond
having a separate directory for each user. 

I knew folks that put the source of their programs into the negative
line numbers and had the executable starting at line 1. 

Steve> -- 
Steve> "SPAM is a registered trademark of a pork product
Steve>  packed only by Geo. A Hormel & Co. Corp."
Steve>      -- Sun Technical Bulletin, March 1991, pg ii

Enjoy!
-- 
Mark D. Baushke
mdb@ESD.3Com.COM