Showing papers on "Upload published in 1990"

Method and apparatus for remotely controlling and monitoring the use of computer software

Abstract: Remote control of the use of computer data is described in a system for renting computer software which derives use and billing information, prevents unauthorized use, maintains integrity of the software and controls related intercomputer communications. A user at a target computer "downloads" programs or data, via a telephone line and remote control modules, from a host computer. Usage of the programs or data by the target computer or other accounting data are recorded and stored and, at predetermined times, the host computer "uploads" the usage data for processing. Other features include: (1) software and usage security for rental programs; (2) a polynomial generator/checker for generating block check characters for assuring integrity of data transmitted and received; (3) a voice-data switch for switching between data communication and normal telephone communication; and (4) an audio amplifier and speaker for monitoring of activity on the communication line during data transfers.

Experiences with the Amoeba distributed operating system

Abstract: The Amoeba project is a research effort aimed at understanding how to connect multiple computers in a seamless way [16, 17, 26, 27, 31]. The basic idea is to provide the users with the illusion of a single powerful timesharing system, when, in fact, the system is implemented on a collection of machines, potentially distributed among several countries. This research has led to the design and implementation of the Amoeba distributed operating system, which is being used as a prototype and vehicle for further research. In this article we will describe the current state of the system (Amoeba 4.0), and show some of the lessons we have learned designing and using it over the past eight years. We will also discuss how this experience has influenced our plans for the next version, Amoeba 5.0.Amoeba was originally designed and implemented at the Vrije Universiteit in Amsterdam, and is now being jointly developed there and at the Centrum voor Wiskunde en Informatica, also in Amsterdam. The chief goal of this work is to build a distributed system that is transparent to the users. This concept can best be illustrated by contrasting it with a network operating system, in which each machine retains its own identity. With a network operating system, each user logs into one specific machine—his home machine. When a program is started, it executes on the home machine, unless the user gives an explicit command to run it elsewhere. Similarly, files are local unless a remote file system is explicitly mounted or files are explicitly copied. In short, the user is clearly aware that multiple independent computers exist, and must deal with them explicitly.In contrast, users effectively log into a transparent distributed system as a whole, rather than to any specific machine. When a program is run, the system—not the user—decides upon the best place to run it. The user is not even aware of this choice. Finally, there is a single, system-wide file system. The files in a single directory may be located on different machines, possibly in different countries. There is no concept of file transfer, uploading or downloading from servers, or mounting remote file systems. A file's position in the directory hierarchy has no relation to its location.The remainder of this article will describe Amoeba and the lessons we have learned from building it. In the next section, we will give a technical overview of Amoeba as it currently stands. Since Amoeba uses the client-server model, we will then describe some of the more important servers that have been implemented so far. This is followed by a description of how wide-area networks are handled. Then we will discuss a number of applications that run on Amoeba. Measurements have shown Amoeba to be fast, so we will present some of our data. After that, we will discuss the successes and failures we have encountered, so that others may profit from those ideas that have worked out well and avoid those that have not. Finally we conclude with a very brief comparison between Amoeba and other systems.Before describing the software, however, it is worth saying something about the system architecture on which Amoeba runs.

Remote gaming system playable by several participants

Abstract: A game of skill or chance playable by several participants remote from each other in conjunction with a common event, such as a computer game, provides the basic format or template of the game on a floppy disk suitable for use with the remote users' personal computers. Then by connection to a mass communications one way channel, such as an FM SCA channel, variations in the game parameters and characteristics are broadcast at the same time to all of the individual remote players. These characteristics both initialize characteristics of the game and when the game is being played, provide updated playing parameters. A score can later be uploaded to the central station by, for example, telephone lines or any other convenient means.

Method of evaluating data

Abstract: A method of determining the winners of, for example, a game of skill in conjunction with a football or baseball game (24) without the input of all the scores is provided. By the use of statistical sampling a small fraction of the remote players upload their scores to a central station (16) via a telephone line (23), for example. Then, when the tentative winners (52) are determined from this small statistical sample, the mass communications link (19) of the system downloads the statistical curve to all of the players and only those players who are equal or better than the winning score (53) telephone. Thus, time and money are saved for the telephone up-link. Furthermore, overcrowding of the telephone system is avoided by a proper delay (47) given the individual remote sources (11).

Validating GPS software and implications for the future

Abstract: An overview of the GPS (global positioning system) is provided. Details are presented on the navigation message that is utilized by GPS user equipment (UE) to provide the user his position, time, and velocity. In order to reduce the adverse impact on GPS users of hosting a new software (S/W) release (OR 5.10) on the operational computer at the Master Control Station System, a multiphased test plan was developed to thoroughly test the S/W end-to-end prior to space vehicle uploads. Test objectives and results are provided for Phase-I test. The Phase-I report has been completed with test results, recommendations, and conclusions. One of the recommendations centered on improving the test configuration such that correlation of upload and UE data could be performed in near real time. A series of options for such a system testbed (STB) were evaluated. For each option, the pros, cons, and rough order of magnitude costs were identified. A potential STB configuration was recommended. It is concluded that no evidence exists to suggest that OR 5.10 will adversely affect the GPS user community with uploads as old as 11 d. >

IDB: an integrated image database system on local area network

Abstract: This work addresses the problem of managing a huge amount of digital color images. It focuses the possibility to store and retrieve them to make them available for a wide range of application. Key point of the architecture that has been designed and implemented is the distribution of the devices needed by an image system on several nodes of a Local Area Network. Optical disks are used to store the large amount of data required by images. To efficiently access a high number of images, an image data base is provided. All textual information, such as image descriptions, image characteristics, physical data allocation and archive devices, are managed by a relational data base placed on a host system connected to the LAN by a channel attachment. A particular attention has been paid in designing the user interlace: the user interacts with the system through a workstation (PS/2) without taking care of the related processes even if they involve remote resources. The user interlace is "window driven". It is oriented to a non DP professional and it does not require any documentation. The main peculiarities of the architecture are: distributed functions, multi-user environment, interactivity, modularity and non-procedurality (the user has only to describe "what" has to be done, rather than "how" to do it).© (1990) COPYRIGHT SPIE--The International Society for Optical Engineering. Downloading of the abstract is permitted for personal use only.