[ih] Saving IETF history

[Jack Haverty]

The particular patent I mentioned is one of those cross-discipline
situations.  It came out of the Television industry, who apparently
discovered computers when they became cheap enough to become the core
component of set-top boxes.  So, of course they encountered the same
issues as computer network people had hit a decade or two earlier, when
computers were scarce and expensive.  So they invented, and patented,
similar solutions.   During the 70s era of computers and networking, I
don't recall anyone ever mentioning or discussing the patentability of
anything we did.   It just wasn't the culture at the time.   But we
apparently created a lot of prior art.   If you can find it.

Re the relation to military history...   In high school I learned about
Roman history, and still remembered some of it circa 1978-9 as we were
defining the next generation TCP (v4).  Roman generals had problems in
communicating from the hinterlands of the Empire back to Rome.  No fiber
or satellites, but they did build an impressive network of roads and
marine routes.

Still, there were problems with "dropouts" (e.g., courier captured by
bandits) and such events.  So they developed techniques such as sending
a message by several different couriers to assure that at least one copy
got through.   They might also dispatch one by land over some mountain
range, and another by sea, to mitigate the threat of pirates or highway
robbers.   For especially secret messages, they might split the message
up into pieces, and send different pieces by different couriers, so that
capturing one or two wouldn't reveal the message contents.

Of course the contemporary military has exactly the same kinds of
problems in assuring that messages get through.   If you think of
packets as "couriers", you can get some very similar solutions for
today's networks.  Similarly, you might think of a TCP connection as one
"courier route", and use multiple such "connections" to get reliable
communications.

As an example of "looking outside your discipline", I remember
discussing the Roman "protocols" in some Internet meetings of the late
70s era.   The discussion generated some entries on the list of "things
we have to work on someday".   One example is "Multi-homed Hosts", i.e.,
how to operate TCP connections where one or both endpoints are attached
to multiple distinct networks.   AFAIK we still don't support that.  
Same with "Diversity Routing" (sending packets by intentionally
different routes).

Caesar apparently never patented any of these inventions, probably
preferring to keep them as trade secrets.   Even if he had, the patent
lifetime has probably run out by now.   2000 years or so should be
sufficient...assuming it's not still in litigation of course.

/Jack Haverty




On 5/13/21 5:58 PM, Toerless Eckert wrote:
> On Thu, May 13, 2021 at 05:14:22PM -0700, Karl Auerbach via Internet-history wrote:
>> One thing about patents and "prior art" is the frequent unwillingness of
>> people to look outside of their own disciplines.
> Sure, but often there is a patent worthy step involved in porting an idea
> into another discipline as well.
>
>> Let's look at the notion of the IMP reloading its memory when it forgot.
>>
>> In our human world one might say "I forget Joe's address, do you remember
>> it?"  That's similar to the IMPs request for a software image.  And the
>> human response, "Oh, it's 123 Imp Lane" is similar to the forgetful IMP
>> getting a refresher from a neighbor IMP.
>>
>> In a patent one might start with a broad claim such as "Refreshing memory
>> from neighbor" and then narrow that down with subsequent claims such as
>> "Computer refreshing memory from a neighbor computer via a network".
>>
>> That's perhaps a weak example.   I have long been intrigued by learning from
>> biology - plants and animals are amazing robust - to see what we can do to
>> improve network reliability and reduce operating costs.  There are a lot of
>> lessons - such as aim for survival rather than optimum or most efficient use
>> of resources. Another is to layer mechanisms so that if one fails there is a
>> backup - this is how trees, for instance, often show surprising resilience
>> to new conditions - and could perhaps help us harden the Internet's routing
>> systems.
> Interestingly thats not too far off from the military. History books always
> point to distributed routing protocols having been developed for
> survivability under attack. Whether thats a true Arpanet creation goal or
> just a nice historic myth, it is still a good problem to consider today:
> "what happens if i shoot down this component (how about that SDN controller)".
> And then the backup and the backup...
>
> Ultimately, this almost-fully self-forming/self-repairing
> and self-securing network completely at device level (as opposed to only
> at the routing subsystem level) is at the core of what we are doing in ANIMA-WG.
>
>> Given a quite synoptic view one could see how a patent on a Covid RNA
>> vaccine technique that informs a person's immune systems of
>> yet-to-be-experienced viruses could arguably be applied to the sharing of
>> Snort intrusion signatures (rules) - both are informing defensive systems
>> about ways to identify an attacker.
> Do you want to write a draft about that for ANIMA ? We should have a
> good underlying secure messaging system to do th dissemination of that data ;-))
>
>> Everyone here on this list has a deep education that feeds imaginative
>> intellects.  I suspect that everyone here has at one time or another had an
>> insight that bridged between disciplines.
>>
>> The Patent Office isn't so smart, informed, or imaginative.
> The only person having worked at a patent office i know by name is Albert Einstein ;-)
>
> I think nowadays there is a lot of name-calling based pattern matching.
> The feedback received for patent submissions typically are:
> I found your component 1 word in patent 1, ... your component N word in
> patent N. How can your patent be novel, i just need to put patent 1...N
> into a mixer, press start, and e voila your new patent smoothie.
>
> Maybe there are no humans by AI working in the patent office nowadays. At least
> the logic of responses often sounds like cheap & silly logics.
>
>> While we may say
>> "but that's obvious" the patent examiners may be unwilling to quickly agree.
>>
>> It is for that reason that I have been concerned that many of our Internet
>> documents have become dry specifications without expressing the reasoning
>> and experimentation behind those specifications, or discussing the paths not
>> taken (and why.) [Indeed those mentions of the paths not taken could
>> sometimes be more important in a patent fight than the reasoning that was
>> adopted for a particular Internet technology.]
> Well... My theory is that prudent engineers simply put into RFCs the minimum
> necessary specification text so that the all 3 company developers involved
> in writing the RFC have a good chance their implementations interoperate.
>
> I say prudent, because whenever you start writing more than this, you are
> not helping yourself: You may encourage even more competing implementations,
> such as from tier 2 vendors who do not bother to participate in the IETF
> process at all. And you have to edit more text which takes longer.
>
> I specifically dislike the standard behavior of prudent engineers to simply
> answer (IESG or other) reviewer questions only in email. I for once answered
> them by adding the answer text to the draft. But trust me, thats not prudent when you are
> interested in getting an RFC out in any reasonable time.
>
> Aka: fully agree with you, but its a bit part of being successful in IETF.
>> When fighting patents the goal is often not to fight the patent in its
>> entirety but to restrict the scope of the patent to the most narrow of its
>> sequence of ever-tightening claims.
> I think there needs to be more fundamental reform than these struggles.
>
> Cheers
>     Toerless
>
>>         --karl--
>>
>>
>>
>> -- 
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history