Transportation reservation system, transportation reservation method, and transportation reservation program

Abstract

To smooth reservation processing in a traffic means such as an express bus and to improve the efficiency of the reservation processing of a common operation route.SOLUTION: In the traffic reservation system provided with each reservation system for storing management information required for reservation of a plurality of routes operated by a plurality of operators and a server 1, the server 1 is provided with a management information storage means 190 for storing the management information stored in the reservation system in advance, a reservation acceptance means 191 for accepting the reservation of the route, and a reservation means 192 for executing the reservation of the route based on the management information stored in the management information storage means 190 when the reservation of the route is accepted by the reservation acceptance means 191.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a transportation reservation system, a transportation reservation method, and a transportation reservation program that can effectively perform route searches, reservations, payments, etc. for express bus transfer routes, as well as smooth reservation processing and seat reservations for jointly operated routes. [Background technology]

[0002] A multimodal transportation search system has been proposed that searches for multiple types of transportation such as buses, airplanes, ferries, taxis, rental cars, and rental bicycles all at once and provides search results (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-211960 Summary of the Invention [Problem to be solved by the invention]

[0004] When using this type of system and actually using the searched multiple means of transportation, after using the first means of transportation, it is necessary to transfer between means of transportation when using the second means of transportation. Transfers occur not only when multiple types of transportation are used, but also when a single transportation mode is used. For example, express bus routes are set up all over the country along expressways, but because different bus companies (entities) operate in different regions, passengers may need to change buses or routes depending on their departure and arrival points. For example, if bus company A operates highway bus route A in region A (say, eastern Japan), then if a user wants to travel by highway bus within region A (say, Tokyo to Nagoya), they must use highway bus A. Also, if bus company B operates highway bus route B in region B (for example, western Japan), then if a user wants to travel by highway bus within region B (for example, Osaka to Okayama), they must use highway bus B. In this case, if you use express bus A, you will need to access the reservation site or counter (called Counter A) operated by bus company A to make a reservation and payment, and if you use express bus B, you will need to access the reservation site or counter (called Counter B) operated by bus company B to make a reservation and payment. Therefore, when traveling between regions A and B (for example, Tokyo to Okayama) by highway bus, it is necessary to travel on route A by highway bus A, then transfer to highway bus B to travel on route B, and it is also necessary to access counter A in advance to make a reservation and payment for highway bus A's route A (for example, Tokyo to Osaka), and to access counter B to make a reservation and payment for highway bus B's route B (for example, Osaka to Okayama). In other words, in addition to connecting flights, passengers had to visit multiple counters and complete procedures at each one. There are also expected benefits, such as the ability to effectively expand express bus routes by utilizing transfers. However, there remains the problem of cumbersome procedures such as reservations and payments required for transfers. In other words, although the conventional express bus system could be made more useful by allowing passengers to transfer, the cumbersome procedures remained an issue.

[0005] To address these issues, computerization of procedures can be effective to a certain extent, but problems are likely to occur in the process of linking with existing reservation systems via communication, and other problems that arise from this need to be addressed (see Figure 24). In addition, in express bus services, multiple bus companies may jointly operate one route (one bus), which poses the following challenges in seat management: For example, let us consider a case where bus company A and bus company B jointly operate a route, with bus company A managing the seats in the front half of the bus (referred to as the front seats) and bus company B managing the seats in the rear half of the bus (referred to as the rear seats). Reservation system A operated by bus company A allows seat reservations and seat management for front seats (including management of reservation status such as reserved or vacant), while reservation system B operated by bus company B allows seat reservations and seat management for rear seats. This resulted in an unreasonable problem: if all front seats were already reserved, users making reservations through reservation system A could not reserve any vacant rear seats, because those rear seats were under the control of reservation system B. In joint operations, the total revenue from the route is distributed to each bus operator at a set rate, but this type of operation can also be problematic in that it hinders increased revenue. In the past, these problems were addressed by having the person in charge at bus company A and the person in charge at bus company B communicate via telephone or other means and transfer some of the rear seats managed by reservation system B to bus company A. However, because this was done manually, it was cumbersome and prone to errors.

[0006] The present invention has been proposed to solve the problems associated with the conventional technology described above, and aims to provide a transportation reservation system, transportation reservation method, and transportation reservation program that make transfers and related procedures easy and useful. Another object of the present invention is to provide a transportation reservation system, a transportation reservation method, and a transportation reservation program that facilitate smooth reservation processing and enable efficient seat reservations for jointly operated routes. [Means for solving the problem]

[0007] In view of the above problems, one aspect of the present invention provides a transportation reservation system comprising reservation systems each storing management information required for reserving multiple routes operated by multiple operators, and a server, wherein the server is configured to include a management information storage means for storing the management information stored in advance by the reservation systems, a reservation acceptance means for accepting reservations for routes, and a reservation means for, when a reservation for a route is accepted by the reservation acceptance means, executing a reservation for the route based on the management information stored in the management information storage means.

[0008] In addition, a transportation reservation method according to another aspect of the present invention uses a server and reservation systems each storing management information necessary for reserving multiple routes operated by multiple operators, and includes a first step of storing the management information stored in the reservation systems in advance, a second step of accepting a reservation for a route, and a third step of, if a reservation for a route is accepted in the second step, executing the reservation for the route based on the management information stored in the first step.

[0009] In addition, a transportation reservation program according to another aspect of the present invention causes a computer connected to each reservation system, which stores management information required for reserving multiple routes operated by multiple operators, to function as a management information storage means for storing the management information stored in advance by the reservation systems, a reservation acceptance means for accepting reservations for the routes, and a reservation means for, when a reservation for a route is accepted by the reservation acceptance means, executing a reservation for the route based on the management information stored in the management information storage means. [Effects of the Invention]

[0010] According to the present invention, it is possible to realize a highly useful express bus service similar to a series of long-distance buses with simplified transfer procedures. In areas lacking direct routes, trains, airplanes and other means of transportation, express buses can be introduced as a new means of transportation. It is possible to provide a new form of transportation that utilizes transfers. It is also possible to facilitate smooth reservation processing and improve the efficiency of reservation processing for jointly operated routes. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a schematic diagram of a high-speed bus system according to an embodiment of the present invention; [Figure 2] FIG. 2 is a hardware configuration diagram of a server. [Figure 3] FIG. 2 is a hardware configuration diagram of a user terminal. [Figure 4] FIG. 2 is a functional configuration diagram of a server. [Figure 5] 10 is a table showing an example of grouping information. [Figure 6] FIG. 10 is an explanatory diagram of a route search based on grouping. [Figure 7] An explanatory diagram of a special transfer route. [Figure 8] 10 is a sequence chart showing a processing procedure for route search. [Figure 9] FIG. 10 is a diagram illustrating an example of a route search screen. [Figure 10] FIG. 10 is a diagram illustrating an example of a search result screen. [Figure 11] FIG. 10 is a diagram showing an example of a flight candidate display / selection screen. [Figure 12] 10 is a sequence chart showing the reservation and payment processing procedure. [Figure 13] FIG. 10 is a diagram showing an example of a fee information display screen. [Figure 14] FIG. 10 is a diagram illustrating an example of a reservation screen. [Figure 15] FIG. 10 is a diagram showing an example of a reservation result screen. [Figure 16] FIG. 10 is a diagram illustrating an example of a payment execution screen. [Figure 17] 10 is a sequence chart showing a procedure for changing a reservation. [Figure 18] 10 is a sequence chart showing a procedure for canceling a reservation. [Figure 19]FIG. 10 is a diagram illustrating an example of a recommendation display screen. [Figure 20] FIG. 10 is a diagram showing another example (part 1) of the display screen. [Figure 21] FIG. 10 is a diagram showing another example (part 2) of the display screen. [Figure 22] FIG. 10 is a diagram showing another example (part 3) of the display screen. [Figure 23] FIG. 1 is an explanatory diagram of cooperation between reservation systems (reservation cooperation). [Figure 24] The following diagrams are provided to explain problems that may occur when linking reservations. (a) shows a problem that may occur when making a new reservation, and (b) shows a problem that may occur when changing the number of people or canceling a reservation. [Figure 25] FIG. 10 is a functional configuration diagram of a server according to another embodiment. [Figure 26] FIG. 10 is an explanatory diagram of a high-speed bus system according to another embodiment. [Figure 27] FIG. 10 is a diagram showing the acquisition of seat information before sales (A1). [Figure 28] This is a diagram showing the setting of seats for sale before sales (A2). [Figure 29] FIG. 10 is a diagram showing seat information (A3) after sales (reservations) have begun. [Figure 30] This is a diagram showing the addition and deletion (A4) of seats for sale after sales (reservations) have begun. [Figure 31] FIG. 10 is a diagram showing the acquisition of vacant seat information (B1). [Figure 32] This is a diagram showing a request for a seat (B2). [Figure 33] FIG. 10 is a diagram showing the execution of seat-taking (B3). [Figure 34] This is a diagram showing the automation of seat support (B4). DETAILED DESCRIPTION OF THE INVENTION

[0012] A preferred embodiment of the express bus system of the present invention will now be described.

[0013] FIG. 1 is a schematic diagram of a high-speed bus system according to an embodiment of the present invention. As shown in the figure, the express bus system of this embodiment is mainly composed of a server 1, a user terminal 2, a reservation system, and a payment system. The reservation system includes a reservation server 3 that is an information processing device, and is configured so that reservation processing, which will be described later, can be executed substantially by the operation of the reservation server 3. The payment system includes a payment server 4 that is an information processing device, and is configured to be able to execute the payment process described below substantially by the operation of the payment server 4. The devices are connected to each other via the Internet 9 so that they can communicate with each other.

[0014] FIG. 2 is a diagram showing the hardware configuration of the server 1. As shown in FIG. The server 1 is an information processing device (computer) including a control unit 101, a memory 102, a storage 103, and a communication unit 104. The control unit 101 is a processor that executes programs (including a high-speed bus processing program), controls each unit of the server 1, and performs processing to realize the functions of the server 1. The control unit 101 is equipped with a CPU (Central Processing Unit). The memory 102 is a computer-readable storage medium, and is configured from RAM (Random Access Memory), ROM (Read Only Memory), and the like. The storage 103 is a computer-readable storage medium, and is configured by an SSD (Solid State Drive), a hard disk, or the like. The memory 102 and / or the storage 103 store programs executed by the control unit 101. The communication unit 104 is connected to the Internet 9 and communicates with the user terminal 2 , the reservation server 3 , and the payment server 4 via the Internet 9 .

[0015] FIG. 3 is a diagram showing the hardware configuration of the user terminal 2. As shown in FIG. The user terminal 2 is an information processing device (computer) such as a smartphone, tablet terminal, or personal computer, which includes a control unit 201, a memory 202, a storage 203, an operation unit 204, a display unit 205, and a communication unit 206. The control unit 201 is a processor that executes a program, controls each unit of the user terminal 2, and performs processing to realize the functions of the user terminal 2. The control unit 201 uses a CPU (Central Processing Unit). The memory 202 is a computer-readable storage medium, and is configured from RAM (Random Access Memory), ROM (Read Only Memory), and the like. The storage 203 is a computer-readable storage medium, and is configured by an SSD (Solid State Drive), a hard disk, or the like. The memory 202 and / or the storage 203 store programs executed by the control unit 201. The operation unit 204 is used to operate the user terminal 2. The operation unit 204 corresponds to, for example, a keyboard and mouse of a personal computer, or a touch panel of a smartphone or tablet terminal. The display unit 205 displays information received from the server 1 and various screens (FIGS. 9, 10, 11, 13 to 16, and 19). The display unit 205 may be, for example, a liquid crystal display or a touch panel. The communication unit 206 is connected to the Internet 9 and communicates with the server 1 via the Internet 9 . A web browser is installed on the user terminal 2.

[0016] The reservation server 3 is an information processing device having the same hardware configuration as the server 1, and is synonymous with a reservation system. There are multiple reservation servers 3, such as reservation server 3A managed by bus company A that operates express bus A on a first route, and reservation server 3B managed by bus company B that operates express bus B on a second route. The reservation server 3A has traditionally operated reservation site A for express bus A and route 1. For this reason, it has been assumed that users can access reservation site A using an information terminal and make reservations for express bus A and its route A. The reservation server 3B has been operating reservation site B for express bus B and the second route. For this reason, it has been assumed that users can access reservation site B using an information terminal and make reservations for express bus B and its route B. In this way, a plurality of reservation servers 3 are provided according to the operators of express buses, and the express buses and routes operated by the operators. The reservation server 3 communicates with the server 1 via the Internet 9 . The reservation server 3 has the same hardware configuration as the server 1, and therefore a detailed description thereof will be omitted.

[0017] The payment server 4 is an information processing device having the same hardware configuration as the server 1, and is synonymous with a payment system. The payment server 4 performs payment processing for the item for which the reservation processing has been performed by the server 1. The payment server 4 of this embodiment is operated by a credit card company and allows credit card payments. In addition to or in addition to credit card payment, other payment methods (bank transfer, electronic money payment, convenience store payment, etc.) can also be used. The payment server 4 has the same hardware configuration as the server 1 and the reservation server 3, and therefore a detailed description thereof will be omitted.

[0018] FIG. 4 is a functional configuration diagram of the server 1. As shown in the figure, the server 1 (control unit 101) includes a storage means 11, an extraction means 12, a display control means 13, a reservation means 14, a payment means 15, a reservation change means 16, a reservation cancellation means 17, and a benefit granting means 18.

[0019] The storage means 11 stores in advance information on currently existing express bus routes throughout the country. The route information is the same as the route information managed by the reservation server 3. For this reason, it is sufficient to acquire and store route information managed by each reservation server 3 in the storage means 11. For example, when updating route information in each reservation server 3, the updated route information may be transmitted from the reservation server 3, or route information may be acquired from the server 1 as appropriate through API linkage to update the information. Route information may be acquired not only from the reservation server 3, but also from an information disclosure service (information disclosure server) that provides express bus route information. Specifically, the route information is configured to identify various information related to the route, such as the name of the route, the names and order of each stop, the names of the areas where each stop is located, the names of the areas where the route begins and ends, and the operating bus company, and each piece of information is linked to each other. Therefore, by referring to the route information, the control unit 101 can recognize, for example, the names of existing express bus routes, the names and order of each stop, the names of the areas where each stop is located, the names of the areas where the route starts and ends, the operating bus company, etc.

[0020] In particular, in the server 1 according to this embodiment, the route information groups routes that are the subject of transfers together so that not only direct routes but also transfer routes can be searched for. A "direct route" is a route that does not require a transfer, while a "transfer route" is a route that does require a transfer. "Grouping" basically means that when the area or stop at the end of one line is the same as the area or stop at the beginning of another line, the two lines are linked in series and stored. The explanation of these two routes is just an example, and three or more routes can be linked in series and grouped.

[0021] FIG. 5 is a diagram illustrating an example of grouping information. The grouping information will be explained using the first row in FIG. 5 as an example. This grouping information links the "Tokyo → Osaka" route (preceding route) with the "Osaka → Okayama" route and the "Osaka → Hiroshima" route (following route) as the same group, since the ending region of the "Tokyo → Osaka" route and the starting region of the "Osaka → Okayama" route and the "Osaka → Hiroshima" route are the same, "Osaka." Note that "〇〇→□□" indicates the name of the route, 〇〇 indicates the name of the area where the route starts, and □□ indicates the name of the area where the route ends. This allows you to set (register) a transfer route where you travel by express bus on the "Tokyo → Osaka" route, get off in Osaka and change onto another express bus to head to Okayama, or a transfer route where you travel by express bus on the "Tokyo → Osaka" route, get off in Osaka and change onto another express bus to head to Hiroshima. The setting and registration (storage) of the transfer route may be performed automatically by a computer or manually in accordance with the above-mentioned rules. By doing this artificially, it is possible to set only the transfer routes that are deemed necessary. In the case of computer processing, there is a possibility that a large number of unnecessary transfer routes will be set, but it is possible to reduce the number of unnecessary transfer routes by combining the methods described below (such as limiting the number of transfers) or by thinning them out manually. The grouping information is stored in the storage means 11 as information constituting a part of the route information.

[0022] The extraction means 12 extracts routes that can be used by the user (hereinafter also referred to as “usable routes”) from the track information stored in the storage means 11, based on the information input by the user terminal 2. The extraction means 12 is capable of extracting not only direct routes but also connecting routes. A "transit route (also called a connecting route)" can also be defined as a route (available route) that involves connections between multiple routes, including a preceding route (first route) and a succeeding route (second route). Because it is "multiple routes," it is not limited to transfers between two routes, but also includes transfers between three or more routes. In other words, available routes include not only connecting routes that connect two routes, but also connecting routes that connect three or more routes.

[0023] FIG. 6 is an explanatory diagram of a route search based on grouping, which is executed in the server 1 (extraction means 12) according to this embodiment. The following describes a case where a route search is performed using the search condition "Tokyo → Okayama." The "search conditions" can be set by the user through input operations on the user terminal 2. That is, when the search conditions (starting point: Tokyo and destination: Okayama) are input on the user terminal 2, the user terminal 2 transmits the input search condition information to the server 1. In the server 1, the communication unit 104 receives the search condition information transmitted from the user terminal 2, and the server 1 can set search conditions based on the search condition information.

[0024] When the search condition is "Tokyo → Okayama," the control unit 101 (extraction unit 12) first refers to the route information (including grouping information) stored in the storage means 11 and extracts the route (first route) whose starting area is "Tokyo." As a result, the routes "Tokyo → Osaka," "Tokyo → Kobe," and "Tokyo → Okayama" are extracted as the first routes. However, routes where the area where the extracted route ends is the same as the starting area will be excluded. In this way, the rule that excludes an extracted route if the area at the end of the route is "the same as the starting point" is called the "first rule." Furthermore, since there are no routes among the above first routes that fall under the first rule, there are no routes that are excluded based on the first rule. If the area at the end of the extracted route is "the same as the destination," the extraction means 12 extracts the route as an available route. The process ends without searching for routes below the route extracted as an available route. In this way, if the area at the end of the extracted route is "the same as the destination," the route is extracted as an available route, and the rule that ends the route search at that point is called the "second rule." Among the first routes, the route that falls under the second rule is "Tokyo → Okayama." Therefore, the extraction means 12 extracts the direct route of the "Tokyo → Okayama" route as an available route, and ends the process without searching for routes lower than "Tokyo → Okayama".

[0025] Next, the control unit 101 (extraction unit 12) extracts a route (second route) that starts from the area where the first route ends. That is, for each of the preceding routes "Tokyo → Osaka" and "Tokyo → Kobe," a following route (second route) is extracted. In the case of the "Tokyo → Osaka" route, the ending region is "Osaka," so routes that start in "Osaka" are extracted. As a result, "Osaka → Tokyo," "Osaka → Okayama," and "Osaka → Hiroshima" are extracted as the second routes. However, based on the first rule, the "Osaka → Tokyo" route is excluded because the area at the end of the extracted route is the same as the starting point. In the case of the "Tokyo → Kobe" route, the ending region is "Kobe," so routes that start in "Kobe" are extracted. As a result, "Kobe → Tokyo" and "Kobe → Okayama" are extracted as the second routes. However, based on the first rule, the "Kobe → Tokyo" route is excluded because the area at the end of the extracted route is the same as the starting point. As a result, the "Osaka → Okayama" route and the "Kobe → Okayama" route are extracted as (part of) available routes based on the second rule, since the region at the end of the route is the same as the destination. That is, in this case, the connecting route "Tokyo → Osaka" → "Osaka → Okayama" and the connecting route "Tokyo → Kobe" → "Kobe → Okayama" are extracted as available routes. The route search for each line is also terminated.

[0026] Next, the control unit 101 (extraction unit 12) extracts a route (third route) that starts from the area where the second route ends. That is, the control unit 101 extracts a route (third route) that follows the preceding route, "Osaka → Hiroshima." In the case of the "Osaka → Hiroshima" route, the ending region is "Hiroshima," so we extract the route with "Hiroshima" as the starting region. As a result, the "Hiroshima → Okayama" route is extracted. The "Hiroshima → Okayama" route is extracted as (part of) an available route based on the second rule, since the area at the end of the route is the same as the destination. That is, in this case, the extraction means 12 extracts the connecting route "Tokyo → Osaka" → "Osaka → Hiroshima" → "Hiroshima → Okayama" as an available route, and terminates the route search. In this way, the route search applies the first and second routes in the order of first route → second route → third route → ..., and executes a process to extract available routes in stages until there are no more routes to search for. In summary, when a route search is performed using "Tokyo → Okayama" as the search criterion, the following routes are extracted as available: "Tokyo → Osaka" → "Osaka → Okayama" (A1 → A3 → A5 in Figure 6), "Tokyo → Osaka" → "Osaka → Hiroshima" → "Hiroshima → Okayama" (A1 → A3 → A6 → A8 in Figure 6), and the connecting routes "Tokyo → Kobe" → "Kobe → Okayama" (B1 → B3 → B5 in Figure 6), as well as the direct route "Tokyo → Okayama" (C1 → C3 in Figure 6).

[0027] However, even if we group route combinations in which the end area of ​​the first route and the start area of ​​the second route are the same while following the first and second rules described above, there are many such combinations, so there is a problem that simply extracting available routes through computer processing may result in extracting many useless available routes. This problem can be addressed by limiting the number of transfers to a certain number. That is, the extraction means 12 extracts, as available routes, transit routes with a specific number of transfers or less, and does not extract, as available routes, transit routes with a specific number of transfers or more. If we set "specific number = 2," the route "Tokyo → Osaka" → "Osaka → Hiroshima" → "Hiroshima → Okayama" (A1 → A3 → A6 → A8 in Figure 6) mentioned above will not be extracted as an available route because it has three transfers.

[0028] In addition to limiting the number of transfers, the available routes can also be limited by other methods. For example, the grouping information is set manually. As an example, a combination (grouping) of routes for which demand for transfers is expected from the perspectives of bus operators, travel agents, and users is manually detected, and the grouping information is stored in the storage means 11. For example, if past usage history shows that many passengers use express buses to travel between Hiroshima and Okayama, or if prior interviews and surveys show that Hiroshima is popular, and Okayama is also the departure and arrival point, Hiroshima, which is one bus stop (nearby area) from Okayama, will be set as the transfer point. As a result, even if the route "Tokyo → Osaka" → "Osaka → Hiroshima" → "Hiroshima → Okayama" (A1 → A3 → A6 → A8 in Figure 6) cannot be extracted due to the limit on the number of transfers, as mentioned above, this route can be extracted as an available route as an exception.

[0029] The aforementioned route "Tokyo → Osaka" → "Osaka → Hiroshima" → "Hiroshima → Okayama" (A1 → A3 → A6 → A8 in Figure 6) is a round-trip transfer route (hereinafter referred to as the special transfer route) in which the passenger passes through Okayama (destination) from Osaka, arrives in Hiroshima, and then transfers to another express bus in Hiroshima to continue to Okayama (destination). FIG. 7 is an explanatory diagram of a special connecting route. As shown in the figure, a special connecting route is, in other words, a connecting route in which the distance from the departure point (Tokyo) to the connecting point (Hiroshima) is longer than the distance from the departure point (Tokyo) to the destination (Okayama). In other words, the special transfer route is also a transfer route that overlaps the preceding route "Osaka → Hiroshima" and the following route "Hiroshima → Okayama" in the "Hiroshima - Okayama" section (part of the section). At first glance, such special transfer routes seem unnecessary.

[0030] However, for example, if a user living in Tokyo whose parents live in Hiroshima needs to go to Okayama for business purposes, they will be able to return to Hiroshima first before traveling to Okayama on a business trip. It is possible to adjust the time until the transfer or set the transfer for the next day, allowing users to make more effective use of their time at the transfer point. Such services are not offered by conventional transportation services, including express buses, and even if they were feasible, they were latent. For this reason, previous users felt some frustration that they had come so close to their parents' homes but were unable to return home, but it seems that they gave up on the idea due to regulatory considerations and common sense. The express bus system of this embodiment can realize a new service that provides connecting routes that allow passengers to travel to areas farther than their destination before arriving at their destination, thereby resolving potential issues with conventional transportation services.

[0031] This section explains route searches based on search criteria limited to bus stop names. Stop-based route search is similar to the area-based route search described above. For this reason, we will omit the explanation of the parts that are common to area-based route search, and will only provide an explanation that will allow you to understand stop-based route search.

[0032] In a route search based on bus stops, the user operates the user terminal 2 to specify the departure point and destination by bus stops. For example, if there is a bus stop called "Tokyo Station" in Tokyo, and there are bus stops called "Okayama Interchange" and "Okayama Station" in Okayama, and there are routes "Tokyo Station → Okayama Interchange" and "Tokyo Station → Okayama Station," you can specify "Tokyo Station" as the departure point and "Okayama Interchange" or "Okayama Station" as the destination.

[0033] For this reason, in the route information, the names of each bus stop and the area name are stored in association with each other. For example, since there are bus stops called "OCAT" and "Umeda Tower" in "Osaka," the route information stores "Osaka" (area name) in association with "OCAT" and "Umeda Tower" (stop name). Similarly, since there are stops called "Okayama Station" and "Okayama Interchange" in "Okayama," in the route information, "Okayama" (area name), "Okayama Interchange" (stop name), and "Okayama" are stored in association with each other. Similarly, since there are bus stops called "Kobe Sannomiya" and "Kobe Station" in "Kobe," the route information stores "Kobe" (area name) in association with "Kobe Sannomiya" and "Kobe Station" (stop names). It is assumed that "Tokyo" only has a stop called "Tokyo Station," and "Hiroshima" only has a stop called "Hiroshima Station." For this reason, "Tokyo" (area name) and "Tokyo Station" (stop name), and "Hiroshima" (area name) and "Hiroshima Station" (stop name) are linked and stored.

[0034] In addition, in the route information, it is assumed that there are stop-based routes "Tokyo Station → Umeda Tower" and "Tokyo Station → OCAT" corresponding to "Tokyo → Osaka" (area name). Similarly, it is assumed that there are stop-based routes "OCAT → Okayama Station" and "OCAT → Okayama Interchange" (stop name) corresponding to "Osaka → Okayama" (area name). Similarly, it is assumed that there is a stop-based route "OCAT → Hiroshima Station" (stop name) corresponding to "Osaka → Hiroshima" (area name). Similarly, it is assumed that there are stop-based routes "Tokyo Station → Kobe Sannomiya" and "Tokyo Station → Kobe Station" (stop name) corresponding to "Tokyo → Kobe" (area name). Similarly, it is assumed that there are stop-based routes "Kobe Station → Okayama Interchange" and "Kobe Station → Okayama Station" (stop name) corresponding to "Kobe → Okayama" (area name). Similarly, it is assumed that there are stop-based routes "Tokyo Station → Okayama Interchange" and "Tokyo Station → Okayama Station" (stop name) corresponding to "Tokyo → Okayama" (area name).

[0035] Under these assumptions, when a route search is executed using the search condition "Tokyo Station → Okayama Station," the same processing as the route search based on the area name described above is executed. The "first rule" is interpreted as "a rule that excludes a route if the stop is the same as the last stop of the extracted route." In addition, the "second rule" is interpreted and applied as "a rule that extracts an extracted route as an available route if the last stop of the extracted route is the same as the destination, and terminates the route search at that point." As a result, the transfer routes "Tokyo Station → OCAT" → "OCAT → Okayama Station" (A1 → A3 → A5 in Figure 6), "Tokyo Station → OCAT" → "OCAT → Hiroshima Station" → "Hiroshima Station → Okayama Station" (A1 → A3 → A6 → A8 in Figure 6), and "Tokyo Station → Kobe Station" → "Kobe Station → Okayama Station" (B1 → B3 → B5 in Figure 6), as well as the direct route "Tokyo Station → Okayama Station" (C1 → C3 in Figure 6), are extracted as available routes.

[0036] The display control means 13 is a function for causing the information output by the server 1 to be displayed on the user terminal 2. Specifically, the information transmitted by the server 1 can be displayed on the display unit 205 (on the web browser) using a web browser provided in the user terminal 2. The display control means 13 can, for example, display information on available routes extracted by the extraction means 12 on the user terminal 2. In this case, the server 1 (communication unit 104) transmits information on the extracted available routes to the user terminal 2. The user terminal 2 displays the information about the available routes sent from the server 1 on the display unit 205 (see FIG. 10).

[0037] The reservation means 14 executes reservation processing for available routes in response to operations on the user terminal 2. The reservation means 14 can execute reservation processing for a plurality of routes that make up a connecting route in a batch in response to an operation of the user terminal 2. This "collective reservation processing" is performed in cooperation with multiple reservation servers 3 that are each responsible for the reservation processing of multiple routes. Specifically, server 1 works in conjunction with reservation server 3A, which has traditionally been responsible for processing reservations for the "Tokyo Station → OCAT" route, and reservation server 3B, which has traditionally been responsible for processing reservations for the "OCAT → Okayama Station" route. For reservation processing for the "Tokyo Station → OCAT" route, server 1 sends reservation request information to reservation server 3A, and for reservation processing for the "OCAT → Okayama Station" route, it sends reservation request information to reservation server 3B. When reservation server 3A receives reservation request information for the "Tokyo Station → OCAT" route, it executes reservation processing for the "Tokyo Station → OCAT" route, and when reservation server 3B receives reservation request information for the "OCAT → Okayama Station" route, it executes reservation processing for the "OCAT → Okayama Station" route. That is, the server 1 transmits reservation request information to the reservation server 3 that handles reservation processing for the target route, and requests the reservation processing, and the reservation processing is then executed by the reservation server 3. Of course, reservations for direct routes can also be processed. In this case, the server 1 may transmit reservation request information to the reservation server 3 that is responsible for reservation processing for direct routes, and request the reservation processing.

[0038] The payment means 15 executes payment processing in response to the operation of the user terminal 2. The payment means 15 can execute payment processing for multiple reserved routes in a lump in response to an operation of the user terminal 2. This "lump-sum payment processing" is realized by the cooperation between the server 1 and the payment server 4. This is because the payment server 4 is, for example, a payment processing device managed and operated by a credit company. Therefore, server 1 receives information necessary for payment (user's name, amount, card number, expiration date, security code, etc.) from user terminal 2, and sends payment request information including that information to payment server 4 to request payment processing, and payment processing is then executed by payment server 4. The express bus system of this embodiment is equipped with one payment server 4, but if there is a payment system for each credit company, cooperation with each payment server 4 equipped in each payment system will be necessary. For example, if only credit card A can be used to settle (pay) the fare for express bus A or the first route (first fare) and the settlement process can be performed by settlement server 4A, and only credit card B can be used to settle (pay) the fare for express bus B or the second route (second fare) and the settlement process can be performed by settlement server 4B, server 1 will send settlement request information to settlement server 4A for the settlement process for the first fare, and will send settlement request information to payment server 4B for the payment process for the second fare.

[0039] The reservation change means 16 executes reservation change processing in response to an operation on the user terminal 2. The reservation change means 16 can execute reservation change processing for multiple reserved routes in a batch in response to an operation on the user terminal 2. The reservation cancellation means 17 can execute a reservation cancellation process in response to an operation on the user terminal 2. The reservation cancellation means 17 can execute cancellation processing for multiple reserved routes in a batch in response to an operation on the user terminal 2. The reservation change means 16 and the reservation cancellation means 17 will be described in detail later (FIGS. 17 and 18).

[0040] The privilege granting means 18 grants privileges such as fare discounts and points to users of the connecting route. In particular, the benefit granting means 18 can grant more benefits to a user of a transit route with a second number of transfers, which is greater than the first number, than to a user of a transit route with a first number of transfers, when using the transit route. Specifically, the discount rate may be set higher the more transfers there are, such as X% for one transfer, Y% (≧X%) for two transfers, and Z% (≧Y%) for three transfers. The discount amount may vary depending on the circumstances at the time of reservation (for example, the discount rate may be higher during off-season than during peak season, or the discount rate may be higher when there are many vacant seats). A special connecting route may be given a higher discount rate than a normal connecting route, in which case the longer the overlapping distance between the preceding route and the following route, the higher the discount rate may be. In addition, the discount amount can be set by combining other factors such as the distance of the route, the time of use, the cumulative number of transfers including past transfers, etc. The administrator can also set any discount amount or discount rate. This will make it easier to use connecting routes at low cost, and will increase the value of express buses through an increase in users, etc.

[0041] The functions of the reservation server 3 will not be described in detail here, as they utilize a known express bus reservation system. The functions of the payment server 4 will not be described in detail because it utilizes a known payment system such as credit card payment.

[0042] (Processing Procedure) A specific processing procedure (high-speed bus processing method) in the high-speed bus system will now be described. Specifically, we will explain "route search," "reservation and payment," "reservation change," and "reservation cancellation" in order.

[0043] (Route search) The route search process will now be described. FIG. 8 is a sequence chart showing the procedure for route search. As shown in the figure, in the route search process, first, search condition information is input (S101). The search condition information is input by the user operating the user terminal 2. FIG. 9 is a diagram showing an example of a route search screen displayed on the user terminal 2 (display unit 205). The route search screen is a web screen managed by the server 1, and can be displayed by inputting a predetermined URL (Uniform Resource Locator) into the web browser of the user terminal 2. On the route search screen, the user enters the search criteria information required for route search. For example, the departure point, destination, and departure date are input as search conditions (d1 to d3 in FIG. 9). The departure point and destination can be displayed, for example, in a pull-down menu, allowing the user to input the name of a region by selecting it, or, once a region is selected, to input the name of a bus stop in that region by selecting it (d1, d2 in FIG. 9). The departure point and destination can also be entered by selecting (clicking or tapping) the stop mark displayed on the map (d5 in Figure 9) (d4 in Figure 9). The departure date can be entered via the calendar linked to the icon or directly into the departure date field (d3 in Figure 9). In this processing procedure, it is assumed that the departure point "Tokyo Station," the destination "Okayama Station," and the departure date "February 1, 2024" are entered as search conditions (Figure 9). The departure date does not have to be entered at this stage, but may be entered immediately before making the reservation, for example. Other information (for example, departure time, arrival date, arrival time, stopovers, whether or not there is a connection, number of people, etc.) may also be entered as search conditions. The user terminal 2 (communication unit 206) transmits the input search condition information (place of departure, destination, and departure date) to the server 1.

[0044] When the server 1 (extraction means 12) receives the search condition information transmitted from the user terminal 2, it executes a route search (S102). In this example, the route search is performed by the extraction means 12 extracting available routes based on the departure point "Tokyo Station" and the destination "Okayama Station." The "departure date" is information required at the time of reservation, and is therefore stored in the server 1. As a result of the route search, four available routes are detected (extracted): (1) "Tokyo Station → OCAT" → "OCAT → Okayama Station," (2) "Tokyo Station → OCAT" → "OCAT → Hiroshima Station" → "Hiroshima Station → Okayama Station," (3) "Tokyo Station → Kobe Station" → "Kobe Station → Okayama Station," and (4) "Tokyo Station → Okayama Station." (1) to (3) are connecting routes, and (4) is a direct route. The explanation of route search has already been given, so it will be omitted here. The server 1 transmits the search result information of the route search to the user terminal 2 (S103). Specifically, the information on the available routes (1) to (4) above is transmitted.

[0045] When the user terminal 2 receives the search result information transmitted from the server 1, it displays the search result on the display unit 205 (S104). FIG. 10 is a diagram showing an example of a search result screen displayed on the display unit 205 of the user terminal 2. As shown in FIG. As shown in the figure, the search result screen displays information on the available routes (1) to (4) described above (d11). In other words, four available routes are displayed for selection: (1) "Tokyo Station → OCAT" → "OCAT → Okayama Station," (2) "Tokyo Station → OCAT" → "OCAT → Hiroshima Station" → "Hiroshima Station → Okayama Station," (3) "Tokyo Station → Kobe Station" → "Kobe Station → Okayama Station," and (4) "Tokyo Station → Okayama Station."

[0046] Next, route selection is performed (S105). Specifically, on the user terminal 2, the user selects a desired route from among routes (1) to (4) displayed on the search result screen (FIG. 10). In this processing procedure, it is assumed that (1) the transfer route "Tokyo Station → OCAT" (first line) → "OCAT → Okayama Station" (second line) has been selected. The user terminal 2 transmits information about the selected route to the server 1.

[0047] Next, when the server 1 receives the information on the connecting route transmitted from the user terminal 2, it transmits flight confirmation information to each reservation server 3 (S106). Specifically, flight confirmation information including the first route information and departure date is sent to the reservation server 3A, and flight confirmation information including the second route information and departure date is sent to the reservation server 3B. This is because reservation server 3A has traditionally been responsible for the operation management of route 1, "Tokyo Station → OCAT," and reservation server 3B has traditionally been responsible for the operation management of route 2, "OCAT → Okayama Station." In other words, since server 1 does not perform flight management, it requests flight confirmation from reservation server 3, which does manage flights. The "departure date" to be included in the flight confirmation information is the departure date received in S101 and stored in the server 1. Note that this "departure date" is not limited to the information received in S101, and may be, for example, the departure date input and transmitted on the user terminal 2 side when selecting the route in S105. It is preferable that the departure time of the second route is later than the arrival time of the first route and is within a predetermined time from the arrival time. Therefore, after receiving flight information for the first route from the reservation server 3A, the server 1 includes the arrival time for the first route included in the flight information in flight confirmation information and transmits it to the reservation server 3B (not shown). In addition, grouping may be set taking into account the arrival time of the first route and the departure time of the second route.

[0048] When each reservation server 3 receives flight confirmation information from the server 1, it searches for flight information (available departure and arrival times, fares, and seat availability) for each route and transmits it to the server 1. The reservation server 3A searches for flight information related to the first route and sends the flight information as the search result to the server 1 (S107), and the reservation server 3B searches for flight information related to the second route and sends the flight information as the search result to the server 1 (S108). In this processing procedure, the flight information for the first route is searched for as "2024 / 2 / 1_22:10-06:44_7,800 yen_6 seats remaining," and the flight information for the second route is searched for as "2024 / 2 / 2_09:30-12:30_2,900 yen_2 seats remaining" and "2024 / 2 / 2_10:30-13:30_3,000 yen_5 seats remaining." You can also set or limit the number of flights that are returned as search results. Searching for flight information is a well-known function provided in conventional reservation systems, and therefore a detailed description thereof will be omitted.

[0049] Next, the server 1 transmits flight information about all routes to the user terminal 2 (S109). Specifically, the server 1 transmits to the user terminal 2 the flight information regarding the first route and the flight information regarding the second route received from the reservation servers 3A and 3B. That is, the flight information for the first route is "2024 / 2 / 1_22:10-06:44_7,800 yen_6 seats remaining," and the flight information for the second route is "2024 / 2 / 2_09:30-12:30_2,900 yen_2 seats remaining" and "2024 / 2 / 2_10:30-13:30_3,000 yen_5 seats remaining."

[0050] The user terminal 2 displays the flight information received from the server 1 on the display unit 205 (S110). That is, the flight information for the first route is displayed as "2024 / 2 / 1_22:10-06:44_7,800 yen_6 seats remaining", and the flight information for the second route is displayed as "2024 / 2 / 2_09:30-12:30_2,900 yen_2 seats remaining" and "2024 / 2 / 2_10:30-13:30_3,000 yen_5 seats remaining". FIG. 11 is a diagram showing an example of the flight candidate display / selection screen. As shown in the figure, the flight candidate display / selection screen displays flight candidate information for the first flight (d21) and also displays flight candidate information for the second flight (d22). Specifically, the following flight candidate information is displayed: Flight 1_Tokyo → Osaka, Boarding date_Monday, February 1, 2024, Section_Tokyo Station → OCAT, Flight candidate 1_22:10 → 6:44, Fare_7,800 yen, Remaining seats_6 (d21); Flight 2_Osaka → Okayama, Boarding date_Monday, February 2, 2024, Section_OCAT → Okayama Station, Flight candidate 1_9:30 → 12:30, Fare_2,900 yen, Remaining seats_2; and Flight candidate 2_10:30 → 13:30, Fare_3,000 yen, Remaining seats_5 (d22).

[0051] (Reservations and payments) The reservation and payment processing procedures will now be described. FIG. 12 is a sequence chart showing the reservation and payment processing procedure. As shown in the figure, in the reservation process, first, flight selection is performed (S201). Specifically, the user selects the desired flight from among the flight candidates displayed on the flight candidate display / selection screen (Fig. 11). As shown in Figure 11, the flight candidate display / selection screen has check boxes for each flight candidate that can be used to select the flight candidate, so users can select their desired flight by selecting the check box for the flight candidate. In this processing procedure, the first flight selected is flight candidate 1, which departs from Tokyo Station at 22:10 and arrives at OCAT at 6:44, and the second flight selected is flight candidate 2, which departs from OCAT at 10:30 and arrives at Okayama Station at 13:30 (Figure 11). The user terminal 2 transmits the selected flight information (boarding flight information) to the server 1. Specifically, the boarding information is transmitted as [Tokyo Station → OCAT_2024 / 2 / 1_22:10-06:44] and [OCAT → Okayama Station_2024 / 2 / 2_10:30-13:30].

[0052] When the server 1 receives the flight information from the user terminal 2, it calculates the discount amount (S202). This is because certain discounts (transfer discounts) are applied to transfer routes as a transfer benefit. Transfer discounts can be set so that the more transfers there are, the greater the discount amount. For example, if the discount rate for one transfer is X%, for two transfers it is Y% (≧X%), and for three transfers it is Z% (≧Y%), the discount amount or fare is calculated by multiplying the fare by the discount rate according to the number of transfers. It is also possible to apply different discount rates and amounts during off-peak and peak seasons, or to apply discount rates and amounts according to the number of available seats. Passengers on special transfer routes may be eligible for higher discount rates and amounts than those on regular transfer routes. In this processing procedure, a discount of 200 yen is applied to the standard fee of 10,800 yen, consisting of 7,800 yen for the first shipment and 3,000 yen for the second shipment, resulting in a net fee of 10,600 yen. The server 1 transmits fee information such as the standard fee, the discount amount, and the deduction amount to the user terminal 2 (S203).

[0053] When the user terminal 2 receives the fee information from the server 1, it displays the fee information on the display unit 205 (S204). FIG. 13 shows an example of a fee information display screen displayed on the user terminal 2 (display unit 205). As shown in the figure, the fee information display screen can display the standard fee, discount amount, and deduction fee (d33). In this processing procedure, the standard fee of 10,800 yen, the discount amount of 200 yen, and the net fee of 10,600 yen are displayed. The fare information display screen can display the standard fare for the first flight (7,800 yen) (d31) or the standard fare for the second flight (3,000 yen) (d32).

[0054] Next, a reservation is made at the user terminal 2 (S205). Specifically, by selecting the "Proceed to reservation" button displayed on the price information display screen, the screen will move to the reservation screen. FIG. 14 is a diagram showing an example of the reservation screen. As shown in FIG. 14, the reservation screen has an input field for the user's personal information (such as name and contact information) (d41). In this processing procedure, it is assumed that "Name: Yamada Taro" and "Email address: yamada@bus.com" are entered (when making a reservation without logging in). You can also make a reservation by logging in. For example, by selecting the SNS login button (d42) displayed on the reservation screen, you can automatically log in via SNS integration and make a reservation request. When the reservation application is completed, the user terminal 2 transmits the reservation information to the server 1. In this processing procedure, personal information (name, contact information, etc.) and flight information ([Tokyo Station → OCAT_2024 / 2 / 1_22:10-06:44], [OCAT → Okayama Station_2024 / 2 / 2_10:30-13:30]) are sent.

[0055] When the server 1 receives the reservation information transmitted from the user terminal 2, it transmits reservation request information to the reservation server 3 (S206, S208). Specifically, reservation request information regarding the first route ("Tokyo Station → OCAT") is sent to reservation server 3A, and reservation request information regarding the second route ("OCAT → Okayama Station") is sent to reservation server 3B. This is because reservation server 3A has traditionally been responsible for processing reservations for the first route, "Tokyo Station → OCAT," and reservation server 3B has traditionally been responsible for processing reservations for the second route, "OCAT → Okayama Station." That is, since the server 1 is not currently processing reservations, it sends reservation request information to the reservation server 3, which has traditionally been responsible for reservation processing, to request the server 1 to process the reservations.

[0056] When the reservation server 3A receives the reservation request information from the server 1, it executes reservation processing for the first route (S207). When the reservation server 3A completes the reservation process, it transmits to the server 1 a reservation number indicating the reservation result. When the reservation server 3B receives the reservation request information from the server 1, it executes reservation processing for the second route (S209). When the reservation server 3B completes the reservation process, it transmits to the server 1 a reservation number indicating the reservation result. This will complete the reservation for the following flights: [Tokyo Station → OCAT_2024 / 2 / 1_22:10-06:44] and [OCAT → Okayama Station_2024 / 2 / 2_10:30-13:30].

[0057] In other words, the reservation process for the first route can be performed by a reservation server 3A (first device) operated by a first operator, and the reservation process for the second route can be performed by a reservation server 3B (second device) operated by a second operator different from the first operator.The reservation means 14 causes the reservation process for the first route to be performed by the reservation server 3A (first device) and the reservation process for the second route to be performed by the reservation server 3B (second device), thereby making it possible to perform the reservation process for a connecting route consisting of the first route and the second route in one go.

[0058] When the server 1 receives the reservation result from each reservation server 3, it transmits the reservation information and the reservation management number to the user terminal 2 (S210). The reservation management number is managed by the server 1. The reservation management number may be, for example, a number that combines the reservation number received from the reservation server 3A and the reservation number received from the reservation server 3B, or a newly assigned number may be managed in association with the reservation number.

[0059] When the user terminal 2 receives the reservation result (reservation management number) transmitted from the server 1, it displays the reservation result (reservation management number) on the display unit 205 (S211). FIG. 15 is a diagram showing an example of the reservation result screen. As shown in the figure, the reservation result screen displays the reservation management number "123456" indicating the reservation result on the user terminal 2 (display unit 205) (d51). This allows the user to know that the reservation has been completed.

[0060] Next, the payment information is entered into the user terminal 2 (S212). Payment information can be entered via the payment execution screen. FIG. 16 is a diagram showing an example of the payment execution screen. The payment execution screen can be displayed by selecting the "Proceed to payment" button on the reservation result screen (Figure 15). As shown in the figure, the payment execution screen displays the fee (d61) as payment information and provides an input field (d62) for credit card information (card number, expiration date, security code). The user's name can also be added to the payment information. The user enters the necessary payment information in the input fields. In this processing procedure, it is assumed that the following payment information has been entered: "Card number: 1234-5678-9021, expiration date: 2026 / 5 / 2, security code: ***" (Figure 16). The user terminal 2 transmits the entered payment information (including the fee) to the server 1.

[0061] When the server 1 receives the payment information transmitted from the user terminal 2, it transmits payment request information including the payment information to the payment server 4 (S213).

[0062] When the payment server 4 receives the payment request information transmitted from the server 1, it executes the payment process based on the payment information (S214). This will result in a credit card payment of 10,600 yen. That is, the payment means 15 executes the payment process in succession to the reservation process. The payment server 4 transmits the payment result to the server 1.

[0063] When the server 1 receives the payment result transmitted from the payment server 4, it transmits the payment result to the user terminal 2 (S215). When the user terminal 2 receives the payment result transmitted from the server 1, it displays the payment result on the display unit 205 (S216). This allows the user to know that the payment has been completed.

[0064] In this way, in the express bus system of this embodiment, reservations and payments for express buses can be made in a single operation.

[0065] (Reservation change) The procedure for changing a reservation will now be described. FIG. 17 is a sequence chart showing the procedure for changing a reservation. As shown in the figure, reservation changes can be made while the reservation information received from the server 1 is displayed on the display unit 205. For example, the reservation result screen (Figure 15) that displays the reservation information received from Server 1 (boarding information for the first reserved flight [Tokyo Station → OCAT_2024 / 2 / 1_22:10-06:44] and the second flight [OCAT → Okayama Station_2024 / 2 / 2_10:30-13:30]) can also be used as Reservation Change Screen 1. That is, in changing a reservation, first, the reservation change screen 1 is displayed on the display unit 205 of the user terminal 2 (S301).

[0066] Next, reservation change operation 1 is performed (S302). Specifically, reservation change operation 1 is an operation to specify the original flight information (i.e., the old flight information), and if the flight information for the first and second flights is displayed on reservation change screen 1, one or both of them can be selected as the flight to be changed. In this processing procedure, it is assumed that the second flight ([OCAT → Okayama Station_2024 / 2 / 2_10:30-13:30]) is selected. The user terminal 2 transmits the original flight information to the server 1.

[0067] When the server 1 receives the original flight information transmitted from the user terminal 2, it transmits the original flight information to the corresponding reservation server 3 (S303). In this processing procedure, the original flight information is sent to the reservation server 3B that is in charge of the reservation processing for the "OCAT → Okayama Station" route.

[0068] When the reservation server 3B receives the original flight information from the server 1, it transmits the candidate flight information to the server 1 (S304). Specifically, the reservation server 3B performs a new flight search based on the departure and arrival points and departure date of the flight to be changed that are included in the original flight information, and sends the search results to the server 1 as flight information for the flight to be changed. In this processing procedure, "2024 / 2 / 2_09:30-12:30_2,900 yen_2 seats remaining" and "2024 / 2 / 2_10:30-13:30_3,000 yen_5 seats remaining" are detected and sent as candidate flight information for change.

[0069] When the server 1 receives the flight information transmitted from the reservation server 3B, it transmits the flight information to the user terminal 2 (S305).

[0070] When the user terminal 2 receives the flight information transmitted from the server 1, it displays the flight information on the display unit 205 (S306). The user terminal 2 can display flight information by using the flight candidate display / selection screen (FIG. 11) as a reservation change screen 2 as well.

[0071] Next, reservation change operation 2 is performed (S307). Specifically, reservation change operation 2 is an operation to specify the destination flight information (i.e., new flight information). For example, if two flight options are displayed on reservation change screen 2, one or both of them can be selected. In this processing procedure, it is assumed that of flight candidate 1 "2024 / 2 / 2_9:30-12:30" and flight candidate 2 "2024 / 2 / 2_10:30-13:30", flight candidate 1 is selected as the changed destination flight information. The user terminal 2 transmits the changed destination information to the server 1.

[0072] When the server 1 receives the changed destination information transmitted from the user terminal 2, it calculates the discount amount (S308). The calculation of the discount amount is the same as in S202, so the explanation will be omitted. The server 1 transmits to the user terminal 2 fee information such as the standard fee, discount amount, and deduction fee. Specifically, fee information such as a standard fee of 10,700 yen, a discount amount of 200 yen, and a net fee of 10,500 yen is transmitted.

[0073] When the user terminal 2 receives the fee information transmitted from the server 1, it displays the fee information on the display unit 205 (S309). The fee information is displayed on the fee information display screen (Fig. 13). However, the net fee will be changed to "10,500 yen" (d33).

[0074] Next, a reservation is made at the user terminal 2 (S310). Specifically, the "Proceed to reservation" button on the price information display screen (Fig. 13) is selected. In response to this, the user terminal 2 transmits the change information to the server 1. The change information includes information on the destination of the change and information on the fee.

[0075] When the server 1 receives the change information transmitted from the user terminal 2, it transmits the change information to the reservation server 3B (S311). When the reservation server 3B receives the change information sent from the server 1, it executes reservation change processing (S312). Specifically, the source flight information "2024 / 2 / 2_9:30-12:30" is changed to the destination flight information "2024 / 2 / 2_10:30-13:30." This executes the reservation change. The reservation server 3B transmits the result of the change to the server 1.

[0076] When the server 1 receives the change result from the reservation server 3B, it transmits the payment request information (including the fee information) to the payment server 4 (S313). The payment request information is received from the user terminal 2 in S212 and the stored payment information is used, and the fee is 10,500 yen.

[0077] Upon receiving the payment request information transmitted from the server 1, the payment server 4 executes the payment process (S314). This will result in a credit card payment of 10,500 yen. The payment server 4 transmits the payment result to the server 1.

[0078] When the server 1 receives the payment result transmitted from the payment server 4, it transmits the change result including the change content to the user terminal 2 (S315). When the user terminal 2 receives the change result transmitted from the server 1, it displays the change result on the display unit 205 (S316). The change result is not shown in the drawing.

[0079] (Reservation cancellation) The procedure for canceling a reservation will now be described. FIG. 18 is a sequence chart showing the procedure for canceling a reservation. As shown in the figure, reservation cancellation can be performed in a state where reservation information received from the server 1 is displayed on the display unit 205. For example, a reservation can be canceled when a screen (reservation cancellation screen) with a "Cancel reservation" button added is displayed on the reservation result screen (Figure 15) that displays the reservation information received from Server 1 (boarding information for the reserved first flight [Tokyo Station → OCAT_2024 / 2 / 1_22:10-06:44] and second flight [OCAT → Okayama Station_2024 / 2 / 2_10:30-13:30]). That is, in canceling a reservation, first, a reservation cancellation screen (not shown) is displayed on the display unit 205 of the user terminal 2 (S401).

[0080] Next, the reservation cancellation operation is performed (S402). Specifically, the "cancel reservation button" is selected. In response to the reservation cancellation operation, the user terminal 2 transmits cancellation information to the server 1.

[0081] When the server 1 receives the cancellation information sent from the user terminal 2, it calculates the fee (S403). Next, the server 1 transmits the cancellation information to the reservation server 3A (S404) and also transmits the cancellation information to the reservation server 3B (S406). When the reservation server 3A receives the cancellation information sent from the server 1, it executes the reservation cancellation process (S405). The reservation server 3A sends the cancellation result to the server 1. When the reservation server 3B receives the cancellation information transmitted from the server 1, it executes the reservation cancellation process (S407). The reservation server 3B transmits the cancellation result to the server 1.

[0082] When the server 1 receives the cancellation results from the reservation servers 3A and 3B, it transmits payment request information to the payment server 4 (S408). The payment request information is the payment information received from the user terminal 2 in S212 and stored therein, and the fee is the fee calculated in S403.

[0083] Upon receiving the payment request information transmitted from the server 1, the payment server 4 executes the payment process (S409). This allows the fee to be paid by credit card. The payment server 4 transmits the payment result to the server 1.

[0084] When the server 1 receives the settlement result transmitted from the settlement server 4, it transmits the cancellation result including the cancellation details to the user terminal 2 (S410). When the user terminal 2 receives the cancellation result transmitted from the server 1, it displays the cancellation result on the display unit 205 (S411). The cancellation result is not shown in the drawing.

[0085] In this way, in the express bus system of this embodiment, it is possible to cancel express bus reservations all at once. In other words, if you make a reservation for a connecting route and then want to cancel that reservation, in the past you would have had to access multiple counters and go through the reservation cancellation procedure individually at each one, but with the bus system of this embodiment, you can complete the procedure all at once.

[0086] (Recommendation information display) The display process of the recommendation information will be described. The express bus system of this embodiment is designed to provide various recommendation information to express bus users. Specifically, the server 1 acquires and stores route search and reservation history information for each member when the member user is logged in, and generates recommended information (recommendation information) that may be of interest to the member through analysis based on the history information, and notifies the member of this information at the appropriate time via the user terminal 2. In particular, for members who have booked a connecting route, recommended information is displayed on the user terminal 2 via a web browser while logged in, and recommended information is sent to a pre-registered email address while not logged in.

[0087] FIG. 19 is a diagram showing an example of a recommendation display screen. Figure 19 shows the recommendation information that will be sent from Server 1 to Yamada's email address between the time of booking and the departure date when member Yamada reserves a connecting route with a departure date of February 1, 2024 and a boarding and transfer point of "Osaka." The recommended information shown in the figure suggests that Yamada has booked a connecting route and that the recommended information corresponds to the time when Yamada will transfer at the connecting point. Specifically, there are "recommended events" (d71), "recommended gourmet food" (d72), and "recommended spots" (d73). The "recommended events" information is recommended information that corresponds not only to the transfer location but also to the transfer period. The same applies to information on "recommended gourmet food" and "recommended spots." In particular, the "recommended spots" information reflects the results of Server 1's recognition or analysis, such as the fact that the arrival time at the transfer point is early in the morning and the departure time is the night before, and therefore the user is likely to be sleep-deprived.

[0088] Recommendation information can also be generated in association with conditions such as before, during, and after using the express bus. An example of recommendation information "before using the express bus" is to have the server 1 generate information encouraging members to make reservations for the express bus by pairing recommended spots etc. with the nearest bus stop, and notify the user terminal 2 by e-mail etc. An example of recommendation information "while using an express bus" is to have the server 1 generate optimal recommendation information for a member who has reserved an express bus before or during boarding, and notify the user terminal 2 at the appropriate time by e-mail or the like. In more detail, the user's current location can be identified from the time and the GPS information of the user terminal 2, and various information according to the current location (for example, while traveling near Mt. Fuji, videos and website information about Mt. Fuji, etc.) is sent to the user terminal 2. An example of recommendation information "after using an express bus" is to have the server 1 generate recommendation information (for example, a message from a popular mascot character such as "Please use this again") that will encourage members who have just used an express bus to make their next reservation, and notify the user terminal 2 via chat or the like.

[0089] Another example of display on the user terminal 2 will be described. FIG. 20 is a diagram showing another display example (part 1) of the search result screen for a route search. As shown in the figure, the user can select the display order of the route search results (d81). Specifically, the user can select either "travel time" or "fare," and if "travel time" is selected, flight information is displayed in order of shortest travel time, and if "fare" is selected, flight information is displayed in order of cheapest fare. Furthermore, you can narrow down the flight information by selecting either "with transfer" or "without transfer." For example, users who prefer or accept transfers can select "with transfers," while users who do not prefer or accept transfers can select "without transfers."

[0090] FIG. 21 is a diagram showing another display example (part 2) of the search result screen for a route search. As shown in the figure, it is also possible to select either "highest number of transfers" or "lowest number of transfers" and display the flight information in the selected order (d82). Such a display control function is controlled by the server 1. For example, if "in order of most number of transfers" is selected, the display control means 13 of the server 1 can display information on flights with the most number of transfers at the top. That is, the display control means 13 causes the user terminal 2 to display a connecting route with a second number of transfers, which is greater than the first number, higher than a connecting route with a first number of transfers.

[0091] FIG. 22 is a diagram showing another display example (part 3) of the search result screen for a route search. As shown in the figure, the transfer discount amount may be displayed. Specifically, the transfer discount (d83) is displayed for transfer routes, and the transfer discount amount is not displayed for direct routes. Furthermore, the transfer discount for a transfer route with many transfers can be greater than the transfer discount for a transfer route with few transfers. In other words, a relatively large discount amount will be applied to a transfer route with a large number of transfers and displayed.

[0092] This will enable the display to cater to users who prefer to transfer, or who want to use express buses at a lower fare by increasing the number of transfers. Previously, the order in which flights were displayed was not rearranged according to the number of transfers. Even if such a thing were to happen, there is a preconceived notion that "transfers = inconvenience," so it was not anticipated that the number of transfers would be displayed in descending order. According to the express bus system of this embodiment, the convenience of transfers is improved, thereby eliminating the idea that "transfers = inconvenience." In addition, the display modes shown in Figures 20 to 22 can further improve convenience for users who want to actively use transfers.

[0093] As described above, the express bus system of this embodiment is an express bus system equipped with a user terminal 2 carried by an express bus user, and comprises: a storage means 11 for storing information on existing express bus route information; an extraction means 12 for extracting available routes that are routes that can be used by the user from the route information based on information input by the user terminal 2; a display control means 13 for displaying information on the extracted available routes on the user terminal 2; and a reservation means 14 capable of executing reservation processing for the available routes in response to operation of the user terminal 2, wherein the extraction means 12 is capable of extracting, as the available route, a transfer route that involves transfers between multiple routes including a first route and a second route, and the reservation means 14 is capable of executing reservation processing for multiple routes that make up the transfer route all at once in response to operation of the user terminal 2. In other words, the reservation process for a connecting route is executed in one batch in response to operations via a single website, and furthermore, following the reservation process, the payment process is executed in a series and batch. This will make reservations and payment procedures easier, and will allow connecting routes to be offered as a highly useful express bus service, similar to a series of long-distance buses. Furthermore, the express bus system of this embodiment requires cooperation and collaboration between bus operators, and through such cooperation and collaboration, the bus business as a whole can flourish. It will also help to resolve the actual vehicle mileage restrictions and the so-called 2024 problem that bus operators face. Furthermore, in areas lacking direct routes or other means of transportation such as rail or air travel, express bus services with transfers can be introduced as a new means of transportation. Furthermore, the express bus system of this embodiment can propose new modes of travel and trips. In contrast to this, conventionally, there has been the cumbersome procedure involved in transferring, but the express bus system of the present invention, by being provided with the above-mentioned configuration, can solve such conventional problems. In other words, in the past, even if you were making a transfer, you had to make reservations at multiple counters, but with the express bus system of this embodiment, all reservations can be processed together, and payments can be made all at once, and changes and cancellations can also be processed together.

[0094] (Other embodiments) Another embodiment of the present invention will now be described. In the above embodiment, it has been explained that reservations for express buses are made in cooperation with an existing reservation system (reservation server) (referred to as reservation cooperation). Reservation integration is expected to occur in cases where two reservation systems are integrated, or in cases where three or more reservation systems are integrated.

[0095] FIG. 23 is an explanatory diagram of reservation linkage. Specifically, Fig. 23 is a diagram that shows the process of making a reservation for a connecting route that involves changing over three lines through reservation cooperation. For this reason, Fig. 23 assumes cooperation with three reservation systems. In other words, Figure 23 assumes that a user operates user terminal 2 to make a reservation for a connecting route consisting of route 1 (bus A), route 2 (bus B), and route 3 (bus C). As a premise, the first route is managed by reservation system A (reservation server A) operated by bus company A, the second route is managed by reservation system B (reservation server B) operated by bus company B, and the third route is managed by reservation system C (reservation server C) operated by bus company C. In other words, there are reservation systems for multiple routes operated by multiple operators, including reservation system A (first reservation system) which can make reservations for a first route operated by bus company A (first operator), and reservation system B (second reservation system) which can make reservations for a second route operated by bus company B (second operator), and each reservation system (each reservation server) can make reservations for routes which it operates and manages within its own system, and therefore holds (stores) the management information necessary for making reservations for its own route. In this case, when the server 1 in the above-described embodiment accepts a reservation for a connecting route, it requests reservation system A to make a reservation for the first route, requests reservation system B to make a reservation for the second route, and requests reservation system C to make a reservation for the third route. The same applies to seat reservations, where reservations for the first route are requested from reservation system A, reservations for the second route are requested from reservation system B, and reservations for the third route are requested from reservation system C. Each reservation system reserves routes and seats according to the request. When the server 1 receives information including the reservation result (reservation result information) from each reservation system, it notifies the reservation result to the user terminal 2. The server 1 saves the reservation result information for log or other purposes. However, the inventors have discovered that such reservation linkages cause the following problems.

[0096] FIG. 24 is a diagram for explaining a problem that occurs in reservation linkage. FIG. 24(a) shows a problem that occurs when making a new reservation. Specifically, this shows a case where, when making a new reservation, the reservation based on the connection between reservation system A and reservation system B was processed without any problems, but a problem occurred in the connection with reservation system C, causing the route or seat reservation to fail. In this case, the user will have to make the reservation again, which reduces convenience, and the successful reservation on reservation systems A and B will have to be deleted, which can cause other problems. FIG. 24(b) shows problems that occur when the number of people is changed or the reservation is canceled after the reservation has been made. Specifically, this shows a case where a reservation cancellation (reservation deletion) based on the collaboration between reservation system A and reservation system C was processed without any problems, but a problem occurred in the collaboration with reservation system B, causing the reservation cancellation to fail. In this case, the user terminal is notified of the "success", but it is necessary to cancel (delete) the reservation on reservation system B. In other words, unless the cancellation on reservation system B is somehow executed, the reservation cancellation will not be completed as a whole, which creates the problem that a management mechanism for the cancellation on reservation system B is required. When changing the number of people in a reservation, the system cancels the original number of people in the reservation and then stores the correct number of people, so the same problems as when canceling a reservation occur. As a result of further investigation and analysis, the inventors discovered that these problems are likely to occur due to problems with the communication and API integration between the server 1 and the reservation system, i.e., problems with reservation integration.

[0097] In order to solve these problems, a new configuration that replaces reservation linkage has been constructed as another embodiment of the present invention. FIG. 25 is a functional configuration diagram of the server 1 according to another embodiment. As shown in FIG. 25, the server 1 (control unit 101) according to another embodiment includes a management information storage means 190, a reservation reception means 191, a reservation means 192, a seat reservation reception means 193, a seat reservation means 194, a specific information storage means 195, a seat reservation control means 196, and a change means 197. Although the reservation means 192 has the same function as the aforementioned reservation means 14, that is, route reservations, it is characterized by making reservations without linking with a reservation system, so for convenience, the terms are the same but the numbers are different.

[0098] The management information storage means 190 stores the management information stored in the reservation system (reservation server). In other words, conventionally, reservation system A stores first management information required for reserving a first route, and reservation system B stores second management information required for reserving a second route, but server 1 stores in advance the management information required for reserving the routes stored by each reservation system. This allows reservations to be accepted and executed by server 1 alone. Furthermore, since the configuration of the reservation system remains the same, reservations can be accepted and executed in the reservation system as needed.

[0099] The reservation acceptance means 191 of the server 1 accepts reservations for routes. When the reservation receiving means 191 receives a reservation for a route, the reservation means 192 of the server 1 executes the reservation for the route based on the management information stored in the management information storage means 190. For example, when the reservation receiving means 191 receives a reservation for a first route, the reservation means 192 executes a reservation for the first route based on the first management information stored in the management information storage means 190, and when the reservation receiving means 191 receives a reservation for a second route, the reservation means 192 executes a reservation for the second route based on the second management information stored in the management information storage means 190.

[0100] The server 1 can reserve seats on express buses together with the reservation of the route or separately. For this reason, the management information includes information necessary for reserving seats (seat information). The seat information includes, for example, a seat number, and vacant seat information indicating whether the seat is vacant or reserved. The seat reservation accepting means 193 of the server 1 accepts seat reservations. When the seat reservation receiving means 193 receives a seat reservation, the seat reservation means 194 of the server 1 executes the seat reservation based on the seat information stored in the management information storage means 190 . For example, when the seat reservation receiving means 193 receives a reservation for the first seat, the seat reservation means 194 of the server 1 makes a reservation for the first seat based on the first seat information stored in the management information storage means 190, and when the seat reservation receiving means 193 receives a reservation for the second seat, the seat reservation means 194 makes a reservation for the second seat based on the second seat information stored in the management information storage means 190.

[0101] FIG. 26 is an explanatory diagram of a high-speed bus system according to another embodiment. As shown in FIG. 26 and described above, in another embodiment, the management information required for reserving routes and seats is acquired (pre-stored) in advance by the server 1, so that reservations can be made by the server 1 alone. The server 1 is communicably connected to each reservation system (reservation server), and receives and acquires management information (including seat information that can identify a seat map) stored in each reservation system from each reservation system. The reservation receiving means 191 receives reservation information transmitted from the user terminal 2 in response to an operation on the user terminal 2 . For example, when server 1 receives a reservation for a connecting route or seat consisting of a first route of bus A operated in reservation system A, a second route of bus B operated in reservation system B, and a third route of bus C operated in reservation system C, server 1 executes the reservation based on the management information of each reservation system that has been pre-stored, without coordinating with each reservation system. That is, according to this express bus system, the server 1 can make reservations for routes and seats by itself, which can prevent problems from occurring that accompany reservation linkage regarding seat reservations.

[0102] Each reservation server has the same configuration as the above-mentioned server 1 (not shown). That is, in the reservation server, a means corresponding to management information storage means 190 stores information necessary for reserving routes under the management of the system, a means corresponding to reservation reception means 191 accepts reservations for routes under the management of the system, a means corresponding to reservation means 192 can reserve the accepted routes, a means corresponding to seat reservation reception means 193 accepts seat reservations, and a means corresponding to seat reservation means 194 can reserve the accepted seats. As a result, reservation servers have traditionally been equipped with a configuration that allows them to make reservations for routes and seats managed by their own systems.

[0103] (Management and reservation of seats on jointly operated routes) A "jointly operated route" refers to a route jointly operated by multiple bus companies (operators). A jointly operated route is a route on which multiple operators, including Operator A (first operator) and Operator B (second operator), jointly operate a single express bus. In this case, for example, operator A would manage the seats in the front half of the express bus (front seats), and operator B would manage the seats in the back half of the same express bus (rear seats). In other words, in this case, reservation system A operated by operator A will be responsible for reservations (sales) of the front seats, and reservation system B operated by operator B will be responsible for reservations (sales) of the rear seats. For this reason, in another embodiment, the management and reservation of seats on jointly operated routes is not carried out centrally by server 1, but rather the reservations of seats allocated to each operator are carried out by each corresponding reservation system, and server 1 provides as a basic function the management and sharing of seat information that enables each operator (each reservation system) to determine which seats to sell (whether to accept reservations). By incorporating this function, this express bus system aims to facilitate seat management and reservations, which previously had to be done individually and manually by each reservation system. Furthermore, by incorporating this function, the express bus system is also able to provide a function that allows a third party operator to handle seat reservations. In other words, the functions of the other embodiments are limited to the management and reservation of "seats" on jointly operated routes, and do not include the management and reservation of "jointly operated routes." These functions can be performed individually by each reservation system.

[0104] (Seat management for jointly operated routes) As mentioned above, seats on express buses operated on jointly operated routes are managed by multiple operators, and therefore each reservation system manages (stores) the information necessary for reserving seats. For this reason, the server 1 has a management information storage means 190 that stores information (seat information) necessary for reserving a seat managed (stored) by the reservation system, and a specific information storage means 195 that stores specific information indicating that the seat is managed by a specific operator, in association with information indicating the seat. Specifically, the specific information storage means 195 stores operator A information indicating that the seat is for sale by operator A (first operator) in association with the seat number, and stores operator B information indicating that the seat is for sale by operator B (second operator) in association with the seat number. This allows the server 1 to identify which seats each operator (each reservation system) can sell (reserve). Specifically, the seat reservation control means 196 controls the reservation means 192 provided in the server 1 to be inoperable for seats for which specific information is set in the seat information (setting: meaning stored in correspondence), thereby allowing reservations in the reservation system. More specifically, if operator A information is set for the seat number of a certain seat, the seat cannot be sold (reserved) in server 1 or reservation system B, but can be sold (reserved) in reservation system A. In addition, if operator B information is set for the seat number of a certain seat, the seat cannot be sold (reserved) on server 1 or reservation system A, but can be sold (reserved) on reservation system B. The above description is for the case where there are two joint operators, but it can also be applied to the case where there are three or more joint operators. For example, if there are three joint operators, the seat information managed (stored) by reservation system C can be acquired and stored in association with the information about operator C.

[0105] (Details of seat management on jointly operated routes) We will explain the details of seat management for jointly operated routes. 27 to 30 are diagrams showing the process (A) of managing seats for sale by two joint operators and adding a third operator to the joint operators.

[0106] FIG. 27 is a diagram showing the acquisition of seat information before sales (A1). As shown in Figure 27, before seats are sold (before reservations are accepted), the server 1 acquires and stores in advance the seat information managed by each reservation system (each operator), i.e., each reservation server (management information storage means 190). "Seat information" is information required to reserve a seat, and includes, for example, the seat number, vacant seat information indicating whether the seat is reserved or vacant, and specific information indicating which operator (reservation system) is selling the seat. In this example, seat information indicating that seat numbers A to D·1 to 4 are seats for sale by operator A is stored in reservation system A (reservation server A), and seat information indicating that seat numbers A to D·5 to 11 are seats for sale by operator B is stored in reservation system B (reservation server B). The server 1 is also communicably connected to each reservation server via the Internet or the like, and can acquire seat information via this communication. For this reason, the server 1 stores the seat information acquired (received) by the specific information storage means 195 from each reservation server. Specifically, seat numbers A to D·1 to 4 are stored in association with specific information (operator A information) indicating that the seats are for sale by reservation system A (operator A), and seat numbers A to D·5 to 11 are stored in association with specific information (operator B information) indicating that the seats are for sale by reservation system B (operator B). In addition, instead of or together with the information on operators who sell seats, information on operators who do not sell seats may be used, and "available for sale" information or "unavailable for sale" information may be associated with and stored in association with the information on operators who sell seats or the information on operators who do not sell seats. The seat information includes seat availability information indicating whether the seat is reserved or vacant. For this reason, the server 1 stores vacant seat information in association with the seat number. This allows the server 1 to determine whether each seat for sale is reserved or vacant.

[0107] The server 1 can generate a seat map for each operator (each reservation system) based on such seat information. The seat map is information that visualizes which operator's seats are for sale, whether the seats are reserved or vacant, and the seat number and seat location (FIGS. 27 to 34). Each operator has a management terminal, and the server 1 can cause the management terminal to display a map of seats (seats for sale) that can be reserved through each reservation system. For example, a unique account is set for each operator, and when the server 1 confirms (authenticates) the input of pre-set account information (user ID, etc.), it displays the operator's seat map on the web on the management terminal. The management terminal is assumed to be the management terminal of server 1 or the management terminal of a reservation system that can connect to server 1 via the web.

[0108] 27(a) is a seat map displayed on the management terminal of reservation system A, and FIG. 27(b) is a seat map displayed on the management terminal of reservation system B. 27(c) is a seat map displayed on the management terminal (also called the server terminal) of server 1. This seat map is also called the "all-operators seat map" because it can identifiably display the seats for sale and vacant seats information of each operator. For convenience, the arrows in the figure schematically show the transmission and reception of information between the server 1 and each reservation server. The seat map shown in Figure 27(a) distinguishes between seats available for sale by reservation system A (seats available for sale by operator A) and seats not available for sale (seats not available for sale by operator A). For convenience, seats available for sale are shown in "light ink" and seats not available for sale are shown with an "X". The seat map shown in FIG. 27(a) is basically intended to be viewed on the management terminal of reservation system A. The seat map shown in Figure 27(b) distinguishes between seats available for sale in reservation system B (seats available for sale by operator B) and seats not available for sale (seats not available for sale by operator B). For convenience, seats available for sale are shown with a "shade" and seats not available for sale are shown with an "x". The seat map shown in FIG. 27(b) is basically intended to be viewed on the management terminal of reservation system B. The all-operator seat map shown in Figure 27(c) distinguishes between seats available for sale in reservation system A (seats available for sale in reservation system A: light gray) and seats available for sale in reservation system B (seats available for sale in reservation system B: shaded). The all-operator seat map is intended to be displayed on a server terminal and viewed by the administrator of Server 1 (also called the server administrator), but this is not limited to this; each operator (operator A or operator B) may display it on the web on the management terminal of each reservation system.

[0109] According to these seat maps, Operator A can recognize that seats A to D·1 to 4 are for sale and seats A to D·5 to 11 are not for sale (Figure 27(a)), and can further recognize that the not for sale seats are for sale by Operator B (Figure 27(c)). In addition, Operator B can recognize that seats A to D·5 to 11 are for sale and seats A to D·1 to 4 are not for sale (Figure 27(b)), and can further recognize that the not for sale seats are seats for sale by Operator A (Figure 27(c)). Furthermore, the server administrator can recognize that A to D·1 to 4 are seats for sale by reservation system A, and A to D·5 to 11 are seats for sale by reservation system B (FIG. 27(c)).

[0110] As shown in FIG. 27, when seats for sale are allocated between reservation system A and reservation system B, server 1 cannot accept or execute reservations. Therefore, the seat reservation control means 196 of the server 1 controls the functions of the server 1, such as the seat reservation acceptance means 193 and the seat reservation means 194, to be inoperable for the seat for which the specific information is set. That is, the state of the seat map shown in FIG. 27(c) indicates that the server 1 (the express bus system) is unable to sell (reserve) any seats. On the other hand, FIG. 27(c) shows a state in which reservations for seats A to D·1 to 4 can be made in reservation system A, and reservations for seats A to D·5 to 11 can be made in reservation system B.

[0111] However, in this embodiment, the server administrator can also serve as the operator (also called the third operator). Specifically, provided that consent is obtained from each operator, it is possible to add a server administrator as a third operator, thereby enabling third operators to accept and execute seat reservations on Server 1. The following describes how to add an administrator (third operator) of the server terminal.

[0112] FIG. 28 is a diagram showing the setting of seat information before sales (A2). Specifically, this figure shows a setting method for adding seats for sale by a third operator after seat information is acquired (A1). Figure 28(a) is a seat map displayed on the management terminal of reservation system A, Figure 28(b) is a seat map displayed on the management terminal of reservation system B, and Figure 28(c) is an all-operator seat map. However, for the sake of convenience, the arrows in the figure schematically show the transmission and reception of information between the server 1 and each reservation server. More specifically, when a seat for sale is allocated to reservation system A and reservation system B, server 1 executes a process to move the seat for sale from the reservation system to the third operator by setting "unavailable for sale" information in the seat information of the seat for sale in the reservation system or by setting information indicating that the seat information is that of a third operator. For example, by operating the management terminal, server 1 associates "not for sale" information or "server administrator information" with the seat numbers A to D, 3 to 4 (dashed lines) of the seats for sale stored in reservation system A and stores them. As a result, Server 1 executes the process of adding (setting) seats A to D, 3 to 4 as seats for sale by the server administrator, and sends information to Reservation System A (Reservation Server A) that seats A to D, 3 to 4 are not seats for sale by Reservation System A (Operator A). Similarly, by operating the management terminal, server 1 associates "not for sale" information or "server administrator information" with the seat numbers A to D, 5 to 6 (dashed lines) of the seats for sale stored in reservation system B and stores them. As a result, Server 1 executes the process of adding (setting) seats A to D, 5 to 6 as seats for sale by the server administrator, and sends information to Reservation System B (Reservation Server B) that seats A to D, 5 to 6 are not seats for sale by Reservation System B (Operator B).

[0113] FIG. 29 is a diagram showing seat information (A3) after the start of sales (reservations). Specifically, FIG. 29 shows the seat map after the settings (operations) shown in FIG. 28 have been performed. Figure 29(a) is a seat map displayed on the management terminal of reservation system A, Figure 29(b) is a seat map displayed on the management terminal of reservation system B, and Figure 29(c) is an all-operator seat map. However, for the sake of convenience, the arrows in the figure schematically show the transmission and reception of information between the server 1 and each reservation server. "Blank" seats on all operator seating maps indicate seats available for sale. As shown in FIG. 29(a), A to D·3 to 4 are displayed as non-sale seats (×), and as shown in FIG. 29(c), A to D·3 to 4 are displayed as sales seats (blank). That is, FIGS. 29(a) and (c) show that the seats for sale A to D and 3 to 4 have been moved from reservation system A (operator A) to the server administrator (third operator). As shown in FIG. 29(b), A to D·5 to 6 are displayed as non-sale seats (×), and as shown in FIG. 29(c), A to D·5 to 6 are displayed as sales seats (blank). That is, Figures 29(b) and (c) show that the seats for sale A to D and 5 to 6 have been moved from reservation system B (operator B) to the server administrator (third operator). Therefore, in the state shown in FIG. 29, the server administrator (third administrator) can accept and execute reservations (sales) for seats A to D and 3 to 6 via the server 1. That is, the specific information storage means 195 stores specific information indicating that the seat is managed by a third operator (server administrator) in association with information indicating the seat, and the seat reservation control means 196 controls the seat reservation means 194 to be executable for the seat associated with the specific information.

[0114] FIG. 30 shows the addition and deletion (A4) of seats for sale after the start of sales (reservations). Specifically, the seat map shown in FIG. 29 is shown after the movement of the seats for sale has been executed. Figure 30(a) is a seat map displayed on the management terminal of reservation system A, Figure 30(b) is a seat map displayed on the management terminal of reservation system B, and Figure 30(c) is an all-operator seat map. However, for the sake of convenience, the arrows in the figure schematically show the transmission and reception of information between the server 1 and each reservation server. Once seat sales begin on this express bus system, seats for sale can be added or deleted only if they are vacant. The reason for limiting the number to "vacant seats" is to solve the existing problem that in joint operations, even if there are vacant seats, they cannot be reserved. The latest "vacant seat information" is managed (stored) in the reservation system, so the server 1 causes the reservation system to transmit the "vacant seat information" as needed. When the server 1 receives the "vacant seat information" transmitted from the reservation system, the server 1 stores the "vacant seat information" in association with the seat number. This allows the server 1 to grasp the seat availability status, such as whether the seats for sale are available or reserved. For example, Figures 30(a) and (c) show that seats C to D, 1 and 2 are available for sale by reservation system A (light ink) and are vacant. 30(b) and (c) show that seats D·5 to D·6 are available for sale by reservation system B (shaded), and are vacant.

[0115] Here, in response to operations on the management terminal, a seat for sale (vacant seat) in the reservation system can be changed to a non-sale seat, and the seat corresponding to the server administrator can be changed from a non-sale seat to a sale seat. Specifically, in response to an operation of the management terminal, the server 1 sets information indicating that the seat is for sale by the server administrator to the seat number of the seat for sale (vacant seat) in the reservation system. As a result, the server 1 transmits to the reservation server information indicating that the corresponding seat is a seat for sale by the server administrator. For example, as shown in Figures 30(a) and (c), if server 1 stores information indicating that seats D·1-2 are sold by the server administrator in association with the seat numbers of seats sold by reservation system A, server 1 will be able to recognize that seats D·1-2 are sold by the server administrator, and reservation server A will also be able to recognize that seats D·1-2 are not sold by reservation system A. This allows the server administrator to add seats D·1 to D·2 as sales seats. In other words, the change means 197 of the server 1 can change the seat to a seat managed by a third operator (another operator) by storing information indicating a seat managed by operator A (one operator) in association with predetermined specific information (information indicating that the seat is managed by another operator). As a result, the server administrator can accept and execute reservations for seats D·1-2 via server 1.

[0116] In addition, in response to operations on the management terminal, the server administrator can change a seat for sale (vacant seat) to a seat not for sale, and change the seat corresponding to the reservation system from a seat not for sale to a seat for sale. Specifically, in response to an operation of the management terminal, the server 1 sets information indicating that the seat is for sale in the reservation system to the seat number of the seat (vacant seat) for sale by the server administrator. As a result, the server 1 transmits to the reservation server information indicating that the corresponding seat is a seat for sale in the reservation system. For example, as shown in Figures 30(b) and (c), if server 1 stores information indicating that seats D·5-6 are seats for sale by reservation system B in association with the seat numbers of seats for sale by the server administrator, server 1 will be able to recognize that seats D·5-6 are not seats for sale by the server administrator, and reservation server B will also be able to recognize that seats D·5-6 are seats for sale by reservation system B. This allows the server administrator to remove seats D·5 to D·6 from the sales seats. That is, the change means 197 of the server 1 can change the seat managed by one operator to a seat managed by another operator by storing information indicating the seat managed by one operator in association with predetermined specific information. As a result, the server administrator will be unable to accept or execute reservations for seats D·5-6 via server 1. By doing this, seats that have remained vacant and not sold (reserved) under the management of one operator can be sold by other operators (including third operators). This solves the existing problem of not being able to make reservations even when there are vacant seats in jointly operated services.

[0117] 31 to 34 are diagrams showing the transfer of seats for sale between joint operators (B). FIG. 31 is a diagram showing the acquisition of vacant seat information (B1). Figure 31(a) is a seat map displayed on the management terminal of reservation system A, Figure 31(b) is a seat map displayed on the management terminal of reservation system B, and Figure 31(c) is an all-operator seat map. However, for the sake of convenience, the arrows in the figure schematically show the transmission and reception of vacant seat information between the server 1 and each reservation server. As mentioned above, "vacant seat information" is managed (stored) by the reservation system, so Server 1 can obtain (receive) "vacant seat information" from the reservation system as needed and store it in association with the seat number (similar to Figure 30). This allows the server 1 to grasp the seat availability status of the seats for sale, such as whether they are vacant or reserved. The server 1 only needs to acquire vacant seat information, and does not need to acquire reservation information. For example, as shown in Figures 31(a) and (c), vacant seat information indicating that seats C to D and 1 to 4 are vacant seats sold by reservation system A is obtained from reservation system A, and as shown in Figures 31(b) and (c), vacant seat information indicating that seats A to D and 5 to 6 and 9 to 11 are vacant seats sold by reservation system B is obtained from reservation system B. As a result, the administrator of reservation system B can display the seat map shown in Figure 31(b) or Figure 31(c) on the management terminal and understand that seats C to D and 1 to 2 are vacant seats available for sale by reservation system A. The purpose of obtaining "vacant seat information" is to solve the conventional problem of not being able to make a reservation even if there are vacant seats in joint operations.

[0118] FIG. 32 shows a request for a seat (B2). As shown in FIG. 32, by operating the management terminal, a request for a seat can be made (changing a seat available in one reservation system to a seat available in another reservation system). As mentioned above, the all-operator seat map shown in the center of Figure 32 can be displayed on the web on the management terminal of the reservation system. Therefore, the administrator of reservation system B can look at the all-operator seat map displayed on the management terminal and see that seats C to D, 1 and 2 are seats for sale by reservation system A and are vacant. As an example, a case will be described in which reservation system B requests reservation system A to obtain seats for sale (vacant seats) C to D and 1 to 2. In this case, a seat reservation request operation can be performed on the management terminal of reservation system B. Accordingly, seat request information (information requesting to request a seat for the seats C to D·1 to 2 for sale) is output from the management terminal to the server 1. The server 1 receives the request information output from the management terminal, and accepts the seat reservation request. Based on the input request information, the server 1 recognizes that it has received a seat reservation request from the reservation system B to the reservation system A. Based on this recognition, the server 1 outputs the input request information to the management terminal of the reservation system A (reservation server A) and displays it. This allows the administrator of reservation system A to grasp the contents of the request information (request to get seats for sale seats C to D·1 to 2) via the management terminal. The dashed line for "request for seat" in Figure 32 is an illustration to make it easier to understand the actual flow of a seat request, and does not represent the actual flow of information processing. The same applies to the dashed line for "approval / rejection."

[0119] The administrator of reservation system A, upon viewing the seat reservation request information, operates the management terminal to respond to the request by either approving or rejecting it. This operation can be performed on a web page provided by server 1. For example, when a "reject" operation is performed, the server 1 transmits "reject" information to the management terminal of the reservation system B. This allows the administrator of reservation system B to know via the management terminal that the seat request has been rejected. On the other hand, if the "approval" operation is performed, the server 1 executes the seat takeover. The "execution of taking a seat" will be explained with reference to FIG.

[0120] FIG. 33 is a diagram showing the execution of seat-taking (B3). Specifically, the seat reservation process stores information about the operator B in association with the seat numbers C to D and 1 to 2 in the server 1. That is, the change means 197 of the server 1 changes a seat managed by an administrator A (one administrator) to a seat managed by an administrator B (another administrator) by storing predetermined specific information for the seat. As a result, the sold seats C to D·1 to 2 are transferred from reservation system A to reservation system B. In other words, the seat transfer is executed. By doing this, seats that have remained vacant and not sold (reserved) by reservation system A (operator A) can now be sold (reserved) by reservation system B (operator B). This solves the existing problem of not being able to make reservations even when there are vacant seats in jointly operated services.

[0121] FIG. 34 shows the automation of seat pads (B4). The above-mentioned seat receiving (FIG. 33, etc.) is partially executed manually, but the seat receiving shown in FIG. 34 is automatically executed when a predetermined condition is met. Specifically, when the number of seats for sale (vacant seats) of one operator (for example, operator A) falls below a certain number and the number of seats for sale (vacant seats) of another operator (for example, operator B) is equal to or greater than a predetermined number, a specific number of seats for sale (vacant seats) are automatically changed (moved) from the other operator's reservation system (reservation system B) to the one operator's reservation system (reservation system A). For example, as shown in FIG. 34, the server 1 determines that the number of seats (vacant seats) for sale in reservation system B has fallen to two (a certain number or less) and that the number of seats (vacant seats) for sale in reservation system A is eight (a certain number or more), so it can select the four seats (vacant seats) for sale in the front: C to D·1 to 2, and change from reservation system A to reservation system B. Specifically, similarly to the case shown in FIG. 33, the server 1 may store information on the operator B in association with the seat numbers C to D and 1 to 2. The "certain number," "predetermined number," and "specific number" can be set to any value, and may be a fixed value or a variable value. For example, the number of seats for sale to be moved may be x% (for example, 30%) of the seats for sale (vacant seats) in the reservation system from which the seats are moved, or may be determined based on the relationship between a "fixed number" and a "predetermined number." This will efficiently solve the traditional problem of not being able to make reservations even when there are available seats in joint operations, without requiring manpower.

[0122] Although the preferred embodiments of the present invention have been described above, it goes without saying that the present invention is not limited to the above-described embodiments, and various modifications can be made within the scope of the present invention. For example, the configuration of the system is not limited to the above-described embodiment, and part or all of the configuration of one device may be provided in another device. Specifically, the express bus processing program of the present invention is mainly provided in the server 1, but some of the programs provided in the server 1 may also be provided in external devices including the user terminal 2, the reservation server 3, and the payment server 4. Furthermore, some or all of the information stored in the storage means 11 of the server 1 may be stored in another device, which may be connected to the server 1 so as to be able to communicate with the server 1. Furthermore, the server 1 may have some of the functions of the reservation server 3 and the payment server 4. Furthermore, part or all of the functions of one of the reservation server 3 and the payment server 4 may be provided by the other. Furthermore, the server 1 and one or some of the reservation servers 3 may be devices operated by the same business operator.

[0123] For the sake of convenience, the special transfer routes have been described based on area names, but they can also be realized based on bus stops. In this case, the area names can be replaced with bus stop names. Furthermore, the server 1 may manage flight information (including seat availability and fares) managed by the reservation server 3. In this case, the server 1 does not transmit route information (S106 in FIG. 8, etc.) or reservation request information (S206, S208 in FIG. 12, etc.), and the server 1 can essentially perform the reservation process itself.

[0124] Furthermore, although the above-described embodiment is a system relating to transfers on express buses, the present invention can be expanded to include systems relating to transfers between other means of transportation, such as airplanes and bullet trains, in addition to express buses. In another embodiment, seat linkage can be applied to reservation processing for regular routes as well as connecting routes. In addition, in the other embodiments, the case where there are two co-operators has been described as an example, but the present invention can also be applied to a case where there are three or more co-operators. It can also be applied to routes jointly operated by an operator who runs one reservation system and a third operator (server administrator). Furthermore, the automation of seat collecting may be performed using AI (Artificial Intelligence). For example, reservation system A and reservation system B can be trained (using machine learning or deep learning, etc.) on their past performance in terms of the number of seats sold and the number of seats given, and a model (program) can be generated that can output the number of seats given to one system when the number of seats sold by the other system reaches a specific number.The number of seats sold and the number of seats remaining for sale in one system or both systems can then be input into the model at regular intervals, so that the seats can be automatically given at the optimal number and timing. [Explanation of symbols]

[0125] 1: Server, 101: Control unit, 102: Memory, 103: Storage, 104: Communication unit, 11: Storage means, 12: Extraction means, 13: Display control means, 14: Reservation means, 15: Payment means, 16: Reservation change means, 17: Reservation cancellation means, 18: Benefit granting means, 190: Management information storage means, 191: Reservation acceptance means, 192: Reservation means, 193: Seat reservation acceptance means, 194: Seat reservation means, 195: Specific information storage means, 196: Seat reservation control means, 197: Change means, 2: User terminal, 201: Control unit, 202: Memory, 203: Storage, 204: Operation unit, 205: Display unit, 206: Communication unit, 3: Reservation system (reservation server), 4: Payment system (payment server), 9: Internet

Claims

1. A transportation reservation system including a server and reservation systems that store management information required for reservations for a plurality of routes operated by a plurality of operators, The server a management information storage means for storing management information previously stored in the reservation system; a reservation acceptance means for accepting reservations for the route; a reservation means for executing a reservation for a route based on the management information stored in the management information storage means when the reservation for the route is accepted by the reservation accepting means; A transportation reservation system characterized by:

2. The plurality of operators include a first operator and a second operator; the plurality of routes includes a first route operated by the first operator and a second route operated by the second operator; The reservation systems include a first reservation system operated by the first operator and a second reservation system operated by the second operator, The management information storage means storing in advance first management information stored in the first reservation system operated by the first manager and second management information stored in the second reservation system operated by the second manager; The reservation acceptance means A reservation for a route including the first route and the second route can be accepted, The reservation means When the reservation acceptance means accepts a reservation for the route, the reservation for the route is executed by executing the reservation for the first route based on the first management information stored in the management information storage means and the reservation for the second route based on the second management information.

2. The transportation reservation system according to claim 1.

3. The management information includes seat information necessary for reserving seats on the means of transportation; a seat reservation acceptance means for accepting seat reservations; a seat reservation means for executing a seat reservation based on the seat information stored in the management information storage means when the seat reservation is accepted by the seat reservation accepting means; 3. The transportation reservation system according to claim 2.

4. the management information includes, as seat information necessary for reserving a seat on the means of transportation, first seat information that is seat information for a first seat on the first route and second seat information that is seat information for a second seat on the second route; The seat reservation acceptance means A reservation for seats including the first seat and the second seat can be accepted, The seat reservation means When the seat reservation acceptance means accepts the seat reservation, the seat reservation is executed by reserving the first seat based on the first seat information and reserving the second seat based on the second seat information, both of which are stored in the management information storage means.

4. The transportation reservation system according to claim 3.

5. A transportation reservation method using a server and reservation systems that store management information required for reservations for multiple routes operated by multiple operators, a first step of storing management information stored in the reservation system in advance; A second step is to accept the reservation of the route; a third step of executing the reservation of the route based on the management information stored in the first step when the reservation of the route is accepted in the second step. A transportation reservation method characterized by:

6. A computer connected to each reservation system stores management information required for reservations for a plurality of routes operated by a plurality of operators, management information storage means for storing management information stored in the reservation system; A reservation acceptance means for accepting reservations for the route in advance; When the reservation acceptance means accepts a reservation for a route, the reservation acceptance means functions as a reservation means for executing the reservation for the route based on the management information stored in the management information storage means. A transportation reservation program characterized by:

Images