JP2002540487A - E-commerce system for non-standard services - Google Patents

Abstract

(57) [Summary] Disclose an e-commerce system for non-standard services. The user (4001) registers with the service dispatch system and creates one or more profiles (4005). The service requester (4007) sends the task to the service dispatch system for presentation. At (4011), the service dispatch system creates a potential service provider (“ Select 4013) and select one or more service providers that are eligible to perform this task. The dispatch system then pays a service provider (4013) that provides the particular service or task to the requestor (4007).

Description

DETAILED DESCRIPTION OF THE INVENTION

CROSS REFERENCE TO RELATED APPLICATIONS This patent application is filed under H. Sayed et al., US Provisional Application No. 60 / 108,834, filed November 18, 1998, entitled “ Market system (Mark
et system for Web-deliverable services).

BACKGROUND OF THE INVENTION FIELD OF THE INVENTION The present invention relates generally to electronic commerce systems, and more particularly to electronic commerce systems in services.

[0003] 2. 2. Description of the Related Art The development of the Internet, and in particular the World Wide Web (WWW), has led to the explosive growth of e-commerce, or e-commerce. The WWW has made it possible to access websites directly from anywhere on the planet, and in the process has greatly expanded the prospective market and greatly reduced transaction costs,
All kinds of new possibilities are open to both super- and micro-enterprises. Take the book seller as an example: on the one hand, amazon.com (R) has become one of the leading book sellers in a few years, and on the other hand, small businesses dealing with specialized or used books, Currently it can be easily accessed from anywhere in the world.

[0004] Currently, the benefits of e-commerce from vendor-to-customer access and increased customer-to-vendor access and transaction costs are being enjoyed only with respect to merchandise and standardized services. As expected, e-commerce is most convenient for consumers without having to see or try the product before buying it, as in the case of personal computers, new books, or share shares, for example. Is the case. E-commerce in the service is standardized tickets,
Limited to services that can be represented by contract or reservation. As an example,
There are e-commerce in theater and concert tickets, information provision, hotel reservations, or aircraft tickets.

[0005] The increased access to customers and vendors and the reduction in transaction costs caused by e-commerce have potentially greater value for non-standardized services than for goods and standardized services. Examples of non-standardized services include translating documents, rewriting medical reports, solving mathematical equations, writing computer programs, creating reports, or conducting legal or business research. As can be seen from these examples, non-standardized services have the following characteristics: they are not standardized and therefore cannot be embodied, ie cannot be represented by tickets, reservations, contracts, etc .; and Since the buyer is typically an individual or small business, there is no effective market mechanism to organize or price buyers and providers. In many cases, providers work part-time. For example, foreign engineering graduate students in the United States make significant contributions by providing technical translations in their spare time. Similarly, lawyers at home with children and friends often conduct legal investigations for other lawyers.

[0006] In many cases, non-standardized services also have the following characteristics: • Special training or experience is required to perform the work; and • The cost of the work is the length of the work, the difficulty of the work And the time given to the service provider to do the job. For example, translation of a French newspaper article is generally less costly than translating a French technical article of the same length, and prices rise steeply as the time to complete a task is reduced.

[0007] From the perspective of a customer of such a non-standardized service, the first problem is to find a person who really provides the service. The more professional a service is, the less likely it is that the customer will know who will provide the service or will be able to determine if the person the customer finds can actually provide the service. Once the person is found, the next issue is setting the price. Since there is virtually no market, the price will ultimately be unjust for one or the other party. In addition, you face all the problems that arise when dealing with small businesses or individuals. Typically, small businesses or individuals do not use credit cards and are difficult to contact, or at best only occasionally. Finally, customers often do not have realistic reimbursement rights if work is not completed, delayed, or otherwise improperly performed.

[0008] Providers of non-standardized services have the opposite problem: the smaller the provider, the more difficult the problem. The first problem is, of course, finding customers. Advertising is expensive and, when the potential customers are widely dispersed, there is often no economical means of advertising. Once a customer is found, setting prices in isolation is as difficult for the provider as it is for the customer. The provider has little or no information about the customer's ability to pay, and once the customer receives a delivery, such as a legal opinion or translation, the customer has little or no incentive to pay. When the customer does not pay, the provider also has no realistic reimbursement rights, as the amount of translation often cannot justify the legal means to force payment Often.

Some things cannot be done at all because of the high transaction costs of finding a qualified, non-standardized service provider. For example, a manufacturer of a particular product may seek some input from potential users of the product. Manufacturers often decide to simply rely on the merchant's idea because of the cost of finding potential users, contacting them, and finding out what their needs are. On the other hand, if any way of contacting is found, many potential users will be willing to provide an opinion, especially if there is some reward for the time spent on the opinion. The high transaction costs of finding customers also make it difficult for married people, students, consultants, and others at home to provide nonstandard services.

If the e-commerce benefits have to be extended to commerce in non-standardized services, the following problems need to be solved: the customers of the services and the providers of the services have more access to each other Ease of service; • guarantee the quality of the service provider and the quality and reliability of the service provided by the service provider; • determine what the price of the service should be; And providing the means of communication between the customer and the service provider; the customer having sufficient access to what is available to determine if the work has been done properly. Be able to do so, but allow full access only after the customer has made the payment; Performing the audit trail when a conflict between the bis provider;
And providing a low cost dispute resolution mechanism to resolve such conflicts.

It is an object of the present invention to address these and other problems when extending e-commerce to include non-standardized services.

SUMMARY OF THE INVENTION The present invention achieves the objective by providing a service dispatch system that mediates between a service requester and a set of service providers. This service
The dispatch system identifies the requester and the provider, assigns the task requested by the service requester to the service provider, negotiates the price of the task, approves the solution to the task by the service requester, and pays the price. And to settle disputes between the parties. Other embodiments may not mediate in all of these areas. Service requesters and service providers can access the service dispatch system through an interactive interface. In a preferred embodiment, service requesters and service providers interact with the service dispatch system via the Internet.

The service dispatch system receives task and price specifications from the service requester. The service dispatch system responds to the task presentation by assigning one or more service providers to the task. When a service provider has a solution to this task, the service provider presents this solution to the service dispatch system, so that the service requester is able to use this solution. Is shown in If the service requester indicates to the service dispatch system that they accept this solution, the service dispatch system pays the service provider a price and provides the solution to the service requester. Therefore, the service dispatch system allows the service requester and the service provider to easily find each other, and that the service requester receives the solution and that the service provider receives the price To guarantee.

The service dispatch system of the present invention further allows a user to define one or more of his or her own profiles. Each of the user's profiles presents the user's various ideas to other users of the system. For example, a user's profile indicates the expertise and educational background that the user has to perform a particular class of task. The profile also allows the service requester to present the task anonymously and the service provider to disclose as much personal information as necessary to demonstrate the ability to perform a particular class of task. When the service dispatch system assigns a task, the task is assigned to one or more profiles. When a service requester pays for a solution,
The service dispatch system obtains evaluation information from both the service requester and the service provider. The cumulative rating for the profile is part of the profile and may be made available to the service requester or service provider. Thus, the service dispatch system provides a marketplace for providing service requesters and service providers with quality of service information, but otherwise provides as much anonymity as is desirable between the parties, thus reducing the traditional It is less susceptible to service requester bias or service provider bias than the market.

When setting a profile, a service provider indicates his / her special technical field, and when a service requester presents a task, the task is classified. The service dispatch system uses information that the system has on the classification of tasks and the evaluation of profiles to select several service providers to which tasks can be assigned. In some cases, the service dispatch system automatically assigns the task to the selected service provider; in other cases, it provides the list of selected profiles to the service requester, The service requester can make a proper selection. This selection can be made based on price, as described below.

A service dispatch system allows a service requester to establish a way to price a service. In a preferred embodiment, establishing a price may include a transaction or bidding system between the service requester and the service provider. In either case, the service dispatch system mediates transactions and bids.

When a service provider presents a solution, the service requestor may request to accept the solution, reject the solution altogether, or modify it. Where possible, the service dispatch system will provide the requester with sufficient information about the solution so that the information can be informed and the quality of the solution can be determined. Unless you give a complete solution.

The service dispatch system also mediates between the service requester and the service provider for payment. Each profile can include details on how to make payments when the profile acts as a service requester and how to get paid when acting as a service provider. When the solution is accepted by the requester, the service dispatch system transfers the payment from the requester to the provider.

The service dispatch system interacts between the service requester and the service provider, as well as rejects, so that a complete audit trail can be performed on the transaction between the service requester and the service provider. Maintain sufficient information on solutions that have been and are accepted. Also, one of the services provided by the service dispatch system is arbitration based on an audit trail of the transactions discussed.

[0020] Other objects and advantages will be apparent to those of skill in the art to which the present invention pertains upon a review of the following detailed description and drawings.

DETAILED DESCRIPTION The following detailed description describes the effects of a system for e-commerce on non-standardized services, referred to herein as a service dispatch system, and provides an overview that provides an operational overview. Beginning and then a summary of the preferred embodiment, and finally details of the preferred embodiment, including the structure of the database used and the user interface for the system.

Overview of the Service Dispatch System The service dispatch system of the present invention is the first mechanism of its kind to process "web-distributable" services over the Internet. The service dispatch system provides a complete environment that maps a given service task to a qualified service provider and tracks the tasks from the time they are presented until payment for the services provided is paid. Designed for During this time, the service dispatch system manages all necessary interactions between the parties. A task is understood herein to be anything from answering a question to a large software engineering or research project. In a preferred embodiment, two subtypes of the task (su
btype), i.e. all that is required is for the service provider to know the answer to give the answer to the service requester, the "question" and for the service provider to provide the requested service. There are "projects" that require considerable independent effort.

The service dispatch system provides a mechanism for outsourcing tasks via the Internet. Regardless of whether the task is to translate a document, rewrite a medical report, solve a mathematical equation, or get legal or consumer opinion, service dispatch The system finds one or more people with expertise and engages in tasks or sends back accepted solutions. The service dispatch system provides a vehicle for both parties to match issues and talent and process transactions.

The e-commerce solutions and services to date have been directed primarily to the sale of tangible goods (books, computers, cars, etc.) and, secondarily, usually to physical realizations. (Flights, Hotels, etc.) were directed to brand-name services (Airline tickets, hotel reservations, news offerings, etc.). The mechanism usually focuses on negotiation of price agreements, the services provided are generally fixed, and buyers find services by external means. Examples include a fixed price for a company stall (eg dell.com), an ebay.com auction model, pr
iceline.com's reverse auction model is included. 1 including non-standardized services
One paradigm was old, with categorized pages being introduced as they were in the digital age.

[0025] The service dispatch system can be any service that can be delivered via the web.
Specifically, it differs in nature in that it is intended to form the basis for a free market for services (which can be converted to text, image, audio, video, or other computer formats). Obvious possibilities include photographs, records, graphic design projects, banner ad design, translating documents, reviewing books, solving math problems, programming tasks, rewriting medical reports, etc. , But not limited to). However, the service
Note that the task management functions of the dispatch system can be used for services that are not delivered over the web.

A service dispatch system is not just a new categorized service. Unlike categorized pages, service dispatch systems provide a specific mechanism for linking service providers and service buyers and managing all transactions in a stable manner. A service dispatch system provides a complete market in which both parties can have the security provided by a well-defined process to exchange services.

The service dispatch system provides a thorough audit, usually via a zero-knowledge dialog or “obscured” solution dialog (eg, a company can purchase photos based on a low-resolution preview) Provide trail and payment security. In addition, full mediation is available in all cases (and all information needed for mediation is automatically logged, making complaint resolution easy and fair).

Further, the service dispatch system allows both parties to be partially or completely anonymous. Thus, service dispatch systems are best suited to facilitate service exchange based solely on skills, independent of other prejudices. Companies that buy banner ad graphics do not need to know race, gender, age, or any other information about the person who created the ad, as long as it looks good. Service dispatch systems make this concept a reality.

The service dispatch system is designed to reduce the level of granularity of service exchanges, and uses current means in a faster and more reliable way than presenting classified advertisements. It is intended to facilitate the transfer of services that cannot be addressed (ie, hiring a new employee).

For small and irregular tasks, service dispatch systems are designed to provide a cheaper and easier solution than traditional contract work. The service dispatch system has the specific goal of helping small, funded companies to address their specific service needs in a timely and efficient manner.

In addition, service dispatch systems are designed to take advantage of the skills of a large number of workers that are underutilized in the current economy. Workers unable to take a full-time job for various reasons can use the service dispatch system to
You can sell your special expertise at a convenient time. For example, a service dispatch system is ideally targeted at students, ie, highly skilled populations that are not accessible due to time constraints. The service dispatch system is also ideal for parents at home and those working part-time. In each case, the structure and format of the exchange allows for the sale of technology in a fluid and flexible manner, consistent with external constraints.

Finally, the service dispatch system creates a truly global 7 × 24 hour service market for services, thus allowing service buyers to utilize talent outside their area, Human resources can find markets outside the local economy.

Examples of services that can be provided via a service dispatch system Translation task Suppose you have a document that you want to translate from English to French. This document can be sent to the service dispatch system in several ways. If this document is a text or .pdf file, simply upload the document over the web. If it is a handwritten document, the user can mail the document and the service dispatch system will scan and upload it.

[0034] 2. Rewriting Task Assume that there is an audio tape or handwritten note of the doctor's note that needs to be rewritten. The user sends the tape or manuscript and the service dispatch system converts it to digital form and uploads it. The service will show the task only to qualified service providers (medical transcribers) and show a list of people / interests who are interested in this task who can assign the task. It can be requested from the dispatch system. After a task is assigned, the service provider performs the task and uploads the results.

[0035] 3. Legal Opinion Task Suppose you need to know about your rights as a resident of a given town. The user submits a legal opinion task describing his situation. Service dispatch
The system presents the task to a lawyer with expertise and assigns the task to one of them. The response will include a reference to such a lawyer's qualifications.

[0036] 4. Problem Task You are studying a dissertation and need to solve a complex mathematical formula. The user submits a math task and requests that the task be presented as broadly as possible and that the user indicates that he will pay for the results. Mathematicians and students who are users of the service dispatch system see this and the first solver gets this task.

[0037] 5. Opinion task Suppose you need to investigate how people think about a political issue. The user submits the opinion task with the question (using the service dispatch system's survey tool) and specifies the number of people who need to get an opinion and how much to pay for each opinion. The service dispatch system displays the user's tasks, provides the respondent with an interface to answer the user's questions, and sends the answer to the user in both full and summary form.

[0038] Suppose that it is necessary to know in which hairstyle a user in a particular country thinks the user is nice. The user presents this question with various pictures on the service dispatch system and specifies the number of respondents and the country required. The service dispatch system provides an answer to the user.

[0039] 6. Photography Task Suppose you need a picture of the sunset in Serengeti. The user opens this and presents it to the public task.

[0040] 7. Audio Task Assume that the voice of the koala needs to be recorded. The user opens it and presents it to the public task.

[0041] 8. Graphic Tasks Banner Ad Design Drafting Service: The service buyer submits the scanned sketch and the service provider replies the drafting.

9. Programming Tasks Assume that you need a company banner ad. ...

10 Reward task Have you ever seen this guy? Wanted by the FBI. ... Have you ever seen this child? I'm missing. ...

11. Competitive Tasks Call for applications for a new park design on the corner of Prospect and Mass Ave. Applications are accepted until 12:00 on December 31.
Selected works will be announced on March 1. The first prize is ...

12. Investigation Tasks Legal Investigation: The service purchaser is a lawyer, and the service purchaser is a lawyer assistant. Source library service, trademark search, etc.

13 Market Research Task Pay each opinion x ＄ on this product.

14. Time-sharing task You pay $ 1 per hour for the calculation time to run this applet.

15. Programming Tasks-You need JavaScript code to pop up a window when you do it.

16. Book Criticism Tasks We are looking for someone to write a 1000 word critique of the new book "Internet for Dummies".

17. Movie Criticism Task We have opened a new cinema. We are looking for someone to write a 100-word review of a movie that is currently open.

18. Tax preparation tasks

19. Advertising Task via Surveys Assume that there is a single question survey that asks for comments on the attached banner ad. The service provider (survey co-worker) is paid for seeing the advertisement and clicking the "like" button or the "dislike" button. Service buyers (advertisers) are assured of their message ratings and feedback about their reputation. You will be paid for seeing the ad.

20. Mediation Tasks Mediation services for small disputes.

Description of the functions of the service dispatch system The functions performed by the service dispatch system are as follows: 1. Create and log in a user account; 2. Task presentation; 3. Task assignment and negotiation; 4. Submit a task solution; 5. Evaluation and acceptance of task solutions; Payment; 7. supply of task solutions; 8. mediation of disputes; Management of contacts; Privacy and security.

1. Creating and logging in a user account a. User Account Management User login is mandatory for service requesters and optional for service providers (however, denying login limits access). The system allows for the creation of a user account for authentication purposes, which can include one or more service requester profiles and / or service provider profiles. A profile is a mechanism that allows a user of the system to show his various aspects to the system. When a user account is created,
The system is stored in a permanent database and subsequently used for login authentication,
Prompt the user for a username and password. For a particular session, the system allows a user (who has created an account in the past) to log in as a service requester or service provider. Before entering the system,
The user must enter a username and password for a valid account in the permanent database.

B. Creating a Service Provider Profile A user can create one or more service provider profiles via a web form. Each profile collects information including at least a handle, an email address used for communication, payment information, and information about the type of service desired. The profile may also optionally collect information such as name, address, description, and the like. To qualify for certain tasks, proof of license may be collected as well (see "Certificate Management" below). Profile information is stored in a permanent database and can be edited at any time by an authorized user.

C. Creating a Service Requester Profile A user may create one or more service requester profiles via a web form. Each profile collects at least information including a work name, work address and phone number, an email address for communication, and payment / billing information. The profile may optionally include other information such as a description. To qualify to perform certain tasks, proof of license may be collected as well (see "Certificate Management" below). Profile information is stored in a permanent database and can be edited at any time by an authorized user.

D. Managing Certificates To qualify for certain tasks (related to purchasing or providing services), external certificates (eg, a lawyer's license) can be collected. Such certificates may be collected in the form of textual information (ie, diploma numbers) and / or uploaded files. Before the certificate is issued, various off-line processes can be performed (i.e., calling the relevant registry). All information is stored in a permanent database and can be edited at any time by an authorized user.

[0059] 2. Task submission Any registered user with a service requester profile can submit a task. Task presentation will collect at least the following pieces of information (if these are not explicitly provided, default values will be used):
a. The type of task (translation, rewriting, photo, etc.); b. Task name; c. A brief description; d. The content of the task; e. Display options (public, open to qualified providers, designated, etc.); f. Solution options; 1. Number of solutions to seek; 2. The number of solutions to actually buy; How to select a solution to buy (ie, auction, competition, first-come, first-served); g. Pricing information (maximum price, whether the transaction is acceptable, etc.); h. Assignment information (whether a task can be assigned automatically, how to confirm the assignment, etc. [see "Task Assignment"below)]; i. Time constraints (for various stages of task resolution). All task information is stored in a permanent database. However, tasks can be edited by an authorized user only before assignment (see below).

[0060] 3. Task Assignment The system authorizes three possible task assignment methods: automatic assignment, manual assignment, and recruitment submission. The task can always be switched to each method (although the resulting action depends on previous assignments).

In the automatic assignment, based on criteria including experience time in the system, performance history, and specified areas of expertise, several service providers (the number may differ from the number and Depends on other information). These service providers are informed of the purchaser's intent when assigning tasks.

[0062] Manual assignment provides the buyer with an opportunity to browse the service provider's space to select the number of people to be notified that the task may be assigned. The browsing process includes some view of the service provider's entire space, which is constrained by factors such as interest, experience in the system, performance history, and possibly others.

In the recruitment presentation, the task description is accessed by an associated group of service providers and an assignment request is made.

All assignment decisions are logged in a permanent database and cannot be edited by an authorized user (these decisions are stored for reconciliation).

In some cases, allocation decisions are made based on price negotiations. Preferred aspects of the system support direct negotiations between service requesters and interested service providers, and also support bidding systems including reverse auctions, sealed bids, and auctions.

Service requester notifications include messages (sent via the internal message system and / or email) that indicate the service provider's interest and provide a certain amount of information about the task. . Various degrees of information about the service requester are provided depending on the privacy settings. The information about the task includes at least a brief description, information about the price, information about the acceptance criteria, and information about the allocation process (such as how many others have been notified).

The notified service requester can respond to such a message in one of four possible ways: 1. The service provider accepts the assignment request. 2. The service provider conditionally accepts the request and submits a countermeasure on the allocation conditions. 3. The service provider rejects the assignment request. 4. The service provider requests a description regarding the assignment request.

The service requester is notified of all such response decisions.

In response to the information from the service provider, the service requester can respond as follows: • If the service provider accepts the assignment request, the service requester can add According to the specified protocol, this assignment can be confirmed or this service provider can be rejected. -If the service provider rejects the assignment request, no response is given. • If the service provider accepts the request conditionally and submits a countermeasure, the service requester accepts the countermeasure (except that the service provider has It has the same effect as accepting the assignment request), or responds with a counter submission (allowing a response from the service provider as described above), or the service provider can be rejected. This counter submission cycle continues until a rejection is made or an agreement is reached. This cycle can be automated and coordinated between each allocation request (ie, in an auction model).

The notification and negotiation of assignment requests continues until the total number of assignments specified in the task description (as a solicited solution) is confirmed. After the task is assigned to the service provider, the service provider can access the complete task content in the event where the task content could not be known before. By accessing the complete task content, the service provider can obtain the information needed to perform the task.

[0071] 4. Submit a task solution : A task solution can be submitted in one of three ways : 1. A registered user who processes the service provider profile to which the task is assigned submits a solution. 2. A registered user who processes the service provider profile submits a solution for the viewable task. 3. You can submit a solution for tasks that can be viewed by registered or unregistered users without a service provider profile (for unregistered users,
This is a public task only).

The solution submission in the latter two cases is only possible if no task has been assigned to any service provider.

Once the service provider has completed the solution, the system allows the service provider to upload the solution and at least the “obscuring method” or related information including the uploaded ambiguous version of the task. To

An ambiguity is a method that “ideally” allows a buyer to verify the required features of a solution, but “shadow” the solution in some way so that it cannot actually have a solution. It is a process of "blurred". Examples include (but are not limited to) actually blurring the photo (or providing a thumbnail), displaying a portion of a text document or audio file, and the like. The system attempts to configure the service requester so that it cannot assemble a complete solution by examining several different submission solutions. If the service provider is not satisfied with the default method for a given task category, it can submit its own "obscured" version.

Initially, all submitted information is stored in a temporary holding area (
(Either logical or physical) and stay there until confirmed. At that point, the obfuscated version of the solution (if any) and possibly other information is transmitted to an area accessible to the service requester.

The submission of a solution is only possible as long as the task is “open”, ie if the provider has not yet accepted the number of solutions specified in the task description.

[0077] 5. Consideration and Acceptance of Task Solutions When the service requester is notified that the service requester is ready to consider a solution, the system requests that the service requester submit a solution (ie, an obfuscation). Inform the service requester of the time constraints specified in the task presentation process regarding the completion or method of the acceptance process, by examining the various aspects of the accepted version You can also).

A service requester can respond to a request in one of three ways: 1. The service requester can accept the solution. 2. The service requester can completely reject the solution. 3. The service requester can reject the solution and request a change. The differences between Case 2 and Case 3 are as follows. A complete rejection means that the service provider's assignment has been revoked and the service provider can no longer submit a solution for this task. Also, other assignment requests can be made (to generate sufficient potential solution) depending on the settings made during the task submission process.

On the other hand, in Case 3, the solution is rejected but the quota remains, and the service provider can upload other submissions for future consideration (during which time the task is not closed) Assume that).

Any of these actions may be performed with the service requester's justification information collected by the system (which may include free text or selection of a checkbox in the list of reasons for refusal) of the service in question. The provider is notified by the system.

As part of the acceptance process, the service requester evaluates the service provider's expertise and conduct in performing the task, and the service provider evaluates the service requester. This rating is kept in a record associated with the task, and the system also aggregates the ratings of tasks presented or performed by a profile and creates a cumulative average rating for this profile. The system can display this assessment to the service requester as part of the task assignment process.

[0082] 6. The payment processing service requester can pay for the task solution through various methods, including but not limited to a credit card or a prepaid escrow account. Accounts are usually charged at the time the solution is accepted (this fee covers both the price of the solution offered to the service provider and any additional fees for using the service dispatch system). Including).

The service provider may be paid via various methods including, but not limited to, credit card refunds, checks, transfers, or additions to the escrow account maintained by the service provider in the system. . The latter method can be performed automatically for amounts smaller than a certain threshold. If the solution is provided by more than one service provider, the system provides a mechanism that allows the service requester to allocate payments among the service providers. the system,
A mechanism for adding tips to payments is also provided.

[0084] 7. The task service delivery service requester, upon accepting the solution, can access the complete and clear solution and download it or view it online.

[0085] 8. If the dispute mediation service requestor rejects the submitted solution, the system may give the service provider an opportunity to refute the buyer's rejection. Every individual
When participating in the system, you must agree to binding mediation in the event of a dispute. When a dispute is recorded, a task is presented to the system that only the mediator can access. The above-described arbitration is performed using each mechanism of the service dispatch system. In this case, the content of the task is a complete audit trail of all relevant information in the permanent database, as well as opposition and response texts collected by the system from service providers and service requesters involved in the dispute.

The arbitrator may make an award based on the information provided or may request any of the involved parties for further testimony (subject to time limitations for resolution). The mediator then makes an award and the system then takes action based on the decision. The ruling issued includes the following comments: Ruling in favor of the service provider. In this case, the buyer is obliged to purchase a solution. 2. Ruling in favor of the service requester. In this case, the provider must accept the rejection. The mediator is the service requester or service provider (depending on the nature of the opposition)
Alternatively, arbitration may be made to process the payment of arbitration costs by a combination thereof. In addition, the service dispatch system can pay for elements of arbitration under certain circumstances.

9. Managing communications All notifications and communications between the parties mentioned above are made by an internal messaging system and / or via email. An internal message system is generally a message-driven system, meaning that a response is generated only if it follows a particular situation (described above) or responds to a previous message. This allows for any degree of privacy protection.

The message system also allows messages to be presented in public forums and semi-public forums (where the system can restrict access to such messages based on various users and profile criteria and information). I do.

Standard email is used as a functional clone of the internal messaging system (
That is, all internal messages are copied to the e-mail, the response is via an internal mail router, and / or (eg, a new internal message has arrived and should be read Can be used simply as a notification device.

10. Privacy and Security All financial transactions made via the World Wide Web are secure. In addition, any other information distribution tasks can be encrypted. The use of profiles within the system allows both service requesters and service providers to control the degree to which they maintain anonymity with respect to tasks (although the system maintains a certain amount of information to guarantee payment). Must).

Overview of Operation of Service Dispatch System: FIG. 40 FIG. 40 is a flowchart 4001 of the operation of the service dispatch system. Dotted arrows indicate communication between the system and a user, service requester, or service provider. In operation 4003, user 4001 receives service dispatch
Register with the system. At 4005, the user creates his or more profiles. 4009, user 4001 acting as service requester 4007 in this regard
Sends a task to the service dispatch system for presentation. 4011,
The service dispatch system is a potential service provider for this task 4013
Select The service dispatch system may present the task for a solution by all users of the system, or, in some cases, the task to the general public, or select the service requester, depending on the situation. A group of one or more service providers that can do so can be presented. Presentation of a group of service providers is based on input from service requesters. This input may be the service provider's profile name or a description of the task. In the latter case, the service dispatch system uses the classification of the discipline indicated by the user when the user submitted the profile and the reputation of the user to use one or more of them to perform the task. Service providers can be selected. The system then notifies the provider of the selected task.

At 4015, a task is assigned to one or more selected service providers. Depending on the input from the requester, the assignment may be made automatically by the service dispatch system, or simply by accepting the task by the service provider, or by the requester and one or more providers. May be the result of negotiations arbitrated by the system between The negotiations can be done simply by signing up and submitting a proposal, or in the form of a bid by some service provider.

Once the task is assigned to one or more service providers, the assigned service provider can access the material provided by the requester to perform the task, as shown at 4017. . In some cases, the task is completely included in the presentation, making this step unnecessary.

At 4019, one or more providers present a solution for the task and the requestor is notified that a solution has been presented. The requestor has access to the solution (if possible, the system obfuscates the solution) and then decides in act 421 whether to accept or reject the solution. In each case, the service provider is notified. If the requester wants a different service provider to try the task, the system returns to task assignment operation 4015 to assign the task to a different service provider (arrow 4022). If the requester simply wants the service provider to correct or improve the solution, the provider will be notified and the provider will later provide the improved solution, as indicated by arrow 4020. Present.

At 4023, the system performs an operation of paying the provider. Generally, what is paid is the price agreed upon during the task assignment operation 4015, but the requester specifies how to allocate this price among several service providers, and one or more Input to specify the tip to the service provider of the service. Once the provider has been paid, the requester has access to a clear solution, as shown at 4025.

Overview of a Preferred Embodiment of the Service Dispatch System: FIG. 1 FIG. 1 is an overview of a preferred embodiment of the service dispatch system 101. The service dispatch system 101 is implemented by a dispatch system server 109 having an Internet protocol address and including an Internet interface 110. The Internet interface 110 follows a HTTP protocol and thus enables web page display and file transfer; an email client 122 for sending and receiving email;
And a server cache client 121 for performing financial transactions securely. Dispatch system server 109 is accessible from its user 104 via the user's web browser and the Internet 103.
Users 104 include two groups: service requesters 105 (a..n) and service providers 107 (a..n). Of course, a given user 104 of the dispatch server 109 is a service requester 105 (i) for one task and a service provider 105 (i) for another task.
107 (j).

The dispatch system server 109 includes an application server 112 and a dispatch system database 125 as well as the web server 111. Application server 112 includes dispatcher 114 and some application server routines. These routines are dispatched
It reads tables in system database 125 and writes to such tables. The information in dispatch system database 125 is organized according to the functions performed by dispatch server 109. Therefore, the user information 127 is information on the service requester 105 and the service provider 107 using the system 109. The task management information 129 indicates that a task is a service requester.
Used to manage this task from the time presented by 105 (i) until the time when all service providers 107 (j..o) who have successfully provided a solution for that task get paid Information. The solution information 133 is a solution. The message information 135 includes messages flowing between the users of the system 101 during the operation of the system 101 and between the system 101 and each user. Finally, archive information 1
37 contains information about the task, permanently stored in the system DB 125,
Therefore, it provides the information necessary to perform an audit trail. The number in parentheses is the reference number of the database table that implements such a class of information in the preferred embodiment. Such tables are discussed in more detail below.

[0098] Each of the database processing routines 115 can be similarly grouped according to the database tables that they process. User routine 11
6 processes the user information 127. The task routine 117 processes task information 129 and task management information 131. Solution routine 118 processes solution information 133. Message routine 119 processes message information 135. Finally, the archive
The routine 120 processes the archive information 138.

A user interacts with the service dispatch system 101 as follows.
Users use their web browser to dispatch system server 10
Specify 9 web addresses. The web server 111 allows the user to
Respond with an initial web page that contains a menu that allows you to select an interaction with. In response to this selection, web server 111 displays an initial web page for the desired interaction. For example, if the user is a service requester 105 (i) and wants to see the task currently being performed for that user, the initial web page displaying the task will identify the user to himself. Request that Upon receiving the user's ID, the web server 111 forwards the ID to the dispatcher 114 along with an indication of what to do with it, and the dispatcher 114 uses this user ID to display a task in a task routine 117. Responds to this indication by calling a routine. The task display routine includes task management information 131 and task information 1
Using the table in 29, a list of tasks currently being performed for this user and their status is returned to dispatcher 114, which passes this list to web server 111. The web server 111 embeds this list in a web page and returns the web page to the service requester 105 (i). The user can view other web pages from the web page containing the list, and web server 111 and dispatcher 114 operate as described above. For example, if a user wants to see detailed information about a particular task on a list, he can select a detailed representation of a task. At the detail level, the user can, for example, review the bid of the task and send a message to the service provider 107 (j) if the task has already been given to the service provider 107 (j) can do.

[0100] For any interaction between the user and the dispatch system server 109, the user can take an initiative or the dispatch system server 109
109 can send an email notifying the user of an important event. For example, if service provider 107 (j) is selected for a task,
The routines in routine 117 allow e-mail server 122 to provide service provider 10
7 (j) can be sent to the service provider 107 (j), indicating that it has been selected and including the URL of the web page containing the relevant information.

Structure of Dispatch System Database 125: FIGS. 2-4 The system database 125 is a relational database, ie, the information in this database is a stored table. Each table is composed of records. All records in a given table contain the same fields, and the fields of each record in one table relate these records to records in other tables. 2 to 4 show the tables of the dispatch system database 125 and the relationships between the records in the tables. Although a single record is shown in each table, the same relationship holds for other records. In general, one-to-many relationships where one record in one table can be related to many records in another table, and one record in one table only relates to one record in another table There are two types of relationships, one-to-one relationships that can be performed. 2 to 4, these relationships are indicated by arrows, and the direction of the arrow indicates the direction of the relationship (if the arrow points from record 205 to record 217, the arrow Indicate how this is related to record 217), the annotation on the arrow indicates whether this relationship is one-to-one ("1" on the arrow) or one-to-many ("m" on the arrow) )). Thus, each account record 205 may have a one-to-one relationship with the buyer payment method record 209 and a one-to-many relationship with the profile record 225.

First, the structure of FIG. 2 will be discussed. The table shown in FIG. 2 contains information about the users of the system 101. Each user has an account
It has a record 205. The user is the service requester 105 or the service provider 10
The information in or accessible from a given account record 205 may be seven or both, depending on which role the user has. Accordingly, account record 205 has a one-to-one relationship with buyer payment record 209 and / or provider payment method record 213. Such a record indicates how payment should be made if the user is a service requester and how payment should be made if the user is a service provider. Account records are educational records
217 and the technical record 221 also have a one-to-one relationship. The educational record shows the user's educational background, and the technical record shows the user's technical skill.

To allow the user 104 to adjust the degree of anonymity he or she has for various types of tasks, and to allow the system 101 to classify users in various ways, Within, is represented by at least one profile record 225 as well as account record 205. Each profile record allows the user to establish different degrees of anonymity, respond to different types of tasks, and display the user's credentials and expertise in different ways. A given task is presented by a profile belonging to the service requester, and the response to the task is made by a profile belonging to the service provider. Thus, in the following, tasks are presented by a "user" and "profile" pair and responded by another "user" and "profile" pair. A user's account record 205 can be associated with a number of profile records 225. Each profile record can be associated with a single reputation record for expertise (229) and action (223) and a single reputation record as buyer (235). These assessments include how service requesters have evaluated the service provider's expertise and practices in providing the service in the past and how the service provider has historically addressed the buyer. Show what you felt. Of course, a given profile record 225 will be associated with a buyer reputation record 235 only if the profile functions as a service requester. Similarly, the profile record 225 is associated with the technical and activity evaluation records
Only if the profile acts as a service provider.

The profile record 225 and the technical record 221 become the profile record 225 according to the profile technical record 241 and the profile educational record 245.
Linked to one or more of the following. With this configuration, the service provider 10
7 can list several sets of information per profile regarding their expertise and educational background. For example, a lawyer who has been formally trained in a foreign language may have a profile record 225 for a legal task and a profile record for a translation task, and the legal profile record may be Associated with the education record 217 and the technical record 221 indicating training and expertise, the translation profile record includes the education record 217 and the technical record 221 indicating the language training and expertise of this lawyer.
Is related to The user aspect represented by a given profile record is referred to herein as the user's profile. Therefore, this lawyer is
Has a legal profile and a translation profile in 1.

The rest of the tables (247, 255, and 271) in FIG. 2 are all about tasks and are described in more detail below. A given task is associated with a user and profile pair, represented by a profile record 225, by a provider status record 261. The relationship between a user's profile record 225 and the provider state record is one-to-many, as would be expected given a given user can handle several tasks of a given type. A task record 249 for the task itself is included in task table 247, and the solution for the task is included in solution table 267.

With continued reference to FIG. 3, FIG. 3 details a table associated with a task. There is one task record 249 for each task. Each task
Record 249 is associated with one or more user and profile sets. For a given user, profile and task set, this relationship is represented by that user and profile set provider status record 261 for that task. Thus, each set of user and profile has a respective provider status record 261 for each task with which the set of user and profile is associated.

[0107] The contents of the task record may be related to whether the task record is associated with a service requester profile, or one or more service provider profiles, or a service requester profile and service. Depends on whether it is associated with both provider profiles. task·
If the record is associated with a service requester profile, it has a one-to-one relationship with the service requester's purchaser payment method record 209 and a one-to-one relationship with the task's pricing scheme record 309; It has a one-to-one relationship with the activity record 257 of the service requester. The price determination method record 309 has a one-to-many relationship with the negotiation state record 313. There is a negotiation status record 313 for every service provider with which the service requester is currently negotiating the performance of the task represented by the task record. Each task record 249 may further be associated with a number of status history records 253, each tracking a change in the status of the task. The status history record 253 for a task allows the audit trail for that task to be reconfigured.

Each provider status record 259 and each task record 249 include an activity record 257
And a many-to-one relationship. A given activity record 257 records a single transaction for a given user, profile and task set. All task activity records can be found in task record 249,
The activity record for a given user, profile and task set can be found from this set of provider status records 261. Activity record when the profile to which activity record 257 belongs is acting as a service provider for this task
257 further has a one-to-one relationship with the service provider account record 205;
It has a one-to-one relationship with the provider payment method record 213. The latter record indicates how the provider to which this profile belongs will be paid.

The provider status record 261 for a given user, profile, and task set has a one-to-one relationship with the task record 249 for this task, and the negotiation state record 313 for the user, profile, and task set. One-to-one relationship with solution record 269
Also has a one-to-many relationship with Each solution record 269 is represented by one of the service provider and profile pairs of the set of tasks represented by task record 249.
Represents one solution. The solution history table 207 includes a record for each solution as long as the task is a service provider-profile pair. Finally, there is a one-to-many relationship between each solution record 269 and a solution file record 315 that contains the pathname of the file containing some or all of the solution. As with the task records, each provider status record 261 can be associated with a number of status history records 253. Each status history record 253 records a change in the status of a set of a user, a profile, and a task represented by the provider status record 271. As with tasks, these status history records 253 are used to construct an audit trail.

As is clear from the above description, the task association table 301 makes it easy to find all task records 249 for each set of user and profile. The user, profile, and task set task record 249 can be easily found via the user, profile, and task set provider status record. Finally, the task category table 303 allows finding task records 249, generally by task type.

FIG. 4 shows a table containing information on messages exchanged between each user of the system 101. Depending on the aspect and / or the user's choice, the message remains internal to system 101 and can be read or written using web server 111, or dispatcher 114 can send email client 122 To send the message originated in the system 101 to the receiving user via e-mail, and the user 104 sends a message for other users to the server 109 using his / her e-mail, 109 can also respond to this message by sending an email to the recipient. Each message has a message record 409 in the message table 407. The message includes a task and has a sender and / or a recipient that is the user 104,
There can be a one-to-many relationship between profile record 225, account record 205, task record 249, and message record 409 because other users 104 can be involved. Thus, messages can be found by user, user / profile set, and task. Dispatch system
The server 109 stores a given user and profile pair in a given task record 249.
Or use the table reference record 405 to track whether or not the message record 409 was examined and when it was last examined.

Details of Tables in Database 125: FIGS. 5 to 12 FIGS. 5 to 12 show SQs related to records in the main tables shown in FIGS.
Shows the L query language declaration.

Details of Account Record 205: FIG. 5 FIG . 5 shows the account record 205. Each account record is
If the value in field hd_account_id 501 is indexed and another record has a relationship with a given account record 205, then that record is
It includes a field having the value of field 501 of a given account record. Five
The field indicated by 03 tracks the modification of record 205. Each field indicated by 505 stores contract information on the user. The following three of these fields are particularly important: username is the name of the user represented by record 205 as known to system 101. taxonomic_categories specifies the category to which the user belongs, for example, a translator or a lawyer, and allows the user to be searched by the category to which the user belongs. receive_email is a flag indicating whether the server 109 converts its internal message to the server 109 into an email and sends it to the user represented by the account record 205.

At 507, buyer_pay_method_id and provider_pay_method_id are record identifiers of the user's purchaser payment method record 209 and / or provider payment method record 213. Which identifier actually exists depends on whether the user is a service requester, a service provider, or both. The information at 509 is personal information that the user wants to make invisible to other users of the system 101. The visible field indicates which of this information is to be made visible. status 510 indicates whether the user represented by the account is active or inactive. current_profile_id
511 indicates which of the profile records 225 belonging to the account record 205 is of current interest. At 513, fields that can contain simple questions and simple answers are shown. The user provides this question and answer when registering, and the question and answer is used to verify a user who has forgotten their password.

At 515, whether the system 101 currently pays user 104 or user 1
A field balance indicating the balance of whether 04 makes payment to the system 101 is shown. In this and other fields in database 125, amounts are expressed in whole cents. The field indicated by 517 is a time stamp field, and indicates the last modification made to the record belonging to the user having the record name indicated by the time stamp name. Therefore, expertis
es_time indicates the latest change of the record belonging to the user in the technical table 219. The time is expressed as an integer number of seconds after the start time fixed by the system 101. In a preferred embodiment, such time is used to control caching of portions of database 125. The field 517 contains information about any escrow account that the system 101 maintains for the user. Finally, upload
The _directory field 519 contains the file name of the dispatch system server 109.
This is a field in the system indicating the directory where the user's files are uploaded.

Details of educational record 217 and technical record 221: FIG. 6 The key fields of these records are shown at 601 and 609. Fields 611 and 603 track the modification of the record, and owner IDs 613 and 605
Hd_ac of account record 205 of the user whose technical skill or educational background is specified
Contains the value of the count_id field 501. In general, the field named owner_id in a record contains the index of the record to which the record containing that field “belongs”, ie, the record in which the record containing this field is generally located. In record 127, the field indicated at 615 contains the actual information regarding the user's educational background. In record 221, the field indicated at 607 contains the actual information about the expertise. In either case, the visible flag allows the user to decide whether to make the educational information or the technical information visible to other users of the system.

Details of Provider Payment Method Record 211 and Buyer Payment Method Table 209: FIG. 7 FIG. 7 shows records of these tables. In a preferred embodiment, these tables are implemented as a single pay_method table containing the records of both tables. Which table a given record belongs to is indicated by the value of the class flag 705. Reference numeral 701 denotes a record key used in the account record 205 and the profile record 225. Each field of 703 tracks the modification of the record. The remaining fields, shown at 707, contain the checking account credit card information that the system uses to make and receive payments.

Details of profile record 211 and rating records 229, 233, and 237: FIG. 8 As described above, the preferred embodiment profile allows the user to see how he or she looks to other users of system 101. Can be controlled. A given user may have several profile records 211, where each profile record contains information specifying different aspects of how the user interacts with the system 101. For example, a user 104 may (but need not) have one profile as a service requester 105 and another as a service provider 107, as well as requesting various types of services. Or if the provider offers different types of services, the requestor or provider can have a different profile for each type of service. When a user registers with the system 101, the system provides the user with a default profile. The user can edit this profile or create another profile.

As shown in FIG. 8, the profile record 225 has an index at 801;
803 has change tracking information. The owner_id 805 has, as its value, the hd_account_id 501 of the account table 205 for the user 104 to which the profile record 225 belongs. The name field 807 is the name of the profile represented by the profile record 225. taxonomic_categories 809 is the profile record 22
Indicates the type of service that the profile represented by 5 performs. This field is used to find potential service providers for the presented task. e
Mail field 811 indicates the email address for messages addressed to this profile. If inherit_emails is specified, the email address will be the address specified in account record 205. As shown at 812, the profile record 225 can have an index 701 of the two records in the payment method table.

The visible 813 indicates what information in the profile record 225 should be made visible to other users of the system 101. description 815 is the written description of this profile. At 817, there is information used to evaluate the effectiveness of this profile. This information includes an index 821 for the three evaluation records 229, 233, and 237. Finally, at 819 there is a set of timestamps indicating the tasks that were first performed by this profile, the tasks that were last performed by this profile, and the last time various tables belonging to this profile were modified.

In a preferred embodiment, all records in the evaluation tables 227, 231, and 235 are:
Included in a single evaluation table. Figure 8 shows the SQL for records in the evaluation table.
229, 233, and 237. Each record is accessible by an index 821 and has modification information 823, a class value 825 indicating which of the three classes the class contains, and a cumulative current rating. As shown at 825, the ratings are specified as the sum of past ratings, the number of ratings, and the average.

Details of Task Record 249 and Task Solution Record 269: FIG. 9 FIG. 9 shows the SQL declaration for task record 249 and task solution record 269. First, in the case of task record 249, there is one such record for every user profile pair for this task. Each task record 249 has its own task_id index 901. Reference numeral 903 indicates correction information. owner_id 905 is the profile_ of the profile of the user profile pair
It has id as its value. structured_category 907 is a local entrapment of categorization information about this task, used to search for tasks by category, and used with category 809 in profile record 225 to match tasks with service providers Is done. dispatch_prototype 909 indicates how the system 101 handles tasks. For example, if the task is a question, the system 101 records the service provider that simply presents the task and provides an acceptable solution, rather than actually assigning the task to the service provider, and then Allocate payment to the service provider.

The fields of 911 describe the task by name, description, and URL, and when publishing the task, ie, making the solution available to anyone who can access the system 101, the public_directory is , Specify that the task solution can be made public and therefore stored in a publicly accessible directory within the system 101. Each field of 913 contains task pricing payment information, 9
Each of the fifteen fields contains a value indicating the status of the task. When the task is being performed by one service provider, the field indicated by 917 contains information about the provider. In this case, a time stamp 919 is included for a change in the table containing information about the provider and the task.

As will be seen with continued reference to the task solution table 269, each such table has its own index 921 and its own update information 923.
task_id 925 is the task_i of task record 249 representing the task to which this solution belongs.
It has d 901 as its value. owner_id 927 is a provider_state_id 110 of a provider state record 261 representing a set of a user, a profile, and a task to which this solution belongs.
Has 1 as its value. Each field of 929 contains status information about this solution. Field 931 contains the solution for the task if the solution is small enough to fit in task solution record 269. If the task solution record 269 does not fit, the flag 933 indicates so, and each record has a task_solution_id 921
, Indicating one of the files containing this solution,
There are one or more solution file table records 317. 935 has various time stamps. seen_time indicates the last time the service requester checked the task. The other two fields are the task status history record 25
3 and time stamp for solution history record 273.

The price determination method record 307, the negotiation state record 311 and the negotiation history record 265
Details: FIG . 10 The table shown in FIG . 10 implements an arrangement in the system 101 for determining the price of the solution. Pricing scheme record 307 contains the scheme selected by the service requester to determine the price of the service. This record is a pricing method record
A record 249 for this task with 307 pricing_scheme_id 1001 as its value
Found at 913 in pricing_scheme_id. Next, a correction record,
There is a class field 1005 which indicates the class of the pricing method to which this record belongs, and which field is the relevant field, then the mechanism used to determine the price, the highest bid ( If you use the bidding system)
There is an index of the winning bidder's account record 205, and a pricing information field 1006 describing the commission of the provider of the system 101.

The history of the current pricing state and past states is represented by records 311 and 265. The negotiation state record 311 indicates the current state. Get involved in a task,
Each user, profile, and task set has a record 311, and the set of provider status records 261 includes the index of the record 311 at 1109. The fields of the negotiation state record 311 include an index 1007, normal correction information 1009, a class of the negotiation state record, a polarity 1013 indicating whether to increase or decrease the bid for the auction, and a record 311. Includes an index 1015 of the pricing scheme record 307, a service provider bid 1017, represented by the negotiation status record, and a time stamp 1019 for the latest change in the negotiation history record of the negotiation.

Each stage of the negotiation represented by the negotiation status record 311 has a negotiation history record 265. In the fields of this record, the key 1021, the normal correction information 1023,
Field 1025 whose value is the key of the negotiation state record and the record in the negotiation
The field 1027 of the amount reached at the point represented by 265 and the negotiation history record 265
A whocode field 1029 indicating whether the party taking this action in the negotiation represented by is the service requester or the service provider. The records 307, 311 and 265 for the user and profile and task set involved in a task collectively allow a complete audit trail of the negotiations for which the service provider has determined the price of providing this service.

Details of Provider Status Record 261 and Activity Record 257: FIG. 11 The provider status record 261 relates a user and profile set to a single task record 249, and thus the users, profiles and tasks in the system. Represents a set of 1101 indicates the index of this record, and 1103 indicates correction information. At 1105, reference fields whose values are the index of the task record 249 and the index of the profile record 225 for the user and profile pair are shown. status 1107 contains the current status of the user, profile and task pair represented by the record. In a preferred embodiment, the status depends on whether this set of user profile pairs is acting as a service requester or as a service provider. If the user profile pair is a service requester, the status will be: • Pending • Allowed • Release • Subscription pending • Assigned • Resolved • Paid • Expired

If the user profile pair is a service provider, the status will be as follows: Not involved-Assignment accepted-Assignment accepted-Assignment accepted-Assignment rejected-Assignment rejected-Resolved-Resolved Solution Release-Receipt of Modification Request-Payment Reception-Expiration-Solution Rejected And the index of the solution record 269 for the solution. price
The _paid field 111 indicates the price paid by the service requester of this service, each field of 113 contains the expert rating for a given service provider and a set of profiles and tasks, and the field offer 1115 Is the latest application given by the service requester to the service provider. The time stamp at 1117 includes the last time the service requester saw this solution and the status history record 253 for this service provider, profile and task pair.
And the last update time of the solution record 269. The tip_amount field 1119 indicates the amount of tip paid by the service requester to the service provider.

Activity record 257 maintains payment information for a given user, profile and task set. The fields include an index 1121 of this record, modification information 1123, an index field 1124 of this user / profile / task set task record 249 and a provider status record 261, and Field 1125 indicating the class of the activity record 1125 and a field 1127 containing the index of the account record 257 of the service provider. Finally, the field indicated by 1131 contains payment information for the user, profile and task set.

[0131] status history record 253, solution log record 273, and details of the message record de 409: 12 status history record 253 is generated each time the status of the task changes. A record is created for the task and for the set of users, profiles and tasks that effected this change. Therefore, the task
Both the record 249 and the provider status record 261 have a one-to-many relationship with the task record. As can be seen from the foregoing, the sequence of status history records for a task allows for an audit trail of this task and an audit trail of the set of users, profiles and tasks involved in this task. The index of this record is shown at 1201 and its correction tracking field is shown at 1203. owner_
The id 1205 is an index of the task record 249 or the provider state record 261 to which the status history record 253 belongs. status 1207 indicates the new status of this task. This value is the same as the value of the status field 1107 in the provider state table 261.

A solution history record 273 is created each time a provider, profile, and task set provides a new solution for this task. Fields 1209 and 1211 are a record index field and a change information field, each field containing the index of the solution record 269 for the provider, profile and task set. The solution_text 1215 is a copy of the solution_text field 931 of the solution record 269 of the task whose history has been recorded.

A message record 409 is created each time a user of the system 101 sends a message about a task to another user of the system, and whenever the system 101 sends a message about a task to a user. You. Each record
409 has an index 1217 and correction information 1219. Field 1221 is the index of task record 249 of the task associated with this message. cla
The ss field 1223 indicates the class to which this message belongs. There are three classes: system messages, requester messages, and provider messages. The text field 1225 contains the text of this message. A field named 1227 indicates the user associated with this message as the sender, receiver, or subject of the message. Each field is an associated user's account record
Includes 205 indexes. seen_time 1231 indicates the time at which the receiver saw this message, and each field indicated by 1233 indicates whether the sender detected this message or whether the receiver detected this message. As can be seen from the foregoing, message records 409 allow messages to be easily retrieved by sender, receiver, subject, or task, and the sequence of messages for a task is part of that task's audit trail. It is.

Storage and Audit Trail in Database 125 The system 101 sets a field in a task record 249 for a task to indicate that the task is stored, and then when the task is stored. Save the current state of this task by copying the state of the task to This copy is part of the archive information 137. The system 101 then moves the stored tasks (either nightly or weekly, depending on the amount of tasks and the load on the system) to a replica of the task table 247, which is in a different tablespace (this involves disk access Is done to optimize and achieve parallel query efficiency). When the stored task record 249 is moved, the copy of the database record accessible through the task index is also moved. Since nothing is actually lost from the database and all actions are recorded by creating records in the table,
An audit trail can be performed by searching for relevant information at.

Overview of Database Processing Routine 115: FIG. 13 FIG. 13 shows the routine used in the preferred embodiment to process the dispatch system database 1255. These routines are subdivided into the groups shown in FIG. The following discussion describes the function of each routine, as well as the basic tables in the database 125 that are read and written by the routine.

The user routine 116 and the user registration routine 1301 create a user account record 205, and create a profile record 225 when the user presents profile information. If the user so instructs, routine 1301 also creates one or more education records 217, expertise records 221 and payment method records 209 or 213. A user search routine 1303 searches for a user profile by name or category, ie, the type of expertise or educational background the user has. The user information display routine 1303 enables the user to display information in the profile table and to display information in the educational background table, the technical table, and the evaluation table obtained through the profile table. A user information evaluation routine 1305 enables one user to evaluate the performance of another user as a service requester or service provider for one task. This routine writes a rating to the provider status record for this user, profile, and task, and updates the expertise rating record 229, 233, or 235 associated with this profile.

The task routine 117 and the task presentation routine 1307 create a provider status record 261 and a task record 249 relating to a set of a user and a profile presenting the task. A task display routine 1309 displays information from the task record 249 and information from the pricing scheme record 309 for this task record. The task search routine 1311 searches for a task according to the category in the task record 249. The task bidding routine 1313 creates a provider status record 261 for the set of provider, profile and task, creates a negotiation status record 313 for this set, and sends a message to the requester, profile and task set. In sending a message, a send message routine 1325 is used to create a message record 409. The bid response routine 1315 modifies the pricing scheme record 309 to reflect the current bidding status, and when a bid is accepted, uses the send message routine 1325 to contact the awarded provider. Send a message to a set of profiles. The provider payment routine 1317 includes a pricing method record 309 for this task.
Information and provider payment method table 21 for this provider and profile pair
This provider is paid for this service using the information in the activity record 207 for the requester, profile and task set.

The Solution Routine 118 / Solution Presentation Routine 1319 includes a solution record 269, a solution history record 273, and, if necessary, a solution file record 317 for the solution of the provider, profile and task set. And send a message indicating that a solution has been provided to the set of requesters and profiles for this task using the send message routine 1325. The solution display routine 1321 displays the solution of the task represented by the solution record 269, including displaying the file specified by the solution file record 317. In some cases, the solution is ambiguous. The Accept / Reject Solution Routine 1323 creates a Solution History Record 273 and, if the solution is accepted, uses the Provider Payment Routine 1317 to pay for the winning Provider and Profile pair. Do. Even if the solution is accepted,
If rejected, the routine uses the send message routine 1325 to send a message to the solution provider and profile set.

Message Routine 119 Message Send Routine 1325 sends a message about the task to the user while creating message record 409. Message Display Routine 1327 allows a set of users, profiles and tasks to display messages related to this set and tasks.

The archive routine 120 and the archive search routine 1329 are stored in the database 125 using the user search routine 1302, the task search routine 1311, the user information display routine 1303, the solution display routine 1321, and the message display routine 1329. Displays the information that is displayed.

Details of the User Interface of the System 101 As described above, the user interface of the system 101 is a web page. In the following, exemplary parts of the user interface are described and the relationship between these parts and the database 125 is shown.

Initial Screen: FIG. 14 FIG. 1 shows a web page first received from the server 109 when the user inputs the server address of the server 109 into his / her browser. This page describes what the service dispatch system looks like and has a section 1403 that allows registered users to log in and allow other users to register. Has a tab bar 1405 for tabs for initial web pages in other parts of the user interface of the service dispatch system.

Registration: FIGS. 15 and 16 FIGS. 15 and 16 show the registration interface. FIG. 15 shows the user name and
Shown is an interface 1501 that collects a password of 1503, an e-mail address of 1505 used by the system 101, and a specification of 1507 on how to receive the e-mail. The information specified here becomes part of the account record 205 for the new user. FIG. 16 shows an interface 1601 that collects the user's real name at 1603 and location information at 1607 and requests the name of the default profile record 225 at 1605. As shown in interface 1601, the system
101 protects the user's privacy of the system by never revealing the user's real name contained in the account record. As shown in 1607,
The user can select a part of his / her location information to be disclosed.

Task Presentation: FIGS. 17 and 18 FIGS. 17 and 18 show the interface used by a service requester to present a task. FIG. 18 shows an interface 1801 for defining a task. The task in this case is a question. At 1803, the task requestor enters a task name, task category, presentation date, price, and task description. As can be seen from 1803, the task requester can specify the time remaining in responding to the task, and also reveal the task in response to a query by the service provider.

FIG. 17 illustrates an interface 1701 used to categorize tasks and specify prices.
Is shown. At 1703, the service requester provides a primary category 1704 and selects a small category 1705 from the list. At 1706, the requester further categorizes the programming environment associated with the question. This information enters task record 249 for this task. At 1707, the requestor sets a fixed price of $ 30.00 for this task, and system 101 describes the payment terms. Information on the price is stored in the price determination method record 309 belonging to this task.

At 1807 and 1813 in FIG. 18, the interface for the service requester to keep pursuing the solution of the task is shown. Bar 1807 indicates that the status of the task has been resolved. The 1811 button allows the service requester to add a description if the solution indicates that a description is needed and to pay the service provider if the result is appropriate To be able to 1813
Shows a list of solutions offered by the service provider to the question and messages about this question. The information here is the solution record 26 for this task.
9 and message record 409.

Task Assignment: FIGS. 35 to 39 When the requester or system 101 selects one or more profiles of a service provider that resolves a task, the system 101 proceeds to associate this task with the profile. A provider status record for each selected profile
Create 261 and then send a message to this provider indicating that it has been selected. When a provider, in this case, a provider having the profile name “hoop” views a task related to this profile, a task notification interface 3501 shown in FIG. 35 is displayed. At 3503, the interface describes the task, presentation profile, presentation time, remaining time to perform the task, and price. This information is, of course, included in the requester's profile, the provider status record 261 for the requester, profile and task pair, and the task record 249 for this task. Since the provider has not yet taken action on this task,
Field 3505 indicates that the status of the task for this provider is not involved. The 3505 button allows the provider to request to be assigned to this task or to send a message containing a question to the requester. At 3507, an interface is shown where the provider receives the message and writes his solution to this task.

When the provider clicks the allocation request button, the interface 3601 shown in FIG.
Is displayed. In the application amount 3603, the provider inputs how much fee he / she wants for this task, and writes a message indicating his proposal in 3605.
When the provider is satisfied, he / she clicks the “submit” button. As a result of this action, the system 101 creates a message record 409 for this answer, updates the negotiation state record 313 for the provider / profile / task pair,
Create a status history record 253 indicating the transaction for the provider / profile / task pair.

FIG. 37 illustrates an interface 3701 used by the requestor to cause the provider to assign tasks based on the request of the provider. At 3703, there is a table of action items related to the requester profile of this task. 3705, the profile "hoop
An item is displayed indicating that "s" has bid $ 33.00 to perform this prime calculation task. At 3707 there is a table listing the new messages received by this requester profile. In 3709, when requesting an quota, "hoops
Is shown in the message text sent. 3711 shows a table of recent task status. The entry for the prime task is shown at 3713. The status of the prime task in the service requester profile is "pending" because no bids have been accepted yet.

FIG. 38 shows the interface displayed when the service requester clicks the underlined portion of the row 3705. Interface 3801 shows at 3803 a description of the task, including the current price. At 3805, it is shown that this task has the status "pending". With the add description button, the service requester can add a description of the pending task. Under "Solutions and Messages", the results of the "hoops" assignment request are shown, showing the service requester's profile name, amount requested, and message 3811 sent with the assignment request. This information is, of course, included in the record created when the provider requested that this task be assigned to him. The service requester accepts or rejects the application using the button at 3809. In this case, the requester accepts the application and therefore clicks the thumb up button. As a result, the provider status record 261 and the negotiation status record 313 of the requester / profile / task pair have been created, and the new status history record 253 for the requester / profile / task pair has been created. Is updated to indicate System 101 then notifies that it has been assigned to this provider profile.

Finally, FIG. 39 shows the interface used by the provider to accept assignments
3901 is shown. This provider simply submits (subm
Click the it) button 3907. If the provider needs to send a message with this confirmation, it writes the message in box 3905. Submit
Clicking on the button 3907 changes the status of this task to "assigned" in the provider status record 261 for both the requester, profile and task set and the provider, profile and task set. Two provider status records
A status history record 253 is also created for 261 and task record 249.

Accepting or Rejecting a Solution : FIG. 19 Interface 1901 is an interface for accepting or rejecting a solution. This interface is displayed when the service requester clicks on one of the solutions listed at 1813 in FIG. At 1903, a description of the solution is provided, including the name of the service provider profile that submitted the solution, the submission time, and the text of the solution. If the solution is long, the file
The upload 1905 indicates where the service requester should look when looking for a solution. This information is contained in the solution record 269 for this solution and, in the case of a file name, in the solution file record 317. At 1907, the service requester can send a response message to the service provider profile for this solution. At 1909, the service requester can respond to the solution by requesting a correction, sending a message, or simply rejecting the solution. In either case, the interaction on this screen creates a status history record 253 for this task.
A solution for a task is accepted when the service requester selects the pay button at 1811 in FIG. At that point, all solutions that have not been rejected are acceptable.

Evaluation of Service Provider: FIG. 20 The interface 2001 is an interface for evaluating a service provider who has provided a solution to a task. As you can see in 2003, each provider
The provider has a row in the table identified by the profile name of the profile used to solve this task. The columns in the table allow the requesting user to evaluate the quality and temporal suitability of this solution and provide comments. This information is placed in the provider status record 261 for this profile and task and is periodically summarized for this profile in the records in the rating tables 229 and 233.

Allocation of Payments between Service Providers: FIG. 21 The service requester can specify the maximum number of solutions for fixed price tasks, and this fixed price can be split among the service providers. . Also, the service provider can add a tip to the payment amount. Interface 2101 is an allocation chip interface. The table 2103 has a row 2105 for each service provider that solved the task. Each row assigns a relative payment and specifies how much the service provider will receive given the current allocation 1
Has a set of buttons. Each line is a field that specifies a tip for respondents,
It also has a field for the total payment to be paid. After confirming the allocation, the service requester presses button 2107 to enter this allocation and tip. As a result, a value is set in the provider status record 261 for each user and profile pair that provided the solution.

Send Message: FIG. 22 FIG . 22 shows a message message for sending messages between users of the system 101.
An interface 2201 is shown. In this case, as shown at 2203, a service provider having a profile of ganesh has transmitted a message regarding the task “question to ganesh” to the service requester of the task. The service requester can write a response in box 2205 and when done, click button 2207 to send this message to the service requester. Of course, the message from ganesh is included in message record 409, and this response creates a new message record 409.

Project Presentation: FIGS. 23 to 25 In this case, the project is a Java applet. Interface 2301 describes this new project. At 2303, the service requester specifies the name of the profile that proposes this project. At 2305, the service requester enters a project name. At 2306, the service requester enters project details.
At 2309, the service requester selects a broad category of projects.

With continued reference to FIG. 24, there is shown an interface for selecting a method for determining the value of a project. As shown at 2401, in a preferred embodiment, the service requester determines that the project has a fixed or non-negotiable fixed price, or that the price of the project is three bids: a reverse auction, a sealed bid, and an auction auction It can be specified to be set by one of the methods. Here, the service requester has the selected sealed bid.

In FIG. 25, an interface for selecting a small category to which a project belongs
2501 and an interface 2509 for specifying a price are shown. The wide category selected in 2309 is displayed in the interface 2503, and the list 2505 shows a small category of the category displayed in 2509. The service requester then characterizes the project by selecting one or more subcategories and specifying a programming environment for the 2507 code. At 2509, the service requester enters the maximum price at 2511 and the duration of the bid at 2513.

In response to the information being entered by the service requester as described above, the system 101 returns a new task record 249 for this task, a service requester profile and a provider status record 261 for the task, Task category record 305 for the task, and pricing method record 307 for this task
Create

Task Status Interface for Service Requester: FIGS. 26 and 34 FIG. 26 shows the task status interface 2601 for the service requester. The 2603 and 2605 buttons allow the user to submit a new project or question using the interface described above. Table 2607
Contains a row for each open task submitted by the service provider. Each row specifies the date the task was presented, the time remaining to complete the task, the task status, the task name, the category to which the task belongs, and the price. The release status here indicates that the task has been submitted but not yet bid. This information is, of course, included in the task record 249 and the pricing scheme record 309 for this task. At 2609, a list of all closed tasks is displayed.

FIG. 34 shows an interface 3401 used by the service requester to display messages for tasks related to the service provider. Table 3403 shows a row for each open task message, with columns for the action taken by the recipient, the date of the message, the sender and recipient, the message, and the name of the task to which the message belongs. As can be seen in the sender-receiver column, messages can be exchanged between the service requester and the service provider, and messages can be exchanged between the system and the service requester or service provider. You can also. The information in the table is contained in the message record 409 for the task.

Service Provider Selection Interface: FIG. 27 The system 101 itself provides services based on the categories assigned to the task by the service requester and the reputation information maintained by the system 101 with respect to the service provider. It also selects one or more service providers for the provider, but also has an interface 2701 shown in FIG. 27 that allows the service requester to select a service provider. At 2703, the service requester can select a service provider by the name of a profile belonging to the service provider. In other cases, the user can select a category from the list 2705 that indicates the type of expertise required by the service provider, and the system 101 will select a service that has at least one of these types of expertise. Give a list of providers. Part of the returned list is shown at 2709. Each service provider has a row on the list, where each row specifies the provider's profile name, the provider's expertise, the provider's usage time of the system 101, and the provider's current rating. The system 101 selects a service provider based on the category field 809 in the service provider's profile record 225. The information in Table 2709 is the profile of the service provider.
Record 225 with associated reputation records 229 and 223 and technical record 2
Included in 21.

Service Provider Task Interface: FIGS. 28-30 FIGS. 28 and 29 illustrate the interface used by a service provider to display the tasks available to a particular profile of the service provider. I have. In FIG. 28, the interface 2801 describes the tasks that the service provider has specifically proposed for this profile (2803), the tasks that can be performed by this profile (2805), and the tasks that this profile involves (2807). Be able to see. “Involved” here means that the profile has taken some action with respect to this task. This information is contained in the provider status record 261 for this profile and the task record 249 associated with each provider status record. At 2809, the service provider can view the tasks completed by this profile. FIG. 29 shows an interface 2901 that can be used by a service provider to display messages about tasks sent or received by this profile. The service provider can see the open task message at 2903 and 2905
To see the closed task message. This information is contained in the message record 409 for the task involving this profile.

FIG. 30 is an interface used by service providers to generally browse for tasks. Interface 3001 includes a search interface that allows the service provider to search for tasks by pressing button 3007. This search can be done by task ID as shown at 3005 or by category as shown at 3009. The interface 3001 also includes a list 3011 of recently submitted tasks available for solutions by any service provider. Each task has one row in the list containing the date of the offer, the name of the task, and the price.
Have a row. The information in the rows of this table is the task record for the task
249 and included in the pricing method record for the task.

Editing Account and Profile Records: FIGS. 31 and 32 FIG. 31 shows the interface 3101 used by a user of the system 101 to edit his or her account record 205 and related records. 3103
At, the user enters an interface for changing the login contact information in the account record 205. At 3105, the user can edit the buyer payment method 209 for the account record. At 3107, the user can edit the provider payment scheme record 213 for the account record. At 3107, the user can also edit the education record 271 and the expertise record 221 associated with the account record.

FIG. 32 shows a profile record 2 belonging to the user's account record 205.
Shows an interface 3201 that can be used by the user to edit 25. 3203
As shown, the user can create a new profile, edit an existing profile, or create a default profile. 3204
Shows a list of profiles belonging to the user. For each profile, the profile name, associated expertise, date the profile was created,
The rating of the profile as a provider and buyer is listed. The information edited is the profile record 225 and the associated reputation records 229, 233
, And 237.

Interface for Displaying a User's Financial Account in System 101: FIG. 33 FIG . 33 shows an interface 3101 for displaying a user's financial account in the system 101. At 3303, a table summarizing the financial transactions on this account is shown. An interface 3305 displays a list of activities related to the current account. The information in this table is contained in the user's activity record 257.

Conclusions The present inventors have disclosed to a person skilled in the art involved in a service dispatch system the best way of implementing this system now known to the person skilled in the art. However, as will be readily apparent to those skilled in the art,
There are many ways to implement the principles of the dispatch system, other than those disclosed herein, and the implementation depends on the type of service requested and provided. For example, in some implementations, a service requester and a service provider can interact directly with each other without using a profile. In other embodiments, the tasks may all have a fixed price, and in yet other embodiments, trading techniques other than those disclosed in the preferred embodiment may be used. If the system is dedicated to a particular small set of tasks, the need for service requesters and service providers to categorize and match by category and expertise is eliminated. In other aspects, other techniques can be used to select a set of service providers to which tasks can be assigned. For example, the system may maintain a list of currently available service providers ordered by the last task completion date, and simply select the service provider that has not been assigned a task for the longest time.

The techniques used to obscure task solutions and to address poor solutions can also vary depending on the type of system. For example, for simple tasks, the service requester may only be allowed to accept or reject the solution. The payment system can include any mechanism that ensures that the accepted solution is paid, and can use any mechanism that stores the information that enables the audit trail required for each aspect. For example, if the solution is simple and the price is not negotiated, the audit trail is only used to determine how much the service requester should pay the system and how much the system should pay the individual service providers Is required.

Although the Internet provides a particularly advantageous environment for service dispatch system users, the system can be used in any environment that provides the system with an interactive interface with the user.

For all the foregoing reasons, the detailed description should be considered in all respects as illustrative and not restrictive, and the scope of the invention disclosed herein is not limited to It is intended to be determined not by the detailed description, but by the claims which are construed to include the full scope granted by patent law.

[Brief description of the drawings]

FIG. 1 is a schematic diagram of a system for processing requests for non-standardized services.

FIG. 2 shows a first example of a database used in a preferred embodiment of the system of FIG. 1;
FIG.

FIG. 3 shows a second database used in the preferred embodiment of the system of FIG. 1;
FIG.

FIG. 4 is a third database used in the preferred embodiment of the system of FIG. 1;
FIG.

FIG. 5 is a diagram showing an SQL definition of an account record 205.

FIG. 6 is a diagram showing SQL definitions of a learning record 217 and a technical record 221.

FIG. 7 is a diagram showing SQL definitions of payment method records 209 and 213.

FIG. 8 is a diagram showing SQL definitions of a profile record 225 and evaluation records 229, 233, and 237.

FIG. 9 is a diagram showing SQL definitions of a task record 249 and a solution record 269.

FIG. 10 is a diagram showing an SQL definition of a price determination method record 307, a negotiation state record 311 and a negotiation history record 265.

FIG. 11 is a diagram showing an SQL definition of a provider status record 261 and an activity record 257.

FIG. 12 is a diagram showing SQL definitions of a status history record 253, a solution history record 273, and a message record 409.

FIG. 13 is a schematic diagram of a database processing routine 115.

FIG. 14 is an initial web page of a user interface.

FIG. 15 First user interface for setting up an account
FIG.

FIG. 16: Second user interface for setting up an account
FIG.

FIG. 17 shows a second part of a user interface for presenting a question.

FIG. 18 shows a first part of a user interface for presenting a question.

FIG. 19 shows a user interface for displaying a solution.

FIG. 20 is a diagram showing a user interface for evaluating a service provider.

FIG. 21 illustrates a user interface for allocating payments between service providers.

FIG. 22 is a diagram showing a user interface for displaying a message.

FIG. 23 is a diagram showing a user interface for presenting a project.

FIG. 24 is a diagram showing a user interface for selecting a task pricing method.

FIG. 25 illustrates a user interface for classifying tasks and setting up sealed bidding for tasks.

FIG. 26 is a diagram showing a user interface for displaying an open task.

FIG. 27 is a diagram illustrating a user interface for finding a service provider.

FIG. 28 illustrates a user interface through which a service provider can view presented tasks.

FIG. 29 illustrates a user interface that allows a user to display a message about a task.

FIG. 30 illustrates a user interface through which a user can view tasks.

FIG. 31 shows a user interface that allows a user to edit his or her account.

FIG. 32: Users who can edit their profile
It is a figure showing an interface.

FIG. 33 illustrates a user interface that allows a user to view his or her balance in the system 101.

FIG. 34 illustrates a user interface where a user can view task messages for tasks associated with one of his profiles.

FIG. 35 illustrates a user interface by which a service requester can present tasks to be assigned.

FIG. 36 is a diagram showing a user interface through which a service provider can apply for execution of a task.

FIG. 37 is a diagram showing a user interface through which a service requester can receive an application from a service provider.

FIG. 38 is a diagram showing a user interface in which a service requester accepts an application from a service provider.

FIG. 39 illustrates a user interface for accepting assignment of tasks by a service provider.

40 is a flowchart of an operation of the system 101. FIG. The reference numerals in the drawings are three or more digits, and the two right-hand digits are the reference numbers in the drawings indicated by the remaining numerals. Thus, the item having the reference number 203 first appears as item 203 in FIG.

────────────────────────────────────────────────── ─── Continued on the front page (72) Inventor Bramberg Andrew Jay. Cambridge, Massachusetts, United States. Oh. Box 425645 Hot Dispatch Incorporated

Claims (2)

[Claims] 1. A method for a service requester to obtain a solution for a task at a price using a service dispatch system, the service requester comprising:
A method comprising using the interactive interface to access the service dispatch system via the interactive interface, including the following steps: sending a task description to the service dispatch system; Receiving from the service dispatch system an indication that a solution from at least one of a set of potential service providers assigned to the task by the dispatch system is available; and Indicating to the service dispatch system that a price needs to be paid to one of the service providers whose solution is available. 2. A method in which a service provider uses a service dispatch system to provide a solution for a task to a service requester at a price, wherein the service provider uses an interactive interface. A method that includes the following steps, performed using an interactive interface that can access the service dispatch system: A notification from the service dispatch system that there is a task available as a solution Receiving, indicating to the service dispatch system that a solution is available, and receiving a price from the service dispatch system.