I was one of the leading team members at System Development Corporation (SDC) in the 1970's on various secure operating system and secure networking projects for various US and UK governmental bodies.

Some of that work was classified, much was not.

In late 1974 David Kaufman and I were working on network security, particularly on the then monolithic TCP (there was at that time no formalized underlying datagram IP layer.) Among other things we were designing and building a multi-level secure nework, with multi-level verifiied secure switches/routers, for a goverment agency.

In our work we split an encrypted datagram layer off from the underside of TCP. Because of nature of packet ordering, packet loss, retransmissions, as well as aspects of various security algorithms this was not as straightforward as one might think.

What we came up with was a precursor to what are today encrypted VLANS, IPSEC, and key distribution infrastructures.

However, we were not able to publish our work widely. In fact now, 40 years later, there is scarcely anything visible on the public web. Even our work that was published via the then National Bureal of Standards (now NIST) is not easily found. (I have been searching for years for a copy of some work I did on debugging hooks for secure operating systems.)

We also worked on things like capability based computers and operating systems with formal verfication of security properties. During that time I designed and wrote what is aguably the first formally verified secure operating system.) That work, also, tends to remain hard to find.

Vint Cerf was a consultant to our group. He helped. But the major thrust and principle design work was done by our team at SDC.

The US Dept of Defense (which includes several agencies) funded much of this work - and really helped move things along - but their institutional resistence to wide publication meant that many of the ideas and implementations we did in the mid 1970's were invisible to most of the world until they were re-invented decades later.

Oakland is not a desert. It is a Mediterranean climate with nearly 24 inches of rain per year on average. Just pointing this as the summary is not talking about Palm Springs or LA or some other city hundreds of miles away.

My wife's 2 month old LEAF gets 110 miles on a single charge with her driving solo and 90 with me driving (with her riding along). If you really like the car it might make sense to stick with it and just get the newer model.

The barrier to entry for a cert authority to be recognized by browsers is too high, as a consequence the price for certificates is too high - it is based on near-monopoly conditions.

In mulitcast network code it is common to randomize scheduling by a factor of +/- 50% in order to reduced synchronization effects.

Similarly, power use scheduling could be randomized across some range.

I have long held that competing DNS root systems *can* work - and in fact have been working for long time.

The issue is not whether there is one singular catholic DNS root, but rather the degree of consistency between competing roots.

We all accept that internet users dislike surprise - they will not like any DNS root that give surprising (or misleading or fraudulent answers). That's why any DNS root that gives surprising DNS answers will quickly be shunned.

What is intriguing about competing DNS roots is that they provide a way around ICANN and around ICANN's choices - and ICANN's fees and ICANN's trademark-over-everything-else policies.

I wrote a note on this topic some years ago - "What would the internet be like had there been no ICANN?" at http://www.cavebear.com/cbblog-archives/000331.html

IP multicast has been in active use on the internet since the 1980's.

IP multicast lets receivers join groups, defined by a special class of IP addresses. Senders emit packets addressed to those addresses and the IP mulitcast routing systems (of which there are several) build distribution trees to get those packets to those receivers.

So to the extent that this patent claims include subscription based addressing and transmission of data packets, IP multicast has been a running example of this for at least a quarter of a century.

What about cables that go from DVI to HDMI?

All those security cameras out there are recording everyone. And a lot of that footage is retained.

With this kind of technology all of that past footage could be scanned and a dossier of past whereabouts created.

(Yes, I know that our mobile phones are already reporting on our whereabouts, but at least you can turn a phone off.)

It would be easy to set up a weakly protect access point that did nothing but generate bogus transactions with bad credit card numbers - that could pollute the crook's database, particularly if they don't do a good job of recording of which card number came from which network.

And if the bogus numbers were timestamped and logged then when the bad card numbers are used (and bounced) one could use the bounced transactions to build a map of where the crooks were on any given day.