US6065046A - Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network - Google Patents

Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network Download PDF

Info

Publication number
US6065046A
US6065046A US08/902,591 US90259197A US6065046A US 6065046 A US6065046 A US 6065046A US 90259197 A US90259197 A US 90259197A US 6065046 A US6065046 A US 6065046A
Authority
US
United States
Prior art keywords
computer
request
user
machine
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
US08/902,591
Inventor
Michael A. Feinberg
Matthew A. Feinberg
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Catharon Products Intellectual Property LLC
Original Assignee
Catharon Productions Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
US case filed in Texas Eastern District Court litigation Critical https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00692 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00691 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00061 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
PTAB case IPR2015-00651 filed (Settlement) litigation https://portal.unifiedpatents.com/ptab/case/IPR2015-00651 Petitioner: "Unified Patents PTAB Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00067 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00066 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00065 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00064 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00706 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00062 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Pennsylvania Middle District Court litigation https://portal.unifiedpatents.com/litigation/Pennsylvania%20Middle%20District%20Court/case/1%3A15-cv-02161 Source: District Court Jurisdiction: Pennsylvania Middle District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/2%3A14-cv-00056 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A14-cv-00063 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00705 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00704 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
First worldwide family litigation filed litigation https://patents.darts-ip.com/?family=25416079&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US6065046(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
PTAB case IPR2015-00652 filed (Settlement) litigation https://portal.unifiedpatents.com/ptab/case/IPR2015-00652 Petitioner: "Unified Patents PTAB Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00690 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
US case filed in Texas Eastern District Court litigation https://portal.unifiedpatents.com/litigation/Texas%20Eastern%20District%20Court/case/6%3A13-cv-00689 Source: District Court Jurisdiction: Texas Eastern District Court "Unified Patents Litigation Data" by Unified Patents is licensed under a Creative Commons Attribution 4.0 International License.
Priority to US08/902,591 priority Critical patent/US6065046A/en
Assigned to CATHARON PRODUCTIONS, INC. reassignment CATHARON PRODUCTIONS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FEINBERG, MATTHEW A., FEINBERG, MICHAEL A.
Application filed by Catharon Productions Inc filed Critical Catharon Productions Inc
Priority to BR9811593-6A priority patent/BR9811593A/en
Priority to NZ502477A priority patent/NZ502477A/en
Priority to KR1020007001043A priority patent/KR100345460B1/en
Priority to CNB988094150A priority patent/CN1232913C/en
Priority to IL13414198A priority patent/IL134141A/en
Priority to EP98938065A priority patent/EP1010193A4/en
Priority to RU2000104864/09A priority patent/RU2226711C2/en
Priority to CA002297069A priority patent/CA2297069C/en
Priority to AU86671/98A priority patent/AU724513B2/en
Priority to JP2000505645A priority patent/JP2001512272A/en
Priority to PCT/US1998/015627 priority patent/WO1999007007A2/en
Publication of US6065046A publication Critical patent/US6065046A/en
Application granted granted Critical
Priority to JP2008189095A priority patent/JP2009009584A/en
Assigned to CATHARON INTELLECTUAL PROPERTY, LLC. reassignment CATHARON INTELLECTUAL PROPERTY, LLC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CATHARON PRODUCTIONS, INC.
Assigned to CATHARON SOFTWARE CORPORATION reassignment CATHARON SOFTWARE CORPORATION MERGER (SEE DOCUMENT FOR DETAILS). Assignors: CATHERON PRODUCTIONS INC.
Assigned to CATHARON INTELLECTUAL PROPERTY LLC reassignment CATHARON INTELLECTUAL PROPERTY LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DUFRESNE, FRED
Assigned to DUFRESNE, FRED reassignment DUFRESNE, FRED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CATHARON SOFTWARE CORPORATION
Assigned to CATHARON PRODUCTS INTELLECTUAL PROPERTY, LLC reassignment CATHARON PRODUCTS INTELLECTUAL PROPERTY, LLC NUNC PRO TUNC ASSIGNMENT (SEE DOCUMENT FOR DETAILS). Assignors: CATHARON INTELLECTUAL PROPERTY, LLC.
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44521Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • This application includes a microfiche appendix consisting of four microfiche transparencies with a total of 325 frames including specification pages numbered 90 through 406.
  • This invention relates to computing and communications on a computer network. More specifically, this invention relates to a computerized system and an associated method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage.
  • the Internet is a network of regional computer networks scattered throughout the world. On any given day, the Internet connects roughly 20 2 million users in over 50 countries. That number will continue to increase annually for the foreseeable future.
  • the Internet has provided a means for enabling individual access to enormous amounts of information in several forms including text, video, graphics and sound.
  • This multi-media agglomeration or abstract space of information is generally referred to as the "World-Wide Web," which is technically a "wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents.”
  • a computer operator uses software called a browser.
  • the most popular browsers in the United States are Netscape Navigator and Microsoft's Internet Explorer.
  • Hypertext is basically the same as regular text in that it may be stored, read, searched and edited, with one important exception: a hypertext document contains links to other documents. For instance, selecting the word "hypertext" in a first document could call up secondary documents to the user's computer screen, including, for example, a dictionary definition of "hypertext" or a history of hypertext. These secondary documents would in turn include connections to other documents so that continually selecting terms in one documents after another would lead the user in a free-associative tour of information. In this way, hypertext links or "hyperlinks" can create a complex virtual web of connections.
  • Hypermedia include hypertext documents which contain links not only to other pieces of text, but also to other media such as sounds, images and video. Images themselves can be selected to link to sound or documents.
  • HyperText Markup HTML
  • SGML Standard Generalized Markup Language
  • Web documents are typically written in HTML and are nothing more than standard text files with formatting codes that contain information about layout (text styles, document titles, paragraphs, lists) and hyperlinks.
  • HTML is limited to display functions (text, animation, graphics, and audio) and form submission.
  • Inherent in the basic HTML protocol are design limitations that prevent the implementation of the type of program functionality that is commonly used in today's desktop computers. Because of this limitation, it is impossible to enhance HTML documents with the features necessary to support the Internet applications currently being sought by industry and consumers.
  • Sun Microsystems and Netscape Communications have attempted to introduce additional program functionality through the implementation of Sun's Java programming language as a browser plug-in.
  • Microsoft in addition to supporting Java, has introduced Active-X as a browser plug-in.
  • Active-X As a browser plug-in.
  • C Java, Active-X and almost all other programming languages use a programming paradigm based on the "C” programming language introduced by AT&T in the 1970's to develop the UNIX operating system.
  • C has two major drawbacks for Internet content delivery. The first drawback is that an entire program must be loaded before anything can be executed using the program. Because Internet content is open-ended, most applications can become very large, making downloading impractical due to the limited bandwidth of most Internet connections. Typical Java and Active-X applications take several minutes to download before they start running. The second drawback using programs based in "C” is that content development is very inefficient.
  • HTML is inadequate to enable or facilitate the conducting of interactive programming on the Internet.
  • HTML is extremely limited in active and interactive software use and development.
  • companies seeking to conduct commercial activities on the Internet are seeking a programming tool or information-exchange methodology to replace HTML or to provide major enhancement to that language.
  • Internet applications programming is generally not subject to multiple uses. Rather an Internet program is consumed: the program is used only once by the typical user.
  • Utilities-type software developed for individual computer use such as word processors, spread sheets, E-mail, etc., can be sold at higher prices because the software is used again and again by any individual.
  • TenCORE is a modular programming language designed in the early 1980's to facilitate the transfer of information between disk drives and RAM, particularly for the delivery of interactive instruction ("Computer-Based Training"). At that time, disk drives were all slow and RAM was inevitably small. In adapting to these hardware limitations, TenCORE introduced the use of small individual code modules for performing respective functions, thereby enabling efficient performance as each code module loaded a single interaction from the slow disk drives. Programming in the form of substantially independent code modules is open-ended, a necessary characteristic for educational software requiring the delivery of whatever remedial instruction is required by the individual student TenCORE utilizes a program called an "interpreter" that implements all basic required functions efficiently. The interpreter has no content itself. The content comes from an unlimited number of small pseudocode modules which are loaded into the system memory and issue commands to the interpreter. In writing a program, the programmer's involvement is reduced to simply issuing commands, leaving all the difficulties of implementation to the interpreter.
  • C type programming includes a series of pre-written code libraries which are linked together as they are compiled.
  • code libraries need to be rewritten and then all programs can be re-compiled using the new libraries.
  • the number of these code libraries has grown to a point where the original concept of rewriting for different microprocessors is no longer practical because of the difficulty in compensating for subtle differences between microprocessors. What remains is a complex and difficult programming syntax that takes years to master and is very difficult to debug.
  • a general object of the present invention is to provide a method for communicating over a computer network.
  • a more particular object of the present invention is provide a method for enabling or facilitating the conducting of interactive programming over a computer network such as the Internet.
  • a related object of the present invention is to provide a method for communicating software over a computer network, to enable an increased degree of interactive computer use via the network.
  • Another object of the present invention is to provide a computing system for enabling or facilitating the conducting of interactive programming over a computer network such as the Internet.
  • the present invention is directed to a computerized system and to an associated method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage.
  • an applications program is stored in a nonvolatile memory of a first computer as a plurality of individual and independent machine-executable code modules.
  • the first computer retrieves a selected one of the machine-executable code modules and only that selected code module from the memory and transmits the selected code module over the network link to the second computer.
  • the first computer is a server computer on a network.
  • the second computer may be a user computer or a secondary server.
  • the two computers may be two individual user computers on the network.
  • the request for the executable code module arises because the user needs the code module to perform a desired function in the applications program.
  • the user's computer does not have all of the code modules of the applications program and obtains new code modules only as those modules are needed.
  • executable code of the applications program is broken down into individually executable modules, the program can be downloaded piecemeal, module by module, as the individual modules are needed by the user's execution of the program. Accordingly, the user need not wait for the entire program to be downloaded before the user can start using the program.
  • the present invention allows the primary server, when is too busy to handle a user request or task, to hand that request or task off to the secondary server.
  • a primary server receives a user request or task that the server cannot handle due to load, that request or task is forwarded preferably to the least busy secondary server available.
  • the secondary server then processes the user request and responds to the client/user directly. If the secondary server does not have a code module, data file, or other resource required to handle the user request, the required code module, data file, or other resource can be transferred to the secondary server from the first server. This shunting of user requests contemplates the utilization of multiple secondary servers located on different Internet connections. The present invention thus eliminates most bandwidth and server load issues on the Internet and other computer networks.
  • a server computer must shed its load before the server reaches its full capacity, thereby leaving enough system resources (processor, memory, etc.) free to fulfill any requests from a secondary server for resources necessary for the secondary server to fulfill a shunted user request or task.
  • the secondary server can forward the user request to another secondary server for processing, since the other secondary server may be able to reach the client machine directly.
  • a secondary server may also serve as a backup server.
  • the secondary server immediately requests all code modules, data files, and other resources from the primary server instead of waiting for a client request that requires one of those resources.
  • the request can then be made of a backup server.
  • the primary server sends notification packets to each of the backup servers whenever a resource is created or updated.
  • the backup servers can then request the new, updated copy of the resource from the primary server, thereby remaining up to date with the primary server at all times.
  • a primary server stores in its memory a list of secondary servers on the network, the list including response times and load statistics (processor usage, etc.) for the respective secondary servers.
  • the primary server periodically updates these response times, by sending echo packets to the secondary servers and measuring delays between the sending of the echo packets and a receiving of responses to the echo packets from the respective secondary servers.
  • the server also periodically updates the load statistics by requesting the current load statistics from the secondary servers. For processing a recently received user request, the primary server scans the list in memory and selects the secondary saver having the lightest load and shortest response time.
  • code modules are transmitted in encrypted form. Encryption is accomplished by placing the code modules, files, documents or other transmittable resources in the data area of an encryption packet. When an encrypted packet is received, it is decrypted and the code modules, files, documents or other transmittable resources subsequently handled pursuant to normal procedures.
  • the encryption/decryption process can be handled by a plug-in code module. Any number of plug-in encryption code modules may exist in a data and code transfer system in accordance with the invention at any one time.
  • the header of an encryption packet contains an indication of which plug-in encryption code module must be used for decryption purposes.
  • Encryption/decryption code modules can be delivered real time by a code module exchange protocol.
  • the primary server stores a list of user authentification codes in its memory.
  • the primary server compares a user authentification code in the request with the stored list of user authentification codes.
  • the primary server proceeds with retrieving and transmitting a selected machine-executable code module only if the user authentification code in the request matches a user authentification code in the stored list.
  • an incoming request for a machine-executable code module is contained in an encryption packet
  • the server decrypts the encryption packet prior to the comparing of the user authentification code in the request with the list of user authentification codes in the memory. Encrypting and decrypting of encryption packets, as well as the checking of user authentification codes, may be performed by the secondary server(s). Whatever programming or data required for carrying out these security measures can be transmitted from the primary server in accordance with the present invention.
  • the present invention provides for the updating of an applications program in users' machines.
  • a user sends a request for a code module to a server
  • the request includes a specification of the version of the program code sought.
  • the server processing the request checks whether the requested version is the latest version available.
  • the server informs the user and inquires whether the user could use the newer version of the requested module. The user could then send a request for the updated version of the desired code module.
  • the older version of the desired code module will be transmitted from the server to the user. If the older version is not available, the user may have to request transmission of the newer versions of several additional modules.
  • machine-executable code modules are written in a user-friendly programming code such as TenCORE.
  • a software-implemented interpreter unit of the user computer translates the code modules from the programming code into machine code directly utilizable by the user computer.
  • the interpreter itself can be updated in the same fashion as an application program or code module.
  • the interpreter is treated as a single large code module.
  • a portion of an applications program is stored in a first computer.
  • the applications program comprises a plurality of individual and independent machine-executable code modules. Only some of the machine-executable code modules are stored in the first computer.
  • This method includes executing at least one of the machine-executable code modules on the first computer, transmitting, to a second computer via a network link, a request for a further machine-executable code module of the applications program, receiving the further machine-executable code module at the first computer from the second computer over the network link, and executing the further machine-executable code module on the first computer.
  • the first computer may conduct an investigation into server availability.
  • a request is sent from the first computer (e.g., a user) to a further computer (e.g., a primary server) for a list of servers (e.g., secondaries) on said network.
  • a further computer e.g., a primary server
  • servers e.g., secondaries
  • response times for the server are determined by (a) sending echo packets from the first computer to the servas, (b) measuring, at the first computer, delays between the sending and receiving of the echopackets, (c) querying the servers as to current server load (processor usage, etc.)
  • the request for a further machine-executable code module is sent to the server having the lightest load and shortest measured response time.
  • the list of servers can be cached in memory by the first computer to facilitate further access to the information in the event that the server from which the list was requested becomes unavailable or is too busy to handle the request.
  • a request from the first computer for a particular version of the code module may trigger an inquiry as to whether the first computer could use the updated version of the code module. If so, the first computer transmits a second requests, this time for the updated version of the desired code module.
  • the method of the present invention facilitates interactive processing.
  • Each computer executes one or more selected code modules in response to the execution of code modules by the other computer.
  • both computers store at least some of the machine-executable code modules of the applications program.
  • one computer will require a code module which it does not have in present memory. Then the one computer can obtain the required code module from the other computer. If the other computer does not have the required module, a request may be made to a server on which the applications program exists in its entirety.
  • each user computer includes an interpreter module implemented as software-modified generic digital processing circuits which translates the code modules from the programming code into machine code utilizable by the respective computer.
  • the machine-executable code modules each incorporate an author identification.
  • the method then further comprises determining, in response to an instruction received by a user computer over the network and prior to executing the one of the machine-executable code modules on the user computer, whether the particular author identification incorporated in the one of the machine-executable code modules is an allowed identification.
  • the user computer proceeds with code module execution only if the particular author identification is an allowable identification.
  • the instruction determining whether a code module is written by an allowed author is a list of blacklisted authors.
  • the author identification feature of the invention severs to prevent an author from creating a virus or other malicious program and distributing it using the code module exchange protocols of the present invention. All compilers supporting the coding of individual machine-executable code modules in accordance with the present invention will incorporate a respective author identification code into each machine-executable code module.
  • the author identification is unique to each author. When a malicious program is discovered, the identification of the author may be distributed throughout the network to blacklist that author and prevent the execution of code modules containing the blacklisted author's identification. As an additional advantage, this feature will discourage users from distributing illegal copies of the authoring package, since the respective users will be held responsible for any malicious programs written under their author identification.
  • the storing of applications program modules in a user computer may include caching the code modules in a nonvolatile memory of the user computer.
  • the present invention permits the transmission during user computer idle time of code modules whose use is anticipated.
  • a request from the user computer is transmitted to a server or other computer for a machine-executable code module during an idle time on the user computer.
  • a computing system comprises, in accordance with the present invention, digital processing circuitry and a nonvolatile memory storing general operations programming and an applications program.
  • the applications program includes a plurality of individual and independent machine-executable code modules.
  • the memory is connected to the processing circuitry to enable access to the memory by the processing circuitry.
  • a communications link is provided for communicating data and programs over a network to a remote computer.
  • a code module exchange means is operatively connected to the memory and to the communications link for retrieving a single code module from among the machine-executable code modules and transferring the single code module to the remote computer in response to a request for the single code module from the remote computer.
  • the computing system of the present invention may be a server computer on the network.
  • the server's memory may contain a list of secondary servers on the network, the list including response times for the respective secondary servers,
  • the computing system then further comprises a detection circuit, generally implemented as software-modified generic digital processing circuitry, for detecting an overload condition of the computing system.
  • a server selector also generally implemented as software-modified generic digital processing circuitry, is operatively connected to the detection circuit, the memory and the communications link for determining which of the secondary servers has a shortest response time and for shunting an incoming user request to the secondary server with the shortest response time when the overload condition exists at a time of arrival of the user request.
  • the remote computer transmitting a code-module request to the computing system may be a secondary server to which a user request has been shunted.
  • the requested single code module is required for enabling the remote computer to process the user request. On behalf of the computing system.
  • the computing system further comprises an updating unit, preferably implemented as software-modified generic digital processing circuitry, operatively connected to the memory and the communications link for (1) periodically sending echo packets to the secondary servers, (2) measuring delays between the sending of the echo packets and a receiving of responses to the echo packets from the respective secondary servers, and (3) updating the response times in the list in accordance with the measured delays.
  • an updating unit preferably implemented as software-modified generic digital processing circuitry, operatively connected to the memory and the communications link for (1) periodically sending echo packets to the secondary servers, (2) measuring delays between the sending of the echo packets and a receiving of responses to the echo packets from the respective secondary servers, and (3) updating the response times in the list in accordance with the measured delays.
  • the memory of the computing system may contain a stored list of user authentification codes.
  • the computing system then includes a comparison unit, preferably implemented as software-modified generic digital processing circuitry, for comparing a user authentification code in an incoming request with the list of user authentification codes in the memory and for preventing code-module retrieval and transmission in the event that the user authentification code in the request fails to correspond to any user authentification code in the list.
  • the computing system further comprises a software-implemented decryption circuit connected to the communications link and the comparison unit for decrypting the encryption packet prior to the comparing of the user authentification code in the request with the list of user authentification codes in the memory.
  • the computing system includes means for determining whether a requested code module has an updated version and for responding to the request with an invitation to the remote computer to accept the updated version of the requested code module.
  • the machine-executable code modules are written in a user-friendly programming code.
  • the computing system uses the applications code itself, the computing system further comprises an interpreter for translating the programming code into machine code directly utilizable by the processing circuitry.
  • the interpreter may take the form of generic digital processing circuit modified by programming to perform the translation function.
  • a computing system (e.g., a user computer on a network) also in accordance with the present invention comprises a memory storing a portion of an applications program having a plurality of individual and independent machine-executable code modules, only some of the machine-executable code modules being stored in the memory.
  • a digital processing circuit is operatively connected to the memory for executing at least one of the machine-executable code modules.
  • a communications link is provided for communicating data and programs over a network to a remote computer.
  • a code module exchange unit is operatively connected to the memory and to the communications link for communicating with a remote computer (e.g., a server on the network) via a network link to obtain from the remote computer a further machine-executable code module of the applications program.
  • the digital processing circuitry is operatively tied to the code module exchange unit for executing the further machine-executable code module upon reception thereof from the remote computer.
  • the present invention provides a programming paradigm which addresses the Internet content developer's specific needs.
  • a software system and computer communications method in accordance with the present invention delivers rapidly over the Internet, provides a practical programming paradigm that supports rapid economical development of content, and facilitates new capabilities in Internet software and systems management.
  • TenCORE a modular programming language designed to use small efficient code modules for facilitating program transfer between disk drives and central processing units of desktop computers, may be easily modified to carry out the present invention. Minimal modifications require the adapting of the transfer capabilities to work over network links.
  • the present invention arises in part from the realization by the inventors that the problems facing the developers of TenCORE in 1980 are the same problems that software designers face today when dealing with the Internet and its limited bandwidth and slow connections. It was perceived that Internet applications must be open-ended and programming must be delivered rapidly in spite of bandwidth limitations. Thus, the solution provided by TenCORE is useful in solving today's problems with interactive software on the Internet.
  • the modular programming of TenCORE enables rapid Internet performance because a single TenCORE Net programming module can be quickly downloaded over the Internet
  • the TenCORE Net programming modules are TenCORE programming modules which are modified to enable downloading from Internet servers instead of from a microcomputer's disk drive.
  • TenCORE and TenCORE Net are interpreted languages, i.e., they serve to translate into machine language pseudocode programs and to perform the indicated operations as they are translated. "Pseudocode" is unrelated to the hardware of a particular computer and requires conversion to the code used by the computer before the program can be used.
  • FIG. 1 is a block diagram of a computer network with various servers and user computers, which transmit executable programs to one another pursuant to the present invention.
  • FIG. 2 is a block diagram of a primary server in accordance with the present invention.
  • FIG. 3 is a block diagram of a user computer in accordance with the present invention.
  • FIGS. 4A and 4B are a flow chart diagram illustrating a maintenance loop in the operation of selected program-modified processing circuits in the primary server of FIG. 2 and the user computer of FIG. 3.
  • FIG. 5 is a flow chart diagram illustrating a loop for processing an incoming data packet in the operation of selected program-modified processing circuits in the primary server of FIG. 2 and the user computer of FIG. 3.
  • FIGS. 6A through 6E are a flow chart diagram illustrating further operations relating to the processing of an incoming request for a code module in accordance with the present invention.
  • FIGS. 7A through 7E are flow chart diagram illustrating a subroutine for processing an incoming resource request packet in the operation of selected program-modified processing circuits in the primary server of FIG. 2.
  • FIGS. 8A through 8E are a flow chart diagram illustrating a maintenance loop in the operation of selected program-modified processing circuits in the primary server or a secondary server of FIG. 2.
  • FIGS. 9A through 9D are a flow chart diagram illustrating a subroutine for processing an incoming resource request packet in the operation of selected program-modified processing circuits in the primary server of FIG. 2.
  • FIGS. 10A through 10F are a flow chart diagram illustrating a maintenance loop in the operation of selected program-modified processing circuits in the primary server or a secondary server of FIG. 2.
  • a computer network comprises a plurality of user computers 12 operatively connected to a primary server computer 14 via a complex of network links 16.
  • the primary server 14 stores, in an area 18 of a nonvolatile memory 20 (FIG. 2), an applications program which may be desired for use on one or more user computers 12.
  • the term "applications program” as used herein refers to any executable collection of computer code other than operating systems and other underlying programming for controlling basic machine functions.
  • the network includes a plurality of secondary servers 22 which are available for assisting primary server 14 in responding to requests from user computers 12. More particularly as shown in FIG. 2.
  • primary computer 14 includes an overload detector 24 which continually monitors a queue of jobs or tasks which primary server 14 has to perform. Overload detector 24 determines whether the number and size of tasks in the queue has exceeded a predefined threshold. Once that threshold is reached, overload detector 24 signals a secondary server selector 26 which accesses an area 28 of memory 20 to identify a secondary server 22 which is least busy. To that end, memory area 28 contains a list of secondary servers 22 as well as measured response times for the respective servers.
  • the response times in the secondary-server list in memory area 28 are periodically measured by dispatching echo packets to each secondary server 22 and measuring the delays between the transmission of the respective echo packets from primary server 14 and the receipt of responses from the respective secondary servers 22.
  • primary server 14 and, more particularly, a processing unit 30 thereof contain an echo packet dispatcher 32 and a response-time monitor 34.
  • dispatcher 32 Upon transmitting an echo packet to a secondary server 22 via a network communications interface 36 at primary server 14, dispatcher 32 notifies response-time monitor 34 as to the transmission of a packet and as to the secondary server 22 to which the transmission was made.
  • Monitor 34 counts out the time between the transmission of the echo packet and the arrival of a response from the respective secondary server 22 via network links 16 and communications interface 36.
  • a response-time update unit 38 is connected to response-time monitor 34 and to memory area 28 for writing updated response times in the secondary server list stored in memory area 28.
  • the applications programs store 18 in memory 20 contains a multiplicity of interacting individual and independent machine-executable code modules. Accordingly, a user computer 12 working with the applications program need not be loaded with the entire program in order to begin processing operations.
  • a request is transmitted from the user computer 23 over network links 16 to primary server 14. If primary server 14 is not overloaded, it retrieves the requested code module from program store 18 and transmits it over communications interface 36 and network links 16 to the user computer which made the request.
  • Processing unit 30 of primary server 14 includes a code-module exchanger 40 which processes incoming requests for code modules of the applications program or programs stored in memory area 18.
  • Exchanger 40 cooperates with a version detector 42 which consults the applications program store 18 to determine whether a requested version of a particular code module is the latest version in store 18. If not, version detector 42 and code module exchanger 40 transmit an inquiry to the resting computer as to whether the latest version of the desired code module is utilizable by the requester. If the newer version of the desired code module can be used in place of the older version, the newer version is transmitted over communications interface 36 and network links 16.
  • Code modules, as well as other resources such as data files, may be transmitted in encrypted form for security purposes. Encryption is accomplished by placing the code modules, files, documents or other transmittable resources in the data area of an encryption packet.
  • Encryption/decryption unit 44 consults a memory area 46 containing a plurality of possible encryption keys and selects an encryption key identified by header information in the encryption packet containing the user request.
  • the user request or code module exchange packet contained therein is forwarded to code-module exchanger 40 for processing.
  • the encryption/decryption process can be handled by a plug-in code module performing the functions of encryption/decryption unit 44 and memory area 46. Any number of plug-in encryption code modules may exist in a data and code transfer system at any one time.
  • the header of an encryption packet contains an indication of which plug-in encryption code module must be used for decryption purposes.
  • primary server 14 stores a list of user authentification codes in a memory area 48.
  • comparator 52 in processing unit 30 compares a user authentification code in the request with the list of user authentification codes stored in memory area 48.
  • Code module exchanger 40 proceeds with retrieving and transmitting a selected machine-executable code module only if the user authentification code in the request matches a user authentification code in the stored list.
  • encryption/decryption unit 44 deciphers the encryption packet prior to the comparing by comparator 52 of the user authentification code in the request with the list of user authentification codes in memory area 48.
  • the secondary server incorporates an encryption/decryption unit and an authentification-code comparator for encrypting and decrypting of encryption packets and the checking of user authentification codes, may be performed by the secondary server(s). Whatever programming or data required for carrying out these security measures can be transmitted from primary server 14 to the selected secondary server 22.
  • a processing unit 54 of a user computer 12 includes a code-module exchanger 56 which generates requests for desired code modules of an applications program as those code modules are required during execution of the applications program by the user.
  • the code-module requests are transmitted to code-module exchanger 40 of primary server 14 via a network communications interface 58 at user computer 12, network links 16 (FIG. 1) and communications interface 36 at primary server 14.
  • processing unit 54 of user computer 12 includes a encryption/decryption unit 60 which inserts code-module request packets, as well as other information transfer packets, into the data areas of respective encryption packets whose encryption keys are selected from a plurality of keys stored in an area 62 of a nonvolatile memory 64 of user computer 12.
  • the encryption/decryption process at user computer 12 can be handled by a plug-in code module performing the functions of encryption/decryption unit 60 and memory area 62.
  • the header of an encryption packet generated by encryption-decryption unit 60 contains an indication of which plug-in encryption code module at primary server 14 must be used for decryption purposes.
  • processing unit 54 is provided with an author identification comparator 66 which accesses an author identification list 68 in memory 64.
  • Author identification list 68 is periodically updated by author identification comparator 66 and other function-converted blocks in generic processing circuits 70 in response to incoming instructions from primary server 14.
  • Author identification list 68 contains a list of allowed authors or, perhaps more efficiently, a list of authors who have been blacklisted owing to their passing of viruses or other malicious programming onto the network. Prior to the use of an incoming machine-executable code module.
  • the author identification in a packet header is checked by comparator 66 to determine that the author of the particular code module has not been blacklisted If the author is allowed to produce executable code modules for user computers 12, processing of the incoming code module proceeds normally. If, on the other hand, the author of the incoming code module has been blacklisted, then the code module is never executed and may be discarded prior to storage in an applications program store 72 in memory 64.
  • primary server 14 may occasionally hand off an incoming user request to a secondary server 22, depending on the load condition of the primary server and the secondary servers. Generally, this handing off of responsibility for responding to users' requests is transparent to the users, i.e., the processing of users' requests proceeds without knowledge or intervention by the users. It is also possible for user computers 12 to take over selection of a secondary computer 22 from primary computer 14. To that end, processing unit 54 of user computer 12 is provided with a secondary server selector 74 which accesses a list 76 of secondary-servers in memory 64. Generally, selector 74 selects a secondary server 22 with a smallest response time relative to the respective user computer 12.
  • processing unit 54 further includes an echo packet dispatcher 78, a response-time monitor 80 and a response-time update unit 82.
  • Dispatcher 78 sends echo packets to secondary servers 22 via communications interface 58 and network links 16 (FIG. 1), while monitor 80 determines the delays of responses from the various secondary servers.
  • Update unit 82 corrects response time data in list 76 in accordance with measurements carried out by dispatcher 78 and monitor 80. It is contemplated that the updating of secondary-server response times in list 76 is implemented only when user computer 12 requires a user module or other resource from primary server 14 and that server is too busy to handle the user request.
  • Processing unit 54 of a user computer 12 has a distributed processing circuit 84 which enables processing unit 54 to share the processing of large tasks with other user computers in the network.
  • that distributed processing circuit 84 looks for other user computers 12 that may be in the midst of a processor-intensive task and enable transfer of some of the load to the processing unit 54 of the respective user computer 12. If necessary, the code modules to handle that task can be transferred to the idle user computer 12. This client-side distributed processing significantly improves the performance of processor-intensive tasks.
  • Processing unit 54 of a user computer 12 also contains a metered delivery and billing circuit 86 which controls access to content which must be paid for.
  • Credit registers 88 in memory 64 accessible by circuit 86, store credits which the particular user has against respective accounts. When credit in an account maintained or monitored by primary server 14 is low, circuit 86 may arrange for the transfer of more credit from primary server 14 to the particular user.
  • Metered delivery and billing circuit 86 includes a billing method to pay for the credit. Generally, credit requests and responses thereto should be encrypted.
  • Processing unit 54 of a user computer 12 additionally includes a unidirectional data submission and collection circuit 90 which accesses data files 92 in memory 64 for purposes of uploading those data files to primary server 14 or to a selected secondary server 22.
  • Data submission and collection circuit 90 is operative when the user computer does not need to read the data back from the server. This circuit is particularly useful for on-line orders, form submission, and data collection (including statistical data) among other things.
  • packets that contain data to be written must be sent directly to the primary server 14 and cannot be shunted. This prevents conflicts between different versions of the resource that was written to.
  • Data written back to the server should require user authentification.
  • User authentification should be used even if the write-back will be done only by a program under author control. In that case, user identification codes and passwords can be built into the program. The reason for this is to prevent another author from writing a program that would write back to the same data and possibly corrupt it.
  • TenCORE a modular programming language originally designed to use small efficient code modules for facilitating program transfer between disk drives and central processing units of desktop computers.
  • TenCORE is easily modified, for example, to adapt the code transfer capabilities to operate over network links.
  • the program so modified for use on user computers 12, primary server 14 and secondary servers 22 may be called "TenCORE Net.”
  • TenCORE Net uses small individual code modules for performing respective functions, thereby enabling efficient performance as each code module is downloaded a single interaction from primary server 14 or a selected secondary server 22.
  • Programming in TenCORE Net is open-ended, so that a user computer 12 executes instructions of an applications program when that applications program is only partially stored in program store 72 of memory 64.
  • processing unit 54 includes a program or programmed interpreter circuit 94 that implements all basic required functions efficiently.
  • the interpreter has no content itself Content is derived from a potentially unlimited number of small pseudocode modules which are loaded into memory store 72 and which effectively issue commands to interpreter 94. In writing a program, the programmer's or author's involvement is reduced to simply issuing commands, leaving all the difficulties of implementation to the interpreter.
  • TenCORE may be modified in two ways to enable network use. First, a subroutine or set of instructions may be inserted before each call line of computer code for checking whether the code intended for execution exists in applications program memory area 72. If not, code module exchanger 56 is instructed to obtain the required code module from primary server 14. Once the required code module has been downloaded into memory area 72, it is called and translated by interpreter circuit 94 prior to execution by processing circuits 70.
  • a user computer 12 may be instructed to draw a three-dimensional geometric figure such as a truncated pyramid. If processing circuits 70 discover that the applications program in program store 72 is missing a code module required for performing that task, code module exchanger 56 requests that the requisite module be transferred from primary server 14. In response to that request, version detector 42 may find that a later version of the desired module exists and inquire of code-module exchanger 56 whether the later version would be acceptable for use by the respective user computer.
  • user computers 12 do not have all of the code modules of the applications program and obtain new code modules only as those modules are needed. Because executable code of the applications program is broken down into individually executable modules, the program can be downloaded piecemeal, module by module, as the individual modules are needed by the user's execution of the program. Accordingly, the user need not wait for the entire program to be downloaded before the user can start using the program.
  • a selected secondary server 22 can begin to process a transferred or shunted user request and respond to the client/user directly, without having the entire applications program and other resources relating to the handling of the program's distribution by the primary server 14. If the selected secondary server does not have a code module, data file, or other resource required to handle the user request, the required code module, data file, or other resource can be transferred to the secondary server from the primary server. Secondary servers 22 are thus provided with code module exchangers similar to exchangers 40 and 56.
  • primary server 14 must shed its load before that server reaches its full capacity, thereby leaving enough system resources (processor, memory, etc.) free to fulfill any requests from a secondary server for resources necessary for the secondary server to fulfill a shunted user request or task.
  • secondary servers 22 are equipped with encryption/decryption units like unit 44, as well as authentification comparators 52. Where an incoming request for a machine-executable code module is contained in an encryption packet, the secondary server decrypts the encryption packet prior to the comparing of the user authentification code in the request with a list of user authentification codes in memory. Whatever programming or data required for carrying out these security measures can be transmitted from primary server 14.
  • the secondary server can forward the user request to another secondary server for processing, since the other secondary server may be able to reach the client machine directly.
  • Code module exchanger 56 of processing unit 54 facilitates interactive processing on a network.
  • Each user computer 12 executes one or more selected code modules in response to the execution of code modules by the other computer.
  • both computers store at least some of the machine-executable code modules of the applications program.
  • one computer will require a code module which it does not have in present memory. Then the one computer can obtain the required code module from the other computer. If the other computer does not have the required module, a request may be made to a server on which the applications program exists in its entirety.
  • clients or users on a network are able to exchange code modules with one another. If a first user and a second user are engaged in an interactive whiteboarding session and the first user starts drawing with a tool that the second user does not have in her version of the whiteboarding program, the code module or modules for that tool can be transferred automatically from the first user's computer to the second user's computer.
  • code module exchanger 56 may be instructed to initiate the transmission during user computer idle time of code modules whose use is anticipated.
  • a request from the user computer 12 is transmitted to primary server 14 or other computer for a machine-executable code module during an idle time on the user computer.
  • Resource requests that are generated for idle-time downloading should be flagged as such, so that code module exchanger 56 can assign different priorities from standard requests for load balancing and distribution purposes.
  • the status of a resource request can be upgraded to real time from idle time in the event that the user attempts to access the associated section of the application.
  • code-module exchanger 40 and 56 are characterizable as protocols for the exchange of code modules between a server 14 or 22 and a user computer 12.
  • This code module exchange protocol is considered a subprotocol of a Modularized Code Master Protocol ("MCMP") which handles load distribution, user authentification and encryption. Load distribution is more particularly handled in primary server 14 by processor overload detector 24 and secondary-server selector 26, while user authentification and encryption are handled in primary server and secondary servers 22 by comparator 52 and encryption/decryption unit 44.
  • MCMP Modularized Code Master Protocol
  • the MCMP has four subprotocols, namely, the Code Module Exchange Protocol ("CMXP"), the Uni-Directional Data submission and Collection Protocol (“UDSCP”), the Metered Delivery and Billing Protocol (“MDBP”), and the Distributed Processing Protocol (DPP").
  • CMXP Code Module Exchange Protocol
  • UDSCP Uni-Directional Data submission and Collection Protocol
  • MDBP Metered Delivery and Billing Protocol
  • DPP Distributed Processing Protocol
  • the Code Module Exchange Protocol is realized by code-module exchanger 40 in processing unit 30 of primary server 14 and secondary servers 22 and by code-module exchanger 56 in processing unit 54 of user computers 12.
  • the Uni-Directional Data submission and Collection Protocol is implemented by circuit 90 in user computers 12 and by corresponding non-illustrated program-modified processing circuitry in primary server 14.
  • the Metered Delivery and Billing Protocol finds realization by circuit 86 in user computers 12 and by corresponding non-illustrated program-modified processing circuitry in primary server 14.
  • the Distributed Processing Protocol takes the form of circuit 84 in processing unit 54
  • FIG. 4 illustrates operations undertaken by echo dispatcher 32, response-time monitor 34, and update unit 38 as well as other processing circuits of processing unit 30 of primary server 14 to maintain an updated list 28 of the availability of secondary servers 22.
  • the same steps may be performed by echo dispatcher 78, response-time monitor 80, and update unit 82 as well as other processing circuits of processing unit 54 of user computer 12 to obtain an updated list of secondary server response times.
  • echo dispatcher 32 or 78 or generic processing circuits 50 or 70 query whether the time since the last echo testing is greater than a predetermined maximum period TMR. If the maximum period has been exceeded, echo packet dispatcher 32 or 78 transmits, in a step 102, an echo packet to the secondary server 22 which was tested the least recently.
  • Response-time monitor 34 or 80 determines in an inquiry 104 whether a response has been received from the targeted secondary server 22. If a response has not been received and if a prespecified number of measurement attempts has not been exceeded, as determined at a decision junction 106, another echo packet is dispatched in step 102. If a response is received from the targeted secondary server 22, update unit 38 or 82 then records, in list 28 or 76, the time between the initial packet transmission by dispatcher 32 or 78 and the receipt of the echo packet by monitor 34 or 80. This recordation is effected in a step 108. If the number of attempts at secondary-server response-time measurement has exceeded the pre-specified number, as determined at decision junction 106, the server is marked in list 28 or 76 as being unavailable (step 110).
  • a message or alert signal may be generated to inform a server overseer. If at query 100, it is determined that the time since the last echo testing is less than predetermined maximum period TMR, processing unit 30 or 54 investigates at 112 whether there is a packet in a MCMP incoming packet queue. If not, the maintenance loop of FIG. 4 is re-entered. If so, a packet processing operation 114 is executed. It should be noted that the MCMP incoming packet queue contains both packets received from the network, and packets placed into the queue by the MCMP protocol.
  • FIGS. 6A through 6E illustrate operation 114 carried out under the MCMP protocol by processing unit 30 of primary server 14 or of a secondary server 22 selected for overflow handing.
  • overload detector 24 decides whether processing unit 30 is too busy to handle the incoming packet (which may be, for example, a user request for a code module). If so, processing circuits 50 investigate the MCMP packet header at a junction 126 to determine whether the packet can be shunted to a secondary server 22. If so, a further investigation 128 is conducted to determine whether the incoming packet has already been shunted.
  • secondary-server selector 26 accesses list 28 in a step 130 to find the secondary server 22 with the lightest load.
  • processing unit 30, and more particularly, server selector 26 determines whether the selected secondary server is suitable for transfer of responsibility for the incoming packet. If the selected secondary server is suitable, the packet is flagged as the result of a service hand-off and forwarded to the selected secondary server (step 134).
  • step 130 If the secondary server selected in step 130 is not suitable for a hand-off, for example, if the response time of the secondary server is greater than a predetermined maximum, as determined at inquiry 132, a query 136 is made as to whether an incoming packet is the result of a service hand-off This inquiry 136 is also made if the packet cannot be shunted, as determined at decision junction 126.
  • processing circuits 50 undertake an investigation 138 as to whether the requested resource is available. If the resource is available, processing circuits 50 ask at 140 whether the resource has passed a pre-assigned expiration date. If so, a signal is transmitted in a step 142 to the source of resource to determine if a newer version of the resource is available. If a new version is available, as ascertained at a decision junction 144 a request for the newer version of the resource is transmitted to the source in a step 146. This request is flagged as non-shuntable and should be additionally flagged as a priority request.
  • processing unit 30 Prior to the processing of an incoming packet, e.g., a user request for a code module, processing unit 30 examines the header information in the incoming packet at an inquiry 150 to determine whether the packet contains user authentification information. Where user authentification information is found, the former encryption status of the packet is determined at 152. If the packet was not encrypted, a message is generated in a step 154 to report that the user authentification failed. If the incoming packet was encrypted, the MCMP header information is checked at 156 to determine if the source server is specified. If there is no source server specification, user authentification failure is reported in step 154.
  • an investigation 160 is conducted (by authentification code comparator 52) as to whether memory area 48 has a non-expired, cached copy of the user authentification data. If there is no non-expired, cached copy of the user authentification data in memory area 48, comparator 52 induces processing circuits 50 to obtain the user's authentification data from the source server and to store that data in memory area 48 (step 162).
  • step 154 A report as to user authentification failure (step 154) is also made if the source server is the host server (decision junction 158) and if comparator 52 finds in an investigation 170 that the user authentification data in the packet header does not correspond to any user authentification data in memory area 48.
  • evaluation 171 determines whether the packet should be handled directly by the MCMP protocol, or by another protocol. If evaluation 171 determines that the packet should be handled by the MCMP protocol directly, then the packet is processed accordingly at a step 173 as illustrated in FIG. 5. If evaluation 171 determines that the packet should be handled by a specific protocol, then processing circuits 50 determine in a step 172 which protocol (e.g., CMXD, UDSCP, MDBP, DPP) is appropriate for handling the content of the packet.
  • protocol e.g., CMXD, UDSCP, MDBP, DPP
  • a response is produced by processing unit 30 under the selected protocol or by the main MCMP protocol, as determined in an inquiry 174, that response is tranenutted in a step 176 to the client that originally made the request. If there was a service handoff, that is, if the packet was shunted to the host server, then the response will be transmitted to a computer other than the computer from which the host received the packet. In a step 178, processing unit 30 begins processing the next packet in the queue or waits for a new packet to arrive.
  • processing operation 173 includes an initial inquiry 116 into the type of packet. If the packet is an encryption packet, encryptionldecryption unit 38 or 60 is activated in a step 118 to decrypt the packet using the appropriate decryption module or key. In a subsequent step 120, the packet encased in the data area of the encrypted packet is flagged as non-shuntable and placed back into the MCMP incoming packet queue. If it is determined at inquiry 116 that the packet is not an encryption packet, an MCMP status report indicated an unknown packet type is issue in a step 122 and the packet is discarded.
  • the functionality of the MCMP protocol may be enhanced at a later time by enhancing the process illustrated in FIG. 5 to include conditions for additional types of packets.
  • the Code Module Exchange Protocol handles dynamic downloading of executable code, program version control, client-to-client module exchange, virus and malicious program protection, data uploading, idle-time downloading, and code module caching. These functions are variously performed in servers 14 and 22 by code module exchanger 40 and version detector 42 and in user computer 12 by code module exchanger 56, author identification comparator 66, and unidirectional data submission and collection circuit 86, as well as by various nondesignated generic processing circuits 50 and 70.
  • the server-side portion of the CMXP protocol as implemented in part by code module exchanger 40, handles the delivery of code modules and supporting resources such as graphic images and fonts.
  • Requests to the CMXP server and to code module exchanger 40 can reference a file, a portion of a file (such as a code module), or a portion of a code module or other supporting module. Because programs are broken down into separate code modules, these code modules can be delivered on an as-needed basis, eliminating the need to download an entire program before execution thereof can commence.
  • the program should be immediately terminated and restarted using the new version code modules.
  • the author of a program can override any of these update procedures by including a custom update module in the new version of the program,. This code module is downloaded (if necessary) and executed whenever a version conflict arises. Then, an election can be made to perform any of the above procedures or a custom procedure such as remapping the contents of the program's memory area so that they can be used by the new version.
  • Code modules and associated resources are cached by both user computers 12 and secondary servers 22.
  • the caching rules can be incorporated into the CMXP protocol and/or the applications program itself This allows custom caching rules to be built into an application, thus providing for special caching schemes and hybrid applications.
  • FIG. 7 illustrates operations executed by digital processing circuits of processing unit 30 which are functionally modified in accordance with the CMXP protocol.
  • the operations include a check on author identification.
  • the author blacklist in memory area 68 of user computers 12 is transmitted to the user computers from a server which undertakes maintenance operations to keep the list updated (FIG. 8).
  • processing circuits 50 inquire at 180 whether an incoming packet constitutes a request for a resource. An affirmative answer to this inquiry leads to a further inquiry 182, as to whether the requested resource is available for anonymous access. If the resource is restricted, a determination 184 is made as to whether the requesting user has rights to access the requested resource. If the user has no such rights, an "access denied" message is returned to the requester in a step 186. If the requested resource is available to the requesting party, processing circuits 50 determine at a decision junction 188 whether the requested resource contains executable code. An affirmative determination causes a query 190 as to the validity of the author's fingerprint. If the fingerprint or author identification is invalid, a message is generated for a responsible party in a step 192. The local copy of the resource is deleted in a subsequent step 194 and a message "Resource Distribution Prohibited" is transmitted to the requesting party in a step 196.
  • a check 198 is made as to whether the author is blacklisted. A blacklisting leads to deletion of the local copy of the resource in step 194 and the issuance of the message "Resource Distribution Prohibited" in step 196. If the author is not blacklisted, or if the requested resource does not contain executable code, as determined at decision junction 188, then the processing unit 30 queries at 200 whether the client already has an up-top-date copy of the resource. If the client or user already has the latest version of the resource, a message to that effect is transmitted in a step 202. If the client or user's copy of the resource is an older version, the requested resource is transmitted to the client in a step 204.
  • an investigation 206 is made as to whether the packet constitutes a request to modify a resource. If so, and if the resource is not available for anonymous modification, as determined at a decision junction 208, then processing unit 30 queries at 210 whether the user has rights to modify the resource. If the user has no such rights, then a message "Access Denied" is returned to the requester in a step 212. If the resource is available for modification by anybody (decision junction 208) or by the particular user (query 210), the processing unit 30 makes the requested modification to the resource in a step 214 and notifies key secondary servers, in a step 216, of the change to the resource.
  • the processing unit 30 checks at 218 whether the packet is an update to a prohibition list, for example, a list of prohibited users or blacklisted authors. If the packet is such an update and is encrypted, as determined at decision junction 220, then the processing unit 30 determines at an inquiry 222 whether the packet was sent under the system user account. If so, the cached copy of the prohibition list is updated in a step 224 and all secondary servers are notified of the update in a step 226.
  • a prohibition list for example, a list of prohibited users or blacklisted authors.
  • an incoming update request is not encrypted (decision junction 220) or is not sent under the system user account (inquiry 222), then an alert message is issued to an appropriate party in a step 228.
  • a special status report is issued if an unknown packet type is received.
  • processing unit 30 asks in an initial query 232 asks whether the time since the last list update is more than a predetermined number of hours. If that much time has passed, an attempt 234 is made to contact the next server upstream of the server conducting the inquiry. If that server cannot be contacted, as determined in a scan 236, a check 238 is made as to whether there are other servers available. If another server is available, an attempt 240 is made to contact that server. If no server can be contacted, the time is again checked, at 242. If a predetermined interval has lapsed since the last update, then an alert is provided to an appropriate party in a step 244.
  • the processing unit 30 determines whether the prohibition list has been modified since the list was cached by the processing unit. Where such a modification has occurred, a copy of the prohibition list is obtained in a step 250.
  • the encryption status of the obtained list is investigated at 252. If the copy of the prohibition list. Finding a nonencrypted copy of the prohibition list leads to an alert status in a step 254, while an encrypted packet is investigated at 256 to determine with the packet was sent under the system user account.
  • a properly sent packet results in an update of the cached copy of the prohibition list in a step 258 and a notification of the update to all servers in a step 260.
  • UDSCP Uni-Directional Data submission and Collection Protocol
  • submissions can be directed to either a primary server 14 or a secondary server 22. All submissions are then collected at a central server, where the submissions are processed by an application-specific server-side module. This method would be particularly useful for collecting all form submissions on one server where they can be incorporated into a LAN-based mail system.
  • a submission can be again directed at either a primary server 14 or a secondary server 22.
  • the submissions are collected on the servers to which they were originally submitted (or are shunted using the standard load collection rules).
  • the submissions are then processed by an application-specific server-side module. This module could, for example, e-mail all of the submissions to an Internet e-mail address.
  • FIG. 9 illustrates program steps undertaken by digital processing circuits of processing unit 30 which are functionally modified in in accordance with the UDSCP protocol. These circuit handle data submissions transmitted from user computers 12, particularly from unidirectional data submission and collection circuit 90 of processing unit 54, and from other servers.
  • the processing unit 30 inquires whether an incoming packet is a data submission. If so, another inquiry 264 is made as to whether the data has to be collected immediately. If immediate collection is called for, the next question 266 entertained by the processing unit 30 is whether the data has to be collected at the source server. If not, the packet is passed in a step 268 through to a module that handles the final data collection.
  • This module handles e-mailing the submission, recording it in a database, writing it to a file, or preforming any other necessary server-side task with the data. Subsequently, in an investigation 270, it is checked whether the request has been processed by the data collection module. If so, the packet is removed in a step 272 from the UDSCP submission processing queue, assuming that is where the packet was obtained. Then a status report is issued at 274 indicating successful data packet transmission. If investigation 270 reveals that the request has not been processed by the data collection module, the processing unit 30 questions at 276 whether the failure to process was due to a possibly temporary condition. If the answer to this question 276 is negative, a status report 278 is issued describing the error condition. If the answer to the question 276 is affirmative, a status report 280 is issued describing the condition and indicating the possibility of delay in processing the data. The packet is then added in a step 282 to the UDSCP processing queue.
  • a status report 284 is issued indicating success and the packet is then added in a step 286 to the UDSCP processing queue. If an incoming data packet is a data submission which has to be collected immediately at the source server, as determined at inquiries 262 and 264 and in response to question 266, a check 288 is made as to whether the host server is the source server. If so, the packet is passed in step 268 through to a module that handles the final data collection. If not, processing unit 30 conducts an investigation 290 as to whether the source server can be contacted.
  • a status report 292 is generated indicating that there will be a delay in processing the data and the packet is then added to the UDSCP processing queue in step 286. If the source server can be contacted, the data is transmitted to that server in a step 294. If the UDSCP function-modified generic processing circuits of processing unit 30 are provided with a packet other than a data submission, a report is produced in a step 296 indicated that the packet is of unknown type.
  • FIG. 10 illustrates steps in a maintenance loop undertaken by generic digital processing circuits in processing unit 30 which are functionally modified in accordance with the UDSCP protocol.
  • an inquiry 298 is made as to whether there are entries in the UDSCP submission processing queue. If so, the first entry is read in a step 300. Subsequently, processing unit 30 decides at junction 302 whether more than X seconds have passed since a date and time stamp on the entry. If not, the UDSCP submission processing queue is investigated at 304 to ascertain whether any further entries are in the queue. If so, the next entry is read in a step 306 and again the processing unit 30 decides at junction 302 whether more than X seconds have passed since a date and time stamp on the entry.
  • a query 308 is made as to whether the server is too busy to handle the data submission. If the server is indeed too busy, processing unit 30 questions at 310 whether the data has the be collected immediately. If the data collection is not urgent, processing unit 30 determines at 312 whether the date and time stamp on the entry was earlier than a particular time. If the date and time stamp is recent, processing unit 30 returns to investigation 304 to check any remaining data submissions in the UDSCP submission queue.
  • processing unit 30 determines at a decision junction 314 whether the data has to be collected by the source server. If not, the packet is passed in a step 316 to a module that handles the final data collection. This module handles e-mailing the submission, recording it in a database, writing it to a file, or preforming any other necessary server-side task with the data. Subsequently, processing unit 30 checks at 318 whether the data submission was processed by the data collection module.
  • the packet is removed from the UDSCP submission processing queue in a step 320 and the processor 30 returns to investigation 304 to ascertain whether any further entries are in the queue. If the data submission packet has not been processed, which is discovered at 318, an inquiry 322 is made as to whether the failure to process the request is due to a possibly temporary condition. If not, a notification 324 is generated for alerting an appropriate person as to the failure. If so, the date and time stamp on the data submission is updated in a step 326.
  • processing unit 30 determines at decision junction 314 that the data has to be collected by the source server and further determines at a subsequent decision junction 328 that the host (itself) is the source server, then the packet is processed (step 3 16).
  • the source server must do the data collection and is a different computer, as determined at decision junction 328, then an attempt 330 is made to contact the source server. If the source server cannot be contacted, the date and time stamp on the data submission is updated in step 326. If the source server is available, the data submission is transmitted to the source server in a step 332 and the packet is removed from the UDSCP processing queue in a step 334.
  • the MCMP protocol handles Load Distribution, User Authentication, and Encryption. All other functions are handled by sub-protocols.
  • the MCMP protocol has four sub-protocols. These are the Code Module Exchange Protocol (CMXP), the Uni-directional Data submission and Collection Protocol (UDSCP), the Metered Delivery and Billing Protocol (MDBP), and the Distributed Processing Protocol (DPP). This set of protocols can be expanded in the future to add additional functionality to the MCMP protocol.
  • CMXP Code Module Exchange Protocol
  • UDSCP Uni-directional Data submission and Collection Protocol
  • MDBP Metered Delivery and Billing Protocol
  • DPP Distributed Processing Protocol
  • All MCMP packets consist of a MCMP header, followed optionally by one or more resource identifiers, and a data area called the packet body (FIG. 1).
  • the entire size of an MCMP packet can be calculated as 128+RsrcIDLen+PacketSize, where RsrcIDLen and PacketSize are elements of MCMP header (see below).
  • the MCMP header identifies the sub-protocol to which the packet belongs, as well as the type of packet.
  • the MCMP header contains load distribution, user authentication, and encryption information.
  • the Resource identifiers identify any resource or resources referred to in the packet (the ResourceReq flag being set).
  • the MCMP packet body contains packet-type specific information and is always interpreted by a subprotocol handle. The packet body is optional and can be omitted b ysetting the PacketSize element of the MCMP headet to be 0.
  • the MCMP header structure is defined as:
  • MPVersion This is a 4-character version identifier for the Master Protocol. If the structure of the MCMP header or any other major component of the Master Protocol structure is revised, this version number is incremented.
  • ProtoVendor This is an 8-byte text literal that describes the software vendor initial responsible for maintaining the sub-protocol specificiation for the sub-protocol to which the packet belongs.
  • ProtoID This is an 8-byte text literal assigned by the software vendor specified in the ProtoVendor element. This identifies the sub-protocol to which the packet belongs. The combination of ProtoVendor and ProtoID uniquely identifies a sub-protocol.
  • ProtoVer This is a 4-byte text string that specifies the version of the sub-protocol specified in the ProtoVendor and ProtoID elements. The first to characters are the major version, the second two the minor version. All characters must be used, so if the major version is one character long, it must be written as 01, not 1. This value does not contain a decimal point. For example, version 2.4 would be 0 2 4 0.
  • Packet-Type Identifier A two-byte integer assigned by the vendor that uniquely identifies the packet type within a particular sub-protocol.
  • PacketVersion This is a 4-character identifier for the packet version. When the structure of a packet is changed, this version number is incremented. This allows a sub-protocol handler running on an MCMP server to deal with both old and new packet structures, should a packet structure need to be altered.
  • the format for the string is the same as the format of the ProtoVer element of the MCMP header.
  • Shunted flag A flag indicating whether this packet has been shunted as the result of a service hand off.
  • Shuntable flag (Shuntable). A flag indicating whether this packet can be shunted. This flag and the Shunted flag are mutually exclusive.
  • Encrypted flag A flag indicating whether the packet was encrypted. This flag is cleared when a packet is placed in the MCMP Server incoming packets queue, unless the packet is place there by the decryption system, in which case the flag is set.
  • Request-Resource flag Indicates whether the packet constitutes a request for a resource.
  • RsrcIDs Number of Resource Identifiers
  • Resource Identifier Length (RsrcIdLen): Specifies the combined length of all resource identifiers following the MCMP Header structure.
  • Originating Host Address (OrigIP, OrigPort): This is the IP address of the host from which the request originated. If the packet was shunted, this is the IP address of the host that originally transmitted the request, not the address of the server that forwarded the request.
  • RsrcSourceIP This is the IP address of the host on which the original copy of the requested resource resides, if the Request-Resource flag is true.
  • Cached Copy Date/Time Stamp This is the date and time stamp of the cached copy of the resource, or zero if no cached copy exists. If the date and time stamp of the resource match this date and time stamp, the resource content will not be returned.
  • PacketSize The size (in bytes) of the packet body following the MCMP Header and (if present) the resource identifiers.
  • User ID and Password for client authentication A user ID and Password used to authenticate the client.
  • the authority for a user's ID and Password is the Resource Source IP server. If a request is made to a secondary server for a password-protected resource, the secondary server must check with the primary (or source server) for password authentication. This information can be cached for the duration of the session.
  • Transaction ID A unique ID assigned by the host initiating the transaction. This is used to track a transaction over one or more service hand-offs. For an encryption packet, this should be set to zero (although it can be set to a non-zero value in the encased packet).
  • the Resource identifiers identify the resource or resources to which the packet refers. Resource identifiers are null-terminated text strings.
  • the basic format for a resource identifier is:
  • the Resource ID is optional, and does not need to be included in a MCMP packet, so long as the ResourceReq flag is not set.
  • MCMP -- Encrypt The encryption packet is used when data must be encrypted.
  • a packet to be encrypted is encased in the data area of a MCMP System encryption packet.
  • the MCMP Header for the encryption packet is:
  • PacketSize Size of encased packet in encrypted form plus 32 bytes
  • the packet body of the encryption packet is:
  • the header for the encryption packet is:
  • STATUS REPORT (MCMP -- Status): The status report packet is used to return the status of an operation. When used, it is always a response to a previously transmitted request.
  • the status packet contains detailed error information, including an English language description of the error or status value which can be displayed by the application if it cannot interpret the error code.
  • a status report packet body consists of one or more information fields, which can vary in length.
  • the first information field is always a Status Report Header.
  • Each information field consists of an 8-byte header which indicates the length and type of the information field, followed by the field itself.
  • the MCMP Header for the status report packet is:
  • the generic status report header (MSR -- Header) is always present in all status report packets, and is always the very first information field in the packet. It has the following structure:
  • ErrorType is one of the following:
  • the ProtoVendor and ProtoID from the Status Report Header are used to identify the protocol.
  • the Short Description information field type (MSR -- ShortDesc) is a short description of the error, 40 characters long or shorter, that can be used in a list or wherever a brief, friendly error description is needed.
  • This packet is 40 bytes long, and is structured as follows:
  • the Long Description information field type (MSR -- LongDesc) is a longer description of the error, which can vary in length up to 2048 characters. This description can span multiple lines, with each line terminated by a carriage return (h0d). The length of this description is determined by the length of the information field, and the entire content of the information field is one long buffer variable containing the description as text. There is no maximum length to a line, and lines may be word-wrapped at any position when this description is displayed.
  • the TenCORE 7.0 Execution Error Data (MSR -- XErr70) is an exact snapshot of the data generated by a TenCORE execution error, and returned by TenCORE in the execution error memory block. It is 256 bytes long. This information field type is normally only included if the error being reported is a TenCORE execution error.
  • the TenCORE 7.0 Execution Error To- Stack (MSR -- XErr70do) is an exact snapshot of the TenCORE execution error -do- stack. The size of the data varies based on the size of the TenCORE -do- stack at the time of the error.
  • PERFORMANCE STATISTICS REQUEST (MCMP -- PerfStatReq): The performance statistics request packet requests a server's current performance and load statistics.
  • the MCMP Header of a performance statistics request is:
  • the response to this packet should be either an MCMP -- PerfStatResp or a MCMP -- Status packet.
  • MCMP -- PertStatResp This packet is a response to an MCMP -- PerfStatReq packet and contains a performance statistics report for the server to which it was addressed.
  • the MCMP Header of a performance statistics report is:
  • the Packet Body of a performance statistics report is:
  • PUsage:Current processor usage percentage (0% to 100%). Set to -1 if processor usage percentage is not available.
  • CurReqs Approximate number of requests currently being processed.
  • TotalReqs Total number of requests that can be processed at one time.
  • ShuntReqs Maximum number of requests before shunting occurs. This is usually less than TotalReqsto allow some extra system resources for the purpose of shunting requests.
  • PmemTotal Number of bytes of physical memory on server, or -1 if amount not known.
  • VmemTotal Number of bytes of virtual memory available on server, -1 if not known.
  • VmemUsed Number of bytes of virtual memory in use, or -1 if not known.
  • AreqPMethod Method that will be used by the server deal with new incoming requests, based on the other statistics in this packet. This can have the numerical value 1, 2, or 3.1 indicates that new requests will be processed normally, 2 indicates that new requests will be shunted; 3 indicates that new requests will be refused.
  • USER AUTHENTICATION INFORMATION REQUEST (MCMP -- UserIReq): This packet requests user authentication information on a particular user. This packet must be encrypted, and is sent only from a secondary server to a primary server. The receiving server must check that the sender is listed as a secondary server before responding to this request.
  • the expected response is either an MCMP -- Status packet or an MCMP -- UserIResp packet.
  • This packet uses a special type of resource identifier, which is defined as follows:
  • the User Authentication Database (UADB) is stored in a tree-file. User information is stored in ⁇ LocalUsers. Inside the ⁇ LocalUsers folder are folders for each user, named based on the user's ID. In each user's folder are folders for each vendor (i.e. "Catharon”, "CTC”, etc.), and inside the vendor folders are folders for each protocol defined by that vendor. The contents of a protocol folder are protocol-specific. The path specified in the resource ID is rooted at ⁇ LocalUsers ⁇ username.
  • Basic user authentication information is stored in ⁇ Catharon ⁇ MCMP ⁇ BaseAuthData. This is structured as follows:
  • the entire user authentication tree is retrieved for the specified user.
  • the ability to read a specific item from the user authentication tree is provided for future use and expandability.
  • That data can be cached for the period of time specified in the ExpTime element of the UserAuthData structure.
  • the user authentication data may not be cached longer than the specified time.
  • the MCMP Header of the User Authentication Information Request is:
  • ResourceID One; specifying the user to retrieve information about, and what information to retrieve.
  • USER AUTHENTICATION INFORMATION RESPONSE (MCMP -- UserIResp): The response to an MCMP -- UserIReq packet, this packet contains the requested information in its data area.
  • This data is either the raw data read from the requested data block in the user database, or (if uadbitem is omitted) is a tree file containing the entire user information tree for the specified user, with the root of the file being equivalent to ⁇ LocalUsers ⁇ username in the UADB.
  • the MCMP Header of the User Authentication Information Response is:
  • PacketType MCMP -- UserIResp (hO009)
  • ECHO REQUEST (MCMP -- EchoReq): This packet is used to time the connection to a particular MCMP host. When this packet is received by an MCMP host, a MCMIP -- EchoResp packet is immediately sent back.
  • the data area can contain any data, up to a maximum size of 2048 bytes. The return packet's data area will contain the same data.
  • the MCMP Header of the Echo Request is:
  • ECHO RESPONSE (MCMP -- EchoResp): This packet is sent in response to an MCMP -- EchoReq packet.
  • the MCMP Header of the Echo Response is:
  • Some files in a directory may support additional access pennission information.
  • a tree file could contain information on access permission for individual units within the tree file.
  • the following is a list of the packet types used by the CMXP protocol at this time.
  • the functionality of the CMXP protocol can be expanded in future by adding to this list of packet types.
  • READ RESOURCE REQUEST (CmxP -- ReadRsrcReq): This packet is a request to read one or more resources. It is sent from a client to a server to download a resource, sent from a client to a client to request a code module transfer for a plug-in module, or sent from a server to a server to request transfer of the appropriate resource to service a client request.
  • a CMXP -- ReadRsrcReq packet can request either resource content, resource information, or both. Because the definition of a resource includes file directory and code module directories, this packet can also be used to request a list of files in a directory or code modules in a file.
  • This packet is responded to with a series of packets (one for each request resource). These packets are either CMXP -- ReadRsrcResp (if the resource was successfully read) or MCMP -- Status (if there was an error reading the resource).
  • the MCMP Header of a read resource request packet is:
  • ResourceID's One or more, Identifying resources to read
  • the Packet Body of a read resource request packet is:
  • the elements of the packet body are, in detail:
  • IdlePreCache If set, indicates the the request is the result of an idle-time pre-caching operation initiated by the client without user involvement.
  • a CMXP server processes packets with this flag clear before packets with this flag set are processed.
  • requests with this flag set will be dropped before requests with this flag clear.
  • IncludeInfo and IncludeData can both be set in the same request In this case, the response is the resource information followed by the resource content. This is the most common request type. At least one of these flags must be set in each request packet
  • CMXP -- ReadRsrcResp Sent in response to a CMXP -- ReadRsrcReq packet, this packet contains the requested information. Note that this packet is never sent in response to a CMXP -- ReadRsrcReq if an error condition exists, instead, a MCMP -- Status packet is sent.
  • the packet body may contain resource information and/or resource content.
  • the resource information if it is present, always comes first in the packet body, followed by the resource content, if present.
  • the size of the resource information can be determined by reading the ResourceInfoSize element of the version of a program can be sucessfully merged with code modules from an old version of the program.
  • RaSizeAInfo The size, in bytes (1 to 8), of the associated information for the resource (RsAlnfo).
  • RsSizeSubName The maximum length, in characters, of the name of a subsidiary of the resource.
  • RsPTime The playing time, in seconds at the default playing speed, of the resource (if applicable); used for video clips, way files, midi files, animations, etc.
  • CMXP -- WriterSrc This packet writes data to the specified resource. This requires sending a packet to the primary server that cannot be shunted, so this can increase server load.
  • UDSCP protocol is recommended over the write functions of the CMXP protocol.
  • a CMXP -- WriteRsrc request may fail due to, among other things, the fact that the user is not allowed to write to the specified resource. This situation may be remediable by repeating the request with a user-id and password specified (in this case, the request must be encased in a MCMP -- Encrypt packet).
  • the status code returned when access is denied due to failed user authentication There are two variations of the status code returned when access is denied due to failed user authentication.
  • One variation indicates that the client should prompt for a user name and password. This is a "hint" to the client that the resource may be accessible via a user name and password. It is not conclusive.
  • the variation on the Access Denied code does NOT indicate whether access is really available to anyone, i just indicates whether the client should ask.
  • the packet body contains the data to be written to the resource.
  • the MCMP Headerof the write resource packet is:
  • ResourceID's One, the ID of the resource to-wnte to
  • CREATE RESOURCE (CMXP -- CreateRsrc): This packet creates a subsidiary in the specified resource. This includes files, directories, and units. The same rules regarding user authentication apply to this packet as apply to the CMXP -- WriteRsrc packet.
  • the MCMP Header of the create resource packet is:
  • ResourceID's One, the ID of the resource In which to create the new subsidiary.
  • the Packet Body of the create resource packet is:
  • the elements of the packet body are, in detail:
  • ReSise The size, in bytes, of the new resource. If creating a TenCORE nameset or dataset, this must be a multiple of 256 bytes, and is equivalent to the records argumen of the -createn- command multiplied by 256 (to convert from records to bytes). When creating new directories, this is ignored.
  • R-AInfo Associated information for the resource, if applicable (see CMXP -- CreateRsrc above)
  • RsMaxSubs The number of subsidiaries allowed in the resource, if applicable. This is required for TenCORE namesets, and is equivalent to the names argument of the -createn- command. In most cases, when not dealing with TenCORE namesets, this is ignored.
  • R-SizeAInfo The size of the resources associated information. For namesets, this is equivalent to the infolength argument of the -createn- command.
  • RsSizeSubName Maximum length of a subsidiary's name. For TenCORE namesets, this is equivalent to the namelength argument of the -createn- command. In most cases when-not dealing with TenCORE namesets, this is ignored.
  • ReName The name of the resource to create. The length of this name and the rules for allowed characters depend on the type of resource being created.
  • RaName2 This is a secondary name for the resource. It is not currently used, but is provided for future use. This may be used, for example, to specify a short file name alias to go with a long filename in Windows 95/NT.
  • RaType This specifies the type of resource being created. Note that not all resource types are necessarily valid for all possible resources in which they could be created (i.e., one cannot create a file inside of a unit). Where only one resource type is possible for a particular containing resource, the value ⁇ default ⁇ is used (for example, the only type of resource that can be created inside a TenCORE nameset is a block). This value is an 8-byte text literal.
  • CMXP -- DestroyRsrc This packet destroys the specified resource.
  • the same rules regarding user authentication apply to this packet as apply to the CMXP -- WriteRsrc packet.
  • the MCMP Header of this packet is:
  • ResourceID's One, the ID of the resource to destroy
  • CMXP -- RenameRsrc This packet renames the specified resource.
  • the same rules regarding user authentication apply to this packet as apply to the CMXP -- WriteRsrc packet.
  • the packet body contains the new name for the resource.
  • the MCMP Header of this packet is:
  • ResourceID's One; the ID of the resource to rename
  • the Packet Body of the rename resource packet is:
  • CMXP -- CopyRsrc This packet copies the specified resource.
  • the same rules regarding user authentication apply to this packet as apply to the CMXP -- WriteRsrc packet
  • the MCMP Header of the copy resource packet is:
  • ResourceID's Two; the first is the location of the resource to copy, the second the location to create the new copy of the resource.
  • CMXP -- MoveRsrc This packet moves the specified resource.
  • the same rules regarding user authentication apply to this packet as apply to the CMXP -- WriteRsrc packet.
  • the MCMP Header of the move resource packet is:
  • ResourceID's Two; the first ts the old location of the resource, the second the new location for the resource.
  • CMXP -- AltSListReq ALTERNATE SERVER LIST REQUEST
  • ResourceID One--The resource for which to list secondary servers.
  • CMXP -- AltSListResp This packet is sent in response to an CMXP -- AltSListReq packet and contains the list of alternate servers.
  • the MCMP Header is:
  • the Packet Bodyof the CMXP -- AltSListResp packet is:
  • the following is a list of the packet types used by the UDSCP protocol at this time.
  • the functionality of the UDSCP protocol can be expanded in future by adding to this list of packet types.
  • UDSCP -- submission This is the primary packet type for the UDSCP protocol. It is generated by a client, and then forwarded from server to server until it reaches the collection point.
  • the packet body consists of a UDSCP Header followed by the content of the submission.
  • the MCMP Header of the data submission packet is:
  • the UDSCP Header is:
  • HeaderSize The size, in bytes, of the UDSCPSubmitHeader structure. This value should be read to determine the size of the whole structure, this allowing the structure to be expanded in future without affecting existing code.
  • DataSize The size, in bytes, of the content of the submission following the UDSCP Header.
  • Cmethod The collection method to be used. This is an integer value. A setting of 1 causes data to be collected and processed at a centeral server, while a setting of 2 allows data to be processed on secondary servers.
  • Priority The priority of the submission. This is an integer value, and can be either 0 for low, 1 for normal, or 2 for high priority.
  • UDSCP servers attempt to process high priority submissions immediately, while normal and low priority submissions are held in the UDSCP submission queue and processed when the server would othewise be idle. If a normal or low priority remains in the LTDSCP queue for longer than the user configurable time limit, the server will attempt to process it immediately regardless of load or, failing to do so, notify a responsible person.
  • the time limits for low and normal priority submissions are configurable separately, and low priority submissions are usually configured for a longer timeout.
  • This flag is set if the submission has been forwarded by a UDSCP server, or clear if this is the first UDSCP server to deal with the submission (i.e., the submission came from a client).
  • QUEUE STATUS REQUEST (UDSCP -- QueueStatusReq): This packet requests the status of the UDSCP queue.
  • the expected response is either an MCMP -- Status packet or a UDSCP QueueStatusResp packet.
  • the MCMP Headerof the queue status request packet is:
  • QUEUE STATUS RESPONSE (UDSCP:QueueStatusResp): This packet is the response to a UDSCP -- QueueStatusReq packet. It contains infonnation about the UDSCP server's current UDSCP queue status.
  • the MCMP Header is:
  • the Packet Body of this status response packet is:
  • MDBP Metered Delivery and Billing Protocol
  • the MDBP protocol works closely with the CMXP protocol.
  • the CMXP protocol is used to deliver the content in encrypted form.
  • the content is then decrypted when it is unlocked by the MDBP libraries on the client machine.
  • the content is unlocked when it is paid for with credit on the local machine. Credit can be replenished through the MDBP protocol.
  • An MDBP -- CreditReq is sent from the client to the server
  • the server responds with an MDBP -- CreditTransfer
  • the client sends an MDBP -- PurchaseReport to the server
  • the following is a list of the packet types used by the MDMP protocol at this time.
  • the functionality of the MDBP protocol can be expanded in future by adding to this list of packet types.
  • the MDBP packet types are described in detail below.
  • MDBP -- CreditReq This packet requests additional credit from the server.
  • the packet body contains the user's ID code, which is used to access the user's data in the user database, as well as the amount of credit to be purchased.
  • the user's data includes a billing method to use to pay for the credit.
  • This packet must be encrypted.
  • the expected response is either an MDBP -- CreditResp or an MCMP -- Status packet.
  • the MCMP Header of a credit request packet is:
  • the Packet Bodyof a credit request packet is:
  • MDBP -- CreditTransfer This packet is the response to an MDBP -- CreditReq. It actually performs the transfer of credit from the server to the client.
  • the packet body contains information on the credit transfer. This packet must be encrypted.
  • the MCMP Header of a credit transfer packet is:
  • the Packet Body of a credit transfer packet is:
  • MDBP -- RegisterUser This packet is used for the initial registration of a user with a credit server. It causes a new entry to be created in the user registration database.
  • the packet body contains information about the user which will be written into the standard fields in the user's new record. The information can be read and modified at a later time through use of the MDBP -- WriteUserData and MDBP -- ReadUserData packets. This packet must be encrypted.
  • the expected response to this packet is an MDBP -- RegisterUserResp or MCMP -- Status packet.
  • the MCMP Header of a user registration packet is:
  • the Packet Body of a user registration packet is:
  • MDBP -- RegisterUserResp This packet is the response to an MDBP -- RegisterUser packet. It acknowledges the fact that the user has been registered, and returns the user's assigned ID code.
  • the MCMP Header of this packet is:
  • the Packet Body is:
  • WRITE USER DATA (MDBP WriteUserData): This packet writes data to the user database. This uses a resource identifier to identify the element in the user registration database to write to. The packet body is the data to be written. This packet uses a special type of resource identifier, which is defined as follows:
  • the user database contains a system folder and a publishers folder.
  • the system folder contains the data specified in the initial User Registration packet, and can be expanded to contain additional data.
  • the publishers folder contains a subfolder for each publisher, named based on the publisher's name, and the publisher's folder contain, in turn, publication folders, named based on the publication.
  • the organization of data within a publication folder is specific to the publication.
  • the MCMP Header of the write user data packet is:
  • READ USER DATA (MDBP -- ReadUserData): This packet reads data from the user database. This uses a resource identifier to identify the element in the user registration database to read from. The format of the resource identifier is the same as that for the resource identifier used in the MDBP -- WriteUserData packet.
  • This packet is responded to with a series of packets (one for each request resource). These packets are either MDBP -- ReadUserDataResp (if the resource was successfully read) or MCMP -- Status (if there was an error reading the resource).
  • the MCMP Header of the read user data packet is:
  • MDBP -- ReadUserDataResp This packet is the response to an MDBP -- ReadUserData packet. It contains the content of the requested element of the user registration database. The body is the data that was read.
  • the MCMP Header is:
  • the data area contains a generic royalty report header followed by a publication-specific royalty-report data area.
  • the royalty report header is sufficient to report the needed royalty information, so the data area is optional and does not have to be included. Any data following the royalty report header is assumed to be publication-specific data.
  • the MCMP Header of the royalty report packet is:
  • Each system involved in the distributed processing process must be configured with a list of those systems which can assist it with a task, as well as those systems which it can assist with tasks.
  • This list can include entries with wildcards, to specify an entire network, such as 192.168.123.* for the entire 192.168.123. C-level network.
  • This system configuration is to control who can utilize a system's processor. For example, a company might want to limit shared processing to systems within it's own internal network, for security reasons.
  • Systems can also be assigned priorities for access to a computer's processor. For example, a company may want all of it's computer to grant distributed processing requests from other computers on it's network in preference to other requests. However, if that company is affiliated with some other company, it might want to grant that other company access to it's computers for distributed processing purposes, provided that none of it's own computers require processing assistance.
  • the following is a list of the packet types used by the DPP protocol at this time.
  • the functionality of the DPP protocol can be expanded in future by adding to this list of packet types.
  • DPP -- AssistReq This packet is sent by a system requiring processing assistance to another system to request processing assistance from that system. This packet contains all the information needed to initiate a distributed process, including the resource identifier for the initial code module to handle the process, so that the code module can be fetched via CMXP if necessary.
  • the response to this packet is either a DPP -- AssistResp packet (if the recipient system can assist) or an MCMP Status packet (if the recipient system can not assist).
  • Possible reasons for an MCMP -- Status packet can include:
  • the system to which the packet was sent was not allowed to assist with the request. This is a result of the system generating the request not being listed in the appropriate configuration file on the receiving system.
  • Request Superceded is a separate status code from Access Denied is that "Access Denied" may generate an error if encountered by a program searching for systems to assist it (to notify the user of a possible mis-configuration) while Request Superceded would simply indicate that the system is not available to assist with the task at that given time, and would therefore not generate an error.
  • the MCMP -- Status packet will contain an additional task-specific error code indicating the specific error which occurred.
  • Task specific errors might include an error indicating that the system is not capable of assisting with the task due to a hardware limitation.
  • the packet body of the assistance request packet consists of a 32-byte header, followed by a task-specific data area, which contains any infommation that the code module referenced in the Resource ID requires to assist in the processing of the task. This could for example, include an image (if an image must be processed) or a description of a 3D environment to be rendered.
  • the MCMP Header of the assistance request packet is:
  • ResourceID One (The ID of the code module to handle the distributed process)
  • the DPP -- AssistReq Header is:
  • Process-ID This is a 2-byte integer value that identifies the process. It is assigned by the system initiating the process, and is a unique identifier when combined with that system's IP address.
  • DPP -- AssistResp This packet is sent in response to a DPP -- AssistReq to acknowledge that the system has begun assisting with the task Because this is simply an acknowledgement message, there are no Resource ID's and there is no packet body.
  • the MCMP Header is:
  • DPP -- EndTaskReq This packet is sent to an assisting system to instruct that system to cease assisting with a task prematurely (before the task is complete). This would be used, for example, if the user on the initiating system were to click a "cancel" button and abort the task.
  • the MCMP Header is:
  • ResourceID One (The ID of the code module to handle the distributed process)
  • the Packet Body of the end task request header is:
  • DPP -- EndTaskNotify This packet is sent by an assisting system to notify the initiating system that it will no longer be assisting with a task. This is used both by itself, and as an acknowledgement to a DPP -- EndTaskReq packet. This would be sent if, for example, the assisting system was to become too busy to continue to assist with the task, or if the assisting system was to be instructed by the initiating system to abort the task. This packet can also be used to notify an initiating system of a completed task.
  • the MCMP Header is:
  • ResourceID One (The ID of the code module to handle the distributed process)
  • the Packet Body of the end task notification packet is:
  • DPP -- UpDateReq This packet is sent by the initiating system to instruct the assisting system to transmit processed data (a DDP -- UpdateResp packet). For example, if an image was being processed, this would cause the assisting system to respond with the data making up the portion of the image that it has processed so far.
  • the use of this packet type depends on the task. Some tasks will not use this packet at all, and will instead automatically generate DPP -- UpdateResp packets at various intervals, and when the task is complete.
  • the MCMP Header is:
  • ResourceID One (The ID of the code module to handle the distributed process)
  • the Packet Body of the update request packet is:
  • DPP -- UpDateResp This packet is sent from an assisting system to an initiating system. It contains the data that has been processed so far as part of the task in question. For example, if an image is being processed, this packet would contain the portion of the image that had already been processed. Note that the data sent in these packets in not cumulative. That is, if two packets are sent in succession, the second contains only data not included in the first.
  • the packet body consists of a header, followed by task-specific data. All data not part of the header is assumed to be task-specific data.
  • the MCMP Header of the update response packet is:
  • ResourceID One (The ID of the code module to handle the distributed process)
  • code module is used herein to denote a self-standing portion of an applications program dedicated to the performance of a specific operation of the applications program. For example, in a painting program, one code module may control the drawing of a line, while another code module implements the application of color and yet another code module is used for generating a geometrical figure such as a circle.
  • code modules are independent in that at least some of them are not required for executing any particular operation. Sometimes two or more modules are required to interact to produce a particular result. However, in no case are all modules required.
  • machine-executable refers to code modules which are program modules, capable of controlling computer operations and changing the state of the arithmetic logic circuits of a general purpose digital computer, thereby changing the functionality of the general purpose digital computer.
  • machine-executable code modules do not include data files and other passive electronically encoded information.
  • the term "applications program” as used herein refers to any executable collection of computer code other than operating systems and other underlying programming for controlling basic machine functions.
  • the Modularized Code Master Protocol is an applications program which is itself modularized and transmittable in code modules over a network. For example, at least some subprotocols will not exist on some secondary servers. Should such a subprotocol be required for a secondary server to compete a task or process a user's request then that required subprotocol may be transmitted over the network from the primary server to the secondary server.
  • Subprotocols are handled by including a subprotocol identifier in the MCMP Header attached to each MCMP packet.
  • the circuits for handling the subprotocols may be plug-in modules which are handled in real-time by the CMXP protocol.
  • the appropriate subprotocol handler is called.
  • the subprotocol handler can then process the packet in whatever way is required.
  • a protocol handler becomes involved in the load distribution process because the MCMP server has no way of knowing what format the resources are in, how to transfer them between servers, or what the caching rules are.
  • the subprotocol handler must deal with accessing, transfer, and caching of the protocol-specific resources.
  • the subprotocol handlers are called periodically during the MCMP server's main processing loop, allowing it to perform various maintenance tasks. Alternatively, the subprotocol handler could be called from a loop running in a separate thread.
  • the handler for a specific subprotocol may request that the MCMP server flag a socket as being in a Proprietary Dialog Mode (PDM).
  • PDM Proprietary Dialog Mode
  • all incoming data is passed directly to the subprotocol handler without being processed by the MCMP server.
  • the subprotocol handler must pass any "extra" unprocessed data to the MCMP server, since it may have read a portion of one or more MCMP packets.
  • primary server or "source server” is used herein to denote the authoritative source for the resources relating to a particular application.
  • source server the authoritative source for the resources relating to a particular application.
  • the primary server for the TenCORE Net Demo would be the server where the latest version of the demo was always posted.
  • secondary server denotes a server that receives service-handoffs from a primary server.
  • a secondary server usually mirrors the content of the primary server for which it is secondary.
  • a secondary server for the TenCORE Net Demo would be a server that could take over servicing clients if the primary server became too busy.
  • a secondary server does not necessarily contain mirrors of the resources for which it is secondary server, inasmuch as the secondary server can request these resources from the primary server as needed.
  • a single machine is can be both a primary server and a secondary server.
  • a machine could be primary server for the TenCORE Net Demo, and secondary server for the Country Closet Clothing Catalog.
  • a single machine can function as primary server for multiple applications, and can function as secondary server for multiple applications.
  • resource is used herein to denote any block of data that can be used by a server or client.
  • a resource can be a file, a code module, a portion of a file, a code module, a portion of a code module. a file directory, a code module directory, or any related piece of information, including the CMXP Prohibited List.
  • the term “resource” is also used to refer to hardware and system resources, such as processor time and memory.
  • tree-file refers to a Catharon Tree-Structure Nameset File.
  • a tree-file contains a series of named sets of records, which are grouped and nested into a tree-like structure (similar to an operating system's file system).
  • names beginning with a percent sign "%" are reserved for internal use. Any other names may be used by whatever application is maintaining the tree-file. Currently, only one percent-sign name has been assigned.
  • TenCORE is an interpreted language which utilizes pseudocode.
  • Interpreter programs suitable for use with the TenCORE programming language as modified in accordance with the above descriptions are in common use today.

Abstract

A computerized system and an associated method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage. In accordance with the method, an applications program is stored in a nonvolatile memory of a first computer as a plurality of individual and independent machine-executable code modules. In response to a request from a second computer transmitted over a network link, the first computer retrieves a selected one of the machine-executable code modules and only that selected code module from the memory and transmits the selected code module over the network link to the second computer.

Description

This application includes a microfiche appendix consisting of four microfiche transparencies with a total of 325 frames including specification pages numbered 90 through 406.
BACKGROUND OF THE INVENTION
This invention relates to computing and communications on a computer network. More specifically, this invention relates to a computerized system and an associated method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage.
In the past several years, there has been an ever increasing number of individuals, corporations and other legal entities which have obtained access to the global network of computers known as the Internet. More precisely described, the Internet is a network of regional computer networks scattered throughout the world. On any given day, the Internet connects roughly 202 million users in over 50 countries. That number will continue to increase annually for the foreseeable future.
The Internet has provided a means for enabling individual access to enormous amounts of information in several forms including text, video, graphics and sound. This multi-media agglomeration or abstract space of information is generally referred to as the "World-Wide Web," which is technically a "wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents." To obtain access to the World-Wide Web, a computer operator uses software called a browser. The most popular browsers in the United States are Netscape Navigator and Microsoft's Internet Explorer.
The operation of the Web relies on so-called hypertext for enabling user interaction. Hypertext is basically the same as regular text in that it may be stored, read, searched and edited, with one important exception: a hypertext document contains links to other documents. For instance, selecting the word "hypertext" in a first document could call up secondary documents to the user's computer screen, including, for example, a dictionary definition of "hypertext" or a history of hypertext. These secondary documents would in turn include connections to other documents so that continually selecting terms in one documents after another would lead the user in a free-associative tour of information. In this way, hypertext links or "hyperlinks" can create a complex virtual web of connections.
Hypermedia include hypertext documents which contain links not only to other pieces of text, but also to other media such as sounds, images and video. Images themselves can be selected to link to sound or documents.
The standard language the Web uses to create and recognize hypermedia documents is the HyperText Markup ("HTML") Language. This language is loosely related to, but technically not a subset of, the Standard Generalized Markup Language ("SGML"), a document formatting language used widely in some computing circles. Web documents are typically written in HTML and are nothing more than standard text files with formatting codes that contain information about layout (text styles, document titles, paragraphs, lists) and hyperlinks.
HTML is limited to display functions (text, animation, graphics, and audio) and form submission. Inherent in the basic HTML protocol (set of software-encoded rules governing the format of messages that are exchanged between computers) are design limitations that prevent the implementation of the type of program functionality that is commonly used in today's desktop computers. Because of this limitation, it is impossible to enhance HTML documents with the features necessary to support the Internet applications currently being sought by industry and consumers.
Sun Microsystems and Netscape Communications have attempted to introduce additional program functionality through the implementation of Sun's Java programming language as a browser plug-in. Microsoft, in addition to supporting Java, has introduced Active-X as a browser plug-in. Currently, after two years of development, both Java and Active-X are still failing to deliver working software. These languages are plagued by software errors that crash the newer operating systems. Even the developers of these languages, Sun and Microsoft, are having major problems with Java and Active-X applications that they have written to demonstrate the capabilities of the languages.
Java, Active-X and almost all other programming languages use a programming paradigm based on the "C" programming language introduced by AT&T in the 1970's to develop the UNIX operating system. Although well suited for operating system development, "C" has two major drawbacks for Internet content delivery. The first drawback is that an entire program must be loaded before anything can be executed using the program. Because Internet content is open-ended, most applications can become very large, making downloading impractical due to the limited bandwidth of most Internet connections. Typical Java and Active-X applications take several minutes to download before they start running. The second drawback using programs based in "C" is that content development is very inefficient. "C" and programming languages based on the "C" paradigm are currently used to produce software tools and utilities such as word processors, spreadsheets, and operating systems. Software developers can assign a large number of programmers to a long-term project, with the knowledge that repeated sales of the product to existing users will recover the large investment expenditure. However, developers of Internet content cannot afford this type of approach and have fallen back upon the very simple HTML protocol to economize development.
However, even HTML is inadequate to enable or facilitate the conducting of interactive programming on the Internet. Although well adapted to passively providing multimedia information, HTML is extremely limited in active and interactive software use and development. Thus, companies seeking to conduct commercial activities on the Internet are seeking a programming tool or information-exchange methodology to replace HTML or to provide major enhancement to that language. In contrast to applications programs based on the "C" paradigm, Internet applications programming is generally not subject to multiple uses. Rather an Internet program is consumed: the program is used only once by the typical user. Utilities-type software developed for individual computer use, such as word processors, spread sheets, E-mail, etc., can be sold at higher prices because the software is used again and again by any individual.
Programming languages based on the "C" programming paradigm are awkward for programming interactions involving the computer's display screen. For example, a Microsoft program for the manipulation of sprites (graphic images that can move over a background and other graphic objects in a nondestructive manner) requires over 800 lines of "C" code and over 290 lines of assembler code. The same program written in the TenCORE language requires only six lines.
TenCORE is a modular programming language designed in the early 1980's to facilitate the transfer of information between disk drives and RAM, particularly for the delivery of interactive instruction ("Computer-Based Training"). At that time, disk drives were all slow and RAM was inevitably small. In adapting to these hardware limitations, TenCORE introduced the use of small individual code modules for performing respective functions, thereby enabling efficient performance as each code module loaded a single interaction from the slow disk drives. Programming in the form of substantially independent code modules is open-ended, a necessary characteristic for educational software requiring the delivery of whatever remedial instruction is required by the individual student TenCORE utilizes a program called an "interpreter" that implements all basic required functions efficiently. The interpreter has no content itself. The content comes from an unlimited number of small pseudocode modules which are loaded into the system memory and issue commands to the interpreter. In writing a program, the programmer's involvement is reduced to simply issuing commands, leaving all the difficulties of implementation to the interpreter.
In contrast to TenCORE, "C" type programming includes a series of pre-written code libraries which are linked together as they are compiled. In theory, when a new microprocessor is designed, only the code libraries need to be rewritten and then all programs can be re-compiled using the new libraries. However, over the past twenty years the number of these code libraries has grown to a point where the original concept of rewriting for different microprocessors is no longer practical because of the difficulty in compensating for subtle differences between microprocessors. What remains is a complex and difficult programming syntax that takes years to master and is very difficult to debug.
OBJECTS OF THE INVENTION
A general object of the present invention is to provide a method for communicating over a computer network.
A more particular object of the present invention is provide a method for enabling or facilitating the conducting of interactive programming over a computer network such as the Internet.
A related object of the present invention is to provide a method for communicating software over a computer network, to enable an increased degree of interactive computer use via the network.
Another object of the present invention is to provide a computing system for enabling or facilitating the conducting of interactive programming over a computer network such as the Internet.
It is a further object of the present invention to provide a computing system for communicating software over a computer network, to enable an increased degree of interactive computer use via the network.
These and other objects of the present invention will be apparent from the drawings and descriptions herein.
SUMMARY OF THE INVENTION
The present invention is directed to a computerized system and to an associated method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage. In accordance with the method, an applications program is stored in a nonvolatile memory of a first computer as a plurality of individual and independent machine-executable code modules. In response to a request from a second computer transmitted over a network link, the first computer retrieves a selected one of the machine-executable code modules and only that selected code module from the memory and transmits the selected code module over the network link to the second computer.
In one important field of use of the invention, the first computer is a server computer on a network. The second computer may be a user computer or a secondary server. Alternatively, the two computers may be two individual user computers on the network.
Where the second computer is a user computer, the request for the executable code module arises because the user needs the code module to perform a desired function in the applications program. The user's computer does not have all of the code modules of the applications program and obtains new code modules only as those modules are needed. Because executable code of the applications program is broken down into individually executable modules, the program can be downloaded piecemeal, module by module, as the individual modules are needed by the user's execution of the program. Accordingly, the user need not wait for the entire program to be downloaded before the user can start using the program.
Where the first computer and the second computer are a primary server and a secondary server, respectively, the present invention allows the primary server, when is too busy to handle a user request or task, to hand that request or task off to the secondary server. When a primary server receives a user request or task that the server cannot handle due to load, that request or task is forwarded preferably to the least busy secondary server available. The secondary server then processes the user request and responds to the client/user directly. If the secondary server does not have a code module, data file, or other resource required to handle the user request, the required code module, data file, or other resource can be transferred to the secondary server from the first server. This shunting of user requests contemplates the utilization of multiple secondary servers located on different Internet connections. The present invention thus eliminates most bandwidth and server load issues on the Internet and other computer networks.
Of course, a server computer must shed its load before the server reaches its full capacity, thereby leaving enough system resources (processor, memory, etc.) free to fulfill any requests from a secondary server for resources necessary for the secondary server to fulfill a shunted user request or task.
If a secondary server is unable to contact the client machine, the secondary server can forward the user request to another secondary server for processing, since the other secondary server may be able to reach the client machine directly.
A secondary server may also serve as a backup server. In that case, the secondary server immediately requests all code modules, data files, and other resources from the primary server instead of waiting for a client request that requires one of those resources. When a client or secondary server makes a request of the primary server and discovers it to be inaccessible, the request can then be made of a backup server. In this way, if a primary server were to fail, the information that was on the primary server would still be accessible through the backup server. To facilitate the maintenance of up-to-date resources on backup servers, the primary server sends notification packets to each of the backup servers whenever a resource is created or updated. The backup servers can then request the new, updated copy of the resource from the primary server, thereby remaining up to date with the primary server at all times.
In order to optimize processing of user requests, a primary server stores in its memory a list of secondary servers on the network, the list including response times and load statistics (processor usage, etc.) for the respective secondary servers. The primary server periodically updates these response times, by sending echo packets to the secondary servers and measuring delays between the sending of the echo packets and a receiving of responses to the echo packets from the respective secondary servers. The server also periodically updates the load statistics by requesting the current load statistics from the secondary servers. For processing a recently received user request, the primary server scans the list in memory and selects the secondary saver having the lightest load and shortest response time.
For security purposes, code modules, as well as other resources such as data files, are transmitted in encrypted form. Encryption is accomplished by placing the code modules, files, documents or other transmittable resources in the data area of an encryption packet. When an encrypted packet is received, it is decrypted and the code modules, files, documents or other transmittable resources subsequently handled pursuant to normal procedures. The encryption/decryption process can be handled by a plug-in code module. Any number of plug-in encryption code modules may exist in a data and code transfer system in accordance with the invention at any one time. The header of an encryption packet contains an indication of which plug-in encryption code module must be used for decryption purposes. Encryption/decryption code modules can be delivered real time by a code module exchange protocol.
To further enhance the security of the system, the primary server stores a list of user authentification codes in its memory. Upon receiving a request, e.g., for a machine executable code module, from another computer, the primary server compares a user authentification code in the request with the stored list of user authentification codes. The primary server proceeds with retrieving and transmitting a selected machine-executable code module only if the user authentification code in the request matches a user authentification code in the stored list. Where an incoming request for a machine-executable code module is contained in an encryption packet, the server decrypts the encryption packet prior to the comparing of the user authentification code in the request with the list of user authentification codes in the memory. Encrypting and decrypting of encryption packets, as well as the checking of user authentification codes, may be performed by the secondary server(s). Whatever programming or data required for carrying out these security measures can be transmitted from the primary server in accordance with the present invention.
The present invention provides for the updating of an applications program in users' machines. When a user sends a request for a code module to a server, the request includes a specification of the version of the program code sought. The server processing the request checks whether the requested version is the latest version available. When a newer version of a requested code module is available, the server informs the user and inquires whether the user could use the newer version of the requested module. The user could then send a request for the updated version of the desired code module.
If the updated version of the desired code module is incompatible with older versions of other code modules, the older version of the desired code module will be transmitted from the server to the user. If the older version is not available, the user may have to request transmission of the newer versions of several additional modules.
Generally, it is contemplated that machine-executable code modules are written in a user-friendly programming code such as TenCORE. In that case, a software-implemented interpreter unit of the user computer translates the code modules from the programming code into machine code directly utilizable by the user computer. When such an interpreter is used, the interpreter itself can be updated in the same fashion as an application program or code module. For purposes of updating the interpreter, the interpreter is treated as a single large code module.
In a related method in accordance with the present invention for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage, a portion of an applications program is stored in a first computer. The applications program comprises a plurality of individual and independent machine-executable code modules. Only some of the machine-executable code modules are stored in the first computer. This method includes executing at least one of the machine-executable code modules on the first computer, transmitting, to a second computer via a network link, a request for a further machine-executable code module of the applications program, receiving the further machine-executable code module at the first computer from the second computer over the network link, and executing the further machine-executable code module on the first computer.
To further facilitate program transfer on the network, the first computer may conduct an investigation into server availability. Pursuant to this feature of the invention, a request is sent from the first computer (e.g., a user) to a further computer (e.g., a primary server) for a list of servers (e.g., secondaries) on said network. After transmission of the list of server to the first computer, response times for the server are determined by (a) sending echo packets from the first computer to the servas, (b) measuring, at the first computer, delays between the sending and receiving of the echopackets, (c) querying the servers as to current server load (processor usage, etc.) The request for a further machine-executable code module is sent to the server having the lightest load and shortest measured response time. The list of servers can be cached in memory by the first computer to facilitate further access to the information in the event that the server from which the list was requested becomes unavailable or is too busy to handle the request.
In the event that there has been an update in a requested code module, a request from the first computer for a particular version of the code module may trigger an inquiry as to whether the first computer could use the updated version of the code module. If so, the first computer transmits a second requests, this time for the updated version of the desired code module.
Where the two computers are both user machines, the method of the present invention facilitates interactive processing. Each computer executes one or more selected code modules in response to the execution of code modules by the other computer. Thus, both computers store at least some of the machine-executable code modules of the applications program. Occasionally one computer will require a code module which it does not have in present memory. Then the one computer can obtain the required code module from the other computer. If the other computer does not have the required module, a request may be made to a server on which the applications program exists in its entirety.
Where the machine-executable code modules are written in a user-friendly programming code, each user computer includes an interpreter module implemented as software-modified generic digital processing circuits which translates the code modules from the programming code into machine code utilizable by the respective computer.
In accordance with a feature of the present invention, the machine-executable code modules each incorporate an author identification. The method then further comprises determining, in response to an instruction received by a user computer over the network and prior to executing the one of the machine-executable code modules on the user computer, whether the particular author identification incorporated in the one of the machine-executable code modules is an allowed identification. The user computer proceeds with code module execution only if the particular author identification is an allowable identification. Generally, the instruction determining whether a code module is written by an allowed author is a list of blacklisted authors.
The author identification feature of the invention severs to prevent an author from creating a virus or other malicious program and distributing it using the code module exchange protocols of the present invention. All compilers supporting the coding of individual machine-executable code modules in accordance with the present invention will incorporate a respective author identification code into each machine-executable code module. The author identification is unique to each author. When a malicious program is discovered, the identification of the author may be distributed throughout the network to blacklist that author and prevent the execution of code modules containing the blacklisted author's identification. As an additional advantage, this feature will discourage users from distributing illegal copies of the authoring package, since the respective users will be held responsible for any malicious programs written under their author identification.
The storing of applications program modules in a user computer may include caching the code modules in a nonvolatile memory of the user computer.
It is to be noted that the present invention permits the transmission during user computer idle time of code modules whose use is anticipated. A request from the user computer is transmitted to a server or other computer for a machine-executable code module during an idle time on the user computer.
A computing system comprises, in accordance with the present invention, digital processing circuitry and a nonvolatile memory storing general operations programming and an applications program. The applications program includes a plurality of individual and independent machine-executable code modules. The memory is connected to the processing circuitry to enable access to the memory by the processing circuitry. A communications link is provided for communicating data and programs over a network to a remote computer. A code module exchange means is operatively connected to the memory and to the communications link for retrieving a single code module from among the machine-executable code modules and transferring the single code module to the remote computer in response to a request for the single code module from the remote computer.
As discussed above, the computing system of the present invention may be a server computer on the network. The server's memory may contain a list of secondary servers on the network, the list including response times for the respective secondary servers, The computing system then further comprises a detection circuit, generally implemented as software-modified generic digital processing circuitry, for detecting an overload condition of the computing system. A server selector also generally implemented as software-modified generic digital processing circuitry, is operatively connected to the detection circuit, the memory and the communications link for determining which of the secondary servers has a shortest response time and for shunting an incoming user request to the secondary server with the shortest response time when the overload condition exists at a time of arrival of the user request.
Thus, the remote computer transmitting a code-module request to the computing system may be a secondary server to which a user request has been shunted. The requested single code module is required for enabling the remote computer to process the user request. On behalf of the computing system.
Pursuant to another feature of the present invention, the computing system further comprises an updating unit, preferably implemented as software-modified generic digital processing circuitry, operatively connected to the memory and the communications link for (1) periodically sending echo packets to the secondary servers, (2) measuring delays between the sending of the echo packets and a receiving of responses to the echo packets from the respective secondary servers, and (3) updating the response times in the list in accordance with the measured delays.
For security purposes, the memory of the computing system may contain a stored list of user authentification codes. The computing system then includes a comparison unit, preferably implemented as software-modified generic digital processing circuitry, for comparing a user authentification code in an incoming request with the list of user authentification codes in the memory and for preventing code-module retrieval and transmission in the event that the user authentification code in the request fails to correspond to any user authentification code in the list.
Where incoming requests for code modules are contained in encryption packets, the computing system further comprises a software-implemented decryption circuit connected to the communications link and the comparison unit for decrypting the encryption packet prior to the comparing of the user authentification code in the request with the list of user authentification codes in the memory.
In accordance with another feature of the invention, the computing system includes means for determining whether a requested code module has an updated version and for responding to the request with an invitation to the remote computer to accept the updated version of the requested code module.
It is contemplated that the machine-executable code modules are written in a user-friendly programming code. Where the computing system uses the applications code itself, the computing system further comprises an interpreter for translating the programming code into machine code directly utilizable by the processing circuitry. The interpreter may take the form of generic digital processing circuit modified by programming to perform the translation function.
A computing system (e.g., a user computer on a network) also in accordance with the present invention comprises a memory storing a portion of an applications program having a plurality of individual and independent machine-executable code modules, only some of the machine-executable code modules being stored in the memory. A digital processing circuit is operatively connected to the memory for executing at least one of the machine-executable code modules. A communications link is provided for communicating data and programs over a network to a remote computer. A code module exchange unit is operatively connected to the memory and to the communications link for communicating with a remote computer (e.g., a server on the network) via a network link to obtain from the remote computer a further machine-executable code module of the applications program. The digital processing circuitry is operatively tied to the code module exchange unit for executing the further machine-executable code module upon reception thereof from the remote computer.
When a client or user machine is not running at full capacity (processor idle time is over a given threshold and network traffic is under a given threshold), that machine can look for other client machines on the same virtual network that may be in the midst of a processor-intensive task and take on some of the load. If necessary, the code modules to handle that task can be transferred to the idle client machine. It is possible for clients working together on the same project to communicate with each other using a custom sub-protocol. This client-side distributed processing significantly improves the performance of processor-intensive tasks.
The present invention provides a programming paradigm which addresses the Internet content developer's specific needs. A software system and computer communications method in accordance with the present invention delivers rapidly over the Internet, provides a practical programming paradigm that supports rapid economical development of content, and facilitates new capabilities in Internet software and systems management.
TenCORE, a modular programming language designed to use small efficient code modules for facilitating program transfer between disk drives and central processing units of desktop computers, may be easily modified to carry out the present invention. Minimal modifications require the adapting of the transfer capabilities to work over network links.
The present invention arises in part from the realization by the inventors that the problems facing the developers of TenCORE in 1980 are the same problems that software designers face today when dealing with the Internet and its limited bandwidth and slow connections. It was perceived that Internet applications must be open-ended and programming must be delivered rapidly in spite of bandwidth limitations. Thus, the solution provided by TenCORE is useful in solving today's problems with interactive software on the Internet. The modular programming of TenCORE enables rapid Internet performance because a single TenCORE Net programming module can be quickly downloaded over the Internet The TenCORE Net programming modules are TenCORE programming modules which are modified to enable downloading from Internet servers instead of from a microcomputer's disk drive.
TenCORE and TenCORE Net are interpreted languages, i.e., they serve to translate into machine language pseudocode programs and to perform the indicated operations as they are translated. "Pseudocode" is unrelated to the hardware of a particular computer and requires conversion to the code used by the computer before the program can be used. Once the TenCORE Net interpreter is installed on a computer equipped with an Internet connection, clicking with a mouse on a conventional World-Wide Web hyperlink that points to a TenCORE Net application automatically bypasses the Internet browsing software and launches the application. Because only the required modules are sent over the Internet and because the TenCORE Net modules are very small, Internet performance is very fast.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 is a block diagram of a computer network with various servers and user computers, which transmit executable programs to one another pursuant to the present invention.
FIG. 2 is a block diagram of a primary server in accordance with the present invention.
FIG. 3 is a block diagram of a user computer in accordance with the present invention.
FIGS. 4A and 4B (hereinafter "FIG. 4") are a flow chart diagram illustrating a maintenance loop in the operation of selected program-modified processing circuits in the primary server of FIG. 2 and the user computer of FIG. 3.
FIG. 5 is a flow chart diagram illustrating a loop for processing an incoming data packet in the operation of selected program-modified processing circuits in the primary server of FIG. 2 and the user computer of FIG. 3.
FIGS. 6A through 6E are a flow chart diagram illustrating further operations relating to the processing of an incoming request for a code module in accordance with the present invention.
FIGS. 7A through 7E (hereinafter FIG. "7") are flow chart diagram illustrating a subroutine for processing an incoming resource request packet in the operation of selected program-modified processing circuits in the primary server of FIG. 2.
FIGS. 8A through 8E (hereinafter "FIG. 8") are a flow chart diagram illustrating a maintenance loop in the operation of selected program-modified processing circuits in the primary server or a secondary server of FIG. 2.
FIGS. 9A through 9D (hereinafter "FIG. 9")are a flow chart diagram illustrating a subroutine for processing an incoming resource request packet in the operation of selected program-modified processing circuits in the primary server of FIG. 2.
FIGS. 10A through 10F (hereinafter "FIG. 10") are a flow chart diagram illustrating a maintenance loop in the operation of selected program-modified processing circuits in the primary server or a secondary server of FIG. 2.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
As illustrated in FIG. 1, a computer network comprises a plurality of user computers 12 operatively connected to a primary server computer 14 via a complex of network links 16. The primary server 14 stores, in an area 18 of a nonvolatile memory 20 (FIG. 2), an applications program which may be desired for use on one or more user computers 12. The term "applications program" as used herein refers to any executable collection of computer code other than operating systems and other underlying programming for controlling basic machine functions.
As further illustrated in FIG. 1, the network includes a plurality of secondary servers 22 which are available for assisting primary server 14 in responding to requests from user computers 12. More particularly as shown in FIG. 2. primary computer 14 includes an overload detector 24 which continually monitors a queue of jobs or tasks which primary server 14 has to perform. Overload detector 24 determines whether the number and size of tasks in the queue has exceeded a predefined threshold. Once that threshold is reached, overload detector 24 signals a secondary server selector 26 which accesses an area 28 of memory 20 to identify a secondary server 22 which is least busy. To that end, memory area 28 contains a list of secondary servers 22 as well as measured response times for the respective servers.
The response times in the secondary-server list in memory area 28 are periodically measured by dispatching echo packets to each secondary server 22 and measuring the delays between the transmission of the respective echo packets from primary server 14 and the receipt of responses from the respective secondary servers 22. To accomplish the measurement, primary server 14 and, more particularly, a processing unit 30 thereof contain an echo packet dispatcher 32 and a response-time monitor 34. Upon transmitting an echo packet to a secondary server 22 via a network communications interface 36 at primary server 14, dispatcher 32 notifies response-time monitor 34 as to the transmission of a packet and as to the secondary server 22 to which the transmission was made. Monitor 34 counts out the time between the transmission of the echo packet and the arrival of a response from the respective secondary server 22 via network links 16 and communications interface 36. A response-time update unit 38 is connected to response-time monitor 34 and to memory area 28 for writing updated response times in the secondary server list stored in memory area 28.
The applications programs store 18 in memory 20 contains a multiplicity of interacting individual and independent machine-executable code modules. Accordingly, a user computer 12 working with the applications program need not be loaded with the entire program in order to begin processing operations. In the event that the user's execution of the applications program requires a code module not contained in the user's computer memory, a request is transmitted from the user computer 23 over network links 16 to primary server 14. If primary server 14 is not overloaded, it retrieves the requested code module from program store 18 and transmits it over communications interface 36 and network links 16 to the user computer which made the request.
Processing unit 30 of primary server 14 includes a code-module exchanger 40 which processes incoming requests for code modules of the applications program or programs stored in memory area 18. Exchanger 40 cooperates with a version detector 42 which consults the applications program store 18 to determine whether a requested version of a particular code module is the latest version in store 18. If not, version detector 42 and code module exchanger 40 transmit an inquiry to the resting computer as to whether the latest version of the desired code module is utilizable by the requester. If the newer version of the desired code module can be used in place of the older version, the newer version is transmitted over communications interface 36 and network links 16.
Code modules, as well as other resources such as data files, may be transmitted in encrypted form for security purposes. Encryption is accomplished by placing the code modules, files, documents or other transmittable resources in the data area of an encryption packet. When an encrypted packet is received by processing unit 30 via communications interface 36, the packet is forwarded via generic processing circuits 50 to an encryption/decryption unit 44 for deciphering Encryption/decryption unit 44 consults a memory area 46 containing a plurality of possible encryption keys and selects an encryption key identified by header information in the encryption packet containing the user request. Upon decryption of the incoming encryption packet, the user request or code module exchange packet contained therein is forwarded to code-module exchanger 40 for processing. The encryption/decryption process can be handled by a plug-in code module performing the functions of encryption/decryption unit 44 and memory area 46. Any number of plug-in encryption code modules may exist in a data and code transfer system at any one time. The header of an encryption packet contains an indication of which plug-in encryption code module must be used for decryption purposes.
To further enhance the security of a computer network which has protocols for the exchange of executable code modules, primary server 14 stores a list of user authentification codes in a memory area 48. In response to a request, e.g., for a machine-executable code module, from another computer, comparator 52 in processing unit 30 compares a user authentification code in the request with the list of user authentification codes stored in memory area 48. Code module exchanger 40 proceeds with retrieving and transmitting a selected machine-executable code module only if the user authentification code in the request matches a user authentification code in the stored list. Where an incoming request for a machine-executable code module is contained in an encryption packet, encryption/decryption unit 44 deciphers the encryption packet prior to the comparing by comparator 52 of the user authentification code in the request with the list of user authentification codes in memory area 48. Where a user request is relayed to a secondary server 22 chosen by selector 26, the secondary server incorporates an encryption/decryption unit and an authentification-code comparator for encrypting and decrypting of encryption packets and the checking of user authentification codes, may be performed by the secondary server(s). Whatever programming or data required for carrying out these security measures can be transmitted from primary server 14 to the selected secondary server 22.
As illustrated in FIG. 3, a processing unit 54 of a user computer 12 includes a code-module exchanger 56 which generates requests for desired code modules of an applications program as those code modules are required during execution of the applications program by the user. The code-module requests are transmitted to code-module exchanger 40 of primary server 14 via a network communications interface 58 at user computer 12, network links 16 (FIG. 1) and communications interface 36 at primary server 14.
In a security enhanced system, processing unit 54 of user computer 12 includes a encryption/decryption unit 60 which inserts code-module request packets, as well as other information transfer packets, into the data areas of respective encryption packets whose encryption keys are selected from a plurality of keys stored in an area 62 of a nonvolatile memory 64 of user computer 12. Again, the encryption/decryption process at user computer 12 can be handled by a plug-in code module performing the functions of encryption/decryption unit 60 and memory area 62. The header of an encryption packet generated by encryption-decryption unit 60 contains an indication of which plug-in encryption code module at primary server 14 must be used for decryption purposes.
In a further security enhancement used to protect the computing system of FIG. 1 in general and user computer 12 in particular from computer viruses and other malicious programming, processing unit 54 is provided with an author identification comparator 66 which accesses an author identification list 68 in memory 64. Author identification list 68 is periodically updated by author identification comparator 66 and other function-converted blocks in generic processing circuits 70 in response to incoming instructions from primary server 14. Author identification list 68 contains a list of allowed authors or, perhaps more efficiently, a list of authors who have been blacklisted owing to their passing of viruses or other malicious programming onto the network. Prior to the use of an incoming machine-executable code module. The author identification in a packet header is checked by comparator 66 to determine that the author of the particular code module has not been blacklisted If the author is allowed to produce executable code modules for user computers 12, processing of the incoming code module proceeds normally. If, on the other hand, the author of the incoming code module has been blacklisted, then the code module is never executed and may be discarded prior to storage in an applications program store 72 in memory 64.
As discussed above with reference to FIGS. 1 and 2, primary server 14 may occasionally hand off an incoming user request to a secondary server 22, depending on the load condition of the primary server and the secondary servers. Generally, this handing off of responsibility for responding to users' requests is transparent to the users, i.e., the processing of users' requests proceeds without knowledge or intervention by the users. It is also possible for user computers 12 to take over selection of a secondary computer 22 from primary computer 14. To that end, processing unit 54 of user computer 12 is provided with a secondary server selector 74 which accesses a list 76 of secondary-servers in memory 64. Generally, selector 74 selects a secondary server 22 with a smallest response time relative to the respective user computer 12. To that end, processing unit 54 further includes an echo packet dispatcher 78, a response-time monitor 80 and a response-time update unit 82. Dispatcher 78 sends echo packets to secondary servers 22 via communications interface 58 and network links 16 (FIG. 1), while monitor 80 determines the delays of responses from the various secondary servers. Update unit 82 corrects response time data in list 76 in accordance with measurements carried out by dispatcher 78 and monitor 80. It is contemplated that the updating of secondary-server response times in list 76 is implemented only when user computer 12 requires a user module or other resource from primary server 14 and that server is too busy to handle the user request.
Processing unit 54 of a user computer 12 has a distributed processing circuit 84 which enables processing unit 54 to share the processing of large tasks with other user computers in the network. Thus, when a user computer is not running at full capacity (processing unit 54 is more than 50% idle and there is no network traffic), that distributed processing circuit 84 looks for other user computers 12 that may be in the midst of a processor-intensive task and enable transfer of some of the load to the processing unit 54 of the respective user computer 12. If necessary, the code modules to handle that task can be transferred to the idle user computer 12. This client-side distributed processing significantly improves the performance of processor-intensive tasks.
Processing unit 54 of a user computer 12 also contains a metered delivery and billing circuit 86 which controls access to content which must be paid for. Credit registers 88 in memory 64, accessible by circuit 86, store credits which the particular user has against respective accounts. When credit in an account maintained or monitored by primary server 14 is low, circuit 86 may arrange for the transfer of more credit from primary server 14 to the particular user. Metered delivery and billing circuit 86 includes a billing method to pay for the credit. Generally, credit requests and responses thereto should be encrypted.
Processing unit 54 of a user computer 12 additionally includes a unidirectional data submission and collection circuit 90 which accesses data files 92 in memory 64 for purposes of uploading those data files to primary server 14 or to a selected secondary server 22. Data submission and collection circuit 90 is operative when the user computer does not need to read the data back from the server. This circuit is particularly useful for on-line orders, form submission, and data collection (including statistical data) among other things.
Generally, packets that contain data to be written must be sent directly to the primary server 14 and cannot be shunted. This prevents conflicts between different versions of the resource that was written to. Data written back to the server should require user authentification. User authentification should be used even if the write-back will be done only by a program under author control. In that case, user identification codes and passwords can be built into the program. The reason for this is to prevent another author from writing a program that would write back to the same data and possibly corrupt it.
Applications program code modules stored in memory area 18 (FIG. 2) and module store 72 (FIG. 3) are written in TenCORE, a modular programming language originally designed to use small efficient code modules for facilitating program transfer between disk drives and central processing units of desktop computers. TenCORE is easily modified, for example, to adapt the code transfer capabilities to operate over network links. The program so modified for use on user computers 12, primary server 14 and secondary servers 22 may be called "TenCORE Net."
TenCORE Net uses small individual code modules for performing respective functions, thereby enabling efficient performance as each code module is downloaded a single interaction from primary server 14 or a selected secondary server 22. Programming in TenCORE Net is open-ended, so that a user computer 12 executes instructions of an applications program when that applications program is only partially stored in program store 72 of memory 64.
The code modules held in memory store 72 are in a user-friendly pseudocode language which must be translated or interpreted for direct machine use. To that end, processing unit 54 includes a program or programmed interpreter circuit 94 that implements all basic required functions efficiently. The interpreter has no content itself Content is derived from a potentially unlimited number of small pseudocode modules which are loaded into memory store 72 and which effectively issue commands to interpreter 94. In writing a program, the programmer's or author's involvement is reduced to simply issuing commands, leaving all the difficulties of implementation to the interpreter.
TenCORE may be modified in two ways to enable network use. First, a subroutine or set of instructions may be inserted before each call line of computer code for checking whether the code intended for execution exists in applications program memory area 72. If not, code module exchanger 56 is instructed to obtain the required code module from primary server 14. Once the required code module has been downloaded into memory area 72, it is called and translated by interpreter circuit 94 prior to execution by processing circuits 70.
Through the use of modular applications programs and code- module exchangers 40 and 56, the control of computer program storage and transfer between computers 12, 14, 22 on a network is optimized, thereby facilitating interactive program usage. An applications program stored in nonvolatile memory area 18 of primary server 14 may be transferred to various user computers 12 in modular fashion. In response to a request transmitted over network links 16 from a user computer 12 or a selected secondary server 22, primary server 14 retrieves a selected machine-executable code module and only that selected code module from memory area 18 and transmits the selected code module over network links 16 to the user computer or secondary server.
Where the applications program is, for instance, a drawing or painting program, a user computer 12 may be instructed to draw a three-dimensional geometric figure such as a truncated pyramid. If processing circuits 70 discover that the applications program in program store 72 is missing a code module required for performing that task, code module exchanger 56 requests that the requisite module be transferred from primary server 14. In response to that request, version detector 42 may find that a later version of the desired module exists and inquire of code-module exchanger 56 whether the later version would be acceptable for use by the respective user computer.
Thus, user computers 12 do not have all of the code modules of the applications program and obtain new code modules only as those modules are needed. Because executable code of the applications program is broken down into individually executable modules, the program can be downloaded piecemeal, module by module, as the individual modules are needed by the user's execution of the program. Accordingly, the user need not wait for the entire program to be downloaded before the user can start using the program.
Similarly, a selected secondary server 22 can begin to process a transferred or shunted user request and respond to the client/user directly, without having the entire applications program and other resources relating to the handling of the program's distribution by the primary server 14. If the selected secondary server does not have a code module, data file, or other resource required to handle the user request, the required code module, data file, or other resource can be transferred to the secondary server from the primary server. Secondary servers 22 are thus provided with code module exchangers similar to exchangers 40 and 56.
Of course, primary server 14 must shed its load before that server reaches its full capacity, thereby leaving enough system resources (processor, memory, etc.) free to fulfill any requests from a secondary server for resources necessary for the secondary server to fulfill a shunted user request or task.
In security sensitive networks, secondary servers 22 are equipped with encryption/decryption units like unit 44, as well as authentification comparators 52. Where an incoming request for a machine-executable code module is contained in an encryption packet, the secondary server decrypts the encryption packet prior to the comparing of the user authentification code in the request with a list of user authentification codes in memory. Whatever programming or data required for carrying out these security measures can be transmitted from primary server 14.
If a secondary server is unable to contact the client machine, the secondary server can forward the user request to another secondary server for processing, since the other secondary server may be able to reach the client machine directly.
Code module exchanger 56 of processing unit 54 facilitates interactive processing on a network. Each user computer 12 executes one or more selected code modules in response to the execution of code modules by the other computer. Thus, both computers store at least some of the machine-executable code modules of the applications program. Occasionally, one computer will require a code module which it does not have in present memory. Then the one computer can obtain the required code module from the other computer. If the other computer does not have the required module, a request may be made to a server on which the applications program exists in its entirety.
Thus, clients or users on a network are able to exchange code modules with one another. If a first user and a second user are engaged in an interactive whiteboarding session and the first user starts drawing with a tool that the second user does not have in her version of the whiteboarding program, the code module or modules for that tool can be transferred automatically from the first user's computer to the second user's computer.
It is to be noted that code module exchanger 56 may be instructed to initiate the transmission during user computer idle time of code modules whose use is anticipated. A request from the user computer 12 is transmitted to primary server 14 or other computer for a machine-executable code module during an idle time on the user computer. Resource requests that are generated for idle-time downloading should be flagged as such, so that code module exchanger 56 can assign different priorities from standard requests for load balancing and distribution purposes. The status of a resource request can be upgraded to real time from idle time in the event that the user attempts to access the associated section of the application.
It is to be noted that the various dedicated function blocks of processing units 30 and 54 are generally and preferably implemented as software-modified generic digital processing circuits. Accordingly, code- module exchanger 40 and 56 are characterizable as protocols for the exchange of code modules between a server 14 or 22 and a user computer 12. This code module exchange protocol is considered a subprotocol of a Modularized Code Master Protocol ("MCMP") which handles load distribution, user authentification and encryption. Load distribution is more particularly handled in primary server 14 by processor overload detector 24 and secondary-server selector 26, while user authentification and encryption are handled in primary server and secondary servers 22 by comparator 52 and encryption/decryption unit 44.
The MCMP has four subprotocols, namely, the Code Module Exchange Protocol ("CMXP"), the Uni-Directional Data Submission and Collection Protocol ("UDSCP"), the Metered Delivery and Billing Protocol ("MDBP"), and the Distributed Processing Protocol (DPP"). The Code Module Exchange Protocol is realized by code-module exchanger 40 in processing unit 30 of primary server 14 and secondary servers 22 and by code-module exchanger 56 in processing unit 54 of user computers 12. The Uni-Directional Data Submission and Collection Protocol is implemented by circuit 90 in user computers 12 and by corresponding non-illustrated program-modified processing circuitry in primary server 14. The Metered Delivery and Billing Protocol finds realization by circuit 86 in user computers 12 and by corresponding non-illustrated program-modified processing circuitry in primary server 14. The Distributed Processing Protocol takes the form of circuit 84 in processing unit 54 of user computers 12.
FIG. 4 illustrates operations undertaken by echo dispatcher 32, response-time monitor 34, and update unit 38 as well as other processing circuits of processing unit 30 of primary server 14 to maintain an updated list 28 of the availability of secondary servers 22. The same steps may be performed by echo dispatcher 78, response-time monitor 80, and update unit 82 as well as other processing circuits of processing unit 54 of user computer 12 to obtain an updated list of secondary server response times. In an inquiry 100, echo dispatcher 32 or 78 or generic processing circuits 50 or 70 query whether the time since the last echo testing is greater than a predetermined maximum period TMR. If the maximum period has been exceeded, echo packet dispatcher 32 or 78 transmits, in a step 102, an echo packet to the secondary server 22 which was tested the least recently. Response-time monitor 34 or 80 determines in an inquiry 104 whether a response has been received from the targeted secondary server 22. If a response has not been received and if a prespecified number of measurement attempts has not been exceeded, as determined at a decision junction 106, another echo packet is dispatched in step 102. If a response is received from the targeted secondary server 22, update unit 38 or 82 then records, in list 28 or 76, the time between the initial packet transmission by dispatcher 32 or 78 and the receipt of the echo packet by monitor 34 or 80. This recordation is effected in a step 108. If the number of attempts at secondary-server response-time measurement has exceeded the pre-specified number, as determined at decision junction 106, the server is marked in list 28 or 76 as being unavailable (step 110). Also a message or alert signal may be generated to inform a server overseer. If at query 100, it is determined that the time since the last echo testing is less than predetermined maximum period TMR, processing unit 30 or 54 investigates at 112 whether there is a packet in a MCMP incoming packet queue. If not, the maintenance loop of FIG. 4 is re-entered. If so, a packet processing operation 114 is executed. It should be noted that the MCMP incoming packet queue contains both packets received from the network, and packets placed into the queue by the MCMP protocol.
FIGS. 6A through 6E illustrate operation 114 carried out under the MCMP protocol by processing unit 30 of primary server 14 or of a secondary server 22 selected for overflow handing. In an initial inquiry 124, overload detector 24 decides whether processing unit 30 is too busy to handle the incoming packet (which may be, for example, a user request for a code module). If so, processing circuits 50 investigate the MCMP packet header at a junction 126 to determine whether the packet can be shunted to a secondary server 22. If so, a further investigation 128 is conducted to determine whether the incoming packet has already been shunted. If the packet was sent to the server directly by the originating computer (i.e., not shunted), secondary-server selector 26 accesses list 28 in a step 130 to find the secondary server 22 with the lightest load. At a subsequent inquiry 132, processing unit 30, and more particularly, server selector 26, determines whether the selected secondary server is suitable for transfer of responsibility for the incoming packet. If the selected secondary server is suitable, the packet is flagged as the result of a service hand-off and forwarded to the selected secondary server (step 134).
If the secondary server selected in step 130 is not suitable for a hand-off, for example, if the response time of the secondary server is greater than a predetermined maximum, as determined at inquiry 132, a query 136 is made as to whether an incoming packet is the result of a service hand-off This inquiry 136 is also made if the packet cannot be shunted, as determined at decision junction 126.
If an incoming MCMP packet is the result of a service hand-off, as determined at query 136, processing circuits 50 undertake an investigation 138 as to whether the requested resource is available. If the resource is available, processing circuits 50 ask at 140 whether the resource has passed a pre-assigned expiration date. If so, a signal is transmitted in a step 142 to the source of resource to determine if a newer version of the resource is available. If a new version is available, as ascertained at a decision junction 144 a request for the newer version of the resource is transmitted to the source in a step 146. This request is flagged as non-shuntable and should be additionally flagged as a priority request.
Prior to the processing of an incoming packet, e.g., a user request for a code module, processing unit 30 examines the header information in the incoming packet at an inquiry 150 to determine whether the packet contains user authentification information. Where user authentification information is found, the former encryption status of the packet is determined at 152. If the packet was not encrypted, a message is generated in a step 154 to report that the user authentification failed. If the incoming packet was encrypted, the MCMP header information is checked at 156 to determine if the source server is specified. If there is no source server specification, user authentification failure is reported in step 154. If there is a source server specified in the MCMP header information and if that source server is not the host server, as determined at a decision junction 158, an investigation 160 is conducted (by authentification code comparator 52) as to whether memory area 48 has a non-expired, cached copy of the user authentification data. If there is no non-expired, cached copy of the user authentification data in memory area 48, comparator 52 induces processing circuits 50 to obtain the user's authentification data from the source server and to store that data in memory area 48 (step 162). If a user's password contained in the MCMP packet header information does not match the cached password, as determined by comparator 52 in an evaluation 164 or if the user is not listed with the source server, as discovered by processing circuits 50 at a check point 166, the user authentification is reported as failed in a step 168. A report as to user authentification failure (step 154) is also made if the source server is the host server (decision junction 158) and if comparator 52 finds in an investigation 170 that the user authentification data in the packet header does not correspond to any user authentification data in memory area 48.
Once comparator 52 finds a match between the authentification code in an incoming packet and the user's authentification code in memory area 48, as determined in investigation 170 or in evaluation 164, or if the incoming packet did not contain a user authentification code, then evaluation 171 determines whether the packet should be handled directly by the MCMP protocol, or by another protocol. If evaluation 171 determines that the packet should be handled by the MCMP protocol directly, then the packet is processed accordingly at a step 173 as illustrated in FIG. 5. If evaluation 171 determines that the packet should be handled by a specific protocol, then processing circuits 50 determine in a step 172 which protocol (e.g., CMXD, UDSCP, MDBP, DPP) is appropriate for handling the content of the packet. If a response is produced by processing unit 30 under the selected protocol or by the main MCMP protocol, as determined in an inquiry 174, that response is tranenutted in a step 176 to the client that originally made the request. If there was a service handoff, that is, if the packet was shunted to the host server, then the response will be transmitted to a computer other than the computer from which the host received the packet. In a step 178, processing unit 30 begins processing the next packet in the queue or waits for a new packet to arrive.
As shown in FIG. 5, processing operation 173 includes an initial inquiry 116 into the type of packet. If the packet is an encryption packet, encryptionldecryption unit 38 or 60 is activated in a step 118 to decrypt the packet using the appropriate decryption module or key. In a subsequent step 120, the packet encased in the data area of the encrypted packet is flagged as non-shuntable and placed back into the MCMP incoming packet queue. If it is determined at inquiry 116 that the packet is not an encryption packet, an MCMP status report indicated an unknown packet type is issue in a step 122 and the packet is discarded. The functionality of the MCMP protocol may be enhanced at a later time by enhancing the process illustrated in FIG. 5 to include conditions for additional types of packets.
The Code Module Exchange Protocol (CMXP) handles dynamic downloading of executable code, program version control, client-to-client module exchange, virus and malicious program protection, data uploading, idle-time downloading, and code module caching. These functions are variously performed in servers 14 and 22 by code module exchanger 40 and version detector 42 and in user computer 12 by code module exchanger 56, author identification comparator 66, and unidirectional data submission and collection circuit 86, as well as by various nondesignated generic processing circuits 50 and 70. The server-side portion of the CMXP protocol, as implemented in part by code module exchanger 40, handles the delivery of code modules and supporting resources such as graphic images and fonts. Requests to the CMXP server and to code module exchanger 40 can reference a file, a portion of a file (such as a code module), or a portion of a code module or other supporting module. Because programs are broken down into separate code modules, these code modules can be delivered on an as-needed basis, eliminating the need to download an entire program before execution thereof can commence.
There are several ways of accommodating or incorporating an upgrade where programs are delivered piecemeal, module by module. If the old and new versions are completely compatible (for example, the new version was generated as the result a fix to a typographical error in a dialog box), the new modules can be merged with the old modules. Version information is stored on a per-file basis as well as a per-code-module basis. This means that code modules which were not changed in a version upgrade do not need to be downloaded again. If the old and the new versions are not compatible and cannot be merged, and the entire program has been cached locally or is still available from the server, the old version of the program can continue to execute until the next time the program is restarted. If the old and the new versions are not compatible and cannot be merged, and the old version of the program is no longer available in its entirety, the program should be immediately terminated and restarted using the new version code modules. The author of a program can override any of these update procedures by including a custom update module in the new version of the program,. This code module is downloaded (if necessary) and executed whenever a version conflict arises. Then, an election can be made to perform any of the above procedures or a custom procedure such as remapping the contents of the program's memory area so that they can be used by the new version.
Code modules and associated resources are cached by both user computers 12 and secondary servers 22. The caching rules can be incorporated into the CMXP protocol and/or the applications program itself This allows custom caching rules to be built into an application, thus providing for special caching schemes and hybrid applications. When a code module download is in progress, the number of bytes completed is stored in the cache along with the actual data downloaded. If a download is interrupted, it can resume where it left off at a later time.
FIG. 7 illustrates operations executed by digital processing circuits of processing unit 30 which are functionally modified in accordance with the CMXP protocol. The operations include a check on author identification. Generally, the author blacklist in memory area 68 of user computers 12 is transmitted to the user computers from a server which undertakes maintenance operations to keep the list updated (FIG. 8).
As illustrated in FIG. 7, processing circuits 50 inquire at 180 whether an incoming packet constitutes a request for a resource. An affirmative answer to this inquiry leads to a further inquiry 182, as to whether the requested resource is available for anonymous access. If the resource is restricted, a determination 184 is made as to whether the requesting user has rights to access the requested resource. If the user has no such rights, an "access denied" message is returned to the requester in a step 186. If the requested resource is available to the requesting party, processing circuits 50 determine at a decision junction 188 whether the requested resource contains executable code. An affirmative determination causes a query 190 as to the validity of the author's fingerprint. If the fingerprint or author identification is invalid, a message is generated for a responsible party in a step 192. The local copy of the resource is deleted in a subsequent step 194 and a message "Resource Distribution Prohibited" is transmitted to the requesting party in a step 196.
If in response to query 190 it is found that the fingerprint of the author of the requested resource is valid, then a check 198 is made as to whether the author is blacklisted. A blacklisting leads to deletion of the local copy of the resource in step 194 and the issuance of the message "Resource Distribution Prohibited" in step 196. If the author is not blacklisted, or if the requested resource does not contain executable code, as determined at decision junction 188, then the processing unit 30 queries at 200 whether the client already has an up-top-date copy of the resource. If the client or user already has the latest version of the resource, a message to that effect is transmitted in a step 202. If the client or user's copy of the resource is an older version, the requested resource is transmitted to the client in a step 204.
If an incoming packet does not constitute a request for a resource, as ascertained in response to at inquiry 180, an investigation 206 is made as to whether the packet constitutes a request to modify a resource. If so, and if the resource is not available for anonymous modification, as determined at a decision junction 208, then processing unit 30 queries at 210 whether the user has rights to modify the resource. If the user has no such rights, then a message "Access Denied" is returned to the requester in a step 212. If the resource is available for modification by anybody (decision junction 208) or by the particular user (query 210), the processing unit 30 makes the requested modification to the resource in a step 214 and notifies key secondary servers, in a step 216, of the change to the resource.
If an incoming packet does not constitute a request for a resource, as ascertained in response to inquiry 180, and is not a request to modify a resource, as determined in investigation 206, then the processing unit 30 checks at 218 whether the packet is an update to a prohibition list, for example, a list of prohibited users or blacklisted authors. If the packet is such an update and is encrypted, as determined at decision junction 220, then the processing unit 30 determines at an inquiry 222 whether the packet was sent under the system user account. If so, the cached copy of the prohibition list is updated in a step 224 and all secondary servers are notified of the update in a step 226. If an incoming update request is not encrypted (decision junction 220) or is not sent under the system user account (inquiry 222), then an alert message is issued to an appropriate party in a step 228. In a step 230, a special status report is issued if an unknown packet type is received.
In a CMXP maintenance loop, shown in FIG. 8, for updating a list of blacklisted authors, processing unit 30 asks in an initial query 232 asks whether the time since the last list update is more than a predetermined number of hours. If that much time has passed, an attempt 234 is made to contact the next server upstream of the server conducting the inquiry. If that server cannot be contacted, as determined in a scan 236, a check 238 is made as to whether there are other servers available. If another server is available, an attempt 240 is made to contact that server. If no server can be contacted, the time is again checked, at 242. If a predetermined interval has lapsed since the last update, then an alert is provided to an appropriate party in a step 244.
If a server can be contacted, as ascertained in scan 236, the date of the last modification of the prohibition list is obtained from that server in a step 246. In a comparison 248, the processing unit 30 then determines whether the prohibition list has been modified since the list was cached by the processing unit. Where such a modification has occurred, a copy of the prohibition list is obtained in a step 250. The encryption status of the obtained list is investigated at 252. If the copy of the prohibition list. Finding a nonencrypted copy of the prohibition list leads to an alert status in a step 254, while an encrypted packet is investigated at 256 to determine with the packet was sent under the system user account. A properly sent packet results in an update of the cached copy of the prohibition list in a step 258 and a notification of the update to all servers in a step 260.
There are two primary methods for submitting or collecting data via the Uni-Directional Data Submission and Collection Protocol ("UDSCP"). Pursuant to the first method, submissions can be directed to either a primary server 14 or a secondary server 22. All submissions are then collected at a central server, where the submissions are processed by an application-specific server-side module. This method would be particularly useful for collecting all form submissions on one server where they can be incorporated into a LAN-based mail system. In the second method, a submission can be again directed at either a primary server 14 or a secondary server 22. The submissions are collected on the servers to which they were originally submitted (or are shunted using the standard load collection rules). The submissions are then processed by an application-specific server-side module. This module could, for example, e-mail all of the submissions to an Internet e-mail address.
FIG. 9 illustrates program steps undertaken by digital processing circuits of processing unit 30 which are functionally modified in in accordance with the UDSCP protocol. These circuit handle data submissions transmitted from user computers 12, particularly from unidirectional data submission and collection circuit 90 of processing unit 54, and from other servers. In a first inquiry 262, the processing unit 30 inquires whether an incoming packet is a data submission. If so, another inquiry 264 is made as to whether the data has to be collected immediately. If immediate collection is called for, the next question 266 entertained by the processing unit 30 is whether the data has to be collected at the source server. If not, the packet is passed in a step 268 through to a module that handles the final data collection. This module handles e-mailing the submission, recording it in a database, writing it to a file, or preforming any other necessary server-side task with the data. Subsequently, in an investigation 270, it is checked whether the request has been processed by the data collection module. If so, the packet is removed in a step 272 from the UDSCP submission processing queue, assuming that is where the packet was obtained. Then a status report is issued at 274 indicating successful data packet transmission. If investigation 270 reveals that the request has not been processed by the data collection module, the processing unit 30 questions at 276 whether the failure to process was due to a possibly temporary condition. If the answer to this question 276 is negative, a status report 278 is issued describing the error condition. If the answer to the question 276 is affirmative, a status report 280 is issued describing the condition and indicating the possibility of delay in processing the data. The packet is then added in a step 282 to the UDSCP processing queue.
If an incoming packet is a data submission which does not have to be collected immediately, as determined at inquiries 262 and 264, a status report 284 is issued indicating success and the packet is then added in a step 286 to the UDSCP processing queue. If an incoming data packet is a data submission which has to be collected immediately at the source server, as determined at inquiries 262 and 264 and in response to question 266, a check 288 is made as to whether the host server is the source server. If so, the packet is passed in step 268 through to a module that handles the final data collection. If not, processing unit 30 conducts an investigation 290 as to whether the source server can be contacted. If no contact is possible, a status report 292 is generated indicating that there will be a delay in processing the data and the packet is then added to the UDSCP processing queue in step 286. If the source server can be contacted, the data is transmitted to that server in a step 294. If the UDSCP function-modified generic processing circuits of processing unit 30 are provided with a packet other than a data submission, a report is produced in a step 296 indicated that the packet is of unknown type.
FIG. 10 illustrates steps in a maintenance loop undertaken by generic digital processing circuits in processing unit 30 which are functionally modified in accordance with the UDSCP protocol. First, an inquiry 298 is made as to whether there are entries in the UDSCP submission processing queue. If so, the first entry is read in a step 300. Subsequently, processing unit 30 decides at junction 302 whether more than X seconds have passed since a date and time stamp on the entry. If not, the UDSCP submission processing queue is investigated at 304 to ascertain whether any further entries are in the queue. If so, the next entry is read in a step 306 and again the processing unit 30 decides at junction 302 whether more than X seconds have passed since a date and time stamp on the entry. If the time passed is greater than that predetermined limit, then a query 308 is made as to whether the server is too busy to handle the data submission. If the server is indeed too busy, processing unit 30 questions at 310 whether the data has the be collected immediately. If the data collection is not urgent, processing unit 30 determines at 312 whether the date and time stamp on the entry was earlier than a particular time. If the date and time stamp is recent, processing unit 30 returns to investigation 304 to check any remaining data submissions in the UDSCP submission queue.
If the server is not too busy to handle a data submission (query 308), if the data has to be collected immediately (question 310), or if data and time stamp indicates a certain age to the data submission (determination 312), processing unit 30 determines at a decision junction 314 whether the data has to be collected by the source server. If not, the packet is passed in a step 316 to a module that handles the final data collection. This module handles e-mailing the submission, recording it in a database, writing it to a file, or preforming any other necessary server-side task with the data. Subsequently, processing unit 30 checks at 318 whether the data submission was processed by the data collection module. If processing has indeed occurred, the packet is removed from the UDSCP submission processing queue in a step 320 and the processor 30 returns to investigation 304 to ascertain whether any further entries are in the queue. If the data submission packet has not been processed, which is discovered at 318, an inquiry 322 is made as to whether the failure to process the request is due to a possibly temporary condition. If not, a notification 324 is generated for alerting an appropriate person as to the failure. If so, the date and time stamp on the data submission is updated in a step 326.
If processing unit 30 determines at decision junction 314 that the data has to be collected by the source server and further determines at a subsequent decision junction 328 that the host (itself) is the source server, then the packet is processed (step 3 16). Alternatively, if the source server must do the data collection and is a different computer, as determined at decision junction 328, then an attempt 330 is made to contact the source server. If the source server cannot be contacted, the date and time stamp on the data submission is updated in step 326. If the source server is available, the data submission is transmitted to the source server in a step 332 and the packet is removed from the UDSCP processing queue in a step 334.
As discussed above, the MCMP protocol handles Load Distribution, User Authentication, and Encryption. All other functions are handled by sub-protocols. The MCMP protocol has four sub-protocols. These are the Code Module Exchange Protocol (CMXP), the Uni-directional Data Submission and Collection Protocol (UDSCP), the Metered Delivery and Billing Protocol (MDBP), and the Distributed Processing Protocol (DPP). This set of protocols can be expanded in the future to add additional functionality to the MCMP protocol.
Basic MCMP Packet Structure
All MCMP packets consist of a MCMP header, followed optionally by one or more resource identifiers, and a data area called the packet body (FIG. 1). The entire size of an MCMP packet can be calculated as 128+RsrcIDLen+PacketSize, where RsrcIDLen and PacketSize are elements of MCMP header (see below).
The MCMP header identifies the sub-protocol to which the packet belongs, as well as the type of packet. In addition, the MCMP header contains load distribution, user authentication, and encryption information. The Resource identifiers identify any resource or resources referred to in the packet (the ResourceReq flag being set). The MCMP packet body contains packet-type specific information and is always interpreted by a subprotocol handle. The packet body is optional and can be omitted b ysetting the PacketSize element of the MCMP headet to be 0.
The MCMP header structure is defined as:
______________________________________                                    
MCMPHeader,128 $$    MCMP header structure                                
•  MPVersion,4                                                      
               $$    Master protocol version                              
•  ProtoVendor, 8                                                   
               $$    Protocol vendor                                      
•  ProtoID, 8                                                       
               $$    Protocol ID                                          
•  ProtoVer, 4                                                      
               $$    Protocol version                                     
•  TransID, 2                                                       
               $$    Client Assigned Transaction-ID                       
•  PacketType, 2                                                    
               $$    Protocol-specific Packet Type                        
•  PacketVersion, 4                                                 
               $$    Packet version number                                
•  PacketSize, 4                                                    
               $$    Size, in bytes, of packet body                       
•  OrigIP, 4                                                        
               $$    Originating Host IP Address                          
•  OrigPort, 2                                                      
               $$    originating Host Port Number                         
•  UserID,10                                                        
               $$    User ID for client authentication                    
•  Password, 10 -                                                   
               $$    Password for client authentication                   
•  RsrcIDLen,2                                                      
               $$    Resource identifier length                           
•  RsrcIDs,2                                                        
               $$    Number of resource identifiers                       
•  RsrcSrcIP,4                                                      
               $$    Resource source IP                                   
•  Flags, 2                                                         
               $$    Flags; see functions below                           
•  , 64  $$    Reserved                                             
* Flags:                                                                  
Shunted = bit (Flags,1)                                                   
               $$    Packet has been shunted                              
Shuntable = bit (Flags,2)                                                 
               $$    Packet can be shunted                                
Encrypted = bit (Flags,3)                                                 
               $$    Packet was encased in an encryption                  
                     packet                                               
ResourceReq = bit (Flags,4)                                               
               $$    Packet constitutes a request for a                   
                     resource                                             
______________________________________                                    
The elements of this structure are described in more detail below.
MPVersion: This is a 4-character version identifier for the Master Protocol. If the structure of the MCMP header or any other major component of the Master Protocol structure is revised, this version number is incremented.
ProtoVendor. This is an 8-byte text literal that describes the software vendor initial responsible for maintaining the sub-protocol specificiation for the sub-protocol to which the packet belongs.
ProtoID. This is an 8-byte text literal assigned by the software vendor specified in the ProtoVendor element. This identifies the sub-protocol to which the packet belongs. The combination of ProtoVendor and ProtoID uniquely identifies a sub-protocol.
ProtoVer: This is a 4-byte text string that specifies the version of the sub-protocol specified in the ProtoVendor and ProtoID elements. The first to characters are the major version, the second two the minor version. All characters must be used, so if the major version is one character long, it must be written as 01, not 1. This value does not contain a decimal point. For example, version 2.4 would be 0 2 4 0.
Packet-Type Identifier (PacketType): A two-byte integer assigned by the vendor that uniquely identifies the packet type within a particular sub-protocol.
PacketVersion: This is a 4-character identifier for the packet version. When the structure of a packet is changed, this version number is incremented. This allows a sub-protocol handler running on an MCMP server to deal with both old and new packet structures, should a packet structure need to be altered. The format for the string is the same as the format of the ProtoVer element of the MCMP header.
Shunted flag (Shunted): A flag indicating whether this packet has been shunted as the result of a service hand off.
Shuntable flag (Shuntable). A flag indicating whether this packet can be shunted. This flag and the Shunted flag are mutually exclusive.
Encrypted flag (Encrypted): A flag indicating whether the packet was encrypted. This flag is cleared when a packet is placed in the MCMP Server incoming packets queue, unless the packet is place there by the decryption system, in which case the flag is set.
Request-Resource flag (ResourceReq): Indicates whether the packet constitutes a request for a resource.
Number of Resource Identifiers (RsrcIDs): Dpecifies the number of resource identifiers following the MCMP header structure.
Resource Identifier Length (RsrcIdLen): Specifies the combined length of all resource identifiers following the MCMP Header structure.
Originating Host Address (OrigIP, OrigPort): This is the IP address of the host from which the request originated. If the packet was shunted, this is the IP address of the host that originally transmitted the request, not the address of the server that forwarded the request.
Resource Source IP (RsrcSourceIP): This is the IP address of the host on which the original copy of the requested resource resides, if the Request-Resource flag is true.
Cached Copy Date/Time Stamp (CacheDate, CacheTime): This is the date and time stamp of the cached copy of the resource, or zero if no cached copy exists. If the date and time stamp of the resource match this date and time stamp, the resource content will not be returned.
Size of packet body (PacketSize): The size (in bytes) of the packet body following the MCMP Header and (if present) the resource identifiers.
User ID and Password for client authentication (UserID, Password): A user ID and Password used to authenticate the client. The authority for a user's ID and Password is the Resource Source IP server. If a request is made to a secondary server for a password-protected resource, the secondary server must check with the primary (or source server) for password authentication. This information can be cached for the duration of the session.
Transaction ID (TransID): A unique ID assigned by the host initiating the transaction. This is used to track a transaction over one or more service hand-offs. For an encryption packet, this should be set to zero (although it can be set to a non-zero value in the encased packet).
MCMP Resource Identifiers
If the packet refers to one or more resources (the ResourceReq flag is set), the Resource identifiers identify the resource or resources to which the packet refers. Resource identifiers are null-terminated text strings. The basic format for a resource identifier is:
type:[locator/s;]length[;date[,time]]
Where:
______________________________________                                    
type   Identifies the resource type; the possible values for this         
       argument are sub-protocol-specific.                                
locator/s                                                                 
       One or more values (in double-quotes if they contain commas;       
       double up the double-quotes where they are used within the         
       value) used to locate the resource.                                
length The amount of the resource to read (in units specific to the       
       sub-protocol). This is always the last item in the resource        
       identifier. It can be in the format "n" to specify n units         
       starting at the beginning of the resource, the format "n/n" to     
       specify a range of units (inclusive), the format "n/n" to          
       specify a starting unit and number of units, or "*" to specify     
       the entire resource.                                               
date   The date, in the format mm/dd/yyyy that the cached copy of         
       the resource was last modified. This field accepts both single     
       and double digits for the month and day, although the year         
       must be specified as a full 4-character string. Forward-slashes    
       must be used as separators.                                        
Time   The time, in the 24-hour format hh:mm:ss, that the cached          
       copy of the resource was last modified. hh may be a single or      
       double digit number, and mm and as must be double digit            
       numbers (use a leading zero if necessary).                         
______________________________________                                    
The Resource ID is optional, and does not need to be included in a MCMP packet, so long as the ResourceReq flag is not set.
Some example Resource ID's are:
______________________________________                                    
data: "\catharon\demos\media., "video.bin", 
"play30";*                                                                
prohibitedlist:*                                                          
dir:"\";*                                                       
data:"\catharon\demos\","mag2.dat";0/256    
data:"\training","air.bin.","Rudder";*;10/03/1995,4:03:30       
______________________________________                                    
MCMP Packet Types
The following subprotocols are not sub-protocl specific and are accordingly defined for the MCMP protocol:
______________________________________                                    
MCMP.sub.-- Encrypt                                                       
            = h0002  $$    Encryption                                     
MCMP.sub.-- Status                                                        
            = h0003  $$    Status Report                                  
MCMP.sub.-- PerfStatReq                                                   
            = h0006  $$    Performance Statistics Request                 
MCMP.sub.-- PerfStatResp                                                  
            = h0007  $$    Performance Statistics                         
                           Response                                       
MCMP.sub.-- UserIReq                                                      
            = h0008  $$    User Information Request                       
MCMP.sub.-- UserIResp                                                     
            = h0009  $$    User Information Response                      
MCMP.sub.-- EchoReq                                                       
            = h000a  $$    Echo Request                                   
MCMP.sub.-- EchoResp                                                      
            = h000b  $$    Echo Response                                  
______________________________________                                    
These packet types are described in detail below.
ENCRYPTION (MCMP-- Encrypt): The encryption packet is used when data must be encrypted. A packet to be encrypted is encased in the data area of a MCMP System encryption packet. The MCMP Header for the encryption packet is:
PacketType: MCMP-- Encrypt (hO002)
PacketSize: Size of encased packet in encrypted form plus 32 bytes
ResourceID's: None
Shuntable: Inherited from encased packet
ResourceReq: False
The packet body of the encryption packet is:
______________________________________                                    
Bytes 0-31          Encryption header                                     
Bytes 32-end        Encrypted packet                                      
______________________________________                                    
The header for the encryption packet is:
______________________________________                                    
PT.sub.-- Encrypt.sub.-- Header,32                                        
•  DecryptLess,8                                                    
                $$ Code module to handle decryption                       
•  DecryptUnit,8                                                    
•  EncodingMethod,2                                                 
                $$ Encoding method                                        
•  ,14    $$ Reserved                                               
______________________________________                                    
STATUS REPORT (MCMP-- Status): The status report packet is used to return the status of an operation. When used, it is always a response to a previously transmitted request. The status packet contains detailed error information, including an English language description of the error or status value which can be displayed by the application if it cannot interpret the error code.
A status report packet body consists of one or more information fields, which can vary in length. The first information field is always a Status Report Header. Each information field consists of an 8-byte header which indicates the length and type of the information field, followed by the field itself.
The MCMP Header for the status report packet is:
PacketType: MCMP-- Status (hO002)
PacketSize: Variable
ResourceID's: None
Shuntable: No
ResourceReq: No
The Information Field Header for the status report packet is:
______________________________________                                    
MCMP.sub.-- StRprt IFldHdr,8                                              
•  IfldSize,2                                                       
                  $$    Size of information field                         
•  IfldClass,1                                                      
                  $$    Field alass (1=Standard,                          
                        2=Protocol Specific)                              
•  IfldType,2                                                       
                  $$    Field type                                        
•  ,3       $$    Reserved                                          
______________________________________                                    
Following are the standard information field types (where IFldClass=1):
______________________________________                                    
MSR.sub.-- Header                                                         
            = 1     $$ Header                                             
MSR.sub.-- ShortDesc -                                                    
            = 2     $$ Short Description                                  
MSR LongDesc                                                              
            = 3     $$ Long Description                                   
MSR.sub.-- DetailDesc                                                     
            = 4     $$ Detailed Description (Technical)                   
MSR.sub.-- XErr70                                                         
            = 102   $$ LAS 7.0 Execution Error Data                       
MSR.sub.-- XErr70do                                                       
            = 103   $$ LAS 7.0 Execution Error-do-stack                   
______________________________________                                    
These information field types are described in detail below:
The generic status report header (MSR-- Header) is always present in all status report packets, and is always the very first information field in the packet. It has the following structure:
______________________________________                                    
MSR Header.sub.-- Struc,32                                                
•  ProtoVendor, 8                                                   
             $$    The Vendor of the protocol reporting the               
                   error                                                  
•  ProtoID, 8                                                       
             $$    The ID of the protocol reporting the error             
•  ProtoVer, 4                                                      
             $$    The version of the protocol reporting the              
                   error                                                  
•  Severity, 1                                                      
             $$    severity of error:                                     
•  *     -1 =   Notification of success                             
•  *   0 =      Warning (operation will proceed                     
                      anyway, but there may be a                          
                      problem)                                            
•  *   1 =      Error (operation cannot proceed)                    
•  *   2 =      Unexpected error                                    
•  ProtoSpecific, 1                                                 
             $$    Protocol-specific error-flag.                          
•  ErrorType, 2                                                     
             $$    Sub-Protocol-Specific error type                       
•  ErrorCode, 2                                                     
             $$    Sub-Protocol -Specific error code                      
•  , 6 $$    Reserved                                               
______________________________________                                    
If the ProtoSpecific flag is set, then ErrorType and ErrorCode are protocol-specific. Otherwise, ErrorType is one of the following:
______________________________________                                    
 ERRT .sub.-- = 1eturn                                                    
                      $$                                                  
*zreturn* error                                                           
 ERRT.sub.-- XErr                                                         
              = 2     $$ TenCORE Execution error                          
 ERRT.sub.-- CErr                                                         
              = 3     $$ TenCORE Condense error                           
 ERRT.sub.-- Dosdata                                                      
              = 4     $$ Catharon dosdata-style error                     
______________________________________                                    
For anything in the MCMP-- Status packet that is protocol specific, the ProtoVendor and ProtoID from the Status Report Header are used to identify the protocol.
The Short Description information field type (MSR-- ShortDesc) is a short description of the error, 40 characters long or shorter, that can be used in a list or wherever a brief, friendly error description is needed. This packet is 40 bytes long, and is structured as follows:
______________________________________                                    
MSR.sub.-- ShortDesc strtlc, 40                                           
•  ShortErrDesc,40                                                  
                  $$ Short description of error                           
______________________________________                                    
The Long Description information field type (MSR-- LongDesc) is a longer description of the error, which can vary in length up to 2048 characters. This description can span multiple lines, with each line terminated by a carriage return (h0d). The length of this description is determined by the length of the information field, and the entire content of the information field is one long buffer variable containing the description as text. There is no maximum length to a line, and lines may be word-wrapped at any position when this description is displayed.
The Detailed Description information field type (MSR-- DetailDesc) is a detailed technical description of the error, with all diagnostic error information included. For example, this might be a standard TenCORE execution error as it would be written to the catharon.err log file by the Catharon error handler. This can vary in length, up to 4096 characters. The description can span multiple lines, with each line terminated by a carriage return (h0d). Lines must be no longer than 80 characters. Lines longer than 80 characters may be truncated at display time. This description is never word-wrapped, and is always displayed in a fixed pitch font, allowing items on separate lines to be aligned and formatted using spaces (tables could be created using this method). The length of this description is determined by the length of the information field, and the entire content of the information field is one long buffer variable containing the description as text.
The TenCORE 7.0 Execution Error Data (MSR-- XErr70) is an exact snapshot of the data generated by a TenCORE execution error, and returned by TenCORE in the execution error memory block. It is 256 bytes long. This information field type is normally only included if the error being reported is a TenCORE execution error.
The TenCORE 7.0 Execution Error To- Stack (MSR-- XErr70do) is an exact snapshot of the TenCORE execution error -do- stack. The size of the data varies based on the size of the TenCORE -do- stack at the time of the error.
PERFORMANCE STATISTICS REQUEST (MCMP-- PerfStatReq): The performance statistics request packet requests a server's current performance and load statistics.
The MCMP Header of a performance statistics request is:
PacketType: MCMP-- PerfStatReq (h0005)
PacketSize: 0
ResourceID's: None
Shuntable: No (because this is a request for the statistics for the server to which it is addressed, shunting me packet would cause meaningless results)
The response to this packet should be either an MCMP-- PerfStatResp or a MCMP-- Status packet.
PERFORMANCE STATISTICS REPORT (MCMP-- PertStatResp): This packet is a response to an MCMP-- PerfStatReq packet and contains a performance statistics report for the server to which it was addressed.
The MCMP Header of a performance statistics report is:
PacketType: MCMP-- PerfStatReq (h0006)
PacketSize: 32
ResourceID's: None
Shuntable: No
ResourceReq: No
The Packet Body of a performance statistics report is:
______________________________________                                    
PerfStats,32                                                              
•  Pusage,1                                                         
            $$    Processor usage (percent)                               
•  CurReqs,2                                                        
            $$    Current number of requests being processed              
•  TotalRegs,2                                                      
            $$    Total number of requests the can be                     
                  processed                                               
•  ShuntRegs,2                                                      
            $$    Threshold, in requests, at which shunting               
                  begins                                                  
•  PmemTotal,4                                                      
            $$    Total physical memory on system                         
•  PmemUsed,4                                                       
            $$    Used memory on system                                   
•  VmemTotal,4                                                      
            $$    Total virtual memory on system                          
•  VmemUsed,4                                                       
            $$    Used virtual memory on system                           
•  AreqPMethod,1                                                    
            $$    Current method for processing additional                
                  requests                                                
•  ,8 $$    Reserved                                                
______________________________________                                    
The elements of the packet body structure are, in detail:
PUsage:Current processor usage percentage (0% to 100%). Set to -1 if processor usage percentage is not available.
CurReqs: Approximate number of requests currently being processed.
TotalReqs: Total number of requests that can be processed at one time.
ShuntReqs: Maximum number of requests before shunting occurs. This is usually less than TotalReqsto allow some extra system resources for the purpose of shunting requests.
PmemTotal: Number of bytes of physical memory on server, or -1 if amount not known.
PnemUsed: Number of bytes of physical memory that have been used, or -1 if amount not known.
VmemTotal: Number of bytes of virtual memory available on server, -1 if not known.
VmemUsed: Number of bytes of virtual memory in use, or -1 if not known.
AreqPMethod: Method that will be used by the server deal with new incoming requests, based on the other statistics in this packet. This can have the numerical value 1, 2, or 3.1 indicates that new requests will be processed normally, 2 indicates that new requests will be shunted; 3 indicates that new requests will be refused.
USER AUTHENTICATION INFORMATION REQUEST (MCMP-- UserIReq): This packet requests user authentication information on a particular user. This packet must be encrypted, and is sent only from a secondary server to a primary server. The receiving server must check that the sender is listed as a secondary server before responding to this request.
The expected response is either an MCMP-- Status packet or an MCMP-- UserIResp packet.
This packet uses a special type of resource identifier, which is defined as follows:
type:user[,uadbitem];length[,date,time]
Where:
______________________________________                                    
type   Identifies the resource type; is always "useradb"                  
user   The name of the user in question                                   
uadbitem                                                                  
       Path to user authentication database item to retrieve. If          
       omitted, a tree-file is resumed containing the entire user         
       authentication data tree for the specified user. The root of the   
       resumed tree-file is equivalent to \LocalUsers\
       username in the                                                    
       user database file. length Portion of item to be                   
______________________________________                                    
       resumed.                                                           
Examples:
useradb:JohnS.\Catharon\RAdmin\Rights;*:03/13/1995,12:20:48
useradb:HugoC;*
useradb:JDouglas.\XYZWidSt\WDBP\GroupMembership;256;S/12/1996, 01:00:30
The User Authentication Database (UADB) is stored in a tree-file. User information is stored in \LocalUsers. Inside the \LocalUsers folder are folders for each user, named based on the user's ID. In each user's folder are folders for each vendor (i.e. "Catharon", "CTC", etc.), and inside the vendor folders are folders for each protocol defined by that vendor. The contents of a protocol folder are protocol-specific. The path specified in the resource ID is rooted at \LocalUsers\username.
Basic user authentication information is stored in \Catharon\MCMP\BaseAuthData. This is structured as follows:
______________________________________                                    
UserAuthData,32                                                           
•  UserID,10                                                        
                 $$ Userts name/ID                                        
•  UserPass,10                                                      
                 $$ User's password                                       
•  ExpTime,3                                                        
                 $$ Time, in seconds, before data                         
•          $$ expires (10 to 864000).                               
•  BinUID,4                                                         
                 $$ Binary User ID                                        
•  ,5      $$ Reserved                                              
______________________________________                                    
If a secondary server sends a request in the form:
useradb:usez,2ame;* [;date,time]
the entire user authentication tree is retrieved for the specified user. The ability to read a specific item from the user authentication tree is provided for future use and expandability.
After retrieving user authentication data, that data can be cached for the period of time specified in the ExpTime element of the UserAuthData structure. The user authentication data may not be cached longer than the specified time.
The MCMP Header of the User Authentication Information Request is:
PacketType: MCMP-- UserIReq (h0008)
PacketSize: 0
ResourceID's: One; specifying the user to retrieve information about, and what information to retrieve.
Shuntable: No (must be processed by primary server because the primary server is the only authoritative source of information on the user).
ResourceReq Yes
USER AUTHENTICATION INFORMATION RESPONSE (MCMP-- UserIResp): The response to an MCMP-- UserIReq packet, this packet contains the requested information in its data area. This data is either the raw data read from the requested data block in the user database, or (if uadbitem is omitted) is a tree file containing the entire user information tree for the specified user, with the root of the file being equivalent to \LocalUsers\username in the UADB.
The MCMP Header of the User Authentication Information Response is:
PacketType: MCMP-- UserIResp (hO009)
PacketSize: Variable
ResourceID's: None
Shuntable: No
ResourceReq: No
ECHO REQUEST (MCMP-- EchoReq): This packet is used to time the connection to a particular MCMP host. When this packet is received by an MCMP host, a MCMIP-- EchoResp packet is immediately sent back. The data area can contain any data, up to a maximum size of 2048 bytes. The return packet's data area will contain the same data.
The MCMP Header of the Echo Request is:
PacketType: MCMP-- EchoReq (hOOOa)
PacketSize: Any
ResourceID's: None
Shuntable: No
ResourceReq: No
ECHO RESPONSE (MCMP-- EchoResp): This packet is sent in response to an MCMP-- EchoReq packet.
The MCMP Header of the Echo Response is:
PacketType: MCMP-- EchoResp (hOOOb)
PacketSize: Same as original MCMP-- EchoReq packet
ResourceID's: None
Shuntable: No
ResourceReq: No
Some files in a directory may support additional access pennission information. For example, a tree file could contain information on access permission for individual units within the tree file.
CMXP Resource Identifiers
Resource Identifiers for CMXP packets are defined as follows:
type:patht,file[,unit]];length[;date,time]
Where:
______________________________________                                    
type   Identifies the resource type. This can be either "Data" to read    
       data from the specified resource, or "Dir" to read a directory     
       of contained resources.                                            
path   Path to a directory...must be at least a backslash "\".  
       If file                                                            
       and unit are not specified, the directory is considered the        
       resource to be read; otherwise, the file or unit referenced is     
       assumed to be located in the specified directory. If file and      
       unit are not specified, then type must be "Dir".                   
file   A filename. If unit is not specified, the file is considered the   
       resource; otherwise, the unit is assumed to be located in the      
       specified file. A file resource can be accessed with both the      
       "Dir" and "Data" resource types; "Dir" will reference the list     
       of contained units, while "Data" will reference the actual data    
       contained in the file.                                             
unit   A unit name. If specified, the unit is considered to be the        
       resource. This can be accessed with both the "Dir" and "Data"      
       resource types; "Dir" will reference the list of sub-units, while  
       "Data" will access the data contained in the unit.                 
length The portion of the resource to read. If typeis "Data", this        
       value is in bytes. If type is "Dir", this value is in directory    
       entries.                                                           
date/time                                                                 
       Can only be specified in a request packet. Causes the recipient    
       process to ignore the request unless the resource has been         
       modified since the date/time specified This can be used in         
       conjunction with the CMXP.sub.-- ReadReq packet to request that    
       a resource be sent only if it has changed since it was cached      
       on the client.                                                     
______________________________________                                    
CMXP Packet Types
The following is a list of the packet types used by the CMXP protocol at this time. The functionality of the CMXP protocol can be expanded in future by adding to this list of packet types.
CMXP-- ReadRsrcReq=h0002
CMXP-- ReadRsrcResp=h0003
CMXP-- WriteRsrc=h0004
CMXP-- CreateRsrc=h0005
CMXP-- DestroyRsrc=h0006
CMXP-- RenameRsrc=h0007
CMXP-- CopyRsrc=h0008
CMXP-- MoveRsrc=h0009
CMXP-- AltSListReq=h000a
CMXP-- AltSListResp=h000b
These packet types are described in detail below.
READ RESOURCE REQUEST (CmxP-- ReadRsrcReq): This packet is a request to read one or more resources. It is sent from a client to a server to download a resource, sent from a client to a client to request a code module transfer for a plug-in module, or sent from a server to a server to request transfer of the appropriate resource to service a client request. A CMXP-- ReadRsrcReq packet can request either resource content, resource information, or both. Because the definition of a resource includes file directory and code module directories, this packet can also be used to request a list of files in a directory or code modules in a file.
This packet is responded to with a series of packets (one for each request resource). These packets are either CMXP-- ReadRsrcResp (if the resource was successfully read) or MCMP-- Status (if there was an error reading the resource).
The MCMP Header of a read resource request packet is:
PacketType: CMXP-- ReadRsrcReq (honey)
PacketSize: 32
ResourceID's: One or more, Identifying resources to read
Shuntable: Yes
ResourceReq: Yes
The Packet Body of a read resource request packet is:
______________________________________                                    
   ReadRsrcReqHeader,32                                                   
•  RHFlags,2                                                        
               $$ Flags                                                   
•  ,30   $$ Reserved                                                
   * Flags:                                                               
   IncludeInfo = bit(RHFlags,1)                                           
                  $$    Include resource information                      
   IncludeData = bit(RHFlags,2)                                           
                  $$    Include resource content                          
   IdlePreCache = bit(RHFlags,3)                                          
                  $$    Request is the result of an                       
                        idle-time pre-caching                             
                        operation.                                        
______________________________________                                    
The elements of the packet body are, in detail:
IncludeInfo: If set, this flag causes infonnation about the resource to be returned.
IncludeData: If set, this flag causes the resource content to be returned.
IdlePreCache: If set, indicates the the request is the result of an idle-time pre-caching operation initiated by the client without user involvement. A CMXP server processes packets with this flag clear before packets with this flag set are processed. When the load on a CMXP server becomes too high for it to deal with all requests, and it can not shunt requests, requests with this flag set will be dropped before requests with this flag clear.
IncludeInfo and IncludeData can both be set in the same request In this case, the response is the resource information followed by the resource content. This is the most common request type. At least one of these flags must be set in each request packet
READ RESOURCE RESPONSE (CMXP-- ReadRsrcResp): Sent in response to a CMXP-- ReadRsrcReq packet, this packet contains the requested information. Note that this packet is never sent in response to a CMXP-- ReadRsrcReq if an error condition exists, instead, a MCMP-- Status packet is sent.
Depending on the state of the IncludeInfo and IncludeData flags in the CMXP-- ReadRsrcReq packet, the packet body may contain resource information and/or resource content. The resource information, if it is present, always comes first in the packet body, followed by the resource content, if present. The size of the resource information can be determined by reading the ResourceInfoSize element of the version of a program can be sucessfully merged with code modules from an old version of the program.
RsMaxSubs: The maximum number of subsidiaries that the resource can contain.
RaSizeAInfo: The size, in bytes (1 to 8), of the associated information for the resource (RsAlnfo).
RsSizeSubName: The maximum length, in characters, of the name of a subsidiary of the resource.
RsHeight, RsWidth. The height and width of the bounding rectangle of the resource at its default scaling, if applicable. This is used for object-based drawings, images, etc.
RsPTime: The playing time, in seconds at the default playing speed, of the resource (if applicable); used for video clips, way files, midi files, animations, etc.
WRITE RESOURCE (CMXP-- WriterSrc): This packet writes data to the specified resource. This requires sending a packet to the primary server that cannot be shunted, so this can increase server load. For form submissions and other uni-directional submissions, the UDSCP protocol is recommended over the write functions of the CMXP protocol.
A CMXP-- WriteRsrc request may fail due to, among other things, the fact that the user is not allowed to write to the specified resource. This situation may be remediable by repeating the request with a user-id and password specified (in this case, the request must be encased in a MCMP-- Encrypt packet).
There are two variations of the status code returned when access is denied due to failed user authentication. One variation indicates that the client should prompt for a user name and password. This is a "hint" to the client that the resource may be accessible via a user name and password. It is not conclusive. In other words, the variation on the Access Denied code does NOT indicate whether access is really available to anyone, i just indicates whether the client should ask. There may, for example, be a resource designed to be accessed under program control, and not under user control, which requires user authentication of an "automation user", and which denies access the rest of the time without even prompting for a user-id/password.
The packet body contains the data to be written to the resource.
The MCMP Headerof the write resource packet is:
PacketType: CMXP-- WriteRsrc (h0004)
PacketSize: Variable
ResourceID's: One, the ID of the resource to-wnte to
Shuntable: No
ResourceReq: Yes
CREATE RESOURCE (CMXP-- CreateRsrc): This packet creates a subsidiary in the specified resource. This includes files, directories, and units. The same rules regarding user authentication apply to this packet as apply to the CMXP-- WriteRsrc packet.
The MCMP Header of the create resource packet is:
PacketType: CMXP-- CreateRsrc (h0005)
PacketSize: Variable
ResourceID's: One, the ID of the resource In which to create the new subsidiary.
Shuntable: No
ResourceReq Yes
The Packet Body of the create resource packet is:
______________________________________                                    
NewRsrc,300                                                               
•  RsSize,4                                                         
              $$ Size, in bytes, of resource                              
•  RsAInfo,8                                                        
              $$ Associated information (if applicable)                   
•  RsMaxSubs,2                                                      
              $$ Maximum number of subsidiaries                           
•  RsSizeAInfo,1                                                    
              $$ Size, in bytes, of associated information                
•  RsSizeSubName,2                                                  
              $$ Maximum length of a subsidiary's name                    
•  RsName,256                                                       
              $$ Resource Name                                            
•  RsName2,8                                                        
              $$ Secondary Resource Name                                  
•  RsType,8                                                         
              $$ Resource type                                            
•  ,11  $$ Reserved                                                 
______________________________________                                    
The elements of the packet body are, in detail:
ReSise The size, in bytes, of the new resource. If creating a TenCORE nameset or dataset, this must be a multiple of 256 bytes, and is equivalent to the records argumen of the -createn- command multiplied by 256 (to convert from records to bytes). When creating new directories, this is ignored.
R-AInfo: Associated information for the resource, if applicable (see CMXP-- CreateRsrc above)
RsMaxSubs: The number of subsidiaries allowed in the resource, if applicable. This is required for TenCORE namesets, and is equivalent to the names argument of the -createn- command. In most cases, when not dealing with TenCORE namesets, this is ignored.
R-SizeAInfo: The size of the resources associated information. For namesets, this is equivalent to the infolength argument of the -createn- command.
RsSizeSubName: Maximum length of a subsidiary's name. For TenCORE namesets, this is equivalent to the namelength argument of the -createn- command. In most cases when-not dealing with TenCORE namesets, this is ignored.
ReName: The name of the resource to create. The length of this name and the rules for allowed characters depend on the type of resource being created.
RaName2: This is a secondary name for the resource. It is not currently used, but is provided for future use. This may be used, for example, to specify a short file name alias to go with a long filename in Windows 95/NT.
RaType: This specifies the type of resource being created. Note that not all resource types are necessarily valid for all possible resources in which they could be created (i.e., one cannot create a file inside of a unit). Where only one resource type is possible for a particular containing resource, the value `default` is used (for example, the only type of resource that can be created inside a TenCORE nameset is a block). This value is an 8-byte text literal.
The following resource types are currently defined for the CMXP protocol:
______________________________________                                    
course                                                                    
      A course file (TenCORE nameset with .CRS extension)                 
group A group file (TenCORE nameset with .GRP extension)                  
nameset                                                                   
      A gentral purpose nameset file (TenCORE nameset with .NAM           
      extension)                                                          
roster                                                                    
      A roster file (TenCORE nameset with .RTR extension)                 
source                                                                    
      A source file (TenCORE nameset with .SRC extension)                 
studata                                                                   
      A student data file (TenCORE nameset with .SDF extension)           
tpr   A Producer file (TenCORE nameset with .TPR extension)               
binary                                                                    
      A binary file (TenCORE nameset with .BIN extension)                 
file  An operating system file                                            
dir   An operating system folder or directory                             
dataset                                                                   
      A TenCORE dataset                                                   
tree  Catharon tree-file                                                  
default                                                                   
      The default type for the container                                  
block A data block (in a nameset or tree-file)                            
folder                                                                    
      A folder (in a time-file)                                           
______________________________________                                    
DESTROY RESOURCE (CMXP-- DestroyRsrc): This packet destroys the specified resource. The same rules regarding user authentication apply to this packet as apply to the CMXP-- WriteRsrc packet. The MCMP Header of this packet is:
PacketType: CMXP-- DestroyRsrc (h0006)
PacketSize: 0
ResourceID's: One, the ID of the resource to destroy
Shuntable: No
ResourceReq: Yes
RENAME RESOURCE (CMXP-- RenameRsrc): This packet renames the specified resource. The same rules regarding user authentication apply to this packet as apply to the CMXP-- WriteRsrc packet. The packet body contains the new name for the resource. The MCMP Header of this packet is:
PacketType: CMXP-- RenameRsrc (hO007)
PacketSize: 272
ResourceID's: One; the ID of the resource to rename
Shuntable: No
ResourceReq: Yes
The Packet Body of the rename resource packet is:
______________________________________                                    
RenameRsrc,272                                                            
•  ResourceName,256                                                 
                 $$ New name for resource                                 
•  ResourceSecondaryName,8                                          
                 $$ Secondary name for resource (if                       
                 applicable)                                              
•  ,9      $$ Reserved                                              
______________________________________                                    
COPY RESOURCE (CMXP-- CopyRsrc): This packet copies the specified resource. The same rules regarding user authentication apply to this packet as apply to the CMXP-- WriteRsrc packet The MCMP Header of the copy resource packet is:
PacketType: CMXP CopyRsrc (h0008)
PacketSize: 0
ResourceID's: Two; the first is the location of the resource to copy, the second the location to create the new copy of the resource.
Shuntable: No
ResourceReq: Yes
MOVE RESOURCE (CMXP-- MoveRsrc): This packet moves the specified resource. The same rules regarding user authentication apply to this packet as apply to the CMXP-- WriteRsrc packet. The MCMP Header of the move resource packet is:
PacketType: CMXP-- MoveRsrc (h0009)
PacketStze: 0
ResourceID's: Two; the first ts the old location of the resource, the second the new location for the resource.
Shuntabte: No
ResourceReq: Yes
ALTERNATE SERVER LIST REQUEST (CMXP-- AltSListReq): This packet requests a list of secondary servers available for the specified resource. The server should respond with an CMXP-- AltSListResp packet, except in the case of an error, in which case an MCMP-- Status packet should be returned. The MCMP Header of this packet is:
PacketType: CMXP-- AltSUstReq (h000a)
PacketSize: 0
ResourceID's: One--The resource for which to list secondary servers.
Shuntable: Yes
ResourceReq: Yes
ALTERNATE SERVER LIST RESPONSE (CMXP-- AltSListResp): This packet is sent in response to an CMXP-- AltSListReq packet and contains the list of alternate servers. The MCMP Header is:
PacketType: CMXP-- AltSUstResp (h000b)
PacketSize: Variable
ResourceID's: None
Shuntable: No
ResourceReq: No
The Packet Bodyof the CMXP-- AltSListResp packet is:
______________________________________                                    
AltSList(nn),16                                                           
•  IP,4  $$ IP Address of server                                    
•  Port,2                                                           
               $$ Port on server to access                                
•  Load,1                                                           
               $$ Last known load on server                               
•  Ping,4                                                           
               $$ Last known ping-time to server                          
•  ,4    $$ Reserved                                                
______________________________________                                    
The following is a list of the packet types used by the UDSCP protocol at this time. The functionality of the UDSCP protocol can be expanded in future by adding to this list of packet types.
______________________________________                                    
       UDSCP.sub.-- Submission                                            
                     = h0002                                              
       UDSCP.sub.-- QueueStatusReq                                        
                     = h0003                                              
       UDSCP.sub.-- QueueStatusResp                                       
                     = h0004                                              
______________________________________                                    
These packet types are described in detail below.
DATA SUBMISSION (UDSCP-- Submission): This is the primary packet type for the UDSCP protocol. It is generated by a client, and then forwarded from server to server until it reaches the collection point. The packet body consists of a UDSCP Header followed by the content of the submission.
The MCMP Header of the data submission packet is:
PacketType: UDSCP-- Submission (hO002)
PacketSize, 32+Size of data being submitted
ResourceID's: None
Shuntable: Yes
ResourceReq: No
The UDSCP Header is:
______________________________________                                    
UDSCPSubmitHeader,32                                                      
•  HeaderSize,2                                                     
             $$    Size of UDSCPSubmitHeader                              
•  DataSize,4                                                       
             $$    Size of data being submitted                           
•  Cmethod,1                                                        
             $$    Collection method (1=Central,                          
                   2=Secondary)                                           
•  CpointIP,4                                                       
             $$    Collection point IP Address                            
•  Priority, 1                                                      
             $$    Priority (O=low, 1=normal, 2=urgent)                   
•  Lesson,8                                                         
             $$    TenCORE Lesson/Unit to process                         
                   submission                                             
•  Unit,8                                                           
•  Flags, 2                                                         
             $$    Flags                                                  
•  ,2                                                               
* Flags:                                                                  
Forwarded = bit(Flags,1)                                                  
             $$    Submission has been forwarded by a                     
                   server                                                 
______________________________________                                    
The elements of the UDSCP header are described in detail below:
HeaderSize: The size, in bytes, of the UDSCPSubmitHeader structure. This value should be read to determine the size of the whole structure, this allowing the structure to be expanded in future without affecting existing code.
DataSize: The size, in bytes, of the content of the submission following the UDSCP Header.
Cmethod: The collection method to be used. This is an integer value. A setting of 1 causes data to be collected and processed at a centeral server, while a setting of 2 allows data to be processed on secondary servers.
CpointIP: The IP address of the collection point (centeral server) This is ignored if CMethod=2.
Priority: The priority of the submission. This is an integer value, and can be either 0 for low, 1 for normal, or 2 for high priority. UDSCP servers attempt to process high priority submissions immediately, while normal and low priority submissions are held in the UDSCP submission queue and processed when the server would othewise be idle. If a normal or low priority remains in the LTDSCP queue for longer than the user configurable time limit, the server will attempt to process it immediately regardless of load or, failing to do so, notify a responsible person. The time limits for low and normal priority submissions are configurable separately, and low priority submissions are usually configured for a longer timeout.
Lesson, Unit: The names of the TenCORE lesson and unit that will process the submission.
Forwarded: This flag is set if the submission has been forwarded by a UDSCP server, or clear if this is the first UDSCP server to deal with the submission (i.e., the submission came from a client).
QUEUE STATUS REQUEST (UDSCP-- QueueStatusReq): This packet requests the status of the UDSCP queue. The expected response is either an MCMP-- Status packet or a UDSCP QueueStatusResp packet.
The MCMP Headerof the queue status request packet is:
Packet Type: UDSCP--Queue Status Req (h0003)
PacketSize: 0
ResourceID's: None
Shuntable: No
ResourceReq: No
QUEUE STATUS RESPONSE (UDSCP:QueueStatusResp): This packet is the response to a UDSCP-- QueueStatusReq packet. It contains infonnation about the UDSCP server's current UDSCP queue status. The MCMP Header is:
PacketType: UDSCPQueueStatusResp (h0004)
PacketSize: 0
ResourceID's: None
Shuntable: No
ResourceReq: No
The Packet Body of this status response packet is:
______________________________________                                    
QueueStatus,64                                                            
•  Entries,4                                                        
           $$    Total number of entries in the queue                     
•  LowEntAge,4                                                      
           $$    Age of the newest entry in the queue, in                 
                 seconds                                                  
•  HighEntAge,4                                                     
           $$    Age of the oldest entry in the queue                     
•  AvgEntAge,4                                                      
           $$    Age of the average queue entry                           
•  HighPriEnt,4                                                     
           $$    Number of high-priority entries in the queue             
•  LowPriEnt,4                                                      
           $$    Number of low-priority entries in the queue              
•  FwdEnt,4                                                         
           $$    Number of entries which have been forwarded              
•  ToFwdEnt,4                                                       
           $$    Number of entries which must be forwarded                
•  ,32                                                              
           $$    Reserved                                                 
______________________________________                                    
The Metered Delivery and Billing Protocol (MDBP) controls access to pay-for content, including delivering credit to pay for the content, and collecting royalty information after the content has been purchased.
MDBP Packet Types
The MDBP protocol works closely with the CMXP protocol. The CMXP protocol is used to deliver the content in encrypted form. The content is then decrypted when it is unlocked by the MDBP libraries on the client machine. The content is unlocked when it is paid for with credit on the local machine. Credit can be replenished through the MDBP protocol.
When credit is replenished on the local machine, the royalty information is reported to the credit server, which then handles the appropriate distribution of profits.
In a standard credit-purchasing transaction, three packets are exchanged:
An MDBP-- CreditReq is sent from the client to the server
The server responds with an MDBP-- CreditTransfer
The client sends an MDBP-- PurchaseReport to the server
Before credit can be purchased by a user, that user must be registered with the credit server.
The following is a list of the packet types used by the MDMP protocol at this time. The functionality of the MDBP protocol can be expanded in future by adding to this list of packet types.
______________________________________                                    
MDBP.sub.-- CreditReq                                                     
               = 2   $$    Request for additional credit                  
MDBP.sub.-- CreditTransfer                                                
               = 3   $$    Response to MDBP.sub.-- CreditReq              
MDBP.sub.-- RegisterUser                                                  
               = 4   $$    Register a user                                
MDBP.sub.-- RegisterUserResp                                              
               = 5   $$    Response to                                    
                           MDBP.sub.-- RegisterUser                       
MDBP.sub.-- WriteUserData                                                 
               = 6   $$    Write user data                                
MDBP.sub.-- ReadUserData                                                  
               = 7   $$    Read user data                                 
MDBP.sub.-- ReadUserDataResp                                              
               = 8   $$    Response to                                    
                           MDBP.sub.-- ReadUserData                       
MDBP.sub.-- PurchaseReport                                                
               = 9   $$    Puchasing/Royalty Report                       
______________________________________                                    
The MDBP packet types are described in detail below.
REQUEST FOR ADDITIONAL CREDIT (MDBP-- CreditReq): This packet requests additional credit from the server. The packet body contains the user's ID code, which is used to access the user's data in the user database, as well as the amount of credit to be purchased. The user's data includes a billing method to use to pay for the credit. This packet must be encrypted. The expected response is either an MDBP-- CreditResp or an MCMP-- Status packet.
The MCMP Header of a credit request packet is:
PacketType: MDBP-- CreditReq (h0002)
PacketSize: 22
ResourceID's: None
Shuntable: No
ResourceReq: No
The Packet Bodyof a credit request packet is:
______________________________________                                    
UserID,8    $$ User ID; B-byte integer value                              
Password,10 $$ User' 8 pasaword                                           
Credit, 4,r $$ How much credit to purchase (in dollars)                   
______________________________________                                    
CREDIT TRANSFER (MDBP-- CreditTransfer): This packet is the response to an MDBP-- CreditReq. It actually performs the transfer of credit from the server to the client. The packet body contains information on the credit transfer. This packet must be encrypted.
The MCMP Header of a credit transfer packet is:
PacketType: MDBP-- CreditReq thOo03)
PacketSize: 20
ResourceID's. None
Shuntable: No
ResourceReq. No
The Packet Body of a credit transfer packet is:
______________________________________                                    
UserID,8                                                                  
        $$ The ID of the user who should be receiving this credit         
Credit, 4,r                                                               
        $$ The amount of credit purchased (in dollars)                    
Tserial,8                                                                 
        $$ A serial number used to track the transaction                  
______________________________________                                    
USER REGISTRATION (MDBP-- RegisterUser): This packet is used for the initial registration of a user with a credit server. It causes a new entry to be created in the user registration database. The packet body contains information about the user which will be written into the standard fields in the user's new record. The information can be read and modified at a later time through use of the MDBP-- WriteUserData and MDBP-- ReadUserData packets. This packet must be encrypted. The expected response to this packet is an MDBP-- RegisterUserResp or MCMP-- Status packet.
The MCMP Header of a user registration packet is:
PacketType: MDBP-- RegisterUser (hO004)
Packet Size:
ResourceID's: None
Shuntable: No
ResourceReq: No
The Packet Body of a user registration packet is:
______________________________________                                    
RegisterUser, 512                                                         
•  Name,54                                                          
            $$    Full name                                               
•  Company, 54                                                      
            $$    Company name                                            
•  Address1,45                                                      
            $$    Line 1 of the street address                            
•  Address2,45                                                      
            $$    Line 2 of the street address                            
•  City, 20                                                         
            $$    City name                                               
•  State,2                                                          
            $$    2-letter state abbreviation                             
•  Pcode,16                                                         
            $$    Postal code (zip code)                                  
•  Country,30                                                       
            $$    Country name                                            
•  Telephone,16                                                     
            $$    Telephone number                                        
•  AX,16                                                            
            $$    FAX number                                              
•  Email,100                                                        
            $$    E-mail address                                          
•  CardNo,20                                                        
            $$    Credit card number (`nnnn nnnn nnnn nnnn`)              
•  CardExpDate,5                                                    
            $$    Credit card expiration date (`mm/yy` or                 
                  `mm-yy`)                                                
•  Password, 10                                                     
            $$    Password                                                
•  ,79                                                              
            $$    Reserved                                                
______________________________________                                    
USER REGISTRATION RESPONSE (MDBP-- RegisterUserResp): This packet is the response to an MDBP-- RegisterUser packet. It acknowledges the fact that the user has been registered, and returns the user's assigned ID code. The MCMP Header of this packet is:
PacketType: MDBP-- RegisterUserResp (h0005)
PacketSize 8
ResourceID's: None
Shuntable: No
ResourceReq: No
The Packet Body is:
______________________________________                                    
userID,8       $$ user ID; 8-byte integer value                           
______________________________________                                    
WRITE USER DATA (MDBP WriteUserData): This packet writes data to the user database. This uses a resource identifier to identify the element in the user registration database to write to. The packet body is the data to be written. This packet uses a special type of resource identifier, which is defined as follows:
type userid[,dbitem];length[;date,time]
Where:
______________________________________                                    
type  Identifies the resource type; is always "mdbpuser"                  
userid                                                                    
      The ID of the user in question (in hexadecimal)                     
dbitem                                                                    
      Path to user database item to retrieve. If omitted, a tree-file is  
      resumed containing the entire user data tree for the specified      
      user.                                                               
length                                                                    
      Portion of item to be returned.                                     
______________________________________                                    
Examples:
mdbpuser:00000000000003e4,\Catharon\RAdmin\Rights; * ;03/13/1995,12:20:48
mdbpuser:0000000000000014;*
mdbpuser:0000000000002aff\XYZWidgt\WDBP\GroupMembership;256; 5/12/1996,01:00:30
The user database contains a system folder and a publishers folder. The system folder contains the data specified in the initial User Registration packet, and can be expanded to contain additional data. The publishers folder contains a subfolder for each publisher, named based on the publisher's name, and the publisher's folder contain, in turn, publication folders, named based on the publication. The organization of data within a publication folder is specific to the publication.
The MCMP Header of the write user data packet is:
PacketType: MDBP-- WriteUserData (h0006)
PacketSize: Variable
ResourceID's: 1 (The resource to write to)
Shuntable: No
ResourceReq: Yes
READ USER DATA (MDBP-- ReadUserData): This packet reads data from the user database. This uses a resource identifier to identify the element in the user registration database to read from. The format of the resource identifier is the same as that for the resource identifier used in the MDBP-- WriteUserData packet.
Multiple resource identifiers can be specified, causing each of the specified elements in the user registration database to be returned.
This packet is responded to with a series of packets (one for each request resource). These packets are either MDBP-- ReadUserDataResp (if the resource was successfully read) or MCMP-- Status (if there was an error reading the resource).
The MCMP Header of the read user data packet is:
PacketType: MDBP-- ReadUserData (h0007)
PacketSize: 0
ResourceID's: 1 or more
Shuntable: No
ResourceReq: Yes
READ USER DATA RESPONSE (MDBP-- ReadUserDataResp): This packet is the response to an MDBP-- ReadUserData packet. It contains the content of the requested element of the user registration database. The body is the data that was read. The MCMP Header is:
PacketType: MDBP-- ReadUserDataResp (h0008)
PacketSize: Variable
ResourceID's: None
Shuntable: No
ResourceReq: No
PURCHASING/ROYALTY REPORT (MDBP-- PurchaseReport): One or more of these packets is sent from the client to the server after the client has received a response to an MDBP-- CreditReq packet, if the client has purchasing or royalty information to report.
The data area contains a generic royalty report header followed by a publication-specific royalty-report data area. In some cases, the royalty report header is sufficient to report the needed royalty information, so the data area is optional and does not have to be included. Any data following the royalty report header is assumed to be publication-specific data.
The MCMP Header of the royalty report packet is:
PacketType: MDBP-- PurchaseReport (h0009)
PacketSize: Variable
ResourceID's: None
Shuntable: No
ResourceReq: No
The Royalty Report Header is
______________________________________                                    
RoyaltyReport,128                                                         
•  HeaderSize,2                                                     
            $$    Size, in bytes, of royalty report header                
•  Publisher,45                                                     
            $$    Name of publisher                                       
•  Publication,45                                                   
            $$    Name of publication                                     
•  VolIssue,20                                                      
            $$    Volume and/or issue number of publication,              
                  if applicable                                           
•  Version, 4                                                       
            $$    Version of publication, if applicable                   
•  UserID,8                                                         
            $$    ID of user who was reading this publication             
•  CreditSpent,4,r                                                  
            $$    Credit spent, in dollars, on this publication           
______________________________________                                    
The distributed processing protocol (DPP) is used to reduce the processing load created by a particular task by distributing it over multiple computers. The protocol is used to search for and locate idle systems and (in conjunction with the CMXP protocol) transmit the appropriate code modules to those systems so that they can assist with the task. When the task is complete, the protocol is used to gather the results from all of the "assisting" machines and collect them and compile them on the machine that initiated the task.
The functionality provided by this protocol should not be confused with the load distribution functionality provided by the main MCMP protocol. The MCMP protocol's load distribution works by distributing client requests over various machines in various locations. The DPP protocol uses several machines working together to accomplish a single task, and is more suited to a local area network, and to processor intensive tasks, such as rendering of 3D images.
Each system involved in the distributed processing process must be configured with a list of those systems which can assist it with a task, as well as those systems which it can assist with tasks. This list can include entries with wildcards, to specify an entire network, such as 192.168.123.* for the entire 192.168.123. C-level network.
The purpose for this system configuration is to control who can utilize a system's processor. For example, a company might want to limit shared processing to systems within it's own internal network, for security reasons.
Systems can also be assigned priorities for access to a computer's processor. For example, a company may want all of it's computer to grant distributed processing requests from other computers on it's network in preference to other requests. However, if that company is affiliated with some other company, it might want to grant that other company access to it's computers for distributed processing purposes, provided that none of it's own computers require processing assistance.
The following is a list of the packet types used by the DPP protocol at this time. The functionality of the DPP protocol can be expanded in future by adding to this list of packet types.
______________________________________                                    
DPP.sub.-- AssistReq                                                      
            = 2   $$    Request for processing assistance                 
DPP.sub.-- AssistResp                                                     
            = 3   $$    Response to DPP.sub.-- AssistReq                  
DPP.sub.-- EndTaskReq                                                     
            = 4   $$    Request to terminate processing                   
                        assistance                                        
DPP.sub.-- EndTaskNotify                                                  
            = 5   $$    Notification of termination of assistance         
DPP.sub.-- UpdateReq                                                      
            = 6   $$    Request for update of task status                 
DPP.sub.-- UpdateResp                                                     
            = 7   $$    Response to UpdateReq                             
______________________________________                                    
These packet types are described in detail below.
REQUEST FOR PROCESSING ASSISTANCE (DPP-- AssistReq): This packet is sent by a system requiring processing assistance to another system to request processing assistance from that system. This packet contains all the information needed to initiate a distributed process, including the resource identifier for the initial code module to handle the process, so that the code module can be fetched via CMXP if necessary. The response to this packet is either a DPP-- AssistResp packet (if the recipient system can assist) or an MCMP Status packet (if the recipient system can not assist).
Possible reasons for an MCMP-- Status packet can include:
Access Denied
The system to which the packet was sent was not allowed to assist with the request. This is a result of the system generating the request not being listed in the appropriate configuration file on the receiving system.
Insufficient Free System Resources
There are not enough free system resources on the system receiving the request for that system to assist with the distributed process. In some cases, a system may be to busy to even return this status value.
Request Superceded
This indicates that the system had enough free processor time, but chose to assist a different system in preference to the one sending the request. The reason that Request Superceded is a separate status code from Access Denied is that "Access Denied" may generate an error if encountered by a program searching for systems to assist it (to notify the user of a possible mis-configuration) while Request Superceded would simply indicate that the system is not available to assist with the task at that given time, and would therefore not generate an error.
Task-Specific Error
This is resumed by the code module that would handle the task. The MCMP-- Status packet will contain an additional task-specific error code indicating the specific error which occurred. Task specific errors might include an error indicating that the system is not capable of assisting with the task due to a hardware limitation.
The packet body of the assistance request packet consists of a 32-byte header, followed by a task-specific data area, which contains any infommation that the code module referenced in the Resource ID requires to assist in the processing of the task. This could for example, include an image (if an image must be processed) or a description of a 3D environment to be rendered.
The task-specific data area also contains information indicating which portion of the task the system is to work on (for example, starting and ending lines in the image) as well as the frequency with which the assisting system is to update the initiating system with processed data.
The MCMP Header of the assistance request packet is:
PacketType: DPP-- AssistReq (hO002)
PacketSize: 32+Size of task-specific data
ResourceID's: One (The ID of the code module to handle the distributed process)
Shuntable: No
ResourceReq. No
The DPP-- AssistReq Header is:
______________________________________                                    
DPP.sub.-- AssistReq Hdr,32                                               
•  ProcessID,2                                                      
                    $$ Process Identifier                                 
•  ,30        $$ Reserved                                           
______________________________________                                    
The elements of the DPP-- AssistReq Header are described in detail below:
Process-ID: This is a 2-byte integer value that identifies the process. It is assigned by the system initiating the process, and is a unique identifier when combined with that system's IP address.
DPP-- AssistResp: This packet is sent in response to a DPP-- AssistReq to acknowledge that the system has begun assisting with the task Because this is simply an acknowledgement message, there are no Resource ID's and there is no packet body. The MCMP Header is:
PacketType: DPP-- AssistResp (h0003)
PacketSize: 0
ResourceID's: None
Shuntable: No
ResourceReq: No
DPP-- EndTaskReq: This packet is sent to an assisting system to instruct that system to cease assisting with a task prematurely (before the task is complete). This would be used, for example, if the user on the initiating system were to click a "cancel" button and abort the task. The MCMP Header is:
PacketType: DPP-- EndTaskReq (h0004)
PacketSize: 16
ResourceID's: One (The ID of the code module to handle the distributed process)
Shuntable: No
ResourceReq: No
The Packet Body of the end task request header is:
______________________________________                                    
DPP.sub.-- EndTaskReq,16                                                  
•  ProcessTD,2                                                      
                 $$ ID of process to terminate                            
•  ,14     $$ Reserved                                              
______________________________________                                    
DPP-- EndTaskNotify: This packet is sent by an assisting system to notify the initiating system that it will no longer be assisting with a task. This is used both by itself, and as an acknowledgement to a DPP-- EndTaskReq packet. This would be sent if, for example, the assisting system was to become too busy to continue to assist with the task, or if the assisting system was to be instructed by the initiating system to abort the task. This packet can also be used to notify an initiating system of a completed task. The MCMP Header is:
PacketType: DPP-- EndTaskNotify (h0005)
PacketSize: 16
ResourceID's: One (The ID of the code module to handle the distributed process)
Shuntable: No
ResourceReq: No
The Packet Body of the end task notification packet is:
______________________________________                                    
   DPP.sub.-- EndTaskResp,16                                              
•  ProcessID,2                                                      
          $$ ID of process to terminate                                   
•  Tstatus,1                                                        
          $$ Task status; 1=Complete, O=Incomplete (Aborted)              
•  ,13                                                              
          $$ Reserved                                                     
______________________________________                                    
DPP-- UpDateReq: This packet is sent by the initiating system to instruct the assisting system to transmit processed data (a DDP-- UpdateResp packet). For example, if an image was being processed, this would cause the assisting system to respond with the data making up the portion of the image that it has processed so far. The use of this packet type depends on the task. Some tasks will not use this packet at all, and will instead automatically generate DPP-- UpdateResp packets at various intervals, and when the task is complete. The MCMP Header is:
PacketType: DPP-- UpdateReq (h0006)
PacketSize: 16
ResourceID's: One (The ID of the code module to handle the distributed process)
Shuntable. No
ResourceReq No
The Packet Body of the update request packet is:
______________________________________                                    
DPP.sub.-- EndTaskResp,16                                                 
ProcessID,2                                                               
          $$ ID of process for which to return processed data             
•  ,14                                                              
          $$ Reserved                                                     
______________________________________                                    
DPP-- UpDateResp: This packet is sent from an assisting system to an initiating system. It contains the data that has been processed so far as part of the task in question. For example, if an image is being processed, this packet would contain the portion of the image that had already been processed. Note that the data sent in these packets in not cumulative. That is, if two packets are sent in succession, the second contains only data not included in the first.
These packets are often sent in response to DPP-- UpdateReq packets, although they can also be sent automatically by the program handling the task assistance, both during the task and upon task completion.
The packet body consists of a header, followed by task-specific data. All data not part of the header is assumed to be task-specific data.
The MCMP Header of the update response packet is:
PacketType: DPP-- UpdateResp (h0007)
PacketSize: 16+Size of task-specific data
ResourceID's: One (The ID of the code module to handle the distributed process)
Shuntable: No
ResourceReq: No
DPP-- UpdateResp Header is:
______________________________________                                    
DPP.sub.-- UpdateResp,16                                                  
•  HeaderSize,2                                                     
            $$    Size, in bytes, of DPP.sub.-- UpdateResp header         
•  ProcessID,2                                                      
            $$    ID of process for which to return processed             
                  data                                                    
•  ,12                                                              
            $$    Reserved                                                
______________________________________                                    
The term "code module" is used herein to denote a self-standing portion of an applications program dedicated to the performance of a specific operation of the applications program. For example, in a painting program, one code module may control the drawing of a line, while another code module implements the application of color and yet another code module is used for generating a geometrical figure such as a circle. These code modules are independent in that at least some of them are not required for executing any particular operation. Sometimes two or more modules are required to interact to produce a particular result. However, in no case are all modules required.
The term "machine-executable" as used herein refers to code modules which are program modules, capable of controlling computer operations and changing the state of the arithmetic logic circuits of a general purpose digital computer, thereby changing the functionality of the general purpose digital computer. Thus, "machine-executable code modules" do not include data files and other passive electronically encoded information.
The term "applications program" as used herein refers to any executable collection of computer code other than operating systems and other underlying programming for controlling basic machine functions. Thus, the Modularized Code Master Protocol, including its subprotocols, is an applications program which is itself modularized and transmittable in code modules over a network. For example, at least some subprotocols will not exist on some secondary servers. Should such a subprotocol be required for a secondary server to compete a task or process a user's request then that required subprotocol may be transmitted over the network from the primary server to the secondary server.
Subprotocols are handled by including a subprotocol identifier in the MCMP Header attached to each MCMP packet. On an MCMP server, the circuits for handling the subprotocols may be plug-in modules which are handled in real-time by the CMXP protocol. When an incoming packet is received, the appropriate subprotocol handler is called. The subprotocol handler can then process the packet in whatever way is required. A protocol handler becomes involved in the load distribution process because the MCMP server has no way of knowing what format the resources are in, how to transfer them between servers, or what the caching rules are. The subprotocol handler must deal with accessing, transfer, and caching of the protocol-specific resources. The subprotocol handlers are called periodically during the MCMP server's main processing loop, allowing it to perform various maintenance tasks. Alternatively, the subprotocol handler could be called from a loop running in a separate thread.
The handler for a specific subprotocol may request that the MCMP server flag a socket as being in a Proprietary Dialog Mode (PDM). On a PDM socket, all incoming data is passed directly to the subprotocol handler without being processed by the MCMP server. When a socket is returned to normal operation from the PDM operation, the subprotocol handler must pass any "extra" unprocessed data to the MCMP server, since it may have read a portion of one or more MCMP packets.
The term "primary server" or "source server" is used herein to denote the authoritative source for the resources relating to a particular application. For example, the primary server for the TenCORE Net Demo would be the server where the latest version of the demo was always posted.
The term "secondary server" as used herein denotes a server that receives service-handoffs from a primary server. A secondary server usually mirrors the content of the primary server for which it is secondary. For example, a secondary server for the TenCORE Net Demo would be a server that could take over servicing clients if the primary server became too busy. A secondary server does not necessarily contain mirrors of the resources for which it is secondary server, inasmuch as the secondary server can request these resources from the primary server as needed.
A single machine is can be both a primary server and a secondary server. For example, a machine could be primary server for the TenCORE Net Demo, and secondary server for the Country Closet Clothing Catalog.
A single machine can function as primary server for multiple applications, and can function as secondary server for multiple applications.
The word "resource" is used herein to denote any block of data that can be used by a server or client. A resource can be a file, a code module, a portion of a file, a code module, a portion of a code module. a file directory, a code module directory, or any related piece of information, including the CMXP Prohibited List. The term "resource" is also used to refer to hardware and system resources, such as processor time and memory.
The term "tree-file" refers to a Catharon Tree-Structure Nameset File. A tree-file contains a series of named sets of records, which are grouped and nested into a tree-like structure (similar to an operating system's file system). In tree files, names beginning with a percent sign "%" are reserved for internal use. Any other names may be used by whatever application is maintaining the tree-file. Currently, only one percent-sign name has been assigned. It is "\%System" and it contains general information about the file, including (optionally) the name of the application that created the file, the user under who's network account the file was last edited the date and time the file was last edited, the location of various resources in the file, the location of the default folder (if none specified), and the file's associated information.
As related hereinabove, TenCORE is an interpreted language which utilizes pseudocode. Interpreter programs suitable for use with the TenCORE programming language as modified in accordance with the above descriptions are in common use today.
A description of the TenCORE programming language is set forth a microfiche Appendix in the file for this application. The basic characteristics of the language are discussed first, then the treatment of variables. Finally, an exposition is made of all the important commands used in the language. From this information, as well as the foregoing description, one of ordinary skill in the art can generate a modular programming language suitable for use in the invention.
Although the invention has been described in terms of particular embodiments and applications, one of ordinary skill in the art, in light of this teaching, can generate additional embodiments and modifications without departing from the spirit of or exceeding the scope of the claimed invention. Accordingly, it is to be understood that the drawings and descriptions herein are proffered by way of example to facilitate comprehension of the invention and should not be construed to limit the scope thereof.

Claims (36)

What is claimed is:
1. A method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage, comprising:
storing an applications program in a nonvolatile memory of a first computer, said applications program being stored as a plurality of interacting individual and independent machine-executable code modules;
in response to a request from a second computer transmitted over a network link, retrieving a selected one of said machine-executable code modules and only said selected one of said machine-executable code modules from said memory; and
transmitting said selected one of said machine-executable code modules over said network link to said second computer.
2. The method defined in claim 1 wherein said first computer is a server computer on a network, said second computer being a secondary server on said network, further comprising, in response to a user request directed to said first computer, forwarding said user request from said first computer to said second computer to initiate processing of said user request by said second computer, said selected one of said machine-executable code modules being required by said second computer to process said user request.
3. The method defined in claim 2, further comprising:
storing, in a memory of said first computer, a list of secondary servers on said network, said list including response times for the respective secondary servers;
periodically updating said response times, said updating including (a) sending echo packets from said first computer to said secondary servers and (b) measuring, at said first computer delays between the sending of said echo packets and a receiving of responses to said echo packets from the respective secondary servers; and
selecting said second computer from among said secondary servers as the secondary server having the shortest response time.
4. The method defined in claim 1, further comprising:
storing a list of user authentification codes in said memory;
upon receiving said request from said second computer, comparing a user authentification code in said request with said list of user authentification codes in said memory;
proceeding with the retrieving and transmitting of said selected one of said machine-executable code modules only if the user authentification code in said request matches a user authentification code in said list.
5. The method defined in claim 4 wherein said request from said second computer is contained in an encryption packet, further comprising decrypting said encryption packet prior to the comparing of said user authentification code in said request with said list of user authentification codes in said memory.
6. The method defined in claim 1 wherein said request from said second computer is a second request directed to said first computer from said second computer, further comprising:
receiving a first request directed to said first computer from said second computer via said network link, said first request asking for transmission of a first version of a particular code module included in said machine-executable code modules;
transmitting, from said first computer to said second computer via said network link, a signal indicating that a more recent version of said particular code module is available, said selected one of said machine-executable code modules being said more recent version of said particular code module.
7. The method defined in claim 1 wherein said machine-executable code modules are written in a user-friendly programming code, further comprising translating said selected one of said code module at said second computer from said programming code into machine code directly utilizable by said second computer.
8. A method for optimally controlling storage and transfer of computer programs between computers on a network to facilitate interactive program usage, comprising:
storing a portion of an applications program in a first computer, said applications program comprising a plurality of interacting individual and independent machine-executable code modules, only some of said machine-executable code modules being stored in said first computer;
executing at least one of said machine-executable code modules on said first computer;
transmitting, to a second computer via a network link, a request for a further machine-executable code module of said applications program;
receiving said further machine-executable code module at said first computer from said second computer over said network link; and
executing said further machine-executable code module on said first computer.
9. The method defined in claim 8, further comprising:
sending a request from the first computer to a further computer for a list of servers on said network;
after transmission of said list of servers from said further computer to said first computer, determining response times for said servers by (a) sending echo packets from said first computer to said servers and (b) measuring, at said first computer, delays between the sending of said echo packets and a receiving of responses to said echo packets from the respective servers; and
selecting said second computer from among said servers as the server having the shortest response time, the transmitting of said request for said further machine-executable code module being executed after the selecting of said second computer.
10. The method defined in claim 8 wherein said request from said first computer is a second request directed to said second computer from said first computer, further comprising transmitting a first request from said first computer to said second computer via said network, said first request being for a first version of a particular machine-executable code module of said applications program, said second request being transmitted in response to a signal from said second computer indicating that a more recent version of said particular machine-executable code module is available, said second request being for said more recent version of said particular machine-executable code module.
11. The method defined in claim 8 wherein said second computer stores at least some of said machine-executable code modules of said applications program, said second computer executing at least one of said machine-executable code modules in response to the execution of a machine-executable code module by said first computer, whereby said first computer and said second computer engage in interactive processing via said network.
12. The method defined in claim 8 wherein said machine-executable code modules are written in a user-friendly programming code, further comprising translating said selected one of said code module at said second computer from said programming code into machine code utilizable by said second computer.
13. The method defined in claim 8 wherein said machine-executable code modules each incorporate an author identification, further comprising, in response to an instruction received by said first computer over said network and prior to executing said one of said machine-executable code modules on said first computer, determining whether the particular author identification incorporated in said one of said machine-executable code modules is an allowed identification and proceeding with the executing of said one of said machine-executable code modules only if said particular author identification is an allowable identification.
14. The method defined in claim 8 wherein the storing of said portion of said applications program in said first computer includes caching said code modules in a nonvolatile memory of said first computer.
15. The method defined in claim 8, further comprising transmitting a request from said first computer to said second computer for a machine-executable code module during an idle time on said first computer.
16. A computing system comprising:
digital processing circuitry;
a nonvolatile memory storing general operations programming and an applications program, said applications program including a plurality of interacting individual and independent machine-executable code modules, said memory being connected to said processing circuitry to enable access to said memory by said processing circuitry;
a communications link for communicating data and programs over a network to a remote computer; and
a code module exchange means operatively connected to said memory and to said communications link for retrieving a single code module from among said machine-executable code modules and transferring said single code module to said remote computer in response to a request for said single code module from said remote computer.
17. The computing system defined in claim 16 wherein said computing system is a server computer on said network.
18. The computing system define in claim 17 wherein said memory contains a list of secondary servers on said network, said list including response times for the respective secondary servers, further comprising:
detection means for detecting an overload condition of the computing system, and
server selection means operatively connected to said detection means, said memory and said communications link for determining which of said secondary servers has a shortest response time and for shunting an incoming user request to the secondary server with the shortest response time when said overload condition exists at a time of arrival of said user request.
19. The computing system defined in claim 18 wherein the secondary server to which said user request is shunted is said remote computer, said single code module being required for enabling said remote computer to process the user request.
20. The computing system defined in claim 18, further comprising updating means operatively connected to said memory and said communications link for (I) periodically sending echo packets to said secondary servers, (II) measuring delays between the sending of said echo packets and a receiving of responses to said echo packets from the respective secondary servers, and (III) updating the response times in said list in accordance with the measured delays.
21. The computing system defined in claim 17 wherein said network is the Internet.
22. The computing system defined in claim 16 wherein said memory contains a stored list of user authentification codes, further comprising comparison means for comparing a user authentification code in said request with said list of user authentification codes in said memory and for preventing code-module retrieval and transmission in the event that the user authentification code in said request fails to correspond to any user authentification code in said list.
23. The computing system defined in claim 22 wherein said request from said remote computer is contained in an encryption packet, further comprising means connected to said communications link and said comparison means for decrypting said encryption packet prior to the comparing of said user authentification code in said request with said list of user authentification codes in said memory.
24. The computing system defined in claim 16, further comprising means for determining whether a requested code module has an updated version and for responding to said request with an invitation to said remote computer to accept the updated version of the requested code module.
25. The computing system defined in claim 16 wherein said machine-executable code modules are written in a user-friendly programming code, further comprising an interpreter for translating said programming code into machine code directly utilizable by said processing circuitry.
26. A computing system comprising:
a first computer;
a second computer remotely located relative to said first computer;
communications links at said first computer and said second computer for tying said first computer and said second computer to one another over a network,
said first computer including a nonvolatile memory storing at least a portion of an applications program, said applications program including a plurality of interacting individual and independent machine-executable code modules,
each of the computers being provided with code module exchange means for cooperating with the code module exchange means of the other computer to transfer a single code module from among said machine-executable code modules from said first computer to said second computer.
27. The computing system defined in claim 26 wherein said first computer is a primary server and said second computer is a secondary server on said network, said first computer including detection means for detecting an overload condition of said first computer, said first computer further including shunting means operatively connected to said detection means and the communications link at said first computer for shunting an incoming user request to said second computer when said overload condition exists at a time of arrival of said user request.
28. The computing system defined in claim 27 wherein said first computer further includes updating means operatively connected to said memory and said communications link for (I) periodically sending echo packets to a plurality of secondary servers on said network, (II) measuring delays between the sending of said echo packets and a receiving of responses to said echo packets from the respective secondary servers, and (III) updating the response times in a list in said memory in accordance with the measured delays.
29. The computing system defined in claim 26 wherein said first computer is a server computer and said second computer is a user computer.
30. A computing system comprising:
a memory storing a portion of an applications program, said applications program comprising a plurality of interacting individual and independent machine-executable code modules, only some of said machine-executable code modules being stored in said memory;
digital processing circuitry operatively connected to said memory for executing at least one of said machine-executable code modules;
a communications link for communicating data and programs over a network to a remote computer; and
a code module exchange means operatively connected to said memory and to said communications link for communicating with a remote computer via a network link to obtain from said remote computer a further machine-executable code module of said applications program, said digital processing circuitry being operatively tied to said code module exchange means for executing said further machine-executable code module upon reception thereof from said remote computer.
31. The computing system defined in claim 30 wherein said computing system is a user computer on said network and said remote computer is a server computer.
32. The computing system defined in claim 31 wherein said memory contains a list of servers on said network, said list including response times for the respective servers, further comprising server selection means operatively connected to said memory and said code module exchange means for instructing said code module exchange means to communicate with a server selected from among said secondary servers as having a shortest response time, said remote computer being the selected server.
33. The computing system defined in claim 32, further comprising updating means operatively connected to said memory and said communications link for (I) periodically sending echo packets to said servers, (II) measuring delays between the sending of said echo packets and receiving of responses to said echo packets from the respective servers, and (III) updating the response times in said list in accordance with the measured delays.
34. The computing system defined in claim 30, further comprising a software modified circuit operatively connected to said code module exchange means for encrypting communications transmitted to said remote computer and for decrypting communications received from said remote computer.
35. The computing system defined in claim 30 wherein said machine-executable code modules are written in a user-friendly programming code, further comprising an interpreter for translating said programming code into machine code directly utilizable by said processing circuitry.
36. A method for distributing processing among computers on a computer network, comprising:
storing an applications program in a nonvolatile memory of a first computer, said applications program being stored as a plurality of interacting individual and independent machine-executable code modules;
executing portions of said applications program on said first computer;
transmitting a request over a network link to said first computer from a second computer not running at full capacity, said request being to take over a part of a work load of said first computer;
in response to said request from said second computer, selectively transmitting machine-executable code modules of said applications program from said first computer to said second computer over said network link, the transmitted code modules being less than all of the code modules of said applications program; and
operating said second computer to follow programming instructions in the transmitted code modules to assist said first computer in executing its work load.
US08/902,591 1997-07-29 1997-07-29 Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network Expired - Lifetime US6065046A (en)

Priority Applications (13)

Application Number Priority Date Filing Date Title
US08/902,591 US6065046A (en) 1997-07-29 1997-07-29 Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network
KR1020007001043A KR100345460B1 (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network
NZ502477A NZ502477A (en) 1997-07-29 1998-07-28 Transfer of computer applications as independent modules between computers via a network
CNB988094150A CN1232913C (en) 1997-07-29 1998-07-28 Computerized system and method for optimally controlling storage and transfer of computer programs on a computer network
IL13414198A IL134141A (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network
EP98938065A EP1010193A4 (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network
RU2000104864/09A RU2226711C2 (en) 1997-07-29 1998-07-28 Computer system and method for optimal control of computer program storage and transmission in computer network
CA002297069A CA2297069C (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network
BR9811593-6A BR9811593A (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling cashing and transfer of computer programs on a computer network (57) Patent: "Computerized system and associated method for optimally controlling cashing and transfer of computer programs computer on a computer network ". a computer system and associated method for optimally controlling the storage and transfer of computer programs between computers on a network and for facilitating the use of an interactive program. According to the method, an application program is stored in nonvolatile memory of a first computer as a plurality of individual and independent machine executable code modules. in response to a request from a second computer transmitted over a network connection, the first computer retrieves a selected module from said machine-executable code modules and only that selected code module from memory and transmits the code module selected by network connection to the second computer.
PCT/US1998/015627 WO1999007007A2 (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network
JP2000505645A JP2001512272A (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimal control of storage and transfer of computer programs over a computer network
AU86671/98A AU724513B2 (en) 1997-07-29 1998-07-28 Computerized system and associated method for optimally controlling storage and transfer of computer programs on a computer network
JP2008189095A JP2009009584A (en) 1997-07-29 2008-07-22 Method and system for controlling storage and transfer of computer program on computer network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US08/902,591 US6065046A (en) 1997-07-29 1997-07-29 Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network

Publications (1)

Publication Number Publication Date
US6065046A true US6065046A (en) 2000-05-16

Family

ID=25416079

Family Applications (1)

Application Number Title Priority Date Filing Date
US08/902,591 Expired - Lifetime US6065046A (en) 1997-07-29 1997-07-29 Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network

Country Status (12)

Country Link
US (1) US6065046A (en)
EP (1) EP1010193A4 (en)
JP (2) JP2001512272A (en)
KR (1) KR100345460B1 (en)
CN (1) CN1232913C (en)
AU (1) AU724513B2 (en)
BR (1) BR9811593A (en)
CA (1) CA2297069C (en)
IL (1) IL134141A (en)
NZ (1) NZ502477A (en)
RU (1) RU2226711C2 (en)
WO (1) WO1999007007A2 (en)

Cited By (100)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212521B1 (en) * 1997-09-25 2001-04-03 Fujitsu Limited Data management system, primary server, and secondary server for data registration and retrieval in distributed environment
US6279030B1 (en) * 1998-11-12 2001-08-21 International Business Machines Corporation Dynamic JAVA™ class selection and download based on changeable attributes
US6298339B1 (en) * 1997-12-19 2001-10-02 Telefonaktiebolaget Lm Ericsson (Publ) Management in data structures
US20010037399A1 (en) * 1998-07-22 2001-11-01 Dan Eylon Method and system for streaming software applications to a client
EP1158404A2 (en) * 2000-05-26 2001-11-28 Sharp Kabushiki Kaisha Server device and application communication system for proper communication of application divided into portions
WO2001095116A2 (en) * 2000-06-07 2001-12-13 Netbloom A/S A method and a system for providing information from a server to a client
US20020013832A1 (en) * 2000-03-30 2002-01-31 Hubbard Edward A. Software-based network attached storage services hosted on massively distributed parallel computing networks
US20020042833A1 (en) * 1998-07-22 2002-04-11 Danny Hendler Streaming of archive files
US20020087717A1 (en) * 2000-09-26 2002-07-04 Itzik Artzi Network streaming of multi-application program code
US6446218B1 (en) 1999-06-30 2002-09-03 B-Hub, Inc. Techniques for maintaining fault tolerance for software programs in a clustered computer system
US20020146118A1 (en) * 2001-02-14 2002-10-10 Disanto Frank J. Method and system for selecting encryption keys from a plurality of encryption keys
US6493870B1 (en) * 1998-03-20 2002-12-10 Sun Microsystems, Inc. Methods and apparatus for packaging a program for remote execution
US20030014480A1 (en) * 2001-07-16 2003-01-16 Sam Pullara Method and apparatus for session replication and failover
US20030014526A1 (en) * 2001-07-16 2003-01-16 Sam Pullara Hardware load-balancing apparatus for session replication
US20030018732A1 (en) * 2001-07-16 2003-01-23 Jacobs Dean Bernard Data replication protocol
US20030018825A1 (en) * 2001-07-17 2003-01-23 Johnson Hollis Bruce Methods and systems for providing platform-independent shared software components for mobile devices
US20030023898A1 (en) * 2001-07-16 2003-01-30 Jacobs Dean Bernard Layered architecture for data replication
US20030028583A1 (en) * 2001-07-31 2003-02-06 International Business Machines Corporation Method and apparatus for providing dynamic workload transition during workload simulation on e-business application server
US20030046230A1 (en) * 2001-08-30 2003-03-06 Jacobs Dean Bernard Method for maintaining account consistency
US20030101035A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Non-redundant collection of harvest events within a batch simulation farm network
US20030101041A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Annealing harvest event testcase collection within a batch simulation farm
US20030101039A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Maintaining data integrity within a distributed simulation environment
US20030101038A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Centralized disablement of instrumentation events within a batch simulation farm network
EP1324217A1 (en) * 2001-12-18 2003-07-02 Hewlett-Packard Company, A Delaware Corporation Process and cache system for providing an electronic service through a telecommunication network
US20030125915A1 (en) * 2001-11-30 2003-07-03 International Business Machines Corporation Count data access in a distributed simulation environment
US20030135354A1 (en) * 2001-11-30 2003-07-17 International Business Machines Corporation Tracking converage results in a batch simulation farm network
US20030163761A1 (en) * 2002-02-21 2003-08-28 Michael Chen System and method for message driven bean service migration
US6629103B1 (en) * 2000-11-02 2003-09-30 Oridus, Inc. Method for securely providing a text file for execution
US6633876B1 (en) * 2000-06-07 2003-10-14 Sun Microsystems, Inc. Analyzing post-mortem information on a remote computer system using a downloadable code module
US20030195920A1 (en) * 2000-05-25 2003-10-16 Brenner Larry Bert Apparatus and method for minimizing lock contention in a multiple processor system with multiple run queues
US20030212731A1 (en) * 2000-02-17 2003-11-13 Brenner Larry Bert Apparatus and method for periodic load balancing in a multiple run queue system
US20030229705A1 (en) * 2002-05-31 2003-12-11 Matsuno Yohichiroh Computer networking system, method of document retrieval in document management system, document management program and media for document management
US20040002046A1 (en) * 2000-09-21 2004-01-01 Cantor Michael B. Method for non- verbal assement of human competence
US6681390B2 (en) * 1999-07-28 2004-01-20 Emc Corporation Upgrade of a program
US20040030801A1 (en) * 2002-06-14 2004-02-12 Moran Timothy L. Method and system for a client to invoke a named service
US6704849B2 (en) * 2000-03-10 2004-03-09 Alcatel Process, data processing device, service provision server, back-up server and program modules for backing-up data
US20040103139A1 (en) * 2000-03-30 2004-05-27 United Devices, Inc. Distributed processing system having sensor based data collection and associated method
US20040109434A1 (en) * 1998-04-02 2004-06-10 Lg Electronics Inc. Method of communication between mobile station and base station in mobile communication system
US20040133444A1 (en) * 2002-09-20 2004-07-08 Florence Defaix Version control system for software development
US20040215829A1 (en) * 2000-03-30 2004-10-28 United Devices, Inc. Data conversion services and associated distributed processing system
US20050010664A1 (en) * 2000-03-30 2005-01-13 United Devices, Inc. Method of managing workloads and associated distributed processing system
US20050038937A1 (en) * 2003-08-13 2005-02-17 Intel Corporation Method and system for configuring network processing software to exploit packet flow data locality
US20050044206A1 (en) * 2001-09-07 2005-02-24 Staffan Johansson Method and arrangements to achieve a dynamic resource distribution policy in packet based communication networks
US20050066181A1 (en) * 1999-05-27 2005-03-24 Microsoft Corporation Method for watermarking computer programs
US20050108264A1 (en) * 2000-10-04 2005-05-19 Microsoft Corporation Web store events
US20050149532A1 (en) * 2000-03-30 2005-07-07 United Devices, Inc. Customer services and advertising based upon device attributes and associated distributed processing system
US20050171997A1 (en) * 2004-01-29 2005-08-04 Samsung Electronics Co., Ltd. Apparatus and method for processing characters in a wireless terminal
US20050192993A1 (en) * 2002-05-23 2005-09-01 Bea Systems, Inc. System and method for performing commutative operations in data access systems
US6944586B1 (en) * 1999-11-09 2005-09-13 Interactive Drama, Inc. Interactive simulated dialogue system and method for a computer network
US6978378B1 (en) * 2000-05-12 2005-12-20 Bluetie, Inc. Secure file transfer system
US20060004959A1 (en) * 2002-01-18 2006-01-05 Bea Systems, Inc. System and method for heterogeneous caching
US6988139B1 (en) * 2002-04-26 2006-01-17 Microsoft Corporation Distributed computing of a job corresponding to a plurality of predefined tasks
US20060123199A1 (en) * 2002-01-18 2006-06-08 Bea Systems, Inc. System and method for optimistic caching
US20060123066A1 (en) * 2001-08-30 2006-06-08 Bea Systems, Inc. Cluster caching with concurrency checking
US20060129872A1 (en) * 2002-02-22 2006-06-15 Fung Priscilla C Apparatus for highly available transaction recovery for transaction processing systems
US7089301B1 (en) * 2000-08-11 2006-08-08 Napster, Inc. System and method for searching peer-to-peer computer networks by selecting a computer based on at least a number of files shared by the computer
US20060195687A1 (en) * 2005-02-28 2006-08-31 International Business Machines Corporation System and method for mapping an encrypted HTTPS network packet to a specific URL name and other data without decryption outside of a secure web server
US20060271814A1 (en) * 2002-02-22 2006-11-30 Bea Systems, Inc. Method for highly available transaction recovery for transaction processing systems
US7162699B1 (en) 1999-04-02 2007-01-09 Massachusetts Institute Of Technology Mechanisms and artifacts to manage heterogeneous platform interfaces in a collaboration system
US7219122B1 (en) 2001-04-23 2007-05-15 Massachusetts Institute Of Technology Software service handoff mechanism with a performance reliability improvement mechanism (PRIM) for a collaborative client-server system
US20070147306A1 (en) * 2002-02-21 2007-06-28 Bea Systems, Inc. Systems and methods for migratable services
US7240096B1 (en) * 2002-09-30 2007-07-03 Bell South Intellectual Property Corp. System and method for providing service technicians access to dispatch information
US20070192320A1 (en) * 2001-08-30 2007-08-16 Bea Systems, Inc. System and Method for Flushing Bean Cache
US20070234270A1 (en) * 2006-03-31 2007-10-04 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Event evaluation using extrinsic state information
US20080059607A1 (en) * 1999-09-01 2008-03-06 Eric Schneider Method, product, and apparatus for processing a data request
US20080091726A1 (en) * 2006-10-16 2008-04-17 Bluetie, Inc. Methods for scheduling and completing reservations within an application and systems thereof
US20080097815A1 (en) * 2006-10-23 2008-04-24 Bluetie, Inc. Methods for employing temporary time zones and predictive locations and systems thereof
US20080098000A1 (en) * 2006-10-23 2008-04-24 Blue Tie, Inc. System and method for storing user data in a centralized database and intelligently reducing data entry
US20080120570A1 (en) * 2006-11-22 2008-05-22 Bluetie, Inc. Methods for managing windows within an internet environment and systems thereof
US20080195506A1 (en) * 2006-10-23 2008-08-14 Blue Tie, Inc. Systems and methods for automated purchase requests
US20080313293A1 (en) * 2001-09-06 2008-12-18 Bea Systems, Inc. System and method for exactly once message store communication
US20090132649A1 (en) * 2000-03-30 2009-05-21 Niration Network Group, L.L.C. Method of Managing Workloads and Associated Distributed Processing System
US20090138601A1 (en) * 2007-11-19 2009-05-28 Broadband Royalty Corporation Switched stream server architecture
US20090217310A1 (en) * 2008-02-25 2009-08-27 Blue Tie, Inc. Methods for integrating and managing one or more features in an application and systems thereof
US20090222508A1 (en) * 2000-03-30 2009-09-03 Hubbard Edward A Network Site Testing
US20090235247A1 (en) * 2008-03-14 2009-09-17 Samsung Electronics Co., Ltd. Apparatus and method for checking idle period of virtual machine, and computer readable recording medium for embodying the method
US7606924B2 (en) 1998-07-22 2009-10-20 Symantec Corporation Method and apparatus for determining the order of streaming modules
US20100161608A1 (en) * 2008-12-18 2010-06-24 Sumooh Inc. Methods and apparatus for content-aware data de-duplication
US7765543B1 (en) * 2003-12-17 2010-07-27 Vmware, Inc. Selective descheduling of idling guests running on a host computer system
US20100332556A1 (en) * 2004-02-27 2010-12-30 Teamon Systems, Inc. Communications system and method for accessing a server and preventing access blocking and minimizing network traffic
USRE42153E1 (en) 2000-03-30 2011-02-15 Hubbard Edward A Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US20110099267A1 (en) * 2009-10-27 2011-04-28 Vmware, Inc. Resource Optimization and Monitoring in Virtualized Infrastructure
US8005978B1 (en) * 2002-03-01 2011-08-23 Cisco Technology, Inc. Method to optimize the load balancing of parallel coprocessors
US20110225141A1 (en) * 2010-03-12 2011-09-15 Copiun, Inc. Distributed Catalog, Data Store, and Indexing
US20110231374A1 (en) * 2010-03-16 2011-09-22 Copiun, Inc. Highly Scalable and Distributed Data De-Duplication
US8056082B2 (en) 2006-05-31 2011-11-08 Bluetie, Inc. Capacity management and predictive planning systems based on trended rate change of monitored factors and methods thereof
US8234203B1 (en) 2000-05-12 2012-07-31 Adventive, Inc. E-commerce system including online automatable inventory monitor and control system
US8260924B2 (en) 2006-05-03 2012-09-04 Bluetie, Inc. User load balancing systems and methods thereof
US20140207652A1 (en) * 2000-08-22 2014-07-24 Ipreo Llc Method, apparatus and article-of-manufacture for managing and supporting initial public offerings and other financial issues
US20140236914A1 (en) * 2013-02-15 2014-08-21 Omron Corporation Controller, information processing apparatus, and recording medium
US20150039882A1 (en) * 2013-08-01 2015-02-05 International Business Machines Corporation Identifying content from an encrypted communication
US9059956B2 (en) 2003-01-31 2015-06-16 Good Technology Corporation Asynchronous real-time retrieval of data
US9141717B2 (en) 1999-03-22 2015-09-22 Esdr Network Solutions Llc Methods, systems, products, and devices for processing DNS friendly identifiers
US20150334194A1 (en) * 2002-12-02 2015-11-19 Sony Corporation Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program
US9400875B1 (en) 2005-02-11 2016-07-26 Nokia Corporation Content routing with rights management
US9621405B2 (en) 2010-08-24 2017-04-11 Good Technology Holdings Limited Constant access gateway and de-duplicated data cache server
US9767460B2 (en) 2006-09-18 2017-09-19 Adventive, Inc. Methods for integrating revenue generating features within a software application and systems thereof
US9854053B1 (en) * 2014-03-24 2017-12-26 Amazon Technologies, Inc. Providing faster data access using multiple caching servers
US9900286B2 (en) 2001-04-26 2018-02-20 Nokia Technologies Oy Device classification for media delivery
US11063882B2 (en) * 2019-08-07 2021-07-13 International Business Machines Corporation Resource allocation for data integration

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3511978B2 (en) 2000-05-18 2004-03-29 日本電気株式会社 Router with priority control function and machine-readable recording medium recording program
FR2824929B1 (en) * 2001-05-18 2003-08-08 Gemplus Card Int APPLICATION DEPLOYMENT FROM A CHIP CARD
EP1318451B1 (en) 2001-12-10 2004-10-06 Aladdin Knowledge Systems GmbH& Co. KG Method to execute a program on a computer
US8037515B2 (en) 2003-10-29 2011-10-11 Qualcomm Incorporated Methods and apparatus for providing application credentials
US7890946B2 (en) 2004-05-11 2011-02-15 Microsoft Corporation Efficient patching
US7559058B2 (en) 2004-05-11 2009-07-07 Microsoft Corporation Efficient patching
US8539469B2 (en) 2004-05-11 2013-09-17 Microsoft Corporation Efficient patching
JP4110557B2 (en) * 2005-06-21 2008-07-02 三菱電機株式会社 Inspection apparatus and programming system provided with program execution system
CN102566862B (en) * 2010-12-21 2014-08-27 汉王科技股份有限公司 Method and device for erasing geometric figures in interactive electronic whiteboard
WO2012127625A1 (en) * 2011-03-22 2012-09-27 富士通株式会社 Parallel computer, communication control device and method of controlling communication
KR101498700B1 (en) * 2013-09-23 2015-03-06 주식회사 플로우시스 Performance testing device of storage on vdi environment
JP6289882B2 (en) * 2013-11-26 2018-03-07 京セラ株式会社 Portable terminal device, download suppression method, and program
CN104363300B (en) * 2014-11-26 2018-06-05 浙江宇视科技有限公司 Task distribution formula dispatching device is calculated in a kind of server cluster
RU2609076C2 (en) * 2015-03-16 2017-01-30 Рамиль Ильдарович Хантимиров Method and system for smart control over distribution of resources in cloud computing environments
EP3418887A1 (en) * 2017-06-19 2018-12-26 Clarion Co., Ltd. Electronic device and program updating method
CN107786544B (en) * 2017-09-29 2018-08-17 贵州白山云科技有限公司 A kind of the task status processing method and system of message
CN109968359A (en) * 2019-03-28 2019-07-05 台州九牛慧联机器人技术有限公司 A kind of industrial robot control system
CN112328510B (en) * 2020-10-29 2022-11-29 上海兆芯集成电路有限公司 Advanced host controller and control method thereof
DE102022001652A1 (en) 2022-05-10 2022-08-25 Mercedes-Benz Group AG Method for providing a vehicle-based server and a vehicle
CN115185526B (en) * 2022-05-27 2023-10-10 韩济澎 Compiling system and method for programming language capable of reverse reasoning

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US4954941A (en) * 1988-08-31 1990-09-04 Bell Communications Research, Inc. Method and apparatus for program updating
US5329619A (en) * 1992-10-30 1994-07-12 Software Ag Cooperative processing interface and communication broker for heterogeneous computing environments
US5341477A (en) * 1989-02-24 1994-08-23 Digital Equipment Corporation Broker for computer network server selection
US5388211A (en) * 1989-04-28 1995-02-07 Softel, Inc. Method and apparatus for remotely controlling and monitoring the use of computer software
US5426427A (en) * 1991-04-04 1995-06-20 Compuserve Incorporated Data transmission routing system
US5473772A (en) * 1991-04-02 1995-12-05 International Business Machines Corporation Automatic update of static and dynamic files at a remote network node in response to calls issued by or for application programs
US5475813A (en) * 1994-07-18 1995-12-12 International Business Machines Corporation Routing transactions in the presence of failing servers
US5475819A (en) * 1990-10-02 1995-12-12 Digital Equipment Corporation Distributed configuration profile for computing system
US5497479A (en) * 1989-04-28 1996-03-05 Softel, Inc. Method and apparatus for remotely controlling and monitoring the use of computer software
US5544320A (en) * 1993-01-08 1996-08-06 Konrad; Allan M. Remote information service access system based on a client-server-service model
US5727950A (en) * 1996-05-22 1998-03-17 Netsage Corporation Agent based instruction system and method
US5732273A (en) * 1995-08-11 1998-03-24 Digital Equipment Corporation System for monitoring compute system performance
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US5819020A (en) * 1995-10-16 1998-10-06 Network Specialists, Inc. Real time backup system
US5828847A (en) * 1996-04-19 1998-10-27 Storage Technology Corporation Dynamic server switching for maximum server availability and load balancing
US5850449A (en) * 1995-10-26 1998-12-15 Sun Microsystems, Inc. Secure network protocol system and method

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1993020511A1 (en) * 1992-03-31 1993-10-14 Aggregate Computing, Inc. An integrated remote execution system for a heterogenous computer network environment
US5459837A (en) * 1993-04-21 1995-10-17 Digital Equipment Corporation System to facilitate efficient utilization of network resources in a computer network
CA2137488C (en) * 1994-02-18 1998-09-29 Richard I. Baum Coexecuting method and means for performing parallel processing in conventional types of data processing systems
US5630066A (en) * 1994-12-20 1997-05-13 Sun Microsystems, Inc. System and method for locating object view and platform independent object
US5692047A (en) * 1995-12-08 1997-11-25 Sun Microsystems, Inc. System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources
US5708709A (en) * 1995-12-08 1998-01-13 Sun Microsystems, Inc. System and method for managing try-and-buy usage of application programs

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US4954941A (en) * 1988-08-31 1990-09-04 Bell Communications Research, Inc. Method and apparatus for program updating
US5341477A (en) * 1989-02-24 1994-08-23 Digital Equipment Corporation Broker for computer network server selection
US5497479A (en) * 1989-04-28 1996-03-05 Softel, Inc. Method and apparatus for remotely controlling and monitoring the use of computer software
US5388211A (en) * 1989-04-28 1995-02-07 Softel, Inc. Method and apparatus for remotely controlling and monitoring the use of computer software
US5475819A (en) * 1990-10-02 1995-12-12 Digital Equipment Corporation Distributed configuration profile for computing system
US5473772A (en) * 1991-04-02 1995-12-05 International Business Machines Corporation Automatic update of static and dynamic files at a remote network node in response to calls issued by or for application programs
US5426427A (en) * 1991-04-04 1995-06-20 Compuserve Incorporated Data transmission routing system
US5329619A (en) * 1992-10-30 1994-07-12 Software Ag Cooperative processing interface and communication broker for heterogeneous computing environments
US5544320A (en) * 1993-01-08 1996-08-06 Konrad; Allan M. Remote information service access system based on a client-server-service model
US5475813A (en) * 1994-07-18 1995-12-12 International Business Machines Corporation Routing transactions in the presence of failing servers
US5732273A (en) * 1995-08-11 1998-03-24 Digital Equipment Corporation System for monitoring compute system performance
US5819020A (en) * 1995-10-16 1998-10-06 Network Specialists, Inc. Real time backup system
US5850449A (en) * 1995-10-26 1998-12-15 Sun Microsystems, Inc. Secure network protocol system and method
US5828847A (en) * 1996-04-19 1998-10-27 Storage Technology Corporation Dynamic server switching for maximum server availability and load balancing
US5727950A (en) * 1996-05-22 1998-03-17 Netsage Corporation Agent based instruction system and method
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network

Cited By (187)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212521B1 (en) * 1997-09-25 2001-04-03 Fujitsu Limited Data management system, primary server, and secondary server for data registration and retrieval in distributed environment
US6298339B1 (en) * 1997-12-19 2001-10-02 Telefonaktiebolaget Lm Ericsson (Publ) Management in data structures
US6493870B1 (en) * 1998-03-20 2002-12-10 Sun Microsystems, Inc. Methods and apparatus for packaging a program for remote execution
US7616592B2 (en) * 1998-04-02 2009-11-10 Lg Electronics Inc. Method of communication between mobile station and base station in mobile communication system
US20100074232A1 (en) * 1998-04-02 2010-03-25 In Tae Hwang Method of communication between mobile station and base station in mobile communication system
US20040109434A1 (en) * 1998-04-02 2004-06-10 Lg Electronics Inc. Method of communication between mobile station and base station in mobile communication system
US20100074184A1 (en) * 1998-04-02 2010-03-25 In Tae Hwang Method of communication between mobile station and base station in mobile communication system
US7907554B2 (en) 1998-04-02 2011-03-15 Lg Electronics Inc. Method of communication between mobile station and base station in mobile communication system
US7907553B2 (en) * 1998-04-02 2011-03-15 Lg Electronics Inc. Method of communication between mobile station and base station in mobile communication system
US7197570B2 (en) 1998-07-22 2007-03-27 Appstream Inc. System and method to send predicted application streamlets to a client device
US20020042833A1 (en) * 1998-07-22 2002-04-11 Danny Hendler Streaming of archive files
US7606924B2 (en) 1998-07-22 2009-10-20 Symantec Corporation Method and apparatus for determining the order of streaming modules
US20010037399A1 (en) * 1998-07-22 2001-11-01 Dan Eylon Method and system for streaming software applications to a client
US6279030B1 (en) * 1998-11-12 2001-08-21 International Business Machines Corporation Dynamic JAVA™ class selection and download based on changeable attributes
US9659070B2 (en) 1999-03-22 2017-05-23 S. Aqua Semiconductor, Llc Methods, systems, products, and devices for processing DNS friendly identifiers
US9141717B2 (en) 1999-03-22 2015-09-22 Esdr Network Solutions Llc Methods, systems, products, and devices for processing DNS friendly identifiers
US7162699B1 (en) 1999-04-02 2007-01-09 Massachusetts Institute Of Technology Mechanisms and artifacts to manage heterogeneous platform interfaces in a collaboration system
US7058813B2 (en) 1999-05-27 2006-06-06 Microsoft Corporation Method for watermarking computer programs
US20060123237A1 (en) * 1999-05-27 2006-06-08 Microsoft Corporation Method for Watermarking Computer Programs
US20050066181A1 (en) * 1999-05-27 2005-03-24 Microsoft Corporation Method for watermarking computer programs
US7231524B2 (en) 1999-05-27 2007-06-12 Microsoft Corporation Method for watermarking computer programs
US6446218B1 (en) 1999-06-30 2002-09-03 B-Hub, Inc. Techniques for maintaining fault tolerance for software programs in a clustered computer system
US6681390B2 (en) * 1999-07-28 2004-01-20 Emc Corporation Upgrade of a program
US8990347B2 (en) * 1999-09-01 2015-03-24 Esdr Network Solutions Llc Method, product, and apparatus for processing a data request
US20080059607A1 (en) * 1999-09-01 2008-03-06 Eric Schneider Method, product, and apparatus for processing a data request
US6944586B1 (en) * 1999-11-09 2005-09-13 Interactive Drama, Inc. Interactive simulated dialogue system and method for a computer network
US20030212731A1 (en) * 2000-02-17 2003-11-13 Brenner Larry Bert Apparatus and method for periodic load balancing in a multiple run queue system
US6993767B2 (en) * 2000-02-17 2006-01-31 International Business Machines Corporation System for preventing periodic load balancing if processor associated with lightest local run queue has benefited from idle processor load balancing within a determined time period
US6986140B2 (en) * 2000-02-17 2006-01-10 International Business Machines Corporation Method for determining idle processor load balancing in a multiple processors system
US20030225815A1 (en) * 2000-02-17 2003-12-04 Brenner Larry Bert Apparatus and method for periodic load balancing in a multiple run queue system
US6704849B2 (en) * 2000-03-10 2004-03-09 Alcatel Process, data processing device, service provision server, back-up server and program modules for backing-up data
US20100036723A1 (en) * 2000-03-30 2010-02-11 Hubbard Edward A Sweepstakes Incentive Model and Associated System
US20050010664A1 (en) * 2000-03-30 2005-01-13 United Devices, Inc. Method of managing workloads and associated distributed processing system
US20090216649A1 (en) * 2000-03-30 2009-08-27 Hubbard Edward A Capability Based Distributed Processing
US20020013832A1 (en) * 2000-03-30 2002-01-31 Hubbard Edward A. Software-based network attached storage services hosted on massively distributed parallel computing networks
US20090222508A1 (en) * 2000-03-30 2009-09-03 Hubbard Edward A Network Site Testing
US8010703B2 (en) 2000-03-30 2011-08-30 Prashtama Wireless Llc Data conversion services and associated distributed processing system
US7092985B2 (en) 2000-03-30 2006-08-15 United Devices, Inc. Method of managing workloads and associated distributed processing system
US8275827B2 (en) 2000-03-30 2012-09-25 Niration Network Group, L.L.C. Software-based network attached storage services hosted on massively distributed parallel computing networks
US10269025B2 (en) 2000-03-30 2019-04-23 Intellectual Ventures Ii Llc Monetizing network connected user bases utilizing distributed processing systems
US8249940B2 (en) 2000-03-30 2012-08-21 Niration Network Group, LLC Capability based distributed processing
US20090132649A1 (en) * 2000-03-30 2009-05-21 Niration Network Group, L.L.C. Method of Managing Workloads and Associated Distributed Processing System
US20090138551A1 (en) * 2000-03-30 2009-05-28 Niration Network Group, L.L.C. Method of Managing Workloads and Associated Distributed Processing System
US20040103139A1 (en) * 2000-03-30 2004-05-27 United Devices, Inc. Distributed processing system having sensor based data collection and associated method
US20090164533A1 (en) * 2000-03-30 2009-06-25 Niration Network Group, L.L.C. Method of Managing Workloads and Associated Distributed Processing System
USRE42153E1 (en) 2000-03-30 2011-02-15 Hubbard Edward A Dynamic coordination and control of network connected devices for large-scale network site testing and associated architectures
US20040215829A1 (en) * 2000-03-30 2004-10-28 United Devices, Inc. Data conversion services and associated distributed processing system
US20050149532A1 (en) * 2000-03-30 2005-07-07 United Devices, Inc. Customer services and advertising based upon device attributes and associated distributed processing system
US6978378B1 (en) * 2000-05-12 2005-12-20 Bluetie, Inc. Secure file transfer system
US8234203B1 (en) 2000-05-12 2012-07-31 Adventive, Inc. E-commerce system including online automatable inventory monitor and control system
US6981260B2 (en) * 2000-05-25 2005-12-27 International Business Machines Corporation Apparatus for minimizing lock contention in a multiple processor system with multiple run queues when determining the threads priorities
US20030195920A1 (en) * 2000-05-25 2003-10-16 Brenner Larry Bert Apparatus and method for minimizing lock contention in a multiple processor system with multiple run queues
US20010051916A1 (en) * 2000-05-26 2001-12-13 Masashi Shiomi Server device, terminal device, application communication system, application communication method and recording medium for recording application communication program, for proper communication of application divided into portions
AU779185B2 (en) * 2000-05-26 2005-01-13 Sharp Kabushiki Kaisha Server device, terminal device, application communication system, application communication method and recording medium for recording application communication program, for proper communication of application divided into portions
EP1158404A2 (en) * 2000-05-26 2001-11-28 Sharp Kabushiki Kaisha Server device and application communication system for proper communication of application divided into portions
EP1158404A3 (en) * 2000-05-26 2004-04-14 Sharp Kabushiki Kaisha Server device and application communication system for proper communication of application divided into portions
WO2001095116A3 (en) * 2000-06-07 2002-04-04 Netbloom As A method and a system for providing information from a server to a client
US6633876B1 (en) * 2000-06-07 2003-10-14 Sun Microsystems, Inc. Analyzing post-mortem information on a remote computer system using a downloadable code module
WO2001095116A2 (en) * 2000-06-07 2001-12-13 Netbloom A/S A method and a system for providing information from a server to a client
US20060218275A1 (en) * 2000-08-11 2006-09-28 Napster, Inc. System and method for searching peer-to-peer computer networks
US20060218274A1 (en) * 2000-08-11 2006-09-28 Napster, Inc. System and method for optimizing access to information in peer-to-peer computer networks
US7454480B2 (en) * 2000-08-11 2008-11-18 Napster, Inc. System and method for optimizing access to information in peer-to-peer computer networks
US7730178B2 (en) * 2000-08-11 2010-06-01 Napster, Inc. System and method for searching peer-to-peer computer networks
US7089301B1 (en) * 2000-08-11 2006-08-08 Napster, Inc. System and method for searching peer-to-peer computer networks by selecting a computer based on at least a number of files shared by the computer
US20140207652A1 (en) * 2000-08-22 2014-07-24 Ipreo Llc Method, apparatus and article-of-manufacture for managing and supporting initial public offerings and other financial issues
US20040002046A1 (en) * 2000-09-21 2004-01-01 Cantor Michael B. Method for non- verbal assement of human competence
US7165973B2 (en) * 2000-09-21 2007-01-23 Cantor Michael B Method for non-verbal assessment of human competence
US7051315B2 (en) * 2000-09-26 2006-05-23 Appstream, Inc. Network streaming of multi-application program code
US20020087717A1 (en) * 2000-09-26 2002-07-04 Itzik Artzi Network streaming of multi-application program code
US7433875B2 (en) * 2000-10-04 2008-10-07 Microsoft Corporation Web store events
US7451127B2 (en) 2000-10-04 2008-11-11 Microsoft Corporation Web store events
US20050108264A1 (en) * 2000-10-04 2005-05-19 Microsoft Corporation Web store events
US6629103B1 (en) * 2000-11-02 2003-09-30 Oridus, Inc. Method for securely providing a text file for execution
US20020146118A1 (en) * 2001-02-14 2002-10-10 Disanto Frank J. Method and system for selecting encryption keys from a plurality of encryption keys
US7254232B2 (en) * 2001-02-14 2007-08-07 Copytele, Inc. Method and system for selecting encryption keys from a plurality of encryption keys
US7219122B1 (en) 2001-04-23 2007-05-15 Massachusetts Institute Of Technology Software service handoff mechanism with a performance reliability improvement mechanism (PRIM) for a collaborative client-server system
US9900286B2 (en) 2001-04-26 2018-02-20 Nokia Technologies Oy Device classification for media delivery
US20030014526A1 (en) * 2001-07-16 2003-01-16 Sam Pullara Hardware load-balancing apparatus for session replication
US7409420B2 (en) 2001-07-16 2008-08-05 Bea Systems, Inc. Method and apparatus for session replication and failover
US7702791B2 (en) 2001-07-16 2010-04-20 Bea Systems, Inc. Hardware load-balancing apparatus for session replication
US20030023898A1 (en) * 2001-07-16 2003-01-30 Jacobs Dean Bernard Layered architecture for data replication
US20030014480A1 (en) * 2001-07-16 2003-01-16 Sam Pullara Method and apparatus for session replication and failover
US7571215B2 (en) * 2001-07-16 2009-08-04 Bea Systems, Inc. Data replication protocol
US20030018732A1 (en) * 2001-07-16 2003-01-23 Jacobs Dean Bernard Data replication protocol
WO2003009137A3 (en) * 2001-07-17 2003-07-24 Appforge Inc Methods and systems for providing platforms-independent shared software components for mobile devices
US6986148B2 (en) 2001-07-17 2006-01-10 Appforge, Inc. Methods and systems for providing platform-independent shared software components for mobile devices
WO2003009137A2 (en) * 2001-07-17 2003-01-30 Appforge, Inc. Methods and systems for providing platforms-independent shared software components for mobile devices
US20030018825A1 (en) * 2001-07-17 2003-01-23 Johnson Hollis Bruce Methods and systems for providing platform-independent shared software components for mobile devices
US20030028583A1 (en) * 2001-07-31 2003-02-06 International Business Machines Corporation Method and apparatus for providing dynamic workload transition during workload simulation on e-business application server
US20030046230A1 (en) * 2001-08-30 2003-03-06 Jacobs Dean Bernard Method for maintaining account consistency
US20070192320A1 (en) * 2001-08-30 2007-08-16 Bea Systems, Inc. System and Method for Flushing Bean Cache
US20060123066A1 (en) * 2001-08-30 2006-06-08 Bea Systems, Inc. Cluster caching with concurrency checking
US8176014B2 (en) 2001-08-30 2012-05-08 Oracle International Corporation System and method for providing a cache that stores entity beans and employs data invalidation
US7444333B2 (en) 2001-08-30 2008-10-28 Bea Systems, Inc. Cluster caching with concurrency checking
US20080313293A1 (en) * 2001-09-06 2008-12-18 Bea Systems, Inc. System and method for exactly once message store communication
US7921169B2 (en) 2001-09-06 2011-04-05 Oracle International Corporation System and method for exactly once message store communication
US20050044206A1 (en) * 2001-09-07 2005-02-24 Staffan Johansson Method and arrangements to achieve a dynamic resource distribution policy in packet based communication networks
US20030101041A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Annealing harvest event testcase collection within a batch simulation farm
US20030101039A1 (en) * 2001-10-30 2003-05-29 International Business Machines Corporation Maintaining data integrity within a distributed simulation environment
US7143019B2 (en) 2001-10-30 2006-11-28 International Business Machines Corporation Maintaining data integrity within a distributed simulation environment
US7092868B2 (en) 2001-10-30 2006-08-15 International Business Machines Corporation Annealing harvest event testcase collection within a batch simulation farm
US7085703B2 (en) 2001-11-30 2006-08-01 International Business Machines Corporation Count data access in a distributed simulation environment
US7143018B2 (en) 2001-11-30 2006-11-28 International Business Machines Corporation Non-redundant collection of harvest events within a batch simulation farm network
US20030101035A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Non-redundant collection of harvest events within a batch simulation farm network
US20030101038A1 (en) * 2001-11-30 2003-05-29 International Business Machines Corporation Centralized disablement of instrumentation events within a batch simulation farm network
US20030125915A1 (en) * 2001-11-30 2003-07-03 International Business Machines Corporation Count data access in a distributed simulation environment
US20030135354A1 (en) * 2001-11-30 2003-07-17 International Business Machines Corporation Tracking converage results in a batch simulation farm network
US7027971B2 (en) * 2001-11-30 2006-04-11 International Business Machines Corporation Centralized disablement of instrumentation events within a batch simulation farm network
US7359847B2 (en) 2001-11-30 2008-04-15 International Business Machines Corporation Tracking converage results in a batch simulation farm network
EP1324217A1 (en) * 2001-12-18 2003-07-02 Hewlett-Packard Company, A Delaware Corporation Process and cache system for providing an electronic service through a telecommunication network
US20030154265A1 (en) * 2001-12-18 2003-08-14 Eric Raffaele Process for executing a downloadable service through a telecommunication network, and cache system and service for doing the same
US20060123199A1 (en) * 2002-01-18 2006-06-08 Bea Systems, Inc. System and method for optimistic caching
US7328322B2 (en) 2002-01-18 2008-02-05 Bea Systems, Inc. System and method for optimistic caching
US7467166B2 (en) 2002-01-18 2008-12-16 Bea Systems, Inc. System and method for heterogeneous caching
US20070192334A1 (en) * 2002-01-18 2007-08-16 Bea Systems, Inc. System and Method for Heterogeneous Caching
US20060004959A1 (en) * 2002-01-18 2006-01-05 Bea Systems, Inc. System and method for heterogeneous caching
US20080097997A1 (en) * 2002-01-18 2008-04-24 Bea Systems, Inc. System and method for optimistic caching
US7403996B2 (en) 2002-02-21 2008-07-22 Bea Systems, Inc. Systems and methods for migratable services
US20030163761A1 (en) * 2002-02-21 2003-08-28 Michael Chen System and method for message driven bean service migration
US20070147306A1 (en) * 2002-02-21 2007-06-28 Bea Systems, Inc. Systems and methods for migratable services
US7392317B2 (en) 2002-02-21 2008-06-24 Bea Systems, Inc. Systems and methods for migratable services
US20060271814A1 (en) * 2002-02-22 2006-11-30 Bea Systems, Inc. Method for highly available transaction recovery for transaction processing systems
US20070136393A1 (en) * 2002-02-22 2007-06-14 Bea Systems, Inc. System for Highly Available Transaction Recovery for Transaction Processing Systems
US20060129872A1 (en) * 2002-02-22 2006-06-15 Fung Priscilla C Apparatus for highly available transaction recovery for transaction processing systems
US7406618B2 (en) 2002-02-22 2008-07-29 Bea Systems, Inc. Apparatus for highly available transaction recovery for transaction processing systems
US7380155B2 (en) 2002-02-22 2008-05-27 Bea Systems, Inc. System for highly available transaction recovery for transaction processing systems
US7620842B2 (en) 2002-02-22 2009-11-17 Bea Systems, Inc. Method for highly available transaction recovery for transaction processing systems
US8005978B1 (en) * 2002-03-01 2011-08-23 Cisco Technology, Inc. Method to optimize the load balancing of parallel coprocessors
US6988139B1 (en) * 2002-04-26 2006-01-17 Microsoft Corporation Distributed computing of a job corresponding to a plurality of predefined tasks
US20050192993A1 (en) * 2002-05-23 2005-09-01 Bea Systems, Inc. System and method for performing commutative operations in data access systems
US20080091683A1 (en) * 2002-05-23 2008-04-17 Bea Systems, Inc. System and method for performing commutative operations in data access systems
US7895153B2 (en) 2002-05-23 2011-02-22 Oracle International Corporation System and method for performing commutative operations in data access systems
US20030229705A1 (en) * 2002-05-31 2003-12-11 Matsuno Yohichiroh Computer networking system, method of document retrieval in document management system, document management program and media for document management
US20040030801A1 (en) * 2002-06-14 2004-02-12 Moran Timothy L. Method and system for a client to invoke a named service
US7680932B2 (en) * 2002-09-20 2010-03-16 Mks Inc. Version control system for software development
US20040133444A1 (en) * 2002-09-20 2004-07-08 Florence Defaix Version control system for software development
US7240096B1 (en) * 2002-09-30 2007-07-03 Bell South Intellectual Property Corp. System and method for providing service technicians access to dispatch information
US20150334194A1 (en) * 2002-12-02 2015-11-19 Sony Corporation Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program
US10749862B2 (en) * 2002-12-02 2020-08-18 Sony Corporation Control system and control method, method and apparatus for processing information, information processing terminal and method thereof, storage medium, and program
US9059956B2 (en) 2003-01-31 2015-06-16 Good Technology Corporation Asynchronous real-time retrieval of data
US20050038937A1 (en) * 2003-08-13 2005-02-17 Intel Corporation Method and system for configuring network processing software to exploit packet flow data locality
US7536674B2 (en) * 2003-08-13 2009-05-19 Intel Corporation Method and system for configuring network processing software to exploit packet flow data locality
US20100257524A1 (en) * 2003-12-17 2010-10-07 Vmware, Inc. Selective descheduling of idling guests running on a host computer system
US7765543B1 (en) * 2003-12-17 2010-07-27 Vmware, Inc. Selective descheduling of idling guests running on a host computer system
US8352944B2 (en) 2003-12-17 2013-01-08 Vmware, Inc. Selective descheduling of idling guests running on a host computer system
US20050171997A1 (en) * 2004-01-29 2005-08-04 Samsung Electronics Co., Ltd. Apparatus and method for processing characters in a wireless terminal
US9692638B2 (en) * 2004-02-27 2017-06-27 Blackberry Limited Communications system and method for accessing a server and preventing access blocking and minimizing network traffic
US20100332556A1 (en) * 2004-02-27 2010-12-30 Teamon Systems, Inc. Communications system and method for accessing a server and preventing access blocking and minimizing network traffic
US9400875B1 (en) 2005-02-11 2016-07-26 Nokia Corporation Content routing with rights management
US20060195687A1 (en) * 2005-02-28 2006-08-31 International Business Machines Corporation System and method for mapping an encrypted HTTPS network packet to a specific URL name and other data without decryption outside of a secure web server
US7657737B2 (en) * 2005-02-28 2010-02-02 International Business Machines Corporation Method for mapping an encrypted https network packet to a specific url name and other data without decryption outside of a secure web server
US20070257354A1 (en) * 2006-03-31 2007-11-08 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Code installation decisions for improving aggregate functionality
US8893111B2 (en) 2006-03-31 2014-11-18 The Invention Science Fund I, Llc Event evaluation using extrinsic state information
US20070234270A1 (en) * 2006-03-31 2007-10-04 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Event evaluation using extrinsic state information
US8260924B2 (en) 2006-05-03 2012-09-04 Bluetie, Inc. User load balancing systems and methods thereof
US8056082B2 (en) 2006-05-31 2011-11-08 Bluetie, Inc. Capacity management and predictive planning systems based on trended rate change of monitored factors and methods thereof
US9767460B2 (en) 2006-09-18 2017-09-19 Adventive, Inc. Methods for integrating revenue generating features within a software application and systems thereof
US20080091726A1 (en) * 2006-10-16 2008-04-17 Bluetie, Inc. Methods for scheduling and completing reservations within an application and systems thereof
US10430845B2 (en) 2006-10-23 2019-10-01 Adventive, Inc. Systems and methods for automated purchase requests
US20080098000A1 (en) * 2006-10-23 2008-04-24 Blue Tie, Inc. System and method for storing user data in a centralized database and intelligently reducing data entry
US20080097815A1 (en) * 2006-10-23 2008-04-24 Bluetie, Inc. Methods for employing temporary time zones and predictive locations and systems thereof
US20080195506A1 (en) * 2006-10-23 2008-08-14 Blue Tie, Inc. Systems and methods for automated purchase requests
US20080120570A1 (en) * 2006-11-22 2008-05-22 Bluetie, Inc. Methods for managing windows within an internet environment and systems thereof
US8301776B2 (en) * 2007-11-19 2012-10-30 Arris Solutions, Inc. Switched stream server architecture
US20090138601A1 (en) * 2007-11-19 2009-05-28 Broadband Royalty Corporation Switched stream server architecture
US20090217310A1 (en) * 2008-02-25 2009-08-27 Blue Tie, Inc. Methods for integrating and managing one or more features in an application and systems thereof
US9489177B2 (en) 2008-02-25 2016-11-08 Adventive, Inc. Methods for integrating and managing one or more features in an application and systems thereof
US20090235247A1 (en) * 2008-03-14 2009-09-17 Samsung Electronics Co., Ltd. Apparatus and method for checking idle period of virtual machine, and computer readable recording medium for embodying the method
US8589455B2 (en) 2008-12-18 2013-11-19 Copiun, Inc. Methods and apparatus for content-aware data partitioning
US20100161608A1 (en) * 2008-12-18 2010-06-24 Sumooh Inc. Methods and apparatus for content-aware data de-duplication
US20100161685A1 (en) * 2008-12-18 2010-06-24 Sumooh Inc. Methods and apparatus for content-aware data partitioning
US7925683B2 (en) 2008-12-18 2011-04-12 Copiun, Inc. Methods and apparatus for content-aware data de-duplication
WO2010080591A3 (en) * 2008-12-18 2010-09-30 Sumooh Inc. Methods and apparatus for content-aware data partitioning and data de-duplication
US8924534B2 (en) 2009-10-27 2014-12-30 Vmware, Inc. Resource optimization and monitoring in virtualized infrastructure
US20110099267A1 (en) * 2009-10-27 2011-04-28 Vmware, Inc. Resource Optimization and Monitoring in Virtualized Infrastructure
US9110915B2 (en) 2009-12-18 2015-08-18 Copiun, Inc. Highly scalable and distributed data de-duplication
US20110225141A1 (en) * 2010-03-12 2011-09-15 Copiun, Inc. Distributed Catalog, Data Store, and Indexing
US9135264B2 (en) 2010-03-12 2015-09-15 Copiun, Inc. Distributed catalog, data store, and indexing
US20110231374A1 (en) * 2010-03-16 2011-09-22 Copiun, Inc. Highly Scalable and Distributed Data De-Duplication
US8452739B2 (en) 2010-03-16 2013-05-28 Copiun, Inc. Highly scalable and distributed data de-duplication
US9621405B2 (en) 2010-08-24 2017-04-11 Good Technology Holdings Limited Constant access gateway and de-duplicated data cache server
US20140236914A1 (en) * 2013-02-15 2014-08-21 Omron Corporation Controller, information processing apparatus, and recording medium
US9413728B2 (en) * 2013-08-01 2016-08-09 Globalfoundries Inc. Identifying content from an encrypted communication
US20150039882A1 (en) * 2013-08-01 2015-02-05 International Business Machines Corporation Identifying content from an encrypted communication
US9854053B1 (en) * 2014-03-24 2017-12-26 Amazon Technologies, Inc. Providing faster data access using multiple caching servers
US10021210B1 (en) 2014-03-24 2018-07-10 Amazon Technologies, Inc. Providing faster data access using multiple caching servers
US11063882B2 (en) * 2019-08-07 2021-07-13 International Business Machines Corporation Resource allocation for data integration

Also Published As

Publication number Publication date
EP1010193A2 (en) 2000-06-21
KR20010022458A (en) 2001-03-15
CN1315018A (en) 2001-09-26
KR100345460B1 (en) 2002-07-26
IL134141A0 (en) 2001-04-30
IL134141A (en) 2004-06-20
JP2001512272A (en) 2001-08-21
EP1010193A4 (en) 2004-09-01
NZ502477A (en) 2002-07-26
JP2009009584A (en) 2009-01-15
CN1232913C (en) 2005-12-21
BR9811593A (en) 2002-01-22
WO1999007007A3 (en) 1999-05-14
WO1999007007A2 (en) 1999-02-11
AU8667198A (en) 1999-02-22
AU724513B2 (en) 2000-09-21
RU2226711C2 (en) 2004-04-10
CA2297069A1 (en) 1999-02-11
CA2297069C (en) 2002-05-07

Similar Documents

Publication Publication Date Title
US6065046A (en) Computerized system and associated method of optimally controlled storage and transfer of computer programs on a computer network
US6654888B1 (en) Installing and controlling trial software
US7574488B2 (en) Method and apparatus for peer-to-peer file sharing
US5758069A (en) Electronic licensing system
US8666933B2 (en) System and method for distributing assets to multi-tiered network nodes
US7447673B2 (en) Enterprise computer system
US6996599B1 (en) System and method providing multi-tier applications architecture
US5905860A (en) Fault tolerant electronic licensing system
US8650226B2 (en) System and method for transactional and fault-tolerant distribution of digital assets over multi-tiered computer networks
US7136857B2 (en) Server system and method for distributing and scheduling modules to be executed on different tiers of a network
US7890428B2 (en) Flexible licensing architecture for licensing digital application
AU740827B2 (en) Web request broker controlling multiple processes
JP5007301B2 (en) Separate download for electronic software download
US20130124695A1 (en) Mobility Device Method
JPH10269078A (en) Software distribution method, server device and client device
JPH06223040A (en) Software license management system
JPH10214297A (en) Closed-membership service system using internet, and method therefor
CA2204317A1 (en) Application software distributing system, application software distributing method and computer-readable medium storing application software distributing program
EP1798916B1 (en) Regulating an extensibility point's access to a wrapped e-mail message
JP3972593B2 (en) IDENTIFICATION INFORMATION MANAGEMENT DEVICE, COMPUTER DATA COMMUNICATION SYSTEM, AND PROGRAM
JP2004062864A (en) On-line shopping system using the internet
JP2001501332A (en) Distributed task execution system
JP2004005632A (en) Remote installing system using internet, and method thereof
JP2004005633A (en) Remote installation system using the internet, and method thereof

Legal Events

Date Code Title Description
AS Assignment

Owner name: CATHARON PRODUCTIONS, INC., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FEINBERG, MICHAEL A.;FEINBERG, MATTHEW A.;REEL/FRAME:008734/0405

Effective date: 19970728

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

REMI Maintenance fee reminder mailed
FPAY Fee payment

Year of fee payment: 12

SULP Surcharge for late payment

Year of fee payment: 11

AS Assignment

Owner name: CATHARON INTELLECTUAL PROPERTY, LLC., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CATHARON PRODUCTIONS, INC.;REEL/FRAME:030317/0813

Effective date: 20130205

AS Assignment

Owner name: CATHARON SOFTWARE CORPORATION, ARIZONA

Free format text: MERGER;ASSIGNOR:CATHERON PRODUCTIONS INC.;REEL/FRAME:033198/0359

Effective date: 20020312

Owner name: CATHARON INTELLECTUAL PROPERTY LLC, TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DUFRESNE, FRED;REEL/FRAME:033125/0975

Effective date: 20130205

Owner name: DUFRESNE, FRED, VIRGINIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CATHARON SOFTWARE CORPORATION;REEL/FRAME:033125/0924

Effective date: 20130109

IPR Aia trial proceeding filed before the patent and appeal board: inter partes review

Free format text: TRIAL NO: IPR2015-00651

Opponent name: FEDEX CORPORATE SERVICES, INC.

Effective date: 20150203

Free format text: TRIAL NO: IPR2015-00652

Opponent name: FEDEX CORPORATE SERVICES, INC.

Effective date: 20150203

AS Assignment

Owner name: CATHARON PRODUCTS INTELLECTUAL PROPERTY, LLC, PENN

Free format text: NUNC PRO TUNC ASSIGNMENT;ASSIGNOR:CATHARON INTELLECTUAL PROPERTY, LLC.;REEL/FRAME:036939/0146

Effective date: 20151030