APPARATUS AND METHOD FOR CREATING AUDIO FORUM WEB
TOURS
This application is a continuation-in-part of serial number 09/358,877, filed July 22, 1999, entitled, "Apparatus and Method For Creating Audio Forums."
BRIEF DESCRIPTION OF THE INVENTION
The present invention discloses an apparatus and method for hosting multiparty audio conference calls, or "forums," using a networked system of computers or other communication devices. More particularly, this invention relates to a system and method for accessing and creating audio forums using a forum controller that is accessible by each computer within the system.
BACKGROUND OF THE INVENTION
With the advent of the Internet and ever improving network technologies, it is now possible to provide voice communication over computer and communication networks such as coiporate intranets and the Internet. Communication technologies which break down voice traffic into data packets for transmission over Internet protocol ("IP") networks are referred to as "voice over IP" or "VOIP" technologies, fact, several of the major Internet portal sites, such as Excite.com, provide services which allow people who have the appropriate computer hardware to communicate with one another over the Internet using VOIP technologies. Such services are typically referred to as "chatrooms." FIG. 1 illustrates a typical chatroom. While chatrooms provide a source of entertainment, they possess drawbacks that severely limit their commercial utility.
One drawback with chatrooms is that, typically, only one person may speak at any given moment during the conversation. Chatroom providers implement the limitation of allowing only one speaker at a time to avoid data loss and to avoid confusion when the number of participants in the chatroom increases. Furtlier, it is lαiown in the art that when too many participants speak at the same time, the speech becomes unintelligible.
Another drawback of conventional chatrooms is that they are dispersed at different Internet protocol (IP) addresses throughout networks making it inconvenient to locate and/or join any given chatroom. Thus, if a sports fan wishes to talk to other sports fans, he must know the specific location of a specific chatroom in which the participants are discussing sports. Absent knowledge of the location, the sports fan must search the network for the IP address for such a chatroom. Often, such sites are dispersed throughout the network at essentially unrelated IP addresses. Similarly, if a participant wishes to discuss the information found on a specific web site, he typically must leave that web site and connect to a different IP address altogether to enter a chatroom discussing that subject matter.
In addition to presenting problems to chatroom participants, chatrooms also present difficulties to their providers. A chatroom provider typically dedicates network resources to a chatroom even if no one is currently using the chatroom because the provider must allocate a fixed name to each chatroom. Moreover, in typical configurations, the provider routes all speech in the forum through a server, requiring further network resources. Together, these network resource requirements limit the number of commercially viable chatrooms that a provider may sponsor. For these and other reasons, the chatrooms, while functional, are unsatisfactory in practice.
Another voice over IP technology is found in peer-to-peer products which allow private phone conversations. While these products solve some of the problems presented by chatrooms, they too suffer drawbacks. For example, if two parties are speaking to each other using a peer-to-peer mechanism, there is no easy way for a subsequent party to join the call. As such, these peer-to-peer products lack a mechanism for a user to create a multiparty conference call or forum.
In view of the foregoing, there is a need in the art for a system and method for guiding users to forums that are of interest and for providing each user with the ability to create a forum that can be accessed by other users.
SUMMARY OF THE INVENTION
A method of executing an audio forum web tour includes the step of linking a set of audio forum participants at a uniform resource location within a networked environment to form a first audio forum. Each audio forum participant can listen and
speak to the set of audio forum participants while observing common graphical content from the uniform resource location. A new uniform resource location is then specified within the networked environment, causing the set of audio forum participants to be automatically connected to the new uniform resource location to form a second audio forum. At the second audio forum, each audio forum participant can listen and speak to the set of audio forum participants while observing common graphical content from the new uniform resource location.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a typical prior art voice chat system.
FIG. 2 illustrates a system for maintaining a forum list in accordance with one embodiment of the invention.
FIG. 3 illustrates a forum GUI window in accordance with one embodiment of the invention.
FIG. 4 illustrates a forum window in accordance with one embodiment of the invention.
FIG. 5 illustrates the processing associated with accessing a forum selected from a forum list in accordance with one embodiment of the invention.
FIG. 6 illustrates a data entry window in accordance with one embodiment of the invention.
FIG. 7 illustrates the processing associated with creating a private forum in accordance with one embodiment of the invention.
FIG. 8 illustrates a data entry window that may be used to provide each user in a system with a different user identifier.
FIG. 9 illustrates a data entry window that may be used by each user in a system to designate a user label and related information.
FIG. 10 illustrates a GUI that includes an Internet browser, which is viewing a particular uniform resource location, and a forum graphical user interface panel.
FIG. 11 is a detailed illustration of the processing steps that may be used to create forums and add participants to the forum in accordance with the system of FIG. 2 and FIG. 13.
FIG. 12 is an illustration of a Web page including a forum hyperlink in accordance with one embodiment of the invention.
FIG. 13 illustrates a system for using a forum hyperlink to direct a user computer to join a particular forum, which is in accordance with one embodiment of the invention.
FIG. 14 illustrates a GUI that can be used to participate in a public or private audio forum web tour when a web tour participant deviates from the tour leaders URL.
FIG. 15 illustrates a GUT that can be used to participant in a public or private audio forum web tour.
FIG. 16 illustrates a GUI that can be used to accept an invitation to join a public audio forum web tour.
FIG. 17 illustrates a GUI and Internet browser engaged in a public audio forum web tour.
FIG. 18 illustrates a GUI being used to participant in a public audio forum web tour.
FIG. 19 illustrates a system for conducting forum web tours that is in accordance with one embodiment of the invention.
FIG. 20 is a detailed illustration of the processing steps that maybe used to add a participant to a public forum web tour in accordance with the system of FIG. 19.
FIG. 21 is a detailed illustration of the processing steps that may be used to update a participant list for a public forum web tour in accordance with the system of FIG. 19.
FIG. 22 is a detailed illustration of the processing steps that may be used to synchronize the Internet browser URLs of public forum web tour participants in accordance with the system of FIG. 19.
FIG. 23 is a detailed illustration of the processing steps that may be used to remove a forum web participant from a public forum web tour in accordance with the system of FIG. 19.
FIG. 24 is a detailed illustration of the processing steps that may be used to add a private forum web tour to a web tour list in accordance with the system of FIG. 19.
FIG. 25 is a detailed illustration of processing steps that may be used to add a participant to a private forum web tour in accordance with the system of FIG. 19.
FIG. 26 is a detailed illustration of additional processing steps that may be used to add a participant to a private forum web tour in accordance with the system of FIG. 19.
FIG. 27 is a detailed illustration of the processing steps that may be used to synchronize the Internet browser URLs of new private forum web tour participants in accordance with the system of FIG. 19.
FIG. 28 is a detailed illustration of the processing steps that may be used to synchronize the Internet browser URLs of private forum web tour participants in accordance with the system of FIG. 19.
FIG. 29 is a detailed illustration of the processing steps that may be used to remove a forum web participant from a private forum web tour in accordance with the system of FIG. 19.
Like reference numerals refer to corresponding parts throughout the several views of the drawings.
DETAILED DESCRIPTION OF THE INVENTION
Joining A Forum
FIG.2 illustrates a network 20 that may be operated in accordance with the present invention. The network 20 includes at least one user computer 22 and at least one server computer 24. The user computer 20 and the server computer 24 are connected by transmission channel 16, which may be any wired or wireless transmission channel. A firewall may optionally separate user computer 22 and transmission channel 16 and/or server computer 24 and transmission channel 16. The firewall serves to protect user computer 22 and/or server computer 24 from unwanted traffic. However, the firewall also limits the way in which user computers 22 may access each other across transmission channel 26.
The user computer 22 is any device that includes a Central Processing Unit (CPU) 30 connected to a memory (primary and/or secondary) 32, a network connection 36, and a user input/output ("i/o") device 38. Memory 32 typically stores computer programs, which may include a graphical user interface ("GUI") 34, a web browser 62, a preferred contact database 64, a URL module 66, and a user profile database 68. GUI 34 is used to access a forum list 46 using network connection 36. addition, GUI 34 can present a command line interface to permit a user to directly enter the name of a forum that the user wishes to join and/or any necessary password. Browser 62 is used in some embodiments to view web pages. Contact database 64 is used in some embodiments to
maintain a personalized list of preferred user contact information by a particular user. URL module 66 is a program that is used in some embodiments to coordinate the creation of forums. User profile database 68 includes pertinent information about auser, including at least a user identifier and a user label. Additional information, however, may be included in user profile database 68 in alternate embodiments. The user profile of a person is transmitted to forum controller 100 from user profile database 68 when the user logs into forum controller 100 from user computer 22. User computer 22 also has i/o device 38, including a visual output device (e.g., a computer monitor) for displaying GUI 34. The user i/o device 38 also includes a microphone and one or more speakers to enable audio communication between other forum participants, a preferred embodiment, user i/o device 38 includes a full duplex sound card so that the user can listen to other forum participants at the same time that the user is speaking.
The server computer 24 includes standard server components, including a network connection device 40, a CPU 42, and a memory (primary and/or secondary) 44. The memory 44 stores a set of computer programs and files to implement the processing associated with the invention, h particular, a forum list 46, an active user database 60, a forum controller 100, and a registered user database 102, are maintained in memory 44. The forum controller 100 controls forum list 46 as will be described in further detail below. Active user database 60 contains information about each user that is logged into forum controller 100. Registered user database 102 contains information about each user that is registered to loginto forum controller 100. In a preferred embodiment, aregistered user is defined as a person who has been assigned a unique user identifier and has designated a descriptive user label.
Forum list 46 comprises a list of forums 48 that are present in system 20. At least one user, associated with a user computer 22, participates in each forum 48. Thus, in this sense, at least one user computer 22 is associated with each forum. When a user computer 22 is associated with a forum, the user computer is capable of broadcasting audio, visual, and/or text messages to all other forum participants. When no user computer 22 is associated with a forum it follows that there is no user participating in the forum. When this occurs, the forum is terminated and removed from forum list 46 by forum controller 100. Each forum 48 in forum list 46 includes information such as, for example, the name of the forum 50, an indicator 52 as to whether the forum is public or private, a forum
password 54, a forum category 56, and the user identifier of each forum participant 58. Each participant in each forum is associated with a user computer 22 present in system 20. hi a preferred embodiment, each participant field 58 contains a user identifier that represents a participant in the corresponding forum 48. The user identifier serves as a pointer to a table entry in active user database 60. Table entries in active user database 60 include more detailed information about each forum participant. The table entries may include, for example, the E-mail address of each active user and/or the Internet Protocol that must be used to communicate with each user. In addition, further information about each user may be stored in an entry found in registered user database 102.
Forums 48 that have indicator 52 set to "public" are designated public forums and forums 48 that have indicator 52 set to "private" are designated private forums. Private forums are hidden in the sense that they are not listed by GUI 34. Forums 48 having a password in password field 54 are password protected forums. A user that wants to become a participant in forum 48 must provide the corresponding password 54 if the forum is password protected. Category field 56 is used to indicate the subject matter of the forum.
As previously pointed out, system 20 may include more than one server 24. Server 24 is defined herein as any computer in system 20 that includes a forum controller 100 having access to forum list 46. In some embodiments, active user database 60 may be an integral part of forum list 46 and there is no registered user database 102. However, as a practical matter, the method of the present invention is best advanced on systems in which active user database 60 is not an integral part of forum list 48 and there is a registered user database 102. In such embodiments, forum controller 100 preferably has access to active user database 60 and registered user database 102. In typical systems 20, registered user database 102 is maintained on a separate server 24, or possibly even on a user computer 22 to minimize the load on any particular computer and to maximize the overall performance of system 20. In some embodiments of system 20, the log in process to the forum list controller from a user computer 22 may be controlled by a routing routine. The routing routine determines which server 24 the log in request will be directed to based on any number of rational criteria, including the relative load of each available server 24, disk space availability, time of day, or a round-robin type algorithm.
The use of a routing routine is transparent to the person logging into forum controller 100 from user computer 22.
Referring to FIGS. 3 & 4, a GUI 34 in accordance with a preferred embodiment of the invention is illustrated. GUI 34 includes a forums button 302 (FIG. 3) that maybe used to launch a forums window 400 (FIG 4). Forums window 400 is used to list public forums present in forum list 46. Each public forum is listed on a row 402. Row 402 includes a column 404 to indicate whether the public forum is password protected, the forum name (50) 406, and the number of participants (58) 408 presently in the forum. In the embodiment shown in FIG. 4, a padlock graphic is displayed next to the name of a forum in column 404 if the forum 406 is password protected. If a user presses the "Join" button 414 while a forum, such as " New Users" or "test," is highlighted in the forums window, the user is added to the forum by forum controller 100. In some embodiments, a scroll bar 410 may be used to review a large forum list. By using a GUI 34 and a Forums Window 400 each user in system 20 can rapidly access forums from one centralized location and easily join the forums of interest.
This brief description of one aspect of the invention is more clearly understood in reference to FIG. 5. FIG. 5 illustrates processing steps that may by executed in accordance with one embodiment of the invention. In the first processing step shown in FIG. 5 (step 502), a user enters in log in information necessary to log in to forum controller 100. Such log in information may be a user identifier, a user label, a password, or any combination of such information. Once the user has entered in log in information, GUI 34 accesses the profile corresponding to the user from user profile database 68 (FIG. 2) (step 504). The log in information of step 502 is combined with the profile information of step 504 to generate a log in request that is transmitted to forum controller 100 on server 24 or other designated computer (step 506). This request may include a request for only a specific category 56 of forums, such as "Sports Talk" or "Vacations." h response to the login request, forum controller logs the user in by adding the user to active user database 60. Other variants of steps 504, 506 and 508 maybe used to achieve the same objective. For example, the user profile maybe transferred to forum controller 100 after forum controller 100 has logged the user in. Once the user has logged in, forum controller provides a portion of forum list 46 (step 510). Only forums 48 that are designated as public, however, may be provided by forum controller 100 in step 510.
The portion of the forum list 46 provided in step 510 may be determined by information stored in, for example, the user profile database 68. Such information may reflect the interests of the particular user. In alternative embodiments, information stored in registered user database 102 may be used to determine what portion of forum list 46 to provide in step 510. For example, registered user database 102 may track the type of forums the user has accessed in the past and provide the subset of forum list 46 that matches the types of forums the user has historically accessed. The portion of forum list 46 that is provided in step 510 is displayed on the user i/o device 38 of user computer 22 (step 512), typically in a forums window, such as the forums window 400 illustrated in FIG. 4. In some embodiments, steps 510 and 512 maybe an iterative process, where the user designates certain categories and "searches" forum 46 for forums of interest. Once the user selects a forum, forum controller 100 joins the user to the selected forum (step 514) and adds an entry 58 to the forum 48 thereby indicating that the user has joined the forum (step 516). If the forum that the user selects is password protected, then the user must supply the correct password 54 before step 514 is executed. If the user does not supply the correct password 54, the user will not be joined to the designated forum 48. Finally, forum participants are notified that the user has joined the forum (step 518) by sending a broadcast message to the GUI 34 of each user computer 22 associated with a participant 58 in the forum.
Because private forums are not provided to GUI 34, users who wish to participate in a private forum must specify the forum name 50 of the private forum through an interface provided by GUI 34. If the private forum is password protected, the user must additionally provide the password 54 associated with the private forum. If the user correctly identifies a forum 48 that is present in forum list 46, then the user is added to the forum 48 in the manner previously described.
At this point, a number of unique attributes of the present invention will be recognizable to those skilled in the art. A primary attribute is that a user does not have to search a large number of unrelated web sites for forums that are of interest. Further, forums can be password protected so that unwanted participants are kept out of forums. Publically available password protected forums provide commercial advantages over prior art chatrooms and peer-to-peer messaging. For example, forums of commercial interest may be password protected and the password sold for a fee. h one embodiment,
passwords may be time-stamped so that they are only useful for a predetermined length of time. Yet another unique attribute is that private forums may be created and tracked from a centralized location. Private forums provide another level of protection from unwanted participants. Finally, the list of forums provided to a user may be uniquely tailored to the interests of a user, based upon categories designated by a history database that hacks the types of forums a user is interested in.
Creating a Forum
The present invention allows any user to create a forum from any computer in system 20. Thus, instead of pressing the "join" button 414 in forums window 400 (FIG. 4), a user could press "create" button 412 to open a data entry window such as window 600 (FIG. 6). A new forum name 50 can be designated in a data entry field such as field 602. The new forum may be password protected by specifying a password in data entry field 604. If a password is supplied in field 604, the password is stored in entry 54 (FIG. 2). The forum may also be designated as public or private by toggling check box 606. Such a designation is stored in entry 52 of the corresponding forum 48 (FIG. 2). hi other embodiments, the data entry window may include fields that allow the creator to designate one or more categories 56 for the forum. In still other embodiments, the creator may designate which users may participate in the forum. Such embodiments provide the same functionality as password protected forums without any requirement that potential forum participants memorize several passwords.
GUI 34 (FIG. 2) can be used to set up forums that serve the same purpose as conference calls. A conventional conference call is created by contacting all conference call parties during the call. In this sense, each member of the conference call is "invited in" by someone who is already participating in the call. Using GUI 34, a user can set up a forum using an approach that is the inverse of conventional conference calling approaches. In this inverse approach, the conference call is originated as a forum that includes one or more participants. When additional users associated with user computers 22 are ready to participate in the forum, they may "join" the forum by designating the name of the forum. In an alternative embodiment, additional users associated with user computers 22 may "join" a forum, when they are ready, by accepting an invitation to join the forum. Such invitations are typically electronic messages sent by forum controller 100
to invited participants by users originating private forums. These electronic invitations are typically stored by user computers 22 and presented to users by GUT 34. As a private forum progresses, the one or more original participants in the forum may leave the forum without destruction of the forum. As previously discussed, in some embodiments, the forum may be password protected and thus require that all potential forum participants enter the correct password 54 even though they have been invited to the forum.
The benefits of forums hosted by a forum controller list maybe further appreciated by reference to FIG. 7. FIG. 7 illustrates detailed processing steps of a preferred embodiment that may be executed to utilize the benefits of a private forum. Each user that is logged into forum controller 100 may create a private forum. Once a user has logged into forum controller 100, the user may designate the name of a forum to be created. Because the forum is a private forum, the forum name is not made available to other users of system 20. In fact, the forum name may be hashed. The user ("forum originator") may further designate the names of people that are to be invited to the private forum. The forum to be created and the invitee list is transferred to the forum controller (step 702). In response to processing step 702, forum controller 100 verifies the uniqueness of the forum name designated by the forum originator. If the forum name is sufficiently unique, the forum controller creates the forum and joins the forum originator to the forum (step 704). A forum name is considered unique if it has a sufficient number of characters and there are no other forums having the same forum name in forum list 46. Forum list 46 is updated to include an entry corresponding to the private forum and the fact that the user is added to the private forum (step 706). The forum originator is notified that the private forum has been created by GUI 34 when forum controller 100 sends a message to GUI 34 (step 708). Additionally, forum controller 100 identifies each of the users that the forum originator has invited in processing step 702. Often this identification step may require the use of active user database 60 or even, in some embodiments, registered user database 102.
Once forum controller 100 has identified each user to be invited, an invitation to join the private forum is transmitted to the GUI 34 of each user computer associated with each invitee (step 710). The invited users have the option to accept or reject the invitation. Furthermore, invited users may block such invitations if the forum originator is on a block list stored in user profile database 68 (FIG.2). The information sent to each
invited user about the private forum in processing step 710 is carefully designed to present enough information to the invitee to be informative. However, care is taken to ensure that the forum created by the forum originator is kept confidential. Thus, even the forum participants are typically not told the name 50 of the forum. An invitee does not have to accept or reject the invitation to join the forum right away. In fact, invitations to join a forum may be scheduled long before the forum is to occur. The invitation may designate, for. example, the name of the forum originator, a Re: line (purpose), and the date, time, and expected duration of the private forum. Thus the invitee may access the forum any time during the existence of the private forum, at the invitee's convenience. It is this unique property that distinguishes the private forum of the present invention from conventional conference calls. Once an invitee has accepted an invitation to a forum (step 712), the invitee is added to the forum (step 714). Therefore, the list of forums 46 is updated to reflect the fact that a new participant 58 (the invitee) has been added to the particular forum 48 (step 716). Finally, a broadcast message is sent to all participants in the private forum indicating that an additional user has joined the forum (step 718).
FIG. 8 serves to illustrate a preferred embodiment of a data entry window that may be used in the invention. The window is used by GUT 34 of a user computer 22 in system 20 to assign a user identifier to each new user. The user identifier facilitates tracking which users are participating in each forum 48. This user identifier is typically a unique serial number, such as "FireTalk ID" 802. Referring to FIG. 9 each user may also designate a user label, or nickname 902. Other information that a user may designate includes a first and last name 904, a user password 906, an E-mail address 908, an option to hide E-mail addresses 910, and an option to specify the type of Internet protocol that may be used to reach the user 912. This information may be stored in user profile database 68 (FIG. 2) and transferred to forum controller 100 during the user log in process. Such information, or a subset of the information may be stored in active user database 60 when the user is logged into forum controller 100. Further, in some embodiments, this information may be stored in registered user database 102 (FIG. 2). In a preferred embodiment, when a user is participating in a forum, the user identifier is stored in participant field 58 and serves as an index to active user database 60 where the more user-friendly user labels 902 maybe found. Thus, notification steps 518 (FIG. 5) and 718 (FIG. 7) may involve looking up the user label of each participant 58 in active
user database 60 and posting the user label in a forum participant window 304 (Fig. 3) of GUI 34.
The maintenance of an active user database 60 of forum participants presents a number of advantages over prior art systems. One advantage is that when a user is viewing the participants in a forum participant window 304 (Fig. 3), the user can easily add any of the forum participants to a preferred contact list that is then stored in contact database 64. For example, using FIG. 3 to illustrate, a user may click on "Dave" to add Dave to a "friends" contact list 306. When the user selects "Dave," pertinent information about "Dave" is copied from an entry corresponding to "Dave" in active user database 60, such as the E-mail address of "Dave." This information is then stored in a record in contact database 64 on user computer 20 (FIG. 2). A user can also add any of the forum participants to a "block list." Communication from forum participants who are on this block list are rejected by user computer 22 and/or by server computer 24.
URL-Centric Forum Feature
A distinct advantage of the present invention is that novel methods may be used to create forums. One such method is disclosed with reference to FIG. 10. FIG. lO shows a typical web browser 62, such as Internet Explorer that is viewing the uniform resource location ("URL") "http://www.drapervc.com/" 1002.
A URL is a structured statement used to designate the location of a web page. A typical URL includes a protocol component which indicates the transfer protocol to be used to retrieve the web page, a domain component which specifies the host computer on which the web page resides, a directory component which indicates the directory on the host computer in which the web page is located, and a file name. See e.g., Shipley and Fish, How the World Wide Web Works, Ziff-Davis Press, Emeryville, California, 1996 which is hereby incorporated by reference.
Presumably, all users in system 20 who are simultaneously viewing web page 1002 share a common interest in the contents of the web page. Using the method of the present invention, a forum can automatically be created and added to forum list 46. In one embodiment, the forum name 50 for the URL exhibited by 2002 in FIG. 10 would be "www.drapervc.com." It will be appreciated that a forum name 50 could be either the server component of the URL, the pathname component of the URL, the filename
component of the URL, or any combination of such components. Furthermore, the URL could be operated on by any predetermined function to produce a candidate forum name. An illustrative predetermined function would be one that replaces all forward slashes "/" in the URL with underscores "_". So in the example, URL 1002 would be "www_drapervc_com." Another predetermined function could be one that strips the top level domain name, the "com" in the example, from the end of any URL. Thus URL 1002 would become "www.drapervc." hi a preferred embodiment, the URL is subjected to a predetermined function that encrypts the URL so that it cannot be accessed by users who are not viewing the same web page. For example, the URL could be subjected to a security hash. Many other functions can be envisioned and the examples presented herein merely serve to illustrate the point that any rational predetermined function or combination of such functions may be used to convert a URL address into a forum name 50.
Forums created based on some function of a URL that is being viewed by a browser 62 are recorded in forum list 46. Thus, once a first user has created a forum that is posted on list 46, additional users, using a different user computer 22 to view the same URL in a web browser 62 will become participants in the same forum. Each of these users participates in the forum 58 according to the methods discussed previously. The approach of creating forums based upon the URL address being viewed in a web browser dramatically changes the web experience. Rather than hunting for forums on unrelated web sites, a user may simply view web pages that are of interest. The likelihood that a particular user would like to speak with other people viewing the same URL is high, particularly if the content of the URL appeals to only a select audience. A representative web page, would be, for example, the technical support web page of a company.
FIG. 10 illustrates a GUT 34 that may be used by a user to enable this URL-centric forum feature. When a user toggles switch 1006 to "enable," the user will be added to public forums that are determined by the content of the URL address 1002 that the user is viewing in browser 62. Other people who are viewing the same web page from different user computers 22, who have turned on the URL-centric forum feature may be listed in forum participant window 304. Further, the forum name 50 could be listed in panel 1004. When a user toggles switch 1006 so that "enable" is not checked, the URL- centric forum feature will be disengaged. The web provides special privacy issues,
however, thus in some embodiments of the present invention, every effort is made to ensure that the identity of each person visiting a particular web site is not revealed to other users. Thus, in such embodiments, the other users visiting the same web site using the URL-centric forum feature are not listed in panel 1004.
GUI 34 is not required to implement the URL-centric forum feature of the present invention. GUI 34 merely serves as a convenient interface for turning on the URL-centric forum feature using switch 1006 (FIG. 10) . The actual URL-centric forum feature is URL module 66 (FIG. 2). URL module 66 will be described in more detail below. When URL module 66 is running on user computer 22, the URL-centric forum feature is enabled. URL module 66 can be implemented as a plug-in to an existing browser 62. Thus, a user may turn on the URL-centric forum feature through browser 62 without any requirement for GUI 34. In some embodiments, URL module 66 is compiled as an object that is easily incorporated into any program running on computer 22.
In a preferred embodiment, URL module 66 launches browser 62 and exploits conventional browser 62 architecture to determine which URL the browser is viewing. To illustrate this embodiment, URL module 66 may provide a unique GUI that allows a user to launch Microsoft Explorer. When the user requests the URL-centric forum feature, URL module 66 launches Microsoft Explorer and any change in the URL status of Microsoft Explorer is tracked using standard hooks. When the hook reports that a new URL is being viewed in Microsoft Explorer, URL module 66 determines whether a forum 48 corresponding to the new URL exists in forum list 46. For example, the URL will be subjected to a predetermined function such as a hash. Then a forum name 50 corresponding to the output of the hash will be searched for in forum list 44 using a lookup request. This look-up request is typically facilitated and/or regulated by forum controller 100. If a forum 48 having the appropriate forum name 50 does not exist, the forum is created by forum controller 100. Regardless of whether the forum existed or not at the time the web page was viewed by browser 62, the user is joined to the forum until the hook reports a change in status.
One of skill in the art will appreciate that browser 62 does not have to be launched from URL module 66 in order to provide an adequate hook by which to determine the URL status of browser 62. Many different types of embodiments for determining the status of browser 62 may be envisioned and all are within the scope of the present
invention. Further, no modification to existing web pages is required to enable the URL- centric forum feature. Rather, the URL-centric forum feature serves to augment web pages by providing added functionality to web pages. The URL-centric forum feature serves to improve the services and functionality of a web page and thus increase traffic to the web site. Because the URL-centric forum feature dramatically increases the utility of a web site, the URL-centric forum feature is an advantageous improvement over prior art technology.
The following example illustrates some of the utility of the URL-centric forum feature. In this example, GUI 34 (FIG. 10) is implemented as a software program named "FireTalk." FireTalk includes, in this example, an ability to execute a URL module 66 called "ShadowTalk" 1006 (FIG. 2). ShadowTalk is capable of launching a browser 62 such as Microsoft Explorer, Netscape, or Opera. When a web page is viewed using the launched browser 62, all Internet users that are viewing the same URL are placed into a forum associated with the URL. For example, all users viewing the ESPN Classic Sports web page are made participants in the ESPN web page forum. In one embodiment, when at least one user is viewing the ESPN web page, the ESPN web page forum, "www.classicsports.com," is published in the available forums window of FireTalk 1004 (FIG. 10). In a preferred embodiment, however, the URL is hashed to encrypt the URL name and the corresponding forum is designated as private so that people who are not accessing the URL may not gain entry into the forum. To continue the above example, when a user participating in the ESPN web page forum changes the web site in their browser 62 to a new web site, the user will no longer be a participant in the ESPN web page forum. Rather, the user will become a participant in the forum associated with the newly loaded web page. When there are no longer any participants in a forum generated by the URL-centric forum feature, the forum is terminated by forum controller 100. This termination feature prevents the build-up of an excessive number of forums in forum list 46. In the illustrated embodiment, a user can turn off the URL-centric forum feature by pressing a "mute" button on GUI 34. This "mute" button can be used to turn off the URL- centric feature until a web page of interest is loaded in browser 62. Then, the user enables the URL-centric feature by disengaging the "mute" button on GUI 34.
The general nature of the URL-centric forum feature has now been disclosed. Attention now turns to a more detailed discussion of the processing steps, necessary in a
preferred embodiment of the present invention, to support the URL-centric forum feature on system 20 (FIG. 2). FIG. 11 illustrates processing steps that are used in accordance with such an embodiment of the invention. In the first processing step, a user associated with user computer 22-1 makes a request for the URL-centric forum feature (step 1102). Such an act maybe as simple as enabling switch 1006 (FIG. 10) on GUI 34. hi response to the request for the URL-centric forum feature, URL module 66 is launched or activated. In this illustrated embodiment, URL module 66 does not have an independent GUI, thus there is no change in the display of user computer 22. Furthermore, it will be appreciated that URL module 66 may be a component or module embedded within the computer code for GUI 34.
Once URL module 66 is launched or activated, URL module 66 launches browser 62 (step 1104). Launching browser 62 from URL module 66 provides a convenient mechanism for establishing a software hook by which URL module 66 can track the URL status of browser 62. However, in alternative embodiments, URL module 66 does not launch browser 66. In fact, URL module 66 may be a plug-in added to browser 62. For example browser 62 could be Microsoft Explorer and URL module 66 could be a Browser Helper Object (BHO) type plug in. hi yet other embodiments, GUI 34 and URL module 66 may be one or more plug-ins added to browser 62. Regardless of what physical embodiment is implemented, a URL is viewed in browser 62 (step 1106) and a software hook is used to notify URL module 66 of the URL status of browser 62 (step 1108).
As discussed previously, the actual software hook used may be any of a number of conventional software hooks, including one that uses the Microsoft BHO. In response to a change in the URL status of browser 62, URL module 66 derives a proposed forum name based on one or more predetermined functions of the URL that browser 62 has loaded (step 1110). URL module 66 then makes a request to forum controller 100 to have the user join a forum having the derived forum name (step 1112). hi response to the request of step 1112, forum controller 100 determines if the requested forum is present in forum list 46 (FIG. 1). If there is no forum name 50 in forum list 46 with the same forum name, then forum controller 100 creates a forum having forum name 50 which is the derived forum name of step 1110 (step 1114). In a preferred embodiment, this new forum will be designated as private in field 52 (FIG. 2). Regardless of whether the forum previously existed, the user is added to the forum (step 1116). Accordingly, forum list 46
is updated to reflect that the user associated with user computer 22- 1 has joined the forum (step 1118). As discussed previously the exact architecture of participant field 58 may vary, h a preferred embodiment, however, field 58 serves as an index to a user record in active user database 60 where more information on each participant in a forum may be found.
Forum Hyperlinks
The centralized forum list 46 that is accessible to a network of user computers 22 has further advantages. One advantage is that web pages may be used as portals for gaining entry into forums in a single user step. FIG. 12 illustrates a web page that includes forum hyperlink 1202. Forum hyperlink 1202 points to a particular forum 48 in forum list 46. When a user clicks on forum hyperlink 1202 they are joined with a forum associated with forum hyperlink 1202. An advantage over prior art systems is that the forum is automatically set up by the simple act of clicking on the hyperlink. Once a user has gained entry into a forum using a forum hyperlink, the user can access all the features previously disclosed. For example, in one embodiment, the user can determine who the other participants in the forum are using a forum participant window 304 in GUI 34 (FIG. 3) which may be automatically launched when the link is selected.
FIG. 13 depicts a system 1300 in accordance with this aspect of the invention. System 1300 is identical to system 20 (FIG. 2) with the exception that there additionally exists a computer 1302 connected to transmission channel 26. Computer 1302 serves as a web page host. Computer 1302 is a standard computer including a Central Processing Unit (CPU) 1306 connected to a memory (primary and/or secondary) 1308. The memory 1308 typically stores a number of computer programs, including a web page 1310. Web page 1310 may be written in any language such as HTML and/or Java. Additionally, there is a forum hyperlink 1312 embedded within web page 1310. The forum hyperlink may also comprise standard computer program code written in a language such as HTML and/or Java. Computer 1302 is connected to other computers in system 1300 by network connection 1304.
It will be appreciated that systems other than system 1300, in which web page 1310 resides in a client computer 22 or server computer 24 are within the scope of the
present invention and that the existence of a web page on computer 1302 merely serves to best illustrate the concept of forum hyperlinks. Accordingly, using FIG. 13 to illustrate, a user will launch browser 62 on user computer 22. When the user selects web page 1310, a web page including forum hyperlink 1312 is displayed in browser 62 on user computer 22. When the user selects forum hyperlink 1312, forum hyperlink 1312 will cause user computer 22 to execute GUI 34. If the user computer 22 does not have GUT 34 installed, forum hyperlink 1312 will prompt the user associated with user computer 22 to see if GUI 34 should be installed on user computer 22. If the user requests that GUT 34 be installed on user computer 22, a copy of GUI 34 residing on computer 1302 will be installed on user computer 22 and then the newly installed GUI 34 will be executed on user computer 22.
Once GUI 34 is running on user computer 22, the user will be required to log in to forum controller 100. Obviously, if GUI 34 was already running on user computer 22 and the user was already logged in to forum controller 100 when forum hyperlink 1312 was selected, the user will not be required to log in to forum controller 100 a second time. Once the user has logged into forum controller 100, forum hyperlink 1312 will direct GUI 34 to join to a particular forum 48 associated with forum hyperlink 1312. The process of joining the forum is automated because pertinent information necessary to join forum 48 was acquired from user profile database 68 and communicated to forum controller 100 when the user logged into forum controller 100. When a user has been added to a forum, forum list 46 is updated according to the processing steps described in the previous embodiments above.
It will be appreciated that web page 1310 may have a plurality of forum hyperlinks 1312, each pointing to a different forum 48. Furthermore, there may be a plurality of web pages 1310 that each have the same forum hyperlink 1312. It will also be appreciated that a user may select a forum hyperlink when the user loads the web page into browser 62. That is, forum hyperlink 1312 may be configured in such a way that it is activated when the web page it is embedded in is loaded. For example the forum hyperlink could be a method tag that provides a hidden link to join a specific forum when the web page is loaded in browser 62.
Public Audio Forum Web Tours
Another advantage of the present invention is that novel methods may be used to allow a number of users to access numerous forums as a group. One such method is known as a public audio forum web tour. Essentially, a public audio forum web tour is a novel extension of the URL-centric forum feature and the public forum concept discussed above. This method allows participants in a public audio forum web tour to engage in an audio conversation while "touring" web sites specified by a tour leader, and in the process join the forum(s) associated with each web site toured.
To start a public audio forum web tour, a user with the URL-centric forum feature enabled on their Internet browser 62 invites other users, who have logged onto forum controller 100, to join a public audio forum web tour. The user issuing the invitation is known as the tour leader; whereas, the user accepting the invitation is know as a tour participant. When a user accepts an invitation to join a public audio forum web tour, Internet browser 62 is launched by URL module 66 with the URL-centric forum feature enabled. If Internet browser 62 is already running, URL module 66 will enable the URL- centric forum feature. Additionally, URL module 66 will set URL address 1002 of the tour participant to that of the tour leader. More specifically, the tour participant's URL address 1002 of Internet browser 62 will be synchronized with the tour leader's URL address 1002 of Internet browser 62. This action triggers the URL-centric forum feature discussed above. Essentially, this means that the user joins the forum associated with URL address 1002. Participants in a public audio forum web tour can then engage in conversations with each other, with participants of other public audio forum web tours, and with users who are forum participants but not public audio forum web tour participants.
At any point during the public audio forum web tour, the tour leader can invite additional users, or tour participants, to join the public audio forum web tour. The tour leader can invite a user from forum participant window 304 or from contact list 306 to join the tour leader's public audio forum web tour.
Each time the tour leader's URL address 1002 of Internet browser 62 is changed, the other participants receive a URL update. URL module 66 applies the URL update to URL address 1002 of Internet browser 62. As noted above, this triggers the URL-centric forum features discussed above.
Another feature of the public audio forum web tour is that the participants are aware of each other by virtue of forum participant window 304, hence the name public audio forum web tour. Specifically, an informative icon is included with each participant' s user name displayed in forum participant window 304 that indicates to other participants that the user is both a member of the forum associated with URL address 1002 and a member of the same public audio forum web tour.
A tour participant may freely leave and rejoin an audio forum. For example, if during a public audio forum web tour URL address 1002 is changed on a participant's Internet browser 62 by the participant, the new URL address will be accessed; however, the participant will no longer be a member of the audio forum with which the other participants of the public audio forum web tour are a member of. This does not however remove the participant from the public audio forum web tour. Thus, the participant can simply move back to the last URL address specified by the tour leader to reestablish audio communication with the other public audio forum web tour participants. This step that can be executed in any number of ways. For example, the participant can press the "Back" button on Internet browser 62, which will change URL address 1002 to the most recently accessed URL address. The user can also manually enter the public audio forum web tour's current URL into URL address 1002. Regardless of which technique is used, the participant will rej oin the correct forum and reestablish audio communication with the other public audio forum web tour participants. Even if the participant does not attempt to rejoin the public audio forum web tour's forum, the participant will still receive a URL update from the tour leader. Consequently, URL module 66 will automatically synchronize the participant's URL address 1002 with that of the tour leader's. However, forum participant window 304 will not list the other public audio forum web tour participants when a participant modifies URL address 1002 as illustrated in FIG. 14 (note the absence of the tour leader, which is indicated in this example by the inclusion of a flag on the bus icon). Instead, forum participant window 304 will list members of the forum associated with the new URL. Although, the participant will still see the icon indicative of a public audio forum web tour next to their name regardless of what forum they are a member of.
Advantageously, any tour participant can withdraw from the public audio forum web tour while it is in progress without affecting the other participants. Participants can
withdraw from a public audio forum web tour in a number of ways. For example, the participant can close Internet browser 66 or GUI 34, un-check Enable check box 1006, or press Leave button 1706 (FIG. 17). However, a public audio forum web tour can not, in a preferred embodiment, continue without the tour leader.
The following example illustrates the utility of a public audio forum web tour. FIG. 15 illustrates a GUI 34 that may be used by a user to participate in a public audio forum web tour. If a user desires to invite another to join a public audio forum web tour, the user can select a potential participant by, for example, right clicking on an entry in contacts list 306 or in forum participants window 304.
FIG. 16 illustrates an invitation 1600 that may be used by a user to join a public audio forum web tour. Note also that the invitation specifies both the tour leader 1602 and the starting URL 1604 of the public audio forum web tour. Note that the starting URL for the tour participant can also be the current URL of an on going public audio forum web tour. The tour participant can accept the invitation in this example by pressing Accept Invitation to Web Tour button 1606. Alternatively, the user can decline the invitation by pressing close button 1608. Should the tour participant accept the invitation, URL module 66 will launch Internet browser 62 and enable FireTalk on the Web as illustrated by FIG. 17. Note that Enable check box 1006 has been automatically checked, which indicates the URL-centric forum feature or, FireTalk on the Web in this example, has been activated. Also note that Internet browser 62 has "FireTalk on the Web" in title bar 1700, which indicates that this Internet browser is being tracked using standard hooks as discussed above. Further still, URL address 1002 has been set to match the URL specified in the invitation.
GUI 34 of FIG. 17 indicates that the tour participant, in this example, "blossom" has joined a web tour being led by "lono." Their participation in a audio forum web tour is indicated by bus icons 1702 next to their respective entries in forum participant window 304. That lono is the tour leader is indicated by flag 1704 included on bus icon 1702 next to his entry. While both blossom and lono are listed in forum participant window 304, they can engage in an audio conversation, h the specific example illustrated in FIG. 17, lono and blossom may want to discuss the latest automobile models available at the current web site.
Lono can lead blossom to another web site by changing URL address 1002 in Internet browser 62. If lono takes this course of action, the hooks tracking Internet browser 62 will notify URL module 66 of the change. URL module 66 will, among other things, pass the new URL to blossom. Once this occurs, URL module 66 of Internet browser 62 running on blossom's computer (and illustrated in FIG. 17) will be changed accordingly.
Blossom can exit the public audio forum web tour being led by lono at any time. Numerous method of exit are possible. For example, blossom can un-check Enable check box 1006. This step would result in blossom' s exit from the public audio forum web tour, but would also disable the URL-centric forum feature. Thus, blossom would not join forums associated with URL address 62, but would still be able to browse the Internet using Internet browser 62. Blossom can also press Close button 1708. This step would result in blossom's exit from the public audio forum web tour, but would also result in the disabling of the URL-centric forum feature and the closing of Internet browser 62. Other options for exiting a public audio forum web tour in this example include pressing Leave button 1706 and closing GUI 34.
In another example illustrated by FIG. 18, lono and blossom are again participating in a public audio forum web tour, though in this example, blossom is the tour leader. Note the entry for "btc" in the forum participant window 304. Since btc is listed in the forum participant window without a bus icon, we know that btc is a member of the forum associated with URL address 1002 in both blossom and lono's Internet browser 62, but is not participating in their public audio forum web tour. Nevertheless, in this embodiment, blossom, lono, and btc can engage in an audio conversation while viewing the same web page. As noted above, blossom can invite btc to join the public audio forum web tour that he is leading or leave btc behind if and when the next site is accessed. It is also worth noting that in this embodiment of the invention, btc will see an entry for both blossom and lono in her forum participant window 304; however, their entries will not include a bus icon. In other words, btc will not know that blossom and lono are participating in a public audio forum web tour. On the other hand, it is possible that btc is participating in a separate public audio forum web tour since it is possible that she has strayed from her public audio forum web tour (which explain' s the absence of other entries in forum participant window 304).
The general nature of the public audio forum web tour feature has now been disclosed. Attention now rums to a more detailed discussion of the processing steps, necessary in a preferred embodiment of the present invention, to support the public audio forum web tour feature on system 1900, as shown in FIG. 19.
FIG. 19 illustrates a network 1900 that may be operated in accordance with this invention. Note the similarity of network 1900 to network 1300 illustrated in FIG. 13. Where the two figures overlap, the operation is the same; however, FIG. 19 includes additional components. To begin with, memory 32 includes web tour database 1904. Web tour database 1904 can be used to store, among other things, tour leader IDs, web tour participant lists, and a web tour flag. The need for web tour database 1904 will become apparent in the following paragraphs. Additionally, memory 44 includes web tour list 1907. Web tour list 1907 is used to store information relating to web tours 1908- 1 through 1908-T. The entry for each web tour 1908 includes web tour name 1910, public or private designator 1912, description 1914, URL 1916, start time 1918, public or private designator 1919, and participant 1 1920-1 through participant S 1920-S. The web tour information listed above serves only as an example of what can be included and in no way limits the scope of this patent to the listed items. Audio forum web tours designated as "private" are private in the sense that GUI 34 will not list in forum participant window 304 non-participants accessing the same uniform resource location. Audio forum web tours designated as "public," on the other hand are public in the sense that GUT 34 will list in forum participant window 304 non-participants when non-participants and participants of the public audio forum web tour access the same uniform resource location. The importance of web tour list 1907 will become apparent in the following paragraphs.
FIG. 19 also includes Web Tour Hyperlink 1926. As will be made clear below, Web Tour Hyperlink 1926 is a web page hyperlink stored on a computer accessible by users. When Web Tour Hyperlink is selected, the user begins the process of joining an audio forum web tour. It will be appreciated that web page 1310 may have a plurality of Web Tour Hyperlinks 1926, each pointing to a different audio forum web tour 48. Furthermore, there may be a plurality of web pages 1310 that each have the same Web Tour Hyperlinks 1926. It will also be appreciated that a user may select an audio forum web tour hyperlink when the user loads the web page into browser 62. That is, forum
hyperlink 1312 may be configured in such a way that it is activated when the web page it is embedded in is loaded. For example the audio forum hyperlink could be a method tag that provides a hidden link to join a specific audio forum web tour when the web page is loaded in browser 62.
FIG.20 illustrates the processing steps that are used in accordance with apreferred embodiment of the invention when a user is invited to j oin a public audio forum web tour. The processing steps begin with a user inviting another user to join a public audio forum web tour (step 2000). Once a user opts to send an invitation, a message is sent to the tour participant across a computer network. Persons skilled in the art will recognize that a computer network includes the Internet, intranets, etc. The message however does not necessarily go directly to the tour participant. As noted above, security on the web is often of great concern. Accordingly, in apreferred embodiment, the message is sent first to the server. The server then forwards the message to the user by reference to the user's ID, which is available to other users and will be included in the invitation. However, for the sake of simplicity, the flow charts do not include the intermediate step of routing messages between the tour leader and the participants through controller 100, though as noted above, this step does occur in the preferred embodiment. Additionally, the invitation should include the URL at which the tour participant will begin the tour and the tour leader's user ID. However, additional information can include a session ID, which is a unique ID provided when a user logs onto forum controller 100, the current participants in the public audio forum web tour, a title for the public audio forum web tour, and a general description of the public audio forum web tour. Other possibilities exist of course, and all are within the scope of this invention. Once the invitation message arrives at the tour participants computer, the user has the option of accepting or declining the invitation (step 2002). Should the user accept the invitation, an acceptance message is sent to the tour leader (step 2004). hi a preferred embodiment, an internal flag will be set in the user's computer memory indicating that the user is a participant in a public audio forum web tour (step 2006). Though not necessary to this invention, the web tour flag allows the user's computer to ignore web tour related messages erroneously or maliciously sent from other users. Another part of step 2006 is the storing of the tour leader's ID. This too is not necessary to the invention, but does offer additional protection, i.e., the tour leader ID included with other web tour related messages can be
compared to the stored tour leader ID. If the two do not match, the message can be safely ignored. The next step is to set URL address 1002 according to the URL included with the invitation message (step 2008). URL module 66 will first determine whether Internet browser 62 is currently running. If not, URL module 66 will launch Internet browser 62 with the URL-centric forum feature enabled. If on the other hand Internet browser 62 is currently running without the URL-centric forum feature enabled, URL module 66 will enable the URL-centric forum feature. Once Internet browser 62 is running, URL module 66 will insert the new URL into URL address 1002 of Internet browser 62. URL module 66 will then send a request to exit the current forum (should one exist) to controller 100 (step 2010) and controller 100 will respond by removing the user from the current forum (step 2014). URL module 66 will then send a request to join the forum derived for the new URL to controller 100 (step 2012). Controller 100 will add the user to the derived forum (step 2016). The process for joining forums is more fully explained above and illustrated in steps 1108-1118 of FIG. 11.
Once the user is a member of the derived forum, he or she can engage in audio conversation with other forum members and public audio forum web tour participants (with the same URL). Once the tour leader has received the acceptance message, a public audio forum web tour participant list on the tour leader's computer is updated (2018). The public audio forum web tour participant list is used by the tour leader and tour participants alike to update forum participant window 304. In particular, this list is used to determine which if any of the participants listed in forum participant window 304 are part of the user's public audio forum web tour. If so, GUT 34 will include icon 1702 next to the participant's entry to indicate participation in the public audio forum web tour.
FIG.21 illustrates the processing steps that are used in accordance with apreferred embodiment of the invention when a tour leader sends an updated public audio forum web tour participant list to participants of the public audio forum web tour. The processing steps begin with the tour leader sending an updated public audio forum web participant tour list to the participants of the public audio forum web tour (step 2100), and are followed each time the list is updated by a participant being joined with or withdrawn from the public audio forum web tour. In the preferred embodiment, the tour leader sends the public audio forum web tour participant list to each participant individually. Alternatively, this list can be stored on controller 100. In this alternative embodiment,
controller 100 will add and remove participants as needed and forward an updated list to the participants and the tour leader alike. In step 2102, the web tour flag is checked to determine whether the user is currently engaged in a public audio forum web tour. Next, the stored tour leader ID is compared to the tour leader ID included with the newly arrived message (step 2104). Again, steps 2102 and 2104 are not necessary to this invention, but are beneficial in certain respects. If the web tour flag is set and the tour leader IDs match, the public audio forum web tour participant list on the user's computer is updated (or created if the list is being received for the first time by a new participant) and used to update the user's forum participant window 304 (step 2106). If however, either the web tour flag was not set or the tour leader IDs do not match, the message is ignored (step 2108).
FIG. 22 illustrates processing steps that are used in accordance with a preferred embodiment of the invention when a tour leader modifies URL address 1002 on Internet browser 62. The processing steps begin with the tour leader modifying URL address 1002 (step 2200). The modification can be the result of a number of actions (selecting a hyperlink, pressing the "back" button on Internet browser 62, manually entering a new URL in URL address 1002, selecting an entry from the "Favorites" list in Internet browser 62, etc.), the choice of which is irrelevant to the invention. The next step is the tour leader sending a request to exit the current forum to controller 100 (step 2202). Upon a URL change, URL module 66 is alerted. The server responds by removing the tour leader from the current forum (step 2220). Next, URL module 66 sends a request to controller 100 requesting that tour leader be added to the forum derived from modified URL address 1002 (step 2204). Once this message is received by controller 100, the tour leader is added to the derived forum (step 2222). Again, this basic URL-centric forum functionality is more fully described above. Additionally, the new URL is individually sent to the users listed in the public audio forum web tour participant list (step 2206). Once this message is received, the web tour flag is checked to determine whether the user is currently engaged in a forum (step 2208). Next, the stored tour leader ID is compared to the tour leader ID included with the newly arrived message (step 2210). If the web tour flag is set and the tour leader IDs match, URL module 66 uses the hooks tracking Internet browser 62 to insert the new URL into URL address 1002 (step 2212). This insertion triggers a standard URL-centric forum feature response. URL module 66 sends a request
to exit the current forum to controller 100 (step 2214) . The server responds by removing the user from the current forum (step 2220). Next, URL module 66 sends a request to controller 100 requesting that the participant be added to the forum derived from modified URL address 1002 (step 2216). Once this message is received by controller 100, the participant is added to the derived forum (step 2222). If however, either the web tour flag was not set or the tour leader IDs did not match, the message is ignored (step 2218).
FIG. 23 illustrates processing steps that are used in accordance with a preferred embodiment of the invention when a participant elects to exit a public audio forum web tour. The processing steps begin with the participant electing to exit the public audio forum web tour by any of the means described above. Regardless of which is used, the following processing steps may be used. After the request to exit is made, a message is sent to controller 100 requesting that the user be removed from the current forum (step 2300). Additionally, a message is sent to the tour leader requesting that the user be removed from the public audio forum web tour as well(step 2302). Also, the user's web tour flag will be reset, indicating that the user is no longer a web tour participant, and the tour leader's ID will be deleted (step 2304). Persons skilled in the art will recognize that the precise order of steps 2300-2304 is not important to this invention. Any order will achieve substantially the same results. Once controller 100 receives the message requesting that the user be removed from the forum, the user will be removed (step 2306). Once this message is received by the tour leader, the user's entry will be removed from the public audio forum web tour participant list stored on the tour leader's computer (step 2308). The tour leader then takes the step of forwarding the updated public audio forum web participant tour list to the participants. This process is described above and illustrated in steps 2100-2108 of FIG. 21.
Private Audio Forum Web Tours h addition to the public audio forum web tour described above, there is another method for allowing a number of users to access numerous URLs as a group. This method is known as a private audio forum web tour. Essentially, a private audio forum web tour is a novel extension of the public forum concept discussed above. This method allows participants in a private audio forum web tour to engage in an audio conversation while "touring" web sites specified by a tour leader. However, unlike participants in a
public audio forum web tour, private audio forum web tour participants are only "visible" (i.e., capable of exchanging text, audio, URLs, etc.) to other participants of the same private audio forum web tour. Thus, when participants in a private audio forum web tour are viewing and discussing a particular URL, participants of a separate private audio forum web tour, participants in the forum derived from the URL address 1002, and participants in a public audio forum web tour who are currently viewing the same URL in Internet browser 62 are not listed in forum participant window 304. Similarly, private audio forum web tour participants are not listed in the forum participant window 304 of participants in the forum derived from URL address 1002, participants in a public audio forum web tour, and participants in a separate private audio forum web tour.
Before a private audio forum web tour can be selected however, a tour leader must make it available. In the preferred embodiment, there are a number of methods by which such information can be made available. One method includes listing such tours on a web server accessible by potential participants and tour leaders alike, hi a preferred embodiment, tour leaders can access this list in order to add entries for upcoming web tours. The entries will ideally include sufficient information to allow a potential participant to make an informed selection. At a minimum, the information will include a name and starting time for the private audio forum web tour and a tour leader ID. However, additional information can include without limitation a password requirement indicator, a password, a starting URL, a description, a category, a list of scheduled web sites, special guest host identifier, and a list of participants scheduled to join. Of course, additional information is possible and any combination of such is within the scope of this invention.
Once private audio forum web tours are listed in this fashion, users can access the list through, for example, the Internet, h a preferred embodiment, users will be able to search for a particular type of private audio forum web tour by key word search or following hyperlinks related to increasingly specific types of tours until the desired tour is located. For example, a user can search for a private audio forum web tour hosted or led by an employee of a company from which the user desires to make a purchase. More specifically, a user might be interested in a tour of web sites, or specific areas within a single web site, relating to, for example, real estate property within a given region that is to be led or is being led by a real estate agent affiliated with the web site(s) included in
the private audio forum web tour. Once a selection has been made, the user can request to join the desired private audio forum web tour using any standard selection method (such as double clicking with a mouse cursor on a hyperlink) that activates the processing steps necessary for a user to join a private audio forum web tour.
There are a number of methods by which the list of private audio forum web tours can be made accessible to users. One method is through the use of standard HTML documents. Another is through the creation of a down loadable j ava script. Still another possibility is a modification of GUI 34 such that a window similar to the forum window 400 (FIG. 4) can be launched to display a list of private audio forum web tours, hi this embodiment, a modified forum window 400 will be provided by controller 100 with a list of private audio forum web tours. hi apreferred embodiment, users will only be able to join private audio forum web tours that are currently in progress, hi another embodiment however, users will be able to j oin a private audio forum web tour before it actually begins, i this embodiment users joining before the tour begins will have an entry created in a private audio forum web tour participant list. Once the forum begins, users, who are logged on to forum controller 100, will immediately begin receiving data related to the private audio forum web tour.
A private audio forum web tour is similar to a private forum (as discussed above) in that participants are able to engage in an audio conversation, view a list of participants of the same private forum, engage in text chat, send instant messages, etc.; however, the private audio forum web tour concept is extended in that participants will also receive URL updates from the tour leader each time the tour leader's URL changes. Once the URL update is received by a participant, the participants' Internet browser URL will be adjusted accordingly.
As indicated above, there are numerous novel applications for private audio forum web tours. One such example is the use of a private audio forum web tour to sell cars. For example a car sales person can sign on to controller 100 using the interface illustrated in FIG. 8 or a web based form. Either way, the sales person will then be able to create an entry for a private audio forum web tour due to begin immediately. The sales person can optionally provide data such as the automobile manufacturer, automobile class (e.g., minivans, luxury, sports, etc.), regional sales locations, etc.. A person interested in purchasing an automobile or simply obtaining additional information can then access the
list of private audio forum web tours and search for specific attributes optionally provided by the sales person. Once a match is found, the participant can then join the selected private audio forum web tour using any of the methods discussed above. hi this example, GUI 34 (FIG. 17) is used as a convenient means for utilizing this invention. If GUI 34 is not running when the user (blossom in this example) begins the process to j oin the tour, it is launched automatically using standard Internet browser tools such as Java scripts. If GUI 34 was not running when the process to join the tour was begun or the user had not already logged on to controller 100, the user will then be required to logon to controller 100 using the data entry window illustrated in FIG. 8. If the private audio forum web tour is password protected (unlikely in this example), the user will also be required to submit a password for access to the private audio forum web tour. If the password provided is correct, or a password was not required, the user will become a participant in the private audio forum web tour. In an alternative embodiment, the tour leader (lono in this example) will have to allow the user to join the private audio forum web tour. This embodiment is advantageous in that a tour leader can limit the number of participants of the web tour to as few as one (not including the tour leader). If the tour leader authorizes the user's participation, the user will then become a participant in the private audio forum web tour. All participants and the tour leader will then receive from controller 100 an updated list of tour participants. The updated list of tour participants will be used to update forum participant window 304. hi this example, icon 1702 will be included with each entry in the forum participant list. When the tour leader receives this update, the new list will be compared to the old tour participant list stored in the tour leader' s computer memory. Any new participants will receive from the tour leader the tour leader's current URL. This URL, once received, will be inserted into URL address 1002 of Internet browser 62 by URL module 66 on the new participant's computer. If by chance, Internet browser 62 is not running on the new participant's computer, URL module 66 will launch it automatically. Additionally, URL address 1002 will default to the URL specified in the message from the tour leader. At this point, blossom is ready to engage in at least an audio conversation with lono the tour leader about the contents of Internet browser 62 - in this example an automotive web site (FIG. 17). Advantageously, the car sales person will be able to provide information to the customer that is not easy to convey when a customer is viewing the web site without the
benefit of this invention. Additionally, the car sales person can direct the flow of web pages accessed by the customer thus ensuring that only highly relevant web pages are accessed. Each time lono modifies her URL, the new URL is sent to blossom for insertion into blossom's Internet browser 62. Furthermore, the car sales person can even take the customer on a tour of various automobile financing web sites in order to complete the sale. Another key advantage of a private audio forum web tour is that only participants in the web tour will be able to hear or speak to the participants of the web tour. Thus, the participants will not be interrupted. And as noted above, the tour leader can limit the number of tour participants to just one. In the example of an automobile sales, this might be advantageous since a sales person will then be able to focus on a single individual or buyer. Another advantageous aspect of this invention is a tour participant's ability to easily terminate the private audio forum web tour.
In another example, the user will select a private audio forum web tour from an advertisement. More specifically, a user will select a hyperlink 1926 (FIG. 19) related to a private audio forum web tour. Once hyperlink 1926 is selected, by for example double clicking with a mouse cursor on the hyperlink 1926, the user will join a private audio forum web tour similar to the one discussed above, h a preferred embodiment, a sales person affiliated with the subject of the advertisement will be the tour leader and guide the user through a tour of one or more web sites related to the subject of the advertisement.
The general nature of the private audio forum web tour feature has now been disclosed. Attention now turns to a more detailed discussion of the processing steps, necessary in a preferred embodiment of the present invention, to support the private audio forum web tour feature on system 1900 (FIG. 19).
FIG.24 illustrates the processing steps that are used in accordance with apreferred embodiment of the invention when a user submits a new entry to the list of private audio forum web tours. The processing steps begin with the tour leader accessing a private audio forum web tour submission form (step 2400). In apreferred embodiment, this form will be on a server accessible by the Internet or other computer network. Once the form is accessed, the user will submit information necessary to adequately list the web tour (step 2402). hi a preferred embodiment, this information can include a forum name, the URL at which the web tour will begin, the tour leader's user ID, current participants, a
password flag, and a general description of the web tour. Other possibilities exist of course, and all are within the scope of this invention. In addition to web tour information, the tour leader is required to submit a user ID and password in order to logon to controller 100 before the information will be accepted. Upon confirming the user ID and password combination, controller 100 will then add the submitted web tour to the private audio forum web tour participant list (step 2404). The updated list will then be displayed for a private audio forum web tour selection by users (step 2406).
FIG.25 illustrates the processing steps that are used in accordance with apreferred embodiment of the invention when a user selects and joins a private audio forum web tour. The processing steps begin with the user viewing a list of entries submitted by tour leaders (step 2500). In a preferred embodiment, the selection will be made directly from a web page (step 2502). When the selection is made, a Java script maybe launched. The script will direct an executable module (e.g., an Active X control) to write a file to a directory accessible by GUI 34 on the user's computer. This file will contain at least the tour leader's ID, the private audio forum web tour name, and a password flag - with this information originating from the web page from which the private audio forum web tour was selected. The script will then direct the executable module to send a message (e.g., Dynamic Data Exchange message) to GUI 34 instructing it to send a request to join the selected private audio forum web tour to controller 100.
If GUI 34 is not already running, the message will launch GUI 34, which will prompt the user to logon to controller 100. Once GUI 34 is launched and the user is logged on to controller 100, GUT 34 will read the file containing the private audio forum web tour information and use it to create a message to be sent to controller 100 requesting it to join the user with the selected private audio forum web tour (step 2504).
Persons skilled in the art will recognize that the executable module can alternatively send the private audio forum web tour information in a Windows message to GUI 34 instead of writing this information to a file. Additionally, persons skilled in the art will recognize that DDE messages are but one option available to programmers for sending messages between computer programs. If the password flag indicates that the selected private audio forum web tour requires a password for access, the user will be prompted for a password before the message is sent. GUI 34 will also take the step of storing the ID of the private audio forum web tour leader (step 2506). This step is not
necessary to the invention, but can be a useful security measure in that subsequent messages from the tour leader will be authenticated by comparison of the tour leader ID included in the message with tour leader ID stored on the user's computer. Once the message requesting to join a forum is received, controller 100 will determine if a password is required to join the private audio forum web tour (step 2508). If so, the password submitted with the request is compared by controller 100 to a stored password (step 2510). If the password is correct, or if no password is required, the user is added to the private audio forum web tour (step 2512). Controller 100 will then update a private audio forum web tour participant list (step 2514). If the password submitted by the user is not correct, controller 100 will send a rejection message to the user (step 2516). Upon receiving this message, GUI 34 will display the rej ection to the user (step 2518) and delete the stored tour leader ID (step 2520).
FIG. 26 illustrates the processing steps that are used in accordance with another embodiment of the invention when a user selects and joins a private audio forum web tour. The processing steps begin with the user viewing a list of entries submitted by tour leaders (step 2600). h a preferred embodiment, the selection will be made directly from a web page (step 2602). When the selection is made, a Java script maybe launched. The script will direct an executable module (e.g., an Active X control) to write a file to a directory accessible by GUT 34 on the user's computer. This file will contain at least the tour leader's ID. The script will then direct the executable module to send a message (e.g., Dynamic Data Exchange message) to GUI 34 instructing it to send a request to join the selected private audio forum web tour to the tour leader. If GUI 34 is not akeady running, the DDE message will launch GUI 34, which will prompt the user to logon to controller 100. Once GUI 34 is launched and the user is logged on to controller 100, GUI 34 will read the file containing the tour leader ID and use it to create a message to the tour leader requesting it to join the user with the selected private audio forum web tour (step 2604). Once the message is received, GUT 34 (on the tour leader's computer / 1902-2) will determine if the tour leader's authorization is required (step 2606). If so, the tour leader will be prompted to grant or deny authorization for the user to join the private audio forum web tour (step 2608). If authorization is granted, or authorization is not required, a message containing the name of the private audio forum web tour will be sent to the user (step 2610). Upon receiving this message, GUI 34 will send a message to
controller 100 requesting it to join the user with the named private audio forum web tour (step 2612). hi a preferred embodiment, step 2612 is not visible to the user, or in other words, GUI 34 executes this step automatically. In alternative embodiments, the user can be prompted to grant authorization before this message is sent. Additionally, the tour leader ID will be stored for verification of subsequent messages from the tour leader (step 2618). Once controller 100 receives this request, the user is added to the selected private audio forum web tour (step 2614) and the private audio forum web tour list is updated (step 2618). If authorization is requested in step 2608 and the tour leader declines to grant it, a message will be sent to the user notifying the user of the tour leader's decision (step 2620) for display on the user's computer (step 2622).
FIG. 27 illustrates the processing steps that are used in accordance with another embodiment of the invention when controller 100 adds or removes a user from a private audio forum web tour. The processing steps begin with controller 100 sending an updated private audio forum web tour participant list to each participant (including the tour leader), though controller 100 does not need to know which tour participant is the tour leader (step 2700). Upon receiving this message, the tour participants and the tour leader update and display their respective private audio forum web tour participant list (step 2702). In a preferred embodiment, forum participant window 304 will be used to display a list of private audio forum web tour participants as well as forum participants. That the listed users are participants in a private audio forum web tour is indicated by the inclusion of icon 1702 with the user's entry, as illustrated in FIG. 17. When the message from step 2700 is received by the tour leader, the following additional steps take place. First, the updated private audio forum web tour participant list is compared to the outdated private audio forum web tour participant list (step 2704). Second, if new participants are included in the updated list, a message, including the tour leader's current URL and the tour leader's ID, are sent to each new participant (2706). Upon receiving this message, the user compares the stored tour leader ID with the tour leader ID included with the message (step 2708). If the two tour leader IDs match, the user's URL address 1002 of Internet browser 62 is set by URL module 66 to the URL contained in the message sent by the tour leader (step 2710) . If Internet browser 62 is not running, URL module 66 will launch Internet browser 62 with the URL defaulting to the URL contained in the message sent by the tour leader. Note however that when the user is participating in a private
audio forum web tour, URL module 66 does not send a message to controller 100 requesting it to join the user with the forum associated with the new URL. This step is only taken when the URL-centric forum feature is enabled, which is the case during a public audio forum web tour. In fact, in a preferred embodiment Enable check box 1006 is grayed-out and disabled while the user is participating in a private audio forum web tour. If the two tour leader IDs do not match, the message is ignored (step 2712).
FIG.28 illustrates the processing steps that are used in accordance with apreferred embodiment of the invention when the tour leader changes URL address 1002 of Internet browser 62. The processing steps begin with the tour leader modifying URL address 1002 (step 2800). The hooks tracking Internet browser 62 detect this change and notify URL module 66, which extracts the new URL from URL address 1002. A message including the new URL and the tour leader's ID is then sent to controller 100 for broadcast to the private audio forum web tour participants (step 2802). Upon receiving this message, controller 100 sends a message to each private audio forum web tour participant individually (step 2804). The only information needed in the message is the name of the private audio forum web tour. Controller 100 uses this information to access the correct private audio forum web tour participant list. Controller 100 then populates a message with at least the content of the message from the tour leader and the tour leader's ID for delivery to each participant listed in the private audio forum web tour participant list. Upon receiving this message, the user computer compares the stored tour leader ID with the tour leader ID included with the message (step 2806). If the two tour leader IDs match, the user's URL address 1002 of Internet browser 62 is set by URL module 66 to the URL contained in the message sent by the tour leader (step 2808). If Internet browser 62 is not running, URL module 66 will launch Internet browser 62 with the URL defaulting to the URL contained in the message sent by the tour leader. If the two tour leader IDs do not match, the message is ignored (step 2810).
FIG.29 illustrates the processing steps that are used in accordance with a preferred embodiment of the invention when a tour participant withdraws from a private audio forum web tour. The processing steps begin with the user requesting to exit the private audio forum web tour of which the user is a participant (step 2900). The user has at least two steps by which a request to exit can be made in a preferred embodiment. One step is to press Leave button 1706. The other step is to close GUI 34. After taking either step,
a message is sent to controller 100 requesting to exit the private audio forum web tour (step 2902). In a preferred embodiment, this message will include the tour participant's ID and the name of the private audio forum web tour. Additionally, the tour leader's ID, which was stored on the user's computer when the user joined the private audio forum web tour, is deleted (step 2904). It should be noted that the deletion of the tour leader's ID in steps 2904, 2520, and 2304 is not required to practice this invention, but is nevertheless beneficial. In alternate embodiments however, retaining this information may be beneficial to users. For example, this information can be used to compile a list of tour leaders who have lead the user.
Once the message sent in step 2902 is received, controller 100 will remove the user's entry from the private audio forum web tour identified in the message (step 2906). Controller 100 will then update the private audio forum web tour participant list (step 2908). The updated private audio forum web tour participant list is then distributed to the remaining participants as described above, and illustrated in steps 2700-2712 of FIG. 27.
Conclusion
While the forgoing attributes are illustrated using embodiments that include a server, the functions of the server may be sharply limited in the present invention and could even be included on user computer 22. The only requirement for the present invention is that forum controller 100 is accessible by the computers in the system so that user computers 22 know where to find the list. Once a user is added to a forum, the user may communicate with the other participants in the forum by using packets that have a formatted payload. The payload may designate the location of each forum participant. Furthermore, if one of the participants is behind a firewall, the formatted payload may include routing instructions to all other forum participants on how to contact the participant who is behind a firewall.
The foregoing descriptions of specific embodiments of the present invention are presented for the purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, obviously many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principals of the invention and its practical applications, to thereby enable others skilled in the art to best
utilize the invention and various embodiments with various modifications as are suited to the particular used contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents. h particular, the audio forum web tour embodiments described above indicate among other things that 1) users can join public audio forum web tours only by invitation and 2) users can join private audio forum web tours only by selecting them from a list of private audio forum web tours or a hyperlink related to a private audio forum web tour. However, alternative embodiments of this invention include private audio forum web tours in which users can be invited to j oin. Additionally, alternative embodiments of this invention also include public audio forum web tours accessible by selecting them from a list of public audio forum web tours or a hyperlink related to a public audio forum web tour. In fact, FIG. 19 clearly shows that web tour list 1907 includes a public/private web tour designation 1919.
The foregoing invention is intended for use in telephony systems such as the apparatus and method disclosed in "Apparatus and Method for Establishing An Audio Conference In a Networked Environment," attorney reference number 10053-013-999, filed 20 July 1999, which is incorporated by reference herein.