SYSTEM AND METHOD FOR INFORMATION AND APPLICATION DISTRIBUTION

Abstract: An Information and Application Distribution System (IADS) for distributing (500), initiating and allowing to play multi-player games via the Internet. The IADS employs known Internet protocols such as Internet Relay Chat (IRC), HTTP and email protocols, (e.g., X.25) to distribute and initiate computer games such that the application's executable and information concerning virtual locations for application interactions are automatically installed on local computer. Application distribution occurs through the transmission (500) and receipt of an "application object" which contains both the application executable code and the application invoker for invoking the application and linking multiple users in connection with the specific application. The application object includes functionality which allows the user's local computer to automatically set-up a socket connection with a central controller which controls interaction (530) and introduction between and among users.

Description: SYSTEM AND METHOD FOR INFORMATION AND APPLICATION DISTRIBUTION Field of the Invention This invention relates generally to software and information distribution and control. More particularly, this invention relates to the use of various communications protocols in order to distribute and enable applications and information through a public or private network. Background of the Invention The recent explosion of the Internet is due to many factors. One primary factor is the availability of practically unlimited information. Users can access data about companies, news events, sports, organizations and almost anything else under the sun. Another benefit of the Internet is its inherent ability to permit communication among users. Various standard protocols allow for information and resource exchange through email, chat rooms, as well as Usenet and other bulletin boards. A third major reason for the Internet's growth is the large number of free or low cost software applications which can be accessed through an Internet connection. There is a vast amount of software available on Internet servers which can be downloaded to the user's local computer and executed later. In addition, though on-line stores and other electronic commerce applications, it is possible for Internet users to purchase software and pay for it without ever placing a call or otherwise communicating with the software vendor. One particularly popular Internet resource is computer games which are made available on-line. In addition to free downloads, the Internet provides an avenue through which game players may play against each other. Some computer games are designed to allow such "network" play either through the Internet or though any other suitable communication medium. For example, players may play against each other through an intranet connection, via modem or, in some cases, via a non-real time email exchange of information. In most cases, including play through the Internet, it is generally required that each player have an executable copy of the game software locally at his or her computer. This may be accomplished by downloading the conventional computer object code from a server prior to game play. Additionally, it is possible to download Java code through a user's browser application. Once each player has a local copy of the game software, there are various methods through which users can "meet" other players and compete in the game. In the case of Internet based play, users can enter public or private chat rooms where suitable competitors may be located. Once all competitors are identified, a game may be commenced via a game server which controls the operation of play between and among the users. The game server communicates with each of the player's local computers through an Internet connection. It is the game server's responsibility to, for example, ensure that game rules are complied with and that all game actions and reactions initiated by one player are communicated to other players. While game play which is established and implemented in the above described manner is generally acceptable, there are various drawbacks. For example, prior to establishing game service, a user must locate the desired game on-line or, alternatively, purchase it in the store. Once the game has been downloaded or purchased, the user must manually complete the often detailed, frustrating and time consuming process of installing the game on the user's local computer. Following this, if the user wishes to initiate network (i.e. Internet) play, he or she must establish an Internet connection. Then the user must locate a suitable playing partner. In order to do this, the user is typically required to install a browser, "surf to a web site which allows the user to locate a suitable playing partner and then follow the steps on that site to find the partner. These steps may include entering a chat room and waiting for one or more suitable players to enter the same room. Alternatively, players may locate each other through pre-arranged bulletin boards or through email exchanges. Once the game competitors have all been located, various methods exist for establishing a connection between all players through a central game server. Unfortunately, users with varying interests and varying game favorites often have a difficult time locating each other. Additionally, many steps and a signifcant amount of time are required prior to the actual game play beginning. Because of these difficulties, it is arguable that online game play has not, as of this date, become as popular as it could. In addition to computer games, there are various other applications which inherently require communication among multiple individuals and which lend themselves well to establishing and maintaining that communication through the Internet or another flexible communications network. While some of these applications currently employ the Internet for inter-participant communication and processing, drawbacks similar to those encountered in connection with the game play example exist with respect to these applications as well. For example, commerce conducted over the Internet (sometimes known as "Electronic Commerce" or "E-commerce"), while an exciting and already expansive application, requires a user to locate an appropriate "on-line store" and then, within that store, locate an appropriate product prior to purchasing it. Searching the entire Internet for a store and then searching within that store can be a daunting task for the neophyte or even an experienced Internet user who has not previously purchased a product through an "on-line store". Summary of the Invention It is therefore an object of the present invention to overcome the drawbacks of the prior art. It is a further object of the present invention to provide a method and system which simplifies processes for interaction among individuals and/or entities which occur through a communications network. It is a still further object of the present invention to provide a method for multi-user interaction through a communications network which is directed to a specific transaction, interaction and/or application. It is an even further object of the present invention to enable the distribution of computer software, including computer games, through electronic mail, the Internet and other channels of electronic communication. It is another object of the present invention to enable the distribution of public and private information which may be specifically targeted to a subject area or a particular audience through electronic mail, the Internet and other channels of electronic communication. It is still another object of the present invention to provide a means for distributing, promoting and enabling the play of computer software games among multiple users in a multiple player game environment. These and other objects are achieved through the present invention which provides a system and method for information and application distribution and delivery. The system described herein is referred to as an Information and Application Distribution System (IADS) and is preferably embodied as a new Internet layer which may be used for a variety of purposes. In one embodiment, the IADS is employed to distribute, initiate and allow the play of multi-player games via the Internet. The IADS of the present invention employs known Internet protocols such as Internet Relay Chat (IRC), HTTP and email protocols (e.g. X.25) to distribute and initiate computer games in Java format such that the application executable and information concerning virtual locations for application interaction are automatically installed on a local computer. Application distribution occurs through the transmission and receipt of an "application object" which contains both the application executable code and the means for invoking the application and linking multiple users in connection with the specific application. The IADS of the present invention may also include a number of customized chat rooms which are designed to match players with other players of particular multi-player games or otherwise match users of multi-user applications. The chat rooms and the delivery methodology of the present invention circumvents many of the drawbacks encountered in matching players or users of other applications through prior art techniques. In a preferred embodiment, the chat room "lobby" executable is distributed via email and/or ICQ. Mass emailings of the application object to selectively targeted groups of customers may be made in order to distribute applications including computer games. All recipients of the application object may then redistribute the application object (and the included executable) to others. The application object includes functionality which allows the user's local computer to automatically set up a socket connection with a central controller which controls interaction and introduction between and among users. Introduction may occur through a lobby chat room application. Once the lobby chat room is entered, users can proceed from room to room in connection with their personal interests. Eventually, users can cause the application emailed to them as part of the application object to be launched and to be executed in a coordinated manner with other users. Brief Description of the Drawing Figure 1 is a block diagram illustrative of the Information and Application Distribution System (IADS) of the present invention; Figure 2 is a block diagram of the IADS of the present invention in an embodiment configured to permit the distribution, initiation and control of a multiple player computer game application; Figure 3 is a more detailed illustration of the central controller and data storage device components of the IADS of the present invention; Figure 4 is a flowchart illustrating the major steps in distributing, initiating and controlling a multiple player computer game application in a particular embodiment of the present invention; Figures 5 A and 5B are flowcharts illustrating the process of game distribution via electronic mail and subsequent game play in a preferred embodiment of the present invention; Figure 6 is a flowchart illustrating the detailed process of game play in a preferred embodiment of the invention; Figure 7 is a flowchart illustrating the detailed process of virtual value ticket account control according to a preferred embodiment of the invention; and Figure 8 is a flowchart illustrating the detailed process involved in a product purchase using the IADS in a preferred embodiment of the invention. Detailed Description of the Preferred Embodiments Figure 1 illustrates a preferred embodiment of the IADS 100 of the present invention. IADS 100 comprises multiple clients 110 connected to the Internet 150 through multiple Internet Service Providers (ISPs) 105. In actual practice there may be significantly more users connected to IADS 100 than shown. This would mean that there would be additional clients which are connected through the same ISPs shown or through other ISPs. Nevertheless, for purposes of illustration, the discussion will presume four clients 110 connected to Internet 150 through two ISPs 105. Clients 110 may be any computing device capable of accessing Internet 150 through ISP 105. Alternatively, some or all of clients 110 may access Internet 150 through a direct connection. In any event, clients 110 are preferably personal computers having a modem, a display, memory, various input devices and a central processing unit. In one embodiment, when IADS 100 is employed to distribute, invoke and control multi-player game play, clients 110 are preferably configured specifically for computer game play including, for example, enhanced graphics capabilities as well as processing speed. Alternatively, clients 110 may be special purpose devices optimized solely for game play but with the ability to access the Internet 150. Clients 110 each have resident thereon at least one form (and preferably multiple forms) of user interface (UI) applications 125. In the preferred embodiment of the present invention, UI applications 125 include Internet browsers such as Netscape Navigator™ or Microsoft Internet Explorer™ as well as at least one email application such as Microsoft Beyond Mail™, Netscape Mail™, Eudora Pro™ or the like. Additionally, clients 110 may also contain UI applications 25 that permit access to newsgroups, usenet applications, bulletin boards and IRC chat rooms. IADS 100 further includes central controller 115. Central controller 115 maintains a high speed, large bandwidth connection to Internet 150. Preferably, the connection is a Tl or T3 line although other connections may also be employed, albeit with degraded performance. Central controller 115 functions to permit clients 110 to interact with each other in connection with various applications, messaging services and other services which may be provided through IADS 100. Central controller 115 preferably comprises either a single server computer or multiple servers configured to appear to clients 110 as a single resource. Central controller 115 communicates with a number of databases which are resident on one or more data storage devices 160. The particular databases are described in further detail below. Various additional databases may also be made available as necessary depending upon the specific applications and services made available through IADS 100. In practice, the data in the databases stored on data storage devices 160 may be merged into a single database or into groups of databases as determined by a system administrator. Physically, the databases may or may not be co-located on the same storage device. As will be discussed in more detail below, the databases may include a software database which stores various software applications which are accessed by users stationed at clients 1 10. Examples of such applications include computer games, shopping cart applications for the purchase of goods and/or services, and work group applications such as word processing, database, accounting, inventory and graphic programs. The databases may also include an email database which may contain listings of email addresses that are located, indexed and stored as described below. As will be discussed in more detail below, various "application objects" containing references to applications and/or information as well as invocation and connection functionality may be sent to some or all of the email addresses stored in the email database. The databases may also include an information database which may contain a variety of different types of information. In the context of computer games which are administered by central controller 115, the information database may be referred to as a game database and may contain data indicative of prize structures and/or points available to system users. This will be discussed in further detail below. The present invention is next described in the context of a system for distributing, initiating and controlling computer games. This discussion is provided for illustrative purposes only in that IADS 100 may be employed in the distribution, initiation and/or control of a practically infinite number of applications as well as with a variety of communications functions and not just with respect to the particular embodiment described herein. With that in mind, Figure 2 illustrates IADS 100 configured so as to allow for a multiple player computer game application. Although the following discussion will be relevant to a multiple player computer game application, the configuration in Figure 2 could also be employed for other applications in accordance with the teachings of the present invention. Figure 2 shows two personal computers (PC's) 210a and 210b each having a connection to Internet 150 through an ISP 205a and 205b respectively and 220 respectively. Of course, both PC's 210 could connect to Internet 150 through the same ISP. Central controller 1 15 also has a connection to Internet 150 as described above. Central controller 115 communicates with one or more data storage devices 160 the latter being discussed in more detail below. Each of PCs 210 may be configured as a typical home based computer. Each of PCs 210 preferably contain email application 255, microprocessor 260 and memory 270. Email applications 255a and 255b need not be the same specific software so long as communication between them is according to standard protocols so that messages sent and received can be recognized. Alternatively, "application objects" which are transmitted may contain conversion utilities to address varying mail formats as discussed n further detail below. PCs 210 have at least one input device 220 for controlling the actions of PCs 230 and 240. Input device 290 may be a keyboard, joystick, touchpad, scanner or any similar device or combination of devices. Each of PCs 210 also include a display 215 which may be a CRT display as known in the art. Figure 3 illustrates the components of central controller 115 and data storage devices 160 in detail. Each of these components and its function is now described. The following description is provided in the context of the control and play of a computer game although the discussion is also applicable to the control and execution of any application using IADS 100. The central controller 115 functions as a game server and controls the start of the game, the game play and rules enforcement, monitors game progress, and player scoring, and determines the end of the game. Central controller 115, following game play may also award game points to players at the conclusion of the game. Additionally, central controller 115 acts as the interface for game play among multiple players and may also obtain various types of information from players and purchasers of games, game elements (such as game cards used in connection with game play) and associated game and products. Central controller 115 also provides certain information to players and purchasers. Information provided may include, for example, new games, advertisements, promotions, updates, and/or new user information for use in contacting the user. Information received and provided is stored in data storage devices 160. The central processing unit 330 provides overall control over the operations occurring on central controller 115. The cryptographic application 320 supports the authentication of communications between the service provider (which operates the multi-player game service and owns or leases central controller 115), players and/or purchasers and advertisers/vendors. In a preferred embodiment, two cryptographic applications are included; one for playing, monitoring, and distributing the games and another for e-commerce functions such as paying for purchases, ordering products, etc. The game encryption application is preferably RSA and is used to distribute games, monitor games, and trade virtual values. The cryptographic system employed for e-commerce functions is preferably based upon the Secure Electronic Transfer (SET) technology developed by VISA™ and MasterCard™. The operating system (OS) 315, read only memory 325, random access memory 335, clock 340, and player monitor and user analysis applications 345, provide support to CPU 330. In a preferred embodiment, OS 315 is either Unix based or Microsoft Windows NT™. Further, read only memory 325 includes a commercial BIOS for low level system control. Player monitor and user analysis applications 345 provide control over game play and administration. For example, these applications may serve to ensure only legal moves and actions (according to game rules) are made. Player monitor and user analysis applications 345 may also serve to control game scoring and award distribution. While the above embodiment describes a single computer acting as central controller 115, those skilled in the art will realize that the functions can be used on a distributed set of networked computers. Prior to a discussion of the various databases which may comprise data storage devices 160, a background regarding game play in general is provided. While the present invention may be employed with various applications in general and various computer games particularly, IADS 100 is particularly well suited for computer games involving multiplayer play and which involve particular "game elements" as a part of game play. For example, a game may involve the use of "game cards." Game cards are icons, a game playing capability, that represent elements of a game, e.g., by allowing players certain abilities in the game. A free set of game cards may initially be sent to a player. Additional cards can be purchased through Internet 100 using IADS 100. All cards are initially sent to the player with the free set "unlocked." In effect, this is controlled by maintaining a database (e.g. game database 355) which enables particular cards or other game elements on a player by player basis. Cards can be traded between players via central controller 115. All elements of the game are present in the executable included in the application object, but the players do not have permission to use some elements (e.g. cards) in the game until they have been "purchased." One example of a game that involves the use of game cards and which may be distributed, invoked and controlled through IADS 100 is the game entitled "Sanctum" offered by the assignee of the present invention. Returning to data storage devices 160 and the description of its possible components, data storage devices 160 store, update and provide information stored in various databases including, for example, player database 350, game 150, database 355, inquiry database 360, message database 365, audit database 370 and other databases 375. Data storage devices 160 may include one or more hard disk drives including magnetic and optical storage units, as well as CD-ROM devices or flash memory. Those skilled in the art will recognize that the storage of the database contents could alternatively be distributed over Internet 150 or over another network. Player database 350 stores information pertaining to what games and game cards (or other elements of game play) the player owns and can use, and selected player demographics. Inquiry database 360, contains a historical data set including information relevant to player and/or purchaser requests as well as various other types of information such as advertising preferences, purchasing history, the number and value of virtual value tickets (discussed below), and rating and ranking of players. The audit database 370 contains information relevant to the purchases made by the player such as payment history and status as well as fulfillment history and status. Game database 355 contains historical information concerning the particular games played such as when the games were played, game results, levels of play, etc. as well as associated player information. Message database 365 contains a summary of information, by player, concerning types of messages sent to the player and received by the player and/or purchases and any results of game play. The other databases 375 may contain any other type of information associated with the application including, for example, summary information, usage of virtual awards, advertiser information, usage statistics and the like. In order to provide multiple player game play through the Internet 150 under the control of central controller 115, a number of steps take place. Those skilled in the art will recognize that control could alternatively be accomplished through a peer-to-peer network or through other communications links. The steps associated with the game distribution and play are illustrated by the flowchart included as Figure 4. Each of the steps in Figure 4 is described generally at this point with further detail following below. First, at step 400, the process is initiated. In step 405, the user in question is sent (to PC 210 for example) an email containing the application/object code and the invoking functionality (the "application object") in the form described below. Upon receipt of this email, the user may open it to view its contents. The email preferably indicates (through a subject line or through content in the actual message) that the purpose of the email is to allow the recipient to participate in multiple player game play using IADS 100. If the user decides to participate in game play, the user must "activate" the application code received. This may be accomplished by "opening" the attachment or "launching" the attachment under a specified application. Upon invocation of the application object, the application object will cause a connection to central controller 115 to be established (step 410). The connection may be established through ISP using any one of many available protocols through Internet 150. The application object is preferably composed in Simple Message Transfer Protocol (SMTP) format or another format that permits conversion for email systems that do not recognize SMTP. Conversion routines may be included within the application object for use by the target email applications. Upon a user's decision to play a game, a small distribution and play application, which is a component of the application object will be initiated. The distribution and play application is in the form of an automatically self loading application program. This component of the application object invokes a connection to central controller 115 through Internet 150. The user clicks on the application represented by the executive file (.exe) for the application. This causes the distribution and play application to be stored on local hard drive and placed in a programming launch menu on client 110. The user may then launch the program and enter chat room which updates itself from server automatically. From there, the user can launch a game by initiating a JAVA application. The distribution and play application is preferably written in the C++ language so that JAVA applications can be easily launched. At step 415, after the connection has been established, central controller 115 may request particular information from the user prior to initiating any further activity. The information request may include a request for personal information or other information which may be useful in marketing the application (e.g. computer game). Additionally, central controller 115 may automatically capture particular information relevant to the user and/or PC 210 without action by or even the knowledge of the user. For example, central controller 115 may capture information relevant to the source of the application code (i.e. the initial source of the email and the routing involved in eventual transmission to this user.). The user responds to the information requests at step 420. Depending upon the responses and predetermined results based upon the responses, the user may or may not be permitted to proceed. In the event that the user is denied the right to proceed, central controller 115 may transmit a predetermined message describing the reason(s) for denial. Alternatively, if the user is permitted to proceed based upon his or her responses, the user may be placed in a chat room at step 425. Preferably, the first chat room is a "lobby" permitting the user to move from room to room until he or she locates players desiring to play the same game as user. The chat room is preferably invoked through a local application obtained from the application object emailed to the user at PC 210 and executed locally at PC 210. The chat room control application preferably resides at central controller 115 so as to permit other users who also have a local copy of the chat application to communicate between and among each other. For example, in this way, it is possible for a user at PC 210a to communicate via a chat room with a user at PC 210b. For example at step 430, users located at PC 210a and PC 210b may interact with each other in the chat room and perhaps determine that they both would like to play the computer game which is included in the application object which has been previously emailed to both users or which may have been e-mailed from one user to the other outside of the chat room. By selecting, for example, a button within the chat room, each of the users, under the control of central controller 115 are set up to play the computer game against each other. This occurs at step 435. Once the invocation procedures have been completed the users may participate in coordinated game play at step 440 under the control of central controller 115. It is also possible that other users may also have been located in the chat room and selected for inclusion in the multiple player game. Once play is completed at step 445, post application processing activities may proceed at step 450. Post application processing may include, for example, awarding of prizes or tickets and/or gathering of additional information. These activities are discussed in greater detail below. Figure 5A illustrates the detailed process for game play according to the preferred embodiment of the present invention. First, the user receives a copy of the application object from some other party as described previously (step 500). At this point, the user may, at his or her option, decide to authenticate the application object. Depending upon the source of the application object, the user may wish to ensure that the original source of the application object is from the service provider operating central controller 115 (or some other legitimate source). In the event the user does not desire to authenticate the application object, processing continues at step 530, discussed below. Otherwise, if the user does desire to authenticate the application object, processing continues at step 511. At step 511 , the user may use a browser application (or some alternate means such as, for example FTP) to locate a website or other server storing a verification application. In one embodiment, the user enters the URL for the website (which may be stored at central controller 115 or some other server). Once the connection with central controller 115 (or another authenticating server) is established, the verification application is downloaded to client 110 at step 512. The user then executes the verification application locally and specifies the location of the application object being verified (step 513). In a preferred embodiment of the invention, verification occurs using the MD-5 checksum algorithm of RSA. As a result, a checksum is generated based upon the coding of the application object. The checksum generated is transmitted to central controller 115 (or other authenticating server) for comparison with known checksums for various application objects and versions thereof. At step 514, the website or authenticating server transmits a verification status to client 110 indicative of the verification results. If the checksums match, the website or authenticating server will transmit a response message indicating that the application object is valid. Otherwise, the response indicates that the application object may be invalid. At step 520, if the response is indicative of an invalid application object, the user is alerted of the same via a message to client 110 at step 525 and the process terminates. Alternatively, if the application object is verified, the user is alerted of successful verification through a message at client 110 (step 518). In a preferred embodiment, the user next launches the application object which establishes a connection with central controller 115. Central controller immediately initiates the "lobby" executable and the user is placed in the "lobby" chat room (530). The lobby serves as the entry point into the gaming environment. Alternatively, it is possible for the verification application to be designed to automatically invoke the connection and launch the application upon successful verification. In either case, on the user's first visit, the user is prompted to register, and does register with the service via central controller at steps 535 and 540 so that information can be gathered as necessary prior to game play. A registration form (or other means for providing the requested information) is completed by the user and may then be sent by client 110 to central controller 115 at step 545. Information completeness is checked at step 550. If the information provided by the user is incomplete, follow-up questions may be sent to the user at step 555. The user then provides answers to follow-up questions 560. This process is repeated until the user furnishes the minimum data requirement pre-selected as a requirement for game play. Once the requisite information is furnished, the user is considered a "valid user" and a cryptographic key is transmitted to client 110 permitting user to access the applications and the lobby area. The cryptographic key is used in connection with cryptography applications 320 to control access to applications and resources resident on central controller 115. The user next enters the lobby at step 570. The lobby is a chat room where the user can select, via various buttons, hyperlinks, pull down menus, etc, other chat rooms and/or the application/game in which the user wishes to participate. In order to participate in a particular application/game, the user should preferably maintain a local copy of the application/game at client 110. In some cases, the user will receive the application as part of an application emailed to him or her as discussed above. Alternatively, the user can download the application from a website or from central controller 115. The important point is that control is established such that central controller 115 preferably will not permit a user to select an application which is determined not to be locally resident at user's client. This control may be established by, for example, tracking downloads of applications to particular registered users or verifying the presence of the application on the local client immediately prior to application execution when requested by the user. Assuming the user has been authorized and is determined to maintain a local copy of the application, client 110 may be instructed by central controller 115 to download art and/or other supporting files such as graphics, game engines, audio files, etc for the selected game/application (step 575). Particular files, characters and game elements may also be cached locally at client 110 for rapid access during game play. The user then selects playing partners at step 5115. Partners may be selected through the chat application with, for example, pull down menus or simultaneous player transfer to a specific chat room intended for a particular game or application. In the latter case, the players shift to a game space (specialized form of chat room) at step 5120. The game is then played by the players under the control of central controller 115 at step 5130. Upon completion of the game, whether by player actions, time limitations or other predetermined criteria for game termination, central controller 115 terminates the game at step 5135. Certain games are configured for "virtual value reallocation" based upon the results of game play. A determination is made at step 5140 as to whether the game just played is one such game. Prior to game play, a user may purchase a certain amount of "virtual value" or "tickets" for game play. Players may alternatively or additionally obtain virtual value from application objects emailed to them. Upon game completion, the amount of virtual value in a player's account may be decremented in return for game play. Additionally, if a game is configured for "virtual value reallocation", a game winner may receive some of the virtual value present in the loser's account. If virtual value reallocation is supported, then the right branch of the decision box at step 5140 is followed. In this case, the amount of reallocation is determined at step 5155. This may be based upon a score differential or may be a fixed number per game. In step 5160, each of the winners and losers accounts are adjusted. In the event of more than two players, various algorithms can be used to reallocate virtual value among all accounts. If the left path at step 5140 is followed (i.e. no virtual value reallocation), in one embodiment, it is possible at step 5145 to award some amount of virtual value to selected players based upon game play. That value is updated in the player's account at step 5150. The virtual value processing ends at step 5165. Following this, a user may return to the lobby or another chat room at step 5170. The user can then decide to play the same game again, to play another game or to not play any more games. This decision is made at step 5175. If the user decides to play another game or the same game again, the user returns to step 5115 where he or she selects partners and repeats the process previously described above. If the user decides not to play any more games at step 5175, then the player can return to the lobby at step 5195 and exit at step 5200. Alternatively, if the user desires, he or she can designate email addresses (as well as possibly some additional data) for potential new users at step 5185. The user can also designate particular games and/or other applications which may be of interest to the potential users. The email addresses and other information are collected by central controller at step 5190, which then may store the data in inquiry database 360 or some other database. Following this, an application object with the designated games (and/or other applications) may be emailed to designated potential users 5205. Following this step, the user may return to the Lobby at step 5195 and exits the process at step 5200. Figure 5B illustrates the process for game play in the event that a user returns to the service under the control of central controller 115 for a play a second or subsequent time (i.e. the user has already established an accounfj.The user decides to play a game at step 5210. Next, the user logs on to central controller 115 at step 5215. Central controller 115 next determines if the user is an accredited user based upon a previously set up account at step 5225. If not, central controller 115 terminates the link at step 5230. Central controller may also issue a message to the user indicating the problem and/or what the user must do to properly set up an account. If the user is properly authenticated, central controller 115 places the user in the lobby at step 5235. At this time, central controller 115 may also determine the status of the player's application object and the embedded executable and provide updates/upgrades as needed at step 5240. After this is completed, the user decides if he or she wishes to establish email/chat contact with others at step 5245. If so, the application object under the control of central controller 115 automatically establishes contact with designated other users at step 5250 by locating other individuals if they are present in system chat rooms. Following this, conversation in chatroom is accomplished at step 5255. Upon termination of the chat, the user returns to the lobby at step 5260. The user then decides whether to play a game at step 5265. If not, the user can then exit at step 5275. Otherwise, if the user desires to play a game, the user proceeds, at step 5265, to step 5115 in Figure 5 A to proceed with game set up and play as described above. Figure 6 illustrates the specific steps involved in game play. The user logs on, if already not logged on, to initiate a game at step 600. The user enters the chat room associated with the particular game or application and meets other potential players or "application partners" at step 605. The user then decides whether or not to play a game at step 610. The user can exit at step 620 or play a game at step 610. The user then plays the game at step 620. At game completion or stop at step 625, a final score is computed for each player. If a player is a winner, he or she may be awarded ticket(s) at step 635 depending on the final score (which may be modified by a special game routine depending on the game). If the player is not a winner, then the player may be returned to the chat room at step 605. Figure 7 is a flow chart illustrating the detailed process of virtual value ticket account control. As discussed above, based upon game play results, players may "win " ' virtual value tickets that may be redeemed for prizes, merchandise, services or additional game play. At step 700, the player's game scores are used to compute a virtual value. Various algorithms may be used to correlate game score to virtual value. For example, a player might receive a virtual value which equals his game score (points) multiplied by some multiple such as one-tenth. Next, at step 710, IADS 100 makes a determination as to whether the game just played is configured for "virtual value reallocation". As discussed above, if the game is configured as such, player's accounts are adjusted based upon game play. In other words, one player's account may be decremented (the loser) while another player's account may be incremented (the winner) (step 715). In a preferred embodiment, the number of total virtual value in the player's collective accounts remains constant. Value is merely shifted from one account to another based upon game play. Following account adjustment at step 715 or in the event the game is not configured for virtual value adjustments (i.e. game configured just to award virtual value to selected players or do nothing at the end of game play), the process exits at step 720. Figure 8 is a flowchart illustrating the steps that may be taken by IADS 100 in connection with a user response in the case where a user desires to purchase a product. In step 800, the user decides that he or she would like to purchase a product using IADS 100. It will be noted that IADS 100, in the context of game play, is particular well suited for vending "cards" which are elements of game play. In this case, when a user purchases cards as described below, central controller 115 "enables" the cards purchased with respect to the user as a result of the purchase. Thus, information stored at data storage devices 160 indicates which "cards " or other game elements each player is entitled to use. Returning to Figure 8, at step 805, the user establishes a connection with central controller 805. This can be accomplished through the use of an application object as described above or through browser access to an appropriate website. At step 810, the user reviews the cards and/or products available for purchase. At step 815, the user decides which products and/or cards to purchase. At steps 820, 825, and 830 the user employs traditional e- commerce technology to pay for and initiate the order fulfillment process. If products are ordered from a third party vendor, central controller 115 may transmit a message (according to an agreed protocol) to the appropriate vendor detailing the order via Internet 150. The preferred embodiment of this feature of IADS 100 provides access to central controller 115 via a client browser or other order entry system which interfaces with vendors' fulfillment system. Virtual value (tickets) stored in a user's account may be used to make purchases resulting in a decrement of "virtual value" in the user's account. Cash payments may also be made via the SET payment system. Those skilled will recognize that this payment and fulfillment can alternatively be made via other payment and fulfillment systems. Although the foregoing invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that other changes in form or in application may be made without departing from the scope and spirit of the invention. For example, the above description contains many specificities, they should not be construed as limitations on the scope of the invention, but rather as an exemplification of one preferred embodiment thereof. For example, the application of this invention could be expanded to encompass the distribution, playing and monitoring of applications on a variety of present and future communications networks, wireless or satellite communications networks and distributed server(s) and systems.

Claims: WE CLAIM: 1. An application distribution system comprising: a central controller; a plurality of clients, each client communicating with said central controller through a network connection; and a communications application resident on each of the plurality of clients for receiving and transmitting at least one application object, the at least one application object further comprising of at least one target application location and at least one invocation application; wherein the central controller establishes coordinated execution of the at least one target application among the clients after execution of the at least one invocation application. 2. The system according to claim 1 , wherein the at least one target application permits interaction between the plurality of clients through the central controller. 3. The system according to claim 1, wherein the at least one target application is a computer game application. 4. The system according to claim 3, wherein the established coordinated execution further comprises: a) executing the computer game application; and b) facilitating game play between at least two of the plurality of clients. 5. The system according to claim 1, wherein the at least one application object is received by one of the plurality of clients from another of the plurality of clients. 6. The system according to claim 1, wherein the central controller further comprises a communications application resident on the central controller and wherein the at least one application object is received by one of the plurality of clients from the central controller. 7. The system according to claim 1 , further comprising a data storage device for storing application data reflective of processing associated with the at least one target application. 8. The system according to claim 1, further comprising a data storage device for storing historical data associated with the plurality of clients. 9. The system according to claim 1, wherein the central controller further comprises a data storage device including the at least one target application location and wherein the at least one target application is transmitted to said client as a result of the execution of the at least one invocation. 10 A method for distributing applications for interaction between at least one client and a central controller, wherein the central controller and the at least one client connected by a network connection, the method comprising the steps of: communicating at least one application object via a communications application to the at least one client, the at least one application object further comprising the location of at least one target application location and at least one invocation application; receiving at the central controller from the at least one client a communication indicating that the invocation application has been executed; and coordinating execution of the at least one target application. 11. The method according to claim 10, wherein the at least one target application facilitates interaction between the at least one client and the central controller. 12. The method according to claim 10, wherein the at least one target application is a computer game application. 13. The method according to claim 12, wherein coordinated execution further comprises the steps of: a) executing the computer game application; and b) facilitating game play between the at least one client and the central controller. 14. The method according to claim 10, wherein the at least one client receive the at least one application objects from another client. 15. The method according to claim 10, wherein the at least one client receive the at least one application objects from the central controller. 16. The method according to claim 10, further comprising the step of storing application data reflective of processing associated with the at least one target application in a data storage device. 17. The method according to claim 10, further comprising the step of storing historical data associated with the at least one client in a data storage device. 18. The method according to claim 10, wherein the central controller further comprises a plurality of target applications located on a storage device, and wherein the step of executing the at least invocation application further comprising transmitting the at least one target application from the at least one target application location to the at least one client. 19. A method for receiving at a client applications for interaction between at least one client and a central controller, the at least one client and the central controller connected by a network connection, the method comprising the steps of: receiving via a communications application at least one application object, the at least one application object further comprising at least one target application location and at least one invocation application; executing the at least one invocation application; communicating to the central controller a transmission indicating that the invocation application has been executed; and executing the at least one target application. 20. The method according to claim 19, wherein the at least one target application facilitates interaction between the at least one client and the central controller. 21. The method according to claim 19, wherein the at least one target application is a computer game application. 22. The method according to claim 21, wherein coordinated execution further comprises the steps of: a) executing the computer game application; and b) facilitating game play between the at least one client and the central controller. 23. The method according to claim 19, wherein the step of receiving includes receiving the at least one application objects from another client. 24. The method according to claim 19, wherein the step of receiving includes receiving the at least one application objects from the central controller. 25. The method according to claim 19, wherein the central controller further comprises a data storage device for storing application data reflective of processing the associated with the at least one target application. 26. The method according to claim 19, wherein the central controller further comprises a data storage device for storing historical data associated with the at least one client. 27. The method according to claim 19, wherein the central controller further comprises a plurality of target applications located on a storage device, and wherein the step of executing the at least invocation application further comprising downloading the at least one target application from the at least one target application location to the at least one client.

Inventors: D AMELIO MARCUS, DEKELBAUM ROBERT, HAM ETHAN, HARVEY JAMES WARREN, LEWIS JEFF, MOYER LEE, POWER LESLIE, ROSENBAUM BENJAMIN, D'AMELIO, MARCUS, DEKELBAUM, ROBERT, HAM, ETHAN, HARVEY, JAMES, WARREN, LEWIS, JEFF, MOYER, LEE, POWER, LESLIE, ROSENBAUM, BENJAMIN
Applicants: AMELIO MARCUS D, DEKELBAUM ROBERT, DIGITAL ADDICTION INC, HAM ETHAN, HARVEY JAMES WARREN, LEWIS JEFF, MOYER LEE, POWER LESLIE, ROSENBAUM BENJAMIN, D'AMELIO, MARCUS, DEKELBAUM, ROBERT, DIGITAL ADDICTION, INC., HAM, ETHAN, HARVEY, JAMES, WARREN, LEWIS, JEFF, MOYER, LEE, POWER, LESLIE, ROSENBAUM, BENJAMIN
Application year: 1999
Main classification: G06F15
IPC codes: A63F13, H04L12, H04L29