AU2008200425A1 - Systems and methods for managing demand driven sporting games - Google PatentsSystems and methods for managing demand driven sporting games Download PDF
- Publication number
- AU2008200425A1 AU2008200425A1 AU2008200425A AU2008200425A AU2008200425A1 AU 2008200425 A1 AU2008200425 A1 AU 2008200425A1 AU 2008200425 A AU2008200425 A AU 2008200425A AU 2008200425 A AU2008200425 A AU 2008200425A AU 2008200425 A1 AU2008200425 A1 AU 2008200425A1
- Prior art keywords
- 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.)
- G06—COMPUTING; CALCULATING; COUNTING
- G06Q—DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation, e.g. computer aided management of electronic mail or groupware; Time management, e.g. calendars, reminders, meetings or time accounting
- G06—COMPUTING; CALCULATING; COUNTING
- G06Q—DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce, e.g. shopping or e-commerce
- G06Q30/02—Marketing, e.g. market research and analysis, surveying, promotions, advertising, buyer profiling, customer management or rewards; Price estimation or determination
0 0 OO (N 00 0 0
Patents Act 1990 COMPLETE SPECIFICATION Standard Patent Applicant(s): Jamware Online Pty Ltd Invention Title: SYSTEMS AND METHODS FOR MANAGING DEMAND DRIVEN SPORTING GAMES The following statement is a full description of this invention, including the best method for performing it known to me/us: 2 0 Systems and Methods for Managing Demand Driven Sporting Games The Present invention both manages demand driven sporting games, Sand performs active demand driven game-fill functions, using a communications C 5 network.
Many people play in local sports leagues and the like in many different Stypes of sport, including for example basketball, netball, indoor soccer, and 0indoor cricket.
N Typically, a league or organising body will set up matches, and provide 00 o game officials and other support, and registered teams will play once a week at c 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 3 00 implemented electronically and automatically given sufficient demand, and the
0 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.
S 5 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) Sslots, and setting directly and indirectly related preferences.
oo00 0 10 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 4 0 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 S 5 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 Smarkets.
N The ability of the system to match 'spare' courts, with teams interested in 00 playing an unrecorded game, in such a way that relevant parties are N 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 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 00 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 S 5 said game 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, Splayers/teams missing out on finals, players/teams identifying themselves as 00
0 10 wishing to play DDG's of a particular character, or the like, and might prompt 0 N 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 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 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 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 00 active confirmations are then required prior to a game being scheduled, and Saccess related preferences for other automatic systems, including systems for Sactive matching. The administration section might take the form of a private webpage, a program/application, flash code or an applet, or any other suitable c- 5 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.
oO 00 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:15pm and 9:30pm 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 the number of registrations) and setting follow-up conditions when after a game might be scheduled 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 The message might be sent through any suitable electronic device and network, including email, SMS, instant 00 messaging, or any other system judged suitable by a reasonably qualified 0 O individual.
The administration interface may also be used to setup a slot not to Sautomatically schedule a game following sufficient registrations, but to perform N 5 a range of pre-schedule functions. These functions might include the confirmation or scheduling of a referee, the confirmation of parties that Sregistered for the DDG, or the payment of necessary join fees prior to a DDG 0 being scheduled.
0 N For example, a slot requiring registerer confirmations might, send 00oo automated, interactive telecommunication confirmations requesting a final Creiteration of 'yes' or 'no' from all relevant parties at the 1 0 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:00pm", 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 00 provided a mechanism exists within the DDG slot setup that allows for referees
Sto 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 S 5 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 00
0 10 court each for a formal training session), active matches (where the system Sprompts 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 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 9 00 that are scheduled to uniquely miss out on games, because of byes, finals or
Sthe 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 S 5 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 N'yes' if you would like an unrecorded replacement game organised". Teams or
00 S 10 parties responding in the affirmative, or clicking on an appropriate hyperlink or 0 N 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:00pm 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 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 0 appropriate way within or beside fields for initiating preference based active 0matching, 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 S 5 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 Spreference allowing unregistered players) would allow anyone to register 00 for a DDG, and shift the system from being aligned with competitions (e.g.
c 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.
00 Preferences from referees might be required in situations where an 0 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, N 5 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 N to DDG's generally, setting to preference said referee target said referee for 00 0 10 being allocated to DDG's), and/or allowing referees to define availability times N 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 parties, or the like. The roll sequence, i.e. the order of message reception, including who gets preferenced 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 12 00 confirmation approach, communicate and confirm a referee for a particular 0 0game.
The referee interface might take any suitable form, including a centralized web interface, decentralized web interface, direct connection S 5 interface 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 N request administrator confirmation prior to game scheduling.
00 N 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 scheduled training sessions); fields for making DDG bookings 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.
13 0It might take the form of a series of fields, relating to different aspects of CDDG 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 00 teams representative captain or the like), as an SMS or the like, with a cI 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.
14 oo 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 Spreventing a team from receiving challenges. Such a system would have a c 5 range of applications, including allowing teams to align with particular training partner teams, within the same grade or not, for ongoing 'challenge matches' for Spractice 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 N leagues.
00oO The team interface might take a range of suitable frameworks, including C- 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 00 to, for example, details like post codes and the like, while public interface
Sapplying 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, Sor methods for populating a list of DDG slots through means of an appropriate i search, such that said list might include a list of DDG's and associated details, 00 i.e. DDG definition data and DDG status data, including the DDG type e.g.
Sa training slot, public game slot, active match slot, challenge match slot or the like), fill status 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 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.
16 0 Processes for registering for a DDG using a web based format might Sinclude '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 N 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 N might specify the character of a slot or situation said player would like to receive 00oO an active match query, when such a match is detected by the system, including c 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 8pm, 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:00pm 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 17 0 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 N DDG registrations and actively querying potential DDG participants, to push 00 registrations to a point where a game can be scheduled.
NThe 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 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
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.
18 oo In a preferred system, the DDG system would be customized for a Sparticular 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 c 5 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 Sregister for an active matching service and administrators might use a discrete web page to setup and manage said slots.
c In a preferred system the DDG Engine would be connected and oo 00 customized to the league database, i.e. the database running software for c 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 00 the like, such that the distribution off DDG slots, and the categorization of said 0 Sslots, 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 c 5 categories to initiate following sufficient registrations, such that initiation would require no less than 80% of registrations be confirmed through system initiated Sand received SMS following sufficient registrations being recorded, to which would be attached booking fees billed by means of premium SMS paid by the N registerer in the process of making a confirmation. The registerer might be billed 00oO $2.50 per confirmation or some other reasonable sum, which would appear on c 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 oo if a DDG game is desired. In a preferred system affirmative responses to 0 0 queries directly replace registrations for a DDG slot.
Embodiments of the present invention will now be described, by way of c 5 example only, with reference to the accompanying drawings. It is to be understood that the particularity of the accompanying drawings does not Ssupersede the generality of the preceding description of the invention: In the drawings N Figure 1 is a schematic block diagram of the demand driven gaming 00 (oo system and various possible features of the system; C Figure 2 is a flow chart of the steps associated with registering for, initializing and scheduling a demand driven game; Figure 3 is a flow chart of the steps associated with performing active matching, i.e. system driven functions to populate DDG slots; Figure 4 is a flow chart of the steps involved in setting up a DDG slot/string; Figure 5 is a flow chart of the steps associated with setting individual preferences for personal active DDG matching through a public interface; Figure 6 is a flow chart of the steps associated with setting team preferences for team active DDG matching through a team interface; Figure 7 is a screen dump of the administration Interface; Figure 8a is a screen dump of the Public/Individual Interface; Figure 8b is a screen dump of the processing screen associated with a DDG initializing; Figure 9 is a screen dump of the Team Interface; Figure 10 is a screen dump of the Referee Interface; Referring to Figure 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
21 0receiving automated communications with relevant parties through channels S181, 182 and 183. The process of scheduling a DDG might include, the (,i administrator 121 setting up an empty DDG slot through interface 12, said slot Sappearing on public interface 13 and 14, in such a way that players 120 teams C 5 124 and individuals 125 can register for said slot. The DDG might initialize 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 (N and/or player billing S28.
00 DDG slots might be setup categorically, i.e. as different DDG types, C-i 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.
22 0 setting/defining the DDG slot season and grade S44, using the 0 '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 Sonly. This setting might be used within DDG game descriptions only, as a C 5 recommendation or the like. The setting is useful for ensuring a certain number of DDG's are available for each season or grade.
Ssetting required referees S45, such that a DDG slot can be setup to require and/or confirm referees at S24, optionally by sending N automated communications requiring a response to said referee at S262 00 (oo through channel 181, such that a DDG shall optionally not initiate without C 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 526, 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 "DDG 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 23 0sent through a premium SMS channel might bill the registerer/player Sanywhere 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 Susing the demand driven game system.
Ci 5 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 Sregistration fee or the like, such that unregistered players might be Cblocked at S223. If the administrator does allow unregistered players for N all or some DDG slots, unregistered players upon registering for a slot 00 might be added to slot register 152 at S224, as per normal.
C 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 Fig. 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.
24 0 Administrators might also control whether active matching is performed Sby 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 c 5 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 Shave 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 C a list of teams sitting out on their weekly game at S314, because of a bye oo 00 (rostered sit out), because said team might have missed out on finals, or the c 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 361, 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 355 and registration level the number of registrations recorded for a particular slot in slot register 152) 356. 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 specifically and only to play teams with byes) at S62, finals matching only specifically and only to play other teams knocked out in finals) at S63. Otherwise a general active match service 0 for teams might allow might for the specification of the desired frequency of IDDG's maximum number of active matches per week) S65, grade of DDG's define grade range for which active matches shall be made) S66, time of I DDG preferenced time for an active match) S67.
c 5 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, Sprocesses 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 00oo to a list S363 while the accepting team shall be reincorporated in the active C 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 Fig. 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 26 00 point no notification to relevant parties is required, since both interfaces
0 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 S 5 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 inputted on interface 11, Fig. 10), congruence with a referee roster,
N previous allocations and the like. Once an appropriate match list is created, 00 C 10 using an active method, confirmation messages might be sent to said referee
Sthrough 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 27 0 merchants derivatives. An administrator might also use a standard SMS,
C 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 c 5 actively S271 or passively S712 organized, game confirmations have been sent S281 and sufficient affirmative responses received S282, and final notifications Sof 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 N marked as 'scheduled' S210 and the game status changed on the public and o00 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 without an active matching service), a singular system making active matches 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.
Priority Applications (3)
|Application Number||Priority Date||Filing Date||Title|
|AU2007900387A AU2007900387A0 (en)||2007-01-29||Systems and Methods for Managing Demand Driven Sporting Games|
|AU2008200425A AU2008200425A1 (en)||2007-01-29||2008-01-29||Systems and methods for managing demand driven sporting games|
Applications Claiming Priority (1)
|Application Number||Priority Date||Filing Date||Title|
|AU2008200425A AU2008200425A1 (en)||2007-01-29||2008-01-29||Systems and methods for managing demand driven sporting games|
|Publication Number||Publication Date|
|AU2008200425A1 true AU2008200425A1 (en)||2008-08-14|
Family Applications (1)
|Application Number||Title||Priority Date||Filing Date|
|AU2008200425A Abandoned AU2008200425A1 (en)||2007-01-29||2008-01-29||Systems and methods for managing demand driven sporting games|
Country Status (2)
|US (1)||US20080305867A1 (en)|
|AU (1)||AU2008200425A1 (en)|
Families Citing this family (21)
|Publication number||Priority date||Publication date||Assignee||Title|
|US8616967B2 (en)||2004-02-25||2013-12-31||Cfph, Llc||System and method for convenience gaming|
|US7534169B2 (en)||2005-07-08||2009-05-19||Cfph, Llc||System and method for wireless gaming system with user profiles|
|US8070604B2 (en)||2005-08-09||2011-12-06||Cfph, Llc||System and method for providing wireless gaming as a service application|
|US7637810B2 (en)||2005-08-09||2009-12-29||Cfph, Llc||System and method for wireless gaming system with alerts|
|US20070060358A1 (en)||2005-08-10||2007-03-15||Amaitis Lee M||System and method for wireless gaming with location determination|
|US7644861B2 (en)||2006-04-18||2010-01-12||Bgc Partners, Inc.||Systems and methods for providing access to wireless gaming devices|
|US7549576B2 (en)||2006-05-05||2009-06-23||Cfph, L.L.C.||Systems and methods for providing access to wireless gaming devices|
|US8939359B2 (en)||2006-05-05||2015-01-27||Cfph, Llc||Game access device with time varying signal|
|US8292741B2 (en)||2006-10-26||2012-10-23||Cfph, Llc||Apparatus, processes and articles for facilitating mobile gaming|
|US8645709B2 (en)||2006-11-14||2014-02-04||Cfph, Llc||Biometric access data encryption|
|US8510567B2 (en)||2006-11-14||2013-08-13||Cfph, Llc||Conditional biometric access in a gaming environment|
|US9411944B2 (en)||2006-11-15||2016-08-09||Cfph, Llc||Biometric access sensitivity|
|US9183693B2 (en)||2007-03-08||2015-11-10||Cfph, Llc||Game access device|
|US8581721B2 (en)||2007-03-08||2013-11-12||Cfph, Llc||Game access device with privileges|
|US8319601B2 (en)||2007-03-14||2012-11-27||Cfph, Llc||Game account access device|
|US8150956B2 (en)||2009-02-09||2012-04-03||Cfph, Llc||Mobile gaming alert|
|AU2011201365A1 (en)||2010-04-06||2011-10-20||Aristocrat Technologies Australia Pty Limited||A gaming system and a method of gaming|
|US8956231B2 (en)||2010-08-13||2015-02-17||Cfph, Llc||Multi-process communication regarding gaming information|
|US8974302B2 (en)||2010-08-13||2015-03-10||Cfph, Llc||Multi-process communication regarding gaming information|
|WO2017201206A1 (en) *||2016-05-18||2017-11-23||Playus Llc||System and method for invitation to games or sports|
|US20180101808A1 (en) *||2016-10-06||2018-04-12||Timothy Joel Zuercher||Platform for coordinating athletic trainers and events|
Family Cites Families (4)
|Publication number||Priority date||Publication date||Assignee||Title|
|US7636669B1 (en) *||1998-12-29||2009-12-22||Bergert Thomas F||Recreational outing reservation system|
|US20050021352A1 (en) *||2002-11-05||2005-01-27||Maierhofer Ronald P.||Sports club creation, management, and operation system and methods therefor|
|US20070060328A1 (en) *||2005-08-12||2007-03-15||Zrike Kenneth L||Sports matchmaker systems|
|US7716078B2 (en) *||2006-06-30||2010-05-11||Intercollegiate Sports Scheduling, Llc||System and method for web-based sports event scheduling|
Also Published As
|Publication number||Publication date|
|Watt||Sports management and administration|
|Cornelissen et al.||The 2010 Football World Cup as a political construct: The challenge of making good on an African promise|
|US9712958B2 (en)||Location-based social software for mobile devices|
|US7001279B1 (en)||Systems and methods for providing multiple user support for shared user equipment in a fantasy sports contest application|
|Stromer-Galley||Presidential campaigning in the Internet age|
|Burton et al.||Campaign craft: the strategies, tactics, and art of political campaign management: The strategies, tactics, and art of political campaign management|
|Bishop et al.||Mapping public participation in policy choices|
|KR100465469B1 (en)||Network game system, network game processing method and computer readable recording medium having network game processing program recorded thereon|
|US20080303811A1 (en)||Virtual Professional|
|US20090187936A1 (en)||Social broadcasting|
|Acemoglu et al.||Coalition formation in non-democracies|
|US20140164126A1 (en)||Method and system for product delivery|
|US20020160824A1 (en)||Game server, recording medium for storing game action control program, network game action control method and network action control program|
|US20100099471A1 (en)||Network-Based Contests Having Multiple Participating Sponsors|
|EP1195184A2 (en)||Apparatus for playing a quiz game|
|US6308160B1 (en)||System and method for integrating operation of an indoor golf facility into operation of an airport concourse|
|Muir||Worth fighting for: Inside the your rights at work campaign|
|US20100088246A1 (en)||System for, and method of, managing a social network|
|US20100114614A1 (en)||Controlling Registration for a Social Event|
|US8301479B2 (en)||System and method for web-based sports event scheduling|
|US20160132604A1 (en)||Goal-based content selection and delivery|
|Masteralexis et al.||Principles and practice of sport management|
|US8090602B2 (en)||Method and apparatus for leisure and entertainment merchandising|
|Swart et al.||The seductive discourse of development: the Cape Town 2004 Olympic bid|
|US20070214182A1 (en)||Establishment-based media and messaging service|
|MK1||Application lapsed section 142(2)(a) - no request for examination in relevant period|