A forum for the support of robust mechanisms of evidence of ownership for intellectual property expressed in any medium

Briefing
Home
Manifesto
FAQs
Examples
Finer Points
Scheme
Methods
Server Demo
White Papers
References
Support
Overview
Downloads
Contact Us

Scheme

Below is how a network of registration servers would respond to an individual wishing to register a document 'my document'. The owner of the document has chosen to register with 'yellow' server. The digest of 'my document' is created on the owner's computer and this is forwarded to 'yellow' for adding to its currently open log segment (6). Once the server has added the entry to segment 6 it responds by sending a receipt back to the owner. The owner keeps this with the original document in order to be able to assert that the document existed at the time it was registered with 'yellow'.

 

Later and independently, 'yellow' server decides that segment 6 is long enough or old enough that it needs to be closed and registered in its own right. The operators of 'yellow' have decided to use 'green' to cross-register with. When it closes segment 6 it calculates the digest of the segment and registers this with 'green' and itself. To do the latter it needs to open a new segment (7) into which the new registration is added. The receipts from both 'yellow' and 'green' are recorded by 'yellow' in its record of registration receipts, just as would be done by a private user, except that the these receipts are publicly accessible.

Server 'green' sees the request to register from 'yellow' just as it would from any other client, public or private. However, its policy is to register with 'yellow' and 'blue' (as well as itself) when it closes a log segment. Similarly, 'blue' registers with itself and 'yellow'.

So, in the example illustrated, the digest of 'my document' has affected the content of 'yellow', 'green' and 'blue' servers. Indeed, for 'yellow' it has affected segment 7 from at least two sources before it is closed. This type of 'knotting' means that post-hoc alteration of registration data is practically difficult to do, not least because there is no formal relationship between the server operators. Because the data is all on open view, such 'failures' could be detected quite quickly and cause reputational (trust) damage.

See the live demonstration to see this in action first hand. Also, there are application examples showing how the scheme enhances trust between users.

Back to Top


© 2009 probity.org