JP6444011B1 - Horse riding matching support system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system useful for reducing the labor of a trainer at the time of a request for riding on a horse while further increasing the riding opportunity for both the trainer and the jockey and obtaining the riding opportunity more evenly. A trainer operates a trainer terminal 3 to access a support server 1 and inputs jockey information indicating that a jockey to ride on a specific race is requested, and is stored in a storage unit 2. To the jockey information file 22. The jockey visits the support server 1 by operating the jockey terminal 4, and the jockey visit schedule stored in the storage unit 2 is the jockey visit schedule information that is scheduled to visit a specific racetrack on a specific date. Record in the schedule information file 27. The jockey visit schedule information can be viewed on the trainer terminal, and the jockey information can be viewed on the jockey terminal. [Selection] Figure 1

Description

  The invention of this application relates to a horse riding matching in a horse race, that is, a system that supports matching between a jockey and a racehorse.

  Regardless of whether it is a central horse race or a local horse race, horses that run in the race (race horses) are managed and trained by the trainer at the request of the owner. The racer decides which race to start by looking at the condition of the horse and the level of the race. On the other hand, the jockey may be independent of the stable or may belong to one of the stables. In any case, the jockey receives the request from the trainer and receives a reward. Remuneration for jockeys is often determined according to the order of arrival.

http://www.jra.go.jp/kouza/yougo/c10120.html

In most cases, a ride request to a jockey is made by an analog method such as oral or telephone. In addition to riding in races, jockeys sometimes ride on racehorses for training purposes (training riding) and often visit stables for training riding. At this time, the trainer often requests a ride.
However, it is very troublesome to request a ride for each of the many racehorses belonging to the stable. A single stable usually has about 30 to 70 racehorses. In addition to daily training work, each racehorse must be asked to start a race after having decided on a race. There are training assistants and general servants working in the stables to assist the trainer, but it is still not easy to find the best jockey after identifying the race on which each racehorse should run.

  In order to increase the probability of winning the race as much as possible, it is indispensable to ask a good jockey for a ride, but the better the jockey, the more the ride request will be flooded, so the intended rider can ride Often not. For this reason, with a certain degree of compromise, we will request a rider from a jockey who can win even a little. Although it is necessary to increase the number of wins as a whole in order to improve the evaluation of the stable, it is very troublesome for the trainer to make a detailed request for riding on all the racehorses to which he belongs. It has become work.

On the other hand, for jockeys, the number of wins is directly linked to the evaluation of jockeys, so I would like to ride a horse with a high probability of winning. However, if you are only aiming for a horse with a high ability, you can easily miss the chance of riding. If you don't ride, you have no chance of winning and you cannot gain experience.
For this reason, there have been intermediaries that have been engaged in mediating horse riding requests from jockeys. The intermediary asks the trainer about the schedule of a specific racehorse for a specific race, searches for a jockey, and requests a ride. The intermediary has a considerable number of jockeys and connections, and he selects his jockey and listens to his intentions while considering the characteristics of the racehorse and the level of the race. If the rider agrees, the rider will be reserved. Intermediaries are often paid a commission according to the order of riders.

The use of such intermediaries has become quite widespread. Since the intermediary's activities reduce the effort of the trainer, this is a favorable situation. However, since the opportunity for riding depends on the connection with the intermediary, there is an unsatisfactory aspect in this respect. The trainer wants to find an optimal jockey from a wide variety of jockeys, but the mediator tries to select from the jockeys with connections, so the range of selection is limited. For the jockey, if the intermediary with whom he / she is connected does not receive a request from the trainer, he / she cannot ride on the horse of the trainer ’s stable and the selection range is limited. This problem is serious for young jockeys with little experience, and because there are few connections with intermediaries, there are situations where even if there are abilities, there are not enough opportunities for riding.
The invention of this application was made in view of the situation of the above-described riding request performed by the trainer to the jockey, and while reducing the time and effort of the trainer when requesting the riding, the trainer and the jockey The aim is to provide a system that will help both sides have more opportunities for riding and more equitable opportunities for riding.

In order to solve the above-mentioned problem, the invention according to claim 1 of the present application includes both a trainer terminal that is a terminal operated by a trainer of a horse racer and a jockey terminal that is a terminal operated by a jockey of a horse race. A horse riding matching support system including a server accessible from a storage unit and a storage unit,
In the storage unit,
A racehorse information file that records information about the racehorse that the trainer is training,
A program information file that records the schedule information of the race including the date and racetrack,
A jockey information file, which is information indicating that a jockey to ride in a specific race is requested,
A jockey visit schedule information file that records the date of the race and at least one race and the name of the jockey scheduled to visit the racetrack,
Jockey information registration means for inputting jockey information at the trainer terminal and recording it in the jockey information file;
Jockey information browsing means for transmitting and browsing jockey information stored in the jockey information file to the jockey terminal;
Jockey attendance schedule information registration means for inputting jockey visit schedule information that is scheduled to visit a specific racetrack on a specific date on a jockey terminal and recording it in a jockey visit schedule information file;
A jockey visit schedule information browsing means for transmitting the jockey visit schedule information recorded in the jockey visit schedule information file to the trainer terminal for viewing.
The jockey information browsing means is a means for browsing jockey information without browsing the name of the requested jockey,
The jockey visit schedule information sent to the trainer terminal for viewing includes the name of the jockey,
The server has a configuration in which a program that causes the server to function as jockey information registration means, jockey information browsing means, jockey arrival schedule information registration means, and jockey arrival schedule browsing means is installed.
In order to solve the above-mentioned problem, the invention according to claim 2 is the configuration according to claim 1, wherein the jockey arrival schedule information browsing means is uncertain about the riding schedule of the jockey on the racetrack on the date of the event. It has a configuration in which the jockey visit schedule information is browsed in a state.
In order to solve the above problem, the invention according to claim 3 is the configuration according to claim 1 or 2, wherein the jockey information recorded in the jockey information file is information on a racehorse that the rider wants to ride. In addition, the jockey information browsing means has a configuration in which information on racehorses is also browsed.
In order to solve the above-mentioned problem, the invention according to claim 4 has a configuration in which the information on the racehorse includes past results in the configuration of claim 3.
In order to solve the above-mentioned problem, the invention according to claim 5 is the configuration according to any one of claims 1 to 4, wherein the jockey information browsing means is configured such that the jockey visit schedule information registration means is the jockey visit schedule information. Is input to the jockey terminal for information regarding whether or not the jockey information is registered for the race held on the racetrack on the date of the event.
In order to solve the above-mentioned problem, the invention according to claim 6 is the configuration of claim 5, wherein the information on whether or not the jockey information is registered is based on the racehorse scheduled to start seeking the jockey. The information is displayed in the number of heads.

As described below, according to the invention described in claim 1 of this application, the trainer informs each jockey that he / she is looking for a jockey for a specific race, and the jockey has a specific event. It is reported that a specific racetrack will be visited every day, and by disclosing such information, the trainer can select a jockey and the jockey can select a racehorse to ride. For this reason, it is horse riding matching support that is optimal for the trainer and jockey.
Further, according to the invention described in claim 2, in addition to the above effect, the jockey visit schedule information is browsed in a state in which the jockey's riding schedule is unknown, so that it becomes a preferable system for obtaining a better riding opportunity for the jockey. .
According to the invention described in claim 3, in addition to the above effect, the jockey information includes information on the racehorse that the horse wants to ride, and the jockey can view this information. You can choose a horse with a chance to win and apply for a ride.
Further, according to the invention described in claim 4, in addition to the above-mentioned effect, since the past battle record is included as the racehorse information, it is possible to determine how much the player is likely to win when riding the horse. It is easy and more suitable.
According to the fifth aspect of the invention, in addition to the above effect, the trainer makes it easier for the jockey to register the attendance schedule by disclosing the jockey information, and the trainer can register the attendance schedule. A synergistic effect that makes it easier to request a ride from a jockey is demonstrated.
According to the invention described in claim 6, in addition to the above effect, the jockey information is transmitted in the form of the number of racehorses seeking jockeys, so if the jockey goes to the racetrack on that day, the chance of riding It is possible to grasp how much the possibility of being obtained is obtained, which is further preferable in this respect.

It is a schematic diagram of a horse riding equivalency matching support system of an embodiment. It is the schematic which showed an example of the structure of a trainer information file. It is the schematic which showed an example of the structure of a jockey information file. It is the schematic which showed an example of the structure of a racehorse information file. It is the schematic which showed an example of the structure of a program information file. It is the schematic which showed an example of the structure of a holding information file. It is the schematic which showed an example of the structure of a start schedule information file. It is the schematic which showed an example of the structure of a jockey visit schedule information file. It is the schematic of the login page displayed on a trainer terminal and a jockey terminal by a login program. It is the schematic which showed an example of the horse list page. It is the schematic of a horse input item selection page. FIG. 12 is a schematic diagram showing an example of a program page. It is the schematic which showed an example of the starting schedule page. It is the schematic which showed an example of the structure of a jockey information file. It is the schematic which showed an example of the structure of a visit schedule information file. It is the schematic which showed an example of the structure of a riding plan information file. It is the schematic which showed an example of the jockey top. It is a schematic diagram of a schedule input selection page. It is the schematic which showed an example of the jockey program display page. It is the flowchart which showed the outline of the program display program for jockeys. It is the schematic which showed an example of the jockey detail page displayed on a jockey terminal by a jockey information detailed display program. It is the schematic which showed an example of the structure of a visit schedule master file. It is the schematic which showed an example in the state where the horse name input page was displayed. It is the schematic which shows an example of the visit plan browsing page which is an execution result of a visit plan browsing program.

Next, modes (embodiments) for carrying out the invention of this application will be described.
The horse riding / sitting matching support system described below is a system that assists the trainer to select a jockey or, conversely, to select a racehorse on which a jockey rides. In the following description, a race at a central horse race will be described. However, the system of the embodiment can be used for riding matching support at each local horse race.

  FIG. 1 is a schematic diagram of a horse racing riding matching support system according to an embodiment. The horse racing riding matching support system of the embodiment includes a server (hereinafter referred to as a support server) 1 and a storage unit 2. The support server 1 is accessible from both a trainer terminal 3 that is a terminal managed by a horse racer and a jockey terminal 4 that is a terminal managed by a horse jockey. In this embodiment, the server is a server on the Internet 5 and is therefore a web server.

The storage unit 2 is a storage such as a hard disk provided in the support server 1. In addition, another server (storage server) including a storage unit may be used as the storage unit 2.
The support server 1 provides a riding matching support site (hereinafter referred to as a support site). Therefore, the storage unit 2 stores an HTML file (not shown) of each page of the support site.
The support site is a membership system for both trainers and jockeys, and is a site that is registered and used. Therefore, the storage unit 2 stores a trainer information file 21 and a jockey information file 22 as user information files.

FIG. 2 is a schematic diagram showing an example of the structure of the trainer information file 21. As shown in FIG. 2, the trainer information file 21 is a database file in which a number of records including fields such as “trainer ID”, “password”, “trainer name”, and “location” are recorded for each trainer. is there. “Location” is a field in which the location of the stable to which the trainer belongs is recorded.
FIG. 3 is a schematic diagram showing an example of the structure of the jockey information file 22. As shown in FIG. 3, the trainer information file 21 is a database file in which a large number of records composed of fields such as “jockey ID”, “password”, and “jockey name” are recorded for each trainer. “Jockey ID” is a field in which a member ID as a jockey is recorded. In addition, the jockey information file 22 may also record data such as age, gender, and total number of wins.

  In addition, the storage unit 2 stores a racehorse information file 23 in which information on racehorses trained by each trainer is recorded. FIG. 4 is a schematic diagram showing an example of the structure of each racehorse information file 23. As shown in FIG. 4, the racehorse information file 23 includes “trainer ID”, “racehorse ID”, “horse name”, “classification”, “female sen”, “running right”, “right” This is a database file in which records composed of fields such as “time limit”, “previous run”, “next run schedule”, etc. are recorded for each racehorse.

  The “trainer ID” is a field for recording a member ID as a trainer, and records the trainer ID of the trainer who trains the racehorse. The “classification” field is a field in which a classification of a racehorse according to a race condition described later is recorded. For example, information of “2-year-old new horse” and “2-year-old unwinned” is recorded in text. The “female sen” is a field in which a mare or a stallion is recorded. ▲ Sen ▼ A horse is a castrated horse. The field “Right to start” is a field for recording information indicating that the player has been excluded after a vote for starting. If excluded, this information is recorded because the right to run preferentially for the next race is granted. A time limit is set for the right to start, and this information is recorded in the “right limit” field. In addition, fields related to the number of wins and pedigree (parent name, etc.) may be provided. The “previous run” is a field in which the arrival order in the latest run race or the time of the most recent run race (weeks before) is recorded. “Scheduled for next run” is a field in which the race ID of the race is recorded when the next race is determined.

Further, a program information file 24 is stored in the storage unit 2. FIG. 5 is a schematic diagram showing an example of the structure of the program information file 24.
As shown in FIG. 5, the program information file 24 includes fields such as “race ID”, “date of holding”, “holding racetrack”, “race number”, “race name”, “condition”, “grade”, and the like. It is a database file that records records for each race. The “race number” is a field in which the number from the first race of the day is recorded. The “race name” is a field in which the name is recorded in the case of a race with a name such as “Japan Derby”. “Condition” is a field in which start conditions such as only a mare can start (a mare battle) or only an unwinned horse can start (an unwin battle) are entered. “Grade” is a field in which the grade of the race is recorded, such as G1, G2, and G3.

  The system of the embodiment is operated by a company that operates a support site (hereinafter referred to as a support company). As shown in FIG. 1, a management terminal 6 is provided in the office of the support provider. The management terminal 6 is given a special access authority to the support server 1 and the storage unit 2, and each piece of information is input and transmitted from the management terminal 6 and recorded in each file.

Further, the storage unit 2 stores a date information file 25, a start schedule information file 26, and a jockey visit schedule information file 27. 6 is a schematic diagram showing an example of the structure of the date information file 25, FIG. 7 is a schematic diagram showing an example of the structure of the start schedule information file 26, and FIG. 8 is an example of the structure of the jockey visit schedule information file 27. It is the shown schematic.
As shown in FIG. 6, the date information file 25 is a database file in which a large number of records including fields of “date ID”, “date”, and “horse racetrack” are recorded. Each record of the holding information file is created for each holding date and each holding racetrack.

  The start schedule information file 26 is a database file created for each trainer, and can be specified by using a file name using the trainer ID. As shown in FIG. 7, the start schedule information file 26 includes fields such as “start ID”, “racing horse ID”, “race ID”, “schedule of jockey”, “name of jockey”, and the like. The start schedule information file 26 is a file in which information is recorded when a specific race is scheduled for a racehorse managed by one trainer. However, the start schedule in this case is a record of the start schedule on the support server 1 to the last, and is different from what is called a start vote for the race organizer (JRA if it is a central horse race).

Further, as shown in FIG. 8, the jockey visit schedule information file 27 includes fields of “Jockey ID”, “Jockey name”, and “Level”. The jockey visit schedule information file 27 is a database file that records a schedule of a specific jockey coming to a specific racetrack on a specific date. Therefore, in this embodiment, the jockey visit schedule information file 27 is created with a file name using the date ID, and can be specified by the date ID.
The information of the date information file 25 is recorded by being input and transmitted by the person in charge of support at the management terminal 6 in the same manner as other files. The information in the jockey arrival schedule information file 27 is recorded by being input and transmitted at the jockey terminal 4 as will be described later.

  The support system of the embodiment includes jockey registration means, jockey information browsing means, jockey visit schedule registration means, and jockey visit schedule information browsing means. Various programs installed in the support server 1 are programs that cause the support server 1 to function as these means. This will be specifically described below.

  In this embodiment, the support site is a site that is accessed using a mobile terminal such as a smartphone or a tablet PC. One of the HTML files stored in the storage unit 2 is for a login page, and a login program 11 is installed in the support server 1. FIG. 9 is a schematic diagram of a login page displayed on the trainer terminal 3 and the jockey terminal 4 by the login program.

  When both the trainer and jockey are registered as members, the member I and password are issued. When the member ID and password are correctly input on the login screen and the login button 70 is tapped or clicked (hereinafter collectively referred to as “pressed”), the login program 11 logs in the support server 1. . Note that different login pages are prepared for the trainer and the jockey, so that it can be determined whether the trainer has logged in or the jockey has logged in.

The support site is divided into a trainer page and a jockey page. First, the trainer page will be described.
When login is performed from the login page for the trainer, the trainer page can be displayed on the trainer terminal 3. In this embodiment, the default trainer page is a horse list page, and when a login is made from the trainer page, the horse list page is displayed first. That is, the login program 11 is programmed to execute, as a subroutine, a program for displaying a horse list page (hereinafter referred to as a horse list program) 12 when a login is performed on the trainer login page.

  FIG. 10 is a schematic diagram illustrating an example of a horse list page. The horse list page is a page that displays a list of information on racehorses managed and trained in the stables to which the trainer belongs. The horse list program 12 opens the racehorse information file 23 for the corresponding trainer with the member ID (trainer ID) input on the trainer login page, obtains information on each record, and is shown in FIG. Thus, it is programmed to be incorporated into the horse list page and transmitted to the trainer terminal 3 for display.

In this embodiment, the horse list page is displayed as a list for each classification. The horse list page is provided with a bar (classification bar) 71 indicating the classification. A pull-down button 72 is provided at the right end of the classification bar 71. When the pull-down button 72 is pressed, a list of racehorses of that classification is displayed. In the example of FIG. 10 (2), a state in which the pull-down button 72 of the 2-year-old new horse classification is pressed is shown.
When the pull-down button 72 is pressed in FIG. 10 (1), as shown in FIG. 10 (2), a heading line is displayed below the classification bar 71, and information on each racehorse is displayed below it. It has become. As shown in FIG. 10, in this embodiment, the horse name, the right to start, the right expiration date, and the next run schedule are displayed as racehorse information.

In the horse list page, the row where the name of each racehorse is displayed is a command button (hereinafter referred to as a horse selection button) 73, and when one of them is pressed, the race schedule for the racehorse is entered. It can be done. Specifically, each horse selection button 73 is linked to a horse input item selection page. FIG. 11 is a schematic diagram of a horse input item selection page.
As shown in FIG. 11, in this embodiment, a race selection button 74, a grazing button 75, and the like are provided. The race selection button 74 is a button for inputting a race for starting the racehorse. The grazing button 75 is a button for inputting that the racehorse is grazed, that is, rested. The button described as “Others” is a button for changing registration as a race horse specialized in disability, deleting registration, or registering toppling (change to stable).

The race selection button 74 is an activation button for the program program 13 for displaying a page for displaying a program, that is, a race schedule (hereinafter referred to as a program page). FIG. 12 is a schematic diagram showing an example of a program page.
As shown in FIG. 12, on the program page, a bar indicating information on the selected racehorse is displayed, and race information is displayed below the bar. In this embodiment, the race information is displayed as a list with the date of the event on the horizontal axis and the racetrack on the vertical axis. In the example of FIG. 12, the program program 13 is programmed so that the race schedule for four days is displayed at a time. The program page is equipped with a scroll function, and swiping the screen to the right will display the race schedule after that.

Since the program program 13 is executed with the racehorse ID as an argument, it is programmed to display only the races that the racehorse can run on the program page. Specifically, the program 13 searches the racehorse information file 23 by racehorse ID, acquires the value of the “classification” field and the value of the “female sen” field from the corresponding record, The program information file 24 is searched with these values, and the race information is acquired from the corresponding record and programmed to be incorporated into the program page.
In the program page, “turf” means a race on the lawn course, and “da” means a race on the dirt course. A number such as “12” means a distance of × 100 m. “(Mixed)” means a race where foreign horses can run, and “(Female)” means a race involving only mares.

In the program page, a rectangular area (hereinafter referred to as a race display cell) 76 in which each race is described is a command button. The race display cell 76 is an activation button of a program (hereinafter referred to as a start registration program) 14 for performing a record (hereinafter referred to as start registration) indicating that the racehorse is scheduled to start for the race in the support server 1. .
The start registration program 14 first displays a confirmation page (not shown). A registration button is provided on the confirmation page, and the racehorse ID and race ID are embedded in the registration button. When the registration button is pressed on the confirmation page, the start registration program 14 opens the trainer's start schedule information file 26 according to the ID (trainer ID) held at the time of login and adds a new record, It is programmed to generate a start ID and record it along with the racehorse ID and race ID.

The race schedule thus registered can be viewed at any time on the trainer terminal 3. Hereinafter, this point will be described.
When logging in on the trainer login page, the horse list page is displayed as described above. As shown in FIG. 8, the uppermost part of the horse list page has command buttons arranged in a horizontal row ( Hereinafter, it is referred to as an upper UI.) 77 is provided. The upper UI 77 has a common layout for each trainer page. In this embodiment, five command buttons are provided on the upper UI 77. The five command buttons are, in order from the left, a button labeled “horse list” (hereinafter “horse list button”) 771, a button labeled “program” (hereinafter “program button”) 772, and “planned to start”. Button (hereinafter referred to as a scheduled start button) 773, a button (hereinafter referred to as a scheduled rider button) 774, and a button (hereinafter referred to as a jockey training button) 774 described as “Jockey Training”. ing.

The run schedule button 773 is a run schedule browsing button that is transmitted by the trainer and registered on the support server 1. The support server 1 is equipped with a start schedule display program 15 for displaying a start schedule page, and the start schedule button 773 is an activation button for the start schedule display program 15. FIG. 13 is a schematic diagram showing an example of a scheduled race page.
As shown in FIG. 13, the starting schedule page is a page that displays the starting schedule according to the date of the event, by racetrack, and in order of the race. The run schedule display program 15 is programmed to open the run schedule information file 26 of the corresponding trainer with the trainer ID held at the time of login, and display the information of each record in order of the date of the race, by racetrack, and in the order of the race. Has been.

As shown in FIG. 13, the start schedule is displayed as a horizontal bar, and the race number, start condition (simplified display), horse name, and jockey name are displayed in the horizontal bar. . The run schedule display program 15 is programmed to indicate “undecided” when the field of “Jockey name” has a null value at the time of activation.
In addition, a pull-down button 78 is provided at the right end of each horizontal bar on the scheduled race page. This pull-down button 78 is a pull-down button for inputting a jockey name or inputting a jockey recruitment. Hereinafter, the pull-down button 78 is referred to as a jockey button. FIG. 13B shows an example of a state where the jockey button 78 is pressed.

  As shown in FIG. 13 (2), when the jockey button 78 is pressed, a button (hereinafter referred to as a search button) 781 labeled “search” is displayed at the top of the pull-down list. . The support server 1 is equipped with a jockey registration button, and the search button 781 is an activation button for a jockey registration program. The jockey registration program is a program that causes the support server 1 to function as jockey registration means.

  The storage unit 2 stores a jockey information file 22. FIG. 14 is a schematic diagram showing an example of the structure of the jockey information file 22. As shown in FIG. 14, the jockey information file 22 records a record including fields such as “Jockey ID”, “Trainer ID”, “Race ID”, “Race Horse ID”, “Jockey ID”, and the like. It is a database file. The jockey ID is an ID for identifying each record in the jockey information file 22 and is an ID assigned to each case of searching for a jockey.

The search button 781 shown in FIG. 13 (2) incorporates a race ID and a racehorse ID. In the search button 781, a code for executing the jockey registration program 16 with the trainer ID, the race ID, and the racehorse ID held at the time of login as arguments is embedded.
When started, the jockey registration program 16 generates a jockey ID and adds a new record to the jockey information file 22. The generated jockey ID, the passed trainer ID, the race ID, and the racehorse ID are programmed to be recorded in the corresponding fields of the new record. Note that the field of “Jockey ID” is left as a Null value.

  The pull-down list embedded in the jockey button 78 has a layout in which the search button 78 is positioned at the top, and the names of jockeys are listed below it. A jockey ID is embedded in each jockey name, and when one is selected, the jockey can be registered for the race. Registration is performed by recording the jockey ID in the start schedule information file 26 of FIG. When a jockey is registered, the name of the jockey is displayed in the display column (horizontal bar) of the scheduled jockey when the scheduled run page is displayed thereafter. In addition, it is preferable that the display of each jockey name in the professional down list is in the order of registration frequency (in descending order of the number of horse riding requests), and the name of the jockey infrequent is set to the Japanese alphabet.

Next, the configuration of the support system prepared for the jockey will be described.
First, the storage unit 2 stores a visit schedule information file 281 that records the visit schedule to each horseman's racetrack and a ride schedule information file 282 that records the ride schedule of each jockey.
FIG. 15 is a schematic diagram showing an example of the structure of the attendance schedule information file 281. The visit schedule information file 281 is created for each jockey, and is a database file that can be specified by using a file name using the jockey ID. As shown in FIG. 15, the attendance schedule information file 281 is a database file that records records including fields such as “date of event”, “racetrack ID”, “racetrack name”, “situation”, and the like. The “situation” field is a field in which any one of “confirmed”, “under consideration”, or blank (Null value) is input. “Confirmed” is a value meaning that the visit to the racetrack is confirmed, and “under consideration” is a value meaning that the visit is being considered (being lost).

  FIG. 16 is a schematic diagram showing an example of the structure of the riding plan information file 282. The riding schedule information file 282 is also created for each jockey and is a database file that can be specified by using a file name using the jockey ID. As shown in FIG. 16, the riding plan information file 282 is a file in which records including fields such as “race ID”, “horse name”, and “situation” are recorded. The “status” field is a field in which any one of “confirmed”, “inquiry”, or blank (Null value) is input. “Confirmed” is a value meaning that the riding schedule is confirmed, and “Inquiry” is a value meaning that the discussion with the trainer is in progress.

  On the other hand, a page for jockeys is prepared on the support site. As described above, when a member is registered as a jockey on the support site, a member ID (jockey ID) as a jockey is issued. The support server 1 is equipped with a jockey top display program for displaying a top page for jockeys (hereinafter, jockey top). When logging in by inputting a jockey ID and password on the login page for jockeys, the jockey top display program 171 is executed, and the jockey top is displayed on the jockey terminal 4. FIG. 17 is a schematic view showing an example of a jockey top.

  In this embodiment, the jockey top is a page that displays a list of racetracks where the race is held in order of date of the event. In this embodiment, a central horse race is targeted. In Central Horse Racing, the dates are mainly weekends and holidays, and there are a maximum of three racetracks where races are held on the same day. Therefore, the jockey top is provided with a three-square racetrack notation column (hereinafter referred to as a venue notation square) 79 next to the column indicating the date and day of the event. A jockey top display program 171 is programmed in each notation column so that the name of each racetrack where the race is held on the date of the event is indicated. In other words, the jockey top display program 171 is programmed to acquire race schedule information from the time point of login from the program information file 24, and to display it by incorporating it into each venue notation box.

  There is a venue notation box labeled “Tanabata Prize” or the like under the notation of the racetrack, which is also indicated when a heavy race is scheduled. The jockey top program determines if there is a heavy prize race from the value of the “grade” field if a race is scheduled on the date of the event, and if so, It is programmed to get the value and display it under the racetrack name. In addition, it is possible to display subsequent schedules by swiping down using the vertical scroll function.

Each venue notation box 79 is a command button. The command button here is a command button for inputting a schedule as to whether or not to go to the racetrack on the date of the event. Hereinafter, each venue notation cell 79 is referred to as a schedule input activation button.
Each schedule input activation button 79 is linked to a schedule input selection page. FIG. 18 is a schematic diagram of a schedule input selection page. As shown in FIG. 18, the schedule input selection page includes a race reference button 811, a visit confirmation button 812, a registration button 813 under consideration, and the like. The schedule input activation button 79 includes a code for displaying a race reference button 811, a visit confirmation button 812, and a registration button 813 under consideration in a state in which the displayed race date and the racetrack ID of the displayed racetrack are incorporated. Embedded.

On the other hand, a jockey program display program 172 is installed in the support server 1. A race reference button 811 shown in FIG. 18 is an activation button of the jockey program display program 172. The race reference button 811 is a button for executing the jockey program display program 172 with the date of the event and the racetrack ID as arguments.
The jockey program 13 is a program for displaying a jockey program display page on a jockey terminal. FIG. 19 is a schematic diagram showing an example of a jockey program display page. As shown in FIG. 19, on the jockey program page, the selected date and the name of the racetrack are displayed at the top, and the information of each scheduled race is displayed in the order of the race number below the horizontal bar. It has become. The displayed information includes a race number, race conditions, race name (if there is a name), and the like. If no race name is registered, the race conditions are displayed. In addition, when a horse to be ridden has already been determined and a jockey has entered and registered a horse name as will be described later, it is displayed with priority.

The jockey program display program 172 is programmed to search the program information file 24 by the date and the racetrack ID that have been passed, acquire all the corresponding records, and sort and display them in the order of the race numbers.
As shown in FIG. 19, at the right end of the horizontal bar displaying information on each scheduled race, a column (hereinafter referred to as a scheduled riding column) 82 showing a jockey scheduled to ride is provided. A characteristic point of the jockey program display program 172 is that it is programmed to access the riding schedule information file 282 and the jockey information file 22 and to display differently in the riding schedule column 82 according to the recorded contents. . Hereinafter, this point will be described with reference to FIG. FIG. 20 is a flowchart showing an outline of a jockey program display program.

  As shown in FIG. 20, the jockey program display program 172 also acquires a race ID when searching the program information file 24 by the date of the event and the racetrack ID and displaying the information of the corresponding record. Then, according to the jockey ID held at the time of login, the jockey's riding plan information file 282 is opened and searched by the race ID. If there is a corresponding record, the “status” field is acquired. If the “situation” field is not a null value, the value is incorporated into the riding plan column 82. In the case of the Null value, the jockey program display program 172 opens the jockey information file 22 and searches by the race ID. Then, the number of corresponding records is acquired, and the value is displayed in the riding plan column 82.

Accordingly, as shown in FIG. 19, when a number is displayed in each riding schedule column 82 of the jockey program display page, the number indicates the racehorse seeking the jockey (the jockey is not yet determined) in the race. It will be a number.
When the jockey program display program 172 displays numbers (the number of racehorses seeking jockeys in one race) in the riding plan column 82, the riding plan column 82 is a command button. The support server 1 is equipped with a jockey detailed information display program 173 for displaying detailed information of a racehorse seeking a jockey. FIG. 21 is a schematic diagram showing an example of a jockey detail page displayed on the jockey terminal 4 by the jockey information detail display program 173.

As shown in FIG. 21, the jockey information page shows the race of the jockey under the heading line that displays the date, racetrack (abbreviation), race number, start condition (abbreviation), and race condition (abbreviation). This page displays a list of horse information. In this example, the horse name, the trainer name, and the previous run information are displayed as racehorse information.
In the jockey information page, in the horizontal bar that displays information on each racehorse of the jockey, a notation such as “one” or “both looking at” may be displayed. This is indicated as “one” if the race has been confirmed for the day of the event, and “both looking at” when considering other races. . The jockey information file 22 is provided with a field for recording information on the possibility (accuracy) of such a run.

On the other hand, a visit confirmation registration program 174 and a registration program under consideration 175 are installed in the support server 1. The visit confirmation button 812 on the schedule input selection page shown in FIG. 17 is an activation button of the visit confirmation registration program 174, and the under-registration registration button 813 is an activation button of the under-registration registration program 175.
Each scheduled input activation button 79 is coded so as to embed the scheduled date and the racetrack ID in the visit confirmation button 812 and the under-registration registration button 813, respectively, when displaying the scheduled input selection page. The visit confirmation registration program 174 opens the visitor scheduled information file 281 according to the jockey ID held at the time of login. Then, the search is performed using the date and racetrack ID as arguments, and if there is no corresponding record, a new record is added, and the date and racetrack ID are recorded in the respective fields. In addition, a “determined” value is recorded in the “status” field. If there is a corresponding record, overwrite each field and record. The under-registration registration button 813 is programmed to operate similarly except that “under consideration” is recorded in the “status” field.

  Note that the jockey top display program 171 is programmed to display each schedule input activation button (scheduled schedule display cell) 79 differently depending on the situation of the scheduled visit when displaying the jockey top. Examples of the different display include making the background color of the buttons different. Specifically, when the jockey top program obtains the race schedule information from the program information file 24 and displays it, the jockey top program opens the jockey's visit schedule information file 281 according to the jockey ID, and the visit schedule information by the date and racetrack ID. The file 281 is searched. If there is a corresponding record and the “status” field is not a null value, the button property is changed so that the background color differs depending on the value. For example, if “confirmed”, the background color is blue, and if “under consideration”, it is yellow.

  On the other hand, the storage unit 2 stores a visit schedule master file 29 in which the visit schedule information of each jockey is recorded together. FIG. 22 is a schematic diagram showing an example of the structure of the attendance schedule master file 29. As shown in FIG. 22, the attendance schedule master file 29 is a database file in which records consisting of fields such as “date of holding”, “racetrack ID”, “hosted racetrack”, “jockey ID”, “situation” are recorded. It is.

  The above-described visit confirmation registration program 174 and the under-registration registration program 175 include a code for recording in the visit planned master file 29 as a subroutine. That is, the visit confirmation registration program 174 opens the attendance schedule master file 29 after recording in the jockey attendance schedule information file 27 for the jockey, and searches by the event date, the racetrack ID, and the jockey ID. If there is no corresponding record, a new record is added and the date of the race, the racetrack ID, and the jockey ID are recorded. “Confirmed” is recorded in the “status” field. If there is a corresponding record, overwrite each field and record. The under-registration registration program 175 is the same except that “under consideration” is recorded in the “status” field.

  The jockey program page shown in FIG. 19 also has a function of displaying the name of the trainer when a horse name is input. Specifically, the left portion (the portion other than the riding plan column 82) 83 of the horizontal bar displaying the information of each race is another command button. This command button is a button for inputting a horse name. Hereinafter, this command button is referred to as a horse name input button.

A horse name input page is linked to the horse name input button. FIG. 23 is a schematic diagram illustrating an example of a state in which a horse name input page is displayed.
The horse name input page is a page that displays a horse name input text box 84. When the text box 84 is selected, a text input screen is displayed by the function of the jockey terminal 4, and a program for registering a trainer is executed. This program is a program that searches the racehorse information file, acquires the trainer name of the racehorse, and displays it on the jockey terminal 4. In addition, it may be programmed to register the name of the racehorse scheduled to be mounted in the mount schedule information file 282. In this case, when a horse name is input, it is programmed to record “determined” in the “situation” field of the riding plan information file 282 for the jockey.

  On the other hand, the visit server browsing program 18 is installed in the support server 1 as a program for providing a service for trainers. The visit schedule browsing program 18 is a program for causing the support server 1 to function as a jockey visit schedule browsing means. FIG. 24 is a schematic diagram illustrating an example of a visit schedule browsing page that is an execution result of the attendance schedule browsing program 18.

Specifically, as described above, the upper UI 77 of each page for trainers includes a visiting schedule button 774. The visit schedule button 774 is an activation button for the visit schedule browsing program 18. When the program to be visited is started, the program information file 24 is first searched, and the date, racetrack ID, and racetrack name in the latest schedule (section) are acquired. Then, the attendance schedule master file 29 is opened and searched by the date of the event and the racetrack ID. Then, jockey IDs are acquired for all the records in which the “situation” field does not have a null value. Then, the attendance plan browsing program 18 is programmed so as to be classified according to the value of the “situation” field and displayed as a list in the visit plan browsing page shown in FIG.
In the example of FIG. 24, the attendance schedule of each jockey at the Chukyo Racetrack is shown. When a square displaying the name of another racetrack provided in the upper row is pressed, the racetrack The attendance schedule for each jockey on the date of the most recent section is displayed.

The operation of the support system of the embodiment having such a configuration will be described below.
The support provider publicizes the support site to each trainer and each jockey and calls for use. In response, each trainer and each jockey register each as a jockey as a trainer. As a result, an ID (trainer ID) and password are issued to each trainer, and an ID (jockey ID) and password are issued to each jockey.

  On the other hand, the person in charge of the support company operates the management terminal 6 and records necessary information on the trainer information file 21, the jockey information file 22, the program information file 24, the date information file 25, and the like. As for the trainer information file 21 and the jockey information file 22, the person in charge may input information provided by each trainer and each jockey by mail or the like, or an input page is provided on the support site. In some cases, each trainer and each jockey input. The program information file 24 and the date information file 25 are used when the person in charge inputs the data on the management terminal 6 one by one, or receives data from the organizer (JRA) with permission for commercial use. In some cases.

  The trainer accesses the support site through the trainer terminal 3 and inputs the trainer ID and password to log in. As a result, the horse list page of FIG. 10 is displayed on the trainer terminal 3. The trainer selects any racehorse while confirming the training status of each racehorse. That is, the classification bar 71 is pressed to display a horse list, and an arbitrary horse selection button 73 is pressed. As a result, the horse input item selection page of FIG. 11 is displayed.

  When the trainer determines that the racehorse should start racing, he presses the race selection button 74. Thereby, the program page of FIG. 12 is displayed. The trainer pushes the race display mass 76 if there is a race that he / she thinks while looking at the race schedule at each racetrack that will be held soon. As a result, a confirmation page (not shown) is displayed, and the registration schedule is registered by pressing the registration button.

  Thereafter, the trainer presses the start schedule button 773 of the upper UI 77 to display the start schedule page on the trainer terminal 3. The jockey button 78 is pressed with respect to those displayed in the notation field of the jockey at the right end of the displayed racehorse (horizontal bar) of each racehorse displayed. As a result, a pull-down menu is displayed, and a search button 781 in the bull-down list is pressed. As a result, the jockey registration program 16 is activated, and a new record is added and recorded in the jockey information file 22.

  On the other hand, the jockey accesses the support site by the jockey terminal 4 and inputs the jockey ID and the password to log in. Thereby, the jockey top shown in FIG. 17 is displayed. The jockey checks the background color of each schedule input start button 79 (scheduled schedule display cell), and confirms the date on which the racetrack is not determined or the date under consideration. Then, an arbitrary schedule input activation button 79 (a scheduled schedule display cell displaying an arbitrary racetrack name) 79 is pressed on these dates. Thereby, the schedule input selection page of FIG. 18 is displayed. If it is decided to go to the racetrack at this time, the visit confirmation button 812 is pushed. As a result, the fact is recorded in the attendance schedule information file 281 for the jockey and also in the attendance schedule master file 29.

If the arrival has not been decided yet, the jockey presses the race reference button 811 on the schedule input selection page of FIG. Accordingly, the jockey program page of FIG. 19 is displayed on the jockey terminal 4.
The jockey checks the display column (horizontal bar) of the information of each race displayed on the jockey program page, and confirms the riding plan column 82 at the right end. When a value of 1 or more is written in the riding plan column 82, there is one or more trainers seeking jockeys in the race. At this time, the jockeys enter the racetrack on the date of the event. Consider whether to go. If it is decided to go, the player returns to the jockey top and presses the scheduled event display cell (schedule input activation button 79) displaying the date of the event to register the scheduled event. As a result, the fact that the user goes to the racetrack on the date of the event is recorded in the attendance schedule information file 281 for the jockey and also in the attendance schedule master file 29. When considering, the registration button 813 under consideration is pushed and recorded in each file in the same manner.

If it is determined that the determination cannot be made without looking at the details of the horse as the jockey, the jockey presses the riding plan column 82 at the left end of the horizontal bar displaying the information of the race. Thereby, the jockey detail page of FIG. 21 is displayed on the jockey terminal 4. The jockey looks at the detailed information on the displayed racehorse and decides that if there is a horse that he or she believes, he decides to go to the racetrack on the day of the event and displays either side of the racehorse information displayed. Press the bar to display the schedule input selection page to register the visit confirmation, and register the under consideration if it is under consideration. When a rider is contacted and a ride is decided, the jockey inputs the name of the racehorse on the horse name input page and registers it.
When a jockey registers a visit confirmation or a study underway in this way, the information is recorded in the visit schedule master file 29, so that the information is immediately reflected on the visit schedule view page viewed by the trainer. The Therefore, the trainer can confirm in real time that a specific jockey has made a decision to visit a specific racetrack on a specific date or is under consideration.

  In this way, information is provided from each trainer side and each jockey side, and after the information is browsed, a final riding contract (contract) is made by telephone or the like. Specifically, for example, a trainer who has confirmed the arrival of a specific jockey on the visiting schedule browsing page calls the jockey and requests a ride. And if it agrees, it will formally vote for the organizer that the jockey will eventually ride. Conversely, the jockey confirms that the specific racehorse is looking for the jockey on the jockey detail page, and calls the trainer of the racehorse to offer that he wants to ride. If the trainer receives an offer, he will vote for the organizer for the jockey to ride. Note that a request for riding from a trainer or a request for riding from a jockey may be made by e-mail or the like.

  As described above, in the support system according to the embodiment, the trainer informs each jockey that he / she is searching for a jockey for a specific race (specific racehorse), and the jockey side reports on a specific date of the event. It is reported that he will visit a specific racetrack. By disclosing such information, the trainer can select a jockey, and the jockey can select a racehorse to ride. For this reason, it is horse riding matching support that is optimal for the trainer and jockey.

In horse riding matching, for example, it may be possible to register that the jockey is recruiting a horse to ride without having a plan to ride in a specific race and to inform each trainer. However, this configuration is not very suitable in practice. If the jockey announces that he / she does not plan to ride, it will be difficult for the jockey to request a ride for a racehorse that he / she does not want to ride. For example, if there is a horse riding request that the jockey thinks that there is not much chance of winning, if he refuses, the trainer may be offended and no longer request the riding. In the case of the embodiment, when a horse rider requests to ride a horse that he does not want to ride, even if there is no plan to ride a horse, the rider will lie, “Sorry, it is decided to ride another horse for that race.” You can decline. On top of that, you can wait for a horse-riding request with a chance to win.
In a similar sense, it is not preferable to register and disclose that a jockey is going to ride in a specific race. This is because, if there is no registration of the riding schedule, the trainer interprets that the jockey has no riding schedule. In other words, it is unclear whether or not there is a plan for riding, but it is preferable for the rider to obtain a better riding opportunity to at least tell him to go to the racetrack on the date of the event.

  In this embodiment, the jockey information includes information on the racehorse that the horse wants to ride, and the jockey can view this information. For this reason, when a jockey proposes to ride on his own, it is preferable because he can choose a horse with a better chance of winning. Furthermore, in this embodiment, since the past battle record is included as racehorse information, it is easy to determine the probability of winning when riding the horse, which is more suitable in this respect. It has become a thing.

  On the other hand, when requesting a ride from the trainer side, it is difficult to select a jockey in a situation where it is not known which trainer will come to the racetrack on the date of the event. It is very cumbersome to call each jockey and check the schedule for the day. On the other hand, if the support system of the embodiment is used, at least which jockey will come to the racetrack can be known, so it is possible to contact the intended jockey from among them, and even if refused, other jockeys scheduled to visit Can be selected and requested, and the labor to select a jockey is considerably saved.

  Furthermore, in the support system of the embodiment, jockey information browsing means and jockey visit schedule information registration means are organically related, and this is also a major feature. That is, when it is planned to go to which racetrack on a specific date, it is possible to view whether jockey information is registered for a specific race held on a specific racetrack. If jockey information is registered, there is a possibility that if you go to the racetrack on that day, you may get a chance to ride. Considering this, the jockey inputs jockey visit schedule information at jockey terminal 4 Can be registered. In other words, the synergistic effect is demonstrated that the jockey makes it easier for the jockey to register the attendance schedule by disclosing the jockey information, and the jockey makes it easier for the trainer to request a ride from the jockey by registering the attendance schedule. Has become. And, the jockey information is released in the form of the number of racehorses seeking jockeys, so the jockey knows how likely it is to get a horseback ride if you go to that racetrack that day This is more suitable in this respect.

  In addition to the above labor-saving viewpoint, the support system according to the embodiment also has an effect from the viewpoint of increasing the riding opportunity and impartiality. That is, even a jockey who does not have a connection with an intermediary can expect to receive a ride request from a trainer simply by registering a visit schedule using the support system of the embodiment. For this reason, it becomes easier for young jockeys and the like who have little experience to get a chance to ride. Since the trainer can easily request a rider other than the jockey who has a connection with the intermediary with whom the trainer is associated, the range of selection is widened, and it becomes easy for the rider to ride a more suitable rider.

  The jockey's work includes riding on a horse for training as well as riding in a race (training riding). The support system of the embodiment can perform matching for training riding. Specifically, a jockey training schedule information file (not shown) is stored in the storage unit 2. The jockey top is provided with a link button 85 to a jockey training schedule input page. On the jockey training schedule input page, a calendar is displayed along with a button for selecting a training center (currently Ritto or Miura), and you can enter your jockey training schedule in the squares of the calendar. The input jockey training schedule is recorded in the jockey training schedule information file, and this content can be viewed by each trainer. In other words, when the jockey training button 774 included in the upper UI 77 of the trainer page is pressed, the schedule of the jockey training of each jockey at the selected training center is displayed on the trainer terminal 3.

Further, in the configuration of the support system of the above embodiment, in order to realize more appropriate horse riding matching, it is preferable that detailed information of each jockey is disclosed to each trainer. Specifically, for example, in the visit schedule browsing page shown in FIG. 23, a field displaying the names of each jockey is set as a command button. And it is preferable to display past battle results and trends (compatibility with horses, compatibility with race conditions, etc.) when the command button is pressed.
If the horse name is entered on the horse name input page of FIG. 23, it is possible to save labor by executing the visit confirmation program 174 on the assumption that it is decided to come to the racetrack on the day of the race. However, there are cases where it is not preferable. This is because some jockeys may not want to disclose that they are going to the racetrack on the day of the event, even if they have decided to ride in a certain race. This is because there are racehorses that are willing to participate in other races on the racetrack on the date of the event, and it may be desirable to conceal the visit in order to ride on it. In other words, it may be preferable for the horse name input to be used by the jockey for managing his / her schedule and not linked to the registration of the visit.

  In the support system of the above embodiment, the trainer side and the jockey side only provide information to each other, and are not systems for reaching the riding agreement on the support site. . For example, in the attendance plan browsing page shown in FIG. 23, a cell displaying the name of each jockey may be used as a command button, and when the button is pressed, a system for sending a request for riding to the jockey side may be used. In this case, an email to be sent may be provided with a button (hyperlink) of a program for sending an answer to the request, and the answer may be made by pressing it. Alternatively, when a horizontal bar displaying racehorse information in the jockey detail page shown in FIG. 21 is pressed, a horseback application may be transmitted to the trainer. The riding application is also transmitted to the trainer by e-mail, and the e-mail includes a button (hyperlink) of a program for transmitting an answer to the application. In addition, when providing the jockey's detailed information to the trainer, the configuration may be such that the detailed information is provided to the trainee of the offer destination only when the horse rider is requested.

  In the above embodiment, the horse name input function by the jockey is not essential and may not be implemented. If no horse name is entered, the number of horses on the jockey's racehorse will be displayed on the jockey program page even in races where riding is determined. Such a configuration may be adopted.

DESCRIPTION OF SYMBOLS 1 Support server 18 Visit plan browsing program 2 Storage part 21 Trainer information file 22 Jockey information file 26 Start plan information file 27 Jockey visit plan information file 3 Trainer terminal 4 Jockey terminal 5 Internet 6 Management terminal 774 Visit plan button

Claims (6)

A racehorse matching support system comprising a server accessible from both a trainer terminal operated by a horse racer trainer and a jockey terminal operated by a horse jockey, and a storage unit. ,
In the storage unit,
A racehorse information file that records information about the racehorse that the trainer is training,
A program information file that records the schedule information of the race including the date and racetrack,
A jockey information file, which is information indicating that a jockey to ride in a specific race is requested,
A jockey visit schedule information file that records the date of the race and at least one race and the name of the jockey scheduled to visit the racetrack,
Jockey information registration means for inputting jockey information at the trainer terminal and recording it in the jockey information file;
Jockey information browsing means for transmitting and browsing jockey information stored in the jockey information file to the jockey terminal;
Jockey attendance schedule information registration means for inputting jockey visit schedule information that is scheduled to visit a specific racetrack on a specific date on a jockey terminal and recording it in a jockey visit schedule information file;
A jockey visit schedule information browsing means for transmitting the jockey visit schedule information recorded in the jockey visit schedule information file to the trainer terminal for viewing.
The jockey information browsing means is a means for browsing jockey information without browsing the name of the requested jockey,
The jockey visit schedule information sent to the trainer terminal for viewing includes the name of the jockey,
The server is equipped with a program for causing the server to function as jockey information registration means, jockey information browsing means, jockey arrival schedule information registration means, and jockey arrival schedule browsing means. system. 2. The horse rider according to claim 1, wherein the jockey arrival schedule information browsing means is a means for allowing the jockey arrival schedule information to be browsed in a state in which the jockey ride schedule is unknown on the racetrack on the date of the event. Matching support system.   The jockey information recorded in the jockey information file includes information on the racehorse that the rider wants to ride, and the jockey information browsing means is means for browsing the information on the racehorse as well. The horse riding / sitting matching system according to claim 1 or 2.   The racehorse riding matching system according to claim 3, wherein the racehorse information includes a past battle record. The jockey information browsing means determines whether or not the jockey information is registered for a race held on the racetrack on the date of the event when the jockey visit schedule information registration means inputs the jockey visit schedule information. 5. The horse riding / sitting matching system according to claim 1, wherein the horse riding / scoring matching system is a means for transmitting information to the jockey terminal for browsing.   6. The horse riding / horse riding matching system according to claim 5, wherein the information on whether or not the jockey information is registered is information displayed by the number of racehorses scheduled to start seeking jockeys.

Images