US20110223981A1 - User-Device-Implemented Contest with Alert Feature - Google Patents

User-Device-Implemented Contest with Alert Feature Download PDF

Info

Publication number
US20110223981A1
US20110223981A1 US13/100,211 US201113100211A US2011223981A1 US 20110223981 A1 US20110223981 A1 US 20110223981A1 US 201113100211 A US201113100211 A US 201113100211A US 2011223981 A1 US2011223981 A1 US 2011223981A1
Authority
US
United States
Prior art keywords
players
player
time
points
contest
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/100,211
Inventor
Robert J. Feeney
Brent W. Barkley
Jeff E. Haas
Gregory J. Pinter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Vergence Entertainment LLC
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US13/100,211 priority Critical patent/US20110223981A1/en
Assigned to VERGENCE ENTERTAINMENT LLC reassignment VERGENCE ENTERTAINMENT LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BARKLEY, BRENT W., FEENEY, ROBERT J., HAAS, JEFF E., PINTER, GREGORY J.
Publication of US20110223981A1 publication Critical patent/US20110223981A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management
    • G06Q10/109Time management, e.g. calendars, reminders, meetings or time accounting
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/71Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/77Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85Providing additional services to players
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326Game play aspects of gaming systems
    • G07F17/3269Timing aspects of game play, e.g. blocking/halting the operation of a gaming machine
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326Game play aspects of gaming systems
    • G07F17/3272Games involving multiple players
    • G07F17/3276Games involving multiple players wherein the players compete, e.g. tournament
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/326Game play aspects of gaming systems
    • G07F17/3272Games involving multiple players
    • G07F17/3276Games involving multiple players wherein the players compete, e.g. tournament
    • G07F17/3279Games involving multiple players wherein the players compete, e.g. tournament wherein the competition is one-to-one, e.g. match
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3286Type of games
    • G07F17/3295Games involving skill, e.g. dexterity, memory, thinking
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/40Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterised by details of platform network
    • A63F2300/401Secure communication, e.g. using encryption or authentication
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/532Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing using secure communication, e.g. by encryption, authentication
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/552Details of game data or player data management for downloading to client devices, e.g. using OS version, hardware or software profile of the client device
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/55Details of game data or player data management
    • A63F2300/5593Details of game data or player data management involving scheduling aspects
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/57Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of game services offered to the player
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72427User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality for supporting games or graphical animations

Definitions

  • the present invention pertains to a contest that is played substantially simultaneously by a number of players.
  • the present invention addresses this need by providing, inter alia, an entirely new type of contest in which, at various intervals, geographically dispersed players attempt to answer the identical problem at substantially the same time.
  • problems typically, questions
  • players have the opportunity either to respond to the problem or (e.g., in the event that a given player is occupied when a particular problem arises) to pass on the current problem and wait for another one.
  • more questions are made available than the players are permitted to answer in accordance with the rules of the game, so that players have flexibility as to when they participate.
  • the invention is directed to systems, methods and techniques for implementing a simultaneous, but intermittently played, contest.
  • a problem is delivered substantially simultaneously to geographically dispersed players, the problem being identical for all players.
  • Responses to the problem are received from the players, the corresponding response times are measured, and scores are determined for the players based on the responses and corresponding response times.
  • the foregoing steps are then repeated a plurality of times, with a median time interval between delivery of consecutive problems being at least 30 minutes, and with an aggregate score being maintained for each of the players.
  • FIG. 1 illustrates an overview of an alert system according to a representative embodiment of the present invention.
  • FIG. 2 illustrates communication between a user device and a server according to a representative embodiment of the present invention.
  • FIG. 3 is a block diagram showing some of the components of a user device according to a representative embodiment of the present invention.
  • FIG. 4 illustrates an example of alert information and time synchronization information according to a representative embodiment of the present invention.
  • FIG. 5 is a flow diagram illustrating an overview of a process for implementing an alert system according to a representative embodiment of the present invention.
  • FIG. 6 is a flow diagram illustrating a process for conducting a contest according to a representative embodiment of the present invention.
  • FIG. 7 illustrates an initial user interface questioning whether a player wants to participate in the current problem in a contest according to a representative embodiment of the present invention.
  • FIG. 8 illustrates a user interface for presenting a problem and accepting a response to it in a contest according to a representative embodiment of the present invention.
  • FIG. 9 illustrates a sliding scale for conversion of game points to Dotz according to a representative embodiment of the present invention.
  • the present disclosure is divided into sections.
  • the first section describes certain technological considerations for implementing contests and other methods of the present invention.
  • the second section describes an exemplary contest that may be implemented using such platforms. Subsequent sections provide additional information, as indicated by their headings.
  • FIG. 1 illustrates an overview of an alert system 10 for achieving this goal, according to a representative embodiment of the present invention.
  • a central server 12 drives the alert system 10 , communicating with a plurality of different user devices (e.g., devices 21 - 26 ).
  • Each such device 21 - 26 typically has a user associated with it (e.g., user 31 for device 21 and user 32 for device 22 ).
  • a single user e.g., user 33
  • two or more user devices e.g., devices 23 and 24
  • Server 12 may be implemented as a single physical device, but more commonly will be implemented as a server cluster, with redundancy, appropriate load-sharing hardware and software, and different functionality distributed across different physical boxes, as is well known in the art.
  • different physical devices are used for communicating across different kinds of networks (e.g., directly over the Internet, by SMS messaging, or using a proprietary wireless protocol).
  • FIG. 1 Although only six user devices 21 - 26 are illustrated in FIG. 1 , this is for ease of illustration only. Typically, there will be many more user devices that participate in the alert system 10 , such as more than 50, 100, 500, 1,000 or even 10,000 such devices (as well as a similar number of users). Also, the same server 12 can be used to handle multiple alert systems, e.g., using different distribution lists and different back-and processing routines for such different systems.
  • Each user 31 - 35 preferably has pre-registered with server 12 for the current alert system 10 , designating the device(s) on which such user 31 - 35 will be receiving the alerts, as well as the manner in which server 12 is to communicate with such device.
  • the present invention contemplates multiple different modes of communication between server 12 and the various user devices 21 - 26 .
  • the most commonly anticipated communication mode will involve the use of a wireless network 41 , so that the corresponding user device 21 will be more likely to be able to communicate with server 12 at any time of day.
  • the preferred embodiments of the present invention do not require real-time communication in order to function as intended.
  • SMS short messaging service
  • Web communications any of the other wireless data protocols (whether public or proprietary) that are supported by the particular wireless carrier.
  • HTTP hypertext transfer protocol
  • FTP file transfer protocol
  • instant messaging or e-mail messaging protocols any of a variety of different specific protocols, such as HTTP, file transfer protocol (FTP), any proprietary data-transfer protocol, or even instant messaging or e-mail messaging protocols.
  • HTTP hypertext transfer protocol
  • FTP file transfer protocol
  • instant messaging or e-mail messaging protocols any of a variety of different specific protocols, such as HTTP, file transfer protocol (FTP), any proprietary data-transfer protocol, or even instant messaging or e-mail messaging protocols.
  • a single user 33 will register multiple different devices 23 and 24 with server 12 for participation in a particular alert system 10 .
  • multiple different communication paths 43 may be used for the different devices 23 and 24 (e.g., a wireless network for device 23 and a direct Internet connection for device 24 ).
  • the user 33 preferably has the ability to designate multiple devices 23 and 24 as both being currently active, so that when the alert occurs it will be delivered by both devices, thereby maximizing the likelihood that the user 33 will be in the vicinity of one of such devices 23 and 24 at the appropriate time.
  • the user 33 preferably also has the ability to designate only a single one of the devices 23 and 24 to deliver the message, e.g., depending on when the message is to be delivered.
  • the user 33 preferably defines a schedule, indicating which device 23 and 24 is active at which times.
  • more than two devices 23 and 24 may be registered, and the user 33 preferably can designate any number as being active at a given time.
  • server 12 may communicate with a non-networked device 25 (operated by user 34 ), e.g., by using a direct connection 44 .
  • a direct connection 44 examples include transferring the required data using a point-to-point cable, wireless connection (e.g., infrared or Bluetooth) or cradle.
  • direct delivery 44 generally will constitute only one of the steps in the overall delivery process, such as where server 12 downloads the required information to a networked computer or other device which, in turn, directly transfers it to user device 25 .
  • server 12 may communicate with a user device 26 via a broadcast medium (a wireless broadcast, e.g., using radio frequencies, and/or a hardwired broadcast, e.g., using television cable or Internet broadcasts).
  • a broadcast medium a wireless broadcast, e.g., using radio frequencies, and/or a hardwired broadcast, e.g., using television cable or Internet broadcasts.
  • the user device 26 is an interactive television, but any other kind of device instead may be used for receiving such broadcasts, including a general-purpose computer or a cellular telephone.
  • server 12 to communicate with the various user devices 21 - 26 should be understood as being exemplary only. Any other communication modes or paths instead, or in addition, may be used. Also, any combination of different paths or modes may be used.
  • FIG. 1 illustrates one-way communication between the server 12 and the various user devices 21 - 26 .
  • communication is bidirectional between server 12 and user devices 21 - 26 .
  • FIG. 2 shows an exemplary user device 21 in communication with server 12 .
  • server 12 typically communicates alert information 61 and time synchronization information 62 to user device 21
  • user device 21 typically communicates a response 63 to such alert information 61 back to server 12 .
  • such communications can occur over significant time intervals and often will vary significantly from one user device 21 to another of the user devices 22 - 26 . Such variations often will be common even where all of the user devices 21 - 26 are delivering the message 61 at substantially the same time and allowing the corresponding users 31 - 35 to submit their responses 63 at substantially the same times.
  • the alert information 61 may be stored on user device 21 at any time prior to the scheduled delivery and the response may be transmitted back to server 12 at any time after it has been submitted by the corresponding user 31 .
  • the various types of information may be transmitted using different communication channels.
  • FIG. 3 is a block diagram showing certain portions of an exemplary user device 21 according to a representative embodiment of the present invention.
  • user device 21 has installed on it an alert-based client application 80 that performs all or nearly all of the special functionality associated with the present invention.
  • application 80 is implemented entirely in software (e.g., as a Java midlet or Brew application), but instead may be implemented in any of the other ways discussed herein.
  • interface 82 generally will be comprised of hardware and software components for communicating, e.g., across a TCP/IP (Transmission Control Protocol/Internet Protocol) network and/or across a wireless communications channel (e.g., cellular-based, any of the 802.11x family of protocols, Bluetooth, infrared, or the like).
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • wireless communications channel e.g., cellular-based, any of the 802.11x family of protocols, Bluetooth, infrared, or the like.
  • input/output interface 82 provides the primary communication link between client application 80 within device 21 and server 12 .
  • application 80 stores certain information that it receives via interface 82 into device memory or storage 83 (preferably non-volatile) until an appropriate time, such as the designated delivery time.
  • Application 80 preferably also monitors device clock 85 and real-time clock 86 .
  • device clock 85 typically is a hardware device that provides timing clock signals for synchronous processing by the various hardware components of device 21 (e.g., including a general-purpose processor executing application 80 ).
  • real-time clock 86 typically is implemented as a software application and provides the actual time of day, e.g., for reference by the corresponding user 31 and for time-stamping certain data items within device 21 .
  • FIG. 4 illustrates one example of a packet 90 containing alert information 61 and time synchronization information 62 according to a representative embodiment of the present invention.
  • synchronization information 62 includes a single timestamp reflecting the current time maintained by server 12 (here, stated to the nearest 0.01 second).
  • the alert information 61 includes a number of entries 91 - 93 , each having a corresponding delivery time 95 and message 96 . Although three such entries 91 - 93 are illustrated, any other number instead may be transmitted at a single time.
  • the synchronization information 62 is illustrated as being transmitted in the same packet 90 as the alert information 61 , they instead can be transmitted in separate packets.
  • the messages 96 are questions; however, as discussed in more detail below, any of a variety of different types of messages instead may be included.
  • FIG. 5 is a flow diagram illustrating an overview of a process for implementing an alert system according to a representative embodiment of the present invention.
  • This process preferably is implemented entirely in software (with step 100 typically being performed by server 12 and the other steps typically being performed by client application 80 ), but instead may be implemented in any of the other ways discussed herein.
  • the process generally is discussed in the context of the hardware configurations shown in FIGS. 1-3 . However, it should be understood that such references are for convenience and ease of understanding only and therefore are merely exemplary in nature.
  • step 100 the server 12 transmits alert information 61 and time synchronization information 62 to a plurality of user devices 21 - 26 .
  • alert information 61 is transmitted in an encrypted format, in order to prevent early discovery by the eventual recipients 31 - 35 .
  • the preferred encryption technique is AES (Advanced Encryption Standard), but any other secure type of secure encryption can be utilized.
  • the alert information 61 and time synchronization information 62 are transmitted to all of the user devices 21 - 26 simultaneously, or substantially simultaneously.
  • such information is transmitted to the various user devices 21 - 26 at different times.
  • the latter approach is particularly preferred if latency times are expected to vary in an amount that exceeds the desired tolerance in terms of how closely in time the individual messages 96 are desired to be delivered.
  • the latency differences e.g., the time differences between when the various devices 21 - 26 actually receive the synchronization information 62
  • Transmitting at least the synchronization information 62 individually to each user device 21 - 26 can allow for the latency to that device to be estimated and accommodated to some extent.
  • the transmission latency is variable and may be larger than the desired tolerance
  • an alternate technique may be employed to estimate the latency between the server 12 and the individual devices 21 - 26 , thereby allowing correction for such latency.
  • the server 12 might first send out one or more probe packets to a subject user device 21 , with the client application 80 having been configured to automatically transmit a response packet, resulting in a kind of pinging of the subject user device 21 .
  • the server 12 need only divide the round-trip latency (or the average round-trip latency if more than one packet was sent) by two and then adjust the transmitted synchronization time 62 (e.g., by simply adding such quantity) in order to compensate for the expected one-way latency.
  • any other technique may be used to estimate and adjust for expectant latency.
  • transmitting the synchronization time 62 separately from the alert information 61 might be useful in reducing latency time, particularly where the alert information is voluminous relative to transmission bandwidth.
  • alert information 61 typically is relatively straightforward.
  • a user or a separate automated process supplies server 12 with one or more messages 96 that are to be distributed to a specified group of user devices 21 - 26 for delivery at one or more specified delivery times 95 .
  • the list of devices 21 - 26 may be generated by reference to user preference information indicating which devices are intended to be active at the scheduled delivery times.
  • Such alert information 61 may then be delivered (preferably in encrypted form) at any time prior to the earliest specified delivery time 95 .
  • step 100 is shown differently than the other process steps illustrated in FIG. 5 . This is because step 100 generally can be performed at any time during the overall process, e.g., whenever server 12 has a new alert 61 to be pushed out. In addition, step 100 preferably also as performed upon request either by the server 12 or by the alert-based client 80 running on the user device 21 , e.g., in order to check for any clock tampering in an attempt to have the message delivered early.
  • step 100 generally stands outside of the normal process flow, although it preferably is initiated from the sleep or background mode (as described below) under normal circumstances. Nevertheless, step 100 preferably is executed as the first step of the present process in order to achieve an initial time synchronization and download of alert information 61 .
  • step 102 client 80 waits until it is time to check the real-time clock 86 .
  • client 80 waits until it is time to check the real-time clock 86 .
  • the present embodiment contemplates a “sleep” or “background” mode in which client 80 performs minimal processing.
  • One of the functions that preferably is performed by client 80 during the sleep mode is to periodically check the real-time clock 86 in order to determine whether it is time to deliver a message and to confirm accuracy.
  • the wait in this step 102 preferably is equal to a fixed number of the clock cycles generated by device clock 85 .
  • the counting of clock cycles can be performed in software.
  • a simple hardware counter can be used, e.g., one which generates an interrupt signal when the desired count has been reached.
  • client 80 checks a real-time clock 86 approximately every five minutes.
  • step 104 client 80 reads the current value of the real-time clock 86 and checks for any variances or potential tampering. For the reasons indicated elsewhere in this disclosure, there often may be significant incentives to learning certain information (e.g., contest questions or financial news) prior to the intended delivery time. Accordingly, the present invention preferably uses a number of measures to detect and correct tampering and normally occurring time discrepancies.
  • client 80 preferably has access to at least three different time indicators.
  • the first one, the synchronization time 62 provided by server 12 generally will be the most accurate, but the least frequently updated.
  • the second, the set of periodic clock-check signals based on the device clock 85 does not provide absolute time, but provides an indication of time-interval durations.
  • the third, the real-time clock 86 provides the most current indication of absolute time, but that measurement might be out of sync with the clock maintained by server 12 and frequently will correspond to a different time zone.
  • at least the second and third sources potentially are subject to user manipulation.
  • client application 80 preferably looks for any anomaly between the three sources, whether manifested as a constant bias, a steady drift or a sudden change.
  • each message-delivery time 95 (or, alternatively, an internal clock correction) is adjusted to account for any detected difference.
  • Such situations can include, e.g., either (i) where the difference between what the real-time clock 86 says and what would be expected by virtue of the periodic check signals based on the device clock 85 is excessive; or (ii) where the applicable tolerances in the device clock 85 and the real-time clock 86 make it difficult to establish which is most representative of the correct time.
  • a reset determination can be made arbitrarily, at fixed time intervals, or randomly, in an attempt to identify more elaborate tampering schemes.
  • step 106 processing returns to step 100 in order to request a new time synchronization signal 62 (if such on-demand requests are supported in the applicable embodiment) or simply wait for the next scheduled time synchronization signal 62 from server 12 (disabling the applicable user device from the alert system until such synchronization occurs). If a reset is not required (e.g., values are within tolerances and/or a determination otherwise is made that the discrepancies appropriately can be handled by an adjustment), then processing simply proceeds to step 108 .
  • an affirmative determination of tampering preferably causes client application 80 to notify server 12 and disqualifies the corresponding user from participating in any further system alerts.
  • the time stated by real-time clock 86 will be significantly different than the actual time without any intentional tampering. Such a condition might occur, for example, where the device 21 has been reset and does not have a connection to its wireless carrier, so its real-time clock 86 might be reset to an arbitrary or default time (e.g., 12:00 p.m.).
  • the logic for declaring a tamper condition preferably checks for and takes into account all such conditions or, at the very least, allows a certain number of unexplained discrepancies before declaring a tamper condition.
  • client application 80 maintains a time offset figure indicating the difference in time between real-time clock 86 and the clock maintained by server 12 .
  • application 80 could maintain its own internal real-time clock, e.g., using input from all of the three sources indicated above.
  • step 108 a determination is made as to whether it is time for the device 21 to wake up from its sleep mode. An affirmative determination in this regard preferably is made if a message is scheduled to be delivered within a specified amount of time (e.g., within 2-10 seconds) or, in certain cases, prior to the next clock-check signal or within a specified margin after it. If the determination is negative, then processing returns to step 102 to await the next clock-check signal. If positive, then processing proceeds to step 110 .
  • a specified amount of time e.g., within 2-10 seconds
  • step 110 any of a variety of different types of processing may be performed.
  • client application 80 preferably brings forward at least some portion of its user interface (preferably overriding any conflicting user interfaces).
  • the first goal of the user interface in this instance is to capture the user's attention.
  • Such a signal preferably comprises an audio alarm, but also could include vibration or other tactile sensations, or even visual cues.
  • the 2-10 seconds mentioned above in connection with step 108 is intended primarily to accommodate such a warning signal (as well as to make the other preparations required for delivering the message on schedule). It is noted that the warning signal is particularly important, and preferably is somewhat longer, in embodiments where the time that the message is to be delivered is not known in advance.
  • the user interface also will include some visual display elements, such as a text message or a logo.
  • some visual display elements such as a text message or a logo.
  • all messages are provided entirely by sound (e.g., using synthesized or sampled speech for devices with a small or nonexistent display), or even entirely by vibration or other tactile sensation (e.g., for the visually impaired).
  • the warning signal is accompanied by an opt-out or opt-in message and corresponding period of time during which the user 31 - 35 can elect to receive the message or elect not to receive the message (depending upon the selected default setting).
  • An opt-in system generally is preferred, particularly where the users 31 - 35 are only permitted to receive a limited number of messages, where they are required to pay for each message received and/or where the messages are sensitive and therefore should not be seen by others.
  • the message 96 is decrypted and delivered to the user 31 - 35 .
  • the net effect of multiple user devices 21 - 26 implementing similar client applications 80 is that all of the users 31 - 35 will receive the message at substantially the same time.
  • the expression, “substantially the same time” and similar expressions with respect to delivery of a message are intended to mean close enough in time such that, ordinarily (e.g., assuming a properly functioning system and no inappropriate tampering), recipients generally will not be significantly advantaged by virtue of having received the message earlier or disadvantaged by receiving the message late.
  • the term will correspond to distribution to all recipients within a time window having a maximum duration of approximately 1-3 seconds.
  • certain embodiments of the invention provide functionality for allowing the users 31 - 35 to respond to the message 96 . More preferably, such embodiments display a response interface (e.g., one or more clickable or otherwise selectable buttons, objects that can be dragged and/or a field for entering text) on the same user interface as that on which the message 96 is displayed.
  • a response interface e.g., one or more clickable or otherwise selectable buttons, objects that can be dragged and/or a field for entering text
  • the response information preferably either is immediately transmitted to the server 12 or else is saved into memory/storage 83 (e.g., in encrypted form) for later transmission to server 12 .
  • step 110 processing returns to step 102 in order to begin waiting for the next message delivery.
  • the foregoing technology is discussed within the context of simultaneous delivery of a message to multiple individuals, its use is not so limited. Rather, as should be readily apparent, the foregoing technology also can be used for any time-controlled disclosure of information, even where the recipients are receiving it at different scheduled times. Similarly, the foregoing technology is not limited to disclosures to natural persons; in addition, it can be used, e.g., for time-controlled release of information to an automated process. Exemplary uses in this latter respect include electronic funds transfers and electronic payment systems.
  • a direct broadcast of such information can be used.
  • the message itself can be transmitted in advance (e.g., in encrypted form) and only a release signal broadcast by the server 12 (or any other device) when it is time for delivering the message.
  • a broadcast message can be used simply to wake up a client application on each of one or more user devices; thereafter, a communication channel is opened between each such user device and the server 12 , or even among all (or any subset) of such user devices and/or the server 12 .
  • a different form of push technology is used.
  • a SMS message can be used to “wake up” each client application 80 , with the server 12 then receiving confirmation of receipt of that SMS.
  • preprogrammed alerts pop up on the user's device 21 - 26 (e.g., using the device's timer) and invite the user 31 - 35 to click a button to retrieve a message.
  • One click opens direct (e.g., HTTP) access to the server 12 to retrieve the desired content.
  • the subject content is broadcast in real time to all users 31 - 35 .
  • Such users 31 - 35 then respond via broadband.
  • FIG. 6 is a flow diagram illustrating a process for conducting a contest according to a representative embodiment of the present invention.
  • the contest according to FIG. 6 is played substantially simultaneously by a number of geographically dispersed players at intermittent points in time.
  • Each player participates by using a (typically network-accessible) device, which may include, e.g., an Internet-accessible computer, a wireless telephone or a wireless personal digital assistant (PDA), as shown in FIG. 1 .
  • a network-accessible device which may include, e.g., an Internet-accessible computer, a wireless telephone or a wireless personal digital assistant (PDA), as shown in FIG. 1 .
  • PDA wireless personal digital assistant
  • the contest is played over an extended period of time, such as anywhere from several days to a month, or even longer.
  • the contest involves a number of problems, which may include multiple-choice or other types of questions.
  • each problem is made available to all of the players at substantially the same time, and multiple problems are made available each day of the contest.
  • more problems preferably are made available than the number of problems that each player is permitted to respond to, under the rules of the contest.
  • the problems preferably are delivered at random times during the day, or during some specified window of time during the day. When that window occurs preferably depends upon the time zones in which the players are expected to be located. In alternate embodiments of the invention, the particular times, or at least some of the times, when the problems are delivered are known in advance by some or all of the players.
  • a feature of the present contest is that problems are delivered at intermittent times over an extended period of time.
  • the intervals between problems typically will be at least 30 minutes and often will be 1-2 hours or even longer, thereby contributing to the randomness of the play.
  • the median time between delivery of problems preferably is at least 30 minutes, 60 minutes or two hours.
  • the contest typically will go on for at least three days, a week, two weeks, a month or even longer.
  • each contest is one month long with three or four problems each day (potentially excluding certain weekend days and/or holidays), but with the players allowed to respond to only one problem each day.
  • a user interface is provided to all of the players via the players' devices.
  • the user interface preferably includes an alert signal which, in turn, preferably includes an audio component, such as a contest-specific ring tone. It is noted that the exact timing of the alert signal (if provided) generally is not as sensitive as delivery of the actual problem, provided that the various players receive roughly the same amount (or even some minimum amount) of advance warning.
  • the user interface preferably queries whether the player wants to respond to this problem or to pass on it.
  • An exemplary user interface 170 is illustrated in FIG. 7 .
  • interface 170 includes a message 171 notifying the player that a new problem is about to be delivered and asking whether the player wants to participate in the problem.
  • a pair of radio buttons 173 allows the player to designate his or her choice, with a timer 175 indicating the remaining time until the default option (or the currently selected option if the player has highlighted the other option) is selected.
  • the default (which occurs if no response is given by the player) is to assume that the player is passing on the problem (as indicated in FIG. 7 ).
  • the timer 175 starts at approximately 4-7 seconds and counts down.
  • step 134 the players who will be participating in the present problem are identified (e.g., all of those who have opted to receive the problem).
  • the players do not get any information about the problem, or at least do not obtain the problem itself, before deciding whether to participate.
  • the players may be given some limited information about the problem along with the alert, such as the general category to which the problem pertains. As a result, in such alternate embodiments the players can decide whether to participate based on factors other than mere convenience (e.g., their comfort level with the general category).
  • step 134 generally can be omitted on the assumption that all of the players can be deemed to be participants, irrespective of whether or not they actually do participate.
  • step 132 also is omitted, so that the players get no advance warning about when a problem is going to be delivered.
  • the set of participants for the current problem preferably exclude the players who already have answered their maximum allotted problems for the current period of time (e.g., their one problem for the day).
  • the preferred implementation is for anywhere between 2-8 problems to be presented each day, with each player allowed to answer no more than 1-5 (but preferably always strictly less than the total number of problems presented). More preferably, 3-4 problems are provided each day, with each player allowed to answer not more than 1 of them.
  • the excluded participants also may be excluded from step 132 , thereby sparing them an unnecessary alert.
  • the problem may be provided to a player at the same time as the participating players even if the subject player already has answered his or her maximum allotted problems or otherwise has opted out; however, this preferably would be for enjoyment purposes only and any response (if permitted) preferably would not count toward the competition. More preferably, however, a problem is not provided to non-participating players until after the problem has been completed by the participating players.
  • the problem is presented substantially simultaneously to all of the participating players.
  • participating players are required to answer an ordinary problem (special problems are discussed below) within 30 seconds, or else are scored as getting the problem incorrect. For that reason, and in order to prevent any unfair advantages, the problem preferably is presented within a 3-second window to all or substantially all of the participating players under normal circumstances.
  • player device failures and other physical limitations at least sometimes will preclude delivery within such a 3-second window to 100% of the player devices.
  • the problems can involve any type of problem (e.g., knowledge-based or skill-based). However, it presently is anticipated that the most commonly used problem will be a question, typically a multiple-choice question.
  • FIG. 8 An exemplary user interface 190 providing such a problem is illustrated in FIG. 8 .
  • user interface 190 includes a multiple-choice question 191 , a plurality of potential answers 193 , and a count-down timer 195 which indicates the time remaining in which to provide a response. Because a timer internal to application 80 preferably is used, the participant can be given the full response time (e.g., 30 seconds) from the time that the problem initially is delivered (or displayed), even if there are slight differences (e.g., a second or two) among the various player devices as to when the problem is delivered in absolute time.
  • the full response time e.g. 30 seconds
  • the potential answers 193 preferably function as input interface elements (radio buttons in this case), allowing the player to respond directly and quickly within the same user interface 190 , by simply designating the desired response 193 . Once such a response is designated and then selected (or entered), the problem is over from the current player's perspective.
  • the problem could be a question that requires a textual and/or numeric response (e.g., entered through the keypad of a wireless telephone).
  • the question can involve additional media beyond a merely textual question.
  • the participants might be asked to: (i) identify an individual within a photograph or video segment, (ii) identify the next three notes, or the next bar, following a segment of a song that is played for the participants, (iii) count the number of specified items in a particular photograph, or (iv) identify which of three movie-clip-and-soundtrack combinations do not go together.
  • the problem might be more in the nature of a puzzle or even a video game, requiring onscreen manipulations by the participants.
  • the problem might involve external events and/or media outside the four corners of the player's devices 21 - 26 .
  • problems are special problems that are allotted additional time to complete.
  • the players are directed to find an answer or an item on the Internet.
  • More elaborate problems can involve a sort of virtual scavenger hunt, in which players move from one web site to another searching for the next clue until the answer is found or until time expires.
  • step 139 the answers are received, typically by the individual player devices themselves in the first instance and then either immediately or subsequently transmitted to the contest server (e.g., server 12 ).
  • the contest server e.g., server 12
  • the response time also will be transmitted to the server; in others, the player devices merely indicate whether the response was received within the allotted period of time.
  • the player devices encrypt the response information before storing it or transmitting it to the contest server.
  • step 141 the players' responses are scored. This step can be performed either at the player's device 21 - 26 itself or, after transmission, by the server 12 , with the resulting score simply obtained later (e.g., via the player's device 21 - 26 ).
  • each correct response that was submitted within the required timeframe e.g., within 30 seconds after the problem was delivered
  • each incorrect response is assigned a negative point value (e.g., the negative of the point value for a correct response).
  • different scoring mechanisms are applied. For example, in certain cases no penalty is attributed to an incorrect response.
  • the point award for a correct response is a function of how quickly the participant provided the response (in which case the participant's response time preferably is transmitted to the server, if that is where scoring occurs, along with the response itself).
  • different point levels are assigned for different levels of performance in connection with the problem (e.g., different point of values for completing 80% of a scavenger hunt and for completing 90% of the same scavenger hunt, within a fixed timeframe).
  • step 143 a determination is made as to whether the current problem was the last one for the contest. If not, then processing returns to step 131 to await the next problem. If so, then processing proceeds to step 144 .
  • step 144 the contest is concluded and the winners (if any) are identified based on total number of points accumulated.
  • a contest according to the present invention may be conducted as a tournament with winners (e.g., first, second, third place and/or similar rankings in various subcategories). Alternatively, it may be conducted simply for the sake of accumulating points, e.g., which then are traded for products or services.
  • different problems can have different associated point values.
  • the longer, more difficult or otherwise more involved problems preferably have higher point values than the shorter or easier ones.
  • there are a relatively large number of regular problems e.g., having a 30-second maximum response time and a standard point value
  • multiple problems e.g., standard, difficult and extreme, having progressively higher point values
  • all of the problems are downloaded prior to the delivery time but, for each player, only the selected problem is actually delivered to that player.
  • the contest is not geographically limited (subject, perhaps, to any practical problems that might arise in attempting to conduct the contest across too many time zones).
  • the contest preferably is played substantially simultaneously by all of the participants, so that in a reasonably large crowd several people might receive the alert and begin play, making the present contest more of a social event than typically is the case with conventional games or contests that are played on a personal device.
  • the times that the problems are to be delivered are not known in advance, an even heightened level of excitement, spontaneity and social connectedness often can occur.
  • the individual players preferably have the ability to: check their point totals; check rankings or standings; view detailed statistics and even photographs of the leaders; view answers to, and/or strategies for approaching, previous problems; review performance statistics; generate customized reports regarding how individual players performed with respect to specified criteria; browse results from other contests; register for additional contests; and spend the points that they have accumulated.
  • a number of the foregoing items can be particularly important when “powering” is involved, as discussed in the following paragraphs.
  • One novel variation is the ability for individual players to “power” with at least one other player. More preferably, each player has the ability to power with one other player, of his or her own choosing, at a time. In such a case, the “powering player” (the one who makes the selection) is awarded points based on the points earned by the player with whom he or she powered (the “leader”) and vice versa. Thus, by powering with a very good player, an individual can significantly boost his or her points. Conversely, if a player can get a large number of other players to power with him or her, his or her own point total can be significantly enlarged.
  • a leader's point total typically will depend not only on how successful he or she is at responding to problems, but also how successful he or she is in attracting others to power with him or her.
  • the powering player cannot result in a net loss of points to the leader (even in embodiments in which penalties are assessed against the responding player for incorrect responses), but instead only adds any net point gain earned during the powering relationship.
  • the leader's both positive and negative point earnings preferably also are attributed to the players who have powered with that leader (although in the preferred embodiments, any player's point score can never fall below zero).
  • the powering player can also derive other benefits by powering with good leaders.
  • a powering player preferably is permitted to continue playing so long as the leader remains in the tournament, even if the powering player would not have qualified for continued play by himself or herself.
  • Dotz are awarded to or subtracted from the player based on the individual player's own correct and incorrect responses and based on the number of Dotz assigned to each individual problem.
  • the same number of Dotz is added or subtracted based on the leader's answer to the problem.
  • the player can pull back his or her Dotz from the leader at any time or switch them to another leader, although the player cannot leave and then return to the same leader during a contest.
  • the leader receives a number of PowerUp points equal to the total number of Dotz earned by all players who currently are powered with the leader, but does not lose PowerUp points when a powering player answers incorrectly (or at least does not incur a net loss due to any given powering player as a result of the powering relationship; in certain sub-embodiments, PowerUp points contributed by a powering player can later be lost by incorrect responses given by that same powering player).
  • a player can power up his or her Dotz with a leader, but not any PowerUp points that he or she has earned (as a result of other players powering up with him or her).
  • Each player's game score is equal to that player's Dotz plus his or her PowerUp points.
  • Dotz are awarded to each player on a sliding scale based on overall rank in the contest and/or the absolute number of game points that particular player has, and the total number of Dotz can be exchanged for prizes (e.g., products or services).
  • An example of such a sliding scale 200 is shown in FIG. 9 , which includes rows for final game score 202 , number of players 204 and Dotz earned 205 based on game score.
  • Dotz are earned based on rank: the player with the largest number of game points gets 1,000,000 Dotz, the next five highest get 500,000, the next 10 highest get 100,000, and so on, with the game score cut-offs 202 being determined only upon completion of the contest.
  • the game score cut-offs 202 are fixed and the number of players who fall within each range varies from contest to contest.
  • any other conversion technique using any combination of overall rank and total number of game points may be used.
  • the powering players might receive only a specified percentage (or some other function) of the points earned by the leader and/or vice versa.
  • a player might incur a cost for powering (e.g., a loss of 50% of the points he or she otherwise would earn, meaning that it would only make sense to power if one thought that the leader would perform better than the powering player).
  • the leader preferably has some control over which players power with them.
  • the general concept of powering is that an individual player has the ability to associate with one or more other players for a desired period of time and then flexibly switch associations as desired, potentially benefiting from the successes of the associated players (and in certain embodiments potentially being harmed by the losses of the associated players).
  • Another preferred feature of powering is that individual players have an incentive to attract other players to power with them.
  • contests according to the present invention can include flexibly constituted teams.
  • the performance of a team as a whole affects the point accumulation of its individual members, for any periods of time that such members are in fact affiliated with the team. While similar in some respects to powering, such a team approach lacks a direct one-to-one relationship between individual players and a leader, instead potentially leading to dynamics in which small ad hoc clusters of individuals are more likely to form.
  • the contest includes rules regarding the structure of the resulting groups and how individual players within the groups accumulate points.
  • the rules might create a multi-level point-earning structure within each group such that the leader earns the highest percentage, the next level down (perhaps limited to a fixed number of people) the next highest percentage, and so on.
  • Such a structure could lead to intense negotiations about who is assigned to what level, with the risk that any individual player might defect to a different group (or leader) if he or she feels a better deal can be obtained.
  • the present invention contemplates contests that test the players across wide ranges of knowledge and skill, and as well as special-interest contests, such as contests targeted toward any specific area of interest, knowledge or skill (e.g., sports or entertainment), or any particular demographic (e.g., children, tweens or teens).
  • the contest can be implemented as a competition with identified winners and potentially bonus points or prizes at the end (typically referred to as a tournament), as a time-limited opportunity to accumulate points which can be exchanged for products or services, or as a combination of both.
  • a tournament typically referred to as a tournament
  • the individual players having the highest point totals, together with any players who have powered with them are invited to participate in an elimination tournament, e.g., with the powering players remaining in the tournament as long as their leader does.
  • the rules can be constructed such that at any stage only the player's earned points are considered (excluding any powered points), all of the player's points are considered (including the powered points), or any (e.g., weighted) combination of the two is considered.
  • broadcast media traditionally have been used for this purpose in the past, broadcast media are inherently limited in that the audience must have access to the media and be tuned in at the time an announcement is made. Also, broadcast media having low latency variability (such as television or cable broadcasts) generally are not suitable for small-scale releases of information.
  • the preferred embodiments of the present invention do not require connectivity at the time a message is delivered, and can permit delivery of a message using a wide range of different devices. Accordingly, a recipient can be more certain that he or she will get an important message at the same time everyone else does. Situations where such substantially simultaneous communications are important include announcement of certain economic and financial news.
  • Another category of use is where some coordinated activity is desired.
  • the user devices for all participants wake up or activate at substantially the same time, prompting all such participants into action.
  • This feature can be useful, for example, as an alert that an item being monitored on an on-line auction has just entered the last five minutes of the auction. In such a case, although the initial announcement generally would not require network connectivity, some connectivity typically would be required to actually submit a bid.
  • Still further applications of the present technology include: sprinkler systems that can be re-programmed remotely; simultaneous opening of locks at banks or other establishments; real-time synchronized traffic light control for efficient traffic flow; updating of electronic billboard content; control of school exams throughout a state or other geographic region; simultaneous adjustment of supermarket pricing at a large number of stores; hotel alarm clocks; simultaneous real-time downloading of prescribed changes in rates to electric meters or other utilities, e.g., giving users a financial incentive to consume during off-peak hours; controlling or timing other aspects of game playing; medication dispensing control (e.g., timing and schedule updating); real-time polling (e.g., Neilson Television Polling) in order to capture instantaneous reactions (e.g., with incentives for the participants to respond immediately) or to track changing reactions over time by capturing reactions at a sequence of points; and in-store promotions (e.g., blasting a promotion to all subscribers to come to the store to purchase any item for a prescribed discount).
  • in-store promotions e.g., blast
  • Another use of the present technology is in conjunction with broadcast programming.
  • content related to a broadcast program e.g., television or radio show
  • the specific messages that are delivered preferably depend upon selections made by the user 31 - 35 on his or her device 21 - 26 .
  • an interactive experience can be created without any special-purpose hardware or any connectivity other than the ability to see the broadcast.
  • even the broadcast has been recorded, with the program recorder/replayer's clock having been synchronized to the clock of the user device, e.g., in the manner described above for user device 25 .
  • Note that such embodiments use the present technology for personalized message delivery, rather than substantially simultaneous mass delivery of a common message.
  • a still further use of this technology is for conducting a real-time audience-participation contest over a broadcast medium.
  • the broadcaster transmits (e.g., broadcasts) a wake-up signal to a number of different user devices 21 - 26 .
  • the user devices 21 - 26 wake up and allow their corresponding users to begin playing, preferably at the same time opening up a communication channel with the server 12 .
  • the wake-up signal and the problem to be solved may be transmitted in real-time or transmitted in advance and stored on the corresponding devices 21 - 26 , as discussed in detail above.
  • the wake-up signal may be provided to all eligible players or only to a (e.g., randomly selected) portion of them.
  • the problem is delivered to all of the audience members (e.g., via television broadcast) at the same time as it is delivered to the participating players, although preferably only the responses of the participating players affect the outcome of the contest.
  • the user devices 21 - 26 preferably time the user responses locally so as to avoid any communication latency discrepancies among the various user devices 21 - 26 , with the resulting responses and response times being transmitted back to the server 12 .
  • Such devices typically will include, for example, at least some of the following components interconnected with each other, e.g., via a common bus: one or more central processing units (CPUs); read-only memory (ROM); random access memory (RAM); input/output software and circuitry for interfacing with other devices (e.g., using a hardwired connection, such as a serial port, a parallel port, a USB connection or a firewire connection, or using a wireless protocol, such as Bluetooth or a 802.11 protocol); software and circuitry for connecting to one or more networks (e.g., using a hardwired connection such as an Ethernet card or a wireless protocol, such as code division multiple access (CDMA), global system for mobile communications (GSM), Bluetooth, a 802.11 protocol, or any other cellular-based or non-cellular-based system), which networks, in turn, in many embodiment
  • CDMA code division multiple access
  • GSM global system for mobile communications
  • Bluetooth Bluetooth
  • 802.11 protocol any other cellular-based or non-cellular-based system
  • the process steps to implement the above methods and functionality typically initially are stored in mass storage (e.g., the hard disk), are downloaded into RAM and then are executed by the CPU out of RAM.
  • mass storage e.g., the hard disk
  • the process steps initially are stored in RAM or ROM.
  • Suitable devices for use in implementing the present invention may be obtained from various vendors. In the various embodiments, different types of devices are used depending upon the size and complexity of the tasks. Suitable devices include mainframe computers, multiprocessor computers, workstations, personal computers, and even smaller computers such as PDAs, wireless telephones or any other appliance or device, whether stand-alone, hard-wired into a network or wirelessly connected to a network.
  • Suitable devices include mainframe computers, multiprocessor computers, workstations, personal computers, and even smaller computers such as PDAs, wireless telephones or any other appliance or device, whether stand-alone, hard-wired into a network or wirelessly connected to a network.
  • any of the functionality described above can be implemented in software, hardware, firmware or any combination of these, with the particular implementation being selected based on known engineering tradeoffs. More specifically, where the functionality described above is implemented in a fixed, predetermined or logical manner, it can be accomplished through programming (e.g., software or firmware), an appropriate arrangement of logic components (hardware) or any combination of the two, as will be readily appreciated by those skilled in the art.
  • the present invention also relates to machine-readable media on which are stored program instructions for performing the methods and functionality of this invention.
  • Such media include, by way of example, magnetic disks, magnetic tape, optically readable media such as CD ROMs and DVD ROMs, or semiconductor memory such as PCMCIA cards, various types of memory cards, USB memory devices, etc.
  • the medium may take the form of a portable item such as a miniature disk drive or a small disk, diskette, cassette, cartridge, card, stick etc., or it may take the form of a relatively larger or immobile item such as a hard disk drive, ROM or RAM provided in a computer or other device.
  • the foregoing description refers to clicking or double-clicking on user-interface buttons, dragging user-interface items, or otherwise entering commands or information via a particular user-interface mechanism and/or in a particular manner. All of such references are intended to be exemplary only, it being understood that the present invention encompasses entry of the corresponding commands or information by a user in any other manner using the same or any other user-interface mechanism. In addition, or instead, such commands or information may be input by an automated (e.g., computer-executed) process.
  • functionality sometimes is ascribed to a particular module or component. However, functionality generally may be redistributed as desired among any different modules or components, in some cases completely obviating the need for a particular component or module and/or requiring the addition of new components or modules.
  • the precise distribution of functionality preferably is made according to known engineering tradeoffs, with reference to the specific embodiment of the invention, as will be understood by those skilled in the art.

Abstract

Provided, inter alia, is a type of contest in which, at various intervals, geographically dispersed players attempt to answer the identical problem at substantially the same time. In representative embodiments, problems (typically, questions) are made available at seemingly random times throughout the day (or throughout some specified time interval), and players have the opportunity either to respond to the problem or (e.g., in the event that a given player is occupied when a particular problem arises) to pass on the current problem and wait for another one. In such embodiments, more questions are made available than the players are permitted to answer in accordance with the rules of the game, so that players have flexibility as to when they participate.

Description

  • This application is a continuation of U.S. patent application Ser. No. 11/539,179, filed Oct. 6, 2006, which in turn claims the benefit of U.S. Provisional Patent Application Ser. No. 60/724,473, filed on Oct. 6, 2005, and titled “Real-Time Incentivized Game Platform”, which applications are incorporated by reference herein as though set forth herein in full.
  • FIELD OF THE INVENTION
  • The present invention pertains to a contest that is played substantially simultaneously by a number of players.
  • BACKGROUND
  • A variety of different kinds of games and contests exist. However, people constantly are looking for new ways in which to compete with others.
  • SUMMARY OF THE INVENTION
  • The present invention addresses this need by providing, inter alia, an entirely new type of contest in which, at various intervals, geographically dispersed players attempt to answer the identical problem at substantially the same time. In representative embodiments, problems (typically, questions) are made available at seemingly random times throughout the day (or throughout some specified time interval), and players have the opportunity either to respond to the problem or (e.g., in the event that a given player is occupied when a particular problem arises) to pass on the current problem and wait for another one. In such embodiments, more questions are made available than the players are permitted to answer in accordance with the rules of the game, so that players have flexibility as to when they participate.
  • Thus, in one aspect the invention is directed to systems, methods and techniques for implementing a simultaneous, but intermittently played, contest. Initially, a problem is delivered substantially simultaneously to geographically dispersed players, the problem being identical for all players. Responses to the problem are received from the players, the corresponding response times are measured, and scores are determined for the players based on the responses and corresponding response times. The foregoing steps are then repeated a plurality of times, with a median time interval between delivery of consecutive problems being at least 30 minutes, and with an aggregate score being maintained for each of the players.
  • The foregoing summary is intended merely to provide a brief description of the general nature of the invention. A more complete understanding of the invention can be obtained by referring to the claims and the following detailed description of the preferred embodiments in connection with the accompanying figures.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates an overview of an alert system according to a representative embodiment of the present invention.
  • FIG. 2 illustrates communication between a user device and a server according to a representative embodiment of the present invention.
  • FIG. 3 is a block diagram showing some of the components of a user device according to a representative embodiment of the present invention.
  • FIG. 4 illustrates an example of alert information and time synchronization information according to a representative embodiment of the present invention.
  • FIG. 5 is a flow diagram illustrating an overview of a process for implementing an alert system according to a representative embodiment of the present invention.
  • FIG. 6 is a flow diagram illustrating a process for conducting a contest according to a representative embodiment of the present invention.
  • FIG. 7 illustrates an initial user interface questioning whether a player wants to participate in the current problem in a contest according to a representative embodiment of the present invention.
  • FIG. 8 illustrates a user interface for presenting a problem and accepting a response to it in a contest according to a representative embodiment of the present invention.
  • FIG. 9 illustrates a sliding scale for conversion of game points to Dotz according to a representative embodiment of the present invention.
  • DESCRIPTION OF THE PREFERRED EMBODIMENT(S)
  • This application is related to commonly assigned U.S. patent application Ser. No. 11/539,180, filed Oct. 5, 2006 and titled, “System For Substantially Simultaneous Alerts”, now U.S. Pat. No. 7,805,151. That application is incorporated by reference herein as though set forth herein in full.
  • The present disclosure is divided into sections. The first section describes certain technological considerations for implementing contests and other methods of the present invention. The second section describes an exemplary contest that may be implemented using such platforms. Subsequent sections provide additional information, as indicated by their headings.
  • Substantially Simultaneous Alert Technology.
  • Many of the techniques of the present invention require that a message be delivered substantially simultaneously to a large number of geographically dispersed (e.g., spread across different cities, states or even countries) individuals or devices. FIG. 1 illustrates an overview of an alert system 10 for achieving this goal, according to a representative embodiment of the present invention.
  • Generally speaking, a central server 12 drives the alert system 10, communicating with a plurality of different user devices (e.g., devices 21-26). Each such device 21-26 typically has a user associated with it (e.g., user 31 for device 21 and user 32 for device 22). In some cases, a single user (e.g., user 33) has two or more user devices (e.g., devices 23 and 24) that are registered with server 12, as discussed in more detail below.
  • Server 12 may be implemented as a single physical device, but more commonly will be implemented as a server cluster, with redundancy, appropriate load-sharing hardware and software, and different functionality distributed across different physical boxes, as is well known in the art. In one embodiment, different physical devices are used for communicating across different kinds of networks (e.g., directly over the Internet, by SMS messaging, or using a proprietary wireless protocol).
  • It is noted that although only six user devices 21-26 are illustrated in FIG. 1, this is for ease of illustration only. Typically, there will be many more user devices that participate in the alert system 10, such as more than 50, 100, 500, 1,000 or even 10,000 such devices (as well as a similar number of users). Also, the same server 12 can be used to handle multiple alert systems, e.g., using different distribution lists and different back-and processing routines for such different systems.
  • Each user 31-35 preferably has pre-registered with server 12 for the current alert system 10, designating the device(s) on which such user 31-35 will be receiving the alerts, as well as the manner in which server 12 is to communicate with such device. In this latter regard, the present invention contemplates multiple different modes of communication between server 12 and the various user devices 21-26.
  • The most commonly anticipated communication mode will involve the use of a wireless network 41, so that the corresponding user device 21 will be more likely to be able to communicate with server 12 at any time of day. However, as discussed in more detail below, the preferred embodiments of the present invention do not require real-time communication in order to function as intended.
  • A variety of different specific communication techniques may be implemented over a wireless network 41. For instance, messages may be sent via short messaging service (SMS), using wireless Web communications, or using any of the other wireless data protocols (whether public or proprietary) that are supported by the particular wireless carrier.
  • Another commonly anticipated communication mode involves direct Internet communications 42. This general mode also can be used to convey information using any of a variety of different specific protocols, such as hypertext transfer protocol (HTTP), file transfer protocol (FTP), any proprietary data-transfer protocol, or even instant messaging or e-mail messaging protocols.
  • As noted above, in certain cases a single user 33 will register multiple different devices 23 and 24 with server 12 for participation in a particular alert system 10. Moreover, as shown in FIG. 1, multiple different communication paths 43 may be used for the different devices 23 and 24 (e.g., a wireless network for device 23 and a direct Internet connection for device 24).
  • The user 33 preferably has the ability to designate multiple devices 23 and 24 as both being currently active, so that when the alert occurs it will be delivered by both devices, thereby maximizing the likelihood that the user 33 will be in the vicinity of one of such devices 23 and 24 at the appropriate time. Alternatively, the user 33 preferably also has the ability to designate only a single one of the devices 23 and 24 to deliver the message, e.g., depending on when the message is to be delivered. In such a case, the user 33 preferably defines a schedule, indicating which device 23 and 24 is active at which times. In addition, more than two devices 23 and 24 may be registered, and the user 33 preferably can designate any number as being active at a given time.
  • Still further, it also is possible for server 12 to communicate with a non-networked device 25 (operated by user 34), e.g., by using a direct connection 44. Examples include transferring the required data using a point-to-point cable, wireless connection (e.g., infrared or Bluetooth) or cradle. It is noted that such direct delivery 44 generally will constitute only one of the steps in the overall delivery process, such as where server 12 downloads the required information to a networked computer or other device which, in turn, directly transfers it to user device 25.
  • Finally, server 12 may communicate with a user device 26 via a broadcast medium (a wireless broadcast, e.g., using radio frequencies, and/or a hardwired broadcast, e.g., using television cable or Internet broadcasts). In the illustrated embodiment, the user device 26 is an interactive television, but any other kind of device instead may be used for receiving such broadcasts, including a general-purpose computer or a cellular telephone.
  • The specific ways described above for server 12 to communicate with the various user devices 21-26 should be understood as being exemplary only. Any other communication modes or paths instead, or in addition, may be used. Also, any combination of different paths or modes may be used.
  • FIG. 1 illustrates one-way communication between the server 12 and the various user devices 21-26. However, in certain preferred embodiments of the invention, communication is bidirectional between server 12 and user devices 21-26.
  • This is illustrated in FIG. 2, which shows an exemplary user device 21 in communication with server 12. As discussed in more detail below, in such embodiments server 12 typically communicates alert information 61 and time synchronization information 62 to user device 21, and user device 21 typically communicates a response 63 to such alert information 61 back to server 12. According to the preferred embodiments of the invention, such communications can occur over significant time intervals and often will vary significantly from one user device 21 to another of the user devices 22-26. Such variations often will be common even where all of the user devices 21-26 are delivering the message 61 at substantially the same time and allowing the corresponding users 31-35 to submit their responses 63 at substantially the same times. More specifically, in the preferred embodiments the alert information 61 may be stored on user device 21 at any time prior to the scheduled delivery and the response may be transmitted back to server 12 at any time after it has been submitted by the corresponding user 31. In addition, the various types of information may be transmitted using different communication channels.
  • FIG. 3 is a block diagram showing certain portions of an exemplary user device 21 according to a representative embodiment of the present invention. In the present embodiment, user device 21 has installed on it an alert-based client application 80 that performs all or nearly all of the special functionality associated with the present invention. Preferably, application 80 is implemented entirely in software (e.g., as a Java midlet or Brew application), but instead may be implemented in any of the other ways discussed herein.
  • As shown, application 80 communicates with the input/output interface 82 of the device 21. Depending upon the particular device 21, interface 82 generally will be comprised of hardware and software components for communicating, e.g., across a TCP/IP (Transmission Control Protocol/Internet Protocol) network and/or across a wireless communications channel (e.g., cellular-based, any of the 802.11x family of protocols, Bluetooth, infrared, or the like). Generally speaking, input/output interface 82 provides the primary communication link between client application 80 within device 21 and server 12.
  • As discussed in more detail below, application 80 stores certain information that it receives via interface 82 into device memory or storage 83 (preferably non-volatile) until an appropriate time, such as the designated delivery time. Application 80 preferably also monitors device clock 85 and real-time clock 86. In this regard, device clock 85 typically is a hardware device that provides timing clock signals for synchronous processing by the various hardware components of device 21 (e.g., including a general-purpose processor executing application 80). On the other hand, real-time clock 86 typically is implemented as a software application and provides the actual time of day, e.g., for reference by the corresponding user 31 and for time-stamping certain data items within device 21.
  • FIG. 4 illustrates one example of a packet 90 containing alert information 61 and time synchronization information 62 according to a representative embodiment of the present invention. In the present example, synchronization information 62 includes a single timestamp reflecting the current time maintained by server 12 (here, stated to the nearest 0.01 second). The alert information 61 includes a number of entries 91-93, each having a corresponding delivery time 95 and message 96. Although three such entries 91-93 are illustrated, any other number instead may be transmitted at a single time. In addition, although the synchronization information 62 is illustrated as being transmitted in the same packet 90 as the alert information 61, they instead can be transmitted in separate packets. Furthermore, in the present example the messages 96 are questions; however, as discussed in more detail below, any of a variety of different types of messages instead may be included.
  • FIG. 5 is a flow diagram illustrating an overview of a process for implementing an alert system according to a representative embodiment of the present invention. This process preferably is implemented entirely in software (with step 100 typically being performed by server 12 and the other steps typically being performed by client application 80), but instead may be implemented in any of the other ways discussed herein. Also, the process generally is discussed in the context of the hardware configurations shown in FIGS. 1-3. However, it should be understood that such references are for convenience and ease of understanding only and therefore are merely exemplary in nature.
  • Initially, in step 100 the server 12 transmits alert information 61 and time synchronization information 62 to a plurality of user devices 21-26. Preferably, at least the alert information 61 is transmitted in an encrypted format, in order to prevent early discovery by the eventual recipients 31-35. Currently, the preferred encryption technique is AES (Advanced Encryption Standard), but any other secure type of secure encryption can be utilized.
  • In one embodiment, the alert information 61 and time synchronization information 62 are transmitted to all of the user devices 21-26 simultaneously, or substantially simultaneously. In an alternate embodiment, such information is transmitted to the various user devices 21-26 at different times. The latter approach is particularly preferred if latency times are expected to vary in an amount that exceeds the desired tolerance in terms of how closely in time the individual messages 96 are desired to be delivered. In such a case, the latency differences (e.g., the time differences between when the various devices 21-26 actually receive the synchronization information 62) will translate directly into synchronization inconsistencies among the various devices 21-26. Transmitting at least the synchronization information 62 individually to each user device 21-26 can allow for the latency to that device to be estimated and accommodated to some extent.
  • If, for example, the transmission latency is variable and may be larger than the desired tolerance, an alternate technique may be employed to estimate the latency between the server 12 and the individual devices 21-26, thereby allowing correction for such latency. Rather than simply transmitting a synchronization time, the server 12 might first send out one or more probe packets to a subject user device 21, with the client application 80 having been configured to automatically transmit a response packet, resulting in a kind of pinging of the subject user device 21. Then, assuming that transmission latency is symmetric, the server 12 need only divide the round-trip latency (or the average round-trip latency if more than one packet was sent) by two and then adjust the transmitted synchronization time 62 (e.g., by simply adding such quantity) in order to compensate for the expected one-way latency.
  • Alternatively, any other technique may be used to estimate and adjust for expectant latency. Also, in certain cases transmitting the synchronization time 62 separately from the alert information 61 might be useful in reducing latency time, particularly where the alert information is voluminous relative to transmission bandwidth.
  • The construction of the alert information 61 typically is relatively straightforward. A user or a separate automated process supplies server 12 with one or more messages 96 that are to be distributed to a specified group of user devices 21-26 for delivery at one or more specified delivery times 95. The list of devices 21-26 may be generated by reference to user preference information indicating which devices are intended to be active at the scheduled delivery times. Such alert information 61 may then be delivered (preferably in encrypted form) at any time prior to the earliest specified delivery time 95.
  • It is noted that step 100 is shown differently than the other process steps illustrated in FIG. 5. This is because step 100 generally can be performed at any time during the overall process, e.g., whenever server 12 has a new alert 61 to be pushed out. In addition, step 100 preferably also as performed upon request either by the server 12 or by the alert-based client 80 running on the user device 21, e.g., in order to check for any clock tampering in an attempt to have the message delivered early.
  • Thus, step 100 generally stands outside of the normal process flow, although it preferably is initiated from the sleep or background mode (as described below) under normal circumstances. Nevertheless, step 100 preferably is executed as the first step of the present process in order to achieve an initial time synchronization and download of alert information 61.
  • Next, in step 102 client 80 waits until it is time to check the real-time clock 86. At the outset, it is noted that the present embodiment contemplates a “sleep” or “background” mode in which client 80 performs minimal processing. One of the functions that preferably is performed by client 80 during the sleep mode is to periodically check the real-time clock 86 in order to determine whether it is time to deliver a message and to confirm accuracy. The wait in this step 102 preferably is equal to a fixed number of the clock cycles generated by device clock 85.
  • In this regard, the counting of clock cycles can be performed in software. Alternatively, to avoid unnecessary processor use, a simple hardware counter can be used, e.g., one which generates an interrupt signal when the desired count has been reached. In the preferred embodiments, client 80 checks a real-time clock 86 approximately every five minutes.
  • In step 104, client 80 reads the current value of the real-time clock 86 and checks for any variances or potential tampering. For the reasons indicated elsewhere in this disclosure, there often may be significant incentives to learning certain information (e.g., contest questions or financial news) prior to the intended delivery time. Accordingly, the present invention preferably uses a number of measures to detect and correct tampering and normally occurring time discrepancies.
  • As indicated above, client 80 preferably has access to at least three different time indicators. The first one, the synchronization time 62 provided by server 12 generally will be the most accurate, but the least frequently updated. The second, the set of periodic clock-check signals based on the device clock 85, does not provide absolute time, but provides an indication of time-interval durations. The third, the real-time clock 86 provides the most current indication of absolute time, but that measurement might be out of sync with the clock maintained by server 12 and frequently will correspond to a different time zone. In addition, at least the second and third sources potentially are subject to user manipulation. In order to maintain time-synchronization integrity, in this step 104 client application 80 preferably looks for any anomaly between the three sources, whether manifested as a constant bias, a steady drift or a sudden change.
  • For example, if the real-time clock 86 indicates a jump in its stated time between two adjacent check signals, and such jump is sufficiently different from the expected time interval (or even a movement backward), then a tamper condition might be declared. Alternatively, if the difference is not too far out of specification, then the condition might be monitored further (e.g., during the next couple of clock checkpoints) to determine whether the real-time clock 86 of the user device 21 is simply running excessively faster or slower than it should be (e.g., outside of a specified tolerance). Of course, such a situation also could be a result of a more subtle attempt to manipulate the time stated by real-time clock 86. In any event, preferably at a minimum each message-delivery time 95 (or, alternatively, an internal clock correction) is adjusted to account for any detected difference.
  • In step 106, a determination is made as to whether a reset is desired. Such situations can include, e.g., either (i) where the difference between what the real-time clock 86 says and what would be expected by virtue of the periodic check signals based on the device clock 85 is excessive; or (ii) where the applicable tolerances in the device clock 85 and the real-time clock 86 make it difficult to establish which is most representative of the correct time. In addition, or instead, a reset determination can be made arbitrarily, at fixed time intervals, or randomly, in an attempt to identify more elaborate tampering schemes.
  • If such a determination is made in this step 106, then processing returns to step 100 in order to request a new time synchronization signal 62 (if such on-demand requests are supported in the applicable embodiment) or simply wait for the next scheduled time synchronization signal 62 from server 12 (disabling the applicable user device from the alert system until such synchronization occurs). If a reset is not required (e.g., values are within tolerances and/or a determination otherwise is made that the discrepancies appropriately can be handled by an adjustment), then processing simply proceeds to step 108.
  • Although not shown in FIG. 5, an affirmative determination of tampering preferably causes client application 80 to notify server 12 and disqualifies the corresponding user from participating in any further system alerts. At the same time, in certain cases the time stated by real-time clock 86 will be significantly different than the actual time without any intentional tampering. Such a condition might occur, for example, where the device 21 has been reset and does not have a connection to its wireless carrier, so its real-time clock 86 might be reset to an arbitrary or default time (e.g., 12:00 p.m.). The logic for declaring a tamper condition preferably checks for and takes into account all such conditions or, at the very least, allows a certain number of unexplained discrepancies before declaring a tamper condition.
  • In the embodiment discussed above, client application 80 maintains a time offset figure indicating the difference in time between real-time clock 86 and the clock maintained by server 12. Equivalently, application 80 could maintain its own internal real-time clock, e.g., using input from all of the three sources indicated above.
  • In step 108, a determination is made as to whether it is time for the device 21 to wake up from its sleep mode. An affirmative determination in this regard preferably is made if a message is scheduled to be delivered within a specified amount of time (e.g., within 2-10 seconds) or, in certain cases, prior to the next clock-check signal or within a specified margin after it. If the determination is negative, then processing returns to step 102 to await the next clock-check signal. If positive, then processing proceeds to step 110.
  • In step 110, any of a variety of different types of processing may be performed. Initially, client application 80 preferably brings forward at least some portion of its user interface (preferably overriding any conflicting user interfaces). Generally speaking, the first goal of the user interface in this instance is to capture the user's attention. Accordingly, it is preferable to include some warning signal indicating that a message is about to be delivered. Such a signal preferably comprises an audio alarm, but also could include vibration or other tactile sensations, or even visual cues. The 2-10 seconds mentioned above in connection with step 108 is intended primarily to accommodate such a warning signal (as well as to make the other preparations required for delivering the message on schedule). It is noted that the warning signal is particularly important, and preferably is somewhat longer, in embodiments where the time that the message is to be delivered is not known in advance.
  • Ordinarily, the user interface also will include some visual display elements, such as a text message or a logo. However, in certain cases all messages are provided entirely by sound (e.g., using synthesized or sampled speech for devices with a small or nonexistent display), or even entirely by vibration or other tactile sensation (e.g., for the visually impaired).
  • Also, in certain embodiments of the invention the warning signal is accompanied by an opt-out or opt-in message and corresponding period of time during which the user 31-35 can elect to receive the message or elect not to receive the message (depending upon the selected default setting). An opt-in system generally is preferred, particularly where the users 31-35 are only permitted to receive a limited number of messages, where they are required to pay for each message received and/or where the messages are sensitive and therefore should not be seen by others.
  • Then, preferably just before the delivery time 95, assuming the user has opted to receive the message 96, the message 96 is decrypted and delivered to the user 31-35. The net effect of multiple user devices 21-26 implementing similar client applications 80 is that all of the users 31-35 will receive the message at substantially the same time. As used herein, the expression, “substantially the same time” and similar expressions with respect to delivery of a message are intended to mean close enough in time such that, ordinarily (e.g., assuming a properly functioning system and no inappropriate tampering), recipients generally will not be significantly advantaged by virtue of having received the message earlier or disadvantaged by receiving the message late. For most embodiments contemplated hereunder, the term will correspond to distribution to all recipients within a time window having a maximum duration of approximately 1-3 seconds.
  • In addition to simply providing a message 96, certain embodiments of the invention provide functionality for allowing the users 31-35 to respond to the message 96. More preferably, such embodiments display a response interface (e.g., one or more clickable or otherwise selectable buttons, objects that can be dragged and/or a field for entering text) on the same user interface as that on which the message 96 is displayed. Depending upon the particular embodiment, as well as the time-sensitivity of the response, the response information preferably either is immediately transmitted to the server 12 or else is saved into memory/storage 83 (e.g., in encrypted form) for later transmission to server 12.
  • Upon completion of step 110, processing returns to step 102 in order to begin waiting for the next message delivery.
  • Although the foregoing technology is discussed within the context of simultaneous delivery of a message to multiple individuals, its use is not so limited. Rather, as should be readily apparent, the foregoing technology also can be used for any time-controlled disclosure of information, even where the recipients are receiving it at different scheduled times. Similarly, the foregoing technology is not limited to disclosures to natural persons; in addition, it can be used, e.g., for time-controlled release of information to an automated process. Exemplary uses in this latter respect include electronic funds transfers and electronic payment systems.
  • The foregoing discussion concerns a particular technique for substantially simultaneous delivery of a message to a number of geographically dispersed recipients. The following two sections describe systems and methods that use such substantially simultaneous delivery of a message. While the approaches described above for achieving the desired substantially simultaneous delivery presently are preferred, the systems and methods described below also may be implemented using any of a variety of other approaches.
  • For example, where latency is not a significant factor in relation to the required time frame for delivering a message to the recipients, a direct broadcast of such information can be used. Alternatively, in such situations the message itself can be transmitted in advance (e.g., in encrypted form) and only a release signal broadcast by the server 12 (or any other device) when it is time for delivering the message. Still further, a broadcast message can be used simply to wake up a client application on each of one or more user devices; thereafter, a communication channel is opened between each such user device and the server 12, or even among all (or any subset) of such user devices and/or the server 12.
  • In an alternate embodiment, a different form of push technology is used. For example, a SMS message can be used to “wake up” each client application 80, with the server 12 then receiving confirmation of receipt of that SMS.
  • In another embodiment, preprogrammed alerts pop up on the user's device 21-26 (e.g., using the device's timer) and invite the user 31-35 to click a button to retrieve a message. One click opens direct (e.g., HTTP) access to the server 12 to retrieve the desired content.
  • In a still further embodiment, the subject content is broadcast in real time to all users 31-35. Such users 31-35 then respond via broadband.
  • Substantially Simultaneous Intermittent Contest.
  • FIG. 6 is a flow diagram illustrating a process for conducting a contest according to a representative embodiment of the present invention. Generally speaking, the contest according to FIG. 6 is played substantially simultaneously by a number of geographically dispersed players at intermittent points in time. Each player participates by using a (typically network-accessible) device, which may include, e.g., an Internet-accessible computer, a wireless telephone or a wireless personal digital assistant (PDA), as shown in FIG. 1. It is noted that if a technology platform according to the preferred embodiments of the preceding section is used, then it is not necessary for a player's device to be actually connected to a network at the particular moments that active play occurs. Such technology currently is preferred for implementing the present contest, with the contest's problems being the delivered messages, the player devices corresponding to user devices 21-26, and the contest server corresponding to server 12. Accordingly, for ease of explanation, the following discussion assumes such an implementation. However, such references are exemplary only.
  • Preferably, the contest is played over an extended period of time, such as anywhere from several days to a month, or even longer. As discussed in more detail below, the contest involves a number of problems, which may include multiple-choice or other types of questions. Preferably, each problem is made available to all of the players at substantially the same time, and multiple problems are made available each day of the contest. In order to address the situation that everyone will not necessarily be able to play at the same time, more problems preferably are made available than the number of problems that each player is permitted to respond to, under the rules of the contest.
  • Initially, upon the beginning of the contest there is a period of waiting 131 for the first problem to be delivered. In the preferred embodiments of the invention, neither the problems nor the times at which they are to be delivered are known to the players in advance. From the players' perspectives, the problems preferably are delivered at random times during the day, or during some specified window of time during the day. When that window occurs preferably depends upon the time zones in which the players are expected to be located. In alternate embodiments of the invention, the particular times, or at least some of the times, when the problems are delivered are known in advance by some or all of the players.
  • A feature of the present contest is that problems are delivered at intermittent times over an extended period of time. For example, the intervals between problems typically will be at least 30 minutes and often will be 1-2 hours or even longer, thereby contributing to the randomness of the play. More generally, the median time between delivery of problems preferably is at least 30 minutes, 60 minutes or two hours. In addition, the contest typically will go on for at least three days, a week, two weeks, a month or even longer. In the preferred embodiment, each contest is one month long with three or four problems each day (potentially excluding certain weekend days and/or holidays), but with the players allowed to respond to only one problem each day.
  • In any event, shortly before a problem is scheduled to be delivered, in step 132 a user interface is provided to all of the players via the players' devices. In the preferred embodiments, the user interface preferably includes an alert signal which, in turn, preferably includes an audio component, such as a contest-specific ring tone. It is noted that the exact timing of the alert signal (if provided) generally is not as sensitive as delivery of the actual problem, provided that the various players receive roughly the same amount (or even some minimum amount) of advance warning.
  • At the same time, the user interface preferably queries whether the player wants to respond to this problem or to pass on it. An exemplary user interface 170 is illustrated in FIG. 7. As shown, interface 170 includes a message 171 notifying the player that a new problem is about to be delivered and asking whether the player wants to participate in the problem. A pair of radio buttons 173 allows the player to designate his or her choice, with a timer 175 indicating the remaining time until the default option (or the currently selected option if the player has highlighted the other option) is selected. In the preferred embodiments, the default (which occurs if no response is given by the player) is to assume that the player is passing on the problem (as indicated in FIG. 7). In a representative embodiment, the timer 175 starts at approximately 4-7 seconds and counts down.
  • Thus, referring back to FIG. 6, in step 134 the players who will be participating in the present problem are identified (e.g., all of those who have opted to receive the problem). In the preferred embodiments, the players do not get any information about the problem, or at least do not obtain the problem itself, before deciding whether to participate. In alternate embodiments, the players may be given some limited information about the problem along with the alert, such as the general category to which the problem pertains. As a result, in such alternate embodiments the players can decide whether to participate based on factors other than mere convenience (e.g., their comfort level with the general category).
  • In still further embodiments, the players either do not have any option as to whether they participate, or at least they are not penalized if they respond incorrectly so there is no disincentive to participating. In such embodiments, step 134 generally can be omitted on the assumption that all of the players can be deemed to be participants, irrespective of whether or not they actually do participate. In a variation on this embodiment, step 132 also is omitted, so that the players get no advance warning about when a problem is going to be delivered.
  • In any event, the set of participants for the current problem preferably exclude the players who already have answered their maximum allotted problems for the current period of time (e.g., their one problem for the day). In this regard, the preferred implementation is for anywhere between 2-8 problems to be presented each day, with each player allowed to answer no more than 1-5 (but preferably always strictly less than the total number of problems presented). More preferably, 3-4 problems are provided each day, with each player allowed to answer not more than 1 of them.
  • It is noted that the excluded participants also may be excluded from step 132, thereby sparing them an unnecessary alert. Also, in alternate embodiments the problem may be provided to a player at the same time as the participating players even if the subject player already has answered his or her maximum allotted problems or otherwise has opted out; however, this preferably would be for enjoyment purposes only and any response (if permitted) preferably would not count toward the competition. More preferably, however, a problem is not provided to non-participating players until after the problem has been completed by the participating players.
  • In step 137, the problem is presented substantially simultaneously to all of the participating players. In the present embodiment, participating players are required to answer an ordinary problem (special problems are discussed below) within 30 seconds, or else are scored as getting the problem incorrect. For that reason, and in order to prevent any unfair advantages, the problem preferably is presented within a 3-second window to all or substantially all of the participating players under normal circumstances. Of course, player device failures and other physical limitations at least sometimes will preclude delivery within such a 3-second window to 100% of the player devices.
  • The problems can involve any type of problem (e.g., knowledge-based or skill-based). However, it presently is anticipated that the most commonly used problem will be a question, typically a multiple-choice question.
  • An exemplary user interface 190 providing such a problem is illustrated in FIG. 8. As shown, user interface 190 includes a multiple-choice question 191, a plurality of potential answers 193, and a count-down timer 195 which indicates the time remaining in which to provide a response. Because a timer internal to application 80 preferably is used, the participant can be given the full response time (e.g., 30 seconds) from the time that the problem initially is delivered (or displayed), even if there are slight differences (e.g., a second or two) among the various player devices as to when the problem is delivered in absolute time.
  • The potential answers 193 preferably function as input interface elements (radio buttons in this case), allowing the player to respond directly and quickly within the same user interface 190, by simply designating the desired response 193. Once such a response is designated and then selected (or entered), the problem is over from the current player's perspective.
  • A number of other types of problems may be provided. For example, rather than a multiple-choice question, the problem could be a question that requires a textual and/or numeric response (e.g., entered through the keypad of a wireless telephone).
  • Also, irrespective of the form of the expected answer, the question can involve additional media beyond a merely textual question. For example, the participants might be asked to: (i) identify an individual within a photograph or video segment, (ii) identify the next three notes, or the next bar, following a segment of a song that is played for the participants, (iii) count the number of specified items in a particular photograph, or (iv) identify which of three movie-clip-and-soundtrack combinations do not go together. Still further, the problem might be more in the nature of a puzzle or even a video game, requiring onscreen manipulations by the participants.
  • Still further, the problem might involve external events and/or media outside the four corners of the player's devices 21-26. Preferably, such problems are special problems that are allotted additional time to complete. In one example, the players are directed to find an answer or an item on the Internet. More elaborate problems can involve a sort of virtual scavenger hunt, in which players move from one web site to another searching for the next clue until the answer is found or until time expires.
  • In any event, in step 139 the answers are received, typically by the individual player devices themselves in the first instance and then either immediately or subsequently transmitted to the contest server (e.g., server 12). As noted below, in certain cases the response time also will be transmitted to the server; in others, the player devices merely indicate whether the response was received within the allotted period of time. In the preferred embodiments, the player devices encrypt the response information before storing it or transmitting it to the contest server.
  • In step 141, the players' responses are scored. This step can be performed either at the player's device 21-26 itself or, after transmission, by the server 12, with the resulting score simply obtained later (e.g., via the player's device 21-26). In the preferred embodiment, each correct response that was submitted within the required timeframe (e.g., within 30 seconds after the problem was delivered) is awarded a fixed number of points and each incorrect response is assigned a negative point value (e.g., the negative of the point value for a correct response). However, in alternate embodiments different scoring mechanisms are applied. For example, in certain cases no penalty is attributed to an incorrect response. In other cases, the point award for a correct response is a function of how quickly the participant provided the response (in which case the participant's response time preferably is transmitted to the server, if that is where scoring occurs, along with the response itself). In other cases, different point levels are assigned for different levels of performance in connection with the problem (e.g., different point of values for completing 80% of a scavenger hunt and for completing 90% of the same scavenger hunt, within a fixed timeframe).
  • Next, in step 143 a determination is made as to whether the current problem was the last one for the contest. If not, then processing returns to step 131 to await the next problem. If so, then processing proceeds to step 144.
  • In step 144, the contest is concluded and the winners (if any) are identified based on total number of points accumulated. In this regard, a contest according to the present invention may be conducted as a tournament with winners (e.g., first, second, third place and/or similar rankings in various subcategories). Alternatively, it may be conducted simply for the sake of accumulating points, e.g., which then are traded for products or services.
  • In the contests of the present invention, different problems can have different associated point values. For example, the longer, more difficult or otherwise more involved problems preferably have higher point values than the shorter or easier ones. In the preferred embodiments, there are a relatively large number of regular problems (e.g., having a 30-second maximum response time and a standard point value) in just a few higher-value, potentially more involved problems. In certain embodiments, multiple problems (e.g., standard, difficult and extreme, having progressively higher point values) are available at a particular delivery time and the individual players can select which one they want to receive. In such cases, preferably all of the problems are downloaded prior to the delivery time but, for each player, only the selected problem is actually delivered to that player.
  • Various aspects of the foregoing contest can work together to generate a level of excitement and novelty that do not exist with conventional games or contests. First, as noted above, the contest is not geographically limited (subject, perhaps, to any practical problems that might arise in attempting to conduct the contest across too many time zones). Second, the contest preferably is played substantially simultaneously by all of the participants, so that in a reasonably large crowd several people might receive the alert and begin play, making the present contest more of a social event than typically is the case with conventional games or contests that are played on a personal device. In addition, when the times that the problems are to be delivered are not known in advance, an even heightened level of excitement, spontaneity and social connectedness often can occur.
  • The foregoing discussion focuses on the actual conduct of the contest. In between active playing times, a significant amount of additional activity can occur. For example, the individual players preferably have the ability to: check their point totals; check rankings or standings; view detailed statistics and even photographs of the leaders; view answers to, and/or strategies for approaching, previous problems; review performance statistics; generate customized reports regarding how individual players performed with respect to specified criteria; browse results from other contests; register for additional contests; and spend the points that they have accumulated. A number of the foregoing items can be particularly important when “powering” is involved, as discussed in the following paragraphs.
  • In this regard, a significant number of variations on the general contest structure described above are possible. One novel variation is the ability for individual players to “power” with at least one other player. More preferably, each player has the ability to power with one other player, of his or her own choosing, at a time. In such a case, the “powering player” (the one who makes the selection) is awarded points based on the points earned by the player with whom he or she powered (the “leader”) and vice versa. Thus, by powering with a very good player, an individual can significantly boost his or her points. Conversely, if a player can get a large number of other players to power with him or her, his or her own point total can be significantly enlarged. As a result, a leader's point total typically will depend not only on how successful he or she is at responding to problems, but also how successful he or she is in attracting others to power with him or her. Preferably, the powering player cannot result in a net loss of points to the leader (even in embodiments in which penalties are assessed against the responding player for incorrect responses), but instead only adds any net point gain earned during the powering relationship. On the other hand, in the preferred embodiments the leader's both positive and negative point earnings preferably also are attributed to the players who have powered with that leader (although in the preferred embodiments, any player's point score can never fall below zero).
  • In the preferred embodiments, the powering player can also derive other benefits by powering with good leaders. For example, in a tournament contest a powering player preferably is permitted to continue playing so long as the leader remains in the tournament, even if the powering player would not have qualified for continued play by himself or herself.
  • This paragraph describes the particular details of powering according to the preferred embodiment of the present invention. In this embodiment, three different kinds of points are contemplated, referred to as: “Dotz”, “PowerUp points” and “game points”. At the beginning of each month, in exchange for the monthly fee for participating in the contest, 5,000 Dotz are deposited into each player's account, and any negative balance from the previous month (if permitted) is zeroed out, so that each player has a minimum of 5,000 Dotz. In addition to earning Dotz based on their own performance, each player may power with one other player at a time, essentially binding all of his or her Dotz to that other player for a desired period of time. Irrespective of powering, Dotz are awarded to or subtracted from the player based on the individual player's own correct and incorrect responses and based on the number of Dotz assigned to each individual problem. In addition, if the player has powered, the same number of Dotz is added or subtracted based on the leader's answer to the problem. The player can pull back his or her Dotz from the leader at any time or switch them to another leader, although the player cannot leave and then return to the same leader during a contest. The leader, in turn, receives a number of PowerUp points equal to the total number of Dotz earned by all players who currently are powered with the leader, but does not lose PowerUp points when a powering player answers incorrectly (or at least does not incur a net loss due to any given powering player as a result of the powering relationship; in certain sub-embodiments, PowerUp points contributed by a powering player can later be lost by incorrect responses given by that same powering player). A player can power up his or her Dotz with a leader, but not any PowerUp points that he or she has earned (as a result of other players powering up with him or her). Each player's game score is equal to that player's Dotz plus his or her PowerUp points. At the end of each contest, additional Dotz are awarded to each player on a sliding scale based on overall rank in the contest and/or the absolute number of game points that particular player has, and the total number of Dotz can be exchanged for prizes (e.g., products or services). An example of such a sliding scale 200 is shown in FIG. 9, which includes rows for final game score 202, number of players 204 and Dotz earned 205 based on game score. In the present example, Dotz are earned based on rank: the player with the largest number of game points gets 1,000,000 Dotz, the next five highest get 500,000, the next 10 highest get 100,000, and so on, with the game score cut-offs 202 being determined only upon completion of the contest. In another embodiment, the game score cut-offs 202 are fixed and the number of players who fall within each range varies from contest to contest. Alternatively, any other conversion technique using any combination of overall rank and total number of game points may be used.
  • The ability to power, as discussed above, often can transform what otherwise would be a solitary or anonymous endeavor into a group or team activity, in which individual players are incentivize to track the performance of, and root for, other players. In the preferred embodiments of the invention, players have flexibility to switch to a different leader (thereby providing incentive to monitor others' performance), but restrictions are applied so that the powering players are forced to carefully consider any such changes. More preferably, during a given contest a player is not allowed to power with the same leader twice, meaning that once a powering player leaves a leader, he or she cannot go back during the same contest.
  • Variations on the powering concept also are possible. For example, the powering players might receive only a specified percentage (or some other function) of the points earned by the leader and/or vice versa. Alternatively, or in addition, a player might incur a cost for powering (e.g., a loss of 50% of the points he or she otherwise would earn, meaning that it would only make sense to power if one thought that the leader would perform better than the powering player). Still further, in embodiments in which the powering player can in fact harm the leader, the leader preferably has some control over which players power with them.
  • However, despite the variations, the general concept of powering is that an individual player has the ability to associate with one or more other players for a desired period of time and then flexibly switch associations as desired, potentially benefiting from the successes of the associated players (and in certain embodiments potentially being harmed by the losses of the associated players). Another preferred feature of powering is that individual players have an incentive to attract other players to power with them.
  • Also, rather than (or in addition to) powering, contests according to the present invention can include flexibly constituted teams. In one such embodiment, the performance of a team as a whole affects the point accumulation of its individual members, for any periods of time that such members are in fact affiliated with the team. While similar in some respects to powering, such a team approach lacks a direct one-to-one relationship between individual players and a leader, instead potentially leading to dynamics in which small ad hoc clusters of individuals are more likely to form.
  • In either the case of powering or teams, in certain embodiments the contest includes rules regarding the structure of the resulting groups and how individual players within the groups accumulate points. For example, the rules might create a multi-level point-earning structure within each group such that the leader earns the highest percentage, the next level down (perhaps limited to a fixed number of people) the next highest percentage, and so on. Such a structure could lead to intense negotiations about who is assigned to what level, with the risk that any individual player might defect to a different group (or leader) if he or she feels a better deal can be obtained.
  • In still further embodiments, by also structuring point awards more along group lines, incentives easily can be created for each group to attempt to ensure that each relevant area of knowledge or expertise is adequately covered, or even that each level within the group is adequately diverse in this regard.
  • The present invention contemplates contests that test the players across wide ranges of knowledge and skill, and as well as special-interest contests, such as contests targeted toward any specific area of interest, knowledge or skill (e.g., sports or entertainment), or any particular demographic (e.g., children, tweens or teens). As indicated above, the contest can be implemented as a competition with identified winners and potentially bonus points or prizes at the end (typically referred to as a tournament), as a time-limited opportunity to accumulate points which can be exchanged for products or services, or as a combination of both. In one example, at the end of the contest only the individual players having the highest point totals, together with any players who have powered with them, are invited to participate in an elimination tournament, e.g., with the powering players remaining in the tournament as long as their leader does.
  • For purposes of any tournament elimination or any similar aspect of competition, the rules can be constructed such that at any stage only the player's earned points are considered (excluding any powered points), all of the player's points are considered (including the powered points), or any (e.g., weighted) combination of the two is considered.
  • Additional Systems and Methods Involving Substantially Simultaneous Delivery.
  • The technology described above for facilitating simultaneous delivery of messages can be used for other purposes besides contests having simultaneous play. One category of such uses is any situation where simultaneous communication is desired or necessary. While broadcast media traditionally have been used for this purpose in the past, broadcast media are inherently limited in that the audience must have access to the media and be tuned in at the time an announcement is made. Also, broadcast media having low latency variability (such as television or cable broadcasts) generally are not suitable for small-scale releases of information. As noted above, the preferred embodiments of the present invention do not require connectivity at the time a message is delivered, and can permit delivery of a message using a wide range of different devices. Accordingly, a recipient can be more certain that he or she will get an important message at the same time everyone else does. Situations where such substantially simultaneous communications are important include announcement of certain economic and financial news.
  • Another category of use is where some coordinated activity is desired. As noted above, according to one feature of the present invention, the user devices for all participants wake up or activate at substantially the same time, prompting all such participants into action. This feature can be useful, for example, as an alert that an item being monitored on an on-line auction has just entered the last five minutes of the auction. In such a case, although the initial announcement generally would not require network connectivity, some connectivity typically would be required to actually submit a bid.
  • An example where coordinated shopping activity can be carried out without any immediate connectivity is where a product or service is made available for sale to the first purchasers. In such a case, using the preferred message delivery technology described above, the initial announcement message is stored in advance on the user's device together with a delivery time. Then, after the message has been delivered, the device stores the response and the response time, transmitting such information back to the server at an appropriate moment. After the fact, the server can identify the winning purchasers by simply ranking the response times. Note that this embodiment also largely eliminates the latency problems associated with conventional systems for selling out inventory (e.g., concert tickets) over a very short period of time.
  • Still further applications of the present technology include: sprinkler systems that can be re-programmed remotely; simultaneous opening of locks at banks or other establishments; real-time synchronized traffic light control for efficient traffic flow; updating of electronic billboard content; control of school exams throughout a state or other geographic region; simultaneous adjustment of supermarket pricing at a large number of stores; hotel alarm clocks; simultaneous real-time downloading of prescribed changes in rates to electric meters or other utilities, e.g., giving users a financial incentive to consume during off-peak hours; controlling or timing other aspects of game playing; medication dispensing control (e.g., timing and schedule updating); real-time polling (e.g., Neilson Television Polling) in order to capture instantaneous reactions (e.g., with incentives for the participants to respond immediately) or to track changing reactions over time by capturing reactions at a sequence of points; and in-store promotions (e.g., blasting a promotion to all subscribers to come to the store to purchase any item for a prescribed discount).
  • Another use of the present technology is in conjunction with broadcast programming. In one such embodiment, content related to a broadcast program (e.g., television or radio show) is downloaded to the user device 21-26 and then is delivered to the corresponding user 31-35 in synchronization with the program. However, the specific messages that are delivered preferably depend upon selections made by the user 31-35 on his or her device 21-26. As a result, an interactive experience can be created without any special-purpose hardware or any connectivity other than the ability to see the broadcast. In one sub-embodiment, even the broadcast has been recorded, with the program recorder/replayer's clock having been synchronized to the clock of the user device, e.g., in the manner described above for user device 25. Note that such embodiments use the present technology for personalized message delivery, rather than substantially simultaneous mass delivery of a common message.
  • A still further use of this technology is for conducting a real-time audience-participation contest over a broadcast medium. According to one such example, the broadcaster transmits (e.g., broadcasts) a wake-up signal to a number of different user devices 21-26. Substantially simultaneously, the user devices 21-26 wake up and allow their corresponding users to begin playing, preferably at the same time opening up a communication channel with the server 12. It is noted that either or both of the wake-up signal and the problem to be solved may be transmitted in real-time or transmitted in advance and stored on the corresponding devices 21-26, as discussed in detail above. In either event, the wake-up signal may be provided to all eligible players or only to a (e.g., randomly selected) portion of them. In the preferred embodiments, the problem is delivered to all of the audience members (e.g., via television broadcast) at the same time as it is delivered to the participating players, although preferably only the responses of the participating players affect the outcome of the contest. Also, upon waking up, the user devices 21-26 preferably time the user responses locally so as to avoid any communication latency discrepancies among the various user devices 21-26, with the resulting responses and response times being transmitted back to the server 12. System Environment.
  • Generally speaking, except where clearly indicated otherwise, all of the systems, methods and techniques described herein can be practiced with the use of one or more programmable general-purpose computing devices. Such devices typically will include, for example, at least some of the following components interconnected with each other, e.g., via a common bus: one or more central processing units (CPUs); read-only memory (ROM); random access memory (RAM); input/output software and circuitry for interfacing with other devices (e.g., using a hardwired connection, such as a serial port, a parallel port, a USB connection or a firewire connection, or using a wireless protocol, such as Bluetooth or a 802.11 protocol); software and circuitry for connecting to one or more networks (e.g., using a hardwired connection such as an Ethernet card or a wireless protocol, such as code division multiple access (CDMA), global system for mobile communications (GSM), Bluetooth, a 802.11 protocol, or any other cellular-based or non-cellular-based system), which networks, in turn, in many embodiments of the invention, connect to the Internet or to any other networks); a display (such as a cathode ray tube display, a liquid crystal display, an organic light-emitting display, a polymeric light-emitting display or any other thin-film display); other output devices (such as one or more speakers, a headphone set and a printer); one or more input devices (such as a mouse, touchpad, tablet, touch-sensitive display or other pointing device, a keyboard, a keypad, a microphone and a scanner); a mass storage unit (such as a hard disk drive); a real-time clock; a removable storage read/write device (such as for reading from and writing to RAM, a magnetic disk, a magnetic tape, an opto-magnetic disk, an optical disk, or the like); and a modem (e.g., for sending faxes or for connecting to the Internet or to any other computer network via a dial-up connection). In operation, the process steps to implement the above methods and functionality, to the extent performed by such a general-purpose computer, typically initially are stored in mass storage (e.g., the hard disk), are downloaded into RAM and then are executed by the CPU out of RAM. However, in some cases the process steps initially are stored in RAM or ROM.
  • Suitable devices for use in implementing the present invention may be obtained from various vendors. In the various embodiments, different types of devices are used depending upon the size and complexity of the tasks. Suitable devices include mainframe computers, multiprocessor computers, workstations, personal computers, and even smaller computers such as PDAs, wireless telephones or any other appliance or device, whether stand-alone, hard-wired into a network or wirelessly connected to a network.
  • In addition, although general-purpose programmable devices have been described above, in alternate embodiments one or more special-purpose processors or computers instead (or in addition) are used. In general, it should be noted that, except as expressly noted otherwise, any of the functionality described above can be implemented in software, hardware, firmware or any combination of these, with the particular implementation being selected based on known engineering tradeoffs. More specifically, where the functionality described above is implemented in a fixed, predetermined or logical manner, it can be accomplished through programming (e.g., software or firmware), an appropriate arrangement of logic components (hardware) or any combination of the two, as will be readily appreciated by those skilled in the art.
  • It should be understood that the present invention also relates to machine-readable media on which are stored program instructions for performing the methods and functionality of this invention. Such media include, by way of example, magnetic disks, magnetic tape, optically readable media such as CD ROMs and DVD ROMs, or semiconductor memory such as PCMCIA cards, various types of memory cards, USB memory devices, etc. In each case, the medium may take the form of a portable item such as a miniature disk drive or a small disk, diskette, cassette, cartridge, card, stick etc., or it may take the form of a relatively larger or immobile item such as a hard disk drive, ROM or RAM provided in a computer or other device.
  • The foregoing description primarily emphasizes electronic computers and devices. However, it should be understood that any other computing or other type of device instead may be used, such as a device utilizing any combination of electronic, optical, biological and chemical processing.
  • Additional Considerations.
  • In certain instances, the foregoing description refers to clicking or double-clicking on user-interface buttons, dragging user-interface items, or otherwise entering commands or information via a particular user-interface mechanism and/or in a particular manner. All of such references are intended to be exemplary only, it being understood that the present invention encompasses entry of the corresponding commands or information by a user in any other manner using the same or any other user-interface mechanism. In addition, or instead, such commands or information may be input by an automated (e.g., computer-executed) process.
  • Several different embodiments of the present invention are described above, with each such embodiment described as including certain features. However, it is intended that the features described in connection with the discussion of any single embodiment are not limited to that embodiment but may be included and/or arranged in various combinations in any of the other embodiments as well, as will be understood by those skilled in the art.
  • Similarly, in the discussion above, functionality sometimes is ascribed to a particular module or component. However, functionality generally may be redistributed as desired among any different modules or components, in some cases completely obviating the need for a particular component or module and/or requiring the addition of new components or modules. The precise distribution of functionality preferably is made according to known engineering tradeoffs, with reference to the specific embodiment of the invention, as will be understood by those skilled in the art.
  • Thus, although the present invention has been described in detail with regard to the exemplary embodiments thereof and accompanying drawings, it should be apparent to those skilled in the art that various adaptations and modifications of the present invention may be accomplished without departing from the spirit and the scope of the invention. Accordingly, the invention is not limited to the precise embodiments shown in the drawings and described above. Rather, it is intended that all such variations not departing from the spirit of the invention be considered as within the scope thereof as limited solely by the claims appended hereto.

Claims (20)

1. A method for implementing a simultaneous, but intermittently played, contest, comprising:
(a) delivering a problem substantially simultaneously to geographically dispersed players, the problem being identical for all players;
(b) receiving responses to the problem from the players and measuring response times corresponding to the responses;
(c) determining scores for the players that are based on the responses and corresponding response times; and
(d) repeating steps (a)-(c) a plurality of times, with a median time interval between delivery of consecutive problems being at least 30 minutes, and with an aggregate score being maintained for each of the players.
2. A method according to claim 1, wherein there are at least 100 players.
3. A method according to claim 1, wherein for each of at least a majority of the players, the problem is delivered, the response is input and the response time is measured on a same user device.
4. A method according to claim 3, further comprising a step of downloading the problems into the user devices in advance, via a publicly accessible network.
5. A method according to claim 1, further comprising a step of permitting the players to decide whether or not to participate in a current problem, wherein only the players who participate in the current problem are scored with respect to the current problem.
6. A method according to claim 5, wherein more problems are available than the players are permitted to answer, so that the players have flexibility regarding when they participate.
7. A method according to claim 1, further comprising steps of:
(e) allowing the players to voluntarily associate with at least one other player; and
(f) while and only while an association exists between a first player and a second player, providing the first player with points that are based directly on a number of points earned by the second player.
8. A method according to claim 7, wherein the first player has an ability to transfer the association from the second player to a third player, in which case the first player ceases to receive points based on points earned by the second player and begins to receive points that are based directly on a number of points earned by the third player.
9. A method according to claim 1, wherein the players must answer the problem within a specified period of time after the problem is delivered in order to obtain credit for answering correctly.
10. A method according to claim 9, wherein the specified period of time is not more than 90 seconds.
11. A method according to claim 1, wherein opportunities to answer the problems are provided to the players at times that are not known in advance to the players.
12. A method according to claim 1, wherein a correct response to a given problem is awarded a number of points that depends upon how quickly the correct response was submitted after the given problem was delivered.
13. A method according to claim 1, wherein said steps (a)-(c) are repeated on a daily basis over a period of at least 5 days.
14. A system for implementing a simultaneous, but intermittently played, contest, comprising:
(a) means for delivering a problem substantially simultaneously to geographically dispersed players, the problem being identical for all players;
(b) means for receiving responses to the problem from the players and measuring response times corresponding to the responses;
(c) means for determining scores for the players that are based on the responses and corresponding response times; and
(d) means for repeating execution of means (a)-(c) a plurality of times, with a median time interval between delivery of consecutive problems being at least 30 minutes, and with an aggregate score being maintained for each of the players.
15. A system according to claim 14, wherein there are at least 100 players.
16. A system according to claim 14, wherein for each of at least a majority of the players, the problem is delivered, the response is input and the response time is measured on a same user device.
17. A system according to claim 16, further comprising means for downloading the problems into the user devices in advance, via a publicly accessible network.
18. A system according to claim 14, further comprising:
(d) means for allowing the players to voluntarily associate with at least one other player and while, and only while, an association exists between a first player and a second player, providing the first player with points that are based directly on a number of points earned by the second player.
19. A system according to claim 18, wherein the first player has an ability to transfer the association from the second player to a third player, in which case the first player ceases to receive points based on points earned by the second player and begins to receive points that are based directly on a number of points earned by the third player.
20. A system according to claim 14, wherein opportunities to answer the problems are provided to the players at times that are not known in advance to the players.
US13/100,211 2005-10-06 2011-05-03 User-Device-Implemented Contest with Alert Feature Abandoned US20110223981A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/100,211 US20110223981A1 (en) 2005-10-06 2011-05-03 User-Device-Implemented Contest with Alert Feature

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US72447305P 2005-10-06 2005-10-06
US11/539,179 US7946910B2 (en) 2005-10-06 2006-10-06 Substantially simultaneous intermittent contest
US13/100,211 US20110223981A1 (en) 2005-10-06 2011-05-03 User-Device-Implemented Contest with Alert Feature

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/539,179 Continuation US7946910B2 (en) 2005-10-06 2006-10-06 Substantially simultaneous intermittent contest

Publications (1)

Publication Number Publication Date
US20110223981A1 true US20110223981A1 (en) 2011-09-15

Family

ID=38163375

Family Applications (3)

Application Number Title Priority Date Filing Date
US11/539,180 Active 2028-09-17 US7805151B2 (en) 2005-10-06 2006-10-06 System for substantially simultaneous alerts
US11/539,179 Expired - Fee Related US7946910B2 (en) 2005-10-06 2006-10-06 Substantially simultaneous intermittent contest
US13/100,211 Abandoned US20110223981A1 (en) 2005-10-06 2011-05-03 User-Device-Implemented Contest with Alert Feature

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US11/539,180 Active 2028-09-17 US7805151B2 (en) 2005-10-06 2006-10-06 System for substantially simultaneous alerts
US11/539,179 Expired - Fee Related US7946910B2 (en) 2005-10-06 2006-10-06 Substantially simultaneous intermittent contest

Country Status (10)

Country Link
US (3) US7805151B2 (en)
EP (1) EP1952294A4 (en)
JP (1) JP2009512019A (en)
KR (1) KR20080060268A (en)
CN (1) CN101322128A (en)
AU (1) AU2006325473A1 (en)
CA (1) CA2672247A1 (en)
RU (2) RU2430765C2 (en)
UA (1) UA94064C2 (en)
WO (1) WO2007070155A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014144419A2 (en) * 2013-03-15 2014-09-18 Master Lock Company Networked security system

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7905777B2 (en) 2005-08-04 2011-03-15 Igt Methods and apparatus for auctioning an item via a gaming device
US8216065B2 (en) 2005-09-09 2012-07-10 Igt Gaming system having multiple adjacently arranged gaming machines which each provide a component for a multi-component game
US7904321B2 (en) * 2006-10-27 2011-03-08 At&T Intellectual Property I, L.P. Systems, methods and computer program products for user-selected calendar and task alerts
US7857699B2 (en) 2006-11-01 2010-12-28 Igt Gaming system and method of operating a gaming system having a bonus participation bidding sequence
US8079048B2 (en) 2006-12-15 2011-12-13 At&T Intellectual Property I, L.P. System and method of scheduling an event related to an advertisement
TW200830844A (en) * 2007-01-11 2008-07-16 Delta Electronics Inc Bluetooth wireless phone with touchpad
CA2682586A1 (en) * 2007-03-30 2008-10-09 Ntn Buzztime, Inc. Video feed synchronization in an interactive environment
US20080300056A1 (en) * 2007-05-30 2008-12-04 Ntn Buzztime, Inc. Telephone Enabled Elimination Game
US8167712B2 (en) * 2007-08-08 2012-05-01 Sony Computer Entertainment America Inc. Method and apparatus for player replacement in an on-line game
IL185433A0 (en) * 2007-08-22 2008-01-06 Shimon Ezra Game of the century
JP4268992B2 (en) 2007-09-28 2009-05-27 株式会社コナミデジタルエンタテインメント Game system and server
US20090197675A1 (en) * 2008-01-28 2009-08-06 Paul Son Interactive gaming platform
US8206222B2 (en) 2008-01-29 2012-06-26 Gary Stephen Shuster Entertainment system for performing human intelligence tasks
US8046620B2 (en) * 2008-01-31 2011-10-25 Peter Sui Lun Fong Interactive device with time synchronization capability
US8583956B2 (en) * 2008-01-31 2013-11-12 Peter Sui Lun Fong Interactive device with local area time synchronization capbility
US20100106859A1 (en) * 2008-10-24 2010-04-29 Samsung Electronics Co. , Ltd. Method and system for synchronizing attributes among multiple electronic devices
US9727139B2 (en) 2008-12-12 2017-08-08 Immersion Corporation Method and apparatus for providing a haptic monitoring system using multiple sensors
WO2010071194A1 (en) * 2008-12-19 2010-06-24 パナソニック電工株式会社 Wireless communication system
US20100205539A1 (en) * 2009-02-12 2010-08-12 Amivox Ehf. Instant messaging and telephony value added services
TW201102847A (en) * 2009-07-14 2011-01-16 Tzu-Ling Liang Game blog platform system
US8602875B2 (en) 2009-10-17 2013-12-10 Nguyen Gaming Llc Preserving game state data for asynchronous persistent group bonus games
US9626826B2 (en) 2010-06-10 2017-04-18 Nguyen Gaming Llc Location-based real-time casino data
US8864586B2 (en) 2009-11-12 2014-10-21 Nguyen Gaming Llc Gaming systems including viral gaming events
US20210005047A1 (en) 2009-11-12 2021-01-07 Nguyen Gaming Llc Gaming system supporting data distribution to gaming devices
US8747209B2 (en) * 2009-11-13 2014-06-10 Bonobo Plc Multi-draw game system
US8597108B2 (en) 2009-11-16 2013-12-03 Nguyen Gaming Llc Asynchronous persistent group bonus game
EP2526537A1 (en) 2010-01-20 2012-11-28 Sanford, L. P. Dynamically configurable audience response system
JP5702941B2 (en) * 2010-03-30 2015-04-15 アズビル株式会社 Control device
US8696470B2 (en) 2010-04-09 2014-04-15 Nguyen Gaming Llc Spontaneous player preferences
US8777227B2 (en) * 2010-07-16 2014-07-15 Ward Kraft, Inc. Apparatus and methods for organizing and playing a game
US20120084171A1 (en) * 2010-09-30 2012-04-05 Adair Aaron J Option for submitting a user-defined super bid that overrides an auction countdown
US20180053374A9 (en) 2010-11-14 2018-02-22 Binh T. Nguyen Multi-Functional Peripheral Device
US9235952B2 (en) 2010-11-14 2016-01-12 Nguyen Gaming Llc Peripheral management device for virtual game interaction
US9486704B2 (en) 2010-11-14 2016-11-08 Nguyen Gaming Llc Social gaming
US10052551B2 (en) 2010-11-14 2018-08-21 Nguyen Gaming Llc Multi-functional peripheral device
US9564018B2 (en) 2010-11-14 2017-02-07 Nguyen Gaming Llc Temporary grant of real-time bonus feature
US9595161B2 (en) 2010-11-14 2017-03-14 Nguyen Gaming Llc Social gaming
US20120258805A1 (en) * 2011-04-07 2012-10-11 Harris Sr Patrick Systems and Methods For Compensating Leaders Within Online Games, Such As Massively Multiplayer Online Games
US9630096B2 (en) 2011-10-03 2017-04-25 Nguyen Gaming Llc Control of mobile game play on a mobile vessel
US9672686B2 (en) 2011-10-03 2017-06-06 Nguyen Gaming Llc Electronic fund transfer for mobile gaming
US9560305B2 (en) 2012-05-31 2017-01-31 At&T Intellectual Property I, L.P. Notification of upcoming media content of interest
US9325203B2 (en) 2012-07-24 2016-04-26 Binh Nguyen Optimized power consumption in a gaming device
US10176666B2 (en) 2012-10-01 2019-01-08 Nguyen Gaming Llc Viral benefit distribution using mobile devices
JP5827410B2 (en) * 2012-10-03 2015-12-02 グリー株式会社 Online game synchronization method and server device
KR102020358B1 (en) * 2013-03-14 2019-11-05 삼성전자 주식회사 Terminal and method for synchronizing application thereof
US10421010B2 (en) 2013-03-15 2019-09-24 Nguyen Gaming Llc Determination of advertisement based on player physiology
US9600976B2 (en) 2013-03-15 2017-03-21 Nguyen Gaming Llc Adaptive mobile device gaming system
US9814970B2 (en) 2013-03-15 2017-11-14 Nguyen Gaming Llc Authentication of mobile servers
US11398131B2 (en) 2013-03-15 2022-07-26 Aristocrat Technologies, Inc. (ATI) Method and system for localized mobile gaming
US9483901B2 (en) 2013-03-15 2016-11-01 Nguyen Gaming Llc Gaming device docking station
US11157998B2 (en) 2014-08-04 2021-10-26 Renaissance Technologies Llc System and method for executing synchronized trades in multiple exchanges
US9589454B2 (en) * 2014-09-08 2017-03-07 Verizon Patent And Licensing Inc. Method, apparatus and system for broadcasting an alarm for an alarm group
US10129313B2 (en) * 2015-02-10 2018-11-13 Cisco Technology, Inc. System, method, and logic for managing content in a virtual meeting
CN106033487B (en) * 2015-03-09 2019-02-05 腾讯科技(深圳)有限公司 User matching method and device
WO2018031493A1 (en) * 2016-08-07 2018-02-15 Wynsom Inc. Inducing consumer purchases on mobile devices
US10916090B2 (en) 2016-08-23 2021-02-09 Igt System and method for transferring funds from a financial institution device to a cashless wagering account accessible via a mobile device
US20180253985A1 (en) * 2017-03-02 2018-09-06 Aspiring Minds Assessment Private Limited Generating messaging streams
US11386747B2 (en) 2017-10-23 2022-07-12 Aristocrat Technologies, Inc. (ATI) Gaming monetary instrument tracking system
US11558740B2 (en) * 2020-09-23 2023-01-17 T-Mobile Usa, Inc. Dynamic encryption for scheduled message delivery

Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5916024A (en) * 1986-03-10 1999-06-29 Response Reward Systems, L.C. System and method of playing games and rewarding successful players
US6394899B1 (en) * 1999-10-29 2002-05-28 Stephen Tobin Walker Method of playing a knowledge based wagering game
US20020132656A1 (en) * 2001-01-09 2002-09-19 Michael Lydon Systems and methods for coding competitions
US20020142842A1 (en) * 2001-03-29 2002-10-03 Easley Gregory W. Console-based system and method for providing multi-player interactive game functionality for use with interactive games
US6565434B1 (en) * 1994-10-12 2003-05-20 Acres Gaming, Inc. Method and apparatus for promoting play on a network of gaming devices
US20040097287A1 (en) * 2002-11-14 2004-05-20 Richard Postrel Method and system for gaming over a computer network
US20050043094A1 (en) * 2003-08-18 2005-02-24 Igt System and method for permitting a tournament game on different computing platforms
US6908389B1 (en) * 2001-03-07 2005-06-21 Nokia Corporation Predefined messages for wireless multiplayer gaming
US20050197189A1 (en) * 2004-03-03 2005-09-08 Motorola, Inc. Method and system for reality gaming on wireless devices
US20050271186A1 (en) * 2004-06-02 2005-12-08 Audiopoint, Inc. System, method and computer program product for interactive voice notification
US7056217B1 (en) * 2000-05-31 2006-06-06 Nintendo Co., Ltd. Messaging service for video game systems with buddy list that displays game being played
US20060154710A1 (en) * 2002-12-10 2006-07-13 Nokia Corporation Method and device for continuing an electronic multi-player game, in case of an absence of a player of said game
US7240093B1 (en) * 2000-02-29 2007-07-03 Microsoft Corporation Use of online messaging to facilitate selection of participants in game play
US20070155465A1 (en) * 1998-03-31 2007-07-05 Walker Jay S Method and apparatus for linked play gaming with combined outcomes and shared indicia
US7470197B2 (en) * 2001-08-17 2008-12-30 Graham Peter Massey On-line gaming with independent player matching

Family Cites Families (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3989900A (en) * 1973-09-06 1976-11-02 Lifeline Systems, Inc. Automatic telephone alarm system
US4492820A (en) * 1980-10-24 1985-01-08 Salt Lake Communications, Inc. Telephone alarm system
US4461927A (en) * 1983-03-03 1984-07-24 Olson Ronald E Automatic dialing and alarm system
US4524243A (en) * 1983-07-07 1985-06-18 Lifeline Systems, Inc. Personal alarm system
US4926255A (en) * 1986-03-10 1990-05-15 Kohorn H Von System for evaluation of response to broadcast transmissions
KR950010298B1 (en) * 1991-03-29 1995-09-14 가시오 게이상기 가부시끼가이샤 Electronic reading device
US5495470A (en) * 1992-04-02 1996-02-27 Applied Digital Access, Inc. Alarm correlation system for a telephone network
SE9300964D0 (en) * 1993-03-23 1993-03-23 Jan Ruus ALARM SYSTEM
US6856986B1 (en) * 1993-05-21 2005-02-15 Michael T. Rossides Answer collection and retrieval system governed by a pay-off meter
US7426264B1 (en) * 1994-01-05 2008-09-16 Henderson Daniel A Method and apparatus for improved personal communication devices and systems
JPH08263438A (en) * 1994-11-23 1996-10-11 Xerox Corp Distribution and use control system of digital work and access control method to digital work
US7133845B1 (en) * 1995-02-13 2006-11-07 Intertrust Technologies Corp. System and methods for secure transaction management and electronic rights protection
FR2732792B1 (en) * 1995-04-06 1997-06-06 Benkel Gerard ELECTRONIC COMPETITION SYSTEM AND IMPLEMENTATION METHOD
US6086381A (en) * 1995-06-07 2000-07-11 Learnstar, Inc. Interactive learning system
US6193610B1 (en) * 1996-01-05 2001-02-27 William Junkin Trust Interactive television system and methodology
US6018719A (en) * 1996-10-02 2000-01-25 Nintendo Of America Inc. Electronic registration system for product transactions
US20030064807A1 (en) * 2001-09-25 2003-04-03 Walker Jay S. Method and apparatus for linked play gaming
US20030040962A1 (en) * 1997-06-12 2003-02-27 Lewis William H. System and data management and on-demand rental and purchase of digital data products
US6267379B1 (en) * 1997-12-31 2001-07-31 Forrest-Pruzan Creative Llc Electronically interactive location-based multimedia game system and method
US5986561A (en) * 1998-06-06 1999-11-16 Kuruvilla; Kolanparampil K. Automatic door warning system
NZ500956A (en) * 1998-12-04 2000-08-25 Two Way Tv Ltd Interactive TV game system, start signal transmitted to all users simultaneously
US20020026321A1 (en) * 1999-02-26 2002-02-28 Sadeg M. Faris Internet-based system and method for fairly and securely enabling timed-constrained competition using globally time-sychronized client subsystems and information servers having microsecond client-event resolution
US6769130B1 (en) * 2000-01-20 2004-07-27 Interactual Technologies, Inc. System, method and article of manufacture for late synchronization during the execution of a multimedia event on a plurality of client computers
KR100741463B1 (en) 1999-05-10 2007-07-20 텔레폰악티에볼라겟엘엠에릭슨(펍) Method and apparatus in a communication network
US7054831B2 (en) * 1999-07-07 2006-05-30 Eric Koenig System and method for combining interactive game with interactive advertising
EP1075108A1 (en) * 1999-07-23 2001-02-07 BRITISH TELECOMMUNICATIONS public limited company Cryptographic data distribution
US6473084B1 (en) * 1999-09-08 2002-10-29 C4Cast.Com, Inc. Prediction input
US6606615B1 (en) * 1999-09-08 2003-08-12 C4Cast.Com, Inc. Forecasting contest
US7243130B2 (en) * 2000-03-16 2007-07-10 Microsoft Corporation Notification platform architecture
US20020087649A1 (en) * 2000-03-16 2002-07-04 Horvitz Eric J. Bounded-deferral policies for reducing the disruptiveness of notifications
US7076434B1 (en) * 2000-03-22 2006-07-11 Goldpocket Interactive, Inc. Method and system of playing and controlling a contest for a large number of simultaneous contestants
US7181623B2 (en) * 2000-03-28 2007-02-20 University Of Maryland Scalable wide-area upload system and method
JP2001276438A (en) * 2000-03-31 2001-10-09 Konami Computer Entertainment Osaka:Kk Net game system, net game device, net game method, and readable recording medium recording game program
US20020004424A1 (en) * 2000-04-14 2002-01-10 Nelson David C. Method, apparatus and system for an electronically distributed game of skill
US20020199096A1 (en) * 2001-02-25 2002-12-26 Storymail, Inc. System and method for secure unidirectional messaging
ZA200103659B (en) * 2000-10-09 2001-11-26 Ajay Ganesh Ubale Net related interactive quiz game.
US8678902B2 (en) * 2005-09-07 2014-03-25 Bally Gaming, Inc. System gaming
SE517816C2 (en) 2000-10-27 2002-07-16 Terraplay Systems Ab Method and device for an application
AU2002239617A1 (en) * 2000-10-30 2002-05-21 The Trend Fund Corp. Method and system for providing messaging to multiple clients
US6688982B2 (en) * 2000-11-29 2004-02-10 Agency.Com Ltd. Wireless communications system for a quiz game
JP4731008B2 (en) * 2000-12-05 2011-07-20 株式会社バンダイナムコゲームス Information providing system and information storage medium
US20020129096A1 (en) * 2001-02-14 2002-09-12 Mansour Peter M. Platform-independent distributed user interface client architecture
US7730401B2 (en) * 2001-05-16 2010-06-01 Synaptics Incorporated Touch screen with user interface enhancement
GB2377143A (en) * 2001-06-29 2002-12-31 3G Scene Plc Internet security
AUPR690701A0 (en) * 2001-08-10 2001-08-30 Redpoint Pty Ltd A system and method for customising call alerts
US20030188188A1 (en) * 2002-03-15 2003-10-02 Microsoft Corporation Time-window-constrained multicast for future delivery multicast
US6800031B2 (en) * 2002-04-15 2004-10-05 Microsoft Corporation Method of conducting an interactive competition
RU2205051C1 (en) * 2002-05-16 2003-05-27 Железняков Николай Александрович Method for playing question and answer game
US7177859B2 (en) * 2002-06-26 2007-02-13 Microsoft Corporation Programming model for subscription services
US7720910B2 (en) * 2002-07-26 2010-05-18 International Business Machines Corporation Interactive filtering electronic messages received from a publication/subscription service
US7248159B2 (en) * 2003-03-01 2007-07-24 User-Centric Ip, Lp User-centric event reporting
GB2421824A (en) * 2003-09-29 2006-07-05 Micro News Network Llc Information acquisition and distribution system
ATE536801T1 (en) * 2004-01-15 2011-12-15 Koninkl Philips Electronics Nv ADAPTIVE PHYSIOLOGICAL MONITORING SYSTEM AND METHOD OF USE THEREOF
US20050172154A1 (en) * 2004-01-29 2005-08-04 Chaoticom, Inc. Systems and methods for providing digital content and caller alerts to wireless network-enabled devices
US7092707B2 (en) * 2004-02-13 2006-08-15 Telcordia Technologies, Inc. Service impact analysis and alert handling in telecommunications systems
US10417298B2 (en) * 2004-12-02 2019-09-17 Insignio Technologies, Inc. Personalized content processing and delivery system and media
US20070063824A1 (en) * 2005-08-18 2007-03-22 Gaddy Kent B Vehicle warning system and detection apparatus
US20070083323A1 (en) * 2005-10-07 2007-04-12 Outland Research Personal cuing for spatially associated information
US7592912B2 (en) * 2005-12-09 2009-09-22 Time Warner Cable Inc. Emergency alert data delivery apparatus and methods

Patent Citations (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5916024A (en) * 1986-03-10 1999-06-29 Response Reward Systems, L.C. System and method of playing games and rewarding successful players
US6565434B1 (en) * 1994-10-12 2003-05-20 Acres Gaming, Inc. Method and apparatus for promoting play on a network of gaming devices
US20070155465A1 (en) * 1998-03-31 2007-07-05 Walker Jay S Method and apparatus for linked play gaming with combined outcomes and shared indicia
US6394899B1 (en) * 1999-10-29 2002-05-28 Stephen Tobin Walker Method of playing a knowledge based wagering game
US7240093B1 (en) * 2000-02-29 2007-07-03 Microsoft Corporation Use of online messaging to facilitate selection of participants in game play
US7056217B1 (en) * 2000-05-31 2006-06-06 Nintendo Co., Ltd. Messaging service for video game systems with buddy list that displays game being played
US20020132656A1 (en) * 2001-01-09 2002-09-19 Michael Lydon Systems and methods for coding competitions
US6908389B1 (en) * 2001-03-07 2005-06-21 Nokia Corporation Predefined messages for wireless multiplayer gaming
US20020142842A1 (en) * 2001-03-29 2002-10-03 Easley Gregory W. Console-based system and method for providing multi-player interactive game functionality for use with interactive games
US7470197B2 (en) * 2001-08-17 2008-12-30 Graham Peter Massey On-line gaming with independent player matching
US20040097287A1 (en) * 2002-11-14 2004-05-20 Richard Postrel Method and system for gaming over a computer network
US20060154710A1 (en) * 2002-12-10 2006-07-13 Nokia Corporation Method and device for continuing an electronic multi-player game, in case of an absence of a player of said game
US20050043094A1 (en) * 2003-08-18 2005-02-24 Igt System and method for permitting a tournament game on different computing platforms
US20050197189A1 (en) * 2004-03-03 2005-09-08 Motorola, Inc. Method and system for reality gaming on wireless devices
US20050271186A1 (en) * 2004-06-02 2005-12-08 Audiopoint, Inc. System, method and computer program product for interactive voice notification

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014144419A2 (en) * 2013-03-15 2014-09-18 Master Lock Company Networked security system
WO2014144419A3 (en) * 2013-03-15 2014-11-20 Master Lock Company Networked security system
US9942840B2 (en) 2013-03-15 2018-04-10 Master Lock Company Llc Networked security system

Also Published As

Publication number Publication date
WO2007070155A2 (en) 2007-06-21
US20070087791A1 (en) 2007-04-19
UA94064C2 (en) 2011-04-11
WO2007070155A9 (en) 2007-08-23
KR20080060268A (en) 2008-07-01
EP1952294A4 (en) 2010-08-18
RU2008117567A (en) 2009-11-20
CN101322128A (en) 2008-12-10
AU2006325473A1 (en) 2007-06-21
US20070087833A1 (en) 2007-04-19
JP2009512019A (en) 2009-03-19
CA2672247A1 (en) 2007-06-21
WO2007070155A3 (en) 2008-01-31
US7946910B2 (en) 2011-05-24
RU2430765C2 (en) 2011-10-10
US7805151B2 (en) 2010-09-28
EP1952294A2 (en) 2008-08-06
RU2011122419A (en) 2012-12-10

Similar Documents

Publication Publication Date Title
US7946910B2 (en) Substantially simultaneous intermittent contest
US11358064B2 (en) Method of and system for conducting multiple contests of skill with a single performance
US20220249935A1 (en) Method of and system for conducting multiple contests of skill with a single performance
US8231470B2 (en) Network-based contests having multiple participating sponsors
KR101106846B1 (en) Tracking, correlating, and processing multi-user online sessions
EP1195184A2 (en) Apparatus for playing a quiz game
US7824268B2 (en) Live hosted online multiplayer game
US20030114224A1 (en) Distributed game over a wireless telecommunications network
CN106875118B (en) Method and device for controlling execution of task plans in group and server
KR20010032547A (en) A system and method for implementing an auction on a computer network
WO2015142439A1 (en) Geofenced event-based fan networking
US8790176B2 (en) System and method for real time interactive entertainment
JP2012075875A (en) Game machine
WO2006053946A2 (en) Method and system for providing mobile means to spectators for consulting statistics and inputing bets during live sport events
US20070136454A1 (en) Performance procurement system
JP2001216416A (en) Web system for advertisement/sales promotion
AU2009201986A1 (en) Gaming method and gaming system
US20240087390A1 (en) System and method for group consensus voting for games and shows
US11766614B1 (en) Utilizing mobile device capabilities to keep a user engaged with a mobile application
WO2023228727A1 (en) System, method, and program for providing live streaming service
JP2023124769A (en) Server and method
AU2018264032A1 (en) Gaming method and gaming system

Legal Events

Date Code Title Description
AS Assignment

Owner name: VERGENCE ENTERTAINMENT LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FEENEY, ROBERT J.;BARKLEY, BRENT W.;HAAS, JEFF E.;AND OTHERS;REEL/FRAME:026219/0908

Effective date: 20061005

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION