Sharing objects over a network for something like computer games, surely there is prior art for this?

Data is shared over a network, having a plurality of network-connected terminals, each including a visual display processor, storage and memory. The memory is configured to store program instructions for equipping objects stored therein with attributes and for managing the duplication of the objects. The processor is configurable by the program instructions to perform the steps of equipping an object with attributes at a first of the network terminals; at a second of the network terminals, matching the object attributes of the first terminal with the attributes of an object amongst all of the objects stored in the second terminal; duplicating the object from the second terminal to the first terminal; at the first terminal, accessing data in the duplicated object using locally executed object instructions; and maintaining data consistency between the duplicated objects.

  • I'm not sure if it matters here, but there was a relatively short period of time when games were really designed for peer-to-peer and not client server. In 2001 there was some seminal work being done by Valve Corporation about lag (network latency compensation) which goes straight to the heart of sync'ing network objects, but is a client server issue. this appears to be specifically peer-to-peer and as such, i think the doom engine is probably the most relevant. multiplayer designed for dial-up didn't last too long. Jul 24, 2013 at 7:59

6 Answers 6


This is written so broadly that I think you could show prior art several ways

1) CVS (1990) or other version control system.

2) rsync (1996) or other network file synchronization tool. Maybe even UUCP.

or more in line with what I think the implied intent is

3) Maze War (1973) - first multiclient game where you can see your opponents on a minimap

4) Doom (December 10, 1993) - if nothing else, this definitely fits the bill


"Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access files over a network in a manner similar to how local storage is accessed."


NFS provides the necessary functionality to synchronize file attributes across multiple terminals as described in the patent.

NFS v4 was described in RFC 3010 (Shepler et al, Dec 2000) and is clearly a superset of the functionality described in this patent. https://www.rfc-editor.org/rfc/rfc3010


I think that this should count as prior art...


  • Not sure how an article published in 2012 is prior art for something filed in 2001?
    – David_001
    Jul 24, 2013 at 13:35

This appears a very common object-synchronisation issue, solved many years before this patent. I remember JavaSpaces being built on this - basically you can add an object into the "JavaSpace", and other processes (from a network, for example) can access this object and modify it etc., thus having synchronised versions of the object. Maybe this patent is deemed different as it has different copies of the object on each machine (?) - this is tenuous as any implementation of what I've just described would need to do this in some way.

JavaSpaces as described on Wikipedia:

JavaSpaces is a service specification providing a distributed object exchange and coordination mechanism (which may or may not be persistent) for Java objects. It is used to store the distributed system state and implement distributed algorithms. In a JavaSpace, all communication partners (peers) communicate and coordinate by sharing state.

I'm not sure when JavaSpaces was released, but it's at least 1999.


Oracle Coherence is a distributed object cache and does exactly what the patent describes (and more).

Tangosol Coherence 1.0 was released on 28th of December 2001, but they had been working on it for some time and had almost certainly created a prototype by the time of this patent. Tangosol and Coherence is now owned by Oracle, who may be keen to help quash this patent.


This sounds like what TCP does to ensure that packets get received. This is way old. (May 1974?)


"Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost data, rearranges out-of-order data, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the receiving application. Thus, TCP abstracts the application's communication from the underlying networking details."

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .