TC 500

I have collected the following contribution. The author did not want to be publicly 
mentioned. Here is is contribution:

Sadly  I'll not be much use to you as it was 25+ years ago so I'm fuzzy on detail, the code and documentation are long gone (the project didn't achieve full rollout just half a dozen pilot sites over a couple of years) and I've not studied the Apple patent in detail (not being a patent lawyer may not fully understand the subtleties anyway).

The aim of my program was for zero intervention at the remote site but I don't recall whether that was achieved - but my successors on newer equipment would have faced the identical requirement, there would be development teams facing the same issue in all the big Banks and I can't believe nobody solved it (and of course other business sectors with distributed networks would have the same need).

A key consideration 25 years ago was that the "end users" were not remotely computer literate.  We had learnt from the TC500 where the program was shipped out on punched tape and we had hours of entertainment trying to get the operators to reload when necessary. Consequently part of a programmer's task was to provide low or zero intervention upgrade/patch mechanisms for remote sites - in my case Bank branches dealing with financial transactions.  That meant a need to consider the possibility of a bug fix requiring to be implemented urgently in a large number of sites over a wide geographic area with an assumed zero technical competence at the remote sites.

Where there is a need a programmer will find a solution (if there is one).  So the inference is that since the need has been there since the early 70s for many businesses in the same position someone would have achieve the goal.  The suggestion that nobody achieved that before Apple in 1998 is laughable.  I'm sure the Banks must have had solutions for devices like ATMs before that ...but sorry I can't provide the hard evidence you will need.

There may be an issue in respect of the phrase "without interruption of its primary function". That seems to me to be the only truly unique aspect of  the patent's claims.  What constitutes interruption? Flipping the active thread of computation from one codebase to another whilst maintaining the integrity of variables being used in the computational flow - difficult.  Maybe both codebases are run side by side and new requests are processed by the new module, the old module continues working on tasks it started and closes when all are complete?  But few computers truly run tasks in parallel, they just give that impression because of the speed at which they switch between tasks so even that isn't "without interruption".
What about saving variables and terminating one codebase, immediately starting the replacement and reloading the saved variables taking a finite time although perhaps only milliseconds - from a computing perspective that is an interruption, but to the human user it is probably not.  That raises the question: How long does the interruption need to be before it is considered to be an interruption?  
My guess that what W3C is proposing will involve interruptions on a technological interpretation of the meaning of "interruptions" but not on a "human" interpretation where the interruptions are too short to be perceived (or are compatible with the "normal" level of delays in the performance of a computational task).  So maybe not infringing the patent anyway?