WO2019100112A1

WO2019100112A1 - A system, method, computer program and data signal for communicating and event based verification

Info

Publication number: WO2019100112A1
Application number: PCT/AU2018/051248
Authority: WO
Inventors: Aditya SHIVKUMAR
Original assignee: Resolve Disputes Online Technology Limited
Priority date: 2017-11-22
Filing date: 2018-11-22
Publication date: 2019-05-31

Abstract

The present invention relates to a system, method, computer program and data signal for communicating and event based verification. In one embodiment, the invention is directed to a dispute resolution system, which is arranged to facilitate communication between parties to the dispute and to also verify the authenticity of information provided by the parties. In a preferred embodiment, the invention is directed to a dispute resolution system that operates via a computing or telecommunications network or any other network protocols, such as the Internet.

Description

A SYSTEM, METHOD, COMPUTER PROGRAM AND DATA SI GNAL FOR COMMUNI CATI NG AND EVENT BASED VERI FI CATI ON

TECHNI CAL FI ELD OF I NVENTI ON

[0001] The present invention relates to a system, method, computer program and data signal for communicating and event based verification. In one embodiment, the invention is directed to a dispute resolution system, which is arranged to facilitate communication between parties to the dispute and to also verify the authenticity of information provided by the parties. In a preferred embodiment, the invention is directed to a dispute resolution system that operates via a computing or telecommunications network or any other network protocols, such as the I nternet.

BACKGROUND

[0002] In the past, the legal resolution of disputes via a legal professional or an officer of the court (referred to herein as“dispute resolution”) has taken place either face to face in a meeting room or in a court room . In recent decades, dispute resolution has also been undertaken via various forms of communication networks, such as email, text messages, telephone, voice over internet protocol technology and video conferencing technology.

[0003] While the above methods for dispute resolution can be suitable in many circumstances, there are many scenarios where information or evidence exchanged within dispute resolution needs to be independently verified. Independent verification is essential during dispute resolution where often there is a lack of trust and relationships may have broken down.

[0004] In more detail, present dispute resolution processes rely on letters, note taking, emails, human memory or audio or video recording devices to validate content, information or evidence exchanged during the dispute process. In many instances the source of such information often originates from one party and this alone can generate further dispute as to the authenticity and reliability of the source purporting to prove the matter stated. There may also be assertions that

Rectified Sheet

Rule 91 (ISA/AU) private centralised system s are more vulnerable to tam pering and fraudulent activity.

[ 0005] I t is in the context of the lim itations of current dispute resolution m ethodologies and processes that the present invention has been conceived.

SUMMARY OF TH E I NVENTI ON

[ 0006] I n a first aspect, the present invention provides a com puting system com prising a processor capable of accessing data in a database, the data corresponding to at least one blockchain ledger, the processor further obtaining notification data from the database, the data identifying a dispute event between two or m ore parties, wherein the notification data includes a blockchain ledger, and the processor decrypts the first encrypted portion of the decentralised blockchain ledger data using a first cryptographic key and a second encrypted portion of the blockchain ledger using a second encrypted portion of the blockchain ledger using a second cryptographic key.

[ 0007] I n a second aspect, the present invention provides a com puter enabled m ethod com prising the steps of accessing data in a database, the data corresponding to at least one blockchain ledger, providing the data to a processor, the processor further obtaining notification data from the database, the data identifying a dispute event between two or m ore parties, whereby the notification data includes a blockchain ledger, and the processor decrypts the first encrypted portion of the decentralised blockchain ledger data using a first cryptographic key and a second encrypted portion of the blockchain ledger using a second encrypted portion of the blockchain ledger using a second cryptographic key.

[ 0008] I n a third aspect, the present invention provides a com puter program including at least one instruction which, when executed on a com puting system , perform s the m ethod step in accordance with the second aspect of the invention.

[ 0009] I n a fourth aspect, the present invention provides a data signal including at least one instruction which, when executed on a com puting system , perform s the m ethod step in accordance with the second aspect of the invention.

Rectified Sheet

Rule 91 (ISA/AU) [0010] In a fifth aspect, the present invention provides a computing system comprising a processor capable of accessing data in a database, the data corresponding to at least one set of encrypted documents and communications related to two or more parties, the processor further obtaining notification data from the database, the data identifying a dispute event between two or more parties, wherein the processor selectively decrypts the documents and communications, and provides an interface where the two or more parties may interact with the documents and communications, in either a synchronous or asynchronous manner.

[0011] In a sixth aspect, the present invention provides a computer enabled method comprising the steps of utilising a processor capable of accessing data in a database to access data corresponding to at least one set of encrypted documents and communications related to two or more parties, the processor further obtaining notification data from the database, the data identifying a dispute event between two or more parties, wherein the processor selectively decrypts the documents and communications, and provides an interface where the two or more parties may interact with the documents and communications, in either a synchronous or asynchronous manner.

BRI EF DESCRI PTI ON OF THE DRAWINGS

[0012] Further features of the present invention are more fully described in the following description of several non-limiting embodiments thereof. This description is included solely for the purposes of exemplifying the present invention. It should not be understood as a restriction on the broad summary, disclosure or description of the invention as set out above. The description will be made with reference to the accompanying drawings in which:

[0013] FIG.1 is a schematic diagram of an example computing system on which a method and/or a computer program may be operated, or from which a data signal may be received or sent, in accordance with an embodiment of the invention;

Rectified Sheet

Rule 91 (ISA/AU) [0014] FIG.2 is a schematic diagram of an example architecture of a computing cloud environment, incorporating an example computing system in accordance with FI G.1 ;

[0015] FIG. 3 is a flow chart illustrating a computer enabled method in accordance with an embodiment of the present invention;

[0016] FIG.4 is a representational diagram illustrating the creation, execution and storage of a smart contract in accordance with an embodiment of the invention;

[0017] FIG.5 is a diagram illustrating a decentralised system in accordance with an embodiment of the invention;

[0018] FIG. 6 is a diagram illustrating a negotiation process using an embodiment of the present invention;

[0019] FIG.7 is a diagram illustrating a mediation process using an embodiment of the present invention; and

[0020] FIG. 8 is a diagram illustrating an arbitration process using an embodiment of the present invention.

DETAI LED DESCRI PTI ON OF PREFERRED EMBODI MENTS

[0021 ] One embodiment of the computing system is shown at FIG.1. In FIG.1 there is shown a schematic diagram of a computing system, which in this embodiment is a computing system 100 suitable for use with an embodiment of the present invention. The computing system 100 may be used to execute application and/or system services such as a computer program and an interface in accordance with an embodiment of the present invention.

[0022] With reference to FIG. 1, the computing system 100 may comprise suitable components necessary to receive, store and execute appropriate computer instructions. The components may include a processor 102, read only memory (ROM) 104, random access memory (RAM) 106, an input/output devices such as disc drives 108, remote or connected mobile devices 110 (such as

Rectified Sheet

Rule 91 (ISA/AU) computers, smartphones or tablets and the like), and one or more communications link(s) 114.

[0023] The computing system 100 includes instructions that may be installed in ROM 104, RAM 106 or disc drives 112 and may be executed by the processor 102. There may be provided a plurality of communication links 114 which may variously connect to one or more user devices 110, such as computers, smartphones or tablets, wherein the one or more user devices have a user interface for interacting with user by collecting and displaying data or information using the conventional means provided by such devices. At least one of a plurality of communications link 114 may be connected to an external computing network through a telecommunications network.

[0024] In one particular embodiment the device may include a database 116 which may reside on the storage device 112. It will be understood that the database may reside on any suitable storage device, which may encompass solid state drives, hard disc drives, optical drives or magnetic tape drives. The database 116 may reside on a single physical storage device or may be spread across multiple storage devices, either locally or remotely.

[0025] The computing system 100 includes a suitable operating system 118 which may also reside on a storage device or in the ROM of the server 100. The operating system is arranged to interact with the database and with one or more computer programs to cause the server to carry out the steps, functions and/or procedures in accordance with the embodiments of the invention described herein.

[0026] The user interface 110 of one or more mobile devices facilitates the collection and display of user data for the computing system 100. The user interface 110 may be a website accessed on a computer or mobile device via a communication network, such as the Internet. Alternatively, the user interface 110 may be a widget arranged on a website that may be accessed by a user using a computer or mobile device via a communication network such as the Internet. The user interface 110 may also be provided as a mobile application or“app” present on the user device, such as a tablet or smart phone.

Rectified Sheet

Rule 91 (ISA/AU) EM BODI MENT

[ 0027] I n m ore detail, the em bodim ent disclosed herein is directed to a system , m ethod, com puter program and data signal which is arranged to generate secured blockchain based ledger structures that facilitate event-based verification of the online dispute resolution process.

[ 0028] The decrypted first data portion may identify a plurality of triggering events controlled by System -Specified Rules (Rules) and the decrypted second data portion may identify a plurality of rules associated with the triggering events.

[ 0029] The executed instructions may further cause the processor to perform the steps of establishing that the identified dispute corresponds to at least one of the triggering events, identifying, based on the detected second data portion, at least one of the rules that dem onstrates a causal relationship with the detected first event and generating an electronic com mand to perform one or more operations to resolve the identified conflict consistent with at least one identified rule.

[ 0030] Figure 2 shows the RDO Application (202) as used by Clients A- D (Client) . Each Client will hold certain data centrally (Centralised Data) on their server (204) . Upon an End User com m encing the dispute resolution process, the RDO Application executes and stores certain data as Decentralised Data on the blockchain (206) . Through RDO’s Centralised and Decentralised architecture, the Client can choose to com pare Centralised Data and Decentralised Data for integrity. This form s a hybrid, public-private blockchain. Alternatively, the Client m ay opt to store certain data as Decentralised Data only. The use of utilising Decentralised architecture elim inates the risk of all data being held centrally.

[ 0031 ] Upon the Client com m encing and undertaking the dispute resolution process, the Decentralised Data is received by Middleware DAPP (208) which pushes the Decentralised Data to create a transaction which is executed as a sm art contract (21 0) using the process of data m ining between two or more peer nodes (212) on the blockchain network. Each executed transaction in a sm art contract is m ined as a block. Each block has the unique details of the previous block to create the block chain (214) which is im m utable and highly hack resistant.

Rectified Sheet

Rule 91 (ISA/AU) [ 0032] Figure 3 shows how the Decentralised Data is stored on the blockchain following the process outlined in Figure 2. As the dispute resolution com m ences and progresses the following will com prise smart contract events subj ect to System -Specified Rules (Rules) that will form Centralised Data and/or Decentralised Data.

[ 0033] Figure 4 shows how System -Specified Rules will act as triggering events to create sm art contracts events on the blockchain. I n sum m ary, this will depend on the status of the End User within the dispute resolution process and within the RDO application. An End User com prises of any of the following: The parties to the dispute ( Disputants) ; Users who are invited to assist the Disputants (Assistants) ; and/or Neutrals who will facilitate settlem ent or determ ine the dispute (Neutrals) .

[ 0034] Figure 5 illustrates a decentralised em bodim ent of the invention. Referring to Figure 5, at step 501 Authorised users login to RDO Dapp ( Decentralised App) .

[ 0035] At step 502 the RDO Dapp validates the User and perm its them to access the application.

[ 0036] At step 503 the RDO Dapp User files case against a respondent who is ether individual or Organisation. Respondent's contact information and dispute details are filed. The user can also select the case type as Negotiation or Mediation or Arbitration. RDO Dapp through Sm art Contracts creates a transaction that add new case in block chain environm ent. I f Negotiation, both parties settle their dispute without any human assistance. If Mediation, RDO Dapp will allocate a neutral to the case and he will assist the parties to settle. I f Arbitration, RDO Dapp will allocate an Arbitrator who will award the settlem ent.

[ 0037] At step 504 the RDO Dapp sends a case invitation to the Respondent's em ail address. The respondent responds through the link provided in the invitation em ail within a stipulated tim e.

Rectified Sheet

Rule 91 (ISA/AU) [ 0038] At step 505, once the Respondent decides to participate in the case, he is required to login into RDO Dapp as an authorised user.

[ 0039] At step 506, both parties are landed in RDO Dapp to resolve their dispute. They can share the docum ents or proofs against each other through Dapp. They can also comm unicate through Text Chat or Video / Audio Chat to reach a conclusion on the dispute.

[ 0040] At step 507, both parties can either com m unicate directly if Negotiation or through a neutral (Mediation) who can assist the parties to reach for settlem ent or an Arbitrator/s who can pass an award.

[ 0041 ] At step 508, once the parties com e to conclusion they will start drafting the outcom e which can take them to final settlem ent. With or without neutral's support both parties can draft or accept or amend outcom e if their case type is Negotiation or Mediation. I n case Arbitration, an Arbitrator will post the final award which is the final settlem ent.

[ 0042] At step 509, the RDO Dapp settles the dispute in crypto or FIAT currency.

[ 0043] I n FIGS 6-8, the em bodim ent illustrates the processes of Negotiation, Mediation and Arbitration, respectively, that form an intrinsic part of the online dispute resolution process using the RDO Dapp.

[ 0044] At Step 601 and 602, RDO ledger verifies the identity of the Claim ant seeking to lodge a negotiation claim .

[ 0045] At Step 603, the RDO ledger creates a smart contract consisting of the details to the Negotiation case which is data provided by the User at the tim e of initiating the claim .

[ 0046] At Step 604, the Claim ant enters the details to the negotiation on hand as well as enters the crypto/fiat account inform ation.

Rectified Sheet

Rule 91 (ISA/AU) [ 0047] At Step 605, the smart contract verifies the user’s crypto/fiat account that is automatically attached to the user’s individual dashboard.

[ 0048] At Step 606, the RDO Dapp autom atically inform s the Respondent/s on the nature of the claim for negotiation lodged by the Claim ant.

[ 0049] At Step 607, 608 Respondent/s enter their counter claim and provide crypto/fiat account.

[ 0050] At Step 609 the RDO Ledger validates the identity of the Respondent/s through RDO own consensus m echanism .

[ 0051 ] At Step 61 0, should the verification of the Respondent/s is affirm ed through RDO’s Consensus m echanism , the process leads to Step 61 1 where the Sm art Contract automatically verifies the crypto/fiat account of the Respondent/s.

[ 0052] At Step 61 2, should there be no counter claim or Respondent/s agree to the claim made in Step 604, the Sm art Contracts locks the agreed claim amount in the Respondent/s crypto/fiat wallet in Step 615 through RDO Settlem ent Builder which can be paid Claim ant/s through a mutually agreed tim efram e which would be Automatically executed through the RDO Smart Contract in Step 61 6. With this the claim is settled as evinced in Step 61 7.

[ 0053] At Step 612, should the Respondent/s have any counter claim to the claim made in Step 604, the claim negotiation will be undertaken as evinced in Step 613 and using RDO Settlem ent builder should the parties reach a settlem ent in Step 614, the processes m entioned in earlier in Step 615 to 617 would follow.

[ 0054] At Step 618, if after unsuccessful negotiations parties would like to continue to negotiate, RDO Dapp provides two options for the parties to resolve the dispute as seen in Step 619, Mediation and Arbitration.

[ 0055] At Step 620, the Negotiation claim would m ove to a Mediation Claim where RDO Dapp will appoint a m ediator at Step 621 to resolve the dispute between Claimant/s and Respondent/s.

Rectified Sheet

Rule 91 (ISA/AU) [ 0056] At Step 622, RDO Ledger validates the identity of the Mediator appointed to the dispute.

[ 0057] For each workflow or an integrated workflow, RDO Dapp verifies and validates the identity of the user at every stage as evinced in Step 624 and Step 626.

[ 0058] At Step 627, the m ediation takes place between the parties to the dispute and the m ediator using RDO’s technology.

[ 0059] At Step 628, should there be no counter claim or Respondent/s agree to the claim made in Step 604, the Sm art Contracts locks the agreed claim amount in the Respondent/s crypto/fiat wallet in Step 629 through RDO Settlem ent Builder which can be paid Claim ant/s through a mutually agreed tim efram e which would be Automatically executed through the RDO Smart Contract in Step 630. With this the claim is settled as evinced in Step 631 .

[ 0060] At Step 628, should the Respondent/s have any counter claim to the claim made in Step 604, the m ediation will be undertaken as evinced in Step 632 and using RDO Settlem ent builder should the parties reach a settlem ent in Step 633, the processes m entioned in earlier in Step 629 to 631 would follow.

[ 0061 ] At Step 632, if after unsuccessful attem pts to m ediate the parties would like to continue to resolve the dispute, RDO Dapp provides a further recourse through Arbitration for the parties to resolve the dispute as seen in Step 635.

[ 0062] At Step 636, the Mediation claim would move to a Arbitration where RDO Dapp will appoint an arbitrator at Step 637 to resolve the dispute between Claim ant/s and Respondent/s.

[ 0063] At Step 638, RDO Ledger validates the identity of the Arbitrator appointed to the dispute.

Rectified Sheet

Rule 91 (ISA/AU) [ 0064] For each workflow or an integrated workflow, RDO Dapp verifies and validates the identity of the user at every stage as evinced in Step 640 and Step 642.

[ 0065] At Step 643, the arbitrator exam ines the claim and passes an award which is bidding on the parties to the arbitration which takes place between the parties to the dispute and the m ediator using RDO’s technology.

[ 0066] At Step 644, post the Award the amount to be paid is appended to the RDO Sm art Contract for this particular dispute and is carried out through Step 645 where the amounts get transferred from the Respondent’s Account to the Claim ant’s.

DI SPUTANTS

[ 0067] Upon, deciding to becom e a party to dispute, an End User then satisfies the Rules pertaining to registration within the RDO application to becom e a Disputant. The Rules include but are not lim ited to entering their details and details of their case.

[ 0068] For a Disputant, this is a triggering event for the creation of a sm art contract which is form ed either as Centralised and/or Decentralised Data.

[ 0069] The following information form s part of the information captured as part of the dispute resolution process.

[ 0070] Case I dentification : a unique reference pertaining to every dispute registered on the RDO application.

[ 0071 ] Party Nam es and Details: the Disputant information such as usernam es, nam es, em ails addresses, phone num bers.

[ 0072] Case Category selection : the Disputant inform ation as to the nature of the dispute. For exam ple, divorce, property etc.

Rectified Sheet

Rule 91 (ISA/AU) [ 0073] Case I nformation : the Disputant information provided in response to pre determ ined questions.

[ 0074] Resolution Choice: the Disputant dispute resolution choice, nam ely negotiation, m ediation or arbitration.

[ 0075] Neutral choice: whether the Disputants have selected a particular Neutral party (such as a Mediator or Arbitrator) or are asking the RDO App to automatically allocate a Neutral.

[ 0076] Files shared: the files a Disputant has shared on a particular case.

[ 0077] Case History: the chronology of events in a case which are tim e-stam ped and End User specified which will include those actions undertaken by a Disputant.

[ 0078] Comm unications: any com munications between parties whether in the form of audio, video and m essages sent and received by a Disputant.

[ 0079] Post an Outcom e: in the event of a negotiation or m ediation, this field captures the offers made by the Disputants throughout the dispute and whether a Disputant has accepted or rejected such offers.

[ 0080] I n the event of arbitration, this field also captures the determ ination provided by the neutral.

ASSI STANTS

[ 0081 ] All End Users are required to satisfy the Rules pertaining to registration within the RDO application to becom e an Assistant. The Rules include the Disputant inviting an Assistant through the RDO application to j oin and assist the Disputant. Upon deciding to becom e a party to dispute, an Assistant satisfies certain predeterm ined rules and thus create a triggering event for the creation of a smart contract based on the following inform ation (listed below) . The smart contract may be form ed either as Centralised and/or Decentralised Data.

[ 0082] Files shared: the files an Assistant has shared on a particular case.

Rectified Sheet

Rule 91 (ISA/AU) [ 0083] Case History: the chronology of events in a case which are tim e-stam ped and End User specified which will include those actions undertaken by an Assistant.

[ 0084] Comm unications: all com m unications in the form of audio, video and m essages sent and received by an Assistant.

N EUTRALS

[ 0085] A user is required to satisfy the Rules pertaining to registration within the RDO application to becom e a Neutral. The Rules include the Disputant inviting an Assistant through the RDO application to j oin in and assist the Disputant. Upon deciding to becom e a party to dispute, an Assistant, upon satisfying the rules, will create a triggering event for the creation of a smart contract based on the following information (described below) which is form ed either as Centralised and/or Decentralised Data.

[ 0086] Files shared: the files an Assistant has shared on a particular case.

[ 0087] Case History: the chronology of events in a case which are tim e-stam ped and End User specified which will include those actions undertaken by an Assistant.

[ 0088] Com m unications: this will capture com m unications in the form of audio, video and m essages sent and received by an Assistant.

[ 0089] Figure 4 shows the Decentralised Data executed as a Smart Contract (402) between peers (404) which initiates the data m ining process. The m ining process (406) protects the data from being hacked and is im m utable thus preserving the integrity and record of the dispute resolution process. The Decentralised Data is stored in m ultiple blocks and each block is connected with the previous by a 64 digit hash. Thus, all of the blocks are chained together even though they are stored in different locations.

Rectified Sheet

Rule 91 (ISA/AU) [ 0090] I n the context of the em bodim ent, the End User can login, register a case, agree to the Service’s term s and conditions, select a mode of resolution for the case, invite a friend or advisor as a support user (third parties who are not parties to the case) , invite other additional parties to take part in the case (such as an additional Claimant or additional Respondent, have a neutral (m ediator or arbitrator) automatically allocated based on algorithm s of expertise and availability, upon registration process being com plete, the registration process being com plete upon agreeing to the term s and conditions, paym ent of the fee through a paym ent gateway if so required by the client, uploading the case history and the relevant docum ents and selecting the m ode of resolution of the dispute share files, schedule appointm ents and hearings, conduct synchronous or asynchronous m eetings and hearings using various technologies such as text chat, audio conferencing or video conferencing (or a com bination of all three) , conclude the case using a collaborative negotiation tool or receive a decision from a neutral, provide feedback on the experience and request any technical help from an Admin using text chat, audio conferencing or video conferencing (or a com bination of all three) .

[ 0091 ] The present invention includes three portals, nam ely the Adm in Portal, the User Portal and the Neutral Portal.

[ 0092] The Adm in Portal is managed by Adm ins. Admins are com prised of Head Adm ins and Adm in Assistants. Adm ins are the Administrators of the Software at the Clients end. Head Adm ins are Administrators of the Client Service. They are created at the request of the Client and have powers to add or rem ove Adm in Assistants. Head Adm ins have the power to create and delete Adm in Assistants. Adm ins manage and oversee the entire dispute and conflict resolution process and are a point of contact for the End User.

[ 0093] Adm in Assistants are Adm inistrators of the Client Service. Adm in Assistants are auto allocated cases by the Software using algorithm and ensure the efficient running of the Client service. Adm in Assistants can be added or rem oved. The Adm in Portal is integrated into the client’s server side which enables Adm ins to manage and oversee the running of the portal and enables the Adm in Assistant to efficiently oversee the cases allocated to them . Through the Adm in

Rectified Sheet

Rule 91 (ISA/AU) Portal the Admins can view statistics of the cases of their Service, allocate Neutrals to cases, share files, schedule and re-schedule appointm ents and engage in synchronous and asynchronous com m unication with the End Users and Neutrals, edit case questions for the End User and add/edit case categories should the client wish to expand their offerings.

[ 0094] Mediators/ Arbitrators are Neutrals selected by the Client who help in resolving the conflicts and disputes. I f Negotiation between the End Users fail, then the End Users can opt for Mediation. Mediators are neutrals selected by the Client who facilitate a negotiation between the End Users. I n the event Mediation fails, the Parties have the option to escalate the matter to Arbitration. Arbitration is the process by which an Arbitrator determ ines the outcom e of a case between two or more End Users. The Mediator/ Arbitrator is allocated a case automatically based on an algorithm or m anually by the Adm in. Mediation/Arbitration can take place synchronously or asynchronously using text chat, audio conferencing or video conferencing (or a com bination of all three) . Upon com pletion of the Negotiations or Mediation process, the End Users post their outcom e. I n the case of Arbitration, only the Arbitrator can post the outcom e of the decision.

[ 0095] Negotiation is the process by which two or more End Users try to resolve a dispute between them . This process is between the End Users only and does not involve a Neutral. However, Case Assistants are involved if the End User wishes. Case Assistants are friends or professional advisors who are not parties to the conflict or dispute, who m ay be invited by the End Users to assist them during the resolution process.

[ 0096] Case Categories are lists of categories which are being offered to the End User as part of the Client Service from a drop down m enu . Exam ples would include: landlord and tenant, consum er disputes, divorce etc. Neutrals (Arbitrators and Mediators) can be autom atically allocated cases based on their expertise in a particular case category.

[ 0097] End Users or Parties are Claimants and Respondents to a case who interact with the Client Service. Claimants or a Claimant is a party who initiates a case against a Respondent.

Rectified Sheet

Rule 91 (ISA/AU) [ 0098] Neutral Portal is a portal integrated into the Client Service to be accessed by the Neutrals of the Client Service.

[ 0099] Post an Outcom e, yet another unique feature of the present invention, refers to the process and m ethod by which cases are resolved. I n Negotiation and Mediation the End Users can use a collaborative space to reach a settlem ent and post the outcom e. I n Arbitration, the Neutral (the Arbitrator) posts an outcom e at the conclusion of a case. Post an Outcom e can be undertaken synchronously and asynchronously.

[ 01 00] User Portal is the portal integrated into the Client Server to be accessed by the End User. The User Portal allows the End User to register a case, share docum ents, schedule and reschedule appointm ents and resolve their case using Arbitration, Mediation and/or Negotiation using inbox m essaging, audio and/or video technology either synchronously or asynchronously.

[ 01 01 ] The present invention com prises of three portals which allow the Client to brand, custom ise, m anage, operate and evaluate their Client Service for their End Users. The Adm in, User and Neutral Portals provide for automated emails and web notifications to users, neutrals and client adm inistrators for all the processes described below.

[ 01 02] The Admin Portal facilitates the client to custom ise, m anage, operate and evaluate their Service. The client is able to customize, edit, create and delete case questions, create, edit and delete case categories and sub categories, autom ated em ail content and create, edit and delete End User feedback questions through a unique feature of this invention known as Masters, which is responsible for posing dynamic questions to the End Users in the Client’s Front End. The Client through the present invention is able to add Neutrals, rem ove Neutrals, m anually or automatically allocate Neutrals to cases, remove or suspend End Users from cases and add or rem ove files/docum ents from cases. The Client also able to view all cases registered and those case details, see all appointm ents registered, view the activities on all cases, add or remove shared files, make case notes, schedule and view appointm ents with End Users, Neutrals and other Adm ins, com m unicate with

Rectified Sheet

Rule 91 (ISA/AU) End Users, Neutrals and other Admins by using synchronous and asynchronous m essaging, audio and video technologies and autom atically request feedback from End Users. The Client is further able to view statistics such as: Cases Registered, Total Sign Ups by End Users, Total Assistant Adm ins, Total Neutrals, Total Neutrals in Case Categories, Total Cases Ongoing, Total Cases Pending, Total Cases at Negotiation/Mediation and Arbitration.

[ 01 03] The Client also m anages their Service with the following controls:

[ 01 04] Enable and Disable End Users: The Admin is enabled with the option to enable and disable End Users who are registered on the Client Service.

[ 01 05] Enable and Disable Neutrals: Depending upon the service offered by the Client, the Admin can add Neutrals by enabling the “Add A Neutral feature” through the Adm in Portal. The Adm in can create an independent list of Mediators and Arbitrators based on the area of expertise which is used to auto allocate the neutrals to the cases of their expertise. The Adm in can also enable and disable the accounts of Neutrals based on the request made by them .

[ 01 06] Enable and Disable Adm in Assistants: Head Adm ins have the power to enable and disable Admin Assistants who are the points of contact for End Users. The Head Adm in adds the Adm in Assistants into the service. Once the Head Admin disables an Adm in Assistant, the cases allocated to them are re-auto allocated to the other Adm in Assistants on the service. End Users are inform ed of the change of Adm in Assistant.

[ 01 07] Schedule and Re-Schedule Appointm ents: An Adm in can schedule appointm ents, accept appointm ents, re-schedule appointm ents, cancel appointm ents with End Users and Neutrals. The Adm in can also view appointm ents m ade by the End Users and Neutrals on the service.

[ 01 08] Add or rem ove share files.

[ 01 09] The Client is able to view feedback from End Users on the experience of using the Client Service and the effectiveness of Neutrals.

Rectified Sheet

Rule 91 (ISA/AU) [0110] The User Portal allows End Users to register a case; respond to a case, agree to terms of service and any fee, add additional End Users to a case, add additional Case Assistants to take part in a case (third parties such as friend, advocate or advisor), share files for a case, schedule and view appointments with other End Users associated with that particular case, Neutrals and Admins, communicate with other End Users of that particular case, Neutrals and Admins by using synchronous and asynchronous messaging, audio and video technologies, collaborate on a settlement and post an outcome synchronously or asynchronously, save and view the outcome on the User Portal, export the outcome to PDF, submit feedback on the user experience of the User Portal. Every End User is allocated a secure username and password. The End User also has the benefit of end-to-end encryption so any communications between End Users remain confidential.

[0111] The Neutral Portal allows Neutrals to become registered as a Neutral, agree terms of service, edit their Case Category specialisms, be manually or automatically allocated a case, view details of cases they have been allocated, share files for a case, save case notes, schedule and view appointments with End Users and Admins, communicate with End Users and Admins using synchronous and asynchronous messaging, audio and video technologies, facilitate settlement (in mediation) and post an outcome (in arbitration) synchronously or asynchronously, save and view the outcome on the Neutral Portal and export the outcome to PDF.

EXAMPLE ONE

[0112] To begin the negotiation, an End User accesses a portal via a web browser. The End User proceeds to Sign Up for the Client Service by providing details such as: Name, Email Account and Mobile Phone Number. An Email Validation is sent to the email account of the End User who has registered and once their account is validated the End User becomes a Claimant within the Client Service.

[0113] The Claimant then provides information regarding the identity of the Respondent. The Claimant also selects a Case Category which then provides a

Rectified Sheet

Rule 91 (ISA/AU) series of dynamic questions depending on the Case Category selected. The Claim ant then chooses a Resolution Choice which, subj ect to the Client’s wishes, can be all or any of negotiation, m ediation and/or arbitration. Finally, the Claimant reviews their subm ission and agrees any term s of service/ paym ent schedule etc., set by the Client.

[ 01 14] The Claimant receives an autom ated em ail confirmation of their case registration and an automated email is sent to the Respondent notifying them of the existence of a case. I n this email, the Respondent is provided with a One Tim e Passcode to login to the Client Service and either Accept or Rej ect the case registered by the Claimant.

[ 01 15] I f the Respondent rej ects the case they are requested to provide reasons of the rej ection which are stored by the Client Service. If the Respondent accepts, then the Respondent is required to provide a response to the case registered by the Claim ant and the Respondent provides their resolution choice.

[ 01 16] Depending upon the nature of resolution specification requested by the Client at the tim e of licensing, the Claimant and Respondent can move from Negotiation to Mediation to Arbitration once inside the Clients service portal, provided the Claimant and Respondent agree on the resolution choice.

[ 01 17] Once the case is registered, the Claimant and Respondent can login. Upon logging in they see the cases they have registered, its Case Category, its Status and the resolution choice. There are six case statuses: Ongoing, Pending, Withdrawn, Rejected, Resolved and Not Resolved.

[ 01 18] Ongoing : when the case is in progress and End Users to the case are participating in the resolution process.

[ 01 19] Pending : when the case is waiting for End Users to respond to the invitation to j oin the case.

[ 01 20] Withdrawn : during the resolution process, any party can choose to withdraw from the proceeding. I n a m ulti-party scenario the status for the

Rectified Sheet

Rule 91 (ISA/AU) withdrawn party will state‘withdrawn’ but those rem aining involved can continue with resolution.

[ 01 21 ] Rej ected: this is for when parties have rejected the offer to resolve the dispute at the outset.

[ 01 22] Resolved: when a dispute has been resolved either via settlem ent by the parties (negotiation and m ediation) or by determ ination from a neutral (arbitration) .

[ 01 23] Not Resolved: this is where a party has withdrawn but has opted to use the‘recuse’ button instead.

[ 01 24] Once the case status reflected as“Ongoing” a party is able to: begin com municating with another party, a Neutral or an Adm in using synchronous and/or asynchronous inbox m essaging, audio and video conferencing.

[ 01 25] A party can also contact individuals or create m ultiple groups for group m essaging and initiating audio and video calls; share files; set up appointm ents with another party, a Neutral or an Admin; make private case notes on a particular case; add, enable or disable Case Assistants; add another party to a case; and/or post an outcom e.

EXAMPLE TWO

[ 01 26] I n another exam ple, the Parties and a Neutral can attem pt to resolve a case using the asynchronous and synchronous inbox m essaging, as well as synchronous audio and video technology. I n the event a Client Service provides Negotiation, Mediation and Arbitration to the Parties then the following process will apply: should a particular dispute fail to be resolved at negotiation, the Parties can m ake a Request for Mediation and the system automatically allocates a Mediator from the database of the Client Service. This allocation is done based on the closest m atch between a Neutral’s specialism and the Case Category selected by the Parties. Should Mediation fail then the parties can request for an Arbitrator to be appointed to determ ine the m atter for the Parties.

Rectified Sheet

Rule 91 (ISA/AU) EXAMPLE TH REE

[ 01 27] If a Negotiation or Mediation is heading towards resolution, then the Parties click on Post an Outcom e. This enables two or more parties to post offers within a collaborative tool which incorporates the legal principles of offer, acceptance and withdrawal. The whole purpose of negotiation and m ediation is to allow parties to enter into a binding settlem ent. An Offer, Withdrawal of Offer, Rej ection and Acceptance m ust be made clear or the entire settlem ent could be challenged as not legally binding. I n sum m ary, when Party X wants to m ake an offer to Party Y they:

i. Click on‘Post an Outcom e”

ii. Draft the term s of the offer and click“offer”

iii. X can then click“withdraw offer” if they change their m ind and make a new offer as per above. I f X wants to withdraw and offer but Y accepts it then, as per com m on law rules, Ys acceptance with bind X.

[ 01 28] An em ail is sent to Party Y inform ing them of Part X’s offer. Party Y logs in and clicks“Post an Outcom e”. Party Y ean either“Accept offer”,“Make Counter- Offer” or“Withdraw”.

[ 01 29] If Party Y wants to reject an offer they are required to m ake a Counter- Offer. This ensures that rejection of an offer is m et with a Counter-Offer in an attem pt to progress settlem ent. Once a party begins typing in the text box the button which previously said“Accept Offer” changes to“Make Counter Offer”. A notification then appears which requires a confirm ation.

[ 01 30] Party X then receives notification of Party Ys Counter-Offer (which also acts as a Rejection of Party X’s offer) . Multiple offers can be exchanged till the parties reach a final agreem ent. The parties are required to confirm their understanding of their offer or their acceptance and the consequences of doing so using e-signature technologies.

[ 01 31 ] Upon acceptance of an offer, the Parties to confirm their understanding to their offer and acceptance will be notified of the settlem ent and the term s of saved within the Case Details and there is an option to export it as a PDF. The

Rectified Sheet

Rule 91 (ISA/AU) case is then considered as‘Resolved’. Whilst Post an Outcom e is ongoing, the Parties are able to see a history of the offers and counter-offers made. This m eans during asynchronous com m unications, the Parties, particularly if there are more than two, are able to keep abreast of the settlem ent process.

EXAMPLE FOU R

[ 01 32] If the resolution choice is Arbitration, the Neutral sim ply drafts a final version as which determ ines the matter for the End Users. Upon clicking‘Send’, the arbitrator’s conclusions are sent to all parties. Upon the m atter being ‘Resolved’ or‘Not Resolved’, the Parties are sent an email inviting them to give feedback on their experience.

ADVANTAGES

[ 01 33] The em bodim ent and broader invention described herein provides a num ber of advantages.

[ 01 34] The em bodim ents and broader invention described herein are directed broadly to a web application known as Resolve Disputes Online ( RDO) . RDO is a cloud based software which allows for dispute resolution to take place using online technology (including synchronous and asynchronous m essaging and real tim e audio and video conferencing) with the exchange of critical inform ation being recorded as smart contracts and independently verifiable within the blockchain. This provides certainty and integrity as to the inform ation exchanged during dispute processes such as negotiation, m ediation, conciliation, arbitration, adjudication or court proceedings.

[ 01 35] When running on Blockchain a smart contract is analogous to a self- operating com puter program that automatically executes when specific conditions are m et. Advantageously, this allows dispute resolution to progress efficiently, and term s in the contract to be m et quickly and efficiently, without hum an intervention.

[ 01 36] Moreover, sm art contracts operate exactly as program m ed without a possibility of censorship, downtim e, fraud or third party interference. I n addition, the public nature, redundant verification and resistance to fraudulent activity of

Rectified Sheet

Rule 91 (ISA/AU) sm art contracts offers advantages over existing centralised system s I n other words, Blockchain dispute resolution technology is less susceptible to argum ent as to authenticity, validation and reliability. This advantageously strengthens the fram ework and integrity in which dispute resolution takes place.

[ 01 37] The em bodim ents and broader invention described herein is able to act as a witness node within a blockchain eco-system to verify that certain events have occurred. By way of illustration only, at least one em bodim ent of the invention m ay be used to verify that smart contracts obligations, such as paym ent or delivery, have occurred.

[ 01 38] The em bodim ents and broader invention described herein is able to im port the ledger history from a blockchain eco-system so that the parties and/or the independent j udge or m ediator can verify what events have happened and when. This allows the narrowing of factual issues or aspects of the dispute.

DI SCLAI M ERS

[ 01 39] Throughout this specification, unless the context requires otherwise, the word “com prise” or variations such as “com prises” or “com prising”, will be understood to im ply the inclusion of a stated feature or group of features but not the explicit exclusion of any other feature or group of features.

[ 01 40] Those skilled in the art will appreciate that the em bodim ents described herein are susceptible to obvious variations and modifications other than those specifically described and it is intended that the broadest claim s cover all such variations and m odifications. Those skilled in the art will also understand that the inventive concept that underpins the broadest claim s may include any num ber of the steps, features, and concepts referred to or indicated in the specification, either individually or collectively, and any and all com binations of any two or more of the steps or features may constitute an invention.

[ 01 41 ] Where definitions for selected term s used herein are found within the detailed description of the invention, it is intended that such definitions apply to the claim ed invention. However, if not explicitly defined, all scientific and technical

Rectified Sheet

Rule 91 (ISA/AU) terms used herein have the same meaning as commonly understood to one of ordinary skill in the art to which the invention belongs.

[0142] Although not required, the embodiments described with reference to the method, computer program, computer interface and aspects of the system can be implemented via an application programming interface (API), an application development kit (ADK) or as a series of program libraries, for use by a developer, for the creation of software applications which are to be used on any one or more computing platforms or devices, such as a terminal or personal computer operating system or a portable computing device, a smartphone or a tablet computing system operating system, or within a larger server structure, such as a‘data farm’ or within a larger computing transaction processing system.

[0143] Generally, as program modules include routines, programs, objects, components and data files that perform or assist in the performance of particular functions, it will be understood that the functionality of the method, computer program and computer interface defined herein may be distributed across a number of routines, programs, objects or components to achieve the same functionality as the embodiment and the broader invention claimed herein. Such variations and modifications are contemplated by the inventor and are within the purview of those skilled in the art.

[0144] It will also be appreciated that where methods and systems of the present invention and/or embodiments are implemented by computing systems or partly implemented by computing systems then any appropriate computing system architecture may be utilised without departing from the inventive concept. This includes standalone computers, networked computers and dedicated computing devices that do not utilise software as it is colloquially understood (such as field-programmable gate arrays).

[0145] Where the terms“computer”, “computing system”,“computing device” and“mobile device” are used in the specification, these terms are intended to cover any appropriate arrangement of computer hardware for implementing the inventive concept and/or embodiments described herein.

Rectified Sheet

Rule 91 (ISA/AU) [0146] Where the terms “software application”, “application”, “computer program” and “program” are used in the specification when referring to an embodiment of the invention, these terms are intended to cover any appropriate software which is capable of performing the functions and/or achieving the outcomes as broadly described herein.

[0147] Where reference is made to communication standards, methods and/or systems, it will be understood that the devices, computing systems, servers, etc., that constitute the embodiments and/or invention or interact with the embodiments and/or invention may transmit and receive data via any suitable hardware mechanism and software protocol, including wired and wireless communications protocols, such as but not limited to second, third and fourth generation (2G, 3G and 4G) telecommunications protocols (in accordance with the International Mobile Telecommunications-2000 (IMT-2000) specification), Wi-Fi (in accordance with the IEEE 802.11 standards), Bluetooth (in accordance with the IEEE 802.15.1 standard and/or standards set by the Bluetooth Special Interest Group), or any other radio frequency, optical, acoustic, magnetic, or any other form or method of communication that may become available from time to time.

Rectified Sheet

Rule 91 (ISA/AU)

Claims

CLAI MS

1 . A com puting system com prising a processor capable of accessing data in a database, the data corresponding to at least one blockchain ledger, the processor further obtaining notification data from the database, the data identifying a dispute event between two or m ore parties, wherein the notification data includes a blockchain ledger, and the processor decrypts the first encrypted portion of the decentralised blockchain ledger data using a first cryptographic key and a second encrypted portion of the blockchain ledger using a second encrypted portion of the blockchain ledger using a second cryptographic key.

2. A com puter enabled m ethod com prising the steps of accessing data in a database, the data corresponding to at least one blockchain ledger, providing the data to a processor, the processor further obtaining notification data from the database, the data identifying a dispute event between two or more parties, whereby the notification data includes a blockchain ledger, and the processor decrypts the first encrypted portion of the decentralised blockchain ledger data using a first cryptographic key and a second encrypted portion of the blockchain ledger using a second encrypted portion of the blockchain ledger using a second cryptographic key.

3. A com puter program including at least one instruction which, when executed on a com puting system , perform s the m ethod step in accordance with claim 2.

4. A data signal including at least one instruction which, when executed on a com puting system , perform s the m ethod step in accordance with claim 2.

5. A com puting system com prising a processor capable of accessing data in a database, the data corresponding to at least one set of encrypted docum ents and com m unications related to two or more parties, the processor further obtaining notification data from the database, the data identifying a dispute event between two or m ore parties, wherein the processor selectively decrypts the documents and communications, and provides an interface where the two or more parties may interact with the documents and communications, in either a synchronous or asynchronous manner.

6. A computer enabled method comprising the steps of utilising a processor capable of accessing data in a database to access data corresponding to at least one set of encrypted documents and communications related to two or more parties, the processor further obtaining notification data from the database, the data identifying a dispute event between two or more parties, wherein the processor selectively decrypts the documents and communications, and provides an interface where the two or more parties may interact with the documents and communications, in either a synchronous or asynchronous manner.

7. A computer program including at least one instruction which, when executed on a computing system, performs the method step in accordance with claim 6.

8. A data signal including at least one instruction which, when executed on a computing system, performs the method step in accordance with claim 6.