US20080220877A1

US20080220877A1 - Systems and methods for managing recruiting and player allocations within sporting competitions

Info

Publication number: US20080220877A1
Application number: US12/021,576
Authority: US
Inventors: Brett GUTHRIE
Original assignee: JAMWARE ONLINE Pty Ltd
Current assignee: JAMWARE ONLINE Pty Ltd
Priority date: 2007-01-29
Filing date: 2008-01-29
Publication date: 2008-09-11
Also published as: AU2008200426A1

Abstract

System 10 implemented over network 120, is a semi-autonomous bot 14 for managing recruiting and player allocation functions, for sporting grades and sporting leagues, with sub-functions for finding and confirming recruits, controlled through administrative interface 11.

The bot uses recruit interface 12, a discrete page on league website 17, to accept allocation requests from new players or the like, i.e. requests to join the league generally or to join particular teams. Using the preferences and personal details submitted in the recruit interface the bot can generate ranked lists 1411 of the most suitable teams for the initiator of the allocation. Ranking is performed by allocation algorithm 141 and uses team population data, team skill, team recruiting status (set through private team interface 13), team congruence with the initiators personal details (particularly age, gender etc), and previous allocation requests received by said team.

The bot either sequentially or in parallel sends allocation requests to said teams using either SMS's 181 sent through SMSC 18, emails sent through network 120, or logs sent to team interface 13, as a means of finding a team interested in receiving the initiator, preferentially targeting teams whose reception of the player would balance the grade, i.e. preferencing underpopulated or under skilled teams. If a team is found, notifications are sent and team lists are updated, if not, the initiator is added to player pending list 162, awaiting further action from an administrator.

The allocation process may be initiated through the recruit interface, or may be initiated by the bot 14, by autonomously prompting selected parties to have teams found for them, particularly dropout players, or fill/temp players. By doing so the league bot can provide an easy process for dropout players to be reintegrated into the competition (and also confirm their interest/non-interest), or provide underemployed players the packaged option of playing more regularly.

Description

The present invention is a sporting league ‘bot’ that semi-autonomously manages new player allocations within sporting competitions, in such a way that grade character is enhanced, and performs recruit targeting on particular groups.
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, within grades grouped by a combination of skill, age, gender etc, 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.
Individuals wanting to join a particular competition, particular indoor competitions, can either communicate their interest with teams directly, or register their interest generally with the league, usually with an official charged with dealing with new recruits. Said registrations are almost exclusively processed when making rosters in the following season, rather than immediately. This process includes a range of barriers of entry for individuals looking to join competitions. There is either a delay attached to registrations processed by the league official, which can be as long as an entire sporting season, or the difficulty associated with contacting teams directly, or finding an administrator willing to contact teams directly, on said individuals behalf. Such processes obviously impact on the ease with which an individual can join a sporting competition, and can be off putting to new players.
A separate but related function performed by sporting league administrators relates to ensuring grades take on a particular character with respect to team populations and the homogeneity of team skill. Grades are groups of teams of similar skill which compete against each other within the competition. When grade character is suitably controlled by an administrator, i.e. team populations are robust and team skill is relatively even, the grade becomes less likely to be associated with game forfeits, and less likely to be associated with player and team dropouts, than relatively uncontrolled grades, i.e. grades made up of under populated teams, or teams of widely different skill levels.
Team forfeits and dropouts have substantial costs. A single forfeit in a basketball league can cost up to $100, once team fees, referee fees and the like are accounted for. Thus, methods for reducing forfeits and dropouts particularly when scaled up to entire leagues, can have significant financial repercussions.
An aim of the present invention is to provide a mechanism for allocating individuals, particularly new players, to sporting teams, while preferentially performing allocations in a way that complements grade character. The mechanism should also ‘manage’ player participation, by prompting particular parties for allocations.
Viewed from one aspect, the present invention provides a recruit and allocation management system for a sporting league implemented over an electronic communications network, including:
a league ‘bot’, a semi-autonomous program that manages the player allocation process, including performing strategic individual/team allocations, and actively identifying and prompting parties for allocations;
an administrative interface, for league administrators to set bot preferences;
discrete team interfaces, for teams to interact with the bot, including setting team recruiting status, and viewing logs of allocation requests made to said team;
a recruit interface, for recruits/individuals to interact with the bot, including initiating a particular or general allocation request;
a database containing league data, bot lists, administrator preferences, team preferences, recruit details etc;
The present invention may for example be implemented through a website on the internet, a direct interface through a suitable communications system, including electronic messaging in general, or some combination, and provides a discrete mechanism for performing recruitment and allocation functions, particularly of a strategic nature. Said allocations might be initiated independently by an individual (e.g. by a new player looking to join a competition) through a suitable interface (e.g. a ‘recruit’ web page or the like) or a request made through a direct communication to the system (e.g. an SMS, or the like, sent to the system), or might be initiated dependently, based on an individuals response to an allocation request ‘prompt’ sent by the system. An allocation request prompt is the active component of the recruitment/allocation system, such that a prompt might be sent to cue particular groups to play in the current season and have team found for them, for example ‘dropout’ players, whose team played the last but not the current season, and ‘underemployed’ players, who might currently play in a temporary fashion only, are likely candidates for prompts, which if responded to in the affirmative, might initiate an allocation.
The allocation process, of finding a suitable and willing team for the initiator of an allocation request, be it a request made through a recruit interface or from a prompt, might be executed through automated, interactive messages (e.g. SMS, instant messages, email and the like), or through posts to web interfaces (e.g. private ‘team pages’, or a practical equivalent), sent sequentially or in parallel to prospective teams (i.e. teams identified as suitable and potentially in need of players by the system), such that said teams are able to confirm an interest in a particular recruit, through making an appropriate reply to the allocation request, e.g. a reply message, to an SMS, or clickable hyperlink, to an email, or a field, to a message embedded into a team interface, thus allowing the initiator to be allocated speedily and without administrative effort to a team.
The bot is two dimensional, including a processing dimension for constructing ranked lists of teams suitable for a particular initiator (i.e. for constructing ‘allocation rank lists’). Ranking is performed through processing a range of variables including age/gender congruence, team skill/performance, team population, team substitutes, team recruiting status, admin preferences and the number of previous allocation requests sent to said team. Using these variables, allocations can be preferentially directed to teams matching the specification of the initiator, in the most need of players and who have not rejected a number of previous allocation requests, and restricted from being sent to unsuitable teams.
The management dimension of the bot accepts allocation initiations, from new players and the like, and communicates with teams to find a position for the initiator. As a process, an allocation might take the form of a party initiating an allocation request e.g. using a recruit interface on league website, to express a specific or general interest in joining the sporting competition. Within that request the initiator might input personal details and preferences. Said data is submitted to the system where it is processed by the rank algorithm to create an allocation rank list, which is used as a contact list for communicating with teams, and asking said teams to receive said initiator. If a team is found, the parties are notified, and the league database is modified to reflect the changes. If a team is not found, the player details are logged in a player pending list, for the follow-up attention of administrators.
The bot can also function to prompt selected individuals to be an ‘initiator’, i.e. to authorize an allocation. The prompt might take the form of a communication, including an email, SMS, instant message, or a suitable equivalent, with an appropriate reply instruction, sent to a party with a reasonable chance of replying positively to said prompt, including dropout players, that played in the last season but not the current season, and/or fill/temp players, that play for teams in the current season but only play occasionally, e.g. playing between 5% and 40% of games.
Confirmations to said prompts, indicating that said dropout or underemployed player would like a team found, or to play more regularly, might initiate the same process as an independent allocation request made through the recruit interface, such that said dropout or underemployed player might be found a team using the ordinary allocation process. Using this method a percentage of dropout players, the biggest source of ‘loss’ for sporting competitions, and a percentage of underemployed players, might be persuaded to play or play more in the current season.
In this way the bot can automate the administrative tasks associated with recruiting and allocation, in such a way that grade character is enhanced, and systems can be put in place that actively follow-up dropouts and underemployed players, to maximize the bot's capability of addressing losses associated with dropouts.
The present invention could apply to a range of sports including for example basketball, netball, soccer (e.g. indoor soccer, including 5-a-side or 6-a-side soccer), indoor cricket, darts or any other team sport. The system would be particularly useful for sports with high barriers to entry, or in which team population impacts directly on game forfeits, team dropout rates and the like, or where the sport is heavily segmented with respect to skill.
The present invention is relevant to both leagues (e.g. football leagues, basketball associations etc) and bodies which co-ordinate leagues (e.g. VFL, Basketball Victoria, etc) irrespective of whether they are for profit or not-for-profit bodies, such that the bot ‘recruit’ interface might be nested in the websites of either leagues or league coordinating bodies, as a centralized means of requesting allocations to a local sporting team.
The administrative interface is a private space for administrators and might take the form of a private webpage, a program/application or the like, or any other suitable framework, and is used by league administrators to set bot preferences, particularly the scope of automatic function, and the method by which automatic functions are executed, and also be used to view the statistical analysis which guides the allocation process as a general insight into grade health.
The administrative interface might include fields for managing the allocation process, including checkboxes or the like which might be used to temporarily or permanently disable the allocation system, by hiding or blocking the ‘recruit’ interface (where allocations might be initiated), or displaying an error message or the like when a player or individual initiates an allocation. Sub-fields might include setting the particular method by which allocations are performed, including whether emails, SMS's, instant messages, messages posted to discrete team web-pages, or the like, or some combination, are used as a means of gaining confirmations from teams, confirmations from the allocation initiator, and the like, and sending notifications to parties once an allocation is made. Sub-fields might also include whether or not to exclusively target ‘recruiting teams’ within the allocation process, i.e. teams setting their status as ‘recruiting’ within a suitable ‘team’ page, or the like. Selecting this setting might limit the allocation process to only send allocation requests to teams that identify themselves as ‘recruiting’.
The administrative interface might also include fields for managing whether or not prompts are sent to dropout players. This might take the form of a check-box, drop-down box, or a practical equivalent, for turning ‘on’ or ‘off’ prompts sent to dropout players, and might include sub-fields putting controls on said automatic prompts, e.g. fields for setting an upper limit on the amount of times a dropout player might be prompted within a given time-frame (e.g. setting a maximum number of 2 prompts per dropout player per year), and/or fields setting the method by which prompts are sent (e.g. SMS, email or the like), and/or fields for defining the time elapsed since ‘dropout’ that a player might receive prompts (e.g. not targeting dropouts more than 6 months old or the like), and/or fields for defining seasons/grades/groups which might be uniquely targeted or not targeted for prompts (e.g. no groups under the age of x, only dropouts from A grade, or an equivalent group based rule). In this way, although the process might be regarded as automatic, the administrator can manage the character of the automatic prompting to fit the needs and values of the league, particularly with respect to the aggressiveness with which dropout players are targeted for re-registration through prompts.
The administrative interface might also include fields for managing prompts for underemployed players. These fields might take on a similar character to that described for prompts for dropout players, including unique fields to turn ‘on’ or ‘off’ the sending of prompts to underemployed players, and/or sub-fields for specifying the point, or range, at or within which a player is defined as underemployed (e.g. participating in less than 50% of games, or between 5% and 30% of games etc), and/or fields specifying the method by which prompts are sent (e.g. email, SMS, instant message etc), and/or fields for specifying the frequency and/or upper limit of prompts (e.g. how often and/or the maximum number of prompts sent to a particular underemployed player), and/or fields for specifying the groups targeted or not targeted for prompts (e.g. target underemployed players older than x, from A and B grade only, or equivalent group based rules), or other sub-fields which might be relevant to the prompting of underemployed players as judged by a suitably qualified person.
Using said fields and sub-fields an administrator might specify whether dropout and underemployed players are targeted by the bot for more regular playing using prompts, if so which players are regarded as dropouts or underemployed, how prompts are sent, which groups are excluded, and upper limits or the like on prompts.
The administrative interface might also display part of the statistical analysis underpinning the allocation process, providing the administrator the opportunity to make manual allocations, and provide a useful insight into the health of particular grades. The analysis might include lists of teams ranked by skill, e.g. using an algorithm processing win/loss data and team points for/against, to create a proximate measure of skill. The measure might be attached to a percentile to provide a context, e.g. that the team is performing in the top 2% of teams generally, or the like. The same could be achieved for population, and include data on active team-members per game and active substitutes per game.
Such analysis provides a good snapshot and unique insight into the wellbeing of a particular grade, and can identify teams which are playing ‘above’ or ‘below’ a particular grade, grades which might need to be split, having two tiers of skill levels etc. The above described analysis, used by the bot within the allocation process, might augment traditional methods for identifying over or under performing teams or under-populated teams, which presently relies on the experience, good judgement and attentiveness of the league administrator, and superficial structures like ladders, which fail to include all the required data.
The administration interface more generally might take a variety of forms, including a private web page, downloadable or cached program, or a practical equivalent, which provides fields for controlling bot settings, particularly whether or not the bot can perform automated allocations, and related sub-fields, and/or whether or not the bot might approach dropout players, and related sub-fields, and/or whether or not the bot might approach underemployed players, and related sub-fields. Said interface might also include tools to navigate the bot statistical outputs. The interface might use any suitable coding platform, including C Sharp, VB, flash, java, some combination, or some practical equivalent, as judged by a reasonably qualified person.
The team interface is a private space for teams to set preferences with respect to recruiting, and control related functions, including being able to block allocation requests. The team interface might take the form of a private web page in a sporting league website, or any other suitable format or platform, including a direct access platform (e.g. accessible through sending communications directly to the system).
The interface might include fields for updating a centralized team ‘recruiting’ status tool, i.e. for a team to identify itself as ‘recruiting’. Teams identified as recruiting might be preferenced and/or ‘unlocked’, depending on related administrative settings. Thus, team recruiting status might effect the allocation process in-so-far as administrators specify, such that the bot might only allocate players to ‘recruiting’ teams, if specified by the administrator, or if not specified, might simply preference said recruiting teams, by artificially increasing their ‘rank’, or the like, within the allocation process. Recruiting teams might also be marked as such on public league data structures, including league ladders, rosters and the like, or added to a centralized list of recruiting teams, to optionally advertise recruiting status. Conversely the team might use an appropriate field to block all allocation requests, particularly if for example, the team has a low team population, the administrator is allowing allocation requests to non-recruiting teams, but the team is not interested in additional players. In said situation it would be useful for said team to block allocation requests.
Sub-fields relating to recruiting status might include specifying the number of recruits needed, specifying the preferred and approximate skill of said recruit, specifying the required ‘position’ of said recruit (e.g. center, goal-keeper etc), or any other variable which might be relevant in describing a recruit, and/or specifying a comment or message attached to the teams recruiting status. Such a message would be viewable within, for example, the recruit interface, and might be used generally to inform recruits of special requirements or considerations of said team.
The team interface might also include logs or the like of allocation requests received by said team. For example if emails were selected as being used to make allocation requests, the log might include when such an email was sent, the response made to said request, including whether the team accepted the allocation request, or rejected the request either by providing a negative response or allowing the request to timeout. Sub-fields within the log might allow the team to re-initiate an allocation, in a situation where the initiator was not ultimately allocated a team, that might act procedurally like an affirmative response to a natural allocation request, such that the initiator might be sent a confirmation message that a team accepted the allocation request, and might call for final confirmation from said initiator before the allocation is executed. For example, this would allow a team representative to reject an initial allocation request, get consensus from the team, and accept said request later, if the individual making the request was still available. Logs might also be used as the method by which teams respond to allocation requests, i.e. acting in place of emails or SMS's sent to a team representative.
The team interface need not take a specific form, e.g. a webpage, application, direct access system or the like, provided said interface is consistent with the before mentioned description, including, at the least, the capacity for a team to update a centralized team recruiting status, such that ‘recruiting status’ is any team constructed electronic signature which indicates a team is in want of players. The interface might also include logs or the like of allocation requests and fields to re-initiate allocations in particular circumstances. Any format which facilitates this capacity, including a private team webpage, a centralized league page with a recruiting status tool, a third party website with a recruiting status tool, a direct service whereby a direct message and/or contact is used to update a recruiting status, e.g. through an SMS, MMS, a voice message or a practical equivalent, might also be used. The interface might use any coding framework, any electronic device and or network to facilitate the aforementioned description, as judged by a suitably qualified person.
The recruit interface is the portal by which new players or individuals might create or initiate allocation requests. Related functions might allow said individuals or players to optionally view lists of ‘recruiting’ teams, view preferences and messages attached to said team recruiting status, mark specific or general interest in joining a league, and insert personal details or preferences to assist in team allocation.
To assist in team allocation the interface might include fields for inputting personal details including name, age, gender, email address, mobile phone number and the like, or details about previous playing experience, including whether the individual is a ‘new’ or ‘existing’ player, previous playing duration, previous playing position if relevant (e.g. goal keeper), grades and the like. These preferences might used by the bot in the allocation process, particularly restricting allocations by gender and age, and might also be restrictively shown to teams in the confirmation process (e.g. “Bot: an X year old player, of X years experience, has asked to join your team, reply ‘yes’ if you would like to accept said player”. Thus, personal preferences might be used both within the allocation process (i.e. process by the algorithm), and in related functions (e.g. communicating with teams).
The interface might include fields for creating or initiating allocations, e.g. a ‘find me a team’ type field, usable once personal details are entered, including sub-fields for defining the character of a specific allocation request, including sub-fields for specifying the season which teams might be drawn from (e.g. men's, women's, mixed etc), and/or specifying the grade in which teams might be drawn from (e.g. A, B, C etc), and/or specifying or preferencing a particular team, or teams (e.g. ‘The Bears’, ‘The Tigers’ etc), and/or sub-fields to set whether or not to continue the allocation process if the preferenced team allocations fail, and/or sub-fields to request a reconfirm once a willing team is found (i.e. electing to receive a further confirmation before an allocation is executed), and/or sub-fields to set the method by which reconfirmation is received (e.g. SMS, email, or some practical equivalent).
In situations where an allocation request fails because of a lack of suitable teams, or lack of teams willing to take a new player, the initiator might be added to a register or buffer, viewable through the administrative interface, a ‘player pending list’ or the like. The buffer could optionally be used to create teams entirely from players within the buffer. This option would be particularly useful in smaller leagues where spare team capacity is limited, such that any failed allocations might initiate a message to the effect of, “Bot: your details have been added to a buffer, you will be contacted when a team becomes available”.
The recruit interface might take a range of forms, provided said interface acts as a mechanism using which players can initiate an allocation, either to a specific team, e.g. “The Bears”, to a ‘recruiting team’, or of a more general nature. The interface might apply to a singular league or multiple leagues (e.g. acting as a recruitment point for a singular league or multiple leagues, or acting as an allocation mechanism for a singular sport or multiple sports). The interface might take a centralized character, e.g. inserted on a page within a league website, or on a page within the website of the body overseeing multiple leagues, or on a page within the website of a third party, or take a decentralized character, such that allocation fields and sub-fields might be embedded within discrete and generic web pages applying to separate teams. The interface might be implemented using a web based framework, or within a downloadable or cached application/program framework, or a practically equivalent system using a direct interface, e.g. making an allocation request by sending an SMS directly to the system, or an equivalent system using any other direct communication, e.g. email, instant messages, MMS or the like, to begin an allocation process. The above systems might act singularly or in combination to allow players and individuals access to a range of methods by which to initiate an allocation.
Once administrator preferences are established, particularly the bot autonomy level, and team preferences are established, particularly the team recruiting status, and an allocation is initiated, the data can be acted on by the bot. Besides creating statistical summaries of competitions and grades for administrators, the bot functions to perform allocations, particularly by sending spammed or rolling emails, and/or spammed or rolling SMS's, to the most ‘suitable’ teams identified by the ranking algorithm.
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 might be 2 minutes, 50 minutes etc (depending on the message nature and 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 preference, is determined by ranking variables, e.g. sequenced according to the allocation algorithm. A rolling message might take on a range of suitable characters, particularly an SMS or email, such that messages might be replied to through the use of keywords or hyperlinks, e.g. “Bot: if interested in receiving X recruit, reply ‘Y’, or click on the hyperlink”.
The allocation algorithm might use a range of variables for creating the allocation rank list, including initiate details (i.e. the gender, age of the initiate etc), initiate preferences (i.e. the preferred season, grade, team etc), team details (e.g. team skill, population etc), team preferences (e.g. preferencing teams set as ‘recruiting’), allocation request history (e.g. preferencing teams receiving fewer previous allocation requests), in some weighted combination determined in the allocation algorithm. If the allocation algorithm was being used as a central point for accessing multiple leagues, it might also consider post code or the like to match the initiator of the allocation with a local team.
Thus, a party might initiate an allocation, the bot could construct a roll list sequenced according to the allocation algorithm, a message might be sent to the party at the top of the roll list, as an SMS or an email, responded to or not, if applicable sent to the next party on the list, and so on, until an affirmative response to the rolling message is received. Once received an affirmative response might could cue the system to reconfirm an allocation with the initiator, before finalizing the allocation.
Other contact methods, include using a ‘spam’ approach (i.e. sending messages simultaneously, through email, SMS or the like, e.g. to the top 5 teams on the rank list), wherein the first party to respond to a request is allocated the initiator. Using a targeted approach (i.e. sending an automated message to a particular recruiting team only, chosen by the system or the recruit/initiator), or using fields within a team interface, or within a centralized interface, to display an allocation request equivalent, and offer proximate fields for responding to said allocation request.
As well as responding to specific join requests, or specific administrator requests, the league bot might also act autonomously, by creating lists of contact parties, e.g. potential recruits, particularly lists of dropout players (i.e. players that played the previous but not the current season), and underemployed players (i.e. fill or temporary players not playing on a weekly basis), created by processing (e.g. performing search functions) the competition database according to the related preferences in the administration section previously described, and using the results of said search, i.e. the listed dropout and underemployed parties, to serve as the basis of a contact list, to send prompts to said parties through rolling messages, spammed messages or the like with a message either prompting re-registration, or more regular involvement in a team. For example, the prompt to dropout players might take the form of an SMS or email with the message “Bot: you have not reregistered for the 2008 winter season in league X, reply ‘yes’, or click on the hyperlink, if you would like to, and you would like a team found”.
Such a system could work variously to automatically prompt dropout teams with offers to play next season as a group (i.e. prompt the team representative to reregister the team), or offer singular players from dropout teams, detected as having not reregistered within the competition, the automated opportunity of playing for a new team or the like, using the above described method.
Dropout teams are often characterized by several players still wanting to play. The categorical nature of sporting teams, particularly in sports with small team populations, means a single team member dropout can cause a team implosion, where only a little administrative effort can assist the team as a whole, or individual players, to re-register for the following season. Manually taking such action is difficult, particularly in sports like basketball where a league can have up to 1000 teams. Identifying which teams, or indeed players, to target for prompting presents a significant challenge in and of itself, irrespective of the effort required to contact and confirm said teams or players. The automated system for identifying and confirming said parties, and linking the process to a team allocation process, is a practical means of performing the task without burdening administrators.
The prompt to dropout teams or player might take any of the forms previously described for contact parties in the allocation process, and might directly replace the process of manually initiating an allocation (e.g. initiating an allocation through a recruit interface on the league website), such that a positive reply to a prompt might begin a specific or general team allocation process, such that the sub-fields associated with an allocation could be filled in automatically by the system using the data associated with said dropout player, e.g. the season and grade said player used to play in, could guide any allocation process flowing from a prompt.
The bot might also target underemployed players, i.e. players that play occasionally, or fill in occasionally, that might otherwise like to play more often, if sufficiently prompted. The bot might use similar systems to target underemployed players, as described for prompting dropout players, i.e. by analysing the participation level of a particular player, in order to construct contact lists etc. The prompt form might take any form of those previously described.
Using this combined identification and prompting approach a valuable percentage of dropout players might be reregistered, and players only playing occasionally might be prompted to play more routinely through being offered positions in teams needing players. Thus not only would such a system generate direct income (from the extra games played by specific parties choosing to re-register, or register for more games) but the matches could correct imbalances (e.g. add to the populations of under-populated or under-skilled teams) which might otherwise snowball into forfeits and/or dropouts.
The league bot might take any suitable form provided it singularly or compositely; offers functions to manage team allocations, dropout player prompting and underemployed player prompting, including making necessary confirmations using a suitable communication system, including email and SMS. The bot may use any coding framework provided it performs the above described actions.
The allocation and prompting processes may be augmented with a variety of separate features without departing from the ambit of the invention, including an associated credit merchant, of the ordinary variety, or the like to charge team join fees, allocation fees, registration fees, or the like, at any point in the allocation process, including to initiate the process. Or using premium SMS's, rather than standard SMS's, at some point in the allocation process, to bill individuals for the service, through their mobile phone.
These examples serve to illustrate the scope and purpose of the bot and the system generally, and the specific method by which players and individuals might automatically have teams found for them, including in such a way that grade character is complemented, how players from disbanded teams might be targeted/prompted for re-registration, how underemployed players might be targeted/prompted for involvement on a weekly basis, and how the systems tie together, such that prompts feed the allocation process.
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 bot would be setup for a particular sporting association, at a particular sporting venue, e.g. a particular indoor netball or basketball association, and thus provide a point at which new players could join the competition.
In a preferred system the association would be equipped with an ordinary sport administration package, such that said package might centralise and store competition data, including team and player scores, team wins and losses, player turn-outs for games, and any emergency players participating in said games. Consistently, said bot might process and operate on said data by being compatible with the major types of sport administration software.
In a preferred system the bot would be controllable from an administrative interface, a centralized, private access, web-based page, attached to the association website. The administrative interface would include bot related preferences and settings which allow for said administrator to enable or disable the allocation service generally, select the method by which allocations might be executed (e.g. SMS, email etc), whether ‘recruiting’ teams or any teams might receive allocation requests, and any upper limits on the number of such requests received (i.e. the maximum number of allocation requests received by recruiting and other teams).
In a preferred system the administrative interface would include sub-fields for controlling the prompting of dropout players, including setting limits on prompts, defining dropout player groups, setting the method by which prompts are sent (e.g. SMS, email), and setting the groups uniquely targeted (e.g. seniors players only, players in A grade only etc). In a preferred system all of said sub-fields would also be available to control prompts sent to underemployed players.
In a preferred system preferences within the administrative interface would interact with preferences in discrete team interfaces, private, web-pages, attached to the league web site, that might be used to set team recruiting status, and view logs of allocation requests.
In a preferred system recruits or individuals seeking teams might make allocation requests non-exclusively through a public/recruit interface, which might be centralized and web-based, and might take the specific form of a ‘recruit’ page linked to the league website. The page might include fields for personal details, particularly name, age, gender, and the like, fields describing the group into which the individual would like to be allocated, particularly the season and grade of the desired allocation, and fields to initiate or submit preferences to begin an allocation process.
In a preferred system an allocation request would be submitted to the bot for processing, within which the bot would create a ranked list of teams which might suit and/or accept the allocation, such that the list might be ranked by a weighted algorithm including a combination of categorical suitedness (e.g. include teams from appropriate seasons and grades only, based on initiators gender, age and new/existing player status), team population (such that teams with lower population might be preferentially targeted), skill (such that lower performing teams might be preferentially targeted), recruiting status (such that teams identifying themselves as ‘recruiting’ might be preferentially targeted), previous approaches (such that teams receiving fewer allocation requests might be preferentially targeted, and teams receiving above a particular number of requests might be discounted altogether) such that said factors might be suitably combined and weighted within said algorithm. In a preferred system any missing ranking variables would be automatically compensated for, such that in cases where, for example, no skill and/or population data is available, the remaining algorithm components produce a usable rank list.
In a preferred system said list would serve as the basis of a contact list, and the bot would send out SMS's or emails in a sequential/rolling fashion, in order of the teams position on the allocation rank list, with a message to the effect of “Bot: The league bot has identified your team as requiring an additional player, a player has expressed interest in joining, reply ‘yes’, or click on the hyperlink, to allow the player to join your team's next game.” Such that said message might be, responded to or allowed to timed out, either triggering an allocation, or triggering the sending of the allocation request to the next team on the rank list, as appropriate and until a match is created. Once the list is exhausted without an allocation, the initiator of the request might be notified and added to a ‘player pending list’ within the league database, viewable within the administrative interface.
In a preferred system, logs of allocation requests, received by particular teams, viewable within said teams team interface, might allow the team to re-initiate and accept an allocation request, after and despite initially rejecting it.
In a preferred system dropout and underemployed parties would be identified through the bot scanning the league database. Parties so identified, given appropriate selection of administrative preferences, would be sent an SMS or email to the effect of “Bot: X sporting league detected you did not reregister for the current season, some teams in X grade are in need of players, reply ‘yes’, or click on the hyperlink, if you would like a team found, and to play in the current seasons. In a preferred system underemployed players would be similarly identified and sent an SMS to the effect of “Bot: Z sporting league detected you are only playing in X % of games, some teams in Y grade are in need of more permanent players, reply ‘yes’, or click on the hyperlink, if you would like a more permanent position in a team found”.
In a preferred system positive replies to said prompts would cue an allocation process, as though the player had made an allocation request through the recruit interface, while a negative or null response from said parties would be added to a log, in order to track and put a limit on future such prompts sent to the same party.
In a preferred system said functions would act organically and semi-autonomously to selectively augment team populations, and re-incorporate and better incorporate players into competitions.
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 recruit manager system and various possible features of the system;

FIG. 2 is a flow chart of the steps involved in initiating an allocation;

FIG. 3 is a flow chart of the steps involved in setting up the system, at an administrative level.

FIG. 4 is a flow chart of the steps involved in creating an allocation rank list;

FIG. 5 is a flow chart of the steps associated with setting team status, particularly team recruiting status;

FIG. 6 is a flow chart of the steps associated with the allocation process;

FIG. 7 is a flow chart of the steps associated with prompting dropout and underemployed players;

FIG. 8 is a flow chart of the steps associated with re-initiating and accepting an allocation request, after it has been preliminarily rejected;

FIG. 9 is a screen dump of the administrative interface;

FIG. 10 is a screen dump of the team interface for setting team recruiting status, and viewing and re-initiating rejected allocation requests;

FIG. 11 is a screen dump of recruit interface for initiating allocations;

FIG. 12 is a screen dump of the processing page displayed when an allocation is submitted and initiated;

FIG. 13 is a screen dump of the confirmation page displayed after the allocation process is complete, and has been successful;

Referring to FIG. 1. the recruiting and allocation system 10 uses a communication system 120, such as the internet and/or telecommunications service, to facilitate the allocation of initiators 19 to sporting teams 1202, particular in ways which complement grade 1201 character (i.e. to ‘balance’ grades), and functions to identify and prompt individuals, particularly dropout players 193 and underemployed players 194, to be re-involved or more involved in the league.
More specifically system 10 can provide;
Functions to automatically allocate initiators 19 to teams 1202, by accepting allocation requests at S65, constructing ranked lists of the most suitable teams at S66, communicating with said teams at S672 or S671, and once a willing team is found, allocating said player to said team at S611 or S614, and sending relevant notifications S6102 or S6132 to relevant parties;
Functions to automatically identify ‘dropout’ players from league data stored on database 16, and construct lists of said identified dropouts at S73, using said lists to send email or SMS allocation prompts at S74 to said dropout players. If a positive response is received at S75, the response might initiate an allocation as though said individual used a recruit interface;
Functions to automatically identify ‘underemployed’ players from league data stored on database 16, in a manner similar to that described for dropout players.
Allocation requests might be made by new players 191, existing players 192 looking for a new team, dropout players 193 looking to be reinvolved in a competition, or underemployed players 194 looking to play on a more regular basis. The requests can be made through recruiting interface 12 which might take the form of FIG. 11. The recruit interface allows an individual seeking entry into a sporting competition, or the like, to enter personal preferences at S21, including the individuals name S215, age S211, gender S212, mobile phone number S213 and email S214, and optionally enter recruit preferences at S22, including the preferred season S221 (e.g. men's, women's, mixed etc) and grade S222 within which the individual would like a team found, and any preferred teams S223. Other options, depicted variously in FIG. 11, include only contacting preferred teams S2231, and choosing whether or not the process requires an additional confirmation S2241, at S682 for example, prior to being allocated a team. All data apart from S21 personal details is optional to initiate an allocation. Once the personal details and preference have been finalized the allocation can be initiated by submitting the page for processing at S225, by clicking on the ‘submit’ button depicted in FIG. 11.
Once the allocation request of a particular individual is submitted at S225 the request moves through network 120 to server 16 where it is processed at S66 by bot algorithm 141. The processing stage generates allocation rank-list 142, a ranked list of potential recipient teams, from ‘most suitable’ to ‘least suitable’, for that particular player. The algorithm might process and operate on a range of variables, including;

- administrative filtering S413, i.e. whether the administrator has specified that only teams actively setting their status as ‘recruiting’ within team interface 13 are sent allocation requests;
- personal detail filtering S432, i.e. filtering teams inconsistent with the personal details of initiator 19, including age and gender;
- team population ranking S44, i.e. assigning ‘weights’ to particular teams based on their population, such that teams with lower populations are preferenced for allocations;
- team skill ranking S45, i.e. assigning ‘weights’ to particular teams based on their skill or performance, such that teams with lower performance records, as drawn by the bot from database 16, are preferenced for allocations;
- team recruiting status ranking S46, i.e. assigning ‘weights’ to teams based on whether or not they are set as ‘recruiting’.
- previous allocation requests S47, i.e. assigning ‘weights’ to particular teams based on previous allocation requests received, such that teams receiving fewer allocation requests, or no allocation requests, might be preferenced for allocations.
- combining said variables to produce a rank list at S48, such that missing variables, e.g. the absence of team skill or population data, can be compensated for, including by employing randomized ranking where necessary.

Team recruiting status is controllable within team interface 13 depicted in FIG. 10. If a team judges it is in need of, will be in need of, or would like additional team members, the team status can be set to ‘recruiting’ at S52. This involves choosing the number of recruits needed in S53, inserting any special message to recruits at S54, setting recruitment visibility at S55 (i.e. whether a teams recruiting status is made viewable on public league data structures) and submitting the request at S56. As specified with the description of the allocation rank process, this will have one of two effects, either preferencing the team when constructing an allocation rank list at S46, i.e. increasing the priority with which the team receives allocation requests, or unlocking the team to receive allocation requests at S413, such that administrators might filter allocation requests to non-recruiting teams at S312 to only be received by ‘recruiting teams’.
Recruiting team filtering is a discretionary selectable option within administrative interface 11 depicted in FIG. 8. It might be used to restrict allocations to recruiting teams only. Other options and preferences include fields to enable or disable allocations generally at S31. If selected, it might block the bot from making allocations altogether by hiding and blocking access to recruit interface 12. Other options include specifying the method by which allocations are made S311, e.g. whether allocation requests are sent via email or SMS, at S67, or setting upper limits on allocation requests sent to non-recruiting teams, depicted variously in FIG. 8.
The allocation rank-list 142 acts as a contact list for sending allocation requests to teams, i.e. asking said teams to receive said initiator. Messages might take the form of either emails or SMS's, as determined by the administrator at S311, and might be sent sequentially in order of position within rank-list 142 at S672, particularly for SMS's, or spammed to several of the top ranked teams at S671, particularly for emails. SMS's are sent through SMSC server 18 through channel 181, while emails can be sent directly by the bot from network 120.
If SMS messages are used to send allocation requests at S672, teams can respond through replying to the message, e.g. replying ‘yes’, ‘no’ etc, which is received by the bot through channel 182. The reply might be affirmative (accepting the join request), negative (declining the join request), or ignored (nor responding to the allocation request). The response of the team will determine what action the bot will take, such that a positive response will cue the bot to request final confirmation from the initiator at S682, if specified in the recruit interface, or send notification to the initiator at S6102 that the allocation has been found and made, when-after the database is updated to reflect the allocation at S611. A negative response, on the other hand, or no response at S68 within a reasonable time-out limit, will add the team to the approached log 164 at S681, and will cue the bot to ask the next team on allocation rank-list 142 at S69. If or when rank-list 142 is exhausted, and an allocation has not been made, the bot will inform the initiator that no match is possible, through an appropriate message, at S615. Initiators informed as such might be added to a centralized register of players awaiting teams, a ‘player pending list’ 162 at S616.
If emails are used to send allocation requests at S671, teams can respond by clicking on an appropriate hyperlink, which is received by the bot through network 120. The steps and processes flowing from email based replies to allocation requests is the same as that for SMS based replies, barring if multiple allocations are sent simultaneously, a first come first serve principle applies, such that the first team to respond positively to the email based allocation request receives said player, while the remaining teams that received allocation requests are issued relevant notifications. Again, if no such affirmation of an allocation request is forthcoming, an appropriate message is sent at S615 to inform the initiator that no allocation is possible at this time, while the initiator is added to player pending list 162 at S616.
It is possible for a team to accept an allocation, although and after it has F been initially rejected or allowed to timeout. All allocation requests are stored and viewable as logs within team interface 13 depicted under logs in FIG. 10, such that teams might view when and if an allocation request was received, and the teams response. At S83 software within the team interface determines whether an initiator listed in the log was ultimately allocated a team, i.e. did the initiator end up in player pending list 162. If not, a re-initiate field is provided next to said log, enabling the team to re-continue and accept the allocation at S832. If the initiator is not in the player pending list, the re-initiate field is hidden S831. Allocations re-initiated using this method are parsed to S682, for using SMS based allocation requests, or S6121, for using email based allocation requests.
As well as passively receiving and processing allocation requests from the initiator, through a recruit interface or the like, the bot can also act autonomously to prompt individuals to act as initiators. Individuals that receive prompts fall into two categories, dropouts or underemployed players.
Prompts sent to dropout players are setup and controllable within administrative interface 11, such that particular fields might enable the prompting of dropout players to be enabled or disabled generally at S32, that the method by which dropout prompts are sent be specified at S321, including whether interactive SMS's or emails are used as prompts, that upper limits on dropout prompts be set at S323 (e.g. the maximum number of prompts sent to a particular dropout), that dropouts be defined at S322 (i.e. the time range since leaving a league a player is regarded as a ‘dropout’, e.g. 0-12 months etc) that particular groups within the dropout population be targeted at S334 (e.g. groups from seniors only, groups from A grade only, all groups except juniors etc), as depicted variously in FIG. 9.
The same fields and sub-fields might be available to systems targeting underemployed players, such that particular fields might enable or disable the prompting of underemployed players at S33, set limits on the number of prompts said to such parties at S333, set the method by which underemployed players are prompted at S331, define the participation range within which a player might be defined as underemployed at S332 (e.g. target players participating in between 10% and 40% of games), and set the groups within which underemployed players might be targeted at S334 (e.g. target underemployed players in A grade only etc).
Once discrete settings for dropout and underemployed players are established, the bot might prompt said parties, according to administration settings, using an SMS sent through outgoing channel 181 through SMSC 18, at S74. The SMS prompt sent at S741 to parties identified as dropout players might take the form of “League Bot: the system has detected you did not reregister for the current season, reply ‘yes’ if you would like to reregister in league X this season, by doing so you will automatically be allocated a team”.
Under this system a positive reply to said message at S75, indicating the dropout player would like to play in the current season, would be received through gateway 182, and trigger the allocation process beginning at S65 and continue as previously described. A ‘negative’ answer, or no answer for specified duration, at S75, will mark the player as ‘approached’ in approached log 164 in database 16 at S751.
The dropout player might also be prompted with an email at S742, such that instead of replying a keyword, said dropout might click a hyperlink or the like at S582.
Similar systems might apply to underemployed players such that said parties are sent prompts at S74, which might be SMS S741 or email S742 based, which might be replied to in an appropriate method, such that a positive reply to said message at S75, indicating the underemployed player would like to play on a weekly basis, would start-up the allocation process beginning at S65 and continuing as previously described. A ‘negative’ answer at S751, or no response within a designated timeout period, will mark the underemployed player as ‘approached’ in log 164.
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 performing allocations, a singular system prompting dropout players and/or a singular system for prompting underemployed players, in any of the variations 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 recruit and allocation management system for a sports league implemented over an electronic communications network, including:

a league ‘bot’, a semi-autonomous program that manages the player allocation process, including performing strategic individual/team allocations, and identifying parties that might serve as recruits/‘new’ players;

an administrative interface, for league administrators to set bot preferences;

a team interface, for teams to interact with the bot, including setting team recruiting status, and viewing logs of allocation requests;

a recruit interface, for recruits/individuals to interact with the bot, including cueing making a particular or general allocation request; and

a database containing league data, bot lists, administrator preferences, team preferences, recruit details etc.

2. The system of claim 1, wherein allocation initiators and prospective teams are contacted by electronic messaging.

3. The system of claim 1, wherein allocation initiators and prospective teams are contacted by email.

4. The system of claim 1, wherein allocation initiators and prospective teams are contacted through a telecommunications messaging service, selected from one of SMS, EMS or MMS messaging.

5. The system of claim 1, wherein allocation initiators and prospective teams are contacted through a web interface, e.g. through posting a message to a private web-page.

6. The system of claim 1, wherein a plurality of prospective teams are contacted at the same time.

7. The system of claim 6, wherein the team to respond positively first is assigned the allocation.

8. The system of claim 6, wherein once a team accepts an initiators allocation request, other alerted teams are notified that there is no longer a player seeking a team.

9. The system of claim 1, wherein prospective teams are contacted sequentially.

10. The system of claim 1, wherein an allocation request made to a prospective team includes response data or links for responding to said alert.

11. The system of claim 1, wherein once an allocation is made, the initiator and accepting team are notified of the match.

12. The system of claim 1, wherein said recruit interface allows an initiator to specify preferences including preferred season, grade, or teams to join.

13. The system of claim 1, wherein said team interface allows teams to flag themselves as ‘recruiting’.

14. The system of claim 1, wherein said allocation request is submitted to a prospective team via a telecommunications network.

15. The system of claim 1, wherein said allocation request is submitted to a prospective team via an SMS message.

16. The system of claim 1, wherein said allocation request is submitted to a prospective team via an email.

17. The system of claim 1, wherein said allocation request is submitted to a prospective team via a log in an interface, e.g. a log in a private team interface.

18. The system of claim 1, wherein said system can identify ‘dropout’ players.

19. The system of claim 1, wherein said system can identify ‘underemployed’ players.

20. The system of claim 1, wherein said system can identify ‘dropout’ players and ‘underemployed’ players, and wherein dropout and underemployed players are contacted by electronic messaging.

21. The system of claim 20 wherein dropout and underemployed players are contacted by email.

22. The system of claim 21, wherein dropout and underemployed players are contacted through a telecommunications messaging service selected from one of SMS, EMS or MMS messaging.

23. The system of claim 20, wherein said positive responses to said contacts, by dropouts or underemployed players, are used procedurally in place of an initiation made through the recruit interface.

24. The system of claim 1, wherein play history data, personal and preferential, associated with a dropout or underemployed player is used in place of manually entered data in the recruit interface.

25. The system of claim 1, wherein said recruit interface allows a player to view lists of recruiting teams.

26. The system of claim 1, wherein said recruit interface allows said system to save or store interest in joining a team, e.g. to a player pending list.

27. The system of claim 1, wherein said system includes a website in which allocation requests and player requests might be submitted by players and teams respectively.

28. A method for automating the allocation of an individual to a sporting team using an electronic communications network, including the steps of;

providing a recruit interface for an individual to register for the allocation service;

providing a team interface for a team to register as ‘recruiting’;

creating a list of ‘suitable’ teams for the initiator, sending allocation requests to said teams, and awaiting a positive reply, which if forthcoming might prompt notifications to relevant parties and the initiator to be added to the relevant team list.

29. The system of claim 28, wherein player to team matching is performed through analysing age/gender, and/or team skill, and/or team population, and/or team recruiting status, and/or previous similar contacts made to teams.

30. A method for prompting parties, particularly dropout and underemployed parties, to use an allocation engine, or express an interest in rejoining or changing teams in a league, including the steps of;

providing an administrative interface to setup prompting systems;

sending prompts in the form of messages to said parties, with reply mechanisms; and

receiving responses and either storing said responses, or using said responses to initiate an allocation or equivalent process.

31. A recruit and allocation management system for a sports league implemented over an electronic communications network, including:

any one or more of the following interfaces:

(a) an administrative interface, for league administrators to set bot preferences;

(b) a team interface, for teams to interact with the bot, including setting team recruiting status, and viewing logs of allocation requests;

(c) a recruit interface, for recruits/individuals to interact with the bot, including cueing making a particular or general allocation request; and a database containing league data, bat lists, administrator preferences, team preferences, recruit details etc.