WO2008065346A2 - Secure messaging and data sharing - Google Patents

Abstract

This invention describes a system of messaging where identity is validated to prevent spam. The system further uses this identity to allow digitally validated document signing. Added to this is the fact that these accounts are created from a very good known source of personal account information. This need not be a public account and can be a private account as in a maidsafe.net account. A unique method of contracted communications is also integral to this invention. This describes a communications facility where a digital contract is digitally signed and the conversation is subject to the contract terms.

Description

ms Messenger

STATEMENT OF INVENTION:

This present invention relates to secure and non refutable messengering. Unlike today's systems such as email and instant messenger this system is fully distributed. Today's systems have many weaknesses such as centralised authentication, poorly maintained and quite complex mail servers. This system seeks to remove this issue by removing the cause, centralisation. Added to this, this present invention introduces another completely new concept, contracted non refutable electronic conversations. The system will allow the selection of existing contracts or allow the user to input his own and then request signatories from all involved in the conversation, allowing a legally protected (in many countries) conversation to take place. This conversation could be a selling, purchasing or merely business deal or indeed any other issue requiring legal protection.

Another important aspect of this system is that the login details are not from this system per say, the system uses anonymously logged in clients who can create a key pair and ID for the messenger. This means any potential theft of ID is made extremely difficult

BACKGROUND: AUTHENTICATION Authentication servers are for user and data transaction authentication e.g. JP2005311545 which describe a system wherein the application of 'a digital seal' to electronic documents conforms to the Electronic Signature Act. This is similar to the case of signing paper documents but uses the application of an electronic signature through an electronic seal authentication system. The system includes: client computers, to each of which a graphics tablet is connected; an electronic seal authentication server and a PKI authentication server, plus the electronic seal authentication server. US2004254894 discloses an automated system for the confirmed efficient authentication of an anonymous subscriber's profile data in this case.

JP2005339247 describes a server based one time ID system and uses a portable terminal. US2006136317 discloses bank drop down boxes and suggests stronger protection by not transmitting any passwords or IDs. Patent US2006126848 discloses a server centric and deals with a one time password or authentication phrase and is not for use on a distributed network. Patent US2002194484 discloses a distributed network where all chunks are not individually verified and where the manifest is only re-computed after updates to files and hashes are applied and are for validation only.

SELF-AUTHENTICATION This is mostly used in biometric (WO2006069158). System for generating a patch file from an old version of data which consists of a series of elements and a new version of data which also consists of a series of elements US2006136514). Authentication servers (therefore not a distributed networking principle as per this invention) are commonly used (JP2006107316, US2005273603, EP1548979). However, server and client exchange valid certificates can be used (US2004255037). Instead of server, uses of information exchange system (semantic information) by participant for authentication can be used (JP2004355358), again this semantic information is stored and referenced unlike this present invention. Concepts of identity-based cryptography and threshold secret sharing provides for a distributed key management and authentication. Without any assumption of pre-fixed trust relationship between nodes, the ad hoc network works in a self-organizing way to provide the key generation and key management service, which effectively solves the problem of single point of failure in the traditional public key infrastructure (PKI)-supported system (US2006023887). Authenticating involves encryption keys for validation (WO2005055162) These are validated against known users unlike the present invention. Also, for authentication external housing are used (WO2005034009). All of these systems require a lost or (whether distributed or not) record of authorised users and pass phrases or certificates and therefore do not represent prior art.

Ranking, hashing for authentication can be implemented step-by-step and empirical authentication of devices upon digital authentication among a plurality of devices. Each of a plurality of authentication devices can unidirectionally generate a hash value of a low experience rank from a hash value of a high experience rank, and receive a set of high experience rank and hash value in accordance with an experience. In this way, the authentication devices authenticate each other's experience ranks (US2004019788). This is a system of hashing access against known identities and providing a mechanism of effort based access. This present invention does not rely or use such mechanisms.

QUICK ENCIPHERING This is another method for authentication (JP2001308845). SeIf- verifying certificate for computer system, uses private and public keys - no chunking but for trusted hardware subsystems (US2002080973) this is a mechanism of self signing certificates for authentication, again useful for effort based computing but not used in this present invention. Other authentication modes are, device for exchanging packets of information (JP2001186186), open key certificate management data 82 (JP10285156), and certification for authentication (WO96139210).

83 Authentication for Peer to Peer system is demonstrated by digital rights

84 management (US2003120928). Digital rights management and CSC

85 (part of that patent s a DRM container) issues which are based on

86 ability to use rather than gaining access to network or resources and

87 therefore not prior art.

88 Known self-healing techniques are divided broadly into two classes.

89 One is a centralized control system that provides overall rerouting

90 control from the central location of a network. In this approach, the

91 rerouting algorithm and the establishing of alarm collection times

92 become increasingly complex as the number of failed channels

93 increases, and a substantial amount of time will be taken to collect

94 alarm signals and to transfer rerouting information should a large

95 number of channels of a multiplexed transmission system fail. The other

96 is a distributed approach in which the rerouting functions are provided

97 by distributed points of the network. The following papers on distributed

98 rerouting approach have been published: (these are all related to self

99 healing but from a network pathway perspective and therefore are not

100 prior art for this invention which deals with data or data chunks self

101 healing mechanisms.

102 Document 1: W. D. Graver, "The Selfhealing Network", Proceedings of

103 Grobecom '87, November 1987.

104 Document 2: H. C. Yang and S. Hasegawa, "Fitness: Failure

105 Immunization Technology For Network Service Survivability",

106 Proceedings of Globecom '88, December 1988.

107 Document 3: H. R. Amirazizi, "Controlling Synchronous Networks With

108 Digital Cross-Connect Systems", Proceedings of Globecom '88,

109 December 1988. 110 Document 1 is concerned with a restoration technique for failures in a

111 single transmission system, and Document 2 relates to a "multiple-

112 wave" approach in which route-finding packets are broadcast in multiple

113 wave fashion in search of a maximum bandwidth until alternate routes

114 having the necessary bandwidth are established. One shortcoming of

115 this multiple wave approach is that it takes a long recovery time.

116 Document 3 also relates to fault recovery for single transmission

117 systems and has a disadvantage in that route-finding packets tend to

118 form a loop and hence a delay is likely to be encountered.

119 SECURITY & ENCRYPTION

120 Common email communications of sensitive information is in plain text

121 and is subject to being read by unauthorized code on the senders

122 system, during transit and by unauthorized code on the receiver's

123 system. Where there is a high degree of confidentially required, a

124 combination of hardware and software secures data.

125 A high degree of security to a computer or several computers

126 connected to the Internet or a LAN as disclosed in US2002099666.

127 Hardware system is used which consists of a processor module, a

128 redundant non-volatile memory system, such as dual disk drives, and

129 multiple communications interfaces. This type of security system must

130 be unlocked by a pass phrase to access data, and all data is

131 transparently encrypted, stored, archived and available for encrypted

132 backup. A system for maintaining secure communications, file transfer

133 and document signing with PKI, and a system for intrusion monitoring

134 and system integrity checks are provided, logged and selectively

135 alarmed in a tamper-proof, time-certain manner.

136 ENCRYPTION

137 WO2005093582 discloses method of encryption where data is secured

138 in the receiving node via private tag for anonymous network browsing.

139 However, other numerous encryption methods are also available such 140 as (i) implantation of Reed Solomon algorithm (WO02052787), which

141 ensures data is coded in parabolic fashion for self-repairing and

142 storage, (ii) storage involves incremental backup (WO02052787), (ii)

143 uses stenographic (US2006177094), (iv) use cipher keys (CN1620005),

144 encryption for non text (US2006107048) and US2005108240 discloses

145 user keys and randomly generated leaf node keys. The present

146 invention uses none of these methods of encryption and in particular

147 ensures all chunks are unique and do not point to another for security

148 (an issue with Reed Solomon and N + K implementations of parabolic

149 coding)

150 ENCRYPTED DOCUMENT SIGNING

151 WO2005060152 discloses a digital watermark representing the one-

152 way hash is embedded in a signature document is used for electronic

153 signing. Mostly encrypted document signing is associated with legal

154 documents, e.g. on-line notary etc. e.g. US2006161781 , signature

155 verification (US6381344). WO0182036 discloses a system and method

156 for signing, storing, and authenticating electronic documents using

157 public key cryptography. The system comprises a document service

158 computer cluster connected to user computers, document owner server

159 computers, and registration computers via a network such as for

160 example, the internet or the world wide web. WO0013368 discloses

161 both the data object and the signature data are encrypted. None of

162 these systems are designed or allow for distributed signing networks

163 unlike the present invention.

164 US6912660 discloses a method for parallel approval of an electronic

165 document. A document authentication code (DAC 0) is generated,

166 linked to the original document. Subsequent approvals of the document

167 generate a DAC x related to that specific approval. This is not linked to

168 the present invention as it's a document approval system - i.e. one

169 which allows a document to have multiple signatories to authenticate

170 approval, the present invention does not do this at all. 171 US6098056 discloses a system and method for controlling access

172 rights to and security of digital content in a distributed information

173 system, e.g., Internet. The network includes at least one server coupled

174 to a storage device for storing the limited access digital content

175 encrypted using a random-generated key, known as a Document

176 Encryption Key (DEK). The DEK is further encrypted with the server's

177 public key, using a public/private key pair algorithm and placed in a

178 digital container stored in a storage device and including as a part of the

179 meta-information which is in the container. The client's workstation is

180 coupled to the server (one of the many differences from the present

181 invention) for acquiring the limited access digital content under the

182 authorized condition. A Trusted Information Handler (TIH) is validated

183 by the server after the handler provides a data signature and type of

184 signing algorithm to transaction data descriptive of the purchase

185 agreement between the client and the owner. After the handler has

186 authenticated, the server decrypts the encrypted DEK with its private

187 key and re-encrypts the DEK with the handler's public key ensuring that

188 only the information handler can process the information. The encrypted

189 DEK is further encrypted with the client's public key personalizing the

190 digital content to the client. The client's program decrypts the DEK with

191 his private key and passes it along with the encrypted content to the

192 handler which decrypts the DEK with his private key and proceeds to

193 decrypt the content for displaying to the client.

194 US5436972 discloses a method for preventing inadvertent betrayal by a

195 trustee of escrowed digital secrets. After unique identification data

196 describing a user has been entered into a computer system, the user is

197 asked to select a password to protect the system. US5557518 discloses

198 a system to open electronic commerce using trusted agents.

199 US5557765 discloses a system and method for data recovery. An

200 encrypting user encrypts a method using a secret storage key (KS) and 201 attaches a Data Recovery Field (DRF), including an Access Rule Index

202 (ARI) and the KS to the encrypted message.

203 US5590199 discloses a system for authenticating and authorizing a

204 user to access services on a heterogeneous computer network. The

205 system includes at least one workstation and one authorization server

206 connected to each other through a network.

207 US2006123227 and WO0221409 describe trust based effort measuring

208 techniques to validate signatures without the requirement for a central

209 body or central messaging entity. This is an interesting new concept but

210 not used in the current invention.

Summary of Invention

211 The main embodiments of this invention are as follows:

212 A messaging system which has the functional elements of:

213 1. Provision of Public ID

214 2. Encrypted Communications

215 3. Document Signing

216 4. Contract conversations

217 ... with the additionally linked functional elements of:

218 1. Share Maps

219 2. Interface with Non-Anonymous Systems

220 3. Provision Key Pairs

221 4. Proven Individual

222 5. Validation of Vote Being Used 223 This present invention relates to secure and non refutable

224 messengering. Unlike today's systems such as email and instant

225 messenger this system is fully distributed. Today's systems have many

226 weaknesses such as centralised authentication, poorly maintained and

227 quite complex mail servers, this system seeks to remove this issue by

228 removing the cause, centralisation. Added to this, this present invention

229 introduces another completely new concept, contracted non refutable

230 electronic conversations. The system will allow the selection of existing

231 contracts or allow the user to input his own and then request signatories

232 from all involved in the conversation, allowing a legally protected (in

233 many countries) conversation to take place. This conversation could be

234 a selling, purchasing or merely business deal or indeed any other issue

235 requiring legal protection.

236 Another important aspect of this system is that the login details are not 237 from this system per say, the system uses anonymously logged in 238 clients who can create a key pair and ID for the messenger. This means 239 any potential theft of ID is made extremely difficult.

240 A system of secure and non refutable message sending in a distributed

241 and peer to peer network

242 A product for a secure and non refutable message sending in a

243 distributed and peer to peer network

244 A system of secure and non refutable message sending in a distributed

245 and peer to peer network is made up of inter linkage all or some of the

246 following elements:

247 a. contract conversations

248 b. document signing

249 c. encrypted communication

250 d. provision of public ID 251 A system of secure and non refutable message sending in a distributed

252 and peer to peer network is made up of inter linkage all or some of the

253 following elements and sub-elements:

254 a. contract conversations

255 b. document signing

256 i. provision of key pairs

257 c. encrypted communication

258 i. share maps

259 d. provision of public ID

260 i. provision of key pairs

261 ii. proven individuals

262 iii. interface with anonymous system

263 A product for a secure and non refutable message sending in a

264 distributed and peer to peer network is made up of inter linkage all or

265 some of the following elements:

266 a. contract conversations

267 b. document signing

268 c. encrypted communication

269 d. provision of public ID

270 A product for a secure and non refutable message sending in a

271 distributed and peer to peer network is made up of inter linkage all or

272 some of the following elements and sub-elements:

273 a. contract conversations

274 b. document signing

275 i. provision of key pairs

276 c. encrypted communication

277 i. share maps 278 d. provision of public ID

279 i. provision of key pairs

280 ii. proven individuals

281 iii. interface with anonymous system

282 A product for message sending in a distributed server less environment

283 comprising of;

284 a. create a distributed messaging system with secure message

285 buffering;

286 b. create a system of non repudiation between parties;

287 c. create a system of public ID created from private ID and linked by#

288 A method for above product and system of secure and non refutable

289 message sending in a distributed and peer to peer network

290 A method for above product and system of message sending in a

291 distributed server less environment comprising of;

292 a. create a distributed messaging system with secure message

293 buffering;

294 b. create a system of non repudiation between parties;

295 c. create a system of public ID created from private ID and linked by

296 user.

297 From above method further enhance security by passing join requests

298 between users securely over a secure medium and encrypted.

299 The method from above wherein the steps to contact another node is

300 carried out by a signed message indicating the wish to communicate

301 which may comprise of;

302 a. a signed message with private information contained in it or; 303 b. a signed message with previously known information contained in

304 it or;

305 c. a signed message with a previously agreed code.

306 A method from above where a contract may be agreed to and signed

307 prior to a conversation taking place; the conversation is then governed

308 by this contract and may include, but not be limited to;

309 a. Non disclosure agreements

310 b. Full disclosure agreements

311 c. Purchase orders.

312 A method of above where to create a public ID the user has to prove or

313 be spawned as an active participant in another network where

314 resources are stored and utilised to provide an effort based ranking

315 mechanism.

316 A method of above where a user may provide another user with a

317 digitally signed equivalent of a 'power of attorney' to agree contracts on

318 their behalf.

319 A method of above where messaging activity is ranked by peers and

320 the rank transmitted in conversation requests.

321 A method of above where the Public ID may also indicate a

322 biometrically signed user.

323 A method of above where users may require a ranking or effort score of

324 a certain level before allowing another node to communicate with them.

325 A method of above where this 'power of attorney¹ can be instantly

326 withdrawn by originating user without permission or requiring of

327 acceptance by receiver or the 'power of attorney'. DESCRIPTION

Detailed Description:

328 (References to IDs used in descriptions of the system's functionality)

329 MID - this is the base ID and is mainly used to store and forget files.

330 Each of these operations will require a signed request. Restoring may

331 simply require a request with an ID attached.

332 PMID - This is the proxy mid which is used to manage the receiving of

333 instructions to the node from any network node such as get/ put / forget

334 etc. This is a key pair which is stored on the node - if stolen the key pair

335 can be regenerated simply disabling the thiefs stolen PMID - although

336 there's not much can be done with a PMID key pair.

337 CID - Chunk Identifier, this is simply the chunkid.KID message on the

338 net.

339 TMID - This is today's ID a one time ID as opposed to a one time

340 password. This is to further disguise users and also ensure that their MID

341 stays as secret as possible.

342 MPID - The maidsafe.net public ID. This is the ID to which users can add

343 their own name and actual data if required. This is the ID for messenger,

344 sharing, non anonymous voting and any other method that requires we

345 know the user.

346 MAID - this is basically the hash of and actual public key of the MID. this

347 ID is used to identify the user actions such as put / forget / get on the

348 maidsafe.net network. This allows a distributed PKI infrastructure to exist

349 and be automatically checked. 350 KID - Kademlia ID this can be randomly generated or derived from

351 known and preferably anonymous information such as an anonymous

352 public key hash as with the MAID.. In this case we use kademlia as the

353 example overlay network although this can be almost any network

354 environment at all.

355 MSID - maidsafe.net Share ID, an ID and key pair specifically created for

356 each share to allow users to interact with shares using a unique key not

357 related to their MID which should always be anonymous and separate.

Anonymous Authentication Description

358 Anonymous authentication relates to system authentication and, in

359 particular, authentication of users for accessing resources stored on a

360 distributed or peer-to-peer file system. Its aim is to preserve the

361 anonymity of the users and to provide secure and private storage of data

362 and shared resources for users on a distributed system. It is a method of

363 authenticating access to a distributed system comprising the steps of;

364 • Receiving a user identifier;

365 • Retrieving an encrypted validation record identified by the user

366 identifier;

367 • Decrypting the encrypted validation record so as to provide

368 decrypted information; and ...

369 • Authenticating access to data in the distributed system using the

370 decrypted information.

371 Receiving, retrieving and authenticating may be performed on a node in

372 the distributed system preferably separate from a node performing the

373 step of decrypting. The method further comprises the step of generating

374 the user identifier using a hash. Therefore, the user identifier may be

375 considered unique (and altered if a collision occurs) and suitable for 376 identifying unique validation records. The step of authenticating access

377 may preferably further comprise the step of digitally signing the user

378 identifier. This provides authentication that can be validated against

379 trusted authorities. The method further comprises the step of using the

380 signed user identifier as a session passport to authenticate a plurality of

381 accesses to the distributed system. This allows persistence of the

382 authentication for an extended session.

383 The step of decrypting preferably comprises decrypting an address in the

384 distributed system of a first chunk of data and the step of authenticating

385 access further comprises the step of determining the existence of the first

386 chunk at the address, or providing the location and names of specific

387 data elements in the network in the form of a data map as previously

388 describe. This efficiently combines the tasks of authentication and

389 starting to retrieve the data from the system. The method preferably

390 further comprises the step of using the content of the first chunk to obtain

391 further chunks from the distributed system. Additionally the decrypted

392 data from the additional chunks may contain a key pair allowing the user

393 at that stage to sign a packet sent to the network to validate them or

394 additionally may preferable self sign their own id.

395 Therefore, there is no need to have a potentially vulnerable record of the

396 file structure persisting in one place on the distributed system, as the

397 user's node constructs its database of file locations after logging onto the

398 system.

399 There is provided a distributed system comprising;

400 • a storage module adapted to store an encrypted validation record;

401 • a client node comprising a decryption module adapted to decrypt an

402 encrypted validation record so as to provide decrypted information;

403 and

404 • a verifying node comprising: 405 • a receiving module adapted to receive a user identifier;

406 • a retrieving module adapted to retrieve from the storage module an

407 encrypted validation record identified by the user identifier;

408 • a transmitting module adapted to transmit the encrypted validation

409 record to the client node; and

410 • an authentication module adapted to authenticate access to data in

411 the distributed file system using the decrypted information from the

412 client node.

413 The client node is further adapted to generate the user identifier using a

414 hash. The authentication module is further adapted to authenticate

415 access by digitally sign the user identifier. The signed user identifier is

416 used as a session passport to authenticate a plurality of accesses by the

417 client node to the distributed system. The decryption module is further

418 adapted to decrypt an address in the distributed system of a first chunk of

419 data from the validation record and the authentication module is further

420 adapted to authenticate access by determining the existence of the first

421 chunk at the address. The client node is further adapted to use the

422 content of the first chunk to obtain further authentication chunks from the

423 distributed system.

424 There is provided at least one computer program comprising program

425 instructions for causing at least one computer to perform. One computer

426 program is embodied on a recording medium or read-only memory,

427 stored in at least one computer memory, or carried on an electrical

428 carrier signal.

429 Additionally there is a check on the system to ensure the user is login

430 into a valid node (software package). This will preferably include the

431 ability of the system to check validity of the running maidsafe.net

432 software by running content hashing or preferably certificate checking of

433 the node and also the code itself. Linked elements for ms Messenger (Figure 1 - PT6)

434 The Anonymous Authentication invention consists of 4 key functional

435 elements, with a further 4 functional elements being linked with.

436 The key functional elements are:

437 P17 - Provision of Public ID

438 P18 - Encrypted Communications

439 P19 - Document Signing

440 P20 - Contract Conversations

441 The linked functional elements are:

442 P16 - Share Maps

443 P23 - Interface with Anonymous Systems

444 P13 - Provision of Key Pairs

445 P26 - Proven Individual

446 P28 - Validation of Vote Being Used 447

448 The ms messenger (PT6) itself is made up from linkage of elements,

449 provision of public ID (P 17), preferably encrypted communication (P18)

450 and preferably provides document signing (P19) and contract

451 conversations (P20) to provide a system of messaging where identity is

452 validated to prevent spam. The system further uses this identity and key

453 pair to allow digitally validated document signing. In addition, provision of

454 public ID element (P17) is dependent on sub-element provision of key

455 pairs (P13) and preferably generate sub-element share maps (P26), sub-

456 element proven individual (P26) and sub-element interface with non- 457 anonymous systems (P23). Preferably the encrypted communication

458 element (P18) generates sub-element share maps (P16) and initiates the

459 validation process (P28) and document signing element (P19) is

460 preferably dependent on sub-element provision of key pairs (P 13) Self Authentication Detail (Figure 2)

461 1. A computer program consisting of a user interface and a chunk server (a

462 system to process anonymous chunks of data) should be running, if not

463 they are started when user selects an icon or other means of starting the

464 program.

465 2. A user will input some data known to them such as a userid (random ID)

466 and PIN number in this case. These pieces of information may be

467 concatenated together and hashed to create a unique (which may be

468 confirmed via a search) identifier. In this case this is called the MID

469 (maidsafe.net ID)

470 3. A TMID (Today's MID) is retrieved from the network, the TMID is then

471 calculated as follows:

472 The TMID is a single use or single day ID that is constantly changed.

473 This allows maidsafe.net to calculate the hash based on the user ID pin

474 and another known variable which is calculable. For this variable we use

475 a day variable for now and this is the number of days since epoch

476 (01/01/1970). This allows for a new ID daily, which assists in maintaining

477 the anonymity of the user. This TMID will create a temporary key pair to

478 sign the database chunks and accept a challenge response from the

479 holder of these db chunks. After retrieval and generation of a new key

480 pair the db is put again in new locations - rendering everything that was

481 contained in the TMID chunk useless. The TMID CANNOT be signed by

482 anyone (therefore hackers can't BAN an unsigned user from retrieving

483 this - in a DOS attack)- it is a special chunk where the data hash does

484 NOT match the name of the chunk (as the name is a random number

485 calculated by hashing other information (i.e. its a hash of the TMID as

486 described below) 487 • take dave as user ID and 1267 as pin.

488 • dave + (pin) 1267 = dave1267 Hash of this becomes MID

489 • day variable (say today is 13416 since epoch) = 13416

490 • so take pin, and for example add the number in where the pin states

491 i.e.

492 • 613dav41e1267

493 • (6 at beginning is going round pin again)

494 • so this is done by taking 1st pin 1 - so put first day value at position 1

495 • then next pin number 2 - so day value 2 at position 2

496 • then next pin number 6 so day value 3 at position 6

497 • then next pin number 7 so day value 4 at position 7

498 • then next pin number is 1 so day value 5 at position 1 (again)

499 • so TMID is hash of 613dav41e1267 and the MID is simply a hash of

500 dave1267

501 (This is an example algorithm and many more can be used to enforce

502 further security.)

503 4. From the TMID chunk the map of the user's database (or list of files

504 maps) is identified. The database is recovered from the net which

505 includes the data maps for the user and any keys passwords etc.. The

506 database chunks are stored in another location immediately and the old

507 chunks forgotten. This can be done now as the MID key pair is also in

508 the database and can now be used to manipulate user's data.

509 5. The maidsafe.net application can now authenticate itself as acting for

510 this MID and put get or forget data chunks belonging to the user. 511 6. The watcher process and Chunk server always have access to the PMID

512 key pair as they are stored on the machine itself, so can start and

513 receive and authenticate anonymous put / get / forget commands.

514 7. A DHT ID is required for a node in a DHT network this may be randomly

515 generated or in fact we can use the hash of the PMID public key to

516 identify the node.

517 8. When the users successfully logged in he can check his authentication

518 validation records exist on the network. These may be as follows:

MAID (maidsafe.net anonymous ID)

519 1. This is a data element stored on net and preferably named with the hash

520 of the MID public Key.

521 2. It contains the MID public key + any PMID public keys associated with

522 this user.

523 3. This is digitally signed with the MID private key to prevent forgery.

524 4. Using this mechanism this allows validation of MID signatures by

525 allowing any users access to this data element and checking the

526 signature of it against any challenge response from any node pertaining

527 to be this MID (as only the MID owner has the private key that signs this

528 MID) Any crook could not create the private key to match to the public

529 key to digitally sign so forgery is made impossible given today's

530 computer resources.

531 5. This mechanism also allows a user to add or remove PMIDS (or chunk

532 servers acting on their behalf like a proxy) at will and replace PMID's at 533 any time in case of the PMID machine becoming compromised.

534 Therefore this can be seen as the PMID authentication element.

PMID (Proxy MID)

535 1. This is a data element stored on the network and preferably named with

536 the hash of the PMID public key.

537 2. It contains the PMID public key and the MID ID (i.e. the hash of the MID

538 public key) and is signed by the MID private key (authenticated).

539 3. This allows a machine to act as a repository for anonymous chunks and

540 supply resources to the net for a MID.

541 4. When answering challenge responses any other machine will confirm the

542 PMID by seeking and checking the MIAD for the PMID and making sure

543 the PMID is mentioned in the MAID bit - otherwise the PMID is

544 considered rouge.

545 5. The key pair is stored on the machine itself and may be encoded or

546 encrypted against a password that has to be entered upon start-up

547 (optionally) in the case of a proxy provider who wishes to further

548 enhance PMID security.

549 6. The design allows for recovery from attack and theft of the PMID key pair

550 as the MAID data element can simply remove the PMID ID from the

551 MAID rendering it unauthenticated.

552 Figure 3 illustrates, in schematic form, a peer-to-peer network in

553 accordance with an embodiment of the invention; and 554 Figure 4 illustrates a flow chart of the authentication, in accordance with

555 a preferred embodiment of the present invention.

556 With reference to Figure 3, a peer-to-peer network 2 is shown with nodes

557 4 to 12 connected by a communication network 14. The nodes may be

558 Personal Computers (PCs) or any other device that can perform the

559 processing, communication and/or storage operations required to

560 operate the invention. The file system will typically have many more

561 nodes of all types than shown in Figure 3 and a PC may act as one or

562 many types of node described herein. Data nodes 4 and 6 store chunks

563 16 of files in the distributed system. The validation record node 8 has a

564 storage module 18 for storing encrypted validation records identified by a

565 user identifier.

566 The client node 10 has a module 20 for input and generation of user

567 identifiers. It also has a decryption module 22 for decrypting an encrypted

568 validation record so as to provide decrypted information, a database or

569 data map of chunk locations 24 and storage 26 for retrieved chunks and

570 files assembled from the retrieved chunks.

571 The verifying node 12 has a receiving module 28 for receiving a user

572 identifier from the client node. The retrieving module 30 is configured to

573 retrieve from the data node an encrypted validation record identified by

574 the user identifier. Alternatively, in the preferred embodiment, the

575 validation record node 8 is the same node as the verifying node 12, i.e.

576 the storage module 18 is part of the verifying node 12 (not as shown in

577 Figure 3). The transmitting module 32 sends the encrypted validation

578 record to the client node. The authentication module 34 authenticates

579 access to chunks of data distributed across the data nodes using the

580 decrypted information.

581 With reference to Figure 4, a more detailed flow of the operation of the

582 present invention is shown laid out on the diagram with the steps being 583 performed at the User's PC (client node) on the left 40, those of the

584 verifying PC (node) in the centre 42 and those of the data PC (node) on

585 the right 44.

586 A login box is presented 46 that requires the user's name or other detail

587 Preferably email address (the same one used in the client node software

588 installation and registration process) or simply name (i.e. nickname) and

589 the user's unique number, preferably PIN number. If the user is a 'main

590 user' then some details may already be stored on the PC. If the user is a

591 visitor, then the login box appears.

592 A content hashed number such as SHA (Secure Hash Algorithm),

593 Preferably 160 bits in length, is created 48 from these two items of data.

594 This 'hash' is now known as the 'User ID Key' (MID), which at this point is

595 classed as 'unverified' within the system. This is stored on the network as

596 the MAID and is simply the hash of the public key containing an

597 unencrypted version of the public key for later validation by any other

598 node. This obviates the requirement for a validation authority

599 The software on the user's PC then combines this MID with a standard

600 'hello' code element 50, to create 52 a 'hello.packet'. This hello.packet is

601 then transmitted with a timed validity on the Internet.

602 The hello.packet will be picked up by the first node (for this description,

603 now called the 'verifying node') that recognises 54 the User ID Key

604 element of the hello.packet as matching a stored, encrypted validation

605 record file 56 that it has in its storage area. A login attempt monitoring

606 system ensures a maximum of three responses. Upon to many attempts,

607 the verifying PC creates a 'black list' for transmission to peers.

608 Optionally, an alert is returned to the user if a 'black list' entry is found

609 and the user may be asked to proceed or perform a virus check. 610 The verifying node then returns this encrypted validation record file to the

611 user via the internet. The user's pass phrase 58 is requested by a dialog

612 box 60, which then will allow decryption of this validation record file.

613 When the validation record file is decrypted 62, the first data chunk

614 details, including a 'decrypted address', are extracted 64 and the user PC

615 sends back a request 66 to the verifying node for it to initiate a query for

616 the first 'file-chunk ID' at the 'decrypted address' that it has extracted

617 from the decrypted validation record file, or preferably the data map of

618 the database chunks to recreate the database and provide access to the

619 key pair associated with this MID.

620 The verifying node then acts as a 'relay node' and initiates a 'notify only'

621 query for this 'file-chunk ID' at the 'decrypted address'.

622 Given that some other node (for this embodiment, called the 'data node')

623 has recognised 68 this request and has sent back a valid 'notification

624 only' message 70 that a 'file-chunk ID' corresponding to the request sent

625 by the verifying node does indeed exist, the verifying node then digitally

626 signs 72 the initial User ID Key, which is then sent back to the user.

627 On reception by the user 74, this verified User ID Key is used as the

628 user's session passport. The user's PC proceeds to construct 76 the

629 database of the file system as backed up by the user onto the network.

630 This database describes the location of all chunks that make up the

631 user's file system. Preferably the ID Key will contain irrefutable evidence

632 such as a public/private key pair to allow signing onto the network as

633 authorised users, preferably this is a case of self signing his or her own

634 ID - in which case the ID Key is decrypted and user is valid - self

635 validating.

636 Further details of the embodiment will now be described. A 'proxy-

637 controlled' handshake routine is employed through an encrypted point-to- 638 point channel, to ensure only authorised access by the legal owner to the

639 system, then to the user's file storage database, then to the files therein.

640 The handshaking check is initiated from the PC that a user logs on to

641 (the 'User PC), by generating the 'unverified encrypted hash' known as

642 the 'User ID Key', this preferably being created from the user's

643 information preferably email address and their PIN number. This 'hash'

644 is transmitted as a ^'hello. packet' on the Internet, to be picked up by any

645 system that recognises the User ID as being associated with specific

646 data that it holds. This PC then becomes the 'verifying PC and will

647 initially act as the User PC's 'gateway' into the system during the

648 authentication process. The encrypted item of data held by the verifying

649 PC will temporarily be used as a 'validation record', it being directly

650 associated with the user's identity and holding the specific address of a

651 number of data chunks belonging to the user and which are located

652 elsewhere in the peer-to-peer distributed file system. This 'validation

653 record' is returned to the User PC for decryption, with the expectation

654 that only the legal user can supply the specific information that will allow

655 its accurate decryption.

656 Preferably this data may be a signed response being given back to the

657 validating node which is possible as the id chunk when decrypted

658 (preferably symmetrically) contains the users public and private keys

659 allowing non refutable signing of data packets.

660 Preferably after successful decryption of the TMID packet (as described

661 above) the machine will now have access to the data map of the

662 database and public/private key pair allowing unfettered access to the

663 system.

664 It should be noted that in this embodiment, preferably no communication

665 is carried out via any nodes without an encrypted channel such as TLS

666 (Transport Layer Security) or SSL (Secure Sockets Layer) being set up

667 first. A peer talks to another peer via an encrypted channel and the other 668 peer (proxy) requests the information (e.g. for some space to save

669 information on or for the retrieval of a file). An encrypted link is formed

670 between all peers at each end of communications and also through the

671 proxy during the authentication process. This effectively bans snoopers

672 from detecting who is talking to whom and also what is being sent or

673 retrieved. The initial handshake for self authentication is also over an

674 encrypted link.

675 Secure connection is provided via certificate passing nodes, in a manner

676 that does not require intervention, with each node being validated by

677 another, where any invalid event or data, for whatever reason (fraud

678 detection, snooping from node or any invalid algorithms that catch the

679 node) will invalidate the chain created by the node. This is all transparent

680 to the user.

681 Further modifications and improvements may be added without departing

682 from the scope of the invention herein described.

683 Figure 5 illustrates a flow chart of data assurance event sequence in

684 accordance with first embodiment of this invention

685 Figure 6 illustrates a flow chart of file chunking event sequence in

686 accordance with second embodiment of this invention

687 Figure 7 illustrates a schematic diagram of file chunking example

688 Figure 8 illustrates a flow chart of self healing event sequence

689 Figure 9 illustrates a flow chart of peer ranking event sequence

690 Figure 10 illustrates a flow chart of duplicate removal event sequence 691 With reference to Figure 5, guaranteed accessibility to user data by data

692 assurance is demonstrated by flow chart. The data is copied to at least

693 three disparate locations at step (10). The disparate locations store data

694 with an appendix pointing to the other two locations by step (20) and is

695 renamed with hash of contents. Preferably this action is managed by

696 another node i.e. super node acting as an intermediary by step (30).

697 Each local copy at user's PC is checked for validity by integrity test by

698 step (40) and in addition validity checks by integrity test are made that

699 the other 2 copies are also still ok by step (50).

700 Any single node failure initiates a replacement copy of equivalent leaf

701 node being made in another disparate location by step (60) and the other

702 remaining copies are updated to reflect this change to reflect the newly

703 added replacement leaf node by step (70).

704 The steps of storing and retrieving are carried out via other network

705 nodes to mask the initiator (30).

706 The method further comprises the step of renaming all files with a hash

707 of their contents.

708 Therefore, each file can be checked for validity or tampering by running a

709 content hashing algorithm such as (for example) MD5 or an SHA variant,

710 the result of this being compared with the name of the file.

711 With reference to Figure 6, provides a methodology to manageable sized

712 data elements and to enable a complimentary data structure for and

713 compression and encryption and the step is to file chunking. By user's

714 pre-selection the nominated data elements (files are passed to chunking

715 process. Each data element (file) is split into small chunks by step (80)

716 and the data chunks are encrypted by step (90) to provide security for the

717 data. The data chunks are stored locally at step (100) ready for network 718 transfer of copies. Only the person or the group, to whom the overall data

719 belongs, will know the location of these (100) or the other related but

720 dissimilar chunks of data. All operations are conducted within the user's

721 local system. No data is presented externally.

722 Each of the above chunks does not contain location information for any

723 other dissimilar chunks. This provides for, security of data content, a

724 basis for integrity checking and redundancy.

725 The method further comprises the step of only allowing the person (or

726 group) to whom the data belongs, to have access to it, preferably via a

727 shared encryption technique. This allows persistence of data.

728 The checking of data or chunks of data between machines is carried out

729 via any presence type protocol such as a distributed hash table network.

730 On the occasion when all data chunks have been relocated (i.e. the user

731 has not logged on for a while,) a redirection record is created and stored

732 in the super node network, (a three copy process - similar to data)

733 therefore when a user requests a check, the redirection record is given to

734 the user to update their database.

735 This efficiently allows data resilience in cases where network churn is a

736 problem as in peer to peer or distributed networks.

737 With reference to Figure 7 which illustrates flow chart example of file

738 chunking. User's normal file has 5Mb document, which is chunked into

739 smaller variable sizes e.g. 135kb, 512kb, 768kb in any order. All chunks

740 may be compressed and encrypted by using Pass phrase. Next step is to

741 individually hash chunks and given hashes as names. Then database

742 record as a file is made from names of hashed chunks brought together

743 e.g. in empty version of original file (CMIIIHIIItIIIIItM ,t2,t3: 744 C2########,t1 ,t2,t3 etc), this file is then sent to transmission queue in

745 storage space allocated to client application.

746 With reference to Figure 8 provides a self healing event sequence

747 methodology. Self healing is required to guarantee availability of accurate

748 data. As data or chunks become invalid by failing integrity test by step

749 (110). The location of failing data chunks is assessed as unreliable and

750 further data from the leaf node is ignored from that location by step (120).

751 A 'Good Copy' from the 'known good' data chunk is recreated in a new

752 and equivalent leaf node. Data or chunks are recreated in a new and

753 safer location by step (130). The leaf node with failing data chunks is

754 marked as unreliable and the data therein as 'dirty' by step (140). Peer

755 leaf nodes become aware of this unreliable leaf node and add its location

756 to watch list by step (150). All operations conducted within the user's

757 local system. No data is presented externally.

758 Therefore, the introduction of viruses, worms etc. will be prevented and

759 faulty machines/ equipment identified automatically.

760 The network will use SSL or TLS type encryption to prevent unauthorised

761 access or snooping.

762 With reference to Figure 9, Peer Ranking id required to ensure consistent

763 response and performance for the level of guaranteed interaction

764 recorded for the user. For Peer Ranking each node (leaf node) monitors

765 its own peer node's resources and availability in a scaleable manner,

766 each leaf node is constantly monitored.

767 Each data store (whether a network service, physical drive etc.) is

768 monitored for availability. A qualified availability ranking is appended to

769 the (leaf) storage node address by consensus of a monitoring super node

770 group by step (160). A ranking figure will be appended by step (160) and

771 signed by the supply of a key from the monitoring super node; this would 772 preferably be agreed by more super nodes to establish a consensus for

773 altering the ranking of the node. The new rank will preferably be

774 appended to the node address or by a similar mechanism to allow the

775 node to be managed preferably in terms of what is stored there and how

776 many copies there has to be of the data for it to be seen as perpetual.

777 Each piece of data is checked via a content hashing mechanism for data

778 integrity, which is carried out by the storage node itself by step (170) or

779 by its partner nodes via super nodes by step (180) or by instigating node

780 via super nodes by step (190) by retrieval and running the hashing

781 algorithm against that piece of data. The data checking cycle repeats

782 itself.

783 As a peer (whether an instigating node or a partner peer (i.e. one that

784 has same chunk)) checks the data, the super node querying the storage

785 peer will respond with the result of the integrity check and update this

786 status on the storage peer. The instigating node or partner peer will

787 decide to forget this data and will replicate it in a more suitable location.

788 If data fails the integrity check the node itself will be marked as 'dirty' by

789 step (200) and 'dirty' status appended to leaf node address to mark it as

790 requiring further checks on the integrity of the data it holds by step (210).

791 Additional checks are carried out on data stored on the leaf node marked

792 as 'dirty' by step (220). If pre-determined percentage of data found to be

793 'dirty' node is removed from the network except for message traffic by

794 step (230). A certain percentage of dirty data being established may

795 conclude that this node is compromised or otherwise damaged and the

796 network would be informed of this. At that point the node will be removed

797 from the network except for the purpose of sending it warning messages

798 by step (230). 799 This allows either having data stored on nodes of equivalent availability

800 and efficiency or dictating the number of copies of data required to

801 maintain reliability.

802 Further modifications and improvements may be added without departing

803 from the scope of the invention herein described.

804 With reference to Figure 10, duplicate data is removed to maximise the

805 efficient use of the disk space. Prior to the initiation of the data backup

806 process by step (240), internally generated content hash may be

807 checked for a match against hashes stored on the internet by step (250)

808 or a list of previously backed up data (250). This will allow only one

809 backed up copy of data to be kept. This reduces the network wide

810 requirement to backup data which has the exact same contents.

811 Notification of shared key existence is passed back to instigating node by

812 step (260) to access authority check requested, which has to pass for

813 signed result is to be passed back to storage node. The storage node

814 passes shared key and database back to instigating node by step (270)

815 Such data is backed up via a shared key which after proof of the file

816 existing (260) on the instigating node, the shared key (270) is shared with

817 this instigating node. The location of the data is then passed to the node

818 for later retrieval if required.

819 This maintains copyright as people can only backup what they prove to

820 have on their systems and not publicly share copyright infringed data

821 openly on the network.

822 This data may be marked as protected or not protected by step (280)

823 which has check carried out for protected or non-protected data content.

824 The protected data ignores sharing process. ms_messenger (Figure 1 - PT6 and Figure 11)

825 1. A non public ID preferably one which is used in some other autonomous

826 system is used as a sign in mechanism and creates a Public ID key pair.

827 2. The user selects or creates their public ID by entering a name that can

828 easily be remembered (such as a nickname) the network is checked for a

829 data element existing with a hash of this and if not there, this name is

830 allowed. Otherwise the user is asked to choose again.

831 3. This ID called the MPID (maidsafe.net public ID) can be passed freely

832 between friends or printed on business cards etc. as an email address is

833 today.

834 4. To initiate communications a user enters the nickname of the person he

835 is trying to communicate with along with perhaps a short statement (like a

836 prearranged pin or other challenge). The receiver agrees or otherwise to

837 this request, disagreeing means a negative score starts to build with

838 initiator. This score may last for hours, days or even months depending

839 on regularity of refusals. A high score will accompany any communication

840 request messages. Users may set a limit on how many refusals a user

841 has prior to being automatically ignored.

842 5. All messages now transmitted are done so encrypted with the receiving

843 party's public key, making messages less refutable.

844 6. These messages may go through a proxy system or additional nodes to

845 mask the location of each user.

846 7. This system also allows document signing (digital signatures) and

847 interestingly, contract conversations. This is where a contract is signed

848 and shared between the users. Preferably this signed contract is equally

849 available to all in a signed (non changeable manner) and retrievable by 850 all. Therefore a distributed environment suits this method. These

851 contracts may be NDAs Tenders, Purchase Orders etc.

852 8. This may in some cases require individuals to prove their identity and this

853 can take many forms from dealing with drivers licenses to utility bills

854 being signed off in person or by other electronic methods such as

855 inputting passport numbers, driving license numbers etc.

856 9. If the recipient is on line then messages are sent straight to them for

857 decoding.

858 10. If the recipient is not on line, messages are require to be buffered as

859 required with email today.

860 11. Unlike today's email though, this is a distributed system with no servers to

861 buffer to. In maidsafe.net messages are stored on the net encrypted with

862 the receiver's public key. Buffer nodes may be known trusted nodes or

863 not.

864 12. Messages will look like receivers ID. message 1.message 2 or simply

865 be appended to the users MPID chunk, in both cases messages are

866 signed by the sender. This allows messages to be buffered in cases

867 where the user is offline. When the user comes on line he will check his

868 ID chunk and look for appended messages as above ID.messagel etc.

869 which is MPID.<message 1 data>.<message 2 data> etc

870 This system allows the ability for automatic system messages to be sent,

871 i.e... in the case of sharing the share, data maps can exist on everyone's

872 database and never be transmitted or stored in the open. File locks and

873 changes to the maps can automatically be routed between users using

874 the messenger system as described above. This is due to the distributed

875 nature of maidsafe.net and is a great, positive differentiator from other

876 messenger systems. These system commands will be strictly limited for 877 security reasons and will initially be used to send alerts from trusted

878 nodes and updates to share information by other shares of a private file

879 share (whether they are speaking with them or not).

Provision of Public ID (Figure 1 - P17)

880 According to a related aspect of this invention, a public and Private

881 key pair is created for a network where preferably the user is

882 anonymously logged on, and preferably has a changeable pseudo

883 random private id which is only used for transmission and retrieval of ID

884 blocks giving access to that network.

885 Preferably this public private key pair will be associated with a public ID.

886 This ID will be transmittable in a relatively harmless way using almost

887 any method including in the open (email, ftp, www etc.) but preferably in

888 an encrypted form. Preferably this ID should be simple enough to

889 remember such as a phone number type length. Preferably this ID will be

890 long enough however, to cope with the entire world's population and

891 more, therefore it would be preferably approx 11 characters long.

892 This ID can be printed on business cards or stationary like a phone

893 number or email address and cannot be linked to the users private ID by

894 external sources. However the user's own private information makes this

895 link by storing the data in the ID bit the user retrieves when logging in to

896 the network or via another equally valid method of secure network

897 authentication.

898 This ID can then be used in data or resource sharing with others in a

899 more open manner than with the private id. This keeps the private ID

900 private and allows much improved inter-node or inter-person

901 communications. Encrypted Communications (Figure 1 - P18)

902 According to a related aspect of this invention, the communications

903 between nodes should be both private and validated. This is preferably

904 irrefutable but there should be options for refutable communications if

905 required. For irrefutable communications the user logs on to the network

906 and retrieves their key pair and ID. This is then used to start

907 communications. Preferably the user's system will seek another node to

908 transmit and receive from randomly - this adds to the masking of the

909 user's private ID as the private ID is not used in any handshake with

910 network resources apart from logging in to the network.

911 As part of the initial handshake between users, a key may be passed.

912 Preferably this is a code passed between users over another

913 communications mechanism in a form such as a pin number known only

914 to the users involved or it may be as simple as appending the user's

915 name and other info to a communication request packet such as exists in

916 some instant messaging clients today - i.e. David wants to communicate

917 with you allow / deny / block.

918 Unlike many communications systems today, this is carried out on a

919 distributed server-less network. This however provides the problem of

920 what to do when users are off line. Today messages are either, stopped

921 or stored on a server, and in many cases not encrypted or secured. This

922 invention allows users to have messages securely buffered whilst off line.

923 This is preferably achieved by the node creating a unique identifier for

924 only this session and passing that ID to all known nodes in the user's

925 address book. Users on-line get this immediately, users off-line have this

926 buffered to their last known random ID. This ensures that the ability to

927 snoop on a user's messages is significantly reduced as there is no

928 identifier to people outside the address book as to the name of the

929 random ID bit the messages are stored to. The random ID bit is 930 preferably used as the first part of the identified buffer file name and

931 when more messages are stored then another file is saved with the

932 random id and a number appended to it representing the next sequential

933 available number. Therefore a user will log on and retrieve the messages

934 sequentially. This allows buffered secured and distributed messaging to

935 exist.

Document Signing (Figure 1 - P19)

936 According to a related aspect of this invention, a by-product of

937 securing communications between nodes using asymmetric encryption is

938 as previously stated, introducing a non-refutable link. This allows for not

939 only messages between nodes to be non-refutable but also for

940 documents signed in the same manner as messages to be non refutable.

941 Today somebody can easily steal a user's password or purposely attack

942 users as they are not anonymous; this invention provides a great deal of

943 anonymity and backs this up with access to resources.

944 Documents may be signed and passed as legally enforceable between

945 parties as a contract in many countries.

Contract Conversations (Figure 1 - P20)

946 According to a related aspect of this invention, a conversation or

947 topic can be requested under various contracted conditions. The system

948 may have a non disclosure agreement as an example and both parties

949 digitally sign this agreement automatically on acceptance of a contract

950 conversation. In this case a non disclosure conversation. This will

951 preferably speed up and protect commercial entities entering into

952 agreements or where merely investigating a relationship. Preferably other

953 conditions can be applied here such as preferably full disclosure 954 conversations, Purchase order conversations, contract signing

955 conversations etc. This is all carried out via a system preferably having

956 ready made enforceable contracts for automatic signing. These contracts

957 may preferably be country or legal domain specific and will require to be

958 enforceable under the law of the countries where the conversation is

959 happening. This will require the users to preferably automatically use a

960 combination of geographic IP status and by selecting which is their home

961 country and where are they are at that time located and having that

962 conversation.

963 Preferably only the discussion thread is under this contract, allowing any

964 party to halt the contract but not the contents of the thread which is under

965 contract.

966 Preferably there can also be a very clear intent statement for a

967 conversation that both parties agree to. This statement will form the basis

968 of a contract in the event of any debate. The clearer the intent statement

969 is; the better for enforceability. These conversations are potentially not

970 enforceable but should lead to simplifying any resolution required at a

971 later date. Preferably this can be added together with an actual contract

972 conversation such as a non disclosure agreement to form a pack of

973 contracts per conversation. Contract conversations will be clearly

974 identified as such with copies of the contracts easily viewable by both

975 parties at any time, these contracts will preferably be data maps and be

976 very small in terms of storage space required.

Claims

977

978 1. A distributed network ms messenger system that allows synchronisation

979 of system and user messages in an irrefutable manner, by allowing

980 messaging where identity is validated to prevent spam and further uses

981 this identity to allow digitally validated document signing and accounts

982 are created from a very good known source of personal account

983 information which need not be a public account and can be a private

984 account as in a maidsafe.net account and communications are via a

985 digital contract which is digitally signed and the conversation is subject to

986 the contract terms, this system comprises of combination of following

987 steps:

988 a. contract conversations

989 b. document signing

990 c. encrypted communication

991 d. provision of public ID

992 the above combination provides a unique system with cumulative and

993 synergistic benefits to allow people to effectively communicate & share

994 resources. 995

996 2. A distributed network ms messenger product that allows synchronisation

997 of system and user messages in an irrefutable manner, by allowing

998 messaging where identity is validated to prevent spam and further uses

999 this identity to allow digitally validated document signing and accounts

000 are created from a very good known source of personal account

001 information which need not be a public account and can be a private

002 account as in a maidsafe.net account and communications are via a

003 digital contract which is digitally signed and the conversation is subject to

304 the contract terms, this product comprises of combination of following

305 steps:

306 a. contract conversations

307 b. document signing

)08 c. encrypted communication 1009 d. provision of public ID

1010 the above combination provides a unique product with cumulative and

1011 synergistic benefits to allow people to effectively communicate & share

1012 resources. 1013

1014 3. A distributed network ms messenger system of claim 1 that allows

1015 synchronisation of system and user messages in an irrefutable manner,

1016 by allowing messaging where identity is validated to prevent spam and

1017 further uses this identity to allow digitally validated document signing and

1018 accounts are created from a very good known source of personal

1019 account information which need not be a public account and can be a

1020 private account as in a maidsafe.net account and communications are

1021 via a digital contract which is digitally signed and the conversation is

1022 subject to the contract terms, this system comprises of combination of

1023 following steps:

1024 a. contract conversations

1025 b. document signing, which further comprises of provision of key pairs

1026 c. encrypted communication, which further comprises of share maps

1027 d. provision of public ID, which further comprises of steps of provision of

1028 key pairs, proven individuals and interface with anonymous system,

1029 the above combination provides a unique system with cumulative and

1030 synergistic benefits to allow people to effectively communicate & share

1031 resources. 1032

1033 4. A distributed network ms messenger product of claim 2 that allows

1034 synchronisation of system and user messages in an irrefutable manner,

1035 by allowing messaging where identity is validated to prevent spam and

1036 further uses this identity to allow digitally validated document signing and

1037 accounts are created from a very good known source of personal

1038 account information which need not be a public account and can be a

1039 private account as in a maidsafe.net account and communications are

1040 via a digital contract which is digitally signed and the conversation is

1041 subject to the contract terms, this product comprises of combination of 1042 following steps:

1043 a. contract conversations

1044 b. document signing, which further comprises of provision of key pairs

1045 c. encrypted communication, which further comprises of share maps

1046 d. provision of public ID, which further comprises of steps of provision of

1047 key pairs, proven individuals and interface with anonymous system,

1048 the above combination provides a unique product with cumulative and

1049 synergistic benefits to allow people to effectively communicate & share

1050 resources 1051

1052 5. A product of claims 1-4 for message sending in a distributed server less

1053 environment comprising of;

1054 a. create a distributed messaging system with secure message

1055 buffering;

1056 b. create a system of non repudiation between parties;

1057 c. create a system of public ID created from private ID and linked by

1058 user 1059

[060 6. A method of claim 5, which further enhances security by passing join

[061 requests between users securely over a secure medium and encrypted;

[062

1063 7. A method of claims 5 and 6, wherein the steps to contact another node is

!064 carried out by a signed message indicating the wish to communicate

065 which may comprise of;

066 a. a signed message with private information contained in it or;

067 b. a signed message with previously known information contained in it

068 or;

069 c. a signed message with a previously agreed code; 070

071 8. A method of claims 5 and 6, where a contract may be agreed to and

072 signed prior to a conversation taking place; the conversation is then

073 governed by this contract and may include, but not be limited to;

074 a. Non disclosure agreements 1075 b. Full disclosure agreements

1076 c. Purchase orders. 1077

1078 9. A method of claims 5 and 6, which is to create a public ID the user has to

1079 prove or be spawned as an active participant in another network where

1080 resources are stored and utilised to provide an effort based ranking

1081 mechanism; 1082

1083 10. A method of claim 8 where a user may provide another user with a

1084 digitally signed equivalent of a 'power of attorney¹ to agree contracts on

1085 their behalf; 1086

1087 11. A method of claim 7 where messaging activity is ranked by peers and the

1088 rank transmitted in conversation requests; 1089

1090 12. A method of claim 9 where the Public ID may also indicate a

1091 biometrically signed user; 1092

1093 13. A method of claim 11 where users may require a ranking or effort score

1094 of a certain level before allowing another node to communicate with

1095 them; 1096

1097 14. A method of claim 10 where this 'power of attorney' can be instantly

1098 withdrawn by originating user without permission or requiring of

1099 acceptance by receiver or the 'power of attorney';