directs users who register for parties to perform functions hosted by other servers, such as server D at 209, and may provide functions to user who are directed to server C from other servers, such as server B
[0076] c. Multi-server installations as indicated by the server installation D at 209 may serve thousands of users, and may divide functions among separate servers at the installation. For example, one server may be a database server which handles registration; a second server may handle system accounting functions; a third may be act as an SMTP and POP email server host for handling invitations; and other servers may devoted to providing special functions or supporting specific ASP clients.
[0077] Thus, the user of a browser at 211 can establish a connection to any of the servers 205-209 via the Internet seen as 215. The user of the browser may, however, will be permitted to participate in only those "invitation only" parties to which he or she has been invited.
[0078] If the user of browser 211 is visiting the web site published by server A at 203, it receives web pages produced by the web server A without the participation of any other server. If the user of browser 211 visits the web site published by server B at 205, he may be referred by a link or redirection message to connect to ASP server C at 207 or server D at 208 which provides the a virtual party session without the browser user being aware that the party is being hosted on a server different from server B. If the user visits a web site hosted by server C at 207, functions such as registration and the principal virtual activities may be provided by the server C while specialized functions, such as special event multimedia experiences, may be hosted on another server such as server D at 209.
[0079] The software contemplated by the present invention contemplated by the present invention and described below is preferably capable of supporting all these potential configurations. To that end, the software must be designed for scalability at the server level. Each server should be able to service a simultaneous load of 250 active users, each of which may concurrently view pages and chat via HTML web pages using java-script or plug-in components with no significant delays in performance.
Server Requirements
[0080] The server(s) that support the functionality required by the present invention should have additional capabilities and characteristics that are briefly summarized in this section.
[0081] Tracking Mechanisms. The activity of each user is be tracked by using a unique identification code assigned to that user. This code may be used to access user identification information created during each session that includes:
[0082] a. the IP address used by the user during the session;
[0083] b. the date and time of the user's arrival at the sight (i.e., the date and time of the first HTTP request message from that user;
[0084] c. The referring URL, or a coded equivalent, with a default value if not listed, as specified in the first request message from the user; and
[0085] d. The entry point URL (or a coded equivalent, with a default value if not listed)
[0086] All additional user and session information stored on the server(s) is indexed by and accessible using this code. The code should be stored on the user's browser as a cookie enabling the user to be identified in later sessions. In the event that the user does not accept cookies, the code is generated and maintained by the server for the duration of the session.
[0087] URL Display. When server(s) that support virtual party functions place links or other visible URLs on generated web pages, these URLs preferably contain as little visible information as possible. In this way, the server can provide functionality to branded web sites without causing confusion in the mind of the user. For this reason, URLs containing user or session ID coded values are acceptable, but other data should be hidden. In general, scripts should make use of the POST mechanism rather than GET.
[0088] Uploading Support. The ability to provide graphical and multimedia content to individualize the experience of each virtual party is an important feature of the invention. Because users will be able to add binary content (including images, audio and video) to the data stored and published by the servers, the server platform must support this activity. Although FTP file transfers may be used, it si preferable to support uploads of binary data from users using full HTTP/ PUT support, with client-side browsing support.
[0089] Secure Server Support. The server should provide the secure transmission and storage of data supplied by users to protect their privacy, and hence should support the Secure Sockets Layer (SSL) during registration.
[0090] Template Based System. For reliability, speed and extensibility, the server(s) and software preferably employ a template-based approach to the generation of web pages rather than storing page definition data in a database. As users provide data to select preferences and customized entries, that data is used to modify standard HTML template pages, XML documents and/or other markups to generate web pages which may be viewed and approved by the designer, modified if desired, and then published to party visitors. Database-only representations of pages should be avoided.
[0091] Interface Standards. In order to promote interoperability with other sites, support easy importation of existing data for use in customizing the virtual parties, and to permit the use of standard development tools wherever possible, standard protocols should be observed wherever possible. The use of XML is particularly desirable for transmitting and storing since it enables user data to be readily integrated with standardized templates using XSL, permitting the content to be varied as desired by the user but still be readily validated and integrated with the functional components of the system.
[0092] Hierarchical Party Structure
[0093] Parties may be defined in parent-child relationships in which attendees who are invited to a parent party are allowed to define and sponsor "sub parties." Initially, a root or top-level parent party is defined by a server administrator on behalf of a party sponsor. As illustrated in FIG. 3, the parent party 301 may be defined to have two activity rooms
Rl at 303 and R2 at 305. Any visitor to the parent party 301 may define and create sub parties as illustrated in FIG. 3 by sub party 1 and 311 and sub party 2 at 313. Users may enter a parent party using an "invitation" (unique code) to the parent party, and if permitted by the invitation, may create a sub party. An invited user who creates a sub party is the host of that sub party and may define its characteristics.
[0094] Sub parties may selectively inherit the characteristics of the parent party. Sub party 311 when created by its host defined a new activity room R3 seen at 321 which may be entered only by guests entering sub party 1 (311). Sub party 1 also inherits and makes available new instances of rooms Rl and R2 as indicated at 323 and 324. The guest invited to the parent party who creates sub party 1 at 311 may modify (override and/or add to) the characteristics of the inherited rooms. Said another way, the rooms 303 and 305 defined for use by the parent party 301 are available as templates for optional use in a sub party, but need not be used as illustrated by the sub party 2 an 313 which used only room Rl inherited from the parent party as seen at 331, but did not use room R2.
[0095] Inherited rooms are entirely separate instances. Thus, visitors to room Rl at 303 in the parent party do not interact with visitors to the inherited room Rl at 323 in the sub party. Inherited rooms have the same decor, content, etc, as initially copied from the room of the parent party, but these room properties may be modified by the host of the sub party.
[0096] Each party or sub party comprises a set of connected, customized "party rooms", each of which is derived from the binding of a "room template", that supports "decoration" and "navigation", with an "activity template" that supports one or more "activities".
[0097] Room Templates
[0098] A room template defines the general format of rooms within a party. It includes space for the room name, party navigation, advertising, and allows for the binding of decorations. A room template is decorated with a single, party-wide "decoration scheme", which may consist of the following elements:
[0099] a. Page background (graphic)
[0100] b. Room name (font, color, background, text effects)
[0101] c. Navigation (font, color, text or button style, etc)
[0102] d. Additional fixed elements (e.g. a party entrance graphic, etc)
[0103] A room template may be implemented as a text file containing an HTML template web page with imbedded markers corresponding to the variable elements. When a user selects from the available element options, or uploads graphical elements in the form of .gif or .jpg files, the markers in the template are replaced by HTML segments which contain or reference the submitted information from the user. The resulting HTML page may then be displayed to the user.
[0104] Alternatively, the room template may take the form of an XML document containing standard content which is
merged using an XSL transformation with an XML document containing the variable content supplied by a user to form a new XML document which may then be converted into displayable form using a client-side or server-side XSL transformation to HTML form, or may rendered using a CSS stylesheet by the browser. Suitable XSLT transformation software are widely available and the techniques for transforming XML into displayable Web page format are described, for example, in Professional XML by Anderson et al, ISBN 1-861003-11-0, Wrox Press (3000). Complete specifications and documentation on XML, XSL, and CSS are available from the World Wide Web Consortium at www.w3c.org.
[0105] The room template provides built-in support for navigation between all party rooms, and to other site functions such as the User Console. If the parent has selected the RequireLink property, all sub-parties of that party will offer a link to the parent party in the navigation scheme. Users who are hosts and who have administrative access privileges view Web pages which further include a navigation link to the Party Management Console.
[0106] Activity Templates
[0107] An activity template defines the formatting and components for a particular activity and may be copied into or provided as an initial component of a room template.
[0108] The list of desired party rooms is defined at party creation time. Each room definition includes the name of the room and the activity that will occur within that room. Rooms are listed in alphabetical order by name for review by the party or subparty host. If the activity includes hostdefined or user-defined content, that content is stored on a per-room basis, not per-activity. In other words, if there are two rooms of the same type (e.g. a photo album), photos uploaded for display in one room will not be available in the other room.
[0109] User Console
[0110] The user console provides features and functions which are available to any user who is not entering, or actually engaged in a party. The user console allows a user to enter an invitation code to gain entrance to an invitationonly party, as well as an entry link to one or more public parties that do not require an invitation.
[0111] The user console is driven by two server-level configuration options. The first allows co-branding of the user console for that server. When set, this option places the co-branded partner's logo in a fixed position on the user console screen, providing equal exposure with the logo of the party's primary host. The second option limits the list of parties available to the user to those on the host's server, and not all those on the network of participating party servers.
[0112] Users may be required to login with a username and password. Although users are considered 'logged in' if they have entered an invitation code, they may not have provided desired registration information if they do not have a username and password. If desired, the user may be required to register before entering a party. Registration typically obtains information from the user such as: first
name, last name, address (two lines), city, state, country, zip or country code, email address and daytime telephone number. Some of these entries may be mandatory and the others optional. Mandatory data must be properly submitted before the user is allowed to proceed to view the list of available parties.
[0113] Once logged in, the user will be presented with a list of parties are available, including both open or "public" parties and parties to which the user has been invited as determined from the user's invitation code. If the user is logged in, and is a host for any party, the user console will display a link to the Party Management Console.
[0114] Party Management Console
[0115] The party management console permits the user to customize selected parties. Parent party hosts may access management features for their party, or for any sub-parties. Party hosts may access features only within their own sub-party. The party management console provides the following functions.
[0116] Create/Edit Party
[0117] Creating a parent party is only possible for a user with administrator access. Sub parties may be created only for parent parties that allow sub parties. Party creation consists of the following phases. When all the phases are complete, the party is 'activated' and can be entered by the hosts. Guests may not enter until the start time is reached.
[0118] Setting properties. The host is permitted to review and set properties using HTML forms-based exchanges with the server. Pull-down lists are used to allow selection of code values where possible. Direct input, when required, is appropriately validated.
[0119] Defining the invitation list. Invitations are transmitted to invited persons using a list of addressee names and their email addresses. The text of the invitation may be prepared by the user/host. Plain-text invitations are preferred since many potential recipients use email client software that does not support HTML email or graphics. The outgoing email typically includes a link to the URL for the server providing the entrypoint for the party or parties to be made available to the invitation recipient. The recipients "invitation code" may be specified in the email text, or may be made a part of the URL for automatic submission to the hosting server.
[0120] Selecting post-party activities. The party creator may choose to invite party hosts and attendees to engage in various post-party activities. One such activity is typically required of all visitors: a simple user survey. The party creator should be able to choose to offer this activity;
[0121] create the text for the post-party email, which will include a link to the survey script; and schedule the date/time to distribute the post-party email.
[0122] Selecting the decoration scheme. The party host is required to initially select one of the supplied decoration schemes. The administrator of the system creates an assortment of decoration schemes.
[0123] Selecting activities. Activity selection is performed for parent parties only. The party creator must define the activities that will be available to the party, and any subparties.
[0124] Creating the room list. This phase allows the host to define the party rooms they want in their party. This process includes:
[0125] Naming the room
[0126] Choosing the activity for the room
[0127] Setting parameters for the activity within that room
[0128] Optionally, organizing the rooms (if not organized, rooms are listed alphabetically)
[0129] Adding content to rooms. This phase allows the host to add content to activities within rooms. For example, photos may be uploaded and added to a photo gallery room, or add music files may be uploaded and added to an entertainment room.
[0130] Removing content. Users who are also hosts may remove content from activities within their party, or if they are parent-hosts, within any sub-party. When viewing content, such users see an optional "remove" link next to it.
[0131] Excluding Guests. For parties that require registration, hosts may block a particular user from entering the party. For parties that require a unique invitation code for each visitor, users presenting a blocked invitation code are denied the right to enter the party.
[0132] Party Activities
[0133] As used in this specification, the term "activities" broadly refers to a number of related structures and data, including but not limited to:
[0134] The software, templates and content to support the activity
[0135] The parameters for configuring the software that supports the activity
[0136] The URL for the activity on the supporting server
[0137] Specific modes of interactive information exchange with and between users, including those described below.
[0138] Chatting. Chatting can be, and preferably should be, supported by a variety of mechanisms which are selected based on the capabilities of the client. These mechanisms include HTML form page exchange as well as live connections implemented by Java or plug-ins. Chatting is preferably limited to users within a single activity room; that is, inter-room chatting is not supported. The mechanism that support chatting may, however, be shared by various rooms, and may be shared between multiple servers, if the party is hosted on multiple servers. Users in any chat room should be able to optionally enter a 'private' mode for 1-on-l chatting.
[0139] Photo album. The photo album activity allows browsing of multiple images, in JPEG and GIF formats. This activity is normally 'locked' so that images can only be added by the party hosts, but can be "unlocked" to permit image sharing among visitors.
[0140] Audio delivery. The audio delivery activity allows users to listen to music or other audio program segments. The user may select the file they wish to hear, in the format they wish to receive it. Like image delivery, the audio delivery activity is typically be 'locked' so that the recordings can only be added by the party hosts, but can be unlocked so that audio files may be posted in an activity room by a visitor for playback by other visitors to that room.
[0141] Video delivery room allows users to watch streaming video files. The user may select the file they wish to view, in the format they wish to receive it. This activity too may be 'locked' so that video files can only be added by the party hosts, or unlocked to permit sharing of video files among visitors to a given activity room.
[0142] When image, audio or video file sharing is permitted in an activity room, the host should actively discourage the posting of copyrighted works without permission from the copyright owner. For example, warnings should be displayed during the file upload stage to advise users that sharing copyrighted works without permission may constitute a copyright violation.
[0143] HTML Content Delivery. An HTML content delivery activity allows users to review static HTML such as a brochures. For example, the host may wish to create a resource room which features links to other HTML pages which are made available for party visitors.
[0144] Messaging. The messaging activity preferably supports several modes in which users can post text message to one another. A messaging activity may take one of the following forms:
[0145] Guest Book. Substantially all parties will feature a "guest book" activity in which visitors are requested to sign in and post comments. The guest book does not permit replies to be posted, nor does it permit later editing of the posted sign in message.
[0146] Threaded Bulletin Board. This activity provides a standard, "Use-Net" style discussion. Users may post new messages, or reply to old messages. Threads are tracked by subject. Editing of messages is not possible.
[0147] Buying. The buying activity presents a directory of products that the hosts will to expose to the party guests. Buying content is typically 'locked,' but could be unlocked to support a "swap room" exchange or "flea-market" in which users may sell or trade goods or services with other visitors to that room. Product directory entries preferably consist of a product photo, text description of the product, a price, and a link to a sales site supported by merchant software (i.e., shopping cart and credit card checkout capabilities). The sales site may be operated the host or a participating merchant.
[0148] Administration Console
[0149] The administration console is available only to users with administrator access and provides an entry point for the following functions:
[0150] Create Users. This function is similar to the Registration (and Update Registration) function noted earlier, but permits all user access properties to be edited, including the specification of user access level privileges granted to users.
[0151] Party Status. This feature displays the number of users on the server, broken down by party code, and an estimate of the relative load on the server.
[0152] Party Control. This feature permits the administrator to suspend or resume a party.
[0153] Party Termination. This function terminates a party and moves it's assets (including chat transcripts, text messages, guest books, image/audio and video files) into a storage area for archival purposes. Once a party has been terminated, it cannot be resumed via the Party Control above.
[0154] Content Monitoring. This function allows an administrator to review all content additions on a specified server, a specified party, or a specified party-room. All content supplied by either administrators or users may be reviewed, including all text (including chat and message postings), images, video and audio. The administrator will have the ability to remove any binary content, or to expel a user who posts improper content.
[0155] Reporting. The administrative console allows reports to be produces in the form of exported data files which summarize the activity and attendance at a party (including, optionally, all-sub parties), including: the number of visitors, the number of sessions, the average session length, the mean session length, cluster of session length, the number of advertising exposures, and a summary of activity usage.
[0156] Display Formats and Standard Features
[0157] Advertising Display. Parties are typically presented using frames, including a top from for holding rotating adverting banners or the like. A consistent "navigation bar" may be included in the same frame with the advertising content, or in a separate frame.
[0158] Survey Script. Visitors will typically be asked to complete a standard user survey questionnaire which collects data using input text boxes, boolean check boxes, or and option selectors (radio buttons). The standard user survey is completed by all party visitors and is used to aid the system administrator in measuring the utility of shared system features. User survey data should be stored in a separate database table, but entries include host, party, and user identification keys so that data may also be selectively reported on a per host, per party or per user basis.
[0159] Conclusion
[0160] It is to be understood that the illustrative preferred embodiment of the invention which has been described is merely illustrative of one application of the principles of the invention. Numerous modifications may be readily made by those skilled in the art without departing from the true spirit and scope of the invention.
What is claimed is:
1. The method of using the Internet to create and host a customized online gathering of participants comprising, in combination, the steps of:
providing at least one server computer connected to the Internet for communicating with a plurality of client computers operated by users which are also connected to the Internet,
storing at said server computer:
a) template data defining one or more template web pages, each of said template web pages implementing a predetermined activity in which said users may participate as part of said online gather,
b) an identification of said first user as the host of said online gathering,
c) a guest list accepted from said first user identifying a plurality of other invited users, and
d) customization data accepted from said first user,
combining said template data and said customization data to create customized web pages which together implement said customized online gathering,
establishing an authorized connection via the Internet between said server computer and each of said invited users that choose to participate in said gathering and,
responding to requests received from any given one of said invited users by transmitting to said given user one a requested one of said customized Web pages.
2. The method as set forth in claim 1 wherein said guest list includes the email addresses of at least some of said other users and further including the step of transmitting an invitation to said gathering to each of said email addresses.
3. The method as set forth in claim 1 wherein said customization data accepted from said first user includes the designation of a gathering type and wherein, in response to
said designation of said gathering type, said server computer automatically establishes a set of predetermined default values for said customization data which are combined with said template data to produce preliminary customized pages.
4. The method as set forth in claim 3 said gathering type is designated by the combination an occasion type and a theme associated with said occasion type.
5. The method as set forth in claim 3 further including the steps of accepting from said first user replacement attribute values which may be substituted for particular ones of said default values to modify said preliminary customized pages.
6. The method as set forth in claim 1 wherein said at least one server computer comprises a first server which acts as an application service provider for presenting said Web pages to users who access at least some of said Web pages using addresses supplied by a collaborating server computer.
7. The method as set forth in claim 1 wherein at least a given one of said template web pages implements an activity in which said invited users may communicate with one another, said method including the further steps of accepting contributed data from one or more of said other invited users, storing said contributed date on said server computer, and thereafter displaying at least selected contributed data as part of said given one of said Web pages.
|
