SYSTEMS AND METHODS FOR MANAGING DEMAND DRIVEN SPORTING GAMES

Abstract

A demand driven game system and method uses a communications network driven by an engine to facilitate the scheduling of demand driven (sporting) games (DDG's), through passively accepting electronic expressions of interest for open slots (registrations), and actively filling slots through a matching service. Such functions can be performed through a combination of processing party preferences from a public interface, a team interface, setup preferences from an administrator interface and a referee interface, processing league data structures from a database, particularly competition rosters and referee rosters, processing DDG registrations and sending and receiving automated communications with relevant parties through SMS channels. DDG slots could be filled through a combination of transactional approaches, players/teams/individuals registering for specific slots, and service approaches, with players/teams/individuals registering to receive queries for DDG's of a specific character.

Description

The Present invention both manages demand driven sporting games, and performs active demand driven game-fill functions, using a communications network.

Many people play in local sports leagues and the like in many different types of sport, including for example basketball, netball, indoor soccer, and indoor cricket.

Typically, a league or organising body will set up matches, and provide game officials and other support, and registered teams will play once a week at a designated time in a local hall, sports centre or the like.

This ‘supply driven’ and ‘top down’ organisational approach is almost the exclusive format of sport, such that games are at the discretion of organising bodies, player needs to be associated with teams, teams are told who they will play, when they play and the like, competitive games are played within the context of a full season, players need to sign-up at the beginning of a season etc.

This approach is becoming increasingly opposed to modern day lifestyles, such that busier lives make it more difficult to maintain a long term sport routine, particularly for those from an adult age group, and organise that routine around the beginning of a sporting season. Moreover, these issues create barriers of entry for new players, particularly associated with season start-up times, and exclude a range of individuals that would otherwise enjoy the competitiveness, exercise and social activity which are uniquely provided by sport.

Indeed, even for those who can accept the necessary commitments, and overcome the barriers to entry, there is still a requirement to systematically sit out games through ‘byes’, not participating in finals or the like. This is both a problem in and of itself, diminishing the player experience, and reflective more generally of the problems associated with an exclusively supply centric approach to sport.

The aim of the present invention is to provide a mechanism facilitating demand driven sport through the provision of demand driven game slots, which can be registered for by teams, players and individuals, which can be implemented electronically and automatically given sufficient demand, and the provision of active matching/filling functions, which enables teams, players and individuals to relate to demand driven games as a service, such that said parties are actively matched by the system based on general preferences.

Viewed from one aspect the following invention provides a demand driven gaming system for sport over an electronic communications network including;

an administrative interface for setting up demand driven game (DDG) slots, and setting directly and indirectly related preferences.

a referee interface to assist in integrating referees within DDG's, including setting participation preferences and specifying availability times.

a team interface for setting participation level, by registering for specific types of active matching, optionally providing access to tools to register for singular DDG's, optional tools to challenge other teams to unrecorded DDG's, viewing up-and-coming games and the like.

a public interface for registering for singular DDG's, and tools to register for an individual active matching service.

a DDG engine for processing game registrations and verifications, processing preferences from various interfaces and processing court availability and performing active match processing.

a database for storing preferences, league data and the like.

The present invention may for example be implemented through a website on the Internet and/or through any other suitable communications system, including electronic messaging in general, and provides a system for administrators to setup, fill and manage demand driven games (DDG's), in such way that players/individuals might register for a particular DDG or a DDG service, or said players or teams might be approached without having registered for a game or a service, particularly in situations where a team is uniquely scheduled not to play for a week, and queried as to whether said team would like a replacement game in the form of a DDG organised.

The present invention assists a party, e.g. a league administrator, to organise team members, referees, spare courts and the like, in such a way that demand driven games are available as an ongoing service to players and individuals in various formats within existing competitions including in the format of DDG bye matches, challenge matches, training session, finals fillers and the like, and outside competitions in the form of public matches and the like, both for increasing the player experience, generating additional revenue streams for sporting leagues, encouraging new individuals to participate in the sport within their respective capacities, and moving sport toward a social/entertainment alignment and away from a purely competitive alignment, thus opening up new markets.

The ability of the system to match ‘spare’ courts, with teams interested in playing an unrecorded game, in such a way that relevant parties are automatically organised using interactive communications sent by the system, effortlessly applies otherwise wasted league resources, while simultaneously providing a service to players, to generate revenue streams, which for example create revenues of $100 per game in the case of basketball. Functions like detecting which court is ‘spare’, which team is ‘uniquely unscheduled’ for a week relies on the system being mounted on, or used in association with, a sport administration package, to the extent the system has access to general purpose game rosters, i.e. lists of teams scheduled to play on particular courts. Thus the system may function in a standalone fashion, using full administrator specified details, or a parasitic fashion and be attached to a sport administration program, to the extent data structures created by said program are used within the identification of ‘spare’ courts, the identification of spare teams, and the identification of spare referees, functions which would otherwise need to be defined or disabled within an administrative interface or the like.

The system might provide demand driven games for a range of purposes and parties, be it existing teams that have a bye and would otherwise miss out on a game, be it existing teams that did not qualify for finals and whose season would otherwise be over, be it existing teams or players that would like to play twice a week irrespective of whether one of those games is unrecorded (i.e. by registering for a specific DDG, or registering for an active matching service for a system organised weekly team DDG of a specific character), be it teams that would like a formal training session on a competition court, be it teams that would like to challenge another specific team to an unrecorded game, or be it individuals without the time to participate in a league on a consistent weekly basis but who would like to play games on odd days through the week.

The system might be both active and passive, such that passive registers for a particular DDG might allow players or teams to express a desire to play in said game (e.g. by adding a name to a register on a centralized DDG web page, through a discrete team page, through a direct interface, or some other practical equivalent), or the system might actively identify parties with a high likelihood of accepting a DDG offer if prompted, such as players/teams with byes, players/teams missing out on finals, players/teams identifying themselves as wishing to play DDG's of a particular character, or the like, and might prompt said player/team to participate in a DDG using a range of suitable interactive communications, including sending an SMS to said player.

A particular demand driven gaming system might be dedicated to a single type of sport or league, e.g. to a basketball league or to a particular sports centre or the like. The system may also be run in a more general manner, e.g. the system may provide a central service for managing or accessing demand driven games for a variety of sports and/or venues.

The present invention might be particularly useful for indoor sports like basketball but might also apply to a range of sports including netball, soccer (e.g. indoor soccer, including 5-a-side or 6-a-side soccer), indoor cricket, darts or any other team sport, particularly sports with smaller team populations. Said system might both augment existing sporting competitions, with filler games, extra games, training sessions and the like, and generate new types of competition, particularly competitions of a more social and flexible character, made from temporary teams, and including non-registered players (i.e. players that haven't before signed up to a competition and/or haven't paid the yearly registration fee).

The administrative interface is a private space for administrators to setup DDG slots, including defining and categorizing slots according to the desired game type (e.g. define a slot as a ‘training session’, ‘bye match’ or the like, which might be attached to categorically unique initiation steps, particularly whether referees are required for the DDG type), set the required number of registrations before a game is initiated and whether a particular number of active confirmations are then required prior to a game being scheduled, and access related preferences for other automatic systems, including systems for active matching. The administration section might take the form of a private webpage, a program/application, flash code or an applet, or any other suitable framework, provided it allows for restricted access to the setup dimensions of the system.

The administration interface might be divided into components for creating and setting up DDG slots, and components for managing active matching systems.

The administration interface might include fields for creating a singular DDG slot, or string of slots, within a particular venue, within selected courts, within a specified time, or set of discrete times. This would allow, for example, an administrator to setup DDG slots of a particular DDG type for 6:15 pm and 9:30 pm on courts/venues X and Y, or some equivalent. Once a setting of this nature was submitted to an active list of DDG's, said slots might appear on a central public page, accessible by teams and players, such that said teams and players might be able to register for said slots. Setting DDG slots might also require the administrator to set the conditions on which the game will initiate (i.e. the number of registrations) and setting follow-up conditions when after a game might be scheduled (e.g. requiring second stage referee confirmations and/or player confirmations and/or join fees or the like, prior to a sufficiently populated DDG slot being officially scheduled).

The DDG initiation process begins when a defined number of registrations are received for a particular DDG slot. For example, a public game might be set by the administrator to initiate at 12 registrations while a training session might be set to initiate at 5 registrations. The initiation process might either start/schedule a game, or begin follow up processes necessary to start a game. For example, a DDG slot set to ‘initiate’ at 10 registrations, might for example, send out telecommunication notifications that the game will go ahead following the 10^th registration, said message taking the form of “DDG Engine: The public game has sufficient players and will go ahead as scheduled, the game will commence at 6:55 on court 1”. The message might be sent through any suitable electronic device and network, including email, SMS, instant messaging, or any other system judged suitable by a reasonably qualified individual.

The administration interface may also be used to setup a slot not to automatically schedule a game following sufficient registrations, but to perform a range of pre-schedule functions. These functions might include the confirmation or scheduling of a referee, the confirmation of parties that registered for the DDG, or the payment of necessary join fees prior to a DDG being scheduled.

For example, a slot requiring registerer confirmations might, send automated, interactive telecommunication confirmations requesting a final reiteration of ‘yes’ or ‘no’ from all relevant parties at the 10^th registration i.e. following sufficient population of said slot. A message to the effect of “DDG Engine: The public game has sufficient players to go ahead and is now taking final confirmations, please reply ‘yes’ to this message if you would still like to play, and ‘no’ if not, this message will expire at 3:00 pm”, or a practically similar email based message requiring hyperlink confirmation, or a practically equivalent system using any other network device combination.

The confirmation point, i.e. required number of confirmations, after which a DDG is scheduled might be separately defined within the administrative interface. Such that a slot might be setup to require 12 registrations and 8 confirmations. The purpose of the confirmation method is twofold, to provide additional security that a DDG will have a sufficient turnout, and to assist in the sending of join fees and the like, such that said join fees might be attached to the confirmation message, for example if an SMS were sent using a premium SMS channel, such that said SMS billed the receiver between $0.55 and $7.50.

Similarly a slot setup to seek confirmation from a referee may use a similar method, such that an automated communication might sent to said referee requiring an iteration of availability and interest, which the system might use as a validation that a particular DDG can be suitably resourced with a referee. Alternatively an active confirmation method for referees might be replaced with a passive database/roster search, i.e. the system performs an approximate analysis on referee sufficiency based on a league data structure, e.g. a referee roster, for a given slot and might alert an administrator, referee or the like only if referee sufficiency is in doubt. Such specifics are immaterial provided a mechanism exists within the DDG slot setup that allows for referees to be processed within the DDG scheduling process, particular through active confirmations using the above defined method.

Such initiation points, and pre-schedule processes might be defined for each DDG type/category, including separately for ‘challenge matches’ (where existing team A might manually challenges team B to an unrecorded game using tools within discrete team interfaces), ‘public matches’ (where singular players can add themselves to a register and elect to play a game within temporary teams), training sessions (where team A and team B can book a half court each for a formal training session), active matches (where the system prompts Team A or B to play a DDG), and the like. Thus, allowing different settings and requirements to be applied to different types of DDG's. This would allow, for example, training sessions to have an altogether different initiation and scheduling requirements and processes to that of public games.

DDG's might be further categorized for particular seasons (men's, women's etc), for a particular grades (A, B etc), and for different individual/player classes (registered players, non-registered players, both etc). Using these categories, and DDG type categorizations, a league administrator might create a range of discrete slots or strings, strategically positioned and scheduled around existing competition rosters and the like, which serve both registered players and individuals looking for casual games. This range of categorization might allow demand to be distributed, different groups equal access to DDG's, accommodations to be made to certain groups for marketing purposes, e.g. free registrations to players of younger ages, or making free registrations on Thursday as part of a promotion or the like, or the like.

The administration interface might also include preferences relating to actively querying whether a team or player would like to participate in a particular DDG, so called ‘active matching’, wherein DDG registers are actively filled by the system through a process of identifying teams and players likely to accept a DDG if prompted, and using automated communication to prompt said teams or players.

The process of identifying DDG interested teams and players might utilize existing league administrative data structures, including game rosters, finals rosters, and the like, which might be used to identify teams and players that are scheduled to uniquely miss out on games, because of byes, finals or the like. This feature might be controllable through an ‘active matching’ checkbox, that when activated enables the system to query teams with byes, or teams not participating in finals, querying whether they would like a DDG organised for the week in which the team would otherwise have no game scheduled. Such a query might take the form of an electronic message, including SMS, Email, MMS, EMS, instant message or the like, with a message to the effect of “System: Your team has no scheduled game this week, reply ‘yes’ if you would like an unrecorded replacement game organised”. Teams or parties responding in the affirmative, or clicking on an appropriate hyperlink or the like, might be added to an active matching list, to be matched against other teams of a similar position or teams having requested an active matching service, as though they had registered for said slots organically.

Active matching might also be driven by player and team preferences, such that a team or player might register for active matching as a type of service, through selecting preferences within public or team interfaces, or some equivalent, to be queried when DDG's of a particular character arose. Preference settings might include games of a particular type, at a particular time, with a particular number of registered players, or some combination. Using this system a player might, for example, register to receive a join query to join a public game, as an interactive SMS, on Thursday night after 8:00 pm following 8 other players registering for said slot, with a message to the effect of “System: A DDG matching your preferences currently exists on Thursday, would you like to be added to the register?”. Such a system might also be represented within the administrative interface with a checkbox to the effect of ‘allow preference based active matching’ or the like, or some practical equivalent, for allowing administrators to specify what type of active matching is allowable. Indeed said checkbox may either make visible or hide the related preference field within the team interface (i.e. hide or show the tool for registering for an active matching service) or may cue the system to present an apology/block message to a player or team upon said party registering for the service while blocked. The specific form of the feature is immaterial provided an administrator may turn on or off preference based active matching, and that this is reflected in an appropriate way within or beside fields for initiating preference based active matching, e.g. within team or public interfaces or the like.

The administration interface might also contain fields for operationally distinguishing between registered and unregistered players, by processing registered player lists or the like within the league database, such that said player groups might be restricted entirely, or selectively from DDG slots. This might be actionable through fields for toggling whether or not unregistered players are allowed to participate in particularly DDG types. The enabling of this preference (i.e. allowing unregistered players) would allow anyone to register for a DDG, and shift the system from being aligned with competitions (e.g. associated with players, teams and the like) to aligning with community members and community demand. This might allow any individuals of suitable physical ability to play a game of sport, with little notice, with no previous experience.

The DDG administration interface might take any suitable form provided it singularly or compositely; offers tools to set and define DDG slots, including setting registration points, setting optional player verification points, setting optional referee allocations and confirmation, setting optional join fees and the like. The interface should also offer tools to manage active matching, including enabling disabling bye matching, enabling disabling finals matching, and enabling disabling preference/demand based matching. The interface might use any singular coding framework, or combination of frameworks (C sharp, .Net, java, flash etc), included hard coded into an electronic device, provided said interface performs the above described actions with respect to allowing said functions to be suitably controlled by an administrator. The interface might be related to leagues, bodies overseeing leagues, third party groups, or any other relevant group looking to setup a DDG or equivalent system.

The referee interface is a private access section for referees to set preferences relating to DDG's. It might be centralized and accessible by all referees, or decentralized with discrete referee pages based on a login for each referee.

Preferences from referees might be required in situations where an administrator requests referee confirmation prior to a DDG being scheduled, this is particularly likely for smaller leagues with more limited referee resources. The page might take the form of a private webpage, a program/application, flash code or an applet, or any other suitable framework, provided it allows for restricted access to the referee preferences dimension of the system.

The interface might include fields allowing a referee to set their relation to DDG slots, including setting fields to prevent said referee from being allocated to DDG's generally, setting to preference said referee (i.e. target said referee for being allocated to DDG's), and/or allowing referees to define availability times more generally. The purpose of the interface is to automate and streamline referee participation in DDG's where possible. For example, the settings might be used when a referee allocation is required, such that the DDG engine could perform match analysis between a particular DDG slot and referee preferences, such that a list of matches might be constructed. Using this list, and the associated contact details, a rolling confirmation method might be used to verify a referee for a particular slot.

A ‘rolling’ message is a sequentially distributed message that is sent to a party, responded to or not, and the nature of the response determines the next action. For example, an answer to the negative, or a message expiry, might cue the system to ‘roll’ the message to the next party, where the process is repeated, until a match is found, i.e. an affirmative response is received. The time a party has to respond to said message might be 2 minutes, 5 minutes etc (depending on the message type), and the ‘roll’ might be indefinite, limited to 10 parties, or the like. The roll sequence, i.e. the order of message reception, including who gets preferenced (i.e. asked first), is determined by ranking variables, which might be categorical e.g. interest level as specified in referee preferences, or continuous, e.g. sequenced according to past actions, such that individuals with a history of accepting DDG game allocations might be preferenced first.

In this way the system could construct a contact list of referees, reasonably approximate with the interest level, and or likelihood of allocation acceptance, of said referee, and using rolling messages, or some other suitable confirmation approach, communicate and confirm a referee for a particular game.

The referee interface might take any suitable form, including a centralized web interface, decentralized web interface, direct connection interface (e.g. where referees can adjust status through sending communications directly to the system) provided said interface allows referees to modify their participation with DDG's, including defining categorical interest, and/or availability times, to be used in the event administrators optionally request administrator confirmation prior to game scheduling.

The team interface is a private interface for teams that might act as a decentralized means of registering for DDG's and/or used to define team preferences, particularly preferences relating to active matching. This interface might take the form of a private webpage, downloadable or cached program, a direct interface, or some other suitable framework, such that said interface includes tools to manage team interaction with the DDG system.

This might include;

fields for viewing team DDG bookings (e.g. scheduled training sessions);

fields for making DDG bookings (i.e. registrations for specific DDG's might be made from within the team interface);

fields for registering for an active matching service, such that a team might specify DDG's of a particular character which the team might be prompted to participate in;

The participation tool might be particularly useful for teams that would like to play routine additional games, without the burden of manually and repeatedly adding names to a register. It would allow, for example, a team to identify themselves as willing and interested to play against teams with byes, in the situation where such a team needed an opposition, and/or identify the team as interested in playing additional matches against teams more generally, such that multiple teams with such settings might be matched by the system, on a particular day at a particular time.

The active match service, driven within the team interface, might be optionally used to replace the manual DDG registration process for teams.

It might take the form of a series of fields, relating to different aspects of DDG character, including DDG time, DDG day, DDG date, DDG type, opposition team season, opposition team grade etc, such that said fields might be used singularly or compositely to define slots or situations where said team would like to be notified, to the extent a team is prompted of situations or slots arising that match the character of the active match service description through a suitable communication network and electronic device combination. For example, upon a DDG slot or situation arising that matches a teams active match service description an interactive communication might be sent to said teams representative (e.g. captain or the like), as an SMS or the like, with a message to the effect of “A game matching your teams active match description has appeared on Thursday night, wherein The Bears of Men's B grade are looking for an opposition, reply ‘yes’ if your team would like to participate in this game”. This example describes a situation where an existing team, ‘The Bears’, registered manually for a DDG, the DDG engine determined this action create a situation which matched a teams active match service description, and prompted the team with said active match description to participate in the game. The service might also be used for matching two teams of which neither has expressed any specific interest, e.g. registered, in a demand driven game, but who have both expressed general interest in playing a DDG at a particular time. For example, two team representatives, from two teams, might be sent similar queries for the purpose of establishing a game match. Thus the active matching service may either partially or entirely create demand driven games through a preference based, engine driven, telecommunications approach.

Once active matching queries are sent, and the system detects sufficient teams or players for a full game, this might cue the system to perform an ordinary initiation process, such that the system might either schedule the game, or perform pre-schedule confirmation processes, as specified by the administrator, and as previously described. Thus the active matching process quite literally replaces either the registration of a singular team, or the registration of two teams, in terms of it's procedural position in the system. The active match service tool, allowing teams to specify preferences for active matching, might be viewed as a value added alternative to putting a name down in a register or the like, for the purpose of driving routine DDG's.

The team interface might also include fields relating to ‘challenge matches’, i.e. tools for one team to challenge another team to a DDG, and related fields for enabling or disabling challenges generally, i.e. optionally preventing a team from receiving challenges. Such a system would have a range of applications, including allowing teams to align with particular training partner teams, within the same grade or not, for ongoing ‘challenge matches’ for practice or the like, for scheduling unrecorded rematches of actual competition games, or taken to it's limit for creating the basis of entirely demand driven leagues.

The team interface might take a range of suitable frameworks, including a discrete team page on the internet, an application/program, and/or a direct method of interfacing with the DDG engine (including SMS's, EMS, MMS or voice messages or the like, updating preferences on a central register), or any or method producing an equivalent approach, to the extent said interface provides sporting teams with the tools to register for DDG's, and/or register for an active matching service, including making specifications of the character of the active match, and/or challenge other teams to DDG's and the like.

The public interface is a centralized register displaying all available DDG slots, which might be used by players, teams or individuals to register for DDG's, including preferences for accessing the active matching service for individuals.

The interface might function as the exclusive means of registering for DDG's, or work in association with other registers, including discrete team interfaces embedded with DDG register/active matching functionality, direct services for registering for DDG games, or a practically equivalent approach for expressing interest in joining a DDG using a suitable electronic interface and/or network as judged by a reasonably qualified person.

The interface might apply to a singular league and venue, or several leagues and venues, optionally related to different sports, such that a particular public interface might provide access to DDG's or individual active matching services or the like for different leagues and/or different sports. Thus, related fields might differ depending on the scope and framework of said interface, such that public interfaces applying to multiple leagues might contain fields relating to, for example, details like post codes and the like, while public interface applying to multiple sports might include fields related to selecting sport type or the like. These variations are immaterial provided said interfaces allows appropriate access to tools for joining DDG's or registering for individual active matching services, or equivalent services, suitable to the electronic context to which said interface is attuned.

The interface might be structured to display a list of relevant DDG slots, or methods for populating a list of DDG slots through means of an appropriate search, such that said list might include a list of DDG's and associated details, i.e. DDG definition data and DDG status data, including the DDG type (i.e. e.g. a training slot, public game slot, active match slot, challenge match slot or the like), fill status (i.e. the number of current registrations for a particular slot and the initiation threshold, for example a slot coupled with the description ‘5/10’ might indicate that the slot currently has 5 registrations and requires 10 for initiation), game status (i.e. the current processing stage of the slot, including whether it is ‘open’ for registrations, ‘closed’, ‘cancelled’, ‘initializing’, ‘scheduled’ or some other suitable description of the DDG state, or processes relating to said state), the data and time of the slot, venue (if required), court number, the names of other players or teams that have registered for the slot, or other relevant data.

This list is non-exclusive and dependent on the nature of the public interface, for example a public interface applying to multiple leagues and sports might have more extensive descriptions about the sport, and/or league, and/or league location. Similarly a public interface constructed as a direct service, e.g. accessible by sending SMS's to a specific number, e.g. through a message to the effect of “Sender: basketball game Thursday”, might display information causally and selectively, through sending messages back to the sender. These variations are immaterial provided said interface provides a suitable mechanism for accessing information to facilitate an individual registering for a DDG, or active matching service. Similarly the same interface might allow the player/individual to make an actual registration through a similar means, e.g. texting ‘join’ or the like, either in response to an information return, or singularly and in association with other game data.

Processes for registering for a DDG using a web based format might include ‘join’ buttons next to DDG slots, such that players can click ‘join’ to add themselves to a particular DDG register. A downloadable or cached program might use a similar method.

The public interface might also include fields relating to an active matching service, for establishing automated relationships between a player and the DDG engine. Associated fields make take on a similar character to the active matching service described for the team interface, such that an individual might specify the character of a slot or situation said player would like to receive an active match query, when such a match is detected by the system, including DDG time, DDG day, DDG date, DDG type, registration numbers, attuned to a specific season (men's, women's etc), attuned to a specific grade (B grade, C grade etc), attuned to a particular category of player (registered, unregistered etc) or any other variable or data relevant for receiving automated active matching queries. For example, the active match service, driven by the DDG Engine, might be set by a particular player to send a query to said player, if DDG situation arises of a ‘public’ type, on Thursday night, after 8 pm, for players from the Men's Season, of players from C or D grade, and 8/10 registrations are taken. Such match arising might cue the system to send a query in the form of a suitable interactive automated communication, including SMS, with a message to the effect of “DDG Engine: A public game on Thursday scheduled at 7:00 pm has 8/10 registrations, and matches your active match description, reply yes if you like to be added to the register?”. As previously described the interactive message might take a range of formats and forms, use a range of electronic devices or networks, provided said message provides the recipient with the necessary capacity to add said recipient to a register or the like to participate in the DDG in question. The purpose of the active matching fields within the public interface is to maximize the number of players registering for DDG's, by providing mechanisms to make DDG's routine.

The public interface might take the form of a centralized web-page, downloadable application, direct access service, e.g. controllable through sending communications to the system by means of a suitable message (e.g. SMS, EMS, MMS, instant message) or any other medium, electronic device, or network which similarly facilitates the registration of a player to a DDG slot, or equivalent service, or an active matching service, or equivalent.

The DDG engine is a processing, integrative and communicative agent for combining data from the various interfaces including singularly or collectively from the administrative interface, team interface, referee interface and public interface, and data from the league database, including game rosters, referee rosters, as a means of scheduling DDG's through a process of passively taking DDG registrations and actively querying potential DDG participants, to push registrations to a point where a game can be scheduled.

The DDG engine includes several distinct processes, using several different algorithms. including,

An algorithm for determining whether a particular DDG is to be initiated or cancelled, e.g. given registrations, verifications, referee confirmations as required.

An algorithm for identifying parties to be added to the active match list, including identifying parties on the basis of situation (e.g. a team uniquely having no scheduled game) and/or a preference setting/situation consistency.

An algorithm for allocating referees to a particular game, including optionally constructing a match list for the distribution of rolling communication. The necessary communication usable by the engine might use interactive automated SMS's, emails, MMS, EMS, instant messages or the like, such that these messages might be sent to team representatives, or relevant parties, in relevant situations, including game confirmations, referee confirmations, game notifications, active match queries and the like. As specified above the system and processes performed by the engine might be particularly useful for teams with byes, teams missing out on finals, or teams requesting additional games, or the like, such that said teams are more likely to be interested in playing a DDG.

The present invention will now be described in terms of a preferred system. It is to be understood that the particularity of the accompanying description does not supersede the generality of the preceding description.

In a preferred system, the DDG system would be customized for a particular league and a particular venue, such that the public interface, administrative interface and team interface relate to a specific sport and specific venue. Said interfaces might be setup as discrete web pages connected to the league website, accessible through suitable private logons and the like, such that teams and players might use said web-pages to register for slots, or register for an active matching service and administrators might use a discrete web page to setup and manage said slots.

In a preferred system the DDG Engine would be connected and customized to the league database, i.e. the database running software for managing the sporting competition, including creating rosters, maintaining ladders, creating referee schedules and the like, such that the DDG system might use data structures including game rosters and referee rosters, from said administration system, within the active match process (to identify teams uniquely missing out on a weekly game) and referee assign process (to identify unutilized referees that might oversee particular demand driven games). In a preferred system the DDG system and sport administration system would be stored on, and processed through a remote server.

In a preferred system the DDG Engine would be setup with three channels to a SMSC server, for sending and receiving standard SMS through telecommunication networks, and for sending or receiving premium SMS through telecommunications networks, such that messages from a premium service might be attached to an administrator designated sum, specified in the administration interface i.e. for a ‘joining fee’, ‘deposit’ or the like, e.g. $2.50 optionally payable when a DDG confirmation is made by SMS by a registerer. Emails might also be sent as a means of communication directly from the server on which the DDG system is hosted.

In a preferred system the administrator would setup multiple demand driven game types around existing competitions, such that ‘training slots’ might be setup immediately before a competition, ‘public game’ slots and ‘active game’ slots for specific grades would be scheduled proximate to the competition related to those grades, ‘public game’ slots for unregistered players might be scheduled on days without a formal competition, and/or on days more generally associated with entertainment rather than competition, e.g. Friday nights and the like, such that the distribution off DDG slots, and the categorization of said slots, both practically distributes the demand and aligns the function of the system with the needs of different groups, situations and target markets.

In a preferred system the administrator would setup all DDG slot categories to initiate following sufficient registrations, such that initiation would require no less than 80% of registrations be confirmed through system initiated and received SMS following sufficient registrations being recorded, to which would be attached booking fees billed by means of premium SMS paid by the registerer in the process of making a confirmation. The registerer might be billed $2.50 per confirmation or some other reasonable sum, which would appear on said registerer's mobile phone bill.

In a preferred system this process this might take the form of, individuals, players or teams registering for a DDG slot over the internet, registration number reaching a point defined by administrators and cueing an initiation process, said initiation process sending interactive confirmation SMS's to said registerer's, at least 80% of said registerer's responding affirmatively to said SMS, such that any affirmative response bills the registerer $2.50 as a join fee, whereupon, after receiving registrations and confirmations, the system schedules the game, and SMS notifications are sent out to all relevant parties, including registerer's, referees and the like, with notification of game details, court number, court time and the like. Any interruption to this process, including in terms of insufficient registerer's, insufficient confirmations or the like, would cue the canceling of the game and the issuing of SMS notifications to relevant parties to that effect.

In a preferred system ‘active matching’ services would be enabled in the administrative interface, such that the system might act proactively to involve teams uniquely missing out on weekly games, and to involve teams or players identifying themselves as willing and interested to participate regularly in DDG's of a particular character, in a public or team interface. In a preferred system this process might take the form of a query SMS sent to team representatives who's team is uniquely missing out on a weekly game, or a query SMS sent to a party who's preferences for an active matching service align with a slot or situation, such that said SMS's for either group might be responded to in a particular way if a DDG game is desired. In a preferred system affirmative responses to queries directly replace registrations for a DDG slot.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings. It is to be understood that the particularity of the accompanying drawings does not supersede the generality of the preceding description of the invention:

In the drawings

FIG. 1 is a schematic block diagram of the demand driven gaming system and various possible features of the system;

FIG. 2 is a flow chart of the steps associated with registering for, initializing and scheduling a demand driven game;

FIG. 3 is a flow chart of the steps associated with performing active matching, i.e. system driven functions to populate DDG slots;

FIG. 4 is a flow chart of the steps involved in setting up a DDG slot/string;

FIG. 5 is a flow chart of the steps associated with setting individual preferences for personal active DDG matching through a public interface;

FIG. 6 is a flow chart of the steps associated with setting team preferences for team active DDG matching through a team interface;

FIG. 7 is a screen dump of the administration Interface;

FIG. 8a is a screen dump of the Public/individual Interface;

FIG. 8b is a screen dump of the processing screen associated with a DDG initializing;

FIG. 9 is a screen dump of the Team Interface;

FIG. 10 is a screen dump of the Referee Interface;

Referring to FIG. 1 the system 10 uses a communications network 122 driven by DDG Engine 15 to facilitate the passive and active population and scheduling of demand driven sporting games, through processing party preferences from referee interface 11 administration interface 12 public interface 13 and team interface 14, processing league data structures from database 16, particularly competition rosters 161 and referee rosters 162, processing DDG registrations 141 within slot register 152 and sending and receiving automated communications with relevant parties through channels 181, 182 and 183. The process of scheduling a DDG might include, the administrator 121 setting up an empty DDG slot through interface 12, said slot appearing on public interface 13 and 14, in such a way that players 120 teams 124 and individuals 125 can register for said slot. The DDG might initialize S20 once a predesignate number of registrations 141 are received, ‘initializing’ being either scheduling the game S29, or performing post-registration processes including referee confirmations S24 and/or active player confirmations S27 and/or player billing S28.

DDG slots might be setup categorically, i.e. as different DDG types, using interface 12, such that a particular DDG might be setup as a ‘training slot’, ‘challenge slot’, ‘public slot’, ‘active slot’ or the like, each type having categorically discrete registration points, verification points, referee and billing settings, game descriptions, and relations with the active matching system (described later) and the like. Setting up DDG slots might include the following steps;

setting the slot time or times S42, using the ‘Slot Time’ tool depicted in FIG. 7, including whether the DDG slot is open on a singular or recurring fashion, and the day, date and time of said slot opening, for example, a slot or string might be scheduled for all Tuesdays at 6:30 between a given date range, or for a singular Tuesday at 6:30, or all Tuesdays at 6:30 barring a, or several, dates between a given date range, or any variation. This system allows administrators to embed open DDG slots on routinely spare courts, one off spare courts, and the like.

defining the DDG game type at S43, using the ‘Slot Settings’, ‘Game Type’ tool depicted in FIG. 7, such that a particular slot or string might be set as a ‘training slot’ for team training, a ‘public slot’ open to singular players and/or unregistered individuals, a ‘challenge slot’ slot wherein said slot might be used by teams to challenge other teams to unrecorded games, an ‘active slot’, wherein said slot is actively filled by the system (described later). Defining DDG slot game types is useful for distributing demand, and maintaining different settings for different game types.

setting/defining the DDG slot season and grade S44, using the ‘Slot Settings’ ‘Season’ and ‘Grade’ tools depicted in FIG. 7, such that said tools allow DDG slots to be defined for particular seasons or grades only. This setting might be used within DDG game descriptions only, as a recommendation or the like. The setting is useful for ensuring a certain number of DDG's are available for each season or grade.

setting required referees S45, such that a DDG slot can be setup to require and/or confirm referees at S24, optionally by sending automated communications requiring a response to said referee at S262 through channel 181, such that a DDG shall optionally not initiate without referee confirmation. This setting allows administrators to control DDG scheduling, such that said games might only be scheduled after a referee is organised, thereby preventing DDG's from stripping referees from ordinary competitions.

setting required number of registrations at S46, such that a slot can be setup to initiate at varying levels of demand. This setup stage will define the registration point 1211 controlling how many registrations at S23, i.e. registrations 141 in slot register 152, initiate a particular DDG, either scheduling the game or cueing post-registration/pre-scheduling processes, such as player S27 or referee S24 confirmation.

setting required confirmations S26, such that a slot can be setup to require secondary confirmations prior to a game being scheduled, of a number defined by the administrator at verification point 1212 in administration interface 12 depicted in FIG. 7 as the ‘schedule’ tool. This number might be less than the initiation point, such that a DDG might require 12 registrations to initialize and 10 confirmations to be scheduled. Confirmations might take the form of automated interactive SMS sent through channel 181 through SMSC 18, with a message to the effect of “DOG Engine: Public Game X at 7:15 on Thursday is taking final confirmations, reply ‘yes’ if you would like to play”. Each positive reply received through channel 182 might count as a confirmation.

setting whether confirmations also bill the player at S48, this might determine whether a final scheduled game notification is sent from a standard 181 or premium 183 SMS channel, such that any messages sent through a premium SMS channel might bill the registerer/player anywhere between $0.55 and $7.50 to receive. Such an optional fee might allow the administration to impose a join fee or the like, on players using the demand driven game system.

setting whether the slot is accessible by unregistered players at S222, i.e. players that have not ‘signed up’ to the competition and paid a registration fee or the like, such that unregistered players might be blocked at S223. If the administrator does allow unregistered players for all or some DDG slots, unregistered players upon registering for a slot might be added to slot register 152 at S224, as per normal.

Finally DDG slots might be given a name and submitted to an active slot list at S49, S410 and S411, such that said list represents DDG slots which are accessible through public registers, or slots being processed by DDG Engine 15 i.e. taking registrations, or being used for active matching, or the like. Once slots are defined and activated S411 they might appear in FIGS. 8a and 9, allowing for players/individuals to register for slots at S21, DDG Engine 15 to use said slots within Active Match Processing, or teams to register for slots S211.

Other administrative settings include the enabling/disabling of team challenges depicted as a checkbox in FIG. 7, said checkbox might open up and unlock the ‘issue challenge’ tool within discrete team interfaces FIG. 9, such that teams might challenge other teams S3b2, irrespective of grade, to unrecorded matches, within available ‘challenge’ DDG slot types, provided said team, or a team being challenged, has not disabled challenges S3b4, resulting in block message S3b5. Issuing a challenge is the same procedurally as performing an active match at S35, such that the system might send a communication through channel 181 to a representative of the challenged team at S3b3, or have the challenge appear within the challenged teams private interface, to be responded to in a reasonable period of time. If said challenged team accepts the challenge S3b9 the match settings are parsed to S20, where the game is initiated according to processes attached to challenge match DDG slots specified in S40. If the challenged team declines the challenge an appropriate notification is given to the challenger at S3b8, by means of an SMS, Email, post within the team interface, or the like.

Administrators might also control whether active matching is performed by the system, using the ‘Allow Active Matching’ tool in FIG. 7. This tool might unlock or make visible the respective active match preference tools depicted in public interface FIG. 8a. and team interface FIG. 9 Active matching is an automated service which actively fills DDG slots, through a process of sending queries to parties for participating in a DDG, although said parties might not have expressed a specific interest in said DDG. This might be particularly useful such that DDG Engine 15 might process league roster 161 at S312 to generate a list of teams sitting out on their weekly game at S314, because of a bye (rostered sit out), because said team might have missed out on finals, or the like, and target said teams for the provision of a replacement game as a DDG. Targeting might be achieved through SMS channel 181, an email, message within team interface 14, or a practical equivalent, such that said query might take the form of a specific game offer at S36, including opposition and court details, when after an affirmative response to said query would parse game details to S20, given appropriate opposition confirmation.

Viewed from one aspect active matching might be regarded as a prompting system for encouraging and organising teams 124, players 120 and individuals 125 to make use of demand driven gaming slots, it also functions more generally as a service, such that players and teams can request automated queries for demand driven games matching a, or several, particular characters at S51 and S61, accessed through interface 13 or 14, depicted in FIG. 8a and 9 respectively.

Said preferences in interface 13 might allow individuals to request active match queries based on slot time S52, game type S53, season S54, grade S55 and registration level (i.e. the number of registrations recorded for a particular slot in slot register 152) S56. Thus, for example, an individual might request queries be sent for public games, for B grade players, at Thursday, after 7:00, when more than 8 players are registered. In this way said player might only receive a query for a DDG of suitable character and with a reasonable chance of going ahead. Variations of this system also allow teams to request active match queries for bye matching only (i.e. specifically and only to play teams with byes) at S62, finals matching only (i.e. specifically and only to play other teams knocked out in finals) at S63. Otherwise a general active match service for teams might allow might for the specification of the desired frequency of DDG's (i.e. maximum number of active matches per week) S65, grade of DDG's (i.e. define grade range for which active matches shall be made) S66, time of I DDG (i.e. preferenced time for an active match) S67.

When Engine 15 detects that a slot, and/or situation matches active match preferences, said parties might be added to the active match list 153, processes and allocated matches and courts at S34, and sent queries at S361.

In situations where a single party, of a two party match, declines an active match, while the other party accepts, the declining party shall be added to a list S363 while the accepting team shall be reincorporated in the active match system, for another round of matches, until a match is found S362, or until the list is exhausted, when-after the party missing out on the active match is notified such at S363, using an appropriate communication sent through channel 181, or an email, or direct message within interface 13 or 14. Positive responses at S361, from both parties, cue the system to parse the active match details to S20 at S37, one negative response at S361 strikes said team from the active match list 153, while the other party is put back in active match list 153 for second round matching.

Registering for DDG slots, without active matching, might be performed through public interface 13 and team interface 14 at S21 and S211 respectively. The interfaces are depicted on FIGS. 8a and 9 and are designed to allow navigation of DDG slots, through filters and the like, and registrations to be added to discrete and attached slot registers 152. A slot might be registered for at S22, by selecting the appropriate button, and or submitting an appropriate set of preferences, within a suitable interface. A registration shall be added to the slot register 152 at S224 if the player is registered. If the player is not registered, administration preferences must be set to allow unregistered players at S222, else the registration is blocked at S223 and an appropriate error message is displayed, e.g. ‘this service is only for registered players’. At an arbitrary point before a game, e.g. 3 hours or the like, upon the registration of the last required registration for initiating a game at S23, the system might begin the initiating process, and display screen FIG. 8b, indicating the progress of game initiation. If the system detects the required number of registers has not joined at S23 the game might be canceled in a suitable manner at S231. At this point no notification to relevant parties is required, since both interfaces expressly state initiation shall only begin with sufficient registrations.

If the administrator has turned on referees at S24, the system is required to find a referee before proceeding further. An active or passive method might be taken to confirm referees, using an active method the system processes lists of referees at S26 and generates a match list at S27, this might be ordered according to a range of variables, including expressly selected availability times (e.g. inputted on interface 11, FIG. 10), congruence with a referee roster, previous allocations and the like. Once an appropriate match list is created, using an active method, confirmation messages might be sent to said referee through channel 181, an email or the like, at S2711. If the referee responds in the negative, or does not respond within a given time, the next referee on the match list might be queried at S2714. If an appropriate response is not forthcoming before the list is exhausted the game might be cancelled at S2715. A passive method of referee confirmation shall, rather than sending communications to said referee, automatically assign the top referee on the match list at S2712. Alternatively an administrator might select no administrators, and allow the process to be handled organically at the venue.

Once referees have been processed, administrators might set the system to require final and active confirmation at S28. This might involve the sending out of communications through channel 181 and 183 at S281, as depicted on FIG. 8b, to parties that registered for the slot, and require a specific number of affirmative responses. The number of confirmations is processed at S282, such that a sufficient number shall cue the system to continue, while an insufficient number shall cue the system to cancel the game at S231 and issue notifications to all parties receiving a confirmation query at S232.

Once a game has confirmed referees, and sufficient confirmations, final notification might be given to all relevant parties that a game has been definitively scheduled for a particular time. At this point the administrator might wish to issue join fees or the like, at S29, such that game notifications might be sent out through a premium SMS channel 183 at S291, thus charging the mobile phone of the registering party a designated fee between $0.55 and $7.50. This might act to restrict frivolous or irresponsible use of the system. Other billing methods might also be used at this stage, including merchants, or merchants derivatives. An administrator might also use a standard SMS, without a booking fee, at S292.

Once a sufficient number of registrations have been received S23, optionally from unregistered players S221, referees have been optionally actively S271 or passively S712 organized, game confirmations have been sent S281 and sufficient affirmative responses received S282, and final notifications of game scheduling have been sent S292, optionally using a premium SMS channel to attach a fee to said notification S291, a DDG slot might be internally marked as ‘scheduled’ S210 and the game status changed on the public and team registers to reflect such.

It is to be understood that various alterations, additions and/or modifications may be made to the parts previously described without departing from the ambit of the present invention, and that, in the light of the above teachings, the present invention may be implemented in software, firmware and/or hardware in a variety of manners as would be understood by the skilled person.

Further it is also to be understood that the present invention might be implemented with all, several or one of the features described, specifically including, but not limited to, being implemented as a singular system for registering for particular DDG's (i.e. without an active matching service), a singular system making active matches (i.e. without passive DDG registers), a singular system for contacting parties uniquely without a weekly game, and/or implemented with all or several of the interfaces provides, such that said system might function using an administrative and public interface only, or an administrative interface only, and function purely through direct contacts. Such variations are deemed to be within the natural variation of the system, provided said variation performs one or some of the functions previously described.

The present application may be used as a basis for priority in respect of one or more future applications, and the claims of any such future application may be directed to any one feature or combination of features that are described in the present application. Any such future application may include one or more of the following claims, which are given by way of example and are non-limiting with regard to what may be claimed in any future application.

Claims

1. A demand driven game management system for sports implemented over an electronic communications network, including:

(a) a public interface for registering for demand driven games, and active matching services;

(b) a team interface for registering for demand driven games, and active matching services;

(c) an administration interface for creating demand driven game slots and categories, and setting related preferences, including active game matching, unregistered player access and the like;

(d) a referee interface for setting referee preferences and availability; and

(e) a DDG engine for processing game registrations and verifications, processing preferences from various interfaces and processing court availability and performing active match processing.

2. The system of claim 1 where electronic game representations are implemented as physical sporting games, including scheduling and organising parties by suitable notifications, by an electronic system following sufficient registrations and sub-functions designated by an administrator.

3. The system of claim 2, wherein sub-functions include SMS based interactive confirmations, sent from the system to the registerer, and responded to from the register to the system.

4. The system of claim 2, wherein sub-functions include SMS based referee confirmation, sent from the system to the referee, and responded to from the referee to the system.

5. The system of claim 4, wherein referee involvement might be predefined, specified in the referee interface or otherwise, particularly a league referee roster.

6. The system of claim 2, wherein sub-functions include join fees, deposits, or the like, applied to a player or team registering for a demand driven game, by means of premium SMS, credit merchant, credit based derivative, or EFT derivative.

7. The system of claim 1, wherein said system identifies teams exclusively or distinctly without a competition game for a particular week, whereupon said teams are saved to and within a temporary register.

8. The system of claim 7, wherein said temporary register is used as the basis of active match processing, wherein teams are matched against other teams, and to admin defined DDG slots.

9. The system of claim 7, wherein said temporary register is used as the basis of a contact list, to send out queries to parties, enquiring whether said party wishes to participate in a specific actively matched game, or be matched to a game generally.

10. The system of claim 9, wherein said queries take the form of interactive SMS.

11. The system of claim 9, wherein said queries take any direct electronic form, including instant messaging, a PSTN derivate, email, EMS, MMS or the like.

12. The system of claim 7, wherein said temporary register might also be populated with player or teams registered for an active matching service, and who's preference within said service align with a slot or situation to which a query is related.

13. The system of claim 7, wherein said temporary register, populated by situation or preference, is used as the basis for creating demand driven games, such that teams within said register are matched for a game, i.e. Team A v Team B, through a suitable matching process.

14. The system of claim 1, wherein said matches are applied to a suitable court, i.e. a spare court identified by an empty demand driven game slot.

15. The system of claim 1, wherein suitable team match/court combinations are confirmed through automated electronic messaging, as a means of gaining approval for scheduling a particular game.

16. The system of claim 15, wherein active match confirmations are made by means of SMS.

17. The system of claim 15, wherein active match confirmations are made using any suitable electronic device/network combination, including instant messaging, email, EMS, MMS, a PSTN derivate, or a practical SMS equivalent.

18. The system of claim 1, wherein said team interface allows said team to directly register for a particular demand driven game, i.e. slot X on day X.

19. The system of claim 1, wherein said team interface allows a team to enter preferences which affect an ongoing relation with the system; such that said team might register to auto-register for, be notified of, or the like, a demand driven game of a, or several, particular characters, as said games arise.

20. The system of claim 1, wherein said team interface might allow for the challenging of another team to an unrecorded demand driven game, such that a challenge might be made generally, or tuned to a specific court and time.

21. The system of claim 1, wherein said public interface allows an individual to directly register for a particular demand driven game, i.e. game X on day X.

22. The system of claim 1, wherein said public interface allows an individual to enter preferences which affect an ongoing relation with the system; such that said individual might register to auto-register for, be notified of, or the like, for a demand driven game of a, or several, particular characters, as said games arise.

23. The system of claim 1, wherein the system response to an identified active match is a SMS notification to the relevant party that a DDG exists that matches an active match rule description.

24. The system of claim 1, wherein the system response to an identified active match is a email notification to the relevant party that a DDG exists that matches an active match rule description.

25. The system of claim 1, wherein the system response to an identified active match is an updated register on a relevant web page.

26. The system of claim 1, wherein the system response to an identified active match is an automatic registration of the relevant party to the DDG that matches an active match rule description.

27. The system of claim 1, wherein said referee interface allows for setting preferences relating to whether or not a referee will be matched to a DDG.

28. The system of claim 1, wherein said referee interface allows for setting availability times for participating in a demand driven game.

29. The system of claim 1, wherein said administration interface allows an administrator to turn on or off a system for populating DDG's that does not rely on specific expression of interest for specific games.

30. The system of claim 1, wherein said administration interface allows said administrator to control whether or not unregistered player are allowed access to DDG's generally.

31. The system of claim 1, wherein DDG slots can be created which align with actual spare slots (courts and times).

32. The system of claim 1, wherein DDG slots might be categorical, such that said slots apply discretely to a particular game type, e.g. a public game, a training session, an active match game, a challenge match, or the like, such that registering for a particular slot is synonymous with registering for a particular type of DDG.

33. The system of claim 1, wherein empty DDG slots might have attached registration points, specified by an administrator or otherwise, such that said registration point might represent the demand point at which a game initiates.

34. The system of claim 1, wherein empty slots might have attached confirmation points, specified by an administrator or otherwise, such that said confirmation point might represent the number of confirmations, i.e. positive responses from a registerer made in response to a confirmation request from the system, required before a game is scheduled.

35. The system of claim 1, wherein empty slots might have attached join fees, such that an administrator might specify an amount charged to a player, as a deposit or the like, for registering for, or confirming interest in, a demand driven game.

36. The system of claim 1, wherein said fees are charged by means of a premium SMS.

37. The system of claim 1, wherein said fees are charged by means of credit merchant, credit based derivative, or EFT derivative.

38. The system of claim 1, wherein said engine is used to process whether a demand driven game slot, and associated actions of registers and the like, meets requirements designated by administrators, or the like, including categorizing the sufficiency of registerers, the sufficiency of confirmations, the sufficiency of deposits, and/or other requirements, such that said process effects whether a demand driven game meets administrator requirements necessary for said game to be scheduled.

39. The system of claim 1, wherein said engine can identify teams uniquely not playing for a particular week and add said teams to a matching register.

40. The system of claim 1, wherein said engine can use team and player preferences as a means of adding said teams and players to a matching register.

41. A method of scheduling demand driven sporting games using an electronic communications network, including the steps of:

providing a setup interface to create DDG slots or equivalents to be used for DDG games;

providing a player or team interface for taking expressions of interest in joining a particular game, or, taking expressions of interest in joining games of a particular character i.e. a join service;

providing a mechanism to process registrations and other data including providing a mechanism for automatically determining whether conditions exist which match admin defined conditions for which DDG's might be scheduled.

providing a mechanism to schedule games including communicating ‘scheduled’ status to relevant parties.

42. A demand driven game management system, including:

a public interface for a player or individual to register for a demand driven game and/or demand driven game service; and/or

a team interface for a team to register for a demand driven game and/or demand driven game service; and/or

a referee interface for a referee to discretely define a relation to the DDG system and/or define availability times; and/or

an administration interface for an administration to define DDG's and related preferences, optionally including whether or not to allow active matching and/or the allowing of unregistered players to participate in DDG's; and/or

a DDG engine for identifying whether conditions exist for a DDG game to be scheduled, and for performing necessary communications and confirmation during and after which.

43. A demand driven game management system for sports implemented over an electronic communications network, including:

(a) an administration interface for creating demand driven game slots and categories, and setting related preferences, including active game matching, unregistered player access and the like,

(b) any one or more of the following interfaces: (i) a public interface for registering for demand driven games, and active matching services, (ii) a team interface for registering for demand driven games, and active matching services, (iii) a referee interface for setting referee preferences and availability, and

(c) a DDG engine for processing game registrations and verifications, processing preferences from various interfaces and processing court availability and performing active match processing.