WO2001035272A2

WO2001035272A2 - Apparatus and method for selective routing of users to experts over a network of computers

Info

Publication number: WO2001035272A2
Application number: PCT/US2000/030314
Authority: WO
Inventors: G. Dewey Gaedcke; Carl N. Samos
Original assignee: Knowitall, Inc.
Priority date: 1999-11-05
Filing date: 2000-11-03
Publication date: 2001-05-17
Also published as: AU1459401A; WO2001035272A3

Abstract

A method and system for online, real-time interface of users and appropriate experts through a network of computers such as the Internet is disclosed. Users seeking a specific type of help are presented with a list of available experts. The user may then browse the information presented and select an expert. When a selection has occurred, the user and expert are connected, real-time, so that the expert may resolve the question or need of the user. Payment may be administered by the system, and obtained from either the user or an entity which has engaged the expert or provider of the system.

Description

APPARATUS AND METHOD FOR SELECTIVE ROUTING OF USERS TO EXPERTS OVER A NETWORK OF COMPUTERS

Copyright Notice A portion of the disclosure of this patent document contains mateπal which is subject to copyπght protection. The protection owner has no objection to the facsimile reproduction by anyone of the patent document, or of the patent disclosure as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyrights whatsoever.

Priority

This application claims pnoπty based upon United States Provisional Application Seπal No. 60/163,900, filed November 5, 2000 and entitled "Apparatus and Method for Selective Routing of Users to Experts over a Network of Computers."

I. Field of the Invention

The present invention relates generally to an apparatus and method for connecting users to expert service providers through a network of computers such as the Internet, and more particularly to routing computer users seeking expert help to experts in one or more topic areas m an online setting.

II. Related Art

Presently, people attempting to locate expert help for a particular request are presented with a host of difficulties Foremost among these are locating an appropπate expert's contact information, obtaining the help of the expert in a timely fashion, learning about the expert's credentials and track record pπor to engaging the expert, and commg to mutually agreeable payment terms

-1-

SUBSTΓΠJTE SHEET (RULE 26) A common pπor art system for addressing the needs of a person seeking expert help is a telephonic help lme. In such systems, the user is first required to identify the appropπate contact number. Oftentimes, the user must place the call within a set of limited and often inconvenient busmess hours adopted by the service When the call is placed, the user is often channeled through a seπes of menu options, after which the user may finally be connected with a human being Even at that juncture, the user has no way of knowing the skill set and expeπence of the person on the other end of the line

When attemptmg to use a network of computers, such as the Internet, to locate an expert, a user is often confounded by a deluge of information in a format that is difficult to intelligently review Moreover, there is seldom any means to contact the given expert, no way to determme the past expeπences of other parties who have contacted the expert, and payment is cumbersome.

In response to this need, computer-based service systems have been developed wherein a user requiring information is required to complete a form to attempt obtam the service they require. Oftentimes, the form is madequate to identify the specific needs of the user, or the user does not have adequate computer skills to formulate their query m what is to that user an arcane syntax In addition, the user may not have sufficient specialized knowledge of computer-based query systems Moreover, users of such pπor art systems often have little or no way of evaluating the experts proffered m response by the system to the user's quenes pπor to retaining such expert's assistance Another flaw inherent in both pπor art telephomc and computer-based systems is the delay commonly expenenced by the user in reaching the expert

From the standpoint of the expert, an equally large number of problems aπse within the typical help-desk setting. An expert m such systems is required to travel to a particular physical location, which may be mconvement or mfeasible An expert is required to man the desk duπng a specified peπod, which makes the expert's schedule less flexible m terms of other mterests,

-2-

SUBSTΓΓUTE SHEET (RULE 26) mcludmg other work pursuits And experts "freelancing" are faced with administrative problems, most notably payment collection issues Finally, experts manning a help-desk often require the user to explain the problem, instead of having the opportunity to actually see and analyze the problem from the standpoint of the user III. Brief Description of the Drawings

For a further understandmg of the nature and objects of the present invention, but not by way of limitation, reference should be made to the following detailed descnption, taken m

conjunction with the accompanying drawings, in which like elements are given the same or analogous reference numbers and wherem

Fig. 1 is a block diagram of the system for connecting users to experts of the present invention

Fig. 2 is a block diagram of a multiple server and multiple database configuration that may be used m connection with the method of the present mvention

Fig. 3 is a schematic diagram of a multiple server configuration with a router for routmg users to experts in accordance with the present mvention

Fig. 4 is an exploded block diagrammatic view of a server m accordance with the present mvention

Fig. 5 is a diagrammatic representation of a taxonomy which may be used in the present invention Fig. 6a is a flowchart of an exemplary initial client logm routme

Fig. 6b is an exemplary flowchart of server actions responsive to client logm

Fig. 6c is a flowchart of a send request between the client and server

Fig. 6d is a flowchart of a receive request from the server

Fig. 6e is a flowchart of a send reply routine between the server and the client

Fig. 6f is a flowchart of a receive reply routine between the client and server

Fig. 7a is a flowchart showing an exemplary user question commumcation protocol between the client and server Fig. 7b is a continuation of the flowchart showing the communication flow responsive to a user question commenced in Fig. 7.

Fig. 7c is a further continuation of the flowchart depicted in Fig. 7a and Fig. 7b.

Fig. 8 is a flowchart for the find agent routine run by the client application.

Fig. 9a and Fig. 9b are flowcharts of the ranking process. Fig. 10a is a flow diagram showing an exemplary routine for initiating a service requestor/service provider conference.

Fig. 10b is a flow diagram showing a process for joining a service requestor/service provider conference.

Fig. 10c is a flow diagram illustrating a process for leaving a service requestor/service provider conference.

Fig. lOd is a flow diagram for the procedure whereby the server of the present invention collects information pertaining to a service requestor/service provider conference.

Fig. lOe is a flow diagram for the procedure for terminating a service requestor/service provider conference.

IV. Description of a Preferred Embodiment

The present invention provides for an online, real-time method and system for connecting users to appropπate experts through a network of computers such as the Internet. Users seeking a specific type of help are presented with a list of available experts The user may then browse the information presented and select an expert When a selection has occuπed, the user and expert are connected, real-time, so that the expert may resolve the question or need of the user Payment may be admmistered by the system, and obtained from either the user or an entity which has engaged the expert or provider of the system.

Fig. 1 shows, in block diagram form, the operation of the present invention in its most basic form. A service requestor 10a who is normally operatmg a computer system, issues a request for a service (commonly a request for expert assistance) from one or more service providers 10b located remote to the service requestor 10a. In a prefeπed embodiment, service providers 10b may be experts or other types of service providers, e g , a catalog site.

At least a portion of the service requestor's 10a request is formatted mto a data commumcations compatible data package, e g , using a standard such as extensible Markup Language (XML), and then sent to server 30 usmg data commumcations pathway 20. In the preferred embodiment, data commumcations pathway 20 is the Internet, using TCP/IP protocols

A routing program (not shown) executing within server 30 examines database 40 accessible to server 30 for a list of appropπate experts responsive to service requestor's 10a request. If one or more matches are found, a resulting list of matches may be returned to service requestor 10a for acceptance. The list may also include specified attributes for each expert. Service requestors 10a may then be allowed to selectively view the resulting list of service providers 10b uncovered by the match, the ability to sort the list according to one or more attribute cπteπa such as name, ranking information, specific attribute, or combmations thereof.

-5-

SUBSTΓΠJTE SHEET (RULE 26) In an alternative embodiment, service requestors 10a are allowed to browse a portion of database 40 which is a taxonomy 60 (shown m Fig 5), detailed herein below Such browsing may allow service requestors 10a to took at attributes of service providers 10b available either m general or in one or more domains (not shown in the figure), questions asked but not answered, questions asked and answered, ongomg conversations, or any combmation thereof

If service requestor 10a accepts service provider 10b or otherwise affirmatively mdicates selection of a service provider 10b, and if service provider 10b is available, service provider 10b selected by a service requestor 10a receives a notification of the attempt by service requestor 10a to contact that service provider 10b The notification may include all or a portion of service requestor's 10a request, the location in taxonomy 60 of the classification of service requestor's 10a request, an attribute representmg an identifier for service requestor 10a, or any combmation thereof Service provider 10b may then elect to receive or reject the request

If service provider 10b is available and elects to receive the request, service requestor 10a establishes real-time, peer-to-peer level commumcations 12 with that service provider 10b, as those skilled in the art will understand the term, at which pomt the commumcations between clients 10 occurs on a peer-to-peer level without any further need for server 30 Real-time, peer- to-peer communication 12, mcludmg the ability to have a secured commumcation established between service requestor 10a and service provider 10b, may include text, audio, video, whiteboard, file transfer, and/or remote control, and server 30 may be extracted from the commumcation link at that pomt

In an alternative embodiment, selection of service provider 10b may be automatically accomplished by the matching program, for example, on a first-match or best fit set of cnteπa

A client application 100 (not shown m Fig. 1) executmg at service requestor 10a and service provider 10b retains state information to allow resumption of a session should the session

-6-

SUBSTTTUTE SHEET (RULE 26) be discontinued abnormally, e.g., a power outage. In a preferred embodiment, the system also provides for logging each transaction between service requestor 10a and server 30, and between client 10a and expert 10b in the event the server 30 is extracted from the communication's loop. In the prefened embodiment, client application 100 communicates to server 30 through a class interface module that encapsulates network communication protocol, XML packet building, XML parsing, and server side method invocation. Use of a standard such as XML for packaging and transmitting data between clients 10 and servers 30 allows for flexibility without having to change code executing within server 30 or client 10.

Client applications 100 may communicate via dynamically linked library (DLL) modules. Each DLL presents a set of application program interfaces to client application 100, receiving data from client application 100 and passing on coπectly formatted data to another application such as Microsoft® Net Meeting®. Use of DLL modules provides great flexibility in the abilities of client application 100, especially in client-to-client peer level communications, without the need for extensive code changes in client application 100. Additionally, a client daemon application (not shown in Fig. 1) may be provided to interface other software applications such as browsers to server 30 as well as to provide an interface to facilitate establishment of sessions between service requestors 10a and service providers 10b, e.g. to Microsoft® Net Meeting® or AOL®. In this manner, a client user interface, as that term is understood by those skilled in the computer arts, may be provided independently of the client daemon application, allowing for customization of a user interface.

Additionally, client daemon applications may provide interfaces to standard protocols such as ITU H.323, for real-time video, voice, or data, and ITU T.120, for real-time multipoint

data connections and conferencing. Referring now to Fig. 2, a block diagram of a multiple server and multiple database configuration, in order to handle volume and load requirements server 30 may be multiple servers 3 la, 3 lb, and 31c, and database 40, detailed herein below, may be replaced with multiple databases 41a, 41b, and 41c, and 41d Servers 31a, 31b, and 31c may be in communication with databases 41a, 41b, 41c, and 41d through any number of means, all of which are readily understood by those skilled m the computer arts, including by way of example and not limitation a common bus, local area network, RAID servers, and the like In the preferred embodiment, the scalability may be dynamic, providing stateless servers to which requests may be routed and or rerouted depending on load and availability of that server Further, servers 31 a, 31 b and 31 c may be multithreaded wherein the number of threads per server is a customizable number, thus allowing each server to be tuned to match the physical hardware with which such server is implemented

The user's computer may be of any family, e g , the x86 family or the Macmtosh Vaπous databases (e g , Oracle, Sybase) may be used as well Fig. 3 is a schematic diagram of an embodiment of the present mvention with a router In a prefened embodiment, intelligent handling routing software such as BIG/IP, marketed and manufactured by F5 may be used to send accept requests from clients 10 and route those requests from router 50 to the best server 30 available at any particular instant from one or more servers 30 In this form of dynamic routmg, servers 30 that are no longer responding are removed or otherwise disabled from receivmg any further requests to process client 10 or server 30 requests Accordingly, each server, such as server 30a, 30b, or 30c, is stateless, allowing requests from service requestors 10a to be serviced in turn by a plurality of servers 30a, 30b and 30c without degradation to response times or of the request In the preferred embodiment, the client/server framework is implemented using the ADAPTIVE Communication Environment (ACE) ACE is an open-source object-onented framework that is fully portable to many operating systems

Referring now to Fig. 4, a block diagrammatic view of a server, server 30 compπses one main function block Pπmary daemon 32 (PD) maintains threads representing requests and responses, as that term is readily understood by those skilled in the software arts In the prefened embodiment, PD 32 is a Win32 service that runs m a Windows NT environment PD

32 receives all requests from clients 10 and processes them usmg one or more handler programs

33 PD 32 supports numerous tasks, including by way of example and not limitation service requestor 10a and service provider 10b logons and logoffs, service requestor 10a and service provider 10b availability status, creation, modification, and deletion of service requestors 10a and service providers 10b, mcludmg attribute information, start conference, join conference, end conference, find service provider, and rank service provider

Handler programs 33 are methods m PD 32 that get mvoked to handle a specific request One or more handler programs 33 execute within server 30 to handle the vanous requests, mcludmg by way of example and not limitation mtegration to other systems via one or more application program interfaces (not shown m Fig. 4)

In a prefened embodiment, every transaction between clients 10 and server 30 is recorded by server 30 Accordmgly, the system provides for gathering and reporting of numerous statistical and empmcal data mcludmg usage and performance The information gathered may also be accessible to and stored m database 40, detailed herein below, for further use by database 40 with respect to knowledge domam contents and utilization

Database 40 compπses representations of qualifications and characteπstics of each service provider 10b As will be understood by those skilled m computer arts, database 40

-9-

SUBSTTTUTE SHEET (RULE 26) itself may be a seπes of databases 40, shown in Fig. 3 as database 41a and database 41b, and may be collocated or dispersed Accordingly, redundancy and replication of databases may be provided to allow for online transactional integπty

Each service requestor 10a and service provider 10b is descnbed in database 40 by a plurality of attπbutes Service provider attπbutes may mclude, by way of example, overall ratmgs numbers of engagements, certifications, helpfulness ratmg, patience ratings, knowledge rating, and the like

Additionally, service providers 10b may provide alternative sets of attπbutes for a plurality of domains in which the service provider wishes to appear In the preferred embodiment, database 40 may be implemented usmg one or more of

Oracle, Microsoft Coφ , SQL Server, or any combmation thereof

Fig. 5 is a diagrammatic representation of a taxonomy that may be used m the present mvention In a preferred embodiment, a method of providing an extensible framework for taxonomy 60 as well as a ratmg methodology may be included m database 40 In one alternative embodiment, each server 30 obtains a copy of taxonomy 60 including any and all indices for taxonomy 60

Extensible taxonomy 60 compπses a collection of domains (not shown), agents 61a, 61b, 61c, and node linkages 64a, 64b, 64c, 64d, 64e, and 64f, mcludmg weightmg factors In Fig. 5, exemplary domams compπse areas in which service providers 10b may be expert such as word processmg, cable modems, or music compact disks Each domam may be subdivided into subdomains, e g within a domain of word processing experts subdomams may exist for two or more operating systems' word processors

Further, a set of descπptors called terms 62a, 62b and 62c exist as well where each term represents a topic area in which a query may be posed At least one contact address is provided

-10-

SUBSTTTUTE SHEET (RULE 26) for each service provider 10b. Contact addresses 63 may include Internet addresses known as universal resource locators (URLs), telephone numbers for voice contact, telephone numbers for facsimile contact, telephone numbers for pager contact, or the like.

Accordingly, extensible taxonomy 60 helps define a set of nodes, where the nodes are agents 61, terms 62, and contact addresses 63. Each node may be linked in extensible taxonomy 60 to more than one other node. Node linkages 64 may be described by additionally weighting factors which describe a node's relationship to the other linked node. Weighting factors may be fuzzy logic, such as "close" or "similar," or may be non-fuzzy quantities such as an integer or other number within a range, e.g. a number between I and 100 where lower numbers indicate a less robust relationship than higher numbers.

In the operation of the preferred embodiment, referring now to Fig. 1 and Fig. 6, a flowchart of the initial client login, clients 10, including end user -service requestors 10a and service providers 10b, wishing to use the present invention invoke a client application 100 native to their operating environment. In the preferred embodiment, client applications 100 are written for a Win32 environment in a language such as Microsoft Visual C++. Additionally, one or more dynamic link libraries (DLLs) may be presented to allow client application 100 to interface with other applications.

As shown in Fig. 6a, service requestor 10a initializes client application 100. Automatic login 110 may be provided as an option. If automatic login 110 has been configured or otherwise enabled 111, service requestor's 10a login information is retrieved from a local data store such as a hard drive. If configured or provided, service requestor 10a is queried 112 for login information. Once supplied, login information is communicated 113 to server 30. Referring now to Fig. 6b, a flowchart of server 30 actions for login, server 30 verifies login information, generally shown as "120," and sends a reply to client application 100. If login is

-1 1-

SUBSTTTUTE SHEET (RULE 26) unsuccessful, client application 100 notifies service requestor 10a and optionally and/or configurably re-prompts for logm information 112

Referring now to Fig. 6c through Fig. 6f, flowcharts of general messaging between client application 100 and server 30, client application 100 interfaces with server 30 and other clients, e g service providers 10b, through data communications network 20 such as the Internet as well as with other applications through one or more appropπate application program interfaces Client's 10 requests are formatted into an appropπate package using any of numerous packagmg means such as XML, before the packaged request is communicated to server 30 or other clients 10 Client application 100 may also be modular to allow utilization of numerous commumcations tools between clients, such as those offered by Microsoft® NetMeetmg® mcludmg but not limited to voice communications, video commumcations, whiteboard and other remote control functionality, chat sessions, and so on Support for multiple media, multiple simultaneous commumcations, or combinations thereof may also be supported

Service requestors 10a may optionally provide service provider 10b with information regardmg the operatmg environment of service requestor 10a including by way of example and not limitation hardware platform, software application information, and combmations thereof Client application 100 creates a formatted message 101a which is transmitted 10 Id to server 30 Server 30 reads 102a the formatted message, decrypts 102b the message, and processes the formatted message 102e If the message was formatted coπectly, server 30 contmues to process 102g the message When sending a response to client application 100, server 30 formats 103a the response, encrypts 103c the response, and sends 103d and 103e the response back to client application 100 Client application 100 receives 104a the response, decrypts 104b, extracts 104d the data, and contmues

-12-

SUBSTΓΓUTE SHEET (RULE 26) Referring back to Fig. 6, if login is successful, the remainder of client application 100 initializes and service requestor 10a availability is updated 131 m the system In the prefened embodiment, state information for service requestors 10a is stored locally on client's 10 computer, including by way of example and not limitation logm information, favoπtes, and history files

Referπng now to Fig. 7, Fig. 7b (a continuation Fig. 7) and Fig. 7c (a contmuation of Fig. 7b), service requestor 10a selects an option or otherwise indicates to client application 100, as will be understood by those skilled in the computer arts, to formulate a request 140 to server 30 At least a portion of the request is encapsulated 145 mto an appropπate format, m the prefened embodiment XML, and sent 147 to server 30 Client application 100 sends a call request 160 to server 30 which m turn calls 165 service provider 10b Service providers 10b may be have one or more statuses with respect to responding to service requestor's 10a requests, mcludmg by way of example and not limitation offline, online but otherwise unavailable (e g busy), online and available Additionally, service providers may provide the system with schedules of availability If service provider 10b accepts the call 170, commumcations between service requestor 10a and service provider 10b begin on a peer-to-peer basis Service requestor 10a and service provider 10b may then agree 173 on a call mode which is to be used for the session Call modes may include text, audio, video, whiteboard, file transfer, and/or remote control In Fig. 8, a routine for finding a service provider 10b, server 30 searches 150 taxonomy

60 in database 40 for one or more service providers 10b which taxonomy 60 indicates can provide the requested service Server 30 then sends 151 a response to client application 100 which indicates a failure 153 if no service provider 10b exists m database 60 for the request, or presents a list 154 of one or more service providers 10b if the search was successful

-13-

SUBSTΓΠJTE SHEET (RULE 26) If the search was successful, service requestor 10a may select 155 one of the listed service providers 10b Service providers 10b may provide their services for free or for fee In one embodiment, service providers 10b may set their rates dynamically, based on one or more factors, may set a flat fee, or any combination thereof Service requestors 10a who so request may be allowed to see service provider's 10b rate at any time including pπor to engagmg in any communication with the service provider

Referπng agam to Fig. 7c, a continuation of client request flowchart, at the conclusion of the peer-to-peer session, service requestor 10a or service provider 10b may end the peer-to-peer session 175 An automatic timeout or pause may be present at step 174 to activate whenever required, such as when there is no activity of some configurable, predetermined amount of tune In part, such a feature is used to more accurately reflect usage with respect to billing for those areas m taxonomy 60 where service requestor 10a gets directly billed or service provider 10b gets paid Additionally, peer-to-peer sessions between service requestors 10a and service providers 10b can be placed on 'hold" at step 175 rather than abandoned altogether Refernng now to Fig. 9a and Fig. 9b, flowcharts of the ranking process, when the peer-to-peer session ends, service requestor 10a may rank 180 service provider 10b after which time client application 100 terminates Service requestors 10a may therefore obtain a display of a rank dialog 200 and be allowed to provide quantitative and qualitative feedback 210 on service provider 10b Feedback may mclude knowledge, responsiveness, patience, ease of access, quality of service, and the like Additionally, client application 100, PD 32, or other processes may track other items such as actual tune online, data packet turn around, use of tools such as whiteboards, and the like One or more algoπthms 240 may then mampulate these quantitative and qualitative feedback measurements mto weightmg factors which are merged or combined with and/or otherwise replace the existmg weightmg factors 241 associated with the node m

-14-

SUBSTTTUTE SHEET (RULE 26) taxonomy 60 representing the service provider Service requestors 10a are allowed to provide quantitative and qualitative feedback on service provider 10b to server 30, mcludmg responsiveness to the service request, applicability of service provider 10b to a service requested, ease of access to and quality of responsiveness from service provider 10b, and the like Server 30 will update the history 182 of service provider 10b with ranking information and other information such as length of time spent peer-to-peer

Client application 100 may also provide an option allowing service requestors 10a to record information about one or more service providers 10b, including by way of example and not limitation biographical information, session information, histoπcal data, statistical data, and any combmation thereof Service requestors, 10a may add to a list of favoπtes and even contact service providers 10b on the favoπtes list directly Optionally, server 30 may update database 40 with information from the peer-to-peer session such as questιon(s) posed and answer(s) received Client application 100 may be responsible for maintaining state information for that client, e g logm information, favoπte service providers, and history, generatmg and routmg commumcations requests to the server, and generatmg and routmg commumcations requests to another client

In one embodiment, service requestors 10a and service providers 10b may nommate other end users or service providers to be service providers For example, service providers may be experts m one or more fields, and end users may nommate another end user as an expert. An end user may even nommate him or herself to be an expert

In an alternative embodiment, a moderator can join an end user - service provider session either passively or actively, and monitor the session In this embodiment, the moderator - which may be another end user or another service provider - may remove the first service provider from

-15-

SUBSTΪTUTE SHEET (RULE 26) the session, for example if the first service provider is being rude, unprofessional, or inadequate Accordingly, moderators may be visible or invisible to the participants

Figs. 10a, 10b, 10c, lOd and lOe illustrate the handling of the conferencing operation between a service requestor 10a and service provider 10b More particularly, Fig. 10a shows the procedure whereby the system starts a conference Service requestor 10a initiates a request, which is received 400 by the server 30 The server 30 determines if the node id to which the conference belongs is valid 405 If it is not valid, the server 30 builds a failure reply 410, and the reply is sent to the service requestor 10a If the node id is valid, the server 30 generates a umque conference id number 420, stores information about the conference 425, stores the creator of the conference 430, adds the conference id to the reference node in the knowledge space 435, builds a success reply 440, adds the conference id to the reply 445, and sends the reply 415

A procedure for joining a conference is shown in Fig. 10b Referring thereto, the server 30 receives a request 449 The server then determines if the conference id from the XML tree identifies a valid conference 450 If not, a failure reply is built 455 and sent to the service requestor 460 If the conference id is valid, the user id is added the list of participants of the conference 465, a success reply is built 470 and sent 460

Fig. 10c shows a procedure for leavmg a conference When server 30 receives a leave request 475, it determines from the XML tree if the conference id identifies a valid conference 480 If it does not, the server builds a failure reply 485 and sends the reply 490 If the conference id is valid, the user is removed from the list of participants 495, a success reply is built 496, and sent to the user 10

In Fig. lOd, responsive to a request 500, server 30 determines if the node id is a valid node id in the knowledge space 505 If it is not, a failure reply is built 510 and transmitted 515

-16-

SUBSTTTUTE SHEET (RULE 26) If the node id is valid, the list of conference id's associated with the node id is added 520. A success reply is generated 525 and sent to the user 515.

Fig. lOe depicts the routine for ending a conference. Responsive to a request 530, the server 30 determines if the conference id is valid and within a list of ongoing conferences. If it is not, a failure reply is generated 540 and transmitted 545. If the conference id is valid and ongoing, then for each node id that has the conference id associated with it, the conference id on such node is removed 550. Then, all user id's stored on the server for the conference id are removed 555, and the conference is removed from the list of ongoing conferences 560. A success reply is generated 565 and sent to the user 545. In another embodiment of the present invention, users can call for additional help if the cunent help has not satisfied the need of the user. Additionally, secure transactions are provided for by the system in a means familiar to persons of ordinary skill in the art.

It may be seen from the preceding description that an apparatus and method for selective routing of users to service providers is provided. While the invention has been described in the context of a prefened embodiment, it will be apparent to those skilled in the art that the present invention may be modified in numerous ways and may assume many embodiments other than that specifically set out and described above. Accordingly, it is intended by the appended claims to cover all modifications of the invention which fall within the true scope of the invention.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims. As used herein, the terms "comprises," "comprising," or any other variation

-17-

SUBSTTTUTE SHEET (RULE 26) thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

Claims

1 A method of linking a user and a selected expert via a network of computers compπsing stoπng a core set of information for a plurality of experts in an online database, said core set of information including contact information and area of specialization of each of such plurality of experts, collecting assistance requirements from a user relating to said user's desired expert assistance, conelatmg said assistance requirements with at least some of said core set of information to identify a plurality of appropπate experts, detecting which of said appropπate experts is available to identify a subgroup of suitable experts, presentmg said user with said subgroup of experts to allow said user to select said selected expert, and establishing a real-time connection between said user and said selected expert

2 The method of linking a user and a selected expert of claim 1, wherem said assistance requirements include field of expertise selection information

3 The method of linking a user and a selected expert of claim 1 , wherem said detectmg step compnses sending an electromc message to each of said appropπate experts

4 The method of lmlαng a user and a selected expert of claim 1 , wherem said detectmg step compπses determining which of said appropπate experts is logged onto a host

5 The method of linking a user and a selected expert of claim 1, further compπsmg terminating said real-time connection upon reachmg a termination event

6 The method of linking a user and a selected expert of claim 5, further compπsmg measuring the total duration of said real-time connection

7 The method of linking a user and a selected expert of claim 6, further compπsing allocating a cost to said user based at least in part upon said total duration 8 The method of linking a user and a selected expert of claim 7, wherein said allocation step is further based at least in part upon a field of expertise of said selected expert

9 The method of linking a user and a selected expert of claim 8, wherein said allocation step is further based at least in part upon a degree of expertise of said selected expert

10 The method of linking a user and a selected expert of claim 7, wherein said allocation step is further based at least in part upon a degree of expertise of said selected expert

11 An onlme system for establishing a communications lmk between a user and a selected expert compπsing a server accessible over a network, said server having a processor and a server storage having an expert database, said expert database containmg a core set of information for a plurality of experts, said core set of information mcludmg contact information and area of specialization of each of such plurality of experts; a computer system in commumcation with said server via said network compπsmg a user, said user having assistance requirements, a display, and a data entry device for collecting said assistance requirements from said user, wherein said server conelates said assistance requirements with at least some of said core set of information to identify a plurality of appropnate experts, detects which of said appropπate experts is available to identify a subgroup of suitable experts, causes said display to present to said user a listing of said subgroup of experts to allow said user to select said selected expert, and establishes a real-time connection between said user and said selected expert

12 The system for establishing a communications link between a user and a selected expert of claim 1 1, wherein said assistance requirements include field of expertise selection information 13 The system for establishing a communications link between a user and a selected expert of claim 11 , wherem said server detects which of said appropπate experts is available to identify a subgroup of suitable experts by sending an electronic message to each of said appropπate experts

14 The system for establishing a communications link between a user and a selected expert of claim 11, wherem said detects which of said appropπate experts is available to identify a subgroup of suitable experts by determining which of said appropπate experts is logged onto a host

15 The system for establishing a communications link between a user and a selected expert of claim 11, further compnsmg terminating said real-time connection upon reaching a termination event

16 The system for establishing a communications link between a user and a selected expert of claim 15, further compπsmg measuπng the total duration of said real-time connection

17 The system for establishing a communications lmk between a user and a selected expert of claim 16, wherem said server allocates a cost to said user based at least in part upon said total duration

18 The system for establishing a commumcations lmk between a user and a selected expert of claim 17, wherem said server allocates said cost based at least in part upon a field of expertise of said selected expert

19 The system for establishing a communications lmk between a user and a selected expert of claim 18, wherem said server allocates said cost based at least in part upon a degree of expertise of said selected expert

20 The system for establishing a commumcations link between a user and a selected expert of claim 17, wherem said said server allocates said cost based at least in part upon a degree of expertise of said selected expert