Field of the Invention

[1 ] Disclosed are platform methods and systems of a trust broker, a nd more particularly a two-way verification process.

Background of the Invention

[2] When a user signs up or logs in to a website or a pp ( ^' property J, the user is required to verify themselves through va rious trust factors, including full name, address, email address, phone number, username, and password. This can be observed when making a purchase from an ecommerce store, registering for a music streaming service, or signing in to a n email account. There is, however, no consistent way to verify that the website or app that the user is engaging with, is the authorised property of an entity. Whilst one can observe the website address manua lly to provide some assurance that the user is visiting a plausible property for an entity, it is not a guarantee of trust because human interpretation is prone to huma n error, as well as malicious technica l interventions such as man in the middle . attacks, TD N homograph. attacks, a nd phishing attacks.

[3] When a user is directed to verify themselves with passwords, passphrases a nd PIN numbers, they are usua lly looking to engage with an entity (eg Telco compa ny) or property (eg logging into your ba nk account, email provider or withdrawing cash from a n ATM) ^" this method of verification provides value to the requesting body, as they can compare the quoted details from the user to those they have stored within their property. They do however provide little to no value to the user, in verifying that the property is actually the authentic entity or property. Actors acting with malicious intent could provide a phishing site wherein a user would be typing in a password into that phishing site, or using a fake ATM. Websites that use password methods are typically static, so if a bad actor was to discover their password, passphrase or PIN, they could gain access to the associated property (eg with a keylogger, video camera or forced under duress). A one-time password or ( OTP J can generate numbers derived from a unique string, which only both the provider and the user know (can be received as S MS , or read from an app like Google Authenticator). The generated numbers are typica lly time based, and are regenerated every 30 seconds. However, again, the OTP only provide a one-way verification of the user, not the provider.

[4] Despite these issues, if the user wants to sign in to the properly, they a re treated as hostile a nd required to verify themselves through various bits of information and activities. This does not demonstrate a process of trust, but instead a process where the user must implicitly trust the property they a re engaged with. Typica lly, a user completes the sign-in or signup process in faith that the property is the authentic entity, a nd not a malicious one.

[5] Another situation similar to the first, is that of ca lls from call centres. When a person receives a call from someone claiming to work for an organisation, there is no tangible way to verify that they are who they say they are. Huma ns are capable of lying, can fake their caller ID for phone calls and S MS ^" and can alter their vocal characteristics (such as accents, pitch, tone) to mask or imitate others. Often, the caller will also try solicit a n TD verification _, process of the person they have just called, posing a serious threat to identity safety s hould they be a ma licious actor. In other circumstances, it is observed that the caller attempts to extract personally identifiable information from the person receiving the call, citing a survey they ^' re conducting., or by asking you to confirm a detail they s hare with you (to deduce the result from your answer).

[6] Yet another similar situation, is that of email authenticity as a user. In that situation, it is becoming increasingly more difficult to ascertain the authenticity of an email. E mail is a common channel for conducting phishing attacks, in which a user is directed to a website or a pp that looks like the official property, but was maliciously created to harvest the user s persona lly identifiable information, including usernames, passwords, full names, address, email address and credit card details. In some cases they are being presented with a credit card form to complete, which likely leads to electronic theft of funds. For businesses, email is very important to establish trust, provide awareness on products & services, and communicate important updates with their customers. But with scam emails on the rise, trust is being diminished between businesses a nd their customers.

[7] A user can check the ^' from. a nd ^' to. address of an email, but these can be faked. They can a lso hover their mouse over links to see where they link to, to manually determine the risk and authenticity of the email. But links can be masked with UR L shortening services, adding further complexity. Mobile devices also restrict what information is visible to optimise user experience for sma ll screens, in addition to not being a ble to 'hover _, over the aforementioned links in an email. E ach of these observations (online accounts, phone calls and emails) demonstrate a single flow of trust, which is typically pushed to or pulled from a user.

[8] Any discussion of the background a rt throughout the specification should in no way be considered as an admission that such background a rt is prior art, nor that such background art is widely known or forms part of the common genera l knowledge in the field in Australia or any other country.

S ummary of the Invention

[9] T he presently disclosed methods and systems seek to provide a solution which will overcome or substantially ameliorate at least some of the deficiencies of the prior art, or to at least provide an a lternative.

[10] The disclosed platform systems a nd methods, provide two ^' way verification that generates unique codes for each entity, per engagement, activity or solicitation (making them useless outside of the engagement). All entities are provided access to each ofthe generated unique codes for the engagement. All entities excha nge their own code, while verifying those received by the others. If all entities can correctly provide or recite their own unique code, two ^' way trust can be established for the engagement and an activity can proceed.

[1 1 ] A platform method implemented at least in pa rt by a computing device for configuring trust between at least two entities being a requestor entity a nd a recipient entity so that at least one of the entities may partake in an activity, wherein the platform comprises a trust broker configured to communicate with the requestor entity a nd the recipient entity. The activity which triggers the platform method can originate from an action, system or process, such as a person signing up for a new mobile account/plan (process), a computer system requesting access to a 3rd party computer system (system), a company wishing to communicate with their customers (process/action), or a user wishing to login to their email provider to send an email (action). T he trust broker is typically configured to accept network communication using TC P/IP based protocols, in particula r HTTP and HTTPS from the Internet, a nd from other public & private networks. As a result, entities can communicate with the trust broker, which in part is comprised of web servers, through an Internet S ervice P rovider. In one such configuration, the solicitation of a verification request is received by one or more web servers, which store the received details in a data store along with appropriate metadata forthe type of solicitation. The trust broker ca n use local, remote, centra lised a nd decentra lised data stores, to store the received details a nd its associated metadata. However, the configuration described here is used as an example of one possible configuration for implementing the platform method disclosed.

[12] The trust broker receives a communication from the requestor entity providing a solicitation for the recipient entity to enable at least one entity to partake in the activity. As a n activity has occurred which requires each entity to verify themselves to establish complete trust between entities, the initiating entity solicits to engage with the others in a process to prove a verified self, with the trust broker.

[13] A verification process involves verifying by the trust broker the authenticity of the requestor entity.

[14] A requestor entity must be registered with the trust broker to solicit an engagement.

E ach entity is granted unique credentials, which they use to initiate the solicitation with the trust broker. If a received solicitation includes invalid credentials, it will discarded a nd the platform method will terminate.

[1 5] The trust broker is either in software or hardwa re so that generating by the trust broker a pending solicitation that includes data releva nt to at least one of the requestor entity a nd the recipient entity. T he received solicitation includes the type of engagement, the list of recipients of which to engage with, and metadata related to the type of engagement. For example, an email related engagement could contain information specific to the email such as its subject. Unique codes are generated for each entity in the engagement, and added to the data store for this engagement.

[16] The trust broker gene rates a unique requestorverification code and a unique recipient verification code for delivery to the requestor entity a nd the recipient entity. The unique verification codes are randomly created for each entity in the engagement, and may comprise of numbers, letters, symbols, words, colours, images, sounds, orvideo. They a re unique to each entity, and per engagement, therefore providing a mechanism for each entity to safely exchange them for verification purposes, without the concern of fraudulent use in another engagement.

[17] The trust broker communicates to the requestor entity the pending solicitation, the unique requestor verification code and the unique recipient verification code. Delivery of the solicitation details, its associated data and verification codes for each entity is returned to the requestor in response to their initial request, or sent as a separate response to a previously approved requestor web address. This occurs over TC P/IP based network protocols HTTP and HTT PS from the Internet, and other public & private networks.

[18] Communication of the pending solicitation, the unique requestor verification code a nd the unique recipient verification code is enabled. If receipt of a communication of at least partia l acceptance of the pending solicitation from the recipient entity is affected, a nd if the requestor entity verifies the unique requestor verification code for the benefit of the recipient entity is effected, a nd if the recipient entity verifies the unique recipient verification code for the benefit of the requestor entity is affected, then at least one of the entities is enabled to partake in the activity. Depending on the type of solicited engagement, there may be an opportunity for the recipients to opt ^' in to a response for the verification request. For example, when the platform method is a pplied to a user logging into a website (FIG . 6), the recipient res ponds to the solicited request with a response to either accept the login request, or decline the login request.

[19] Disclosed is a platform method implemented at least in part by a computing device for configuring trust between at least two entities being a requestor entity and a recipient entity so that at least one of the entities may partake in an activity, wherein the platform comprises a trust broker configured to communicate with the requestor entity and the recipient entity, comprising:

[20] the trust broker receiving a communication from the requestor entity providing a solicitation for the recipient entity to enable at least one entity to partake in the activity;

[21 ] verifying by the trust broker the authenticity of the requestor entity;

[22] generating by the trust broker a pending solicitation that includes data relevant to at least one of the requestor entity a nd the recipient entity;

[23] generating by the trust broker a unique requestor verification code and a unique recipient verification code for delivery to the requestor entity a nd the recipient entity;

[24] communicating by the trust broker to the requestor entity the pending solicitation, the unique requestor verification code and the unique recipient verification code;

[25] ena bling communication to the recipient entity the pending solicitation, the unique requestor verification code and the unique recipient verification code; and

[26] if receipt of a communication of at least partial accepta nce of the pending solicitation from the recipient entity is effected, a nd if the requestor entity verifies the unique requestor verification code for the benefit of the recipient entity is effected, a nd if the recipient entity verifies the unique recipient verification code for the benefit of the requestor entity is affected, then at least one of the entities is enabled to parta ke in the activity.

[27] Also disclosed is a platform system, comprising:

[28] a server hosting a trust broker configured to receive a communication from a requestor entity to provide a solicitation for a recipient entity to enable at least one entity to partake in an activity;

[29] the trust broker being configured to verify the authenticity of the requestor entity [30] the trust broker being configured to generate a pending solicitation that includes data relevant to at least one of the requestor entity and the recipient entity;

[31 ] the trust broker being configured to generate a unique requestor verification code a nd a unique recipient verification code for delivery to the requestor entity and the recipient entity;

[32] the trust broker being configured to communicate to the requestor entity the pending solicitation, the unique requestor verification code and the unique recipient verification code;

[33] the system being configured to ena ble communication of the pending solicitation to the recipient entity, the unique requestor verification code a nd the unique recipient verification code; and

[34] the system being configured to enable at least one of the entities to partake in the activity if there is receipt of a communication of at least partial acceptance of the pending solicitation from the recipient entity, and if the requestor entity verifies the unique requestor verification code for the benefit of the recipient entity, a nd if the recipient entity verifies the unique recipient verification code for the benefit of the requestor entity is affected.

B rief Des cription of the Drawings

[35] Notwithsta nding a ny other forms which may fall within the scope of the presently disclosed systems a nd methods, various embodiments will now be described, by way of example only, with reference to the accompanying drawings in which:

[36] FIG . 1 depicts a generic overview of the disclosed two-way verification platform method and system;

[37] FIG . 2 also depicts a generic overview of the disclosed two-way verification platform that also includes registration of data;

[38] FIG . 3 depicts an email scena rio of the disclosed two-way verification platform method a nd system;

[39] FIG . 4 depicts a verbal scenario of the disclosed two-way verification platform method a nd system;

[40] FIG . 5 depicts a new user signup scena rio of the disclosed two ^' way verification platform method and systems;

[41 ] FIG . 6 depicts a n existing user login scenario of the disclosed two ^' way verification platform method and systems; a nd [42] FIG . 7 represents the disclosed physical system of the trust broker a nd a plurality of entities.

Des cription of E mbodiments

[43] It should be noted in the following description that like orthe same reference numerals in different embodiments denote the same or similar features.

[44] Disclosed is a platform and a method of a platform implemented at least in pa rt by a computing device for configuring trust between at least two entities being a requestor entity and a recipient entity so that at least one of the entities may partake in an activity. As mentioned above, there are situations in which a user cannot be sure about the trustworthiness of entities with which the user may which to have dealings. The examples provided above include when signing onto a website, receiving calls from call centres and receiving unsolicited emails. Other examples include an existing user login, requesting a rideshare service, a computer system requesting access to a 3rd party computer system, and allowing a user to connect to a remote computer system. While some of the details of these other examples may involve some different processes orsteps, the overall mecha nisms may involve the same or similar processes or steps. It is understood that qualifications, for example, alternative process step orders and multiple parties, made a pply to all of the figures showing various embodiments.

[45] FIG . 1 is illustrative of a process of the disclosed platform method. Two entities, E ntity A 101 and E ntity Z 103 are Requestor E ntity 101 a nd R ecipient E ntity 103, respectively. While the typica lly depict two entities, the Requestor E ntity 101 a nd the R ecipient E ntity 103 along with a Trust Broker 105, the present description in no way limits the number of entities that can be involved in a transaction, including the number of Trust Brokers. The entities and one or more trust brokers can be located remotely from one another, wherein communication is via, for example the Internet, but can also be via a n Intranet. All forms of communication, including telephone communication, or face-to-face communication are within the scope of this discussion.

[46] An activity 107 can be any type of activity. For example, the activity can be can be a requestto become involved in a game, an event, or sign up for a free offer. Any activity is within the scope of this discussion. In an initial pa rt of the process, the Requestor 101 can solicit engagement of E ntity Z, the Recipient 103 so that the recipient might partake in the activity. However, between the R equestor 101 and a R ecipient 103 is the T rust Broker 105. T hat is, in the initial process, the Requestor 101 involves the Trust Broker 105. T he T rust Broker 105 receives the S olicitation (S ) 109 and creates a new Request or Contract (C).

[47] The Request or Contract (C) ca n be one or more terms. In one embodiment, the R equest or Contract (C) can include a plurality of terms that the Recipient can accept either in whole or partially. Depending upon the terms accepted, the process may continue. In different cases, if certain terms are not accepted, the process may not proceed. But, for the sake of simplicity in this discussion, a simple Request (C) ca n suffice for explanation purposes.

[48] In the next step, before or simulta neously with generation the Request or Contract (C) 1 1 1 , the T rust Broker 103 generates a R equestor C ode (X) a nd a Recipient C ode (Y) 1 13. All of these details are sent to the R equestor 101 at step 1 15. The reason that they are sent to the Requestor 101 is that eventually, the Requestor will need to verify the Requestor Code (X) and the Recipient C ode (Y) with the Recipient 103. That is, ultimately, if receipt of a communication of at least partia l acceptance of the pending solicitation from the Recipient E ntity 103 is effected, and if the Requestor E ntity 101 verifies the unique requestor verification code (X) for the benefit of the recipient entity is effected, and if the recipient entity verifies the unique recipient verification code (Y) for the benefit of the requestor entity is affected, then at least one of the entities is enabled to partake in the activity.

[49] In the generic overview of FIG . 1 , either after, before or simultaneously with receipt of the (C), (X) a nd (Y) by the Requestor 1 1 5, the Recipient E ntity 103 ca n a lso be notified 1 17 as well as the same (C), (X) and (Y) can be received by the Recipient E ntity 103 1 19. In a figure later discussed, it is eitherthe Trust Broker 103 or the Requestor E ntity 101 that notifies the Recipient E ntity 103. In either event, the Recipient E ntity 103 can either accept 1 19 or not accept 121 the solicitation (S ) that culminates in the (C), (X) a nd (Y) and the Requestor E ntity 101 ca n be notified 123 of the result. That is, ultimately, if receipt of a communication of at least partia l acceptance of the pending solicitation from the Recipient E ntity 103 is effected, and if the Requestor E ntity 101 verifies the unique requestor verification code (X) for the benefit of the recipient entity is effected, and if the recipient entity verifies the unique recipient verification code (Y) for the benefit of the requestor entity is affected, then at least one of the entities is enabled to partake in the activity.

[50] The platform system a nd method therefore provides the ability to establish trust as all entities need to prove themselves as trusted. The two-way verification process requires that at the point of an engagement, each entity ^' s identity is verified, and a solicitation is accepted or in the alternative a contract is formed between them. T here is a R equester E ntity 101 (the entity that initiated the engagement) and 1 or more Recipient E ntities 103 (other entities in which the requestor wishes to engage, to complete an activity). A solicitation that includes a contract can hold relevant information about the engagement, including types of communication allowed between the entities, such as via email or by S MS , times and dates of communication, and other physical attributes of communication between the entities. Additiona lly, codes (X) and (Y) a re generated a nd assigned to each entity. These codes a re unique to each entity, and assigned on a per contract or request basis. This is valuable, as it allows the entities to exchange a nd disclose information that is s pecific to the engagement contract, without offering persona lly identifiable information which may later be used for fraudulent activity in other engagements. These unique codes enable a safe a nd verifiable process of excha nge between the entities during their engagement.

[51 ] In order to maintain anonymity of the parties, the T rust Broker 103 can be the recipient of the Code (X) of the Requestor E ntity 125 and Code (Y) of the Recipient E ntity 127 as illustrated in FIG . 1. Alternatively, the Code (X) and the Code (Y) ca n be exchanged directly. In either event, ultimately, if receipt of a solicitation (S) there is at least partia l acceptance of a pending contract or acceptance of a request by the Recipient E ntity 103 is effected, and if the Requestor E ntity 101 verifies the unique requestor verification code (X) for the benefit of the recipient entity is effected, and if the recipient entity verifies the unique recipient verification code (Y) for the benefit of the requestor entity is affected, then at least one of the entities is enabled to partake in the activity.

[52] FIG . 2 provides a nother overview, in this figure showing the recordation and storage aspects of the platform. Again, a Requestor 201 provides an activity for which the R ecipients) 203 may partake. This particular activity 207 requires each entity to verify themselves to establish trust. In a different situation, a Recipient 203 may require trust of the R equestor. That situation is described below.

[53] As in FIG . 1 , a lso here shown in FIG . 2, a solicitation (S) 209 is sent to engage with recipient(s) and initiate a two-way verification. The platform system receives, verifies a nd creates the verification request (C), along with uniquely created verification codes (X) and (Y). T hese details are stored in a data store 231 and/or written to a Iedger 233 for auditability. T his registration 235 can occur in any suita ble manner.

[54] The entities are notified 237 in any suitable order, and in fact, the notification process can occur depending upon which of the entities requires the disclosed two-way verification process. In any event, details (C), (X) and (Y) are sent to the requestor 215 and sent to the recipient 219. As discussed a bove, in the verification process 239, if receipt of a solicitation (S ) there is at least partial acceptance of a pending contract or acceptance of a request by the R ecipient E ntity 203 is effected, and if the R equestor E ntity 201 verifies the unique requestor verification code (X) for the benefit of the recipient entity is effected, and if the recipient entity verifies the unique recipient verification code (Y) for the benefit of the requestor entity is affected, then at least one of the entities is ena bled to partake in the activity.

[55] Referring to FIG . 3, in the activity section 307, a situation is depicted where an unexpected tra nsaction occurs on an entity ^' s account, so a bank suspends the subject account. The bank needs to email the entity requesting that the entity contact the ba nk immediately as the subject account has been suspended. S imilarto above depictions, the solicitation (S ) is provide and registered 335, a two-way notification 337 is provided. In this situation, there is a manual verification process 341 can occur. For example, the ba nk ca n create a n email 319 to the recipient entity 303 and include details (C), (X) a nd (Y). At this point, there are various options that the recipient entity 303 may take to verify the email 319 sent from the Requestor 301 depending upon the configurations provided. It is understood that va rious manners in which for the R ecipient E ntity 303 to verify the authenticity of the R equestor E ntity 301 within the spirit of that which is described herein.

[56] FIG . 3 illustrates a manual verification 341 can include an email from the R equestor 301 to the Recipient 303 whereby the R ecipient 303 chooses to verify the authenticity of the Requestor 301 by visiting 345 the T rust Broker s 305 or the Ba nk s verify page verify page 351. T here, the R ecipient 303 enters the verification codes found in the email, into the verify website 347. The verify website returns the verification details registered by the original request The R ecipient 303 can compare the registered email against the email he received. The R ecipient 393 now trusts the authenticity of the email, and call the R equestor (the Bank) to solve the issue.

[57] FIG . 4 depicts a n activity in 407, where a Telco finds that a customer s credit card on file has expired, and that their current plan is up for renewal. A representative of the Telco 401 contacts the Recipient customer 403 by phone to address the aforementioned issues. S imilarto the above depictions, the solicitation (S ) is provided a nd registered 435, a two-way notification 437 is provided. In this circumstance, the solicitation is triggered through an integration with the Telco s C ustomer Ma nagement system 409. The R ecipient 403 receives a n electronic notification 419 of the engagement details (C) , (X) a nd (Y), a nd is able to review its details either manually or automatically before continuing with the activity 407. [58] Also in FIG . 4 is a verbal or electronic verification 441 whereby the Requestor 401 a nd Recipient 403 either orally or via electronic communication exchange their issued a nd unique verification codes 443 445, for the other party to compa re against those received by the Trust Broker 445 447. Once each entity has exchanged a nd verified the verification codes, trust may have been established for the recipient (authenticity of the caller) and the requestor (ID check of recipient). As an added safety measure, either entity can visit the Telco or Trust broker s verify page 449 to confirm the details received.

[59] In FIG . 5 a n activity 507 is initiated where a Recipient 503 is engaged with a website a nd makes a selection of an item from an online e ^' commerce store 501. In one example scenario, the Recipient 503 a product is added to a n online shopping ca rt a nd the checkout process 509 is initiated. The solicitation of the two ^' way verification request 535 is made by the e ^' commerce store 501 , to the T rust Broker 505, as part of the signup / checkout process 534. As with previous depictions, the details of the two ^" way verification (C) and the unique verification codes (X) and (Y) a re returned to the R equestor 515 and sent to the Recipient 519 via electronic communication to ena ble the verification process 541.

[60] The Requestor 601 displays their verification code 545 on their signup /checkout page upon receiving the response from the Trust Broker 605, allowing the recipient to review a nd compare against the details they received 543. If after successful verification of the details the Recipient 603 determines to continue the activity, notification ca n be provided the Trust Broker 605 by accepting the signup invitation 549 by electronic communication, which can subsequently send a notification of the outcome to the R ecipient 547 so the signup/checkout activity can be appropriately finalised. In this scenario, the Requestor 601 may require the Recipient 603 to provide their unique verification code to confirm the method of electronic communication as well as the R ecipient entity 603 itself as part of the final steps of the signup/checkout activity 547.

[61 ] The scenario depicted in FIG . 6, where an entity engages in a login process activity 607 to their existing email provider to check for new email. The recipient 603 visits the website 608 of the requestor 601 , a nd initiates a login process 609, whereby as in previous scena rios the requestor solicits a two ^' way verification request to the trust broker (S ). The T rust Broker 605 receives, verifies and creates the verification request (C) a long with unique codes for each entity (X) a nd (Y), which is stored in the platform data store 631 and written to the ledger for auditability 633. [62] As in previous scenarios, the details of the two ^' way verification (C) are returned to the requestor 615 a long with the verification codes for each entity (X) (Y). T he R equestor 601 can display their unique verification code on the website login page 645 for the Recipient 603 to compare against those that they received 619 from the T rust Broker 605. As the recipient is able to compare the disclosed requestor code (X) via the Requestor s login page, against those received 643 from the T rust Broker 605, authentication of the website is determined for the email provider. The Recipient 603 can continue the login activity, wherein they a re provided an electronic option to accept the login invitation by electronic res ponse 649 to the Trust Broker 605. S ubsequently, the Requestor 601 is electronically notified of the solicited outcome 647 a nd they can finalise the login activity. In this scenario, as in FIG . 5, the Requestor 601 may require the Recipient 603 to enter their unique verification code to confirm the method of electronic communication for the Recipient 603, in addition to confirming the recipient entity itself by a login process 647.

[63] FIG . 7 depicts the physical system of the trust broker and plurality of entities, including R equestors 780 788, Recipients 760 768 and the Trust Broker 771 entities. As previously described, to enable solicitation and activity engagement, the Trust Broker is typica lly configured to accept network communication using TC P/IP based protocols, in pa rticula r HTTP and HTTPS from the Internet, and from other public & private networks. The transceiver 776 allows forthis network communication to occur between public and private networks, as well as directly from wide a rea networks (WAN) such as the internet, in addition to local area networks (LAN) such as a home or office computer network. T he network can be a wired E thernet network, wireless network, Bluetooth network or IE E E 802.1 1 network. Recipients 760 768 can use the transceiver 766 to communicate with the trust broker directly 754, as well as other Recipients 756 a nd Requestors 758 792, with access enabled but not limited to Internet S ervice P rovider or 3G/4G telephony provider, or any other suitable communication cha nnel. S imilarly, R ecipients 760 768 can communicate with subsequent Requestors 750 794 to participate in the solicited activity, as well as communicate directly 754 796 with the Trust Broker 771. T he R equestors 780 788 can communicate 752 798 with the Trust Broker 771 to solicit, receive, and verify a two ^' way verification. Requestors 780 788 can communicate 790 directly with each other as ca n Recipients 760 768. This may enable a circular network effect between entities that can ensure that the network is a lmost always availa ble a nd accessible, and thus improve service availability over other forms of network design. The described transceiver 776 a lso enables secure communication to supporting ha rdware a nd systems, such as the data store 231 and ledger store 233 to ensure that solicited requests by entities can be received, verified a nd responded to accordingly. This may be critical as the solicitation of a two ^' way verification request can have singular or multiple number of recipients, and therefore the network communication preferably interoperate between each entity directly, and the T rust Broker 771 to deliver an outcome for the solicited activity.

[64] E ach recipient comprises of a system containing memory 764 such as a form of random access memory (RAM) or read only memory (R OM), a nd the memory 764 ca n comprise of either RAM or R OM, or a combination of both RAM and R OM. Requester entities can a lso contain memory 784, as well as a S erver configured as a Trust Broker 774 with the same optionality as described for the recipient entity. While components a re shown in loca l configurations, of course, components can be remote to one a nother. T he processing of arithmetic instructions is computed with a central processing unit (C P U) or graphica l processing unit (G P U) 762 772 782. The processing of instructions may comprise of both C P U and G P U computation, or either C P U or G P U, depending on the size and complexity of the instructions that require processing. Typica lly, the memory and processing hardware would interoperate to achieve the desired processing and returned output, given the instructed activity initiated or received by the tra nsceiver of each entity. T he Trust Broker 771 can be configured to interoperate with processing 772 and memory 774 hardware to accept, establish, generate and respond with the appropriate data a nd verification codes for the solicited two ^' way verification request, in addition to communicating with each associated entity operationally through the transceiver 776 and associated network connectivity 752 754. In the event that encryption of data is required, a hardwa re security module 778 can be accessed, should it be available, to ensure the accelerated speed, quality and security of processing the cryptographic requirements, and may be used in conjunction with the C P U and G P U 772 to complete the encryption. This may include but not be limited to asymmetric and symmetric cryptographic methods, as well as key derivative and public key infrastructure (P KI) methodologies, for purposes including securing data in transport, securing data at rest, providing proof of identity, or providing digital signatures.

Definitions

[65] Activity: An action, system or process that triggers the Verification process. For example: a call from a C all Centre; S igning up for a new Mobile phone pla n; Receiving an email from an orga nisation;

[66] Broker The trusted entity, system or network that establishes, moderates, governs and validates other entities; [67] Contract (C) or R equest: A documented agreement which ca ptures the details of an engagement which ca n also be in the form of a requisition with one or no actual terms. An accepta nce of a contract ca n be an acceptance of the whole contract, or an acceptance of one or more terms. An acceptance of a request or contract, can be acceptance of one term, or simply the allowance of the process to continue.

[68] E ntity / E ntities: A thing of existence, such as person, team, organisation, system, platform or device;

[69] E ngage / E ngagement or Pa rtake in an Activity: An act with the intention of connecting, following, verifying, validating, registering or tra nsacting with another entity or entities;

[70] Notify / Notification: The act of communicating between entities, to invite, exchange, update, add, delete, request or register an intention, relating to an engagement.

[71 ] S olicitation (S ): The act of initiating a contract, request or engagement to partake in an activity, which is received by a trusted entity. The authenticity of a solicitation is verified before a contract or request is created to ca pture the engagement.

[72] Requestor: The entity which initiated the request to engage Requestor Code (X) S ee Verification Codes

[73] R ecipient: T he entity or entities which have been solicited to participate in a n engagement

[74] Recipient Code (Y): S ee Verification C odes

[75] T rusted E ntity: S ee Broker

[76] Verification: The act of confirming the identity and authenticity of an activity or entity

[77] Verification Codes: T hese are unique codes generated for each entity involved in a contract, which are unique to the contract itself. They cannot be reused with other contracts or requests, therefore making them safe to exchange during a n engagement.

Interpretation

E mbodiments:

[78] U nless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary s kill in the art to which this invention belongs. It will be further understood that terms used herein should be interpreted as having a mea ning that is consistent with their meaning in the context of this specification a nd the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. For the purposes of the present invention, additional terms are defined below. F urthermore, all definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordina ry mea nings of the defined terms unless there is doubt as to the meaning of a pa rticular term, in which case the common dictionary definition and/or common usage of the term will prevail.

[79] T he terminology used herein is for the purpose of describing pa rticular embodiments only and is not intended to be limiting of the invention. As used herein, the singular a rticles a _, a n. and ^' the . are intended to include the plural forms as well, unless the context clearly indicates otherwise and thus a re used herein to refer to one or to more than one (i.e. to at least one J of the grammatica l object of the article. By way of example, the phrase an element _, refers to one element or more tha n one element.

[80] The term about _, is used herein to refer to quantities that vary by as much as 30%, preferably by as much as 20%, and more preferably by as much as 10% to a reference quantity. T he use of the word :abouf to qua lify a number is merely an express indication that the number is not to be construed as a precise value.

[81 ] Throughout this specification, unless the context requires otherwise, the words comprise _, comprises _, and comprising _, will be understood to imply the inclusion of a stated step or element or group of steps or elements but not the exclusion of a ny other step or element or group of steps or elements.

[82] The term Veal-time _, for example ^' dis playing real-time data, _, refers to the display of the data without intentional delay, given the processing limitations of the system and the time required to accurately measure the data.

[83] As used herein, the term exempla ry _, is used in the sense of providing examples, as opposed to indicating quality. That is, an exemplary embodiment _, is an embodiment provided as an example, as opposed to necessarily being an embodiment of exempla ry quality for example serving as a desirable model or representing the best of its kind.

[84] T he phrase and/or, . as used herein in the specification a nd in the claims, should be understood to mean either or both _, of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with and/or. should be construed in the same fashion, i.e., one or more _, of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the a nd/or. clause, whether related or unrelated to those elements specifically identified. T hus, as a non-limiting example, a reference to Ά and/or B _, when used in conjunction with open-ended language such as comprising . can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optiona lly including other elements); etc.

[85] As used herein in the specification a nd in the claims, or. should be understood to have the same meaning as and/or. as defined above. For example, when sepa rating items in a list, or. or and/or. sha ll be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, a nd, optionally, additiona l unlisted items. Only terms clearly indicated to the contrary, such as only one of. or exactly one of, _, or, when used in the claims, consisting of. will refer to the inclusion of exactly one element of a number or list of elements. In general, the term or. as used herein shall only be interpreted as indicating exclusive alternatives (i.e. one or the other but not both J when preceded by terms of exclusivity, such as either, _, one of, _, only one of, . or exactly one of.. ^' Consisting essentially of, . when used in the claims, shall have its ordina ry meaning as used in the field of patent law.

[86] As used herein in the s pecification and in the claims, the phrase at least one, _, in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition a lso allows that elements may optionally be present otherthan the elements specifically identified within the list of elements to which the phrase at least one . refers, whether related or unrelated to those elements specifica lly identified. Thus, as a non- limiting example, at least one of A and B . (or, equivalently, at least one of A or B, . or, equivalently at least one of A and/or B J can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (a nd optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optiona lly including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

Different Instances of Objects

[87] As used herein, unless otherwise specified the use of the ordinal adjectives ^' first., second _, ^' third _, etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either tempora lly, spatially, in ranking, or in a ny other manner. S pecific Details

[88] In the description provided herein, numerous s pecific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Comprising and Including

[89] In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express la nguage or necessary implication, the word comprise _, or variations such as comprises _, or comprising _, are used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention. Any one of the terms: including or which includes or that includes as used herein is also an open term that also mea ns including at least the elements/features that follow the term, but not excluding others. T hus, including is synonymous with and mea ns comprising.

S cope of Invention

[90] Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim a ll such cha nges and modifications as fall within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functiona lity may be added or deleted from the block diagrams and operations may be intercha nged among functiona l blocks. S teps may be added or deleted to methods described within the scope of the present invention.

Industrial Applicability

[91 ] It is apparent from the above, that the a rrangements described a re applicable to industries involving communication.