WO2021072539A1

WO2021072539A1 - Method for operating a multi-account system and for tracking fund transfers therein

Info

Publication number: WO2021072539A1
Application number: PCT/CA2020/051381
Authority: WO
Inventors: Caroline DESROSIERS
Original assignee: Corporation Goodowl Inc.
Priority date: 2019-10-16
Filing date: 2020-10-15
Publication date: 2021-04-22

Abstract

A method for transferring funds between a client and a service provider in a marketplace. The method comprises providing a trust account and a distinct operation account. A mandate is selected and a corresponding payment is received from the client to the trust account, and an identifier is generated which comprises objective data queried by a server, data originating from the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify an amount in the trust account originating from the payment by tagging the amount with the identifier. The amount is held in the trust account for an indefinite period of time, which ends when receiving a confirmation that the mandate is completed. It is transferred to the operation account and held there for a regulatory period of time until paid-out to an external account.

Description

METHOD FOR OPERATING A MULTI-ACCOUNT SYSTEM AND FOR TRACKING FUND

TRANSFERS THEREIN

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the priority or benefit of U.S. provisional patent application 62/915,718, filed October 16, 2019, the specification of which is hereby incorporated herein by reference in its entirety.

BACKGROUND

(a) Fiejd

[0002] The subject matter disclosed generally relates to systems for fund transfers. More specifically, it relates to a system for transferring funds in a multi-account arrangement, including a method for tracking the funds.

(b) Related Prior Art

[0003] There are various marketplaces which aim at pairing potential customers with potential sellers. Typically, a marketplace is a web platform in which sellers sell their products or services, and customers can buy these products or services, or request for particular products or personalized services, to which a plurality of service providers are free to respond. The service provider therefore has access to a large pool of potential customers and the customers can choose from a variety of service providers.

[0004] Some marketplaces have been found very successful, such as marketplaces for selling goods (e.g., eBay®), or marketplaces for freelance jobs.

[0005] However, professional service providers are underrepresented in marketplaces. This can be explained at least in part by the fact that the infrastructure that underlies marketplaces (especially payment gateways) is often not adapted to some constraints inherent to the professional activity, in particular the requirements for managing funds for lawyers, for example. Practitioners of the legal profession often need to respect very stringent rules with respect to fund management of their clients. Payment infrastructures used on the internet are not at all adapted for appropriate fund management in these particular circumstances. Payment infrastructures are complex systems which cannot be adapted easily to fit the needs of these professionals, making these systems unsuitable in particular circumstances.

SUMMARY

[0006] According to an aspect of the invention, there is provided a method for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, the method comprising:

- providing a trust account and an operation account distinct from the trust account;

- selecting a mandate or a portion thereof by one of the client and the service provider on a user interface; - upon selection of the mandate or the portion thereof, querying payment information to the client on the user interface that corresponds to the client;

- receiving the payment from the client to the trust account, comprising generating an identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify an amount in the trust account originating from the payment by tagging the amount with the identifier;

- holding the amount in the trust account for an indefinite period of time;

- receiving, at the server, a confirmation from the user interface that corresponds to the service provider, that the mandate or the portion thereof is completed, with a corresponding amount;

- transferring the corresponding amount from the trust account to the operation account;

- holding the corresponding amount in the operation account for a regulatory period of time; and

- paying-out the corresponding amount or a representative portion thereof.

[0007] According to an embodiment, the method further comprises the step of providing an application server which generates a website for selecting the mandate or the portion thereof by one of the client and the service provider on the user interface, wherein the user interface corresponds to the client or to the service provider, respectively.

[0008] According to an embodiment, transferring the corresponding amount from the trust account to the operation account comprises generating another identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify the corresponding amount in the operation account by tagging the corresponding amount with the other identifier.

[0009] According to an embodiment, the indefinite period of time is greater than zero and has no predetermined limit, the indefinite period of time ending upon a trigger, the trigger comprising the confirmation that the mandate or the portion thereof is completed.

[0010] According to an embodiment, the regulatory period of time is between 30 days and 60 days.

[0011] According to an embodiment, paying-out the representative portion of the corresponding amount comprises paying-out the corresponding amount minus a fee which is deducted from the corresponding amount. [0012] According to an embodiment, selecting the mandate or the portion thereof by one of the client and the service provider on the user interface comprises classifying a jurisdiction or set of rules to which the mandate or the portion thereof is subject to determine the regulatory period of time applicable to the mandate or the portion thereof for holding the corresponding amount in the operation account.

[0013] According to another aspect of the invention, there is provided a method for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, the method comprising:

- defining a mandate or a portion thereof by the service provider on a user interface;

- proposing a confirmation to a user interface that corresponds to the client, and upon receiving a confirmation for the mandate or the portion thereof, querying payment information to the client on the user interface that corresponds to the client;

- holding the amount in the trust account for an indefinite period of time;

- holding the corresponding amount in the operation account for a regulatory period of time; an

- paying-out the corresponding amount or a representative portion thereof.

[0014] According to an embodiment, the method further comprises the step of providing an application server which generates for defining the mandate or the portion thereof by the service provider on the user interface, wherein the user interface corresponds to the service provider.

[0015] According to an embodiment, transferring the corresponding amount from the trust account to the operation account comprises generating another identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify the corresponding amount in the operation account by tagging the corresponding amount with the other identifier.

[0016] According to an embodiment, the indefinite period of time is greater than zero and has no predetermined limit, the indefinite period of time ending upon a trigger, the trigger comprising the confirmation that the mandate or the portion thereof is completed.

[0017] According to an embodiment, the regulatory period of time is between 30 days and 60 days.

[0018] According to an embodiment, paying-out the representative portion of the corresponding amount comprises paying-out the corresponding amount minus a fee which is deducted from the corresponding amount.

[0019] According to an embodiment, defining the mandate or the portion thereof by the service provider on the user interface comprises classifying a jurisdiction or set of rules to which the mandate or the portion thereof is subject to determine the regulatory period of time applicable to the mandate or the portion thereof for holding the corresponding amount in the operation account.

[0020] According to another aspect of the invention, there is provided a system for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, the system comprising:

- computing systems implementing a trust account and an operation account distinct from the trust account;

- an application server and a client device corresponding to each one of the parties, wherein the application server and the client device corresponding to each one of the parties are in communication over the internet to perform the steps of:

- selecting a mandate or a portion thereof by one of the client and the service provider on a user interface;

- upon selection of the mandate or the portion thereof, querying payment information to the client on the user interface that corresponds to the client;

- holding the amount in the trust account for an indefinite period of time; - receiving, at the server, a confirmation from the user interface that corresponds to the service provider, that the mandate or the portion thereof is completed, with a corresponding amount;

- paying-out the corresponding amount or a representative portion thereof.

[0021] According to an embodiment, the application server generates a website for selecting the mandate or the portion thereof by one of the client and the service provider on the user interface, wherein the user interface is on the client device corresponding to the client or to the service provider, respectively.

[0022] According to an embodiment, transferring the corresponding amount from the trust account to the operation account comprises generating another identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify the corresponding amount in the operation account by tagging the corresponding amount with the other identifier.

[0023] According to an embodiment, the indefinite period of time is greater than zero and has no predetermined limit, the indefinite period of time ending upon a trigger, the trigger comprising the confirmation that the mandate or the portion thereof is completed.

[0024] According to an embodiment, the regulatory period of time is between 30 days and 60 days.

[0025] According to an embodiment, paying-out the representative portion of the corresponding amount comprises paying-out the corresponding amount minus a fee which is deducted from the corresponding amount.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Further features and advantages of the present disclosure will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0027] Fig. 1 is a screenshot illustrating an interface for generating a personalized mandate, according to an embodiment of the invention;

[0028] Fig. 2 is a screenshot illustrating an interface for presenting invoices of a personalized mandate, according to an embodiment of the invention;

[0029] Fig. 3 is a screenshot illustrating an interface for presenting a purchase order for a regular mandate, according to an embodiment of the invention; [0030] Fig. 4 is a screenshot illustrating an interface for presenting a state of advancement of a regular mandate, according to an embodiment of the invention;

[0031] Fig. 5 is a screenshot illustrating an interface for presenting invoices of a regular mandate, according to an embodiment of the invention;

[0032] Fig. 6 is a flowchart illustrating a method for transferring funds between parties in a marketplace, according to an embodiment of the invention; and

[0033] Fig. 7 is a schematic diagram illustrating a method for transferring funds between parties in a marketplace, according to an embodiment of the invention.

[0034] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

DETAILED DESCRIPTION

[0035] There is described herein a network-enabled computer system for transferring funds between multiple external parties in which a trust account is necessarily involved in the transfer. If the trust account needs to be involved in the transfer, then funds can be mismanaged easily due to the confusion that would arise from having a great number of concurrent transactions between multiple parties all involving the trust account. Therefore, a method for unambiguous identification (i.e., tagging) of the individual amounts being transferred, and unambiguous traceability of the individual amounts (which would otherwise be indiscernible in the total amount held in the account) is described herein. This method can be applied in an architecture for payment described herein, provided that a set of rules are implemented, to arrive at a payment infrastructure which can be used advantageously in marketplaces for services providers who have restrictions with respect to fund management, such as practitioners of the legal profession or other professions having similar rules.

[0036] Various difficulties arise from trying to apply the infrastructure of a marketplace for serving a pool of service providers having to respect such stringent rules on fund managements. To put it shortly, the marketplace is typically a website manager which also implements a payment platform such that the marketplace is the fund-managing party; but the marketplace is not a practitioner of the legal profession and does not implement the stringent rules on fund managements with which legal practitioners or other professionals need to comply. Moreover, the purpose of the marketplace is to serve a plurality of service providers and a plurality of customers, but it is very likely that the rules to which the plurality of service providers have to comply will be different. It is therefore very likely too that the payment infrastructure used by the marketplace, typically a single, one-size-fits-all payment solution, will not be appropriate to fit the needs of all service providers who are members of the marketplace. [0037] For example, the marketplace may implement an independent third-party payment solution such as PayPal® or Stripe®, which both have their limitations. These payment solutions are not adapted for trust accounts used to hold amounts for an indefinite period of time (a discussion of the “indefinite” period of time is provided further below and currently available infrastructures are not adapted to this feature). They are also not adaptable to the context of each service provider such that the transfer includes a time buffer before the execution of the pay-out transfer for legal reasons. For example, these solutions can have a time buffer of maximum 30 days, and not beyond, for various technical and legal reasons. This time buffer can be chosen, but is not adaptable to each of the service providers of the marketplace, and therefore cannot be chosen according to a given set of rules (or a jurisdiction) to which an amount is categorized to belong.

[0038] Moreover, marketplaces act as a third-party between the customer and the service provider. A marketplace may put in place their own trust account (as will be detailed below in relation with an embodiment of the invention). However, according to the current practices, it would be very hard to implement, because the marketplace is not the service provider; they rather hold money for a plurality of distinct service providers, and the funds are received from a plurality of customers. The amounts in relation to these many and distinct service providers and customers can easily be scrambled in the trust account given the variety of origins and destinations for these amounts. Only a total amount exists in an account, and the individual nature of each of the individual amounts (i.e., origin, destination, mandate to which it corresponds) that together make up the total is indiscernible in the total. This gets even more complicated taking into account that the service providers may be accountable to different professional rules depending on the professional order or bar association to which they belong (i.e., can differ depending on the state or province or depending on the profession, each with its set of rules applicable to a mandate and the corresponding financial transactions, where each mandate is to be categorized as belonging to a particular set of rules or jurisdiction). The nature of a marketplace, i.e., a platform using computer systems to perform transactions between third-parties, implies that the number of transactions can be very high.

[0039] There is therefore proposed herein a system in which the marketplace, now referred to as the fund-managing party, acts as the marketplace and also as an intermediate between the originating party (customer or client from which originates the original fund transfer) and the receiving party (service provider receiving the funds).

[0040] The fund-managing party, distinct from the client(s) and from the service provider(s), should have control over accounts which are distinct and which are of different types. The first account is a trust account. The trust account is an account which is used to receive funds for services which have not yet been executed, i.e., funds received in advance on behalf of the client. When the service is executed, the company having performed the service is now entitled to transfer the funds from the trust account to an operational account.

[0041] The fund-managing party has control over the trust account, preferably a single trust account for each currency. The trust account is used as would a trust account in a law firm, i.e., it is used to receive the funds from the clients, typically as an advance amount for a mandate (which can be a predetermined mandate or a personalized mandate, as discussed further below).

[0042] The fund-managing party further has control over the operation account, distinct from the trust account. Once the mandate is performed, or once a portion of the mandate is performed, the original funds or the appropriate portion thereof are “consumed”, i.e., the service for which the amount was in the trust account is now performed, such that the original funds or the appropriate portion thereof can be transferred to the operation account. This transfer will indeed take place immediately after the system is notified of the completion of the mandate or the portion of the mandate (this notification of the completion acting as a trigger for the transfer and ends the indefinite period of time in which an individual amount corresponding to the completed mandate of the notification was held). This transfer will take place based on an identification or tagging of the original funds, and subsequent transfers will also undergo a similar step of identification or tagging of the transferred funds as explained further below.

[0043] It should be appreciated that the method described above ensures that the fund-managing party can hold funds in a trust account for advance payments in a manner which should satisfy requirements for most service providers, since there are many service providers which are bound to have advance amounts kept in a trust amount until the service has been actually rendered. The transfer of the original funds or the appropriate portion thereof from the trust account to the operation account of the fund managing party is automated and performed only after the service is completed, as instructed from the user interface of one of the users, typically the service providers.

[0044] It should be noted that the funds are not, at this stage, transferred to the service provider. This is because practitioners of the legal profession or other professionals may have to offer a chance to their clients to contest the invoice. This is a frequent legal requirement that dictates the relationship between a client and the professional they hire, and state-of-the-art marketplaces and their payment infrastructure fail to address this aspect as they typically transfer funds automatically over a predetermined period of time which is too short to satisfy that requirement and cannot be lengthened for various reasons, preventing compliance of those systems with the legal framework for practicing these professions.

[0045] Meanwhile, according to the embodiment of the invention herein described, the appropriate funds are transferred from the trust account to the operation account upon completion of the corresponding mandate or portion thereof, and both these accounts are controlled by the fund-managing party. The subsequent transfer is a transfer of the same traceable amount (identified and tracked according to the method described herein) from the operation account of the fund-managing party to the service provider account (not under the control of the fund-managing party), assuming that no contestation was made.

[0046] If a contestation is made, the amount is frozen until the issue is resolved, such that the transfer can take place, either wholly or just in part, and including any refund back to the trust account or to the client if this is an appropriate action.

[0047] In most cases, there will not be any contestation. However, the regulatory time buffer for contestation must be observed, typically it can be in the order of 45 days, although this may depend on the rules that are applicable to a professional practice (depending on the nature of the profession and the jurisdiction). Each mandate (and the corresponding amounts to be transferred, identified as corresponding to the mandate) is categorized as belonging to a jurisdiction or set of rules which dictate the regulatory period of time (buffer for contestation or similar). Due to the remote nature of the services rendered using the marketplace, and/or due to the third-party nature of the marketplace, other periods may need to be observed, more or less than 45 days (15, 30, 45, 60 or 90 days for example, or anything between 15 days and 90 days which is appropriate). On a side note, typical payment solutions such as PayPal® or Stripe® are, currently, technically unable to observe such a long period of time that would be dictated by a professional order or bar association.

[0048] Therefore, the system in place needs to have rules which implement the following: 1) hold the received funds in a trust account for an indefinite period of time which ends when the mandate associated to the amount is marked as completed in the system; and when the period ends, i.e., when the task is completed, either transfer the whole amount to the operation account, or fragment (or split) the amount to transfer only a predetermined portion thereof that corresponds to the value of the task (portion of the mandate) that was performed; and 2) hold the transferred amount in the operation account for a regulatory period of time; the regulatory period of time being a buffer period of delay for contestation in which the funds are held (i.e., unmoved).

[0049] The indefinite period of time for holding the funds in trust and the regulatory period of time for holding the funds in the operation account are two different types of waiting periods, and one should not be confused one for the other.

[0050] On one, hand, the indefinite period of time is necessarily greater than zero (not a null period of time). It does not have a maximum boundary, i.e., it is indefinite. However, “indefinite” does not mean “infinite”, as despite the absence of a time limit to the indefinite period of time, the indefinite period of time is ended by a trigger which eventually happens and which cause transfer to the operation account or reimbursement. (The probability of such a trigger never happening is significantly low so it can be considered 0). The indefinite period of time is therefore not constrained between boundaries (other than being a non-zero positive number), and it is not dictated by any other parameter than the trigger. Generally speaking, the indefinite period of time is different for each amount, as the duration in the trust account depends on external factors which dictate the trigger for a transfer and end of the indefinite period of time.

[0051] On the other hand, the regulatory period of time is a predefined period of time which is set by rules in the computerized environment. It is a non-zero positive number which is the same for all amounts governed by the same rules. A plurality of the traceable amounts in the operation account are therefore held there during the same duration.

[0052] It will be appreciated that the originating accounts for the funds, from which the funds are received in the first place, are numerous. Moreover, the destination that receive the funds, in the end, are also numerous. There is however a single trust account and a single operation account (which are distinct one from another), so the traceability of amounts becomes an issue because of the multi-party aspect of the system.

[0053] From all amounts transferred into the single trust account, each one has its origin from one external account among a diverse plurality of external origin accounts. All amounts held in the single trust account are held for an indefinite period of time which is independent (i.e., generally different) for each of the traceable amounts in the total amount held there.

[0054] Upon triggering the transfer of an individual amount in the single trust account, the destination of the transferred amount is the same for all transferred amounts, i.e., it is the operation account (unless the amount is being reimbursed, in which case it is returned to the origin account).

[0055] All amounts held in the operation account are held there for the regulatory period of time, which is the same for all amounts that are categorized as being subject to a given jurisdiction and respective set of rules dictating the regulatory period of time (typically same for all, unless the amounts are subject to different jurisdictions where the rules are different). When the amounts are dispatched from the operation account at the end of the regulatory period of time, they are each transferred to one external account among another diverse plurality of external destination accounts.

[0056] A fee (such as a commission) may be deducted from the transferred amounts upon a transfer thereof, during one or more of the transfers being performed. Therefore, the transfer may involve the totality of an individual amount (corresponding to a mandate or portion of a mandate), or it may involve a representative portion of the individual amount (e.g., the individual amount, minus the commission fee, with the fee remaining in the account where the amount was previously located and where the fee may be eventually removed from the account upon a trigger to be transferred elsewhere as per busines rules).

[0057] According to an embodiment of the invention, there should be provided a method to track the individual amounts that are subject to a transfer. The method comprises the generation of a unique tag which is generated in order to unambiguously identify a specific amount in relation with the parties involved (where both the originating party and the receiving party are third parties with respect to the fund managing party) and in relation with the mandate to which the amount relates, considering that the tag’s unambiguous value contains information which is both objective (i.e., fact-based), and subjective, i.e., taken from the originating party and the receiving party through a respective user interface from these different and distinct third parties.

[0058] Table 1 : Sub-parts for generating a complete, unambiguous tag

[0059] Therefore, a purchase order and an invoice can be identified using a tag as shown as an example in Table 1. For example, the type of transaction (incoming mandated purchase order to the trust account; executed portion of mandated invoice and transfer to the operation account, or even payout after the regulatory period of time). Time data can be agglomerated into the identifier, such as the year, and optionally the exact date or time. The type of mandate (personalized, regular) can be used in the identifier, using an alphanumeric symbol that corresponds thereto. While an advanced amount in relation with a purchase order is always “complete” by default, the invoiced and subsequently transferred amounts may be partial as the mandate can be executed in individual portions. For example, if there are 5 tasks or portions of the personalized mandate, the corresponding transferred amounts have an identifier for the invoice bearing a corresponding number: .1 , .2, .3, .4, .5. These identifier portions identify portions of a mandate and originate from the service provider’s user interface through which the service provider divided the mandate in portions.

[0060] For example, the advance to start a new mandate starts with the following tag generated and associated to an amount entering the multi-account system following a payment through the user interface of a customer:

• PO2019-1 .12-P123456-U 123456-1-2

• IN2019-1.12-P123456-U123456-1-2.1 - issued when the service provider finished task 1 of the personalized mandate and clicked on the first task;

• IN2019-1.12-P123456-U 123456-1 -2.2 - issued when the service provider finished task 2 of the personalized mandate and clicked on the second task;

• IN2019-1.12-P123456-U123456-1-2.3 - issued when the service provider finished task 3 of the personalized mandate and clicked on the third task;

• IN2019-1.12-P123456-U123456-1-2.4 - issued when the service provider finished task 4 of the personalized mandate and clicked on the fourth task;

• IN2019-1.12-P123456-U123456-1-2.5- issued when the service provider finished task 5 of the personalized mandate and clicked on the fifth task.

[0061] Then:

• IN-P-2019-1 .12- P123456-U123456-1-2.1 - issued after the 45 days delay (or any other regulatory period of time for conciliation, e.g., between 15 days and 180 days, or between 18 days and 90 days, or between 30 days and 60 days, such as 45 days) following the completion of Task 1 of the special mandate (it’s the auto-invoice issued in order to pay the professional)

• IN-P-2019-1 .12- P123456-U123456-1-2.2 - issued after the 45 days delay (or any other regulatory period of time for conciliation) following the completion of Task 2 of the special mandate (it’s the auto-invoice issued in order to pay the professional)

[0062] If it is a regular mandate instead of a personalized mandate, then the identifier will look like

• PO2019-1 .12-P123456-U123456-1-1.0

• I N-C-2019-1 .12-P123456-U 123456-1 -1.0 I N-P-2019-1.12-P123456-U 123456-1-1.0

[0063] The identifier is generated by the server of the marketplace (i.e., the fund-managing party) for each transaction. The identifier is unambiguous because it is formed by data which uniquely refer to an amount for a mandate or portion thereof (originating from the user interface of the service provider), and uniquely identify the step in the streamlined process in which the amount is at. The data used to form the identifier is formed by the agglutination of objective data on the mandate (such as time and jurisdictional information), on data provided by the user (such as user instructions to pay or client identifier originating from their inscription), and on data provided by the service provider, such as the completion state of a task, identifier of a portion of a mandate, or service provider’s identifying information originating from their inscription. The data that is objective may be taken by the server either using APIs (e.g., querying the time on the operating system) or by querying the database, while the data from the user originates from the corresponding client side, where the client uses their own user interface or where the service provider uses their own, distinct, user interface. According to an embodiment, the identifier is formed by agglomeration or concatenation of the such data into an alphanumeric identifier.

[0064] To summarize, referring to the embodiment of the invention of Fig. 6, the method for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, comprises:

[0065] Step 610: providing a trust account and an operation account;

[0066] Step 620: providing a website platform for selecting a mandate or a portion thereof by one of the client and the service provider on a user interface that corresponds to the client or to service provider, respectively;

[0067] Step 630: upon selection of the mandate or the portion thereof, querying payment information to the client on the user interface that corresponds to the client;

[0068] Step 640: generating an identifier comprising objective data queried by a server, data from the client’s GUI, and data from the provider’s GUI;

[0069] Step 645: tagging the transaction and resulting amount;

[0070] Step 650 receiving the payment from the client to the trust account, and holding the amount in the trust account for an indefinite period of time;

[0071] Step 660: receiving, at the server, a confirmation from the user interface that corresponds to the service provider, that the mandate or a portion thereof is completed, with a corresponding amount; [0072] Step 670: transferring the corresponding amount from the trust account to the operation account, comprising the steps 640 and 645;

[0073] Step 680: holding the corresponding amount in the operation account for a regulatory period of time; an

[0074] Step 690: paying-out the corresponding amount or a representative portion thereof.

[0075] Fig. 7 illustrates that the management of the graphical user interface, notifications to parties and recordation of instructions, and all other practicalities involved by the marketplace platform, are performed by the application server 700. The application server 700 therefore serves the client computers of a plurality of clients and a plurality of service providers, notably the client computer 751 of the client and the client computer 752 of the service provider which are entering in a business relationship. The application server 700 also instructs the financial transfers, which take place with financial transaction servers, to the trust account 701 and operation account 702 as already described above, which have their own, respective and distinct waiting time for holding amounts. The application server 700 also tags the transactions such that all amounts under the control of the application server 700 remain identifiable over the course of the waiting time. It will be appreciated that the financial servers of the different parties have been omitted from the figure for greater clarity, but typically, payments are made from and to financial servers associated to financial institutions.

[0076] Even though Fig. 7 shows that the trust account 701 comprises the amounts being identified and therefore individually retraceable, the trust account 701 only knows the total amount stored therein. The tracking by the identifiers of individual amounts is done by the application server 700 which can retrospectively retrace the individual amounts and their corresponding identifier from the total amount held by the trust account 701.

[0077] There is now described a system which is used to act as a graphical user interface for the clients and service providers to enter necessary information for mandate creation and advancement, client’s instructions and payments, and service provider confirmation that a task was completed that will instruct the underlying fund transfers.

[0078] A person skilled in the art will understand that the marketplace would require parties to create a profile and enter their personal or professional information along with financial information to enable eventual payments and fund transfers.

[0079] Professional service providers can then display their professional expertise on the marketplace, with some visibility to the potential clients. Potential clients can then enter in contact with the service provider of their choice, either directly or after having posted an offer for a mandate for example. The contact and pairing between a client and a service provider can be made according to any of the usual practices in marketplaces.

[0080] According to an embodiment of the invention, once a contact has been made and a mandate is being discussed, there may be two different ways to generate a mandate. First, there may be a regular mandate, e.g., the service provider has, on their profile, a list of standard services that they offer. For example, a lawyer may offer the service of “Incorporation” or a “Thirty-minute telephone call” for a fixed price. The client therefore needs to select the regular mandate on their user interface. This selection should have the server implementing the marketplace send an invitation to the service provider to accept the client, e.g., to check for conflicts. Once the service provider has accepted the new client/mandate, a notification is sent to the client. Preferably, the client will already have provided payment information (if not, they can do that at that time). Upon acceptance of the client by the service provider, the payment from the client is made, for the fixed, predetermined price of the service that they selected through the user interface or though the personalized mandate process, in relation to a purchase order (PO). These steps are performed over a client-side web page (or web application, installed application, and the like), on a client device, with data transferred over the internet on a network.

[0081] The payment implies a fund transfer which is tagged according to the identification method described above, such that the funds are held in the trust account with proper identification for subsequent transfers.

[0082] Second, the mandate may be a personalized mandate. In this case, a short chat, email thread or phone discussion should be held between the potential client and the service provider (either using built-in communication tools within the marketplace platform, or using outside tools such as the phone) to establish a potential mandate which is not predetermined. The personalized mandate can be created, for example, as a second mandate following a first regular mandate when the regular mandate is not adapted anymore to the reality of services to be rendered. The personalized mandate also offers the flexibility for a service provider and client to enter the marketplace for a mandate which was already defined prior to their subscription on the platform, thereby defining the personalizing mandate through the interface and starting the workflow. As shown in Fig. 1 , the service provider may then create a mandate using their user interface, the mandate comprising one task or a plurality of tasks, each having, for example, a description, a timeline and a price, or hourly rate, or price range. The mandate can be a single-task mandate, or a multi-task mandate that can be divided in at least two portions of the mandate, each portion being executable individually and being charged accordingly (“charged” implying the transfer from the trust account to the operation account), upon completion of that portion only. [0083] If the client was not a member of the marketplace platform, the client will be invited to create a profile, with all necessary information and then have access to the personalized mandate for acceptance. If the client was already a member with a profile, the client will then be notified through the user interface that they may accept a personalized mandate, and accept all the mandate or portions of it. The acceptance of the service provider is not needed in this case since the proposition originates from the service provider. The acceptance of the mandate by the client will trigger the request for payment information and the payment will take place, in relation to a purchase order (PO).

[0084] Once the payment is made, using for example a payment gateway such as PayPal® or Stripe®, or using bank wire transfer, debit transfer or cheque, the service provider will be notified that the amount in advance for the mandate or the portion thereof has been transferred in trust and the service may be executed.

[0085] Once the mandate or the portion thereof is completed, the service provider will indicate through the user interface that it has been completed, using the user interface such as in Fig. 1 . This will have the server notify the client through the user interface, and it will trigger the transfer from the trust account to the operation account, as described above. Even though the funds were previously tagged according to the initial transaction (payment by the client), the new transfer is a new transaction that will have its own identifier. The funds transferred to the operation account will bear the new identifier generated during that specific transfer, as generated by the application server which tracks the amounts. It should be noted that while the whole amount may be transferred, the mandate or portion of mandate that was completed may have a price which is less than the complete amount that was advanced/paid by the client. This amount therefore needs to be fragmented/split to ensure that only the portion of the amount that relates to the performed task(s) is being transferred, and the remainder remains in the trust account for later. Only the newly transferred portion is re-identified with a new tag for identification.

[0086] As shown in Fig. 2, the user interface can show an invoice (typically generated on the server side) of all portions of the mandate completed, with the related amounts being formally invoiced (i.e., reflecting that they are not in the trust account anymore).

[0087] Similarly, Fig. 3 shows a purchase order from a client for predetermined, regular services, all being prepaid. Once each of these tasks or portions of mandate are performed, they are invoiced and the characteristics of that task are saved, along with the individual invoice or transfer identifier that corresponds to an invoiced amount for a task, as shown in Fig. 4. A user-friendly invoice can be generated as shown in Fig. 5. [0088] While the invoice is generated, the corresponding amount is effectively deducted from the appropriate amount in the trust account, as identified using the tag and recorded in the database as being associated to the client-provider pair and also associated to the mandate being executed. This amount is transferred to the operation account and re-identified. It means that that amount was held for indefinite period of time in the trust account which now ends as the server is notified of the completion of the portion of the mandate (the action acting as a trigger which ends the indefinite period of time). The transfer to the operation account triggers, for that specific amount, its own regulatory time period (i.e., a timer of a specific number of days). If contestation occurs, the amount can be frozen until the issue is resolved. Otherwise, at the end of the regulatory time period (timer for that specific amount), the amount is paid to the service provider (pay-out). While the amount actually leaves the hands of the fund-managing party, the transaction can, again, be tagged according to the method above to ensure traceability and proper recordation in the system. This pay-out is preferably an automated transaction, such as a bank wire transfer or any other suitable method for payment.

[0089] According to an embodiment, and as briefly mentioned above, a commission may be deducted from the pay-out amount, which implies that the remaining amount in the account will be tagged accordingly as the commission, i.e., revenue for the marketplace operator, and therefore be left in the account or be paid-out to another account. Another invoice may be generated for the commission, addressed to the service provider from the marketplace operator.

[0090] It should be understood that the system and method described above are particularly useful in the context of marketplaces. Indeed, marketplaces are a specific type of platform for managing relationships between parties over the web, and the current state-of-the-art is not adapted to the use thereof for particular services such as those offered by lawyers, as described above. The payment gateways that are used in marketplaces, which are complex computer systems, are not suitable for various technical reasons detailed above, notably in that the infrastructure of the payment gateways are not suited for trust accounts which are highly regulated and need to hold amounts for an indefinite period of time, and the infrastructure of the payment gateways implement various technical features which make them very hard to adapt for regulatory waiting periods of time. The proposed system and method can solve the issue of the holding for an indefinite period of time and also for the regulatory waiting period of time, thus enabling the use of a marketplace for a greater variety of service providers who have restrictions on the way payments can be made and for whom typical payment gateways in marketplaces are not suitable.

[0091] It will be understood as the problem relates to the user of computer servers and client computers used in conducting business activities over the internet. They relate to a problem arising in computer technologies, where current method of operating the computer systems under these computer technologies are unsuitable. By reorganizing payments between parties, the parties may use computer technologies over the internet in a more suitable manner. As the problem arises in the realm of computer technologies, computer systems are of course essential to the invention.

[0092] A computer system acting as a server is essential to form the application server which generates a website by hosting it, by receiving requests/queries and sending responses to make the web application work, including the reception and recording of financial information and identification information, the initiation of transaction and the tracking of all amounts.

[0093] Since the method described above is applicable for remote transactions over the web, the financial transactions are performed over the web, and a network infrastructure and other layers of telecommunications are essential for carrying out the method. Moreover, the financial transactions are also performed over the web and computer systems which implement high cybersecurity standards are essentially required to perform the financial transactions and for holding the accounts, in particular the trust account and the distinct and different operation account, and receive and send amounts from and to external destination and origin accounts which are held by computer systems of a similar nature.

[0094] Finally, a client device which is in remote communication with the application server using the essential network, is also essential to provide the data required to carry out the method and to remotely initiate mandates and have transfers triggered by the application server using the information entered through the appropriate client device of a client or of a service provider.

[0095] Computer systems can comprise a computer acting as a server, or a plurality of computers arranged in a network, such as forming a cloud computing network if they are arranged to work together. A computer system or a server, even when using a singular form, should be viewed as including suitable forms according to which a plurality of computers are arranged in such a network or cloud system to perform similar functions more efficiently than a single computer, even though there are more than one computer actually performing the task.

[0096] While preferred embodiments have been described above and illustrated in the accompanying drawings, it will be evident to those skilled in the art that modifications may be made without departing from this disclosure. Such modifications are considered as possible variants comprised in the scope of the disclosure.

Claims

CLAIMS:

1. A method for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, the method comprising:

- holding the amount in the trust account for an indefinite period of time;

- paying-out the corresponding amount or a representative portion thereof.

2. The method of claim 1 , further comprising providing an application server which generates a website for selecting the mandate or the portion thereof by one of the client and the service provider on the user interface, wherein the user interface corresponds to the client or to the service provider, respectively.

3. The method of claim 1 or 2, wherein transferring the corresponding amount from the trust account to the operation account comprises generating another identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify the corresponding amount in the operation account by tagging the corresponding amount with the other identifier.

4. The method of any one of claims 1 to 3, wherein the indefinite period of time is greater than zero and has no predetermined limit, the indefinite period of time ending upon a trigger, the trigger comprising the confirmation that the mandate or the portion thereof is completed.

5. The method of any one of claims 1 to 4, wherein the regulatory period of time is between 30 days and 60 days.

6. The method of any one of claims 1 to 5, wherein paying-out the representative portion of the corresponding amount comprises paying-out the corresponding amount minus a fee which is deducted from the corresponding amount.

7. The method of any one of claims 1 to 6, wherein selecting the mandate or the portion thereof by one of the client and the service provider on the user interface comprises classifying a jurisdiction or set of rules to which the mandate or the portion thereof is subject to determine the regulatory period of time applicable to the mandate or the portion thereof for holding the corresponding amount in the operation account.

8. A method for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, the method comprising:

- proposing a confirmation to a user interface that corresponds to the client, and upon receiving a confirmation for the mandate or the portion thereof, querying payment information to the client on the user interface that corresponds to the client; - receiving the payment from the client to the trust account, comprising generating an identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify an amount in the trust account originating from the payment by tagging the amount with the identifier;

- holding the amount in the trust account for an indefinite period of time;

- paying-out the corresponding amount or a representative portion thereof.

9. The method of claim 8, further comprising providing an application server which generates for defining the mandate or the portion thereof by the service provider on the user interface, wherein the user interface corresponds to the service provider.

10. The method of claim 8 or 9, wherein transferring the corresponding amount from the trust account to the operation account comprises generating another identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify the corresponding amount in the operation account by tagging the corresponding amount with the other identifier.

11 . The method of any one of claims 8 to 10, wherein the indefinite period of time is greater than zero and has no predetermined limit, the indefinite period of time ending upon a trigger, the trigger comprising the confirmation that the mandate or the portion thereof is completed.

12. The method of any one of claims 8 to 11 , wherein the regulatory period of time is between 30 days and 60 days.

13. The method of any one of claims 8 to 12, wherein paying-out the representative portion of the corresponding amount comprises paying-out the corresponding amount minus a fee which is deducted from the corresponding amount.

14. The method of any one of claims 8 to 13, wherein defining the mandate or the portion thereof by the service provider on the user interface comprises classifying a jurisdiction or set of rules to which the mandate or the portion thereof is subject to determine the regulatory period of time applicable to the mandate or the portion thereof for holding the corresponding amount in the operation account.

15. A system for transferring funds between parties in a marketplace, wherein the parties comprise a client among a plurality of clients and a service provider among a plurality of services providers, the system comprising:

- holding the amount in the trust account for an indefinite period of time;

- receiving, at the server, a confirmation from the user interface that corresponds to the service provider, that the mandate or the portion thereof is completed, with a corresponding amount; - transferring the corresponding amount from the trust account to the operation account;

- paying-out the corresponding amount or a representative portion thereof.

16. The system of claim 15, wherein the application server generates a website for selecting the mandate or the portion thereof by one of the client and the service provider on the user interface, wherein the user interface is on the client device corresponding to the client or to the service provider, respectively.

17. The system of claim 15 or 16, wherein transferring the corresponding amount from the trust account to the operation account comprises generating another identifier which comprises objective data queried by a server, data originating from the client on the user interface that corresponds to the client, and data originating from the service provider on the user interface that corresponds to the service provider, to unambiguously identify the corresponding amount in the operation account by tagging the corresponding amount with the other identifier.

18. The system of any one of claims 15 to 17, wherein the indefinite period of time is greater than zero and has no predetermined limit, the indefinite period of time ending upon a trigger, the trigger comprising the confirmation that the mandate or the portion thereof is completed.

19. The system of any one of claims 15 to 18, wherein the regulatory period of time is between 30 days and 60 days.

20. The system of any one of claims 15 to 19, wherein paying-out the representative portion of the corresponding amount comprises paying-out the corresponding amount minus a fee which is deducted from the corresponding amount.