A system for a web platform marketplace of goods and services including a settlement / arbitration algorithm and using blockchain technology

Abstract

A system for Web platform marketplace of goods and services, characterized by a novel settlement / arbitration algorithm that increases transactions' fairness and preserves both purchaser's and vendor's rights. Purchaser can acquire credits from platform and use credits to buy goods / service, with reciprocal rating. If purchaser acknowledges he received what agreed, credits are transferred to vendor; otherwise settlement / arbitration process is started and will define the dispute in a short and well defined maximum time. Transactions can be supported by blockchain technology with related advantages. Platform can allow the credits usable for transactions to be converted in a proprietary cryptocurrency.

Description

[0001] A system for a web platform marketplace of goods and services including a settlement / arbitration algorithm and using blockchain technology.

[0002] Description

[0003] Background of the invention

[0004] So many transactions simply do not happen because of lack of trust among the Parties. If the good / service is paid in advance, the vendor can provide something well below the agreement, or simply do not provide anything. If the good / service is paid at the end, the buyer cannot pay claiming false defects or simply closing communications and disappearing. If payments is on steps, the problem is split or divided but it remains present. Recurring in Court is expensive and it takes very long for a solution.

[0005] Prior art

[0006] Several forms of guarantees are used to allow transactions, from the Escrow agents to Letter of Credit and many others, but all are expensive and / or complicated.

[0007] While several web marketplace platforms (including Amazon, Alibaba, etc..) guarantee that the goods will be exactly as ordered or the buyer will get the money back, the Applicant has not found platforms that allow the same safety for services, at least not with a well-defined semi-automated settlement and arbitration algorithm set to solve disputes.

[0008] Especially when vendor and buyer do not know physically each other, several transactions will not even be considered: for example a software bug will not be fixed by an unknown person thousands km far away, even if the internet does not make difference between 10m and 10.000 km distance. When a parent buys a private lesson of Homeric Greek for his child, the web Platform cannot guarantee that the child will learn; Platform can guarantee that when the lesson will be held, the teacher will be paid.

[0009] Blockchain is a recent technology characterized by Distributed Ledger technology DLT, immutability of the Ledger, transparency and traceability, cryptography safety. The use of Blockchain technology for an open digital marketplace is not very diffused yet and it is innovative in the way it is applied in the instant invention.

[0010] Description of the invention

[0011] This patent discloses and claims a useful, novel, and unobvious invention for Web platform marketplace of goods and services, characterized by a settlement / arbitration algorithm with the possibility of using blockchain technology for transactions.

[0012] The fully automated settlement algorithm shows to the Parties of the transaction what they agreed, obliging them to describe what in each point of view does not match or vice versa; maximum time for reciprocal answer is clearly set and automatically reminded to the Parties. In case one Party does not respond on time, Platform will consider that he tacitly accepts the other Party rightfulness. Parties can reach an agreement different from the initial one; in case of no agreement, it is possible to recur to the human arbitration that is bonded on what initially agreed and on communications / descriptions made inside the Platform by the Parties during settlement phase.

[0013] This patent presents an innovative, practical, and non-obvious invention for a webbased marketplace platform for goods and services. This invention is defined by a settlement / arbitration algorithm, which offers the flexibility of implementing blockchain technology for transaction processes.

[0014] The automated and trust settlement algorithm displays to the transaction Parties the details of their agreement, requiring them to specify any areas of disagreement or conformity, from their respective viewpoints. A strict timeframe for reciprocal responses is established and automatically prompted to the Participants. If a Party does not respond within this timeframe, the platform will interpret this as tacit acceptance of the other Party's position.

[0015] The Parties have the latitude to reach a settlement different from the initial agreement. In instances where consensus cannot be achieved, the system offers the option to resort to human arbitration. This arbitration is tethered to the initial agreement, to the possible new agreement reached during settlement process and to the communication / descriptions provided within the platform by the Parties during the settlement phase.

[0016] The utilization of blockchain technology in this model ensures transactional transparency and immutability.

[0017] As said, the invention refers to a system for a web platform marketplace of goods and services.

[0018] Preferably, the system increases transactions’ fairness.

[0019] Preferably, a transaction includes at least two Parties.

[0020] Preferably, the Parties include a Buyer and a Seller.

[0021] Preferably, wherein the system preserves both Buyer’s and Seller’s rights.

[0022] Preferably, Buyer is associated with a respective wallet.

[0023] Preferably, Seller is associated with a respective wallet.

[0024] Preferably, an automated intervention of the settlement / arbitration algorithm is provided, in case of disputes.

[0025] Preferably, the settlement / arbitration algorithm ensures fairness by adhering to preset terms and conditions.

[0026] Preferably, a settlement algorithm is provided.

[0027] Preferably, according to said settlement algorithm, if Buyer considers that he / she has not received, from Seller or on behalf of Seller, the good / service according to the agreed terms, Buyer can initiate a complaint.

[0028] Preferably, in order to initiate the complaint, Buyer starts a negotiation via the platform.

[0029] Preferably, according to said settlement algorithm, the Parties explain their motivations and try to solve the dispute by reaching an agreement.

[0030] Preferably, according to said settlement algorithm, an amount corresponding to the good / service according to the agreed terms is not transferred yet from the Buyer’s wallet when the settlement process is started. Preferably, the settlement algorithm is executed after a complaint.

[0031] Preferably, according to said settlement algorithm, a Party's failure to respond within the specified timeframe is interpreted by the platform as an implicit acceptance of the opposing Party's position.

[0032] Preferably, implicit acceptance of the opposing Party’s position leads to a swift resolution of disputes.

[0033] Preferably, implicit acceptance of the opposing Party’s position causes credits to be moved accordingly.

[0034] Preferably, an arbitration algorithm is provided.

[0035] Preferably, the arbitration algorithm is made accessible to each Party only after the compulsory steps of the settlement algorithm have been executed without leading to acceptance.

[0036] Preferably, said steps of the settlement algorithm are at least three compulsory steps, including: Buyer’s complaint, Seller’s response and Buyer’s counterresponse.

[0037] Preferably, according to said arbitration algorithm, a human arbiter is guided by the system algorithm.

[0038] Preferably, the human arbiter must take a decision only within the specific frame.

[0039] The invention can comprise one or more of the following preferred features.

[0040] Preferably, said settlement algorithm empowers Parties with the ability to renegotiate and reach a settlement that deviates from the initial agreement.

[0041] Preferably, said settlement algorithm offers a flexible framework for dispute resolution

[0042] Preferably, according to said settlement algorithm, the Buyer can accept or reject the Seller’s standard offer.

[0043] Preferably, according to said settlement algorithm, the standard offer can be negotiated between the Parties. Preferably, according to said settlement algorithm, the negotiated offer can become a customized offer and / or a new standard public offer.

[0044] Preferably, in case of accepting the offer (standard or customized), the system checks the credit in Buyer’s wallet or account.

[0045] Preferably, the system warns the Buyer both via e-mail and platform inbox if the credit amount is lower than said amount.

[0046] Preferably, if the credit amount is equal or greater than said amount, Parties are informed both via e-mail and platform inbox that the transaction process is started.

[0047] Preferably, Seller has the possibility to inform the platform that service / good was delivered.

[0048] Preferably, following the Seller’s information regarding the service / good having been delivered, the platform automatically emails / inboxes the Buyer that he is required to either recognize the transaction completion, or start settlement process within a fixed (parametric) time.

[0049] Preferably, the platform sends the Buyer automatic scheduled reminders before a set deadline.

[0050] Preferably, in case Buyer does not answer within the set deadline, the system considers that Buyer tacitly acknowledges Seller’s statement and moves credits accordingly.

[0051] Preferably, some or all processes including Settlement / Arbitration algorithm can operate using either traditional digital technology or blockchain technology, based on the administrator's choice.

[0052] Preferably, the system further includes a human arbitration component that becomes accessible in situations where the automated resolution does not achieve consensus.

[0053] Preferably, the human arbitration component operates within the boundaries of the initial agreement or the new renegotiated agreement. Preferably, the human arbitration component takes into consideration communications and descriptions furnished on the platform by the involved Parties via the settlement algorithm.

[0054] Preferably, a server providing the contract management and settlement and arbitrage service is provided.

[0055] Preferably, said server can be connected to a blockchain network with a p2p (peer- to-peer) connection to include the data of the agreement obligation, including the virtual currency and its amount, becoming a method to provide a P2P contract management service using a blockchain-based or non-blockchain-based virtual currency that is stored to be distributed among at least two or more public nodes.

[0056] Preferably, the system endows involved Parties with the capacity to renegotiate the terms of the transaction, allowing them to reach a settlement that deviates from the initially encoded agreement or smart contract agreement.

[0057] In particular, Parties can negotiate in order to set a transaction; Parties can renegotiate during settlement, i.e. the phase started by a complaint. The agreement can be on traditional digital or smart contract.

[0058] Preferably, in both cases of traditional or blockchain technology, the web platform provides intuitive user interface tools to facilitate the management and use of credits, their conversion into ERC20 tokens or similar tokens, this conversion increasing the versatility of the system, as these tokens can be traded on the open market, allowing users to take advantage of market fluctuations.

[0059] Preferably, the web platform includes a module for real-time tracking of the conversion rate between the credits and the ERC20 token or similar token.

[0060] Preferably, the web platform provides a secure digital wallet for each user, facilitating the safe storage, usage, and conversion of credits and ERC20 tokens or similar tokens.

[0061] Preferably, the cryptographic component of the blockchain is utilized to implement ScriptPubKey, a locking script that outlines the unique conditions that must be met for the IITXO to be expended or employed in the settlement / arbitration process. Preferably, the system incorporates the Unspent Transaction Output (UTXO) model, which is a model in which each transaction is linked to a distinct UTXO that uniquely signifies a specific quantity of cryptocurrency.

[0062] Preferably, the ScriptPubKey is configured to mandate a multi-signature requirement, thereby ensuring that a predetermined number of Parties must grant authorization for any arbitration outcome.

[0063] In an embodiment, until a final decision is made by executing the settlement algorithm and possibly the arbitration algorithm, the amount corresponding to the good / service according to the agreed terms is not transferred from the Buyer’s wallet

[0064] In an embodiment, when a final decision made by executing the settlement algorithm and possibly the arbitration algorithm implies that the Seller has to receive said amount, such amount is transferred from the Buyer’s wallet to the Seller’s wallet.

[0065] Transaction, settlement and arbitration

[0066] Transaction, settlement, arbitration process is described in detail in the algorithm presented in Figures 1a-1d.

[0067] A. Transaction

[0068] The Platform hosts a marketplace where Buyers and Sellers use the Platform's credit as a means of exchange in order to complete transactions. In this context, the platform allows the credit exchange only when both Seller and Buyers are compliant with all the required conditions for the transaction by modulating disputes through a settlement and arbitration algorithm. The system allows the conversion of transaction Credits into a national currency or into a corresponding specified cryptocurrency.

[0069] Once the good / service to be purchased has been identified based on the active offers available in the system, the Buyer can select the offer of interest by opening the offer detail sheet. In this detail sheet, in addition to the information relating to the goods / service, the Buyer can decide the purchase action by pressing the relevant button or go back and continue with his search.

[0070] Parties can negotiate and agree on a different / personalized offer, as described more in details in the algorithm.

[0071] After good / service has been supplied by the Seller, the latter has the possibility to inform the platform that the good / service has been delivered through a specific button and can add a note. Following this action, the platform will send an email to the Buyer urging them to close the deal or to start the settlement process as described in the algorithm. After the "x" parametric time, the Buyer’s consent will be considered implied and the sales process will be closed.

[0072] B. Settlement

[0073] If Buyer considers he has not received the good / service according to the agreed terms, he can initiate a complaint and start the negotiation in which Parties explains their motivations and try to solve the dispute by reaching an agreement. This process, called Settlement Process, ensures communication between the Parties without platform interference.

[0074] Buyer is required to motivate his “No, I have a problem”, texting a “complaint” with / without attachments. It starts the settlement process.

[0075] Seller is required to answer the complaint within a fixed time and Buyer to respond to the answer within a fixed time, with automatic scheduled reminders from the Platform; from this point on, Parties can either continue negotiation (as long as they consider and without time limits for answers) or can require arbitration. In case one Party does not respond on time, the Platform’s system will consider that this Party tacitly accepts the other Party rightfulness.

[0076] Parties can agree about changes of the initial agreement (make a discount, send new product, modify or integrate the service etc); in this case Buyer receives back in his wallets the credits corresponding to the initial agreement, and the new amount of credits gets frozen. Buyer can acknowledge fulfilment of the new transaction or require arbitration, within a fixed time; in case Buyer will make no action will be consider implicit transaction fulfilment acknowledgement.

[0077] C. Arbitration

[0078] Buyer or Seller may begin the arbitration process if and only if the Settlement process has not been concluded with an agreement, Parties have completed the 3 compulsory steps for Settlement (namely: Buyer’s complaint, Seller’s answer and Buyer’s response to Seller’s answer) and one of the Parties pushes the Request arbitration button.

[0079] Once enabled, the Request Arbitration button will be visible to both Seller and Buyer.

[0080] Before enabling the button, Platform’s back-office can activate actions (separately or together):

[0081] It can be activated a pop-up informing that if arbitration is requested, the losing Party will have to pay a fee (parametric established by the back-office). In this case, whoever wants to access the arbitration must freeze a credit equivalent to the fee. If the User requesting arbitration does not have enough credit, he will have to top up his wallet. If the applicant wins the arbitration, the Platform will automatically transfer the frozen credits to the applicant's wallet, the back-office will manually transfer the equivalent of the arbitration fee.

[0082] If the losing Party is not the User requesting arbitration, Platform cannot coercively withdraw his credit; therefore the above procedure refers. Other solutions will be taken in case the losing Party did not request arbitration. The credit freezing described above is a separate transaction to be tracked on the application. Therefore, like the sales process, there will be a reference to the "Arbitration Fee" transfer type.

[0083] Arbiter will receive from Platform a pre-set pack of information and he is allowed to ask questions to the Parties as described in the algorithm. No automatic penalties for late or missing response by Parties, even if proactivity and willingness to find a settlement will be positively considered. Platform shows to Arbiter the following data for analyses:

[0084] 1 . Data of offer or possible new agreement

[0085] 2. Buyer’s complaint, Seller’s answer and Buyer’s response (compulsory passages for the Parties)

[0086] 3. Other communications available on the Platform; Arbiter cannot evaluate information other than what described before.

[0087] Blockchain use

[0088] Blockchain has several features such as: decentralized Ledger, immutability of the Ledger, transparency and traceability (within an inside the blockchain), cryptography. The practical benefits for decentralized Ledger is that an hypothetical dictator can change my real estate ownership from the cadastre Ledger and Notary archive, he cannot from the Blockchain. Furthermore once a block has been added it is possible to add new blocks but nobody and nothing can change what it has been done previously.

[0089] Blockchain technology is not new but the Applicant considers that Platform is innovative and it is innovative the way blockchain is applied to the Platform according to the present disclosure. The system is versatile in its technological underpinning, as it can operate on either traditional digital technology or blockchain technology. Blockchain, in Particular, introduces an unprecedented level of transparency and security to the arbitration process. Every transaction is recorded on a decentralized, immutable ledger. This not only allows for complete traceability but also assures that no single Party can unilaterally alter or delete past transaction records. This unique feature of blockchain significantly enhances the reliability and trustworthiness of the system's arbitration mechanism. An additional strength of the system lies in its adaptability. The choice of technology, whether traditional or blockchain, can be determined by the administrator based on the specific requirements and constraints of the platform. This flexibility ensures that the system can be optimized for different contexts and can adapt to evolving technological landscapes. When the blockchain option is selected, the arbitration process benefits from enhanced transparency and verifiability. Blockchain's decentralized and immutable nature allows for an open review of transactions, which can be instrumental in resolving disputes fairly. This innovative use of blockchain technology in the arbitration process sets a new standard for dispute resolution in digital marketplaces, promoting trust and encouraging further platform engagement.

[0090] In the context of the settlement system only based on blockchain technology, stakeholders initially have the opportunity to seek dispute resolution directly within the decentralized blockchain network. Should this direct resolution fail, arbitration becomes the fallback. Alternatively, Parties may prefer to initiate the arbitration protocol directly, skipping the attempt at blockchain-based non-arbitrated resolution.

[0091] Upon receiving an arbitration demand, the arbitrator interacts with the blockchain by broadcasting an acceptance / decision transaction on-chain. The acceptance / transaction, once verified and added to the blockchain, indicates the arbitrator's acceptance of the subrogation claim, consequently delisting it from the pool of pending arbitration cases within the blockchain network.

[0092] In certain implementations, the claim lodged on the blockchain, which could be represented as a smart contract or a series of linked transactions in a UTXO (Unspent Transaction Output) model chain, is also validated by the Parties to the claim. This validation is indicated by the broadcast and recording of acceptance transactions after the arbitrator has cleared any conflict check, or obtained approval from the Parties.

[0093] The arbitration demand transaction within the blockchain can specify preference parameters for an arbitrator. This might include holding credentials from a recognized professional organization, having membership in a professional society, being whitelisted by the involved Parties, or possessing specific qualifications for deciding disputes in arbitration. This opens a door for independent, freelance arbitrators to Participate, as they can accept arbitration demands broadcasted on the network.

[0094] This is in contrast to traditional systems where arbitrators are typically tethered to a specific insurance entity for adjudication of non-Party cases. In such systems, an insurer submitting a Party case to arbitration is expected to provide an arbitrator to hear a non-Party case, while obtaining an arbitrator from another insurer unrelated to the arbitration of the submitted case.

[0095] By leveraging the immutability and transparency of blockchain technology, this innovative approach ensures data integrity and disseminates the arbitration process across multiple nodes, thereby enhancing the efficiency and fairness of dispute resolution.

[0096] The step-by-step breakdown is:

[0097] 1 . **Dispute Initiation**: Parties involved in the subrogation claim can initially try to resolve the dispute directly within the blockchain network. If this attempt fails, they can initiate the arbitration process. Alternatively, they can skip the direct resolution attempt and demand arbitration from the outset.

[0098] 2. “Arbitration Demand**: The Parties demand arbitration by broadcasting a request transaction on the blockchain. This request can specify preference for an arbitrator with certain qualifications or credentials.

[0099] 3. “Arbitrator Acceptance**: The arbitrator accepts the arbitration request by broadcasting an acceptance / decision transaction on-chain. This action marks the subrogation claim as accepted by the arbitrator and removes it from the pool of available arbitration cases on the blockchain.

[0100] 4. “Claim Validation**: The subrogation claim, represented as a smart contract or linked transactions in a IITXO model chain, is validated by the involved Parties. Validation is indicated by the broadcast and recording of acceptance transactions on the blockchain after the arbitrator has cleared any conflict checks or obtained necessary approvals.

[0101] 5. “Dispute Resolution**: The arbitrator resolves the dispute based on the information and rules available on the blockchain. The outcome is recorded as a new transaction on the blockchain. 6. “Transparency and Security**: Blockchain technology ensures that all transactions and decisions are transparent, immutable, and secure, enhancing the efficiency and fairness of the dispute resolution process.

[0102] This approach allows for a high degree of flexibility and transparency, with the potential for freelance arbitrators to Participate in the network. It also contrasts with traditional systems where arbitrators are typically employed by a specific entity and may be expected to handle cases not directly related to their employer.

[0103] The focus behind the IITXO model in the present system is, that, these transaction outputs remain as "unspent" outputs until the owner uses them in a new transaction. At that point, they become "spent" transaction outputs and can no longer be used.

[0104] The Unspent Transaction Output (UTXO) model is a method used in some blockchains, most notably Bitcoin, for tracking the ownership of cryptocurrency. In the UTXO model, a transaction output is created whenever a transaction takes place, and these outputs represent a certain amount of cryptocurrency.

[0105] Each transaction output can only be used once and the whole amount in this output must be used in the transaction. When one wishes to make a transaction, he / she chooses a number of UTXOs he / she controls, which together make up an amount that covers the transaction value. If the total value of the selected UTXOs is more than he / she wants to spend, the transaction will also include a "change" output that sends the difference back to him / her.

[0106] Now, in the context of an arbitration system, there are several advantages to using a UTXO model:

[0107] “Transparency**: Since every transaction output is recorded on the blockchain, it's easy for any Party to trace the history of a transaction. This transparency can help in dispute resolution, as Parties can verify the entire history of transactions related to the dispute.

[0108] “Security**: Because UTXOs can only be spent by the owner of the private key, it provides security for the transactions. This can ensure that only the rightful Parties are involved in the resolution of a dispute. **Scalability**: The IITXO model can potentially offer greater scalability for handling multiple disputes simultaneously. Each transaction is independent, and they can be processed in parallel. This can make the arbitration process more efficient when dealing with a high volume of cases.

[0109] **lmmutability**: Once a transaction is recorded on the blockchain, it cannot be changed. This immutability is especially useful in an arbitration context, as it ensures that once a decision has been made and recorded, it cannot be altered or deleted. This provides assurance to all Parties that the arbitration process is fair and final.

[0110] In the present system based on IITXO, the 'ScriptPubKey' field can be leveraged to incorporate conditions that must be met for the transaction to be considered valid or completed in the settlement.

[0111] The 'ScriptPubKey' is essentially a cryptographic puzzle that requires a solution to allow the transaction to proceed. In the most common use case, this puzzle ensures that only the owner of the private key associated with (for example) the Bitcoin address can spend the UTXOs.

[0112] To apply this concept in a settlement / arbitration system, a multi-signature ('multisig') script can be used, which requires signatures from multiple Parties for the transaction to be valid.

[0113] For instance, consider a scenario including a buyer, a seller, and an arbitrator. A '2- of-3 multisig' address could be set up, which would require any two of the three Participants' signatures to spend the UTXOs. This could be the buyer and the seller in case of a smooth transaction, or, if a dispute arises, the arbitrator could provide the second required signature after deciding in favour of one Party.

[0114] So, in a dispute scenario, the arbitrator reviews the case details, makes a decision, and then signs a transaction sending the disputed amount to the winning Party. The 'ScriptPubKey' of this transaction could be set up to require signatures from the arbitrator and the winning Party, thereby enforcing the arbitrator's decision. This mechanism ensures a trustless and decentralized settlement / arbitration process. Every Participant has equal power, and the transparency of the blockchain ensures that the process is fair and can be audited.

[0115] This mechanism records all transactional activities, including initial agreement parameters, disagreements, resolutions, and arbitration outcomes, in an immutable and verifiable manner.

[0116] The system incorporates the Unspent Transaction Output (UTXO) model. In this model, each transaction is linked to a unique UTXO that distinctly signifies a specific amount of cryptocurrency. This serves as an ownership proof indicator and acts as a critical unit in the dispute resolution process.

[0117] The system ensures that the ScriptPubKey is configured to mandate a multisignature requirement. This provision ensures that a predetermined number of Parties must authorize any arbitration outcome, thereby enhancing the fairness and security of the dispute resolution process.

[0118] The multi-signature requirement within the ScriptPubKey can be designed to necessitate the inclusion of signatures from the arbitrator, buyer, and seller. This facilitates a trustless and decentralized arbitration process.

[0119] By combining the UTXO model and the multi-signature requirement, the system is able to handle multiple disputes simultaneously, resulting in improved scalability and efficiency.

[0120] The blockchain-based settlement / arbitration system incorporates a mechanism for time-bound responses, with automatic notifications dispatched to the Participating Parties. This improves the timeliness and effectiveness of the dispute resolution process.

[0121] In order to better explain the invention outlined above, reference is now made to figures 1a-1d.

[0122] Blocks 100-122 refer to an initial phase, to be carried out before purchase is authorized.

[0123] In step 100, the Buyer is interested in the good / service offered by the Seller. In step 110, the Buyer evaluates whether the standard offer for the good / service is acceptable.

[0124] In the negative, in step 112 the Parties communicate thorough the platform. The receiving party gets an email informing that he / she received a message in the platform inbox. Parties can negotiate a different / personalized offer. If Parties agree, the Seller is required to formalize this offer.

[0125] The Seller has now two options (step 113):

[0126] Option 1 : formalizing an offer inside the inbox chat, to be seen only by the Buyer. A “PURCHASE” button appears in the Buyer inbox. The flow then moves to step 120, disclosed in the following.

[0127] Option 2: formalizing a new offer in “my shop”, i.e. the new offer becomes standard and public. The flow then goes back to step 110, for acceptability evaluation by the Buyer.

[0128] If the offer (be it the original standard offer or the new offer) is accepted by the Buyer (step 110, YES branch), step 120 is performed, in which the Buyer’s wallet or account is checked to verify whether the amount contained therein is sufficient to cover the prize of the selected good / service.

[0129] In the affirmative, the flow proceeds to purchase operations, disclosed in the following.

[0130] In the negative, step 122 is performed, in which the platform warns the Buyer that the wallet / account has to be replenished, for example by acquiring further credits.

[0131] Blocks 130 to 155 refer to the purchase operations.

[0132] In step 130, Buyer can push the PURCHASE button. Seller is informed by both email and inbox. The transaction process between parts is started. At this point Buyer’s credits are frozen and no more available.

[0133] In step 140, the good / service is delivered.

[0134] In step 142, Seller can optionally inform the platform that service / good was delivered, adding a short “text”. Following step 142, in step 143 the platform automatically emails / inboxes the Buyer that he is required either to accept the service / good that was delivered, or to start the settlement process within an “x” time (parametric). See step 144.

[0135] Preferably, such “x” time can be equivalent to the time for withdrawal envisaged by the Law.

[0136] The “text” from Seller will be added. If Buyer does not answer within “z” days, he will receive a reminder he has still “x-z” days to answer.

[0137] In case the Buyer does not answer by the set deadline, the platform will consider that Buyer has received what was agreed (step 145).

[0138] In case the Buyer provides an answer, and the answer is a confirmation that the good / service has been delivered as agreed (step 150), flow moves to step 155.

[0139] In case steps 142-144 are not performed, the flow can move from step 140 to step 150 and, from step 150, to either step 155 or 160.

[0140] In step 155, credits are transferred from the Buyer’s wallet into Seller’s wallet. Buyer and Seller can rate each other, with possible comments via the platform.

[0141] Step 155 is also performed in case the Buyer does not react to the notification of step 143 (see step 145).

[0142] Blocks 160 to 212 refer to steps performed when something goes wrong with the transaction process.

[0143] Step 160 is performed by the Buyer, either on his own initiative or as a reaction to the notification of step 143 and, instead of confirming the proper delivery of the good / service, the Buyer notifies the platform that he / she has a problem.

[0144] Specifically, in step 160 Buyer pushes a “NO I HAVE A PROBLEM” button. Buyer is required to motivate his NO, texting a “complaint” with / without attachments. This starts the settlement process.

[0145] Flow moves on to step 170, wherein Seller is informed of the problem and receives from the platform the “complaint”. Both Parties receive a copy of what was agreed upon and the previous conversation occurred via the platform. In step 180, the platform automatically informs Seller that if he does not answer within a “y” time (parametric), it will be considered that he tacitly accepted Buyer’s claim. If Seller does not answer, after “z” time will receive a reminder that he has still “y-z” days to answer.

[0146] Step 190 provides two scenarios:

[0147] “NO”: the Seller does not reply within “y” days. Step 192 is performed, wherein credits are available in Buyer’s wallet / account. Seller and Buyer are be informed accordingly. Buyer can rate Seller with possible comments. Seller cannot rate Buyer.

[0148] “YES”: the Seller replies to the complaint within “y” days. Step 200 is performed, wherein Buyer is informed and is required to provide at least one response to Seller’s answer. Platform informs Buyer that, if he does not respond within a “y” time (parametric), it will be considered that he tacitly accepted Seller’s counterclaim. After “z” time, Buyer will receive a reminder he has still “y-z” days to answer.

[0149] Step 210 provides two scenarios:

[0150] “NO”: Buyer does not answer within “y” days. Step 212 is performed, wherein credits are transferred from Buyer’s wallet into Seller’s wallet. Seller and Buyer will be informed. Buyer and Seller can rate each other, with possible comments.

[0151] “YES”: Buyer answers within “y” days. Flow moves on to the subsequent steps, namely step 220.

[0152] Blocks 220-252 refers to a negotiation that can occur between Buyer and Seller.

[0153] In step 220, after Buyer’s response to Seller’s answer, for both Buyer and Seller the button “REQUEST ARBITRATION” becomes active. The button will remain active hereinafter.

[0154] In step 230, negotiations / discussions between the Parties can continue, and the Parties can agree about changes of the initial agreement (e.g. make a discount, send new product, etc).

[0155] In step 240, possibility of changes to the initial agreement is taken into account: “NO”: in step 250, Buyer can acknowledge he received what agreed pushing the YES button or require arbitration. If arbitration is required, arbitration process begins in step 260 (discussed in the following). If arbitration is not required and “YES” button is pushed, step 252 is performed, wherein credits are transferred from Buyer’s wallet into Seller’s wallet. Buyer and Seller rate each other with possible comments.

[0156] “YES”: flow moves to step 241 , wherein Buyer receives back in his wallet the credits, and the new amount of credits (i.e. the new amount agreed upon during negotiation) gets frozen. The new agreement is recorded. Then, in step 242, Seller informs the platform that the agreement has been reached and the transaction has been fulfilled. In step 243, Buyer is informed that he / she must either confirm the fulfilment or require arbitration, within a “x” time. If the fulfilment is confirmed (“yes”), step 252 is performed. If fulfilment is not confirmed, step 245 represents two possible scenarios:

[0157] “NO”: arbitration is not requested within “x” time. Then step 252 is performed.

[0158] “YES”: arbitration is requested in time. Flow moves to step 260.

[0159] The Applicant observes that blocks 160 to 252 represent the settlement algorithm.

[0160] Blocks 260 to 302 refer to the arbitration process and represent the arbitration algorithm.

[0161] As said, in step 260 the arbitration process begins.

[0162] In step 270, data acquisition and examination are carried out.

[0163] Specifically, the platform shows to Arbiter the following data for analyses:

[0164] 1 . Data of the offer or possible new agreement;

[0165] 2. Buyer’s complaint, Seller’s answer and Buyer’s response (compulsory passages for the Parties in order to trigger the arbitration process);

[0166] 3. Other communications available on the platform (any other communication outside the Platform will not be considered). Preferably, information indicated above at 1-3 is shown to the Arbiter via a suitable user interface, arranged on or via the platform.

[0167] In step 280, the Arbiter determines whether he / she has enough information to decide the case.

[0168] In the negative, step 282 is performed, wherein the Arbiter emails / inboxes one or both Parties asking for further information. Information must be provided within a fixed time (parametric set by back office). Preferably, no automatic penalties are provided for late or missing response. The flow then returns to step 280.

[0169] In the affirmative, in step 290 it is determined whether the good / service provided match the agreement or not. This is a human mediated passage.

[0170] In the affirmative, Parties are informed. Credits are transferred from Buyer’s wallet into Seller’s wallet. Buyer and Seller rate each other with possible comments.

[0171] In the negative, Parties are informed. Credits are transferred / maintained in Buyer’s wallet. Buyer and Seller rate each other with possible comments.

[0172] Step 302 represents a rare case, wherein the Arbiter is uncertain. In this situation, Parties are informed. Credits are frozen and dispute is settled extra marketplace platform. A back-office operator has the chance to manually move the disputed credits to one wallet or share them between Parties’ wallets.

[0173] The system / platform according to the invention can be realized as one or more processors, coupled with one or more memories. Such processor(s) is / are specifically configured in order to perform the operations herein described and claimed. In particular, a specific software program is stored in said memory(ies) and executed by said processor(s), so as to carry out the operations herein described and claimed. For example, such software program includes the settlement algorithm, and the arbitration algorithm, and possibly the preferred features associated therewith disclosed above and claimed hereinafter.

[0174] The processor(s) and memory(ies) can be installed at a same geographic location, or in different geographic location. Suitable connections therebetween is provided, so as to ensure proper functioning of the system. The algorithms generate suitable user interfaces, such as for example, graphic interface, so as to allow Buyer, Seller and possibly the human Arbiter to interact with the system. In particular the user interfaces make the information disclosed herein available to the relevant user(s), and prompt each user to undertake actions where necessary, according to the present disclosure and attached flowchart. Such user interfaces can be employed by Buyer, Seller and possibly the human Arbiter through electronic devices such as personal computers, laptops, smartphone, tablets, etc. suitably connected with the other parts of the system / platform.

Claims

CLAIMS1. A system for a web platform marketplace of goods and services that increases transactions’ fairness, wherein a transaction includes at least two Parties, wherein the Parties include a Buyer and a Seller, and wherein the system preserves both Buyer’s and Seller’s rights, wherein Buyer and Seller are associated with respective wallets or accounts, comprising: a) an automated intervention of the settlement / arbitration algorithm in case of disputes, where the algorithm ensures fairness by adhering to preset terms and conditions; b) a settlement algorithm in which, if Buyer considers that he / she has not received, from Seller or on behalf of Seller, the good / service according to the agreed terms, Buyer can initiate a complaint and start the negotiation via the platform, in which Parties explain their motivations and try to solve the dispute by reaching an agreement, wherein an amount corresponding to the good / service according to the agreed terms has not been transferred yet from the Buyer’s wallet or account when the negotiation is started; wherein, according to said settlement algorithm, after a complaint, a Party's failure to respond within the specified timeframe is interpreted by the platform as an implicit acceptance of the opposing Party's position, leading to a swift resolution of disputes; credits will be moved accordingly; c) an arbitration algorithm made accessible to each Party only after the steps of the settlement algorithm have been executed without leading to acceptance, and where human arbiter is guided by the system algorithm.

2. The system according to claim 1 , wherein said settlement algorithm empowers Parties with the ability to renegotiate and reach a settlement that deviates from the initial agreement, offering a flexible framework for dispute resolution,wherein the Buyer can accept or reject the Seller’s standard offer, and the standard offer can be renegotiated between the Parties and become a customized offer and / or a new standard public offer.

3. The system of claim 1 or 2, in which, in case of accepting the offer (standard or customized), the system will check the credit in Buyer’s wallet or account, and will warn the Buyer both via e-mail and platform inbox if the credit amount is lower than said amount, otherwise Parties are informed both via e-mail and platform inbox that the transaction process is started.

4. The system of anyone of the preceding claims, where the Seller informs the platform that service / good was delivered, and automatically the platform emails / inboxes the Buyer that he is required to either: recognize the transaction completion, or start settlement process within a fixed (parametric) time, wherein the platform sends the Buyer automatic scheduled reminders before a set deadline, wherein in case Buyer does not answer within the set deadline, the system considers that Buyer tacitly acknowledges Seller’s statement and will move credits accordingly.

5. The system of anyone of the preceding claims, in which some or all processes including Settlement / Arbitration algorithm can operate using either traditional digital technology or blockchain technology, based on the administrator's choice, the system further including a human arbitration component that becomes accessible in situations where the automated resolution does not achieve consensus, the human arbitration component operates within the boundaries of the initial agreement and takes into consideration communication and descriptions furnished on the platform by the involved Parties via the settlement algorithm.

6. The system according to any one of claims from 1 to 5, wherein server providing the contract management and settlement and arbitrage service can be connected to a blockchain network with a p2p (peer-to-peer) connection to include the data of the agreement obligation, including the virtual currency and its amount, becoming a method to provide a P2P contract management service using a blockchain-based or non-blockchain-based virtual currency that is stored to be distributed among at least two or more public nodes.

7. The system according to claim 6 that endows involved Parties with the capacity to renegotiate the terms of the transaction, allowing them to reach a settlement that deviates from the initially encoded smart contract agreement.

8. The system of any one of claims 1 to 6, wherein (in both cases of traditional or blockchain technology) the web platform provides intuitive user interface tools to facilitate the management and use of credits, their conversion into ERC20 tokens or similar tokens, this conversion increasing the versatility of the system, as these tokens can be traded on the open market, allowing users to take advantage of market fluctuations.

9. The system of any one of claims from 1 to 8, wherein the web platform includes a module for real-time tracking of the conversion rate between the credits and the ERC20 token or similar token.

10. The system of any one claims 1 to 9, wherein the web platform provides a secure digital wallet for each user, facilitating the safe storage, usage, and conversion of credits and ERC20 tokens or similar tokens.

11. The system of any one of claims from 1 to 10, wherein the cryptographic component of the blockchain is utilized to implement ScriptPubKey, a locking script that outlines the unique conditions that must be met for the IITXO to be expended or employed in the settlement / arbitration process.

12. The system of claim 6 that incorporates the Unspent Transaction Output (UTXO) model, which is a model in which each transaction is linked to a distinct UTXO that uniquely signifies a specific quantity of cryptocurrency.

13. The system of claim 6, wherein the ScriptPubKey is configured to mandate a multi-signature requirement, thereby ensuring that a predetermined number of Parties must grant authorization for any arbitration outcome.

14. The system according to anyone of the preceding claims, wherein: until a final decision is made by the settlement algorithm and possibly by the arbitration algorithm, the amount corresponding to the good / service according to the agreed terms is not transferred from the Buyer’s wallet or account; when a final decision made by the settlement algorithm and possibly by the arbitration algorithm implies that the Seller has to receive said amount, such amount is transferred from the Buyer’s wallet or account to the Seller’s wallet.

Images