WO2001006400A2 - Method and apparatus for establishing a central exchange of market-rated information transacted by a user-driven network - Google Patents

Abstract

A centralized, user-driven process is combined with a rating system to facilitate information dissemination. An online bidding method compensates a participant who satisfies a request for information. A controller (101) receives and distributes the request to potential bidders. Before offering to answer a request, an information provider (103, 104, 105) examines the request in conjunction with a report that evaluates the requestor (102). The requestor evaluates a bid concurrent with a report concerning the information provider. The controller coordinates an exchange of information and payment upon requestor acceptance. Data reflecting the actions of both the requestor and information provider is recorded by the controller for future reference.

Description

METHOD AND APPARATUS FOR ESTABLISHING A CENTRAL

EXCHANGE OF MARKET-RATED INFORMATION TRANSACTED BY

A USER-DRIVEN NETWORK

Cross-Reference to Related Applications

This application is a United States continuation-in-part of U.S.

Provisional Patent Application serial no. 60/144,541, filed July 16, 1999,

which is hereby incorporated by reference herein in its entirety.

Field of the Invention

The present invention relates generally to an apparatus and

method for online exchange and, more particularly, to electronic transactions

of priced and/or rated information.

Background of the Invention

Information is critical to any individual or enterprise.

Accordingly, industry has developed tools to more effectively disseminate information. Automated online search engines allow Internet users to search

existing databases for matching key words. However, many such searches

produce undesirable results. Even simple searches result in users being

inundated with irrelevant data. The task of sifting through the results is

tedious, inefficient and cost-ineffective. Conversely, no data may be retrieved

where a user conducts a search of a particular or time-sensitive nature. The

absence of relevant data is often attributable to a lack of incentive to post such information.

Groups of specialized data providers are alternatively utilized

as sources of information. Collections of experts, available through services

such as news groups, discussion forum web sites and bulletin boards, entertain

queries that pertain to the specialty topic of the group. Group responses are

electronically-mailed or otherwise communicated to a requestor. Because

such groups are decentralized, however, the usefulness of a single group is

limited to the scope of its specific expertise. For instance, a person seeking

real estate advice can not reasonably expect help at a website purporting to

provide medical advice. Thus, requesters are relegated to locating different

specialty groups for divergent topics. Additionally, users have limited means

of evaluating the validity of the supposed expert information. Many group

providers have no monetary or other incentive to provide timely, concise or

accurate information, which results in undesirable responses. Related systems allow users to purchase the temporary services

of an expert consultant online. For instance, the dedicated expertise of a group

of computer engineers may be temporarily retained to establish a network for a

user. However, this strategy is not cost effective when applied to broad, lateral

market information. As above, such a format relies on niche groups and fails

to invok e conventionally structured businesses that comprise the majority of

information providers.

Other services distribute articles, audio and/or video cassettes

in an Internet auction format. The static content of these items has limited

utility for users seeking perishable information, such as job listings.

Additionally, these services operate under binding purchase constraints that

are undesirable in the context of information distribution. Such an inflexible

format would not allow requesters to evaluate sources of information before

committing to transactions. Likewise, the provider would have no way of

bargaining for the payment reliability of a requestor.

Therefore a significant need exists for an improved method of

disseminating information.

Summary of the Invention

The present invention addresses these and other problems

associated with the prior art by providing a centralized method for conducting

an online information bidding session. A market-driven process is combined with a rating system to facilitate information transactions. A request for

information is transmitted to potential information providers via a controller.

The request may include an invitation for a bilateral offer, as well as payment

and performance conditions. Upon submission of the request, a file particular

to the requestor, which may be a separate file in a computer system, a

database, a record of a database, or any other data structure, is created within

the controller for recordation of actions taken within the system.

Information providers transmit responses to the central

controller, which communicates them back to the requestor. A response

generally includes a bid for performance and may solicit a more specific

description. All actions taken by an information provider are recorded by the

central controller in order to make evaluative data available to future

requesters. The data is reviewed by subsequent requesters to characterize the

expected performance of the information provider. Evaluative data includes

provider credentials, promptness, accuracy and compensation statistics.

Likewise, information providers may access ratings data derived from a

requestor's prior transactions within the system. Such ratings reflect past

request statistics, as well as percentages of bid prices paid and promptness of

payments.

The requestor indicates acceptance of an offer to the central

controller, which communicates it to the information provider. A requestor is periodically prompted to submit evaluative data to the central controller, for

instance, after reviewing a response. Similarly, information providers are

required to enter ratings data.

One particular application deriving unique benefit from the

invention involves computer networks and systems. However, it should be

appreciated that the method of the invention is equally applicable to other

distribution systems, such as voice mail, wireless, and postal services.

The above and other objects and advantages of the present

invention shall be made apparent from the accompanying drawings and the

description thereof.

Brief Description of the Drawing

The accompanying drawings, which are incorporated in and

constitutes a part of this specification, illustrate an embodiment of the

invention and, together with a general description of the invention given

above, and the detailed description of the embodiment given below, serve to

explain the principles of the invention.

Fig. 1 is a schematic diagram of a communications network in

accordance with the principles of the present invention;

Figs. 2A and 2B is a data diagram illustrating the structure of

database tables used in accordance with principles of the present invention; Fig. 2C is a state diagram illustrating the bid status values

achieved as a user participates in the inventive system in accordance with

principles of the present invention;

Fig. 3 A is a flow chart illustrating the top-level interaction of a

user with a web site in accordance with principles of the present invention;

Tig 3B is a flow chart illustrating the interaction of a member

with a "my account" page in accordance with principles of the present

invention;

Fig. 3C is a flow chart illustrating a process for asking a

question in accordance with principles of the present invention;

Fig. 3D is a flow chart illustrating a process for login to a

system in accordance with principles of the present invention;

Fig. 3E is a flow chart illustrating a process for registering with

a system in accordance with principles of the present invention;

Fig 3F is a flow chart illustrating a process for requesting

clarification in accordance with principles of the present invention;

Fig. 3G is a flow chart illustrating a process for placing a bid in

accordance with principles of the present invention;

Fig. 3H is a flow chart illustrating a process for sending an e-

mail verification in accordance with principles of the present invention; Fig. 31 is a flow chart illustrating a process for verifying an e-

mail address using a target page in accordance with principles of the present

invention;

Fig. 3J is a flow chart illustrating a process used by a buyer in

negotiating on an answer bid in accordance with principles of the present

invention;

Fig. 3K is a flow chart illustrating a process used by a seller in

negotiating on an answer bid in accordance with principles of the present

invention;

Figs 4A, 4B, 4C and 4D are flow charts illustrating batch

processes for enforcing warning periods for unread and unrated answers in

accordance with principles of the present invention;

Figs. 5 A, 5B and 5C are flow charts illustrating batch processes

for month end payout of earnings in accordance with principles of the present

invention; and

Fig. 6 is a flow chart illustrating a batch process for alerting

users of questions of interest in accordance with principles of the present

invention.

Detailed Description of Specific Embodiments

Generally, the present invention relates to the exchange of

priced and/or rated information. In one embodiment of this invention, online bidding between a requestor and providers of information is accomplished

through an electronic network and a controller. There may be a single, central

controller or multiple decentralized controllers, in accordance with the scale of

the system and desired performance.

Referring to Fig. 1 , all participants are prompted to register

contact and payment information with the central controller 101. Unique

identifiers, such as USERID's, are assigned to each requestor, one of which is

illustrated as connected to central controller 101 via a computer system 102.

USERID's are also assigned to information providers, illustrated as

communicating with central controller 101 via telephone computer and mail

delivery mechanisms 103, 104, 105. Registration may be universally free, or

have fees associated with different types of memberships.

Generall) . a request is composed by a requester at terminal 102,

comprising an invitation to make an offer for information. Requests may be

binding or non-binding. In the embodiment described below, the requests are

non-binding, which allows the requestor to evaluate responses before

determining whether and how much to pay. This approach is believed to make

the system appealing to the broadest range of potential users. However, in an

alternative approach, providers may have the option to make payment binding,

so that a requestor, upon viewing requested information, is required to make

payment. Thus, a provider would be permitted to select a "binding" option for all requests, or only for requests in given categories. The system may also

require that a provider achieve a given level of positive ratings from prior

requestors (as discussed below), before being permitted to make binding

requests.

In another application, the system might not associate monetary

value with requests for information and replies. For example, the system may

be used within a business organization to collect a database of information. In

this case, persons that supply requested information may receive points

redeemable for vacation time, frequent flyer miles, credit toward promotion, or

another form of compensation. Alternatively, no compensation need

necessarily be provided for supplying information.

An exemplary request involves the acquisition of land. The

requestor may seek information relevant to applicable zoning laws, tax

ramifications, as well as leasing or insurance considerations. The requestor

selects a category and/or sub-category from a scroll-bar menu. Key words may

be alternatively typed in, for instance: "real estate and business property

acquisition." This selection process expedites the matching of the requestor

with providers by enabling prospective providers to perform category and/or

keyword searches, as described below. A request may also indicate the

maximum amount of compensation that a requestor will provide. Similarly,

the date and time that a request expires may be included in the request. The request may be transmitted via numerous means, including

a Worldwide-web interface, electronic mail, wireless device, voice mail,

facsimile, or postal mail. Standard legal provisions and language may be

integrated with the request to "fill in the gaps" at central controller 101. The

central controller 101 may require that the requestor provide a credit card

number or other financial account number and may take steps to evaluate the

credit or other financial status of a requestor. The central controller 101 then

assigns a unique tracking number to the request makes it available to potential

information providers. Requests may be made available globally, to providers

in certain geographic regions, or to providers meeting criteria, such as

affiliation with a particular organization, security clearance, or minimum ratings.

Potential information providers may find requests in a number

of wa> ≤. A potential pro ider may browse categories for requests, in whcih

case requests may de displayed by category or sub-category to make it easier

for potential information providers to identify relevant requests. A search may

be performed using categories and/or key words to find relevant requests. The

keyword search may be applied only to the title of the request or the entirety or

any part of its description. Other boolean logic may be applied to keyword

search or otherwise search any aspects of the request (such as whether the request is "binding"). Potential providers may regularly access the controller to search

for relevant requests, or alternatively the controller may provide an automatic

notification service based upon previously defined criteria for each potential

information provider. These criteria may include any of the criteria that can be

used in a search, including category, key word, and other criteria described

above. A provider may be provided the option to save the criteria used in a

search for future automatic notifications of requests.

Should an information provider wish to submit an answer,

solution or other information, a response is communicated to the central

controller 101. The provider may include a bid amount in conjunction with

the response. The central controller 101 then time stamps the response from

the information provider, verifies that the request has not expired, and stores

the response in a database at central controller 101. Responses from providers

are communicated to the requestor via electronic mail, web-site posting,

wireless device, facsimile or postal service, so that the requester can

asynchronous!) view the responses. Requesters and providers may engage in

asynchronous negotiation through controller 101 to arrive at a final, negotiated

price. (For negotiations and responses, embodiment using synchronous

communication, e.g., online chat or voice communication over IP or telephone

connections, or other synchronous media, may also be implemented.)

Evaluative data applicable to an information provider is also posted, if available, at central controller 101. Such data reduces costs associated with

independent evaluation procedures, and provides incentive for higher quality

responses and prompt payments. The rating system allows both the requestor

and providers to bargain for expected performance based upon historic

information.

Upon reviewing a list of responses, a requestor may select or reject responses for viewing. In either case, the requestor may rate the

information provider and may be penalized or 'locked out' of future

transactions until evaluative data is generated. If applicable, the requestor

pays the provider for the produced information. All transactions are recorded

by the central controller 101 for the benefit of future requesters and providers.

For instance, ratings data may capture what percentage of the provider's bid

price was ultimately paid by the requestor. This percentage can be used to

quantify the cumulative payment reliability, and can be used by subsequent

providers who transact with the requestor.

A system in accordance with the present invention may be

profitable to its administrator for one of a variety of purposes. First, the

administrator may receive a commission on the value exchanged between the

requester and provider. Also, the administrator may receive revenue from

advertisers, by posting ad\ ertisements visible to users as they interact with the

system. These advertisements may be targeted, e.g., specific advertisements may be used for specific requesters or providers based upon their current

request and/or a historic profile of requests or responses. Further, on a page

providing particular information content, advertisements may be targeted

based on that information content. All of these approaches enhance the value

of the advertisement by targeting a desired audience.

Other potential value can be reaped by the administrator. By its

nature, the system accumulates a database of demographic information on its

users, including email addresses, profiles (including but not necessarily limited

to. questions asked and answered), resumes, and credit card numbers or other

financial information as well as creditworthiness. This information can be

valuable to parties wishing to directly solicit the users, and can be useful in

targeting users with particular interests. Users may be provided the option to

prevent distribution of this information to others, if desired. Furthermore, this

information can be aggregated and used to perform market research, e.g., by

determining correlations between interests of the users. Another value of the

system is that by its nature it will accumulate an archive of question and

answer pairs, where at least in some cases the answers will be rated for

accuracy/usefulness. This database can be resold as an aggregate or on a

categorized basis, or may be "mined" for useful information desired by future

requestors. In such applications, a commission may be paid to the original

information provider to reflect the value subsequently derived from the provider's response. Alternatively, the agreement with participants in the

system may establish that the administrator has a license to make any or all

desired uses for questions and answers processed by the system.

Referring now to Figs. 2A through 2D, data that is stored or

used by a computer system such as that described above, for a specific

implementation of the present invention, can be explained in greater detail.

Specifically, controller 101 (Fig. 1) stores data in a number of tables in a

relational database system. The contents of these tables and the relations

betw een the tables is illustrated in Figs. 2A, 2B. 2C and 2D. Relations

between tables are indicated by lines drawn between those tables. The relation

is created by linking fields in the tables permitting other data in the table to be

joined as part of the relational database operation, as is known in the art.

Referring now to Fig. 2A, the first table of interest stored by

controller 101 is a table 200 storing member information. Members are those

persons who participate in the knowledge exchange system illustrated in Fig. 1

by either posting questions to be answered or answering questions or both.

Member table 200 stores information regarding members and identifiers for

members that can be used to link members to information in other tables. This

specific information in the member table 200 includes a unique "member ID"

which is an identifier for the member that can be used to identify the member

in other tables. In addition, table 200 stores a character value for the "user name" of the member as well as a character value for a user identifier for the

member. The "user ID" value is half of the data that must be supplied by a

member to log in to the knowledge exchange system.

As will be elaborated in greater detail below, each member is

associated with ratings relating to their performance in prior knowledge

exchange transactions. Accordingly, members table 200 includes a field

identifying a "current rating" for a member. This current rating reflects a combination of all prior feedback provided by participants in previous

transactions with the member.

Members may be referred to the knowledge exchange system

illustrated in Fig. 1 , and as a consequence of this referral, the referring member

may receive incentive rewards. To facilitate managing these incentive

rewards, the members table 200 includes fields for storing the "referral

member ID" for the member that referred a member to the knowledge

exchange system, and a "referral user ID" having the user ID for the member

that referred the member to the knowledge exchange system.

The members table 200 further includes additional statistics

regarding a member's interaction with the knowledge exchange system

including a total number of questions posted and a total number of questions

for which the member did not pay upon receiving an answer. Additional fields

can be used to provide a member with access to questions of particular interest to the member. This is done by a "category preferences field" which stores an

identification of those question categories in which a member has identified an

interest. A member may also define an interval over which that member

should be notified of new questions in that preferred categories. This interval

is identified in an "alert interval" field. Additional statistics regarding a

member include the "date registered" field which identifies the date that the

member registered with the knowledge exchange system. An "email verify

date" identifies the last date that the email address of the member was verified.

A final field "receive third party docs" indicates whether the member has

identified a willingness to be contacted by third parties for marketing

purposes.

A second table illustrated in Fig. 2A is a member resume table

202 providing additional information regarding a member useful in

determining whether that member is likely to have knowledge of value to a

particular questioner. This table includes a "member ID" field for storing the

identifier of a member, and additional fields for providing personal

information on the member that can be used to evaluate that members

qualifications. This personal information includes an "occupation" field

identifying the member's occupation, an "age" field identifying the members

age, a uniform resource locator identifying the location of a picture of the

member and a "comment" field for free-form text relating to the members qualifications or other information potentially of interest to participants in the

knowledge exchange system. The remaining fields relate to the educational

qualifications of the member and include fields level 1, level 2 and level 3 for

identifying the educational levels achieved by the member. Additional fields

area 1 . area 2 and area 2 identify an area of studies in which the member reached the corresponding levels identified in the level 1 , level 2 and level 3

fields. Finally, school 1. school 2 and school 3 fields identify the educational

institution in which the member achieved the level of degree in the identified

study area provided in the preceding fields.

Passwords, and contact information include a member's mail

and e-mail address, are stored separately in a table (not shown) indexed by

member identifier.

Continuing now in Fig. 2A, member category preferences are

stored in a normalized manner in a member resume categories table 204. This

table affiliates each member ID with a category ID for a category that member

has interest in, and provides a category details field within which the member

identifi es. in free form text, specific aspects of that category that member has

interest in. It will appreciated that table 204 will contain a record for each

category identified as of interest to each member and provide specific

information about that member's interest in the category. Because there are

multiple records potentially in table 204 for each member, table 204 can be substantial in size, and for this reason category preferences of each member

are also stored in table 200 as noted above in a non-normalized way for ready

access.

The category identifier used in the members resume table 204

relates to categories described in a categories table 206. This table includes an

unique field "category ID" for each category that is defined by the knowledge

exchange system. Each category further includes a description in a "category"

field that describes the general subject matter of the knowledge category. The

character value in the category field is used to display a description of the

category to a member when that member is browsing categories for the

purposes of posing or answering questions. Categories are arranged in a

hierarchical structure and with the exception of a root category, each category

has a parent category. The parent category for a category is identified in a

"parent category ID" field. The value in this field is an identifier for the parent

categor) that appears in the parent categories record in table 206. Further

information about a category in table 206 includes a 255 character field

"description" including a long textual description of the subject matter of the

category. This lengthy description is used when a member requests detailed

information about the content of the category as part of browsing categories

for the purposes of posing or answering questions. Categories are further

identified with images which are stored in image files and the location of the image file for a particular category is identified in an "image file" field.

Categories may also be associated with color schemes of particular colors as

identified in a "color" field of table 206. Finally, each category may be

associated with a particular advertisement of a pool of possible advertisements

that will be displayed to members as they browse categories. A particular

advertisement is identified by an "Ad ID" field in table 206.

Referring now to Fig. 2B, details of the storage of questions

and bids and transactions relating to questions can be explained. A central

table in this process is a questions table 208 seen in Fig. 2B. Within this table,

each question is represented by a record each record having a unique question

identifier "question ID". The question is associated with the member that

posed the question through a "member ID" field and includes text fields for a

title of the question and details of the question which identify in specificity the

entirety of the question being asked. If a picture is utilized or is necessary to

ask the question, the member may provide a picture URL for a file of the

picture associated with the question.

When a question is posed, the date and time that the question is

posed is stored in a "submit date time" field in the question table 208. In

possible future implementations of the knowledge exchange system, templates

may be provided for posing questions, and in this instance a "template ID"

field will be used to identify the template used to pose the questions. When a question is posed, it is associated with a category of interest which is identified

in the category ID field.

Questions are priced by the member that poses the question and

this monetary value of the question is identified in a price field of the

questions table 208. Questions are also associated with the requestor with a

"due date" which is a time by which bids must be received. The member

posing the question may also identify minimum qualifications for a member to

bid on the question and may also identify criteria for the answers such as the

specific information that must be included in an answer to be acceptable.

Questions are further associated with a subcategory identifier for the

subcategor) in which the question was posed and a status identifier that

identifies the current status of the question. Questions cycle through a

sequence of status values as those questions are posed, bid, bids are negotiated

and answers are provided as in explained in further detail below. Additional

statistics on a question in table 208 include a counter "NoWdCt" that identifies

whether the question can be withdrawn. Members are generally prevented

from withdrawing questions after a bid has been accepted on the question.

Additionally, a "bid received" field includes identifies the number of bids that

have been received on the question. A "negotiation received" field identifies

the number of bids that are negotiation on the question and a "purchase received" field identifies the number of answers that have been purchased for

the question.

As noted above, questions identified in question table 208 are

each associated with a status identifier. This status identifier references one of

a number of possible question status values that are described by status table

210. Each status in table 210 has a status identifier and an internal status and

external status description, each stored as a 25 character string. Separate fields

are provided for an internal and external status description so that information

available to the knowledge exchange system as the reason of the status can be

held within the knowledge exchange system and not delivered to members.

For example, bids that have an external status of "decline" may be declined

because the member submitting the question (hereafter occasionally referred to

as the "buyer") declined the bid or because the bid had insufficient funds

available through their credit card to purchase the bid. This distinction is a

matter of some privacy and therefore is shielded from the bidding member

(hereafter occasionally referred as the bidder) who will only see an external

status value of "decline". Details of specific status values and the procession

of the status value is provided in the following description.

As noted above, members who pose questions may identify

qualifications for possible bidders as well as criteria for acceptable answers.

The qualifications and criteria that may be established by bidders are selected from a list of possible qualifications and possible criteria. These lists of

possible qualifications and possible criteria are stored in tables 212 and 214

(Fig. 2A). Table 212 identifies bidder qualifications that may be selected by a

member upon posing a question. Each bidder qualification has a bidder

qualification ID (BQID) and text description of the bidder qualifications.

Similarly, criteria for acceptable answers may also be defined by a member

posing a question b) selecting criteria from a list of criteria. The list of criteria

is identified in a table 214. Each criterion has a criteria ID, and a character

description of the criterion. A particular category may have a subset of the

possible bidder qualifications or criteria that is applicable to that category.

When a question is posed in a particular category, only those qualifications or

criteria that are applicable to that category are displayed to the member posing

the question. The relationships between categories and qualifications and

criteria are established by tables 216 and 218.

Table 216 associates each category with those bidder

qualifications that are applicable to the category. Potentially multiple records

appear in table 216 for each category. Each record provides a category

identifier linking to the category identifiers used in the category table 206 and

a bidder qualification identifier linking to the bidder qualification identifier in

the bidder qualification table 212. Similarly, a category criteria table 218 links

a category to those criteria that are applicable to the category. Each record in table 218 provides a category identifier linking to a category in table 206 and a

criteria identifier linking to a criteria in table 214. Potentially multiple records

appear in table 21 8 in each categor)⁷.

As described in further detail below, in the process of bidding

upon questions posed by members, other members may request clarification of

the posed question prior to placing bids. This is one of several examples

where members may wish to transmit messages to other members. The facility

for transmitting such messages between members is an inbox table 220. The

knowledge exchange system may also deliver messages to members by placing

those messages into the inbox table 220.

Within the inbox table 220, each message is associated with an

identifier uniquely identifying the message. Each record in the inbox table 220

represents a message being transmitted from one member to another.

Messages relate to questions stored in the knowledge exchange system,

accordingly, each message is associated with a question identifier in a

"question ID" field. Messages are dated in a "message date" field, and each

message is associated with the member ID of the member to which the

message is directed and the member from which the message originated. In

addition, the message contains a "subject text" field identifying the subject of

the message and then an 8000 character text field for identifying the body of

the message. Messages are finally associated with a flag bit "HAS BEEN READ" indicating whether the message has been read by the intended

recipient. This information can be used to notify the member that generated

the message whether that message has been read. As noted above, one typical

use of messages is to allow members to request clarifications on questions that

have been posed in the knowledge exchange system.

After any clarification regarding a question has been provided,

members interested on bidding on a question may utilize the process described

below to generate a bid record. The bid records are stored in a bids table 222

(Fig. 2B). Bids table 222 includes all information needed to completely

identify a member's bid on a given question. Each bid is associated with a bid

identifier and additional information regarding the bid. This additional

information includes a seller identifier providing the identifier for the member

that submitted the bid (hereafter occasionally referred to as the "seller") and

question identifier connecting the bid to the question identifier of the question

stored in table 208. Once submitted, each bid is associated with a title and

typically this title indicates the reasons why the bidder should be capable of

answering the questions. The information provided by the bidder in the title

field is a character string of no more than 255 characters and should be

designed to entice the members submitting the question to believe that the

bidder can provide an accurate answer to the question. When a bid is

accepted, the bidder supplies the answer and this answer is stored in a "details" field of table 222. If the answer requires reference to a picture, the bidder will

also supply a URL for the picture in the "picture URL" field. Upon

submission, a bid is associated with an asking price stored in the "ask price"

field. The date on which the date is posted is stored in a "post date" field.

Bidders may determine whether recipients of their bids are able

to view that bidder member's resume. Members are not generally able to view

the resumes of other members, rather, members are only able to view resumes

of those members who have bid upon their questions and then only if the

bidder has permitted viewing of their resume. If the bidder has indicated that

the question submitter may view the bidder's resume, then the "resume visible"

bit in the record of table 222 will be set.

It will be noted that the knowledge exchange system can be

structured so that members are anonymous, that is, by interacting with each other through the s) stcm rather than directly via, e.g., email, members can e

allowed to minimize the amount of information available about them through

the system. For maximum anonymity, the system can be structured so that

members are not given even user identifiers or email addresses of other

members. Members, of course, can provide this information in a resume, or as

part of a request or as part of a bid, at the member's option. Selective

anonymity of this kind may be viewed as an advantage of the knowledge

exchange system. Bids are associated with status identifiers and the status

identifiers progress through a number of values as the bidding, negotiating,

answ er delivery and review process proceeds as detailed below with reference

to Fig. 2C. The status ID is stored in a field in table 222 for the bid.

As will be described in further detail below, bids submitted by

members may be negotiated to a new bid price. This negotiation process is

reflected by a "last negotiation price" field indicating the most recent offer by

the question presenter, the "last negotiation date" field identifying the date that

this offer w as provided, and a "last negotiation reason" field providing the text

supplied by the question presenter for explaining the rationale for the last

negotiated price offer.

As is explained in further detail below, once answers are

provided in response to acceptance of a bid, the question presenter rates the

provided answer. The rating is stored in a rating field in the bid table 222. If

the buyer desires to provide comments on the rating provided, these are

provided in the "buyer comment" field. If the bidder, also known as the seller,

wishes to provide a responsive comments to the buyers comment, this is

placed in the "seller comment" field. Ratings may take a number of forms,

including numerical values, typed text values or free form text values. In the

illustrated implementation, ratings are an integer number between zero and

four where zero represents an answer that had no value to the purchaser and four represents an answer that has best possible value. The comment fields are ided in the bid lecords in table 222 to permit a buying member an

opportunity to explain a numeric rating, and to permit a selling member an

opportunity to respond to those comments. A last field in a bid record in table

222 is a "status effective date" field which identifies the date on which the bid

achieved its current status This information is used, as noted below, to

prov ide warnings to bu\ers that have not provided feedback ratings within a

seven-day rating period that is discussed in further detail below.

Referring now again to Fig. 2A, the final table involved in

management of the knowledge exchange system is a bid negotiation table 224.

As discussed in detail below, a potential buyer that posed a question may

initiate negotiation over a bid presenter by a potential seller. This negotiation

process proceeds through the exchange of messages between the prospective

buyer and prospective seller. Each of these messages is represented by a

record in the bid negotiation table 224. Each record has a bid negotiation

identifier and then a sequence of fields providing details of the content of the

message forming part of the bid negotiation. A "poster ID" field stores a

member identifier for the member that produced the message represented by

the bid negotiation record. A "question ID" field identifies the question to

which the message relates. A "bid ID" field identifies the bid record in table

222 to which the message relates "Buyer ID" and "seller ID" fields in the bid negotiation record identify the members who are prospective buyer and seller

for the bid under negotiation. The content of a message is provided by a

"price" field which identifies a price being offered by the prospective buyer or

seller, and text explaining the rationale behind the proposed price. As an example, a prospective buyer may initiate negotiation

and specify a price below that bid by the seller, and provide as a reason for the

lowered price, that the resume of the seller does not identify an expertise

necessarily associated with the subject matter of the question. In responsive

message produced b) the prospective seller, the seller may set a higher price

and provide a reason indicating an expertise of the seller not reflected in that

sellers resume. Λ final field in each bid negotiation lecord is a "negotiation

date" field, dating the message represented by the record. Typically, a

negotiation will involve a number of messages assembled over a span of time

and will be presented to each of the negotiating parties as a sequence of lines

of text on a computer display.

Referring now to Fig. 2C, an explanation can be provided for

the sequence of bid status values that a bid record in table 222 will have. Bids

proceed through a number bid status values as the bid is initially entered,

negotiated, accepted, confirmed, the answer is provided and then the answer is

reviewed. In a first step when a prospective seller submits a bid, the bid

record is created and marked with a status identifier corresponding to a value

of "initial bid" (state 230). When the prospective buyer accepts a bid that is in

its "initial bid" state 230, then the bid is marked "bid accepted" (state 232).

Subsequent to this, an answer will be provided and feedback on that answer

w ill be provided.

Often, a buyer will wish to negotiate the price for the

information begin requested. In this situation, the buyer will initiate a

negotiation through a process described in further detail below and the bid

status value will change to a value of "negotiate" (state 234). The prospective

seller will be notified of the offer to negotiate and will then respond with a

new bid which may or may not be of a lower price of the previous bid. At this

point, the bid status value proceeds to "revised bid" (state 236). Thereafter,

the buyer may accept the seller's new proposed value in which case the bid

status value returns to state 232, or the buyer may reject that value and propose

a alternative value in which case the bid status value will be altered to a value

"negotiate" (state 238). At this point, the seller may submit an adjusted bid

identifying a new value that the seller is willing to accept for providing the

requested information. If this occurs, then the bid status is returned to a value

"revise bid^'* in state 236. Alternatively, the seller may withdraw the bid, in

response to failure to reach an acceptable negotiation, in which case the bid status value is changed to a value of "bid withdrawn" (state 240). Once the

bid is withdrawn in state 240, further processing of the bid is terminated.

It will be noted that in either in state 234 or state 238, the seller

ma) accept the counter offer provided by the buyer. In either of these

situations, the bid status value is returned to the value "revised bid" in state

236. Thus, the seller must in effect submit a new offer matching the proposal

from the buyer, returning the bid status value to state 236, after which the

buyer may accept the new proposal from the seller to transition to state 232.

Once a bid has been accepted in state 232, the acceptance of the

bid is communicated to the seller and the seller must confirm the acceptance,

causing the bid status value to change to a value of "bid confirmed" (state

242). After confirming the acceptance of the bid, the seller then provides the requested answer, at which time the bid status is changed to "answer

delivered" in state 244.

After an answer has been provided on a confirmed bid, the

buyer is required to view the answer and provide a review for the answer. The

first time the answer is viewed by the buyer, the bid status value is changed to

"under review" (step 246). At this point or at some subsequent time, the buyer

a) then provide a rating value for the answer for that was supplied. Provided

the buyer gives a rating of greater than zero to the supplied answer, upon

supplying the rating value the bid status is changed to a value of "purchased" (state 248). At this point, the buyer's credit card will be charged for the value

of the accepted bid. If the buyer provides a rating value of zero for the

supplied answer, or if the credit card charge fails, then the bid status value is

changed to a value "declined" in state 250 indicating that the answer was

unacceptable to the buyer. In this circumstance, the buyers credit card is not

charged for the value of the bid that was accepted. After a bid reaches a status

value of "purchased" or "declined", no further processing is performed on the

bid.

As will be explained in further detail below, buyers are required

to

iew supplied answers within a seven day period. Buyers are provided

with regular notifications of the unviewed answers on accepted bids. Once an

answer has been viewed, the buyer is provided a seven day period to provide a

rating on the answer. If no rating is provided within this seven day period,

then the buyers credit card is charged for the value of the bid without regard to

an the absence of a rating from the buyer. Here again, regular warnings are

provided to the buyer of the need to provide a rating value for the received answer within this seven day period.

Referring now to Fig. 3A, the process followed by a member of

the knowledge exchange system in interacting with the controller 101 of Fig. 1

can be explained in greater detail. Initially, the member visits the Internet

home page of the knowledge exchange system, in the illustrated case at the URL KnowToday.com. From this home page, the member may select a

variety of options for knowledge exchange using controller 101. The first

option is to initiate an ask a question process 304 through which the member

may pose questions to be answered by others. Alternatively, the member may

search for questions posed by others that the member may bid to answer (step

306). In this case the member requests questions utilizing categories or

keyword searches or other search techniques, to produce a list of questions of

potential interest. The member may then in step 308 request details for a

particular question identified through the search and browse process. The

details requested may include the buyer's history (step 310) for the buyer that

posed the question. The buyer's history may indicate, for example, the number

of questions, the kinds of questions, and the ratings given by the buyer posing

the question. The second alternative is for the member to request clarification

in the question in step 312. The member may then exchange one of a number

of messages with the perspective buyer that posed the question to clarify the

question before a bid is provided. Finally, the member may place the bid in

step 314 using a place a bid process described in further detail below.

Once a member has asked a question or has placed a bid on a

question, or has requested clarification of a question, that member's activity

would be available for viewing at the member's "my account" page. From the home page in step 300, the member may request to view this "my account" page in step 318. When this request is received, controller 101 of Fig. 1 will

query the members computer system to determine whether the member has a

"cookie" indicating that the member has logged in and providing the members

user identifier in the knowledge exchange system. In step 318, therefore, it is

determined whether the user is logged in. and if not, in step 320 it is

determined whether the user is already registered with the knowledge

exchange. If the user is registered with the knowledge exchange system, then

in step 322 a log-in process is performed so that the user may log into the

knowledge exchange system. If the user is not registered with the knowledge

exchange system, then in step 324 the registration process is performed so that

the user may register with the knowledge exchange system and can

subsequently log-in.

As user that is not previously logged-in and requests to proceed

to "my account" page, will also directly invoke the log-in process in step 326.

Furthermore, a user viewing the knowledge exchange system home page that

wishes to register, may directly invoke the registration process in step 328. In

any of these situations, after successfully logging in and/or registering and

logging in, the user is delivered to the "my account" page in step 330.

Referring now to Fig. 3B, processing at the "my account" 330

can be further detailed. The "my account" page provides a member with a

variety of options for maintaining the member's account with the knowledge exchange system, or following-up on questions or answers being processed

through the knowledge exchange system.

The first option that the member may invoke is to view a

summary of transactions and financial information relating to that member's

activities and the knowledge exchange system (step 332). Alternatively, the

member may perform account maintenance in step 334, altering the members

personal information such as their resume information, or other personal

information. This process also permits a user to change their current e-mail

address in step 336. Doing so triggers an email verification process in step

338 to verify the new email address, as described in further detail below.

At the "my account" page 330, a member may view current

questions posed by that member by requesting a "my questions" page 340. At

the "my questions" page 342, the member may edit an existing question in step

344 or may withdraw a question in step 346, from a view bids on a question in

step 348. If the member chooses to view bids on a question then the member

must select a particular bid in step 350 and select an action to take on that bid.

As a first option, the member may view the bidders feedback or resume if

permitted in step 352. This information may be useful in deciding whether to

accept the bid. If the member is satisfied and the bid is acceptable, the

member may accept the bid in step 354, in which case the bid status for the bid

is changed to "purchased" in step 355. Subsequently, an automatic email is generated and sent to the bidder announcing acceptance of the bid, to prompt

the bidder to confirm the acceptance of the bid and provide an answer to the

question.

As noted above, a member may be intrigued by a bid but may

wish to negotiate the price of the bid. In this situation, the member may

initiate a buyer negotiation process in step 356, as elaborated in further detail

below . Alternatively, a member may identify a bid that has had an answer

delivered subsequent to its acceptance. To view this answer, the member will

click on an "answer delivered" icon in step 358, in response to which the

answer will displayed to the member. At the same time in step 360 the bid

status for the bid will be changed to "under review" as described above. The

buyer is then required to provide a feedback rating on the provided answer. The buyer may immediately provide this feedback or may provide this

feedback at any time within the following seven days. Thus, when viewing

bids on a particular question in step 350, a member may identify a bid that is

"under review" and select this bid in step 366 in order to provide feedback that

had not yet been provided. Subsequently in step 368 the buyer provides

feedback rating on the answer received of the bid. At this point, the buyer's

credit card is charged if the feedback rating is greater than 0. If the buyer

provides a feedback rating of 0, then the buyer's credit card is not charged. At the "my account" page, the member who has bid on possible

answers to questions may request to view a "my answers" page in step 368,

and be delivered to the "my answers" page 370. The "my answers" page will

display all answers that had been bid by the member on others' questions.

Bids that have been acted upon by the other member may be awaiting action.

Specifically, if the other member has requested negotiation on a bid, the bid

will be identified as a status of "negotiate". In this case, the member may click

in step 372 on the negotiate bid to invoke the seller's negotiation process (step

374). This process is described in further detail below. A bid may also have

been accepted by the buyer, in which case this acceptance should be

confirmed. To do so, the member clicks on the bid marks as "accepted" in

step 376. Thereafter in step 378 the member is prompted to confirm

acceptance of the bid, and upon acceptance in step 380 and email verification process described below is performed to verify the email address of the

member. Subsequently in step 382 the bid status for the bid is changed to a

status of "confirmed", and an automatic email is sent to the buyer announcing

confirmation. Thereafter the bidder will submit an answer to the question

posed by the buyer. This may be done immediately after step 382 and step

384. Alternatively, the bidder may later provide the answer. This may be

done by identifying the bid that is marked as "confirmed" then selecting this

bid in step 388. In either case, in step 384, the bidder submits the answer to the posed question. After this is done, the status of the bid is changed to

"answered", and the buyer is notified that the answer has been delivered.

The final action that may be taken at the " my account" page

330 is to view a member's inbox by invoking this option in step 390. From the

member's inbox page (step 392), the member may scan messages received at

the member's inbox and respond to those messages. Specifically in step 394

the member may view clarifications received from buyers upon request for

clarification delivered in step 312 (Fig. 3 A). As an alternative, the buyer may

reply to a clarification request issued by a prospective bidder, by generating

this reply in step 396 and storing the reply in the prospective bidder's inbox in

step 398.

Referring now to Fig. 3C-1 , the process for asking a question in

step 304 can be elaborated. Initiating this process, the buyer clicks on an ask a

question option in step 400. In response, a form is presented to the perspective

buyer requesting the buyer fill out the specifics of the question including the

title, details, picture URL category, price and due date in step 402. The buyer

then clicks on the continue button in step 404. Subsequently, a series of tasks

are conducted to ensure that the supplied information is valid. These tests

include determining that the question title is not null (step 406), determining

that the question details are not null (step 408), determining that a category for

the question has been selected (step 410). determining that the price has been identified and is greater than $3.00 and less than a $1,000 (step 412) and

determining that the identified due date is after today (step 414). If any of

these tests fail, then in step 416 a proper error message is generated and displayed on the question form and the buyer is returned to step 402 to provide

new information. If all of these tests are successfully completed, then the

question has been successfully submitted and processing continues to step 418

where further specifics regarding the question are obtained. In a first step of

this process, the buyer is provided a form to fill out more detailed specifics of

the question, such as a sub-category, answer criteria and seller qualifications

(step 420). At this point the buyer may wish to go back and edit the question

itself, in which case the buyer will click a back button in step 424 and be

returned to step 426 in which previously in-putt question details are used to

repopulate the form displayed in step 402, and then this form is redisplayed. If

the buyer does not wish to go back to edit the question, then in step 426 the

buyer clicks a continue button after providing the desired specifics on the

question.

After thus submitting the question, in step 428 it is determined

whether a sub-category has been selected. If no sub-category has been

selected then in step 430 an error message is generated and displayed and then

in step 420 the details form is redisplayed so that the user may select a sub-

category. If the user has passed the test of 428, then the question has been successfully submitted and in step 430 the buyer previews the submitted

details on the question on a preview page. If the buyer wishes to edit the

question details the buyer may click on the back button in step 432, in which

case previously provided question details are used in step 434 to repopulate

the form displayed in step 420, and then this form is displayed again in step

420.

If the buyer has approved the question at the preview page in

step 430, the buyer will confirm the buyer's desire to ask this question, and

processing will continue to step 436. In step 436 it is determined whether the

buyer is logged in to the information exchange system. If not, then in step 438

it is determined whether the buyer is registered in the information exchange

system based upon whether the buyer provides a valid member identifier or

alternatively indicates the registration would be needed. If the buyer is already

registered then in step 440 a log-in process is performed to log the member

into the system. If the buyer is not registered with the knowledge exchange

system, then in step 442 a registration process is initiated to cause the buyer to

be registered with the knowledge exchange system.

After step 436, 440 or 442, the buyer will have successfully

logged-in to the knowledge exchange system. At this point in step 444 it is

determined whether the buyer has credit card information saved in the

knowledge exchange system. If not, the buyer is requested to provide a valid credit card and this credit card is validated through a banking network in step

446. If the buyer provides or has previously provided a validated credit card

number, then after step 444 or 446 the buyer's question is posted by storing an

appropriate record in the question table 208.

Referring to now to Fig. 3D, the log-in process referenced

above can be explained. This process is initiated whenever a user who has not

logged-in to the knowledge exchange system, chooses to perform an action

that requires log-in, including requesting to log-in, requesting to view an

account, my account page, attempting to post a question, attempting to place a

bid on a question, requesting clarification of a question or accessing any other

page that an anonymous user is not permitted to view. In the first step 452 the

user is requested to provide a user name, i.e. member ID, and a password.

Then in step 454 the user clicks the log-in button to request the log-in to the

valid exchange system. If in step 456 the provided user and password

combination exist within the knowledge exchange system, then the member

has successfully logged-in and in step 458 the user is returned to the next step

after the log-in was required. If however, an invalid name or password is

supplied, then in step 460 an error message is generated and displayed on the

log-in form, and the log-in page is redisplayed in step 452.

Referring now to Fig. 3E a registration process referenced in

the proceeding discussion can be explained. This process is initiated when the user in step 460 clicks on a join now or register button on a page requiring

registration to continue actions in the knowledge exchange system. In step

462, the user is presented with a registration form requesting various

information needed for a member record in table 200. This information

includes a first and last name, valid email address, a desired user name and

password, a confirmation of the desired password, birth date, a password

question and a password answer that can be used to validate the user's identity

in the absence of the password, and a member ID for a referring member.

After filling out the registration form in step 462, in step 464 the user clicks on

a submit button to submit the identified information for registration.

Thereafter, a series of tests are performed to validate the information provided

for registration. These steps include determining whether the first name and

last name fields are non-null, and that the email address has a top level domain

suffix that is valid, i.e. is either .com, .net, .org, .cc, .uk or any of the other

valid top level domain names. Further tests include determining whether the

user name is null and whether it is at least 4 characters and no more than 12

characters, determining that the password is not null and is at least six

characters and no more than 12 characters, determining that the confirmed

password and the password are exact matches, determining that the user has

supplied a birth date and is eighteen years of age or older, determining whether

the user has supplied a password question and determining whether the user has supplied a password answer. If any of these tests fail, then processing

continues to step 484 in which an error message is generated to be displayed

on the registration form, and then the registration form is redisplayed in step

462. The final test relates to the existence of an accurate referral. In a first

step 488 it is determined whether the user has identified a referrer's member

ID. If so then in step 490 it is determined whether the member ID that was

provided is valid. If the provided member ID is invalid then processing

returns to step 484 generating the appropriate error message. If no referring

member ID is provided, or if a valid ID is provided, then the user has

successfully registered and in step 492 the user is presented with a successful

registration page. Subsequent to this step, an email is automatically sent to the

identified email address in step 494 welcoming the user to the knowledge

exchange system. At the same time, an email verification process is triggered

in step 496. Also, in step 498 the user is returned to the next step after

registration is required or requested.

Referring now to Fig. 3F, a process for requesting clarification

of a question can be explained in further detail. This process is initiated in

step 312 when the user requests clarification on a questions detail page. In

step 500 the user is presented a form in which the user outlines a clarification

request message to be sent to the buyer who posed the question. In step 502,

the user clicks a submit button to submit this clarification request to the prospective buyer. In step 504 it is determined whether the message on the

form is empty. If so, then in step 506, an error message is displayed to the

user, and the user is returned into step 400. If the message is not empty, then

in step 508 the message is delivered to the perspective buyer's inbox.

Referring now to Fig. 3G, a process for placing a bid can be

explained in further detail. This process is initiated in step 314 when the seller

clicks a "place a bid" button on a question details page. Initially, in step 510 it

is determined whether the prospective seller that wishes to place the bid is

currently logged into the knowledge exchange system. If not, if the seller is

registered in the knowledge exchange system, the system will initiate the log¬

in process described above with reference to Fig. 3B in step 514. If the seller

is not yet registered, the seller will request registration, initiating the

registration process illustrated above with reference to Fig. 3E in step 516.

Thereafter, or immediately after step 510 if the seller is already logged in, the

seller is presented with a form in which to provide details of the bid. In this

form the seller enters a title for the bid, which typically would include a

qualifications statement, and a bid price (step 518). After providing this

information, in step 520 the user clicks a "place bid" button on the form.

A series of tests are performed upon a suggested bid to

determine that it is valid. These tests include whether there is a qualifications

statement (step 522), whether there is a bid price, whether the bid price is less than a $ 1.000.00, greater than $3.00 or equal to 0 (steps 524, 526 and 528),

and whether the user is placing a bid on the user's own question (step 530). If

an) of these tests fail, then in step 532 an appropriate error message is

generated to be displayed on the placed bid form, and the form is redisplayed

in step 518. If the information provided by the prospective seller passes these

tests, then a bid has successfully been submitted then in step 534 the bid is

stored in the bid table 222 (Fig. 2B). It is discussed above, the bid status is

initially set to evaluate a "initial bid" in step 536. At the same time an

automated email is generated and sent to the buyer of the question announcing

that a bid has been placed (step 538).

Referring now to Fig. 3H, the email verification process

discussed above can be elaborated. This process is triggered in step 338 and

step 496 under circumstances that require verification of an email address

provided by a member. In a first step 548 it is determined whether the email

address to be verified has already been verified. This may occur if the

knowledge exchange system requests an email verification under

circumstances where an email address has already been verified. Whether an

email address has been verified can be determined by consulting with the

email verification table 226 illustrated in Fig. 2A, which stores a record for

each unv erified email addresses. If the email address in question has already

been verified, then the email verification process is completed in step 542 because the address has been verified. If, however, the email address has not

yet been verified, then a unique identifier for the email address is generated.

The identifier, along with the members identifier, and the date and time, are

stored in the email verification table 226 of Fig. 2A for use by the

acknowledgment process. Subsequently in step 546, a verification email with

a link to an email verification page, is sent to the email address. Subsequently

in step 548, the message is posted in the user's inbox indicating that an email address verification request has been sent.

Once an email verification has been requested, the user

receiving the verification email transmitted in step 546 may use the link in that

mail to return to a email verification page. Referring to Fig. 31, once the user

takes the step 550, the unique identifier in the email address being verified are

returned to the knowledge exchange system. Thereafter in step 552 it is

determined whether the email address and unique ID are in the list of

verification requests stored in table 226. If not then the verification has failed

and the appropriate message is delivered to the user in step 554. Alternatively,

if the email address and unique ID are in the table 226, and in step 556 the

user is asked to log-in, and after the user has logged-in, the email address is

considered verified. The date on which it was verified is recorded and

applicable requests are removed from the verification requests list. A

confirmation page is displayed in step 558. Reterπng now to Fig. 3J, the buyer negotiation process is

performed when the buyer identifies the bid that they wish to negotiate in step

356. Once identifying a bid to negotiate, in step 560 the buyer is presented

with a form in which the buyer provides negotiation details, specifically a new

suggested price and a reason for the new suggested price. To submit this information, the buyer clicks a "submit" button in step 562. In step 564 it is

determined whether the new price is not null greater or equal to $3.00 and less

than a $1.000.00. If any of these tests fails, then in step 566 an appropriate

error message is directed to the buyer and the buyer returns to step 560 to fill

out new negotiation details. If the buyer does not provide a reason in step 568,

the buyer is also directed to step 566 where an error message is displayed. If

the buyer has accurately submitted negotiations, then in step 570 the buyer's

offer for negotiation is stored and thereby delivered to the seller. At the same

time an automated e-mail is delivered to the seller announcing the offer for

negotiation, and in step 574 the bid status for the bid is set to "negotiate" as

discussed above.

Referring now to Fig. 3K, the seller's negotiation process can

be further explained. This process is initiated in step 374 when the seller

receives an offer for negotiation from a buyer and chooses to continue with

negotiation. In the first step 580 the seller is presented with a form in which

the seller may provide details on the negotiation. These details include a suggested new price, and a reason justifying this new price. If the seller

wishes to withdraw the bid then in step 582 the user will select an option to

withdraw the bid in which case the seller is directed to a response page

confirming withdraw of the bid, and in step 584 the bid status value for the bid

is converted to "bid withdrawn", as described above. If the seller doesn't wish

to withdraw the bid, in step 586 the seller may choose to accept the buyer's

suggested term or choose to renegotiate. In another case, a sequence of tests

are performed to verify that the accepted or proposed renegotiated bid is valid.

In step 588 it is determined that the new bid price is not null or greater than

$ 1.000.00. in step 590 it is determined that the new bid price is greater than or

equal to $3.00 or equal to $0.00 (step 592), and in step 594 it is verified that

the reason for the bid is not null. If any of these tests fails, then in step 596 an

appropriate error message is generated and the seller is returned to step 580 to

fill out additional negotiation details. If all of the tests of steps 588-594 are

successfully passed, then the revised bid is submitted for the buyer's review in

step 596. The bid status is set to a value of "revised bid" in step 598, then the

automated email is set to the buyer in step 600.

Referring now to Fig. 4A, the batch process for generating

warnings regarding unread answers can be described. In step 610, this batch

process is initiated. This step is taken each day, and identifies every question

having bids, where the bid status on a bid is "answer delivered", and it has been more but less than seven days since the answer has been delivered. For

each of these questions, in step 612 an automated email is delivered to the buyer requesting that the buyer view and rate the answer provided. In step 614

it is determined whether all bids have been processed, and if not, then for the

next bid. another automated email is generated in step 612. After all bids have

been processed, the log is generated and e-mailed to an administrator of the

knowledge exchange system in step 616.

Referring to Fig. 4B. a similar batch process is performed for

answers that have not been read in seven days. Each day, in step 620, this

batch process initiates, by identifying all questions that have had an answer

delivered for seven days. For each of these questions, in step 622, the seller is

provided with no rating received and the buyer is credited with a no pay rating

for the bid. and the bid status is changed to a value of "declined." After these

steps, an email notification is sent in step 624 informing the seller that the

answer is declined. In step 626, it is determined whether all bids in this status

have been processed and if not, additional bids are processed in steps 622 and

624 After all bids have been processed, a log of the processed bids is supplied to the knowledge exchange administrator in step 628.

Referring now to Fig. 4C, the batch process is also performed

with respect to answers that have been delivered but have not been rated. In

step 630, this batch process is initiated by identifying all answers that have a status oϊ "under review" and which have had this status for at least three and

less than seven days. For each of these bids, in step 632, an automated email

is sent reminding the buyer to rate the answer provided and warning that the

credit card charge will be made if no rating is provided by the end of the

seven-day period. Thereafter, in step 634 it is determined whether all bids

have been processed and if not, then processing returns to step 632 to send additional e-mails for other bids in the same status. After all bids have been

processed in step 636, a log of bids processed in this manner is sent to the

administrator of the knowledge exchange system.

Referring now to Fig. 4D, a similar batch process is performed

for questions that have been answered but the answers have not been rated for

at least seven days. In the first step 640, those questions which have had a

status of "under review" for at least seven days are identified. Then, for each

bid in step 642 the buyer's account balance or credit card are charged for the

value of the bid. In step 644, it is determined whether sufficient funds were

found in the account balance of the buyer or the credit card charge transaction

succeeded. If a credit card transaction cannot be consummated, and

insufficient funds were available in the buyer's account, then in step 646, a

seller rating of no rating received is applied to the bid, and the bid status is

changed to a value which externally appears as "declined" and internally

appears as "NSF". The buyer is also credited with a no-pay and the failure of the transaction is logged. An email notification is then sent to the seller in step

638 indicating that the seller's answer was declined. If there are sufficient

funds in the buyer's account or a successful credit card transaction has been

consummated, then in step 650 seller is provided with no rating for the

answer, but in step 652 the bid status value for the bid is changed to

"purchased." In step 654 an email notification is sent to the seller announcing

that the seller's answer was purchased. After the foregoing steps, in step 656,

it is determined whether all bids have been processed, and if not, processing returns to step 642 to process another bid identified in step 640. After all bids

have been processed, in step 658 a log of all processed bids is provided to the administrator of the knowledge exchange system.

Referring to Fig. 5A, the monthly batch process for paying

earnings to participants in the knowledge exchange system can be described.

In Fig. 5A a process is performed to attempt to verify email addresses for those

members whose email addresses have as yet not been verified. In step 660, a

list is generated of all members who have earnings greater than or equal to $25, subtracting any pending questions that will deplete these earnings and

whose email addresses have not been verified. In step 662, a notice is posted

in the inbox for each of these members that they have not been paid because

their email address has not yet been verified. Referring to Fig. 5B, the process for providing payments to

those users that have verified email addresses can be explained. In step 664 a

list is collected of all users who have earnings greater than or equal to $25

subtracting the cost of any pending questions, and whose email addresses have

been verified. In step 666, if a user's accumulated earnings is greater than or

equal to a predetermined value, such as $600, then the user is skipped during

this batch process. If the user's accumulated earnings are less than $600, then

the funds in the user's account are withdrawn and a payout transaction is

generated to be sent to a payment service, such as the Internet payment service

paypal.com (Step 668). Thereafter, in step 670, a report is generated to show

the amounts paid and the total number of users paid.

Users who have an accumulated earnings greater than or equal

to $600 in step 666 are paid separately to subdivide those members from other members receiving relatively small amounts of earnings. These members may be paid through electronic funds transfer, checks, or other conventional

payment means.

Referring now to Fig. 5C. the process attempting email

verification of those users who do not have a verified email address can be

explained. Specifically, in step 672, a list is generated of those users that have

earnings greater than or equal to $25 subtracting any pending questions that do

not have a currently verified email address. For each of these members, in step 674. the email verification process of Fig 3H is performed. At the same

time, m step 676, a lemindei is posted in the member's inbox

Referring now to Fig 6, a batch process for alerting members

of questions of interest can be described In this process in step 680, all

members that have requested notifications are evaluated to determine whether there aie any new questions of interest to those members. In step 682, it is

determined whether new questions have been posted within the identified notification frequency, and if so, in step 684, the posted questions are

evaluated to deteimine if any are in the categories identified of interest by any

of the members If the conditions in step 682 and 684 are satisfied, then in

step 686 an email is sent to the user notifying the user that there are new

questions of interest In step 688. it is determined whether all users have been

processed, and if not, processing returns to step 682 to process another user.

After all users have been processed, in step 690, a log of all activities is

provided to the administrator of the knowledge exchange system.

While the present invention has been illustrated by a

descnption of vanous embodiments, and while these embodiments have been

descπbed in consideiable detail, it is not the intention of the applicants to

restrict oi in any way limit the scope of the appended claims to such detail.

Additional advantages and modifications will readily appear to those skilled in

the ait 1 he invention in its bioader aspects is therefore not limited to the specific details, representative apparatus and method, and illustrative example

sho n and described. Accordingly, departures may be made from such details

without departing from the spirit or scope of applicant's general inventive concept.

What is claimed is:

Claims

Claims

1. A method for conducting an information bidding session,

comprising: receiving a request for information at a controller;

communicating said request to a plurality of information providers; receiving a response from one said information provider at said

central controller, said response comprising an offer to provide the requested

information upon acceptance of said offer.

2. The method of claim 1 wherein said communicating is by

means of one or more of Internet, wireless, postal, and telephone

communication media.

3. The method of claim 1, further comprising communicating said response from the central controller to a requestor.

4. The method of claim 3 wherein said communicating is by

means of one or more of Internet, wireless, postal, and telephone communication media.

5. The method of claim 1 , wherein said response includes a bid

for providing the requested information.

6. The method of claim 1 further comprising a plurality of controllers, one or more of said controllers receiving said response.

7. The method of claim 1, further comprising registering financial and contact information of the requestor and the information

provider.

8. The method of claim 7, wherein said registering includes

assigning unique identifiers to the requestor and the information provider.

9. The method of claim 1. further comprising assigning distinct

tracking numbers to the request and to the response.

10. The method of claim 1, further comprising creating and maintaining evaluative data relating to requests.

1 1. The method of claim 10, wherein said evaluative data

reflects one or more of requested compensation, qualifications, promptness,

accuracy, requestor satisfaction and requestor creditworthiness.

12. The method of claim 10, further comprising the requestor submitting evaluative data to the central controller.

13. The method of claim 10, further comprising communicating said evaluative data to the requestor.

14. The method of claim 10 wherein said controller creates said

evaluative data.

15. The method of claim 1, further comprising creating and maintaining ratings data particular to a requestor.

16. The method of claim 15, wherein said ratings data includes

the requestor^'s file history of requested information categories, percentages of bid price paid and promptness of payment.

17. The method of claim 1, further comprising creating and

maintaining ratings data particular to a request.

18. The method of claim 1 , further comprising creating and

maintaining ratings data particular to a response to a request.

19. The method of claim 1 , further comprising creating and maintaining ratings data particular to an information provider.

20. The method of claim 1, including the information provider

submitting ratings data to the central controller.

21. The method of claim 20, further comprising

communicating said ratings data to the information provider.

22. The method of claim 1 , further comprising automatically notifying a potential information provider of a request.

23. The method of claim 22, wherein said potential information

provider is notified of requests associated with a particular category.

24. The method of claim 23, wherein said potential information provider is notified of requests associated with a particular key word.

25. The method of claim 22 wherein said potential information provider is notified of requests based upon comparison of said request to a

profile of said information provider.

26. The method of claim 25 wherein said profile comprises one or more of demographic information, prior information provided or requests made by the information provider, and ratings of prior information provided by the information provider.

27. The method of claim 22 wherein said potential information

provider is notified of requests based upon comparison of a profile of said

information provider and a profile of a requestor generating said request.

28. The method of claim 27 wherein said profiles comprise one

or more of demographic information, prior information provided or requests made by the information provider, ratings of prior information provided by the

information provider, and satisfaction of a requestor and creditworthiness of a requestor.

29. The method of claim 22, wherein said potential information provider is notified of requests associated with a particular key word.

30. The method of claim 1 applied to accumulating a database of information, further comprising accumulating one or more of demographic

information on requestors and information providers, and requests and responses provided thereby.

31. The method of claim 1 applied to advertising to users,

further comprising displaying advertisements to said users as part of interacting with the controller.

32. The method of claim 31 wherein advertisements are selected based upon interactions of the user with the controller.

33. The method of claim 1 further comprising selecting an

information provider to whom said request is to be communicated based upon

one or more of: geographic location, affiliations with an organization, security

clearance, or ratings of prior information provided.

34. The method of claim 1 wherein said method utilizes a

synchronous communication media for one or more of receiving said request,

communicating said request, or receiving said response.

35. The method of claim 1 wherein said method utilizes an asynchronous communication media for one or more of receiving said request,

communicating said request, or receiving said response.

36. A network for conducting an online bidding session,

comprising a central controller operable to receive a request for information

and a bid: a computer operable to send a request for information said

central controller;

a plurality of computers operable to send a bid in response to said request to said central controller. communication lines operable to connect the central controller to the computers.