Well, that's nice, someone who apparently wants to consider the idea :)
 

Message text written by INTERNET:simon.east@symbian.com > I have had a brief look at the patent. If you have an electronic copy       of it that might make looking at it a bit easier since the       photographic version on the website is rather slow to access. < The best I can do is to fax it to you since I have only the originals of what my attorneys typed on a steam-driven word processor of some sort, and the same thing that you can see the image of, on the web site. The latter is better since we know that's the final version. Please let me know. I have a number of other documents which are of significance relating to the prosecution stage of the patent but from the questions you are asking I am supposing they are more of interest to your lawyers than you. I also have some documents and material which we would prefer to reveal only under non-disclosure. >       If I understand the patent properly it is about how modules of a       program such as DLLs are linked togehter and fetched from a code       server. <  That's correct. A more refined statement is to say that we use the necessary steps in module link-loading as a way of controlling what pieces of program reach an executing client. This achieves a marriage of operating system and network in a way that we believe is uniquely powerful. The "necessary steps" I refer to are the steps which a client has to take anyway for any multi-module application (define your terms but it doesnt actually have to be DLL's, just something like them) to be started by an O/S or loader on a given target. It is an improvement on PUSH technology because the system never sends things which are not in the direct chain of things needing to be link-loaded. >       Given that our devices are wireless and the link is not garanteed I       would not see us relying on a link to a code server in order to run       applications on a handheld device - typically the whole application       would be installed on local storage and then run. < Yes that's true. But once the pieces are downloaded once they would not need to be updated until a server they were connected to signalled the necessity to do so. The code server arrangement usually will be configured so that programs which have run once will run many times, whether or not the network is there. However the overhead of checking (ie making a request such as in the general case for an UNinstalled application) all the time is negligible, since the amounts of information needed to verify each module are tiny, of the order of dozens of bytes for each one per program invocation. So if this is any sort of a network that the device depends on for real-world usage(ie it's being used for more than an isolated station doing a fancy calculator/storage function) then really we are talking about security/reliability. And the code server can ensure both, without making the device overly dependent on network bottlenecks. >      Maybe you can explain how you think your system can be of help to us? < The big advantage, it seems to me, is that the above set up relieves you of the necessity to ever install or deliberately update a handheld device (we make exactly the same claim about PC's of any kind). The worst scenario that we can visualise is that the memory of the client (be that permanent or RAM) gets corrupted to the point where a flag needs to be set to force the transfer of (all?) new pieces. This can be done at either end, depending on the whim of the software provider. For example you could force users to pay you for an application by never permanently downloading some small piece of code, and they can only run it while the subscription they have is paid for. It also means that if you have a relatively simple machine and operating system that isnt cluttered with 200 Windows applications, that it is nice and easy to clear it out in order to run the application you want. Of course the code server is in no way tied to any operating system in the target - indeed we used p-code in our original implementation with the idea of JIT compilation.   Hope this helps, Regards Stephen Pickett

 

Sender: simon.east@symbian.com Date: Wed, 28 Oct 1998 10:30:35 GMT To: <sfbp@compuserve.com> Subject: Re[2]: REC Software Code Server Patent       Stephen,      I'm still not really sure how such technology will be of help to us.      We do not architetect programs as monolithic masses of modules/DLLs.       Instead - we abstract the engine, view creation and UI rendering code       into three separate bits. In addition a lot of the common system       functionality is encapulated as servers (we have been using       client-server internall in EPOC since 1988 or so).      We also have an install/uninstall system which works on normal lines       of reference counting.      So intalling an App will mean any associated servers are installed -      and will only be removed on un-install if no one else is using them.      I think your system may well be of use to Corporates who need to roll       out large applications and replace modules - but generally I imagine       they will be using Java and so can replace class files as a method of       doing this.      Also Network operators/content providers may be interested in this       idea - there is quite a bit of work going on in software download       currently - but there is more to software download than just working       out is a module is needed on the target system.      However I cannot see any real advantages for us in using this system       internally in EPOC - unless I'm missing something fundamental.      Regards,      Simon.

IS this guy missing something fundamental, or what? He sounds like he is exactly describing one of the possible arrangements we envisage. Here is my reply (if you are still reading) - the impression one gets is that here is someone who is threatened by an idea. It's the classic catch-22 - "if you haven't invented something new, don't bother me; if you have, then I don't believe it can be done, so don't bother me either way"
 
 

Message text written by INTERNET:simon.east@symbian.com >       I'm still not really sure how such technology will be of help to us. < Unless I missed something about the nature of operating systems and what you are doing then I am having trouble here. I will do my best to deal with it point by point. I hope you won't take umbrage if some of my statements seem a little sweeping, because this may in part be because I dont know enough about EPOC. For this I apologise. However I would venture to say that the patent was filed because it purports to deal with a general problem in operating systems. Evidence to the contrary would be a top priority for us.  >   We do not architetect programs as monolithic masses of modules/DLLs.       Instead - we abstract the engine, view creation and UI rendering code       into three separate bits. < The implication from your comment is (I think) "we have a relatively closed system which we control, and therefore we dont need this technology since our environment is well-defined". If that's true, well and good, but you are consciously limiting the extensibility of your devices in a way that Windows (?CE) does not. Of course if every module (and therefore server) has some kind of predefined slot that everybody knows about then the code server approach is less interesting. The corollary is that you can not do true dynamic linking to the infinite world of user applications that the wit of humans can in the future come up with. If this is a limitation you can live with, then so be it - prepare to be trampled by the Gates army! >       In addition a lot of the common system       functionality is encapulated as servers (we have been using       client-server internall in EPOC since 1988 or so). < That is well and good. But is your dynamic linker-loader a server process? The existence of servers to perform tasks in your system in no way speaks to the content and linkability of the modules (accessing those server processes) to each other.   >      We also have an install/uninstall system which works on normal lines       of reference counting.      So intalling an App will mean any associated servers are installed -       and will only be removed on un-install if no one else is using them. < I am talking about using the code server arrangement as a means of shipping multiple interdependent application modules to your clients. Whether those applications are client-server or not doesnt matter. If you only ever need one application module at the client (ie YOUR system is monolithic) then clearly the code-server-dynamic-linking complex is useless. Maybe you have misunderstood me here, I am not talking about using such an arrangement to control which servers at the other end of your network are installed. I am assuming that your handheld devices are now able to have megabytes of memory and able to run "true" applications made up of a number of independently compiled and independently maintained modules. >       I think your system may well be of use to Corporates who need to roll       out large applications and replace modules - but generally I imagine       they will be using Java and so can replace class files as a method of       doing this. < My inference from this comment is that you see this as some "extra" layer that application builders (ie owners of "user" applications) will want to hook into as a means of policing their own private networks. I have heard this comment before. This is at the core of what I need to explain to you, and if you are able to spare the time, I should appreciate some telephone time to see if I can do just that. Java is clearly in danger of infringing on our patent, in any event. However the Java view of the world, where classes (modules) are downloaded and the "real" operating system subsequently gets to load the module in the way it sees fit, is really only about 10 percent of the power of what we can achieve. The actual activities of your EPOC operating system as it performs its own dynamic linking are the engine which would drive the distribution of content in a "code server" arrangement.   >       Also Network operators/content providers may be interested in this       idea - there is quite a bit of work going on in software download       currently - but there is more to software download than just working       out is a module is needed on the target system. < Yes!   There certainly is. In the original version of this idea, we had a real-time server translating one form of p-code to another by disassembling it and re-assembling with a Windows/OS2 .EXE format as an envelope so that it could be executed in protected mode as if it were a normal DLL. Apart from the simple activity of detecting whether a module is changed (which can be done on a per-client basis if necessary), the possibilities exist for at-server transformation of code, including encryption, modification, and partial resolution of "dynamic" links against a set of addresses supplied by the client, or if you prefer to view it that way, module relocation (remember REBASE in Windows NT?). The server can have language compilers being invoked automatically to generate modules in a particular machine code or particular form of pcode depending on the target. >       However I cannot see any real advantages for us in using this system      internally in EPOC - unless I'm missing something fundamental. < Is this the key? Is there some reason you suggest that it is only of value internally? Or is EPOC merely a host for real operating systems like Windows? In our proof-of-concept we had the Windows system load all modules, both its own and those from all applications,  via our server, and as you probably know, Windows uses the same mechanism to load both system and application modules, ie it is completely general. Your suggestion implies that EPOC treats internal modules differently from external ones. This is an intolerable limitation, in my view. Hoping this is of some use Stephen Pickett REC Software Inc.

No reply! Henry Root, would that you were alive to read this..........